Illusion

Oh Yes! I have done multiple factory resets. I have been working on this for 6 hours today. Been doing Insteon since the beginning. I have never seen anything like this. I am at a total loss.

Oh sorry! I meant to put that in the original post. I stopped all programs from running and it still happens. I did a compare links and all are a match.

Edited with new findings Background: I had a 6 button KPL (very old, first gen) fail the other day. I did lots of factory reseting and stuff and thought I had brought it back to life. But I would hit the top big on button and a few seconds later it would be off. Looking at the event viewer there was a fade down event after every time I hit the on button and the switch would fade itself off. Okay, never seen that before, but old switch. I yank that and put a new one in its place. Disregard above. After extensive testing, I have determined that that old KPL is just wonky. Weird flashing lights after reset. Refuses to respond to key presses now. This one I turn on and its indicator leds stay in the on position, but the ISY shows it as off instantly after I hit the button on. It shows it go on for a split second, then it shows status as off. (no load connected, just using as a controller). It was also turning off the load that is in the scene with the main button as the controller. After lots of reset and restore work, playing with the toggle/non toggle settings, and updating the scene control type of the responder, I finally got the load to stay on, but the status of the KPL shows as off in the ISY. Now I begin to wonder if something similar was going on with the one I pulled out. I grabbed an event viewer of me turning on the switch and there is too much there that I do not understand and I am hoping someone can look at that and offer a suggestion: This is what happens as a result of me pressing the top on button: Sun 02/13/2022 11:17:17 AM : [INST-SRX ] 02 50 56.CF.CE 00.00.01 CF 11 00 LTONRR (00) Sun 02/13/2022 11:17:18 AM : [Std-Group ] 56.CF.CE-->Group=1, Max Hops=3, Hops Left=3 Sun 02/13/2022 11:17:18 AM : [D2D EVENT ] Event [56 CF CE 1] [DON] [0] uom=0 prec=-1 Sun 02/13/2022 11:17:18 AM : [ 56 CF CE 1] DON 0 Sun 02/13/2022 11:17:18 AM : [D2D-CMP 01C5] CTL [56 CF CE 1] [DON] op=is --> true Sun 02/13/2022 11:17:18 AM : [D2D EVENT ] Event [56 CF CE 1] [ST] [255] uom=100 prec=0 Sun 02/13/2022 11:17:18 AM : [ 56 CF CE 1] ST 255 (uom=100 prec=0) Sun 02/13/2022 11:17:18 AM : [INST-SRX ] 02 50 56.CF.CE 00.01.01 CF 11 01 LTONRR (01) Sun 02/13/2022 11:17:18 AM : [Std-Group ] 56.CF.CE-->Group=1, Max Hops=3, Hops Left=3 Sun 02/13/2022 11:17:18 AM : [INST-SRX ] 02 50 56.CF.CE 51.12.25 40 11 01 LTONRR (01) Sun 02/13/2022 11:17:18 AM : [Std-Cleanup ] 56.CF.CE-->ISY/PLM Group=1, Max Hops=0, Hops Left=0 Sun 02/13/2022 11:17:18 AM : [INST-DUP ] Previous message ignored. Sun 02/13/2022 11:17:18 AM : [D2D EVENT ] Event [56 CF CE 1] [DON] [1] uom=0 prec=-1 Sun 02/13/2022 11:17:18 AM : [ 56 CF CE 1] DON 1 Sun 02/13/2022 11:17:18 AM : [D2D-CMP 01C5] CTL [56 CF CE 1] [DON] op=is --> true Sun 02/13/2022 11:17:18 AM : [D2D EVENT ] Event [56 CF CE 1] [ST] [1] uom=100 prec=0 Sun 02/13/2022 11:17:19 AM : [ 56 CF CE 1] ST 1 (uom=100 prec=0) Sun 02/13/2022 11:17:19 AM : [INST-SRX ] 02 50 56.CF.CE 11.01.01 CF 06 00 (00) Sun 02/13/2022 11:17:19 AM : [Std-Group ] 56.CF.CE-->11.01.01, Max Hops=3, Hops Left=3 Sun 02/13/2022 11:17:19 AM : [INST-INFO ] Previous message ignored. Sun 02/13/2022 11:17:19 AM : [INST-SRX ] 02 50 56.CF.CE 11.01.01 C3 06 00 (00) Sun 02/13/2022 11:17:19 AM : [Std-Group ] 56.CF.CE-->11.01.01, Max Hops=3, Hops Left=0 Sun 02/13/2022 11:17:19 AM : [INST-INFO ] Previous message ignored. There appears to be a second command from the switch in the event viewer from a single key press. Also, while the ISY shows the KPL main button as off, the switch LEDs are showing it is still on, and indeed if I query it the ISY will update the status to on. Another press on will again cause it to show off in the ISY status.

Please see: Just those two posts in that thread should answer your questions. 5m of reading or less.

@shannong I do not want to get into a flame war with you, but in my experience UDI staff respond to posts of all types in the forums more than any other company I have ever experienced. Nearly every other community/user forum I have ever participated in has almost no official responses to user posts. Often, it seems, these companies leave it up to volunteer moderators to be the de-facto face of their company on the community forums that they host. I agree that as UDI has gotten bigger, and a vastly greater portion of their income has moved to large contracts vs individual users, their employee engagement with the user forum that they maintain has decreased from the good old days. But this reality is contrasted by their greatly increased individual customer ticket support system. Even as they have gotten larger, their customer support, both on the forum and through their support ticket system, is unmatched by any other company that I have ever engaged with.

@shannong Please see this tread to answer you more detailed upgrade questions:

I am having trouble now updating my last 2440. I replaced a switch and needed to write updates to the 2440. I put new batteries in it and put it far away from the PLM (as I also have one of the PLMs that will not talk to it) and I cannot succeed in the write updates. I have done this a dozen times using this distant programming method without fail, but now I cannot make it work. This is the first time I have tried since moving to the 5.x branch and I wonder if it is related? Followup: After a painful factory reset of the 2440 and a full restore using the far away trick, I am back in operation. I guess the 2440 had a glitch that required a wipe to allow comms to resume.

I can confirm that I as well have never been able to get to my Polisy on an iOS device. Using Safari or Firefox both yield the Polisy page with the "not connected to server.." banner.

Fixed now. Maybe it was the browser cache?

Absolutely.

I updated from 5.1.0 to 5.3.0. But my polisy shows my ISY is still on 5.1.0. I restarted the polisy, but it still shows ISY at 5.1.0? ISY Shows running 5.3.0...

Is this supposed to say 5.0.10 or newer? The way I am reading it as written, everything before 5.0.10 is good for easy program and device migration, but not the most recent betas.

HI All, Three years away and jumping into a huge upgrade from 4.x to 5.1.0. I have been working on it for a couple of days now. Today while pounding away on cleaning up scenes, I noticed that my Memory LED on the ISY is busy busy busy. Then quiet, then super busy for long period of time. What I was doing at the time was cleaning up "retries" in scenes which were a mess. I opened up the event viewer to level 3 and saw stuff like this: Sun 08/23/2020 06:14:41 PM : [FileOpen ] Open failed for [/CONF/223.PRP] (r) Sun 08/23/2020 06:14:41 PM : [FileOpen ] Open failed for [/CONF/100.PRP] (r) Sun 08/23/2020 06:14:42 PM : [FileOpen ] Open failed for [/CONF/436.PRP] (r) Sun 08/23/2020 06:14:42 PM : [FileOpen ] Open failed for [/CONF/139.PRP] (r) Sun 08/23/2020 06:14:42 PM : [FileOpen ] Open failed for [/CONF/21.PRP] (r) And lots of it. I mean LOTS. Like 150 lines a minute. I left the event viewer open for about 25 minutes and had over 3500 of these entries. I am not sure if it related to what I was doing, some error I made in the upgrade, subsequent downgrade back to 4.x to get program enabled values, subsequent re-upgrade and micro SD card replacement in there. Or maybe it is a bug with 5.1.0. not sure, but there it is. I will keep an eye on the ISY and see if it settles down when I am not working on the system. But it was pretty much doing all day over the 10 hours I have been putting in today.

Hi All. Total success using the website IFTTT.com. I use Mobilinc with my iOS devices and I have the Mobilinc Connect service and the necessary module added to my ISY. Mobilinc recently announced that they have set up an IFTTT channel. While I did not really need a Roomba, I could not pass up this opportunity. Now that both Mobilinc and iRobot have IFTTT channels the path was clear. So now I have it such that my Roomba vacuums when I leave. If I get home before he is done, he stops and goes back to his base. I got the new i7 and was surprised to discover that this advanced Roomba requires a bit of light to function as it has a camera for location awareness. So in addition to starting, I have a low level lighting scene that comes on when the Roomba runs. And iRobot has a mission complete trigger on IFTTT so it is sorta two way communication. When the Roomba is done, he sends the trigger to the iRobot servers, which gets sent to IFTTT which triggers a Mobilinc IFTTT response to trigger a program in my ISY and the Roomba light scene gets shut off. It is working great.

I understand what you are saying, but that was not matching up with what I was experiencing in my system. So I got a wattage meter and a variable load. I set the trigger threshold to 30, and the hysteresis to 30. The synchrolinc turned on when the draw went up to 60W or above. Any draw below 30 once on triggered off. I then set the threshold to 30 and the hysteresis to 40. Under your belief, the syncrolinc would never send an off command once on. But it did. It turned on above 70W and then as I reduced the wattage it again sent an off command at 30W. Maybe my syncrolincs are different than yours. I thought they worked exactly like you are describing, and that would actually be better for me. If you have an idea how to change the mode they work in, I would be most interested. My TV draws wildly variable wattage. I was trying to tune the synchrolinc so that it would send an on command once the TV hit about 48 watts. My problem was that when I switch inputs, the wattage drop to about 35. I set the threshold at 45 watts and no matter what I set hystersis at, the synchrolinc would throw an off command when the wattage dropped below 45 watts. I figured that if I set a high hystersis like 30 or so, the synchrolinc would not send an off command until the wattage dropped to about 15, but alas that was futile. Regardless of the hystersis setting, the synchrolinc would send an off command when the wattage dropped below the trigger wattage of 45. I replaced that synchrolinc with a new one that had just been factory reset and it showed identical behavior. After about 150 tests with those two in system, I set up the controlled environment with a variable wattage load that I could control on a watt by watt basis at any time interval. After about 50 tests using different values with 100% repeatability I came to the conclusions that I posted.

Alright, I have been working on this for 4 hours today. Finally I got a variable wattage load and an unused synchrolinc. I have been working in a controlled environment to come up with this. Here is watt the values mean: (cute funny typo intentional!) Trigger Threshold is off wattage. Any wattage draw from the connected device at or below this level will cause an Off Insteon command. Holdoff is how long SynchroLinc will wait from last On/Off Insteon Command before sending another command. This prevents quick cycling. An on or off command is sent immediately if it has been longer than the holdoff since last command. If an on command has just been sent and the connected device immediately shuts back off, the Synchrolinc will wait the holdoff period before sending the off command. If the device turns back on in that window, and is still on when the holdoff expires, no command will be sent as the device is on and that was the last command sent. Hysteresis is added to trigger to create on level. When the device draws the Trigger Threshold wattage plus the Hysteresis wattage value the Synchrolic sends an on command.

Hugely helpful original post and responses. Thank you all. There is no way I could have gotten my iTach IP2IR working this quickly or well without this topic. Thanks so much to all and especially to GPC.

Elegant solution to the dual band KPL in a tabletop enclosure. Use longer screws and wrap the gap with trim.

Important update. I was a bit distraught about my findings in my latest testing. I very much want to minimize my power consumption of the batteries, and I only need 'night' triggering. However, all my MDs sense motion in areas that are then illuminated by the 'on' action of motion sense. Others may have discovered this, but here it is in any case: The timeout effect delays the switch to "day" but does not seem to delay the switch to "night" in the MD. This coupled with the always send occupancy option, which ignores timeout, solves all my issue. They really did a great thing on this version. With a timeout of .5m dark will be executed in about 3m and day will be executed about 4m after exposure to bright. But with a timeout of 5m set, dark will be executed about 3m after being in the dark, but day's execution will be after 25-30m. So I set the MD to only send motion after dark, occupancy mode, with a 5m timeout and now for about 30m I can move around the area and keep the lights on, while still getting the huge energy savings I found in testing.

Updated test results on new motion detector version. Tests done on REV 2.3 motion detector with ISY994i/IR Pro v4.0.5: 60µA on initial power up. No programing as this Motion Detector (MD) was already part of my system. This would be the same effect as a battery replacement. This was the condition created when I broke the circuit to put the amp meter in line. This new version did not fail to drop back into sleep mode. So that is a good bug fix. But after programming options the MD did stick in a 6.55mA state until I pressed the set button and saw the commands show up in the event viewer. Indeed the MD would not respond to motion during this time, similar to the REV 1.1 used in the first tests. However, eventually it would drop into sleep and respond to motion. This occurred after about 3-4 minutes in several test attempts. So maybe still a good Idea to see the MD send commands in response to the set button press before returning them to service. Only takes a couple of extra seconds. 32µA in sleep mode 12.03mA to Xmit a command Energy cost of allowing the led to flash: (all values exist only for the duration of time for the led flash) 500µA LED at 255 (Very bright) 170µA LED at 100 (Not so bright) Almost nothing at 1 (Very Very dim, but still visible in darkness) It appears that the LED is now off when set to 0. Another nice bug fix. MD set in always detect mode, LED disabled via software set at 0 LED brightness, Occupancy sensing mode: 33µA sleep mode 66µA pulses about every 25s while in sleep mode 12.1mA to Xmit motion sense 6.55mA standby mode for 1s after xmit motion. MD set in night only mode, LED disabled via software set at 0 LED brightness, Occupancy sensing mode: 32µA sleep mode 66µA pulses about every 25s while in sleep mode 50-150µA pulse on motion detect without Xmiting (day time) 12.1mA to Xmit 6.55mA standby mode for 1s after xmit motion. Once darkness befalls the detector set for night only operation the power draw is identical to the always detect mode. It jumps out of sleep to Xmit and then goes right back to sleep with that 1s at 6.55mA Real world test: Simulating a motion event during the "day". I created motion intermittently over the course of 30s during the "day" with the detector set to night only mode and always detect. LED at brightness of 100, Occupancy sensing so the sensor would send commands upon sensing motion irrespective of timeout, on-only mode, timeout is not relevant with these settings: Night only mode: Average power draw of 42µA over 1:30m Always Xmit mode: Average power draw of 1mA over 1:30m - 5 on Xmit occurred during the 30s of simulated motion. It took almost 24 times as much energy to send the unnecessary commands if you only wanted actions to occur after dark. Conclusion: The conclusion with this newer MD is exactly the opposite from the conclusion drawn on the REV 1.1 MD. It is way better from a battery life perspective to let the MD determine dark if you want something to only occur after dark than to send commands during the day and use the ISY to determine whether to execute an action or not based on other data (Sunrise/Sunset, Dusk/Dawn sensors, Weather Bug light Data, Time of Day... Etc...). And the other conclusion is that the newer version is much much more power conservative all across the board.

Yes. It works in 3.2.6

Backlights of my v2.D KPL do not dim in this version. Broke in 3.3.10. Still Broke. Event trace from failure to dim in 4.0.4: Wed 05/15/2013 01:47:03 PM : [All ] Writing 1 bytes to devices Wed 05/15/2013 01:47:03 PM : [F C1 DE 1 ] Memory : Write dbAddr=0x0264 [11] cmd1=0x2E cmd2=0x00 Wed 05/15/2013 01:47:03 PM : [iNST-TX-I1 ] 02 62 0F C1 DE 0F 2E 00 Wed 05/15/2013 01:47:03 PM : [iNST-ACK ] 02 62 0F.C1.DE 0F 2E 00 06 (00) Wed 05/15/2013 01:47:03 PM : [iNST-SRX ] 02 50 0F.C1.DE 13.24.AA 27 2E 00 (00) Wed 05/15/2013 01:47:03 PM : [std-Direct Ack] 0F.C1.DE-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Event trace from failure to dim in 3.3.10: Wed 05/15/2013 01:31:24 PM : [iNST-TX-I1 ] 02 62 0F C1 DE 0F 2E 00 Wed 05/15/2013 01:31:24 PM : [iNST-ACK ] 02 62 0F.C1.DE 0F 2E 00 06 (00) Wed 05/15/2013 01:31:24 PM : [iNST-SRX ] 02 50 0F.C1.DE 13.24.AA 2B 2E 00 (00) Wed 05/15/2013 01:31:24 PM : [std-Direct Ack] 0F.C1.DE-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Event Trace from Success in 3.2.6 after rolling back to that firmware version.: Wed 05/15/2013 02:39:20 PM : [All ] Writing 2 bytes to devices Wed 05/15/2013 02:39:20 PM : [F C1 DE 1 ] Memory : Write dbAddr=0x0264 [11] cmd1=0x2E cmd2=0x00 Wed 05/15/2013 02:39:20 PM : [iNST-TX-I1 ] 02 62 0F C1 DE 0F 28 02 Wed 05/15/2013 02:39:20 PM : [iNST-ACK ] 02 62 0F.C1.DE 0F 28 02 06 SET-MSB(02) Wed 05/15/2013 02:39:20 PM : [iNST-SRX ] 02 50 0F.C1.DE 13.24.AA 2B 28 02 SET-MSB(02) Wed 05/15/2013 02:39:20 PM : [standard-Direct Ack][0F.C1.DE-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 05/15/2013 02:39:20 PM : [iNST-TX-I1 ] 02 62 0F C1 DE 0F 2B 64 Wed 05/15/2013 02:39:20 PM : [iNST-ACK ] 02 62 0F.C1.DE 0F 2B 64 06 PEEK (64) Wed 05/15/2013 02:39:20 PM : [iNST-SRX ] 02 50 0F.C1.DE 13.24.AA 2B 2B 7F PEEK (7F) Wed 05/15/2013 02:39:20 PM : [standard-Direct Ack][0F.C1.DE-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 05/15/2013 02:39:20 PM : [iNST-TX-I1 ] 02 62 0F C1 DE 0F 29 11 Wed 05/15/2013 02:39:20 PM : [iNST-ACK ] 02 62 0F.C1.DE 0F 29 11 06 POKE (11) Wed 05/15/2013 02:39:21 PM : [iNST-SRX ] 02 50 0F.C1.DE 13.24.AA 2B 29 11 POKE (11) Wed 05/15/2013 02:39:21 PM : [standard-Direct Ack][0F.C1.DE-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 05/15/2013 02:39:21 PM : [iNST-TX-I1 ] 02 62 0F C1 DE 0F 24 00 Wed 05/15/2013 02:39:21 PM : [iNST-ACK ] 02 62 0F.C1.DE 0F 24 00 06 (00) Wed 05/15/2013 02:39:21 PM : [iNST-SRX ] 02 50 0F.C1.DE 13.24.AA 2B 24 00 (00) Wed 05/15/2013 02:39:21 PM : [standard-Direct Ack][0F.C1.DE-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 05/15/2013 02:39:21 PM : [F C1 DE 1 ] Memory : EPROM Refreshed I did >Diagnostics>Query Insteon Engine in all cases.

Well sort of... Not a lamb to the slaughter at all. Just curious as to why I find repeated mention of multiple scenes when I have never needed them. And then today I was adding another Fanlinc and a V.41KPL and a MiniRemote (Remotelinc2) and I ran into a problem. The miniremote does not have the KPL secondary sliders so I can do the KPL button tracking without ISY programs. I went to the forums for info and all the reference were for a multi-scene approach. While that did not fix the problem I came here for, I became curious why my single scene methodology is not commonly utilized. As I do not have the ISY call the fan scenes ever, it had not even occurred to me that multiple scene would be required. For my purposes, I like the single scene approach. Clean and tidy with no downside I can see. As for the unrelated issue of the KPL secondary sliders not showing up in the scene when I choose either the ISY scene node or one of the MiniRemote controller nodes, I suspect that is due to me being on 3.2.6. I know that this new feature of the KPLs was just coming out when 3.2.6 was released. I can do it from another KPL, but apparently not from the MiniRemote. I am stuck here for a while. Mac, Java, 10.6.8 The new ISY firmware does not work with the Java I have, and to get the new Java I have to change operating systems, which may necessitate new hardware. It is a whole thing.

So only from ISY control perspective? Meaning that if we want the ISY to be able to call different fan speed scenes we need multiple scenes? But if I just want two KPLs and Remotelinc2 to be in a scene with the Fan motor it would work fine? As long as I never need an ISY program to call a fan scene speed, this would never be an issue, right? The twelve controllers can each call for the proper fan speed in a single scene.

Hey LeeG, Why 3 separate scenes for High, Medium, and Low? I have seen this mentioned several times in the forum. Why not just one scene called Fan. All the controllers are added and the motor speed is set and the >v.40 KPL secondarys are adjusted for 0% on level for each controller as necessary?