oberkc Posted December 24, 2024 Posted December 24, 2024 3 hours ago, Guy Lavoie said: Not to hijack the thread, but are you talking about the Insteon garage door kit that has an i/o linc? Just reply yes or no. If yes, it might be worth starting a separate thread on it. Thanks. yes Quote
IndyMike Posted December 24, 2024 Posted December 24, 2024 So, rather than telling @CoolToys why what he was seeing couldn't happen, I tried some "stress testing: Constructed a program with 29 devices and the same wait sequence he used. Used a Set variable = 1 at the beginning and set variable = 0 at the end (to test if the program completed). Triggered the program with a 2477D switchlinc using a control "switched off". Seven (7) of the devices were plug-in's (lamplincs, ApplianceLincs, IOLincs) powered on a strip. These were for inducing communication failures Bottom line - the program ALWAYS finished. My variable was always set to 0 at the end. There were a crazy number of "other" programs being triggered as I went through the sequence. None of this stopped the test program from completing. Turning off the strip of 7 devices caused PLM retries and ISY Retries. Again - the program finished. There was 1 very interesting development during the testing - The following would show up at in response to some commands to the PLM. The 1st line is the command from the ISY to the PLM. The 2nd line is the PLM acknowledging the command. The 3rd line is very strange. The PLM is sending a 2nd ACK back to the ISY. I have never seen this before, nor can I find any reference to it on the forum. Has anyone ever seen this message? Seems like the PLM is getting confused or out of synch with the ISY. Tue 12/24/2024 08:44:50 AM : [INST-ACK ] 02 62 18.93.83 0F 13 00 06 LTOFFRR(00) Tue 12/24/2024 08:44:51 AM : [INST-ACK ] 02 62 54.A5.19 0F 13 00 06 LTOFFRR(00) Tue 12/24/2024 08:44:51 AM : [INST-ACK ] 02 62 54.A5.19 0F 13 00 06 LTOFFRR(00): Duplicate or ACK for a different device Test Program - bold items are installed on power strip CoolToys - [ID 0068][Parent 0067] If 'Basement / BSMT Fam Cans' is switched Off Then $FirstDining.On = 1 Set 'Basement / BSMT Back Room' Off Set 'Basement / BSMT Back Room Load' Off Wait 5 seconds Set 'Basement / BSMT Fam Cans' Off Set 'Basement / BSMT Fam Rm Sconce' Off Set 'Basement / BSMT Game KPL Overhead A' Fast Off Wait 5 seconds Set 'Basement / BSMT Game Sconce' Off Set 'Basement / BSMT KPL Game' Fast Off Wait 4 seconds Set 'Basement / BSMT Kitchen Cans' Off Wait 4 seconds Set 'Basement / BSMT Kitchen Ceiling' Off Set 'Basement / BSMT Stair' Off Wait 5 seconds Set 'Basement / BSMT Stair 2' Off Set 'Basement / BSMT Storage' Off Set 'Basement / BSMT Video Cans' Off Set 'Basement / Basement Bed' Off Wait 5 seconds Set 'Basement / Furnace Room' Off Set 'Basement / Test LampLinc' Off Set 'Basement / Test Matthew Lamp' Off Wait 5 seconds Set '13.32.8B-Sensor / 13.32.8B-Relay' Off Wait 5 seconds Set 'Basement / Test-Sensor / Test-Relay' Off Set 'Basement / Test 13.07.33.1' Off Wait 5 seconds Set 'Basement / Test 13.05.A8.1' Off Wait 4 seconds Set '0F.82.A9.1' Off Set 'Basement / BSMT Back Room' On Wait 5 seconds Set 'Basement / BSMT Back Room Load' On Set 'Basement / BSMT Fam Cans' On Set 'Basement / BSMT Bed' On Wait 4 seconds Set 'Basement / BSMT Fam Rm Sconce' On Set 'Basement / BSMT Game KPL Overhead A' On Set 'Basement / BSMT Game Sconce' On Wait 4 seconds Set 'Basement / BSMT KPL Game' On $FirstDining.On = 0 Else - No Actions - (To add one, press 'Action') Quote
Guy Lavoie Posted December 24, 2024 Posted December 24, 2024 (edited) Interesting, a few days ago I also created a test program (but simpler than yours) to test that a series of waits would always complete, as part of trying to understand this problem. I created 9 integer variables, and a program like yours that incremented one variable, sent a few Insteon commands (turning off basement lights), wait a few seconds, then increment the next variable, etc, all the way to the end. Then I had a second program trigger it every few minutes. My thinking was that if the program ended before all the waits had executed, then some of the later integer increments would be missing. I let it run overnight. The next day, all the integers had incremented to the same value, about 550. None were missing. Both our tests seem to indicate that the problem is elsewhere. Having motion sensors in the mix can certainly be a factor. I suggest that CoolToys try to simplify it down to something more linear (without anything that might cause random triggers, like motion sensors) and/or break it up into several programs that would make it easier to troubleshoot. Edited December 24, 2024 by Guy Lavoie Quote
CoolToys Posted December 24, 2024 Author Posted December 24, 2024 (edited) @IndyMike, Happy Holidays and thank you for doing the test, it reminded me to double check my final variable to see if the program was finishing. I will watch the PLM to eISY comm more closely after the family leaves. I have been overlooking this. I do know that the eISY is different that the ISY, and it is why I may go back and give up on adding blinds for now. Last night the final variable triggered so the program did "finish" however four lights stayed on this time. Which led me to comm, especially since using mostly scenes in the program to shut down. Going back, way back in the thread there was a note about scenes not transferring perfectly from the ISY, there was someone who suggested I start over from scratch on the eISY and I may do that. Last night I went through the four scenes that didn't work properly, and found this interesting tidbit which was and is true of all four scenes. Two of these were new last night BTW. Pressing the button next to the bed which was the Controller, turned the lights on and off perfectly. These are three way set ups with one master and either two slave switches or two slave buttons on keypads or a mix of Master Switch, Slave Switch and Slave Keypad button. Sending the command from UDI mobile or the AC did not work. The AC would indicate 60%, On, On and both slaves responded but the master did not. So the two slaves LED lit up as if they were on, and the lights didn't come on. Pressing the master also lit up the slaves. The previous day UDI mobile worked perfectly. Per the recommendation of the post about transferred scenes not holding the keys, I deleted and rebuilt each of the 6 scenes that have randomly failed over the last three days. One of the scenes, did not finish writing, so I selected write changes to device and still the same issue. Now... Either slave button or the master turns the lights on and off and correctly sets the scene. The AC shows "65%,On,On" Turning on the Scene with AC, the devices show "Off, On, On", AC shows "65%,On,On". Turning on Master Switch with AC, the master sets to 65%, keypads remain off, AC indicates "65%,Off,Off" I don't recall this ever being the case with the ISY. Why doesn't the AC triggering the switch trigger the scene when a physical switch press does? For a comm test, I set a button on the other side of the house as a controller and it also turned the scene on and off just fine. Since that last reboot, no lights have randomly come back on which is interesting in itself. Today I am moving the PLM and eISY to another location to see if it is comm, but the scene failures don't indicate that. I am down to three thoughts today, 1. noise/comm issues (but the errors are way more consistent after rebuilding the 6 scenes), 2. Possible corrupt program because I didn't migrate correctly from my ISY. 3. eISY is different logic and I have to do a lot of homework to understand it. Post Edit - OOPS forgot to sync UDI mobile after rebuilding the scenes. UDI mobile now works as I expect, only AC that fails when I activate the scene Edited December 24, 2024 by CoolToys Quote
CoolToys Posted December 24, 2024 Author Posted December 24, 2024 @Guy Lavoie, I thought that way too, but I also used the model demo that @larryllix posted earlier here and if the state in the IF statement changes then the program stops. That appears to have been solved by making a simple program and Switched and Status both now work fine. Bedtime Trigger - [ID 001D][Parent 0001] If 'MB Window Keypad.On' Status is Off Or 'MB Door Keypad 70 9B C0All On' is switched Off Then $sBedtime = 1 Else - No Actions - (To add one, press 'Action') And then changing the IF of the Bedtime program to : BedTime - [ID 0016][Parent 0001] If $sBedtime is 1 The program now runs all the way through but not everything is working. The random relighting appears to have stopped the last few days and I have no explanation why. Quote
IndyMike Posted December 24, 2024 Posted December 24, 2024 Quote Either slave button or the master turns the lights on and off and correctly sets the scene. The AC shows "65%,On,On" Turning on the Scene with AC, the devices show "Off, On, On", AC shows "65%,On,On". Turning on Master Switch with AC, the master sets to 65%, keypads remain off, AC indicates "65%,Off,Off" I don't recall this ever being the case with the ISY. Why doesn't the AC triggering the switch trigger the scene when a physical switch press does? When you actuate a device, you are executing a scene. However, the device will (try to) interrogate each member of the scene to determine if it responded correctly. If a group member does not respond, the device will try again up to 3 times. If any device in the scene responds incorrectly, the initiating device (may) retry the command up to 3 times. If the scene still fails, the device (may) flash red. When there is high Insteon traffic, the device may abandon the group interrogation. The ISY does NOT do this. It sends the Group On command (scene) and does not interrogate the individual group members. It assumes the command was followed and reflects this status. LeeG's description (better than mine): https://forum.universal-devices.com/topic/11690-understanding-retries-in-isy/#findComment-109217 If you are concerned scenes not responding, you can run the "scene test" under "Tools/diagnostics/Scene Test". This is a special test that runs the scene ON followed by an OFF followed by a group cleanup on each device. It's actually not an easy test to pass. 1 Quote
Guy Lavoie Posted December 24, 2024 Posted December 24, 2024 2 hours ago, IndyMike said: The ISY does NOT do this. It sends the Group On command (scene) and does not interrogate the individual group members. It assumes the command was followed and reflects this status. That's good to know. I would have thought that the PLM would have done that, not the ISY. That way, a failed scene command could have been reported back to the ISY as a communication error with a device. 1 Quote
CoolToys Posted December 26, 2024 Author Posted December 26, 2024 @Guy Lavoie and @IndyMike I was thinking both would at least verify later? Good to know the scene is just a command sent to the ether with no expected response. STATUS UPDATE After having rebuilt the 6 scenes, nothing changed. So using some cache flushing logic I rebooted the eISY. The interesting thing is that when I rebooted the house started just running random things and the kitchen auto lights stopped working. The scenes all worked fine from the AC though. So once again I started at the top. I found two very odd things. The line for the Kitchen auto lights reversed and instead of IF Dining.Motion = "on" the program had IF Dining.Motion= "off". Second was an "and" swapped to an "or" in another program so the lights were just constantly turning off and on. Those corrected about 10 pm, the house appeared stable so I called it a night. The MB.Door all off button did nothing for the Bedtime program. The program didn't even start. My wife was sleeping so I didn't test her side. Using the "Run Then" Bedtime button on UDI mobile, the Bedtime program worked perfectly. The keypad that didn't work is the newest dual mode 6 button in the house, but possible bad or comm from that outlet. X-10 is not received from that outlet but I hoped a dual mode keypad would work. Going to swap keypads tonight and keep trying. 1 Quote
CoolToys Posted December 27, 2024 Author Posted December 27, 2024 12/27 update. After the full reboot ( not just "restart IOX") and resetting the errors found, the system worked as expected no weird light things except that neither keypad ran the bedtime program. All scenes and automations worked as they should. I used the trigger program that if either is switched off the $sBedime = "1". The variable changed and the bedtime program never ran. Pressing the Bedtime button on UDI mobile forcing a "run then" of the Bedtime program worked perfectly. Ugh. Quote
Guy Lavoie Posted December 27, 2024 Posted December 27, 2024 1 hour ago, CoolToys said: I used the trigger program that if either is switched off the $sBedime = "1". The variable changed and the bedtime program never ran. Well that should be easy to troubleshoot, if it's repeatable. One thing: In both the program(s) that sets the variable, and the program that looks for it being set to 1: edit the program, select the variable again from the list (as if you were selecting another variable), click on update to save the line, and save the program. I've seen odd stuff happen with variable references looking right but not working. It could be an admin console thing. 1 Quote
CoolToys Posted December 27, 2024 Author Posted December 27, 2024 (edited) @Guy Lavoie, Thank you, I wasn't aware of variable reference issues. I use them extensively and this is the only goofy one. I killed and rewrote the entire Bedtime program just in case it was an issue with the program itself. I am not 100% clear on which program to try this on so I went to the Bedtime program, selected the $sBedtime line in the if Statement, clicked update and then Save Changes. If that is what you meant, I will try again tonight. Quick Edit, I had some time so I tried it during the day and it appears to run.. I will double check tonight. Might have just discombobulated the whole house though. Edited December 27, 2024 by CoolToys Got impatient, tested daytime 1 Quote
Guy Lavoie Posted December 27, 2024 Posted December 27, 2024 31 minutes ago, CoolToys said: @Guy Lavoie, I am not 100% clear on which program to try this on so I went to the Bedtime program, selected the $sBedtime line in the if Statement, clicked update and then Save Changes. If that is what you meant, I will try again tonight. I will double check tonight. Might have just discombobulated the whole house though. Yes, that's the idea: to redo the variable reference. I still have your mention in the back of my mind that this worked fine on the ISY but not on the eisy. This problem potentially popped up between the two. I'm looking forward to hearing how it goes this evening. 1 1 Quote
IndyMike Posted December 27, 2024 Posted December 27, 2024 2 hours ago, CoolToys said: @Guy Lavoie, Thank you, I wasn't aware of variable reference issues. I use them extensively and this is the only goofy one. I killed and rewrote the entire Bedtime program just in case it was an issue with the program itself. I am not 100% clear on which program to try this on so I went to the Bedtime program, selected the $sBedtime line in the if Statement, clicked update and then Save Changes. If that is what you meant, I will try again tonight. Quick Edit, I had some time so I tried it during the day and it appears to run.. I will double check tonight. Might have just discombobulated the whole house though. @CoolToys, I'm glad to hear that you re-wrote the entire program. I am starting to think along the same lines as @Guy Lavoie, that this is at least partly due to a ISY994/Eisy transfer. I was playing with my test program for awhile today. After numerous edits, I found a situation where the program was calling the incorrect scenes and executing things in the incorrect order. I exported the program to XML and could see that it was incorrect, but the "text" version was correct. Saving the program, copying and saving, etc. did not correct the issue. I had to go line by line, change the "text", update, save and then re-change to correct things. Quite the process - rewriting would have been easier. If your programs didn't transfer properly, it would be very difficult to correct them given the complexity. They look correct visually, but execute very differently. I am still playing with the "Duplicate or ACK for a different device" error from the PLM. I can turn it on/off now based on devices communication failures and wait times. Still not sure whether it's a problem - can't imagine that it's a good thing. One interesting thing that I did put in the program was an integer variable that I increment after each "Wait". It's far easier to track the program progress in the event viewer with the variable incrementing. CoolToys Copy - [ID 006B][Parent 0067] If '19.21.5C.1' is switched Off Then $FirstDining.On = 1 Wait 5 seconds Set 'Basement / SC BSMT' Fast On Wait 5 seconds $FirstDining.On = 2 Set 'Basement / BSMT Back Room' Off Set 'Basement / BSMT Back Room Load' Off Wait 5 seconds $FirstDining.On = 3 Set 'Basement / BSMT Fam Cans' Off Set 'Basement / BSMT Fam Rm Sconce' Off Set 'Basement / BSMT Game KPL Overhead A' Fast Off Wait 5 seconds $FirstDining.On = 4 Set 'Basement / BSMT Game Sconce' Off Set 'Basement / BSMT KPL Game' Fast Off Wait 5 seconds $FirstDining.On = 5 Set 'Basement / BSMT Kitchen Cans' Off Wait 5 seconds $FirstDining.On = 6 Set 'Basement / BSMT Kitchen Ceiling' Off Set 'Basement / BSMT Stair' Off Wait 5 seconds $FirstDining.On = 7 Set 'Basement / BSMT Stair 2' Off Set 'Basement / BSMT Storage' Off Set 'Basement / BSMT Video Cans' Off Set 'Basement / Basement Bed' Off Wait 5 seconds $FirstDining.On = 8 Set 'Basement / Furnace Room' Off Set 'Basement / Test LampLinc' Off Set 'Basement / Test Matthew Lamp' Off Wait 5 seconds $FirstDining.On = 9 Set '13.32.8B-Sensor / 13.32.8B-Relay' Off Wait 5 seconds $FirstDining.On = 10 Set 'Basement / Test-Sensor / Test-Relay' Off Set 'Basement / Test 13.07.33.1' Off Wait 5 seconds $FirstDining.On = 11 Set 'Basement / Test 13.05.A8.1' Off Wait 5 seconds $FirstDining.On = 12 Set '0F.82.A9.1' Off Set 'Basement / BSMT Back Room' On Wait 5 seconds $FirstDining.On = 13 Set 'Basement / BSMT Back Room Load' On Set 'Basement / BSMT Fam Cans' On Set 'Basement / BSMT Bed' On Wait 5 seconds $FirstDining.On = 14 Set 'Basement / BSMT Fam Rm Sconce' On Set 'Basement / BSMT Game KPL Overhead A' On Set 'Basement / BSMT Game Sconce' On Wait 5 seconds $FirstDining.On = 15 Set 'Basement / BSMT KPL Game' On Wait 5 seconds $FirstDining.On = 16 Set 'Basement / SC BSMT' Fast Off Wait 5 seconds $FirstDining.On = 17 Set 'Basement / SC BSMT Entry' On Else - No Actions - (To add one, press 'Action') 1 Quote
CoolToys Posted December 28, 2024 Author Posted December 28, 2024 @IndyMike, The integer update for each wait is a great idea. Last night there might have been a breakthrough. I have been moving blocks of programs that work correctly into folders with similar programs like 3-Way switches etc. Last night I watched the Bedtime Run perfectly but about 90% of the way through I saw "Night Daily Home" turn green. I looked at the summary tab and saw that both Bedtime and Night Daily Home were true and running. I checked the variables and they were correct so "Night Daily Home" should have been false. The IF statement is. Night Daily Home - [ID 0003][Parent 0001] If $sOccupied_Main is 1 And $sNight is 1 And $sBedtime is 0 Going back through my logs, before creating the Bedtime Trigger and using $sBedtime = 1 as the IF for Bedtime, I didn't set $sBedtime = 0 until the end of the Bedtime program. This would have let Night Daily Home start, and if it wasn't running in order, create a randomness. By the time I checked it, Bedtime was finished running and so Night Daily Home would be red. Following @Guy Lavoie 's earlier idea, I reset all of the variables in the Night Daily Home IF just in case one of those didn't transfer. This is a very plausible explanation of the randomness given @IndyMike's experiment. Moving from a slower (possibly linear action model) ISY to a faster eISY, with a couple of variables that didn't transfer it may be that the Daily Night Home was starting to run, and when Bedtime hit the last line of $sBedtime=1 it stopped giving a random appearance. Because I shrank the program list length I could see it all on one screen last night. I should have caught it while looking at the programs "last ran" column but I was clearly a bit myopic only focusing on what I could see running and the top two which are what I expected. Once the reset of the variables was done, I manually changed $sBedtime back to 0 and the house lit up. Five minutes later I pressed the Off on the keypad and the house shut down normally. I am leaving for the next 10 days but will test again when I return. Hoping to find this solved. Thank you all and Happy Holidays. Quote
CoolToys Posted 23 hours ago Author Posted 23 hours ago @IndyMike and @Guy Lavoie, thank you for your help, I am happy to report since returning home there have been three successful nights in a row where all programs and all but one scene are working perfectly. The Variables not transferring and scene's not transferring correctly is odd, but those two things solved a lot of problems. As a side note, a couple of the new i3 outlets still require an off command wait 2 seconds and another off command to keep them off even though I manually turned off the load sensing feature per a suggestion from @SteveL in another thread. I have three of them now, one works perfectly with a 8W LED, the others have 6W which should be enough but isn't. The last scene has been rebuilt three times. There is a button by the bed labeled "bed" which is in a scene with some over cabinet spot lights in our bedroom. The very last step of the new version of the bedtime program is to turn the MB Cabinet scene off. The lights go out but both .2 buttons on the 8 button keypads remain lit. Before I rebuilt the scene the opposite was true, the buttons would indicate off and the lights remained on still working on it, but your help got me on the path to getting the wife approved solution working. Thank you again and happy new year 2 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.