Jump to content

CoolToys

Members
  • Posts

    205
  • Joined

  • Last visited

Profile Information

  • Location
    Huntington Beach CA
  • Occupation
    Pilot - Actor

Recent Profile Visitors

1360 profile views

CoolToys's Achievements

Advanced

Advanced (5/6)

28

Reputation

3

Community Answers

  1. @gdavis is correct, since Harmony was designed to work with any system they were programmed to allow for Phillips toggle codes. This was Phillips solution to discrete codes, saving a separate Power On and Power Off button on the remote among other things. Wherever the database came from for the IR codes could be the issue. The second button press could be blank or some code unknown to the ISY/Eisy. I have a Request Video Server and had similar issues. Harmony only programmed the "A" codes, leaving the "B" codes blank, which would do odd things if there were codes on the "B" pages. The off command for my TV was hiding under the FF command for the request. So instead of stopping the FF operation it turned off the screen with the second press. Manually programming (learning) the button twice from the Request remote solved it. 99% of the time Harmony just pasted the A codes in the B page unless the device had discrete A/B Phillips style codes.
  2. This might sound silly, but the region is set to NA? Does it need to have US set? The "Connected to Tesla Cloud" reading Disconnected is where I would start. That looks like the node server isn't logged into Tesla to get the data from your car. the "Controller Connected" displaying "Connected" might only be the node server to your AC?
  3. @Gamarando, when you restored the back up from the ISY your devices didn't appear? @jkmcfadden is correct, that going slowly using the migration guide will make life much easier, however we did discover that some variables and scenes don't transfer properly and can lead to erratic behavior. Fortunately the fix is simple. Any scene not working reliably, just delete and rebuild. Small hassle but it helps troubleshooting any other minor quirks. I have what I think is a pretty large system and the speed and logic change of the Eisy created a few issues that took a lot of troubleshooting but now appear to all be fixed. I had a bug in my programming logic that never appeared with the ISY. The Eisy is so much faster that I was having all kinds of fun trying to find it. Until I rebuilt two variables and half a dozen scenes (all three way switche scenes BTW), I couldn't see or find the bug in my programming logic. If you get bored look at the Long Running Randomness Thread. The fix turned out to not quite be it, so if you experience similar problems look at the tests that @IndyMike came up with to help troubleshoot after the "solved" date.
  4. @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
  5. @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.
  6. @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.
  7. 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.
  8. @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.
  9. @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.
  10. @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
  11. @IndyMike, 1. Nope no repress until the program stops running then. But previous to this weeks testing with an open laptop and the Admin Console running, sometimes two or three presses 5 -7 min apart will do it. 2. The only reference to the bedtime program is the bedtime trigger, and I disabled that yesterday just to see and just did a "find" and only found the reference in the trigger program. 3. Log doesn't show a reboot for over two weeks, I did that manually to see if there was cached data somehow. Last night, Only used UDI mobile. I like it because it shows "Running then" on the screen . Everything shut down in order but two unrelated items were skipped. $sBedtime remained at "0". The program ran all the way through. The Admin Console showed one of the switches as off, the other on. I queried and the AC and both showed on I manually turned them off and went to bed. Possibly bad communication and since it was a scene off command, a lost command? But why does the AC display "off" when it isn't. Looking more like comm issues even though at least a dozen of the switches are dual mode mesh. The one that showed on is an outlet with a 6W LED lamp that does occasionally turn it self on. Steve Lee thinks it is because the wattage is so low the i3 outlet senses an on from an inline type switch and turns back on. I have tested this and the outlets do it. Tonight I have added a second off for that curio. He said I needed a larger bub so I went from 3W to 6W. There is a way to turn that off but like blinking while running, I haven't figured that out yet. And yes here are the two different IF statements I tried. BedTime - [ID 0016][Parent 0001] If 'MB Door Keypad 70 9B C0All On' Status is Off Or 'MB Window Keypad.On' Status is Off AND BedTime - [ID 0016][Parent 0001] If 'MB Door Keypad 70 9B C0All On' is switched Off Or 'MB Window Keypad.On' is switched Off There is no significant difference in the result but due to a test where "wait" re-evaluates the "IF" condition, I have elected to leave the Status is Off version in place. @oberkc, I don't have any nested programs, it is 90% a copy from my old HAI Omni ProII that has just grown as I added devices to this house. That thing got lost with nesting so I avoid the technique. When I review logs and the status in the AC it appears as if the entire program ran. I added the $sAtomic_Tracker Variable at the end and changed it to 1 last night. It is the last line in the program and it did switch to one. At sunset it reverts to "0". My best guess at this point is two things. First , there is noise in my house that causes faults, and second when running a program with a scene, when the command is sent, the AC assumes it worked. I have even tried swapping PLM from Serial to USB, I have one of each. No change in performance. The next big thing is to move the eISY out of the media closet and down to my office closer to the main panel. After that it is revert to ISY until I find something that will run my lights and blinds autonomously. Amazon and Apple Home both work, I just don't want to be dependent on the matrix.
  12. @IndyMike I am not disagreeing but something isn't working right. Since upgrading to the eISY in an attempt to get my Matter blinds on the system (different thread, they are not). @oberkc, that makes sense and in both cases the program should still (and has on rare occasion) worked. 1. Tried to only trigger the "Bedtime" program with BedTime - [ID 0016][Parent 0001] If 'MB Door Keypad 70 9B C0All On' Status is Off Or 'MB Window Keypad.On' Status is Off Result, Program starts and stops somewhere. 2. Tried to use the IF from above in a new Program Bedtime Trigger - [ID 001D][Parent 0001] If 'MB Door Keypad 70 9B C0All On' Status is Off Or 'MB Window Keypad.On' Status is Off Then $sBedtime = 1 and use only as the Bedtime program If BedTime - [ID 0016][Parent 0001] If $sBedtime is 1 3. Changed "Status" to "Switched" 4. Changed direct Insteon device status changes to scene changes to eliminate collisions. 5. Tried all of the above again with just one switch in the IF statement, just because. 6. Using Alexa skill I added "Time For Bed" command. This didn't work at all. 7. Used UDI Mobile and built a button. The first four of these ideas are somewhere in this thread and all had the same result. They all worked once, they all start the bedtime program and they all get partway through and occasionally lights even randomly come back on. None turned off the house twice in a row. Number 5 didn't change any outcomes significantly. Last night I went through this very methodically, using all four approaches and reseting the variables manually each time. I did this four times for each change with my laptop with me so I could see the $sBedtime variable change and hear the very first item, the watch winder click off so I know the Bedtime program was activated. None worked all the way through. While I was getting frustrated further since the program that once worked no longer works I found a thread about UDI mobile. So I created a button for the Bedtime scene, edited it so that the only visible option was "Run Then". This way when you press the button it can only "Run Then". Wife approved simple and it worked not once but twice in a row. At that point I was told it was good enough and to try again later. If in fact this works, the question is Why?. Bedtime doesn't trigger to "1" so the one thing that does revert as it should is the thermostat. Everything else works and yet the IF statement is false because $sBedtime is still "0".
  13. Quick Update - In one scene I used "Motion" from the first motion II sensor instead of "Activity" which is where motion was registered. One scene problem solved and possible one "random" light since "Motion" was always "On" for that option on that sensor. Doesn't explain why that light/scene wasn't always on but... I also realized that in my "Bedtime" program I used the option of "Switched" instead of "Status" IF MB Door Keypad is switched off Instead of IF MB Door Keypad Status is off. My guess is that "Switched off" is momentarily true, where "Status off" is true until "on". That would explain a lot. I have that in a lot of places and just made them all "Status" since I force the switched "on" when the lights come on at sunset and the only momentary command I use is the side gate lock release. To monitor this I have colored the buttons green and have the LED on so I know the status without logging into the UDI AC. Fingers crossed the next few days work.
  14. @paulbates, Thanks I will try and figure out how to turn the blink on traffic on. I don't see that in the UDI admin panel so it must be another way. Last week I tried changing the IF statement and having only IF $sBedtime=1 Then I created a program "Bedtime Trigger" IF $sOccupied =1 And (MB Keypad door is switched off or MB Keypad Window is switched off) THEN $sBedtime=1 When I pressed the button, $sBedtime went from "0" to "1" but the Bedtime program didn't run at all. Last night I took out the state variable $sOccupied and reverted to the buttons. So instead of IF $sOccupied=1 and (MB Keypad door is switched off or MD Keypad window is switched off) I used IF MB Keypad door is switched off or MB Keypad Window is switched off The bedtime program ran. But it ran before sometimes with $sOccupied = 1 in there. Today I have been going through the system with a fine tooth comb, comparing everything and I noticed I have three Insteon Motion II v.47 sensors but for some reason the UDI admin panel sees them differently. The First One Has: Activity (With the same boxes as the Motion option below) Motion (Always On) Tamper (blank) The Other Two Have Motion (on or off depending on activity) Motion.Enabled (blank) Tamper (blank) I also found several scenes where the light was off but the button was on. Since the button on the 6 buttons is a controller/responder I assumed the button would follow the light if the light was turned off somewhere. So as I followed some earlier advice of using scenes in the longer programs it appears where there is still a direct command to the light, the button is not "responding". I also added the Amazon command "time for bed" via the mobile app, to see what that does to the bedtime scene. It didn't work at all. Alexa said "Sleep Well" and that was it. I wish I could have an option to return the eISY to "linear" thinking so this "wait" thing wouldn't be the looming question. It shouldn't be, especially when i used triggers for variables, and yet those are the least consistent results. According to the UDI guide, ISY works on states and the $svariable=1 doesn't change so each wait should still read true, and the fact that the program has a green bar also indicates true and yet the program randomly stops or light come back on. I am thinking of relocating the eISY and PLM today to a position closer to the main panel as a test of noise/signal strength issues. I do have a dual mode switch in at least every other room. If Lutron/Control4/Crestron had the capability of the Insteon 6 button in a prosumer product so I didn't need a dealer or need to become one, I would switch today.
  15. @paulbates, New experiment, one "bedtime" all scenes, one all direct commands with 2 seconds in between. The button on my side of the bed started the scene version, my wife's side the other version. Similar issues, first three-five steps completed and it stops. Working from the thought process that the wait statement causes a re-evaluation of the "if" I went to the next experiment. The "off" button next to the bed would change sBedtime from 0 to 1. Then the "If" was changed to if sBedtime = 1. This time nothing happened. The variable changed to 1, so we know the command was received, but not one light went out. I then used UDI mobile to run the "Then" of the bedtime flows. This time the one will only direct commands worked, however 45 seconds later a light came back on downstairs. I then sent the "Then" for the version with scenes, and the light went out and a few minutes later a different light came back on. All the other state variables were 0 so no other lights should be triggered.
×
×
  • Create New...