MrBill

that should work assuming 'ELK / Jameson' Alarm Status is Entrance Delay is Active is valid... (I don't have ELK). you can always break into 2 programs which might help spot the issue. Alarm Entrance Delay - [ID 0023][Parent 0001] If 'ELK / Jameson' Alarm Status is Entrance Delay is Active Then Run Program2 (if) Else - No Actions - (To add one, press 'Action') ---- Program 2 (Must be DISABLED) Alarm Entrance Delay - [ID 0023][Parent 0001] If From 5:00:00PM To Sunrise (next day) Then Set 'Welcome Home' On Else - No Actions - (To add one, press 'Action') Reminder: disabled programs still run when run by another program, they won't be triggered by IF conditions however.

@Clarence Martin if you have the pro version on 994 or any version on Polisy/eisy you will have these two buttons on the admin console ribbon: you can use the left one to pause automatically writting to hardwired devices. the right one is the same thing for wireless devices. When scene programming it's best to press both so they are "deselected" or greyed out. this will cause the changes to be batched by the admin console... press the left button again to enable to cause the batched changes to be written when you are done making scene changes. If you have unwritten battery device changes queued that will also slow changes, when writing scenes. do you see any 1011 icons like this (or greyed out) hanging around, especially on wireless devices? those will cause problems when writing scenes and make it take longer.

One issue is that most don't realize there were 3 differnt firmware versions for the leak sensor. Here's a post that describes the differences:

right click the program name and choose Copy to clipboard and paste (ctrl-v) into a forum post, and let's see what the program does.

You can stop all programs by creating a folder condition on the top folder in your program tree. Create one that will never be true, like any integer variable you have = -99999999 or something like that, then . Also check the error log for clues as to what's going on.... Tools > Error log.

When using Percents i've never mixed in "Turn on" with the command... I just say "Alexa, set X to Y" (you can actually omit the word "Percent"). Example, "Alexa, Set Lamp one to 30"

you likely need two temp programs to establish a hysteresis. If Temp > 37 then Enable Program Gen Sump2 Run Program Gen Sump2 If Temp < 36 then Disable Program Gen Sump2 Set 'Generator Sump' Off Also note that other programs that are not disabled may be behaving differently than you're expecting and may interfere. So be careful what's in the tree, If statements are event driven and operate differently than new to the platform expect. You'll note in my examples I've done two things enable and disable the schedule and ensure that it gets enforced. In the first program I'm not entirely certain the run line is needed, it may not be but it won't hurt either. In the Second program if you disable the schedule while the pump is running the pump will continue to run forever, so if the temp drops we also need to turn off the pump. A possible improvement to the second program is: If Temp < 36 AND Program 'Gen Sump2' is false then Disable Program Gen Sump2 Which will instead will wait until the pump turns off based on the schedule if the temp falls below 36 while it's running. You can also probably run these programs to a lower temp, I usually don't worry about freezing above around 28 or so. ---- Finally when posting programs to the forum, please don't post screenshots. Instead Right-click the program name in the tree and choose the last item in the context menu "Copy to Clipboard", then Paste (Ctrl-V) that into your forum post. This allows those of us helping you with programming to Copy your program and paste them into our response and then make changes. it's much faster to write responses to you. Thank you.

@Kentinada if you keep your admin console open 24/7 then I suppose not. Personally I only open the admin console when I need it... at some point in the past I had trouble leaving it open alot--but that was many firmwares ago.. Edit to add: the selection only applies when the Event Viewer window is open. it's not logging at level 3 in the background... the window must be open.

Use the place to connect two low voltage wires, but only use the terminals for the buttons not the other ones for the safety beam.😁 In all seriousness tho, not every new garage door opener will accept a momentary contact anymore. Some such as newer Liftmaster are expecting an electronic control and if you want to use a momentary button you need an interface for that, or you need to solder to an existing wall controls actual button.

Those programs are hard to read and I think missing a few characters (also not everyone has word, or will download docx files--- virus threats spread by word files are real). When you have the need to post programs please right click the program name, choose the last item-- copy to clipboard -- then paste the program into a forum message (right click in the post and choose PASTE or simply click into the post and type CTRL-V). I think you must have some scene's involved as well. The top two control programs don't seem to have anything to activate them, they aren't called by the lower two programs. Missing info, need complete picture. as @oberkc mentions you may also have some scene's involved. You also seem to be doing something non-standard. here's one commonly used method, see also the ISY Cookbook page 368 (pdf page 391).

@Ricka2 are you using Windows or Mac? Mac users often need to download the admin console from the ISY itself and store it on the desktop. http://IP.ADDR.OF.ISY/admin.jnlp (you'll need to clear the java cache again before starting, also get rid of any existing files named start.jnlp or admin.jnlp beforehand).

@KConoverSince you're using an ISY994i try http://IP.ADDR.OF.ISY/desc The instructions by @tazman are for a Polisy. Note in the case of Polisy I would use: http://IP.ADDR.OF.ISY:8080/desc rather than https://IP.ADDR.OF.ISY:8443/desc (in short http and port 8080 go together, and https:// and port 8443 go together-- and since your home network should be trustworthy there's really no need for the extra overhead added by using https:// and 8443) Note: IP.ADDR.OF.ISY must be replaced by an actual IP of the ISY, so in your case http://192.168.1.159/desc

Tools > Diagnostics > Event Viewer > (set to level 3) might give a clue, but it would need to be open when it happens again. Assuming you mean an Insteon device, here's what I'd do first: Click the device in the tree. Note if there are any scene's involved with this device by looking at membership on the right: right click the device name, pick "Restore Device", do that also for any other devices you may have found belonging to a scene in Step 1 above Go to the programs tab and right click a program to get the the find tool. Search programs for the device and any scene found in step 1 to see if there's a program you forgot about. If it does it again after this, then Factory reset the switch (Pull the set button out, wait 30 seconds, push the set button all the way in AND HOLD IT all the way until until the long beeps ENDS or STOPS. (you'll likely be holding it in for 20-30 seconds, its important that once you start pushing the button back in that you push all the way down and HOLD until the beeps are done, letting it up early or not pressing completely in a single motion will mean the factory reset is not performed.) Once the switch has been factory reset you will need to RIGHT click the device in the tree again and again pick "Restore Device" to reprogram it. If it still does it again even after this, try to capture the event in the Event Viewer and post that if you need help reading it.

State variables have the magical property of being able to trigger an IF statement. Integer variables act as a filter in an IF statement, they must be coupled with an AND to something else that provides a trigger or the program must have been run from another program.

You must be using a state variable. with this limited view of how the variable is being used my initial reaction is to say switch to an integer variable. The IF is triggering twice and apparently in the same second, or at least the ISY is seeing it that way. Whats happaning is the value is > 1 and the time is 7am which triggers the program, the fact it's a state variable as soon as the value changes the program is triggered again--because the value of the state variable changed. As noted the limited view fix is to change the variable to Integer which won't trigger the IF statement on any change. The other fix is to use two programs: Variable Rain Delay Clear.0 - [ID 0016][Parent 0001] If Time is 7:00:00AM Then Run Program Variable Rain Delay Clear.1 (if) Else - No Actions - (To add one, press 'Action') --------------- Variable Rain Delay Clear.1 - DISABLED If $RainDelay >= 1 Then $RainDelay -= 1 Else - No Actions - (To add one, press 'Action') The second program MUST be Disabled. A disabled program still runs when specifically run by another program, as in my example here. Be careful: The second program is a good example of how to create an infinite loop that brings an ISY to it's knee's. If $RainDelay is a state variable as soon as the value of $RainDelay >= 1 changes the program runs again because $RainDelay is a state variable and its value changes. When you write a program that has that potential I would recommend adding a delay to the beginning of the THEN statement so that ISY isn't caught in an infite loop that causes the admin console to respond slowly.... such as: If $RainDelay >= 1 Then Wait 2 seconds $RainDelay -= 1 the wait must be before (not after) the "$RainDelay -= 1" to be effective. Once you've entered the realm of intentionally disabled programs that are subroutines it's also a good practice to keep updated a program that runs on start up to make sure those programs stay disabled. We've seen odd conditions that make disabled programs enabled (usually firmware upgrades). Disabled-Intentionally - [ID 013A][Parent 0001] [Run at Startup] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Disable Program 'Variable Rain Delay Clear.1' { .... add any others you create in the future here.... } Else - No Actions - (To add one, press 'Action')

excellent catch! Seems like a simple fix, hope @Michel Kohanim takes note since there isn't a forum bug submission/tracking process.

post the program. Right click the program name in the tree, pick the bottom entry "copy to clipboard" then paste it in a forum message. this also sounds like an X-Y Problem, so tell us what your really trying to accomplish because they may be a better way.

As @Bumbershoot points out it's far easier to have them separate. The instructions he linked only install HA core as another process. With HA yellow, or even HA on pi, the OS is customized/optimized for HA, and Supervisor exists to manage the next layer. You probably don't realize it but supervisor is managing containers under HA OS, thats what makes managing Add-on's and updates stupid simple for the average one day a month system admins like me or you. Keep em separate.

They are insteon door sensors, when they open or close they send on or off to the ISY... the status in the top lines of the .on and .off catch when they change status.... they are married with an AND to the status of the button so that if they button is already off or on, it don't send uneeded insteon traffic. that doesn't come into play when the say the front door opens triggering the program, but does come into play when .refresh hammers those two programs about every 10 minutes, only sending insteon traffic when there is the need to change the state. I don't use the + anymore, at one time it meant there was an Alexa spoken in the portal for that node, but there are still a few hanging out in my program tree. The # indicates the the A button of this switch has the load attached. that's also about to go away (on a snowy day in January)... All my Insteon nodes either have {hide} or # in the string... that worked great for my needs once when I was still using mobilinc, but now that I also run Home assistant I'm going to change all the {hide} to ~ and drop the # altogether. That's a giant job tho, because first i need to sit and rename nodes for a long time, then when I reload Home Assistant and lots of things will be broken...lol. I figure my node renaming project is a good two days worth... 🤣

Have you opened a ticket? sounds like it might be time: support@universal-devices.com

It's possible that there is another failing component that doesn't often fail. You've tried 4 different PLMs so that suggests it could be the device at the other end of the cable..i.e. the 994. while it's uncommon to have serial port issues there... it's not impossible. also this was an interesting post yesterday on the range of issues with bad PLMs:

Java control panel, advanced tab: then see what's happening via the java console window when the busy light is on and you're unable to enter your password.

I don't know, outside of the method you're attempting to use with a state variable. As I mentioned before we don't really have the concept of "all on" in our system. H in almost all cases is "All Off behind you" In short, that means if your existing the Master Bath H will turn off the bathroom, if you're existing the master bedroom then H will turn off the bedroom AND the bathroom. As far as turning on we either have scene's to use or individual devices. In the case of scenes the respective button will be on if the scene has been activated. The "All Off" button is set as "non-toggle Off" which means when the button is pressed it always sends "off' to the scene it's attached to. As a "non-toggle Off" the H button is never lit (it does light briefly when pressed but is normally always off) The only place I'm really trying to make a button display a status not part of scene is a "door open" light. I fought with this for a long time. It was always wrong. Originally it was a single program such as.... If Front door is on or Back door is on or ......etc..... then Turn on dooropen light else turn off dooropen light "dooropen light" being a scene, whose only member is the button. It was rarely in synch... adding a little delay helped as in... If Front door is on or Back door is on or ......etc..... then wait 2 seconds Turn on dooropen light else wait 2 seconds turn off dooropen light but it was still constantly out of synch.... It finally evolved into the following 4 programs: =================================================================================== DoorOpenLight - [ID 018B][Parent 0034] Folder Conditions for 'DoorOpenLight' If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Allow the programs in this folder to run. ----------------------------------------------------------------------------------- DoorOpenLight.off - [ID 0125][Parent 018B] If ( 'Door Switches / Barn OHD' Status is Off And 'Door Switches / LowerSlider' Status is Off And 'Door Switches / UpperSlider' Status is Off And 'Door Switches / Front Door' Status is Off And 'Door Switches / Garage-North OHD' Status is Off And 'Door Switches / Garage-South OHD' Status is Off And 'Door Switches / Playroom OHD' Status is Off And 'Door Switches / Barn Walk-thru Door' Status is Off And 'Door Switches / Playroom Door' Status is Off And 'Door Switches / Garage to House Door 2' Status is Off ) And 'Garage Entryway+# / Door Open' Status is On Then Wait 2 seconds Set 'Door Open Light' Off Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- DoorOpenLight.on - [ID 002D][Parent 018B] If ( 'Door Switches / Barn OHD' Status is On Or 'Door Switches / LowerSlider' Status is On Or 'Door Switches / UpperSlider' Status is On Or 'Door Switches / Front Door' Status is On Or 'Door Switches / Garage-North OHD' Status is On Or 'Door Switches / Garage-South OHD' Status is On Or 'Door Switches / Playroom OHD' Status is On Or 'Door Switches / Barn Walk-thru Door' Status is On Or 'Door Switches / Playroom Door' Status is On Or 'Door Switches / Garage to House Door 2' Status is On ) And 'Garage Entryway+# / Door Open' Status is Off Then Wait 2 seconds Set 'Door Open Light' On Else - No Actions - (To add one, press 'Action') ----------------------------------------------------------------------------------- DoorOpenLight.Query - [ID 014C][Parent 018B] If From 5:28:28AM To 11:59:59PM (same day) Then Run Program 'DoorOpenLight.refresh' (Then Path) Repeat Every 54 minutes and 54 seconds Set 'Garage Entryway+# / Door Open' Query Else Stop program 'DoorOpenLight.refresh' ----------------------------------------------------------------------------------- DoorOpenLight.refresh - [ID 00FF][Parent 018B] If 'Garage Entryway+# / Door Open' is switched On Or 'Garage Entryway+# / Door Open' is switched Off Then Repeat Every 10 minutes and 10 seconds Run Program 'DoorOpenLight.on' (If) Wait 3 seconds Run Program 'DoorOpenLight.off' (If) // to instantly force the door open light to refresh, push the Door Open button to activate the (IF) // // Otherwise this program will continue to run every 10 minutes. // What still may not work is if ISY thinks status of button in differnt than actual button status // (current design Minimizes insteon traffic-- we could add a device query to the loop) // Else - No Actions - (To add one, press 'Action') All of these were carefully written to minimize Insteon traffic. For example you'll note that in the .on and .off programs (the first two) the THEN body only runs if the light needs to change state... in other words if the status light is already off we don't turn it off anyway... (remember Insteon is SLOW communication and other things are injecting traffic.) When looking at just these two programs it doesn't make sense why... but consider that the 4 program (.refresh) is running each of these programs every 10 minutes and 10 seconds.... as a result no Insteon traffic is generated if it doesn't need to be, only of the button has gotten out of sync. Further the .query program runs a query every 54 minutes and 54 seconds to make certain the ISY knows the current state of the button. It query stops overnight because when the query runs during the 3AM query it sometimes causes Insteon collision problems, I could have written the timing to stop the programs from 2:55am to 3:30am but i just stopped it overnight because the buttons never get out of sync overnight. This type of logic all works well on a small scale but won't work well for lots of different queries all over the place. the problem is Insteon collisions is real-- that's how the door open light gets out of sync in first place. Remember two things when programming... 1) Insteon comms is SLOW... think 300 baud dialup modem slow (if you're old enough to remember those days...) 2) because of 1 take care to write programs in ways that they don't generate excess Insteon traffic... (turning off a scene or device that's already off, etc).

I did that above... here it is repasted: What I would do if I were you is just simplify this. If Time is Sunset - 30 minutes Then Set 'Scenes / Device Scenes / Front Outside' On Set 'Devices / Master Bedroom / Master Bedroom KP Dimmer / A: Master Bedroom Outlet' Backlight On 1 / Off 0 Set 'Devices / Living Room / Living Room Lamp Dimmer' On 60% Set 'Scenes / Special Scenes / KitchenIslandAndSink' On Set 'Scenes / Device Scenes / Office Brian' On Set 'Scenes / Device Scenes / Office Lori' On Set 'Scenes / Program Related_Scenes / KPL All Off On / prs_KPL_All_Kitchen_On' On Resource 'Hue Morracan Lamp On' Else - No Actions - (To add one, press 'Action') Basically everything you were doing with other routines is included in this revised program. The sunset program, the "some downstairs" program and the state change of the on button. I used to use a lot of run Programs to avoid setting the same things up multiple times, in the end tho the ISY or the PLM doesn't seem to manage the buffer very well. You must remember while creating programs that the Insteon protocol is very slow compared to the speed programs run. It also seems like having program X inject something into the buffer, then program Y also inject into the buffer just creates collisions. In short, I've had better luck only letting one program at a time inject Insteon commands into the buffer. I'm even careful when i create a new Sunset program to use some random offset to keep it away from the others. For example the lighting controls run at sunset, but adjust scene for the bathroom light programs runs at Sunset + 1:11. Sure it seems like we shouldn't have to deal with things like that, but I've found when I do, I have much greater system reliability. The beast is really how slow the Insteon protocol is.

The other thing that you could try is to delete the portal node server and recreate. (I'd reboot the ISY with the node deleted before re-adding.)