MrBill

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.

@GTench I agree with @Geddy even if it's informational when they are posting sometimes two rows per second as in your log, it's time to get to the bottom of it. You can send your entire log to support@universal-devices.com they maybe able to identify an issue. Your error log shouldn't get hammered like that. My error log gets just a few rows per day usually.

A feature is that each scene controller can control the scene differently. Click first on the Scene name, or the root of the scene, look at the right window, that's how the scene is configured when the ISY itself is the controller. Now click each scene controller one at a time (each RED link) and check the the scene is correctly configured for each scene controller/button.

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

Yes don't stop it. Also I would NOT upgrade firmware until you get your system back to normal. Beware upgrading from 4.9 to 5.3.4 may or may not be a simple upgrade. Don't just upgrade from 4.9 to 5.3.4 without doing your homework, and get your system working correctly first.

@headless, I agree with @TFay... also keep in mind that @io_guy isn't making any money off nodelink. It free software and it's supported pretty darn well for free stuff.

FYI, File > Restore devices should be reserved for specific cases. Also you need to avoid other insteon traffic during that process. if your system is large it takes awhile, other traffic will often times create new problems you didn't have before. Before using File > Restore devices I would try to stop programs with a false IF statement in the My Programs Folder (be sure to remove it later), and if you have motions either put paper over them or make sure no one triggers them. After "Restore Device" (the individual device) doesn't work, the next step should be to Factory Reset the device, and "Restore Device" a second time. If you create new profiles with your "Restore Devices" above just use individual "Restore Device" to try and fix it.

I have a lot of H is "all off" instances, but I don't really use the concept of all on. H is simply set as "Non-Toggle Off" and is attached to a scene only, not a program. If your use case is working for you go for it.... but it does increase the amount of insteon communication required, thereby creating some of the collisions you're dealing with. I really think moving the "sub-routine" to starting 3 seconds after the other commands will improve your situation.

Comcast Mail: Server: smtp.comcast.net user: the part before the @ only From: Home:full@email.com (Note: TEXT COLON full@email.com -- both halves of this field MUST BE populated) Use TLS: Checked Port: 587 Password: YOUR PASSWORD Timeout: long, I use 3000 on a 994, there are reports it needs to be longer like 10,000 on Polisy. Don't Fill out the FROM line in customization, leave it fully blank, not even a space.

If these programs are about turning keypad buttons on an off, just include them in scenes. You don't need programs for this. Insteon has what I call "sloppy" scene's. You can create scene's that are separate and include those devices and buttons in other scene's. For example I have two buttons at the front door that are scene controllers for the top and bottom of the front porch outlets. Those outlets, and the buttons are also included in other scenes, one in the general outdoor lighting scene that has many members, and the other outlet and its button appears in the "holiday" scene.

@bjs169 I'd rewrite the first program like 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 Wait 3 seconds Run Program 'Downstairs Some On' (THEN) Else - No Actions - (To add one, press 'Action') I suspect the Insteon buffer is getting trashed, because two programs are sending commands at once. The error log probably shows these collisions. Let the first "sunset program" get it's commands out, then trigger the second program. What's the purpose of the variable that is being set via the third program? That program seems like there are better ways to approach the issue? how is the variable used? I assume it's a state variable? i See you already answered that let me study that a minute...

Did you install Java version 8 from https://www.java.com or some other version? The official version 8 is supported, others versions may work but often require fiddling.