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 January 8 Author Posted January 8 @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
CoolToys Posted January 12 Author Posted January 12 Jan 12 2025 update. The bedtime random relighting of the house is over (Thank you again @Guy Lavoie and @IndyMike) but because I am now paying ultra close attention to the system, I have realized a few other random things that I knew about but were much lower priority. Remaining "random" items from migration to eisy: One i3 outlet that needs a double tap command ("off", wait 2 seconds, "off") to stay off even after being set to load sense off. This is true if the off is sent from the program or a "controller" switch. There were two. I removed them both from the system, manually set load sensing to off, re-started IoX and added them back. One is now working correctly with a 6w bulb, the other is not. Both had 3w before Steve Lee clued me in that 3w is too small of a load. (Admittedly both of these outlets were non i3 with the ISY, when I upgraded and they started doing the auto on thing, I thought they failed and replaced with i3.) Two scenes that don't work. One is a 3 way with a master and slave switch, one is a 4 way with a master and two slaves. In both cases the slaves don't follow the master. There are 9 such scenes, the others all work. I removed and rebuilt all nine scenes since most were not working correctly after the migration. Finally the motion activated scenes have been failing randomly. I do know why but just started testing a patch. I discovered this a few days ago when walking in the garage. There is an Insteon Motion II (was a motion I with ISY but I thought it failed) it blinks green but the big lights didn't come on, a review of the AC indicated the garage lights were already on. The switch indicated off. I selected "query" which synced the garage to "off". When I went back in the garage the lights worked normally. The same has happened a couple of times with each of the other motion areas. There is a daily query at 3:15 am, and in the past I chalked this up to motion sensors not picking us up because the scenes worked "later". I went so far as to buy an aeotech motion sensor thinking it might help. Now that I am checking every event failure every time, the cause was simple. The eisy and the insteon system are occasionally getting out of sync. When that happens the motion activated programs fail. Over night the system syncs and the next day the scene works. All of these events activate a scene, and I am wondering that since the "scene" command is sent without requiring a response if some noise in my lines is preventing the command from being received and the eisy is assuming a switch position? As silly as this sounds, to experiment, I just added a "wait 2 seconds" and "{device_name}, query" to half of the programs and an "beep" on the switch to the others to see if this is a possible band-aid until I figure out my random noise generator. Quote
IndyMike Posted January 12 Posted January 12 Quote Two scenes that don't work. One is a 3 way with a master and slave switch, one is a 4 way with a master and two slaves. In both cases the slaves don't follow the master. There are 9 such scenes, the others all work. I removed and rebuilt all nine scenes since most were not working correctly after the migration. Are these scenes locally activated (device) or activated from the ISY? Very different scenarios. Device activated scenes will attempt to determine the status of the responders. The ISY will not. 1 Quote
Guy Lavoie Posted January 12 Posted January 12 39 minutes ago, CoolToys said: Jan 12 2025 update. Finally the motion activated scenes have been failing randomly. I do know why but just started testing a patch. I discovered this a few days ago when walking in the garage. There is an Insteon Motion II (was a motion I with ISY but I thought it failed) it blinks green but the big lights didn't come on, a review of the AC indicated the garage lights were already on. The switch indicated off. I selected "query" which synced the garage to "off". When I went back in the garage the lights worked normally. This sounds similar to the problem I had with the i/o linc status being incorrect for my garage door. The sensor status indicated the door was closed, even after opening it. And a query would update it. A discussion of this in another thread brought up the fact that the i/o linc is powerline only (not dual band), and that the electrical noise of the opener motor might be inhibiting the status update that the module is sending out right after the door starts opening. As a workaround I tried adding a couple of query statements, sent a few seconds after the door is fully open and the motor stops (I timed the door opening and added a few extra seconds). It seems to have helped. I also added a lamplinc in the garage, as a signal booster and converter to rf signal as well. Interesting that we're both talking about a garage. These tend to be farther away and isolated (physically and electrically) from the rest of our living spaces, which might make any signal issues more relevant. If you have a spare lamplinc on hand, you might give that a try. Also, how is your motion sensor configured? Does it send both on and off commands, and what is the on time? On the ones I use, I have the time set to the minimum 30 seconds, and sending on/off commands. 1 Quote
CoolToys Posted January 12 Author Posted January 12 (edited) @IndyMike, You are correct, the scenes fail when commanded by the eisy. I tried using the eisy to turn on the master switch and the slave (controller/responders) still don't follow. When i manually turn on the switch the slaves follow. @Guy Lavoie, I had that same issue before the remodel, and wired the new garage to the ELK and solved that issue with the ISY and now with the eisy and ELK poly (when I paid the bill that is). I never considered the motor noise and timing, makes perfect sense now. There are four different motion sensors in the house, each activates one of four different scenes, sets occupancy states of two zones for HVAC and change the lighting configuration of the house at night automatically if there are guests or zone 2 is in use. All four scenes have occasional failures. The garage and stairwell are close to the switches so I made them beep. The other two are semi remote so I added the query to see what happens. We'll see. Some electrical side notes, - Every breaker circuit has at least one dual band device on it. - A dual band i/o linc is at the farthest point from the sub panel, in an "A" phase outlet with a "B" phase dual band switch right above it. I learned that trick as soon as dual band hit the market. - A dual band i/o linc is also in the garage on the "B" Phase just a few feet from an "A" phase switch on the main panel circuits. - Main Panel has a leviton filter on it with a SolarEdge Inverter attached. The two sub panels do not. - Batteries are being considered to clean up the power even more and minimize power failure recovery issues. Edit add - and I only use the "on" command from motion and then query the off. Auto Garage Lights - [ID 0012][Parent 0001] If 'Garage Lights' Status is Off And ( 'Garage.1 Motion' Status is On Or 'ELK Alarm / Garage Courtyard' Logical Status is Violated Or 'ELK Alarm / Garage Big' Logical Status is Violated ) Then $sGarage = 1 Set 'Garage Lights' On Wait 2 seconds Set 'Garage Lights' Query Else - No Actions - (To add one, press 'Action') Auto Garage Off - [ID 0029][Parent 0001] If $sGarage is 1 And 'Garage.1 Motion' Status is Off And 'ELK Alarm / Garage Big' Logical Status is Normal And 'ELK Alarm / Garage Courtyard' Logical Status is Normal Then Wait 15 minutes $sGarage = 0 Set 'Garage Lights' Off Else - No Actions - (To add one, press 'Action') Edited January 12 by CoolToys Forgot to answer how I use motion Quote
IndyMike Posted January 12 Posted January 12 Quote @IndyMike, You are correct, the scenes fail when commanded by the eisy. I tried using the eisy to turn on the master switch and the slave (controller/responders) still don't follow. When i manually turn on the switch the slaves follow. I'm thinking you may have mis-stated things here. You can't activate a scene by turning one a Controller from the Admin Console. That will activate the controller by itself. You have to activate the "Scene" from the admin console tree (or a program). If this was the case, we need to start looking for noise/signal absorbers on the responder circuits. Quote
CoolToys Posted January 12 Author Posted January 12 @IndyMike, no that wasn't a mis-statement, I did it as a test to see how Insteon, and UDI play. I wanted to fully understand the logic. Insteon devices defined as a controller have two modes, controller and responder. When pressed directly (with my finger) the device responds as a controller. When I press a scene button on another Insteon device, i.e. keypad 8, the device then acts as a responder. I had assumed (hoped?) that Insteon had two different commands so the ISY sending a scene command could also be treated differently than a direct command by the Insteon device. My apologies for venting in the thread that it doesn't work as I wanted. Quote
CoolToys Posted Wednesday at 05:24 PM Author Posted Wednesday at 05:24 PM Thank you to everyone listed here that helped. I think the admins can close this thread and here are the highlights to save anyone else a lot of reading. Given the time spent it might have been easier to just wipe the Eisy clean and build everything from scratch as was suggested early on however my pea brain may have left the logic error of "the big one" in the new code too. The program in question now works correctly and consistently. The only two open issues with my system are the scenes not working reliably (see Step 7 and request at the end) and blinds not added (Matter 2025?), neither of which are part of this thread. Every Step listed led to improvements which helped me find the big one. Without all of the help, I would have never seen the real issue. The length of the list shows why I think I should have just started over from scratch when I moved to the Eisy. The system worked with my ISY, but the Eisy has way more brainpower so it was faster than my linear thinking and programs built for an HAI Omni Pro. Step 1. Batteries low in Insteon Motion I sensor, changed states randomly due to "false motion" - @IndyMike Step 2. Move variable reference to the end of a program if same variable used in the program @dbwarner5 Step 3. Improved Variable naming for better tracking $sVariable for State, $iVariable for integer @larryllix Step 4. Rewrite Problem Program if system otherwise working normally @dbwarner5 Step 5. Disable the program, Click and select each line, save program, enable program. This action Re-syncs Tokens @larryllix Step 6. Find and Fix "Broken Variables". Look at every program for a [Variable_undefined] or similar entry - @IndyMike Step Seven. Be aware a scene command sent by the Eisy via PLM to Insteon is not verified, but assumed so Admin Console and device status may disagree. - @oberkc Step 7. Add a 2 second wait between commands in a program to prevent communications collisions. Keep in mind each "wait" verifies the "IF" is still true. @paulbates I added 4 seconds after scenes which helped but due to 7 above, still some issues. Step 8. The Big One, Two conflicting programs were true for a short period of time. As "Bedtime" started turning off the lights Night_Daily_Home saw the lights off but the "$sBedTime" Variable still = "0" so it started running again turning on lights since the state had not changed. When the Bedtime program finished, the $sBedTime became "1" and the Night_Daily_Home program stopped. Where the conflicting program stopped was slightly different each time hence the "randomness" I was seeing. This did not happen with the isy. Eisy runs faster? I think states are checked every minute so the Bedtime program needed the $sBedTime = "1" command moved to the first line. @oberkc Step 9. Run the Scene Test from the Eisy. Click on the Scene, right click (control click on mac), diagnostics, scene test. @IndyMike Side note on this one. Nothing appears to happen for any scene so maybe all of mine fail? Step 10. Similar to step five, click on each variable that isn't changing when program runs and resave program @Guy Lavoie Step 11. i3 outlets that turn off and back on due to possible load sensing on low wattage devices require a double tap even after the scene they are in is commanded off, (Meaning in the program: Hallway_Curio_Scene "off", Curio_Light "off", wait 2 seconds, Curio_Light "off") .@SteveL The program in question (Bedtime) that started this thread now appears to be reliable. The only known issue remaining is scenes not staying synced. i.e. the device turns off but the associated keypads stay lit as if the master device was on. This is a scene/communications problem since ISY doesn't verify. I would also like my blinds on the system but that is for another day. Request to @Michel Kohanim and Company - Please query scenes as insteon devices do or add a "retry" to the devices list in the scene command so we can beat them into submission. 2 Quote
Guy Lavoie Posted Wednesday at 07:48 PM Posted Wednesday at 07:48 PM 2 hours ago, CoolToys said: The only known issue remaining is scenes not staying synced. i.e. the device turns off but the associated keypads stay lit as if the master device was on. This is a scene/communications problem since ISY doesn't verify. 1- Please don't close the thread. I think there are still a few things worth discussing, and reliability testing over time. Wow, how long did it take you to write that post? You say that it would have been easier to just start from scratch, but I would argue that everything learned along the way was more valuable, and not just for you... About that quote I just made above: what type of keypads are these? If there is a way to turn off the light on the button by sending a off command to it, then I do have a workaround that is able to track scenes nicely. I have keypadlincs that I do that with. 1 Quote
CoolToys Posted Wednesday at 08:26 PM Author Posted Wednesday at 08:26 PM (edited) @Guy Lavoie There are several scenes that don't sync, this morning it was the temperature scene but the one in question is a 4 set up with. 2476D Switchlinc Dimmer W Beeper 4.0 - The live load KeypadLinc Dimmer 5 Button V.43 Button 2 KeypadLinc Dimmer 5 Button V.45 Button 2 When the scene for all of these turns off, the 2476D turns off the other two remain "on" If I press any of the three buttons, they work as they should. Scene command from Insteon ok, ISY not so ok. I am guessing due to the lack of verification by ISY? Edited Wednesday at 08:27 PM by CoolToys add response person 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.