gzahar

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.

Because present month in not 10 is now false. Even though present day is not 31 is true, when ‘anded’ with a false will result in false. There may be a direct way to put in the logic you are wanting, but easiest way may be to set a variable in another program based on month is 10 and day is 31. Then use that variable in program above.

You man need to assign the temperatures (or at least one of them) to a variable and then compare.

It is built in to the board:

I would think the 12v trigger out could power the relay without a separate power supply. Only requires 30mA. It should definitely not require any connections on the relay output side to test. Your relay out connections look fine. For the input, the 12V trigger + (probably tip on the 3.5mm connector, but I would check with voltmeter) should go to relay board VCC & INPUT. The 12V trigger - (3.5mm ring connection?) would go to GND (the two ground inputs are tied together internally, so either should work). Have you verified the trigger output is activated? (the LED will only come on when it is active)

Doubtful, but I used one of these in front of an I/O Linc to detect audio out of a Ring chime unit. https://www.aliexpress.com/item/32879003728.html?spm=a2g0s.12269583.0.0.66e81bfcT3GAjw

I think your best bet is to cap the KPL load wire and use a secondary Insteon device (micro module, etc. as suggested) to control the second motor with an ISY program based on Fanlinc status.

Good catch. Forgot about that. It must be inherent delay in the status changing that restarts the program. Or it’s queuing up the status change?

It is not getting to the Stop program command. When you change the device (center ceiling) it causes the program to re-trigger the 'if' evaluation and run 'Then' or 'Else' accordingly. You have created an infinite loop. As far as why the stop menu command is not working, I can only guess. The last insteon command to change the light has probably already been sent out by the PLM when you issue the stop. But the light then responds to the command after the program has stopped (due to communications or queue delays) and that starts the program up again.

Please click on the red IRLinc E shown in your latest picture. It will have a set of scene definitions. Do they match your 1st picture?

How are you activating the scene? Can you show this section of your scene:

You could use something like this paired with an I/O Linc. https://www.amazon.com/dp/B00LWX9PPA/?coliid=I3TZQA51Z1RMS9&colid=3FU9DR7KP09DP&ref_=lv_ov_lig_dp_it&th=1

I see similar situation with programs involving node servers (but not Sonos specific) after a reboot of ISY. I can also fix the issue by toggling the state of the node in the ‘if’ statement. What version are you running? One of the newer RCs has a fix for a similar issue with ELK nodes. Was hoping it also fixed this. I haven’t tried the last two. You are seeing this reoccur without an ISY restart?