MrBill

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.

I've used brother clear labels for other things. You should also check out Niimbot they are easier to customize in Size and add graphics etc.... Amazon has them but pricing all over the place. it's a chinese product with multiple importers... Clear labels are defiantly available. There are several sizes of printers, they are bluetooth, you customize your label in a phone app then print.

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... 🤣

I believe you should be able to swap in standard Insteon 2477d dimmers for those. Hopefully the modules that those control don't put out interface back feeding on the line. Perhaps I'll tag @Brian H to see if he agrees on the dimmers (see the schematics 2 posts upward). I don't. But i would definitely take the step to put a time delay relay to enforce the 15 minute off cycles. The problem with Insteon or another other remote switching/home automation solution is that it not infallible. There's always a chance the signal doesn't get through. I don't have enough hours right now to study the schematic.... there maybe a way to add a solid state timer circuit relatively easy--to the existing control circuit already powering contactors. I used an ITE programmable relay for something like this 25-30 years ago, it was two pole and had the ability (set via dip switches) to program a cool down cycle... it was actually for some HID lighting that needed to be powered off 15 minutes out of each 24 hours. There's a lot of other people around here that may be able to suggest a more concrete good plan, I'm just short on time cycles for about the next 7 days.

Ahh I see. This is very interesting. I'm surprised tho that they didn't engineer the control panel with some type of time delay relay to enforce the off cycle every 4 hours. It seems like with the current wall timer it would be possible to just go turn it back on immediately. Can you identify the specs or make/model of the dimmers? not all dimmers are created alike. If I were designing the automation for this for my own house, I'd look at adding a time delay relay to the circuit to prevent the possibility of automation failure for the 4 hour cool-down cycle.

The three gang control is certainly interesting. The inards of your control box contain contractors (relays) that switch the timed load. I'm not sure what the load requirement for the dimmers is, or even what they are dimming. You could definitely replace the right hand timer switch with an Insteon On/Off switch and control it. I'd write the program so that it Turns the switch off, waits 15 seconds and does a query to make sure the switch is really off. Need more info tho to figure out how the dimmers are working in this circuit.

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.)

Have you tried completely deleting the program and recreating it? or even create a second identical program and disable this copy.

I did miss the 994 in the title when i as i thought through the possibilities and wondered if it was an IoP issue... Does the Program Summary tab give you any clue? Like a yellow warning message for the program. If the admin console was open when the program quit responding you may need to close the admin console and re-open it to see a non-normal status on the summary page.

v5.3.4 generally implies you're speaking of an ISY994 and not a Polisy running IoP, but since there was a 5.3.4 at one point on Polisy it's ambiguous which hardware you're running on.... I essentially do the same thing, only updating 1 state variable, and never have the problem. Perhaps you should post your programs. (Right click the program name, Copy to Clipboard, and then paste into a post.) The only other issue I can imagine is that your programs becoming corrupt which would hint at a bad SD card, but I think you would be having much greater issues than just this...

Something really sounds off here.... at one time @InsteonNut had a great relationship with UD. The only thing I can figure is mobilinc is asking for a change or update that UD can't accommodate in the current vision. I choose to move away from mobilinc long ago... but still actually use mobilinc pro for one obscure needs that pops up a few times a year.

As mentioned elsewhere, you're also running HA, you can add the screenlogic integration. Then pick the values that you need updated to ISY and I'll be more than happy to assist you getting them there and/or creating automations on the HA side that meet your needs. Unfortunately there are only about 3 users: you, me and one more that have Screenlogic, there is not a great demand for the node server.

@Michel Kohanim specificity stated PG2 can't be stopped just yet. Remove all the node servers and ignore it. Shouldn't use any noticeable resources running empty.

My point is the best way to do it is just create programs that do everything themselves.... the way you're using programs as subroutines can work, I do it several places such as my goodnight and away routines that use the same list of turn off's. You're not saving a million lines of code doing it the way your doing it, but you're creating a buffer timing issue. I thought you could work around that by moving the Run program to the bottom of the program and adding a wait before it, but you said that didn't work. My best suggestion is have your programs do everything they need to do within one program. In the case of my Goodnight / away situation yes the turn off list is a common THEN block but it's the only string of insteon commands being sent, so once insteon is being executed there are no other programs to inject "noise" or "confusion".

Gosh I guess your right, I'd have trouble imagining a complex installation. I have 346 Insteon Nodes, 112 scenes, 67 node server nodes, 87 state variables 109 integer variables and 507 programs, that the ISY, on the Home Assistant side there's even more.... but I likely can't imagine an installation as complex as yours. Good Luck!

UD's always been a hardware company. Polisy and eisy are brothers... they both based on FreeBSD. UD chose a platform purposely so that it wasn't simple to just go the Pi route. Unfortunately we are at an odd time in the lifecycle of the product. Last April Insteon closed it's doors, as a result there was huge unprecedented and unexpected demand for Polisy. To UD's surprise it was unable to order some parts with appropriate lead times, so Polisy was redesigned and 'eisy' was born. Very similar to Polisy similar main board, slightly different ports and a different case, both run the same software under FreeBSD. Actually it's not difficult to figure out... but by your own admission you haven't been paying attention. @Geddy explained it all... but you seem to have chose to either not read or not absorb his post. Polyglot 2 which was NOT originally created by UD is deprecated. The Developer is gone, no longer working in the project. Polyglot 3 was developed by UD to run on hardware produced by UD. As noted, you may be able to get PG2 running on a Pi, but the developer is no longer around. UD's new hardware will be available very soon, its has taken a little longer than originally predicted and the ship date hasn't been announced but we are down to weeks, not months.