gzahar

This:

Not sure if link below will paste correctly, but thread in Q&A mentions just fixed in 5.3.0. hinge pin zw door sensor https://r.tapatalk.com/shareLink/topic?share_fid=23986&share_tid=22166&url=https%3A%2F%2Fforum%2Euniversal-devices%2Ecom%2Findex%2Ephp%3F%2Ftopic%2F22166-hinge-pin-zw-door-sensor&share_type=t&link_source=app

Sorry, didn’t see picture you posted earlier. And you clicked on modules button. Nothing was listed for purchase?

You need to login to the UDI web page to purchase the Zwave module.

Don't know if you can change the username, but passwd should allow you to change password.

I found putting a repeating device a few feet from my ISY really helped my network communications.

You should be able to use http://<ipaddress of ISY>/admin.jnlp to download.

Don't know what is causing it. Failing is obviously a possibility. A new bulb (noisy load) could be another, but doubtful. You could check the device link table, or just restore the device (with a factory reset first if a restore on it's own doesn't do it).

Delete the routine, re-discover your devices and add the routine back. Only thing I can think of.

If I follow, you are talking about an Alexa routine (not ISY program). So state variable shouldn’t matter, but should still work. Stupid question, the routine is enabled, right? I stand corrected: "In addition to ISY nodes and ELK zones, you can also expose a state variable as a motion sensor."

No. Thanks.

My login shows: FreeBSD 12.1-RELEASE-p1 r355229 POLISY When I would check the web UI for updates it just disappeared after a while and didn't indicate if updates were available or not. Ran 'sudo pkg update && sudo pkg upgrade' and it went through an installation process after which I rebooted Polisy. Now the 'check for Polisy updates' returns no updates available (as I would expect). Curious if the -p1 (which I still get) vs -p10 release information is an issue. (no problems with Polisy that I am aware of)

You forgot to list this program. Run Program 'ISY Uptime' (Else Path) Upon further inspection of the programs, doesn't appear to be relevant to DST operation. Thanks again.

Thanks for the heads up and the programs! FYI, It's Daylight SAVING (no s) Time.

The scene works completely outside of ISY (once you set it up). So disabling the sensor in the ISY admin console really doesn't do anything to the scene operation. You could pull the air gap on the switch. Or delete/adjust the scene as you have done.

I don't think you can delete the /user/web directory itself. But you should be able to delete any files/directories below that. Right click / delete works for me. Maybe try to restart the Admin console?

Just wrote a program to test the query issue for the IOLinc sensor. I get the same results. So doubtful a communications issue (at least a manual query triggering a program). If I press the query button at the bottom of the device page, nothing; but if I right click the node and select query it triggers a program every time. Curious. Sounds more like a bug, unless there was some reason they did it that way that I can't see. Regardless, that doesn't seem to be causing your problem. I'll leave the program in tact overnight to see if I get any hits from the 'query all' just to verify. I would imagine the issue to be more prevalent if it did. So at this point you have an isolated? instance of the overnight query causing the program to trigger. It is definitely possible that one time a message got lost and the status was incorrect when queried and properly caused a program trigger (could also occur after an ISY reboot if the query is disabled). So you're either back to filtering or beefing up your Insteon communications (which will never be 100%) or program around it so that it doesn't go off in the middle of the night. If you have a goodnight routine, you could include a query there. Also a query every hour? would decrease the likelihood of a 3:00 announcement. Or as you said, remove the announcement altogether. FYI, I set it up both with and without trigger reverse selected and got the same results. Don't think that is your issue either.

@jmwhite5Are you basing your announcement on the status of the sensor input or the relay? If you are using the relay and it is using the momentary mode, the ISY will see the relay close (ON) but not open. If this is the situation, you can create a program that query's the relay a few seconds after detecting a relay change to get it back in sync on the ISY. Gate Relay Reset - [ID 00D9][Parent 0108] If 'Backyard / Gate-Sensor / Gate-Relay' Status is On Then Wait 3 seconds Set 'Backyard / Gate-Sensor / Gate-Relay' Query Else - No Actions - (To add one, press 'Action')

Maybe you need to change the backlight setting? In 6 button mode, the Off button should definitely illuminate when the switch is off.

I'm on 5.0.16C and it has been that way as long as I remember for 5.x. But I started later in the 5.x cycle. IIRC there is a note in 5.1? or later referring to this being the required method going forward. (meaning you would have to hit the backlight button after changing the dropdown) Found it: The 5.1.0 (RC2) Release is now available. - New – Some changes to the Admin Console o You now have to press the button when issuing a command for a node on the device page (rather than just change a parameter for the command to automatically be submitted)

What I am saying is that you don't need to set the level twice on the second device. Just hit the backlight button (without changing the dropdown) and it should write the current value in the dropdown (what you set the first device to) to the second device.

I know this does not address the bug of not being able to retrieve the current backlight level. If you just press the backlight button to the left of the drop-down value, it writes (hopefully what is shown in the drop down) to the device. It appears to be writing something at least, I can not verify what value it is writing. If so, you don't need to change the drop down to something else and then back to get it to write the current value shown.

Reading back through your original post; given that you had two different devices act the same way and another blow up, I would focus on AC issues if the problem resurfaces. Possibly a filter would help. Another idea is that the original lamp module did something to the socket it was plugged into when it went bad (assuming the replacement devices have used the same outlet).

That is what I would try.

In the Program Summary tab you can also sort programs by when they last ran. And you can disable programs by right clicking on them.