Illusion

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?

The only way would be to disable the normal 4am query and build your own scene with only the devices you want queried and a program to query that scene at 4am. -Xathros Use EXTREME caution if you choose to do this. With a user made scene for the purpose of Query, devices that are controller only will be added to the scene as a controller. IE, an IOLinc sensor node would control all the other devices in the scene if it were to turn on. Same for triggerlincs and the like.

For some light reading... viewtopic.php?p=69560#p69560 May be related

I think I am going to call this a bug report: See discussion viewtopic.php?p=67295#p67295 for all details. I have been aware of this issue for some time, but due to a new program it has become a problem for me and I am not sure it has been addressed in subsequent betas as I am not on them. If an IOLinc relay is in a scene with reverse function via the on level being at zero, the relay functions as expected on scene operation; however, the ISY's awareness of this action is incorrect and as a result the status in the ISY will be incorrect.

ergodic, I know this is off topic, but I thought I would mention it here. Philips has developed a LED product line called Dimtone that warms up as it dims to match incandescent. I do not know if they have an MR16 yet, but might be worth investigation.

Or you could put that $160 toward LED bulbs instead of Flos. Great if it gets cold in the shop, and much more energy efficient. No filters, plugs, etc required... http://store.earthled.com/collections/l ... I1O5r_Npyc

viewtopic.php?t=2673 Sent from my iPhone using Tapatalk

Sounds like maybe the ISY cannot hear the 6 button KPL when the lights are on. Open Admin Console>Event Viewer Turn lights on, try to turn lights off with 6 button KPL. See if the ISY can hear the KPL by looking for entry in the 'Event Viewer' I had a lamp in the living room that I could always turn on, but not off. It was a flo that was going bad. Switched to LEDs and have not had a failure since.

You are going to have to explain this. I had assumed that the button on the 6 button KPL related to the lights was a controller for said scene. If that is not the case, and the ISY is involved in this event directly (not just an observer) please explain why the signal has to go to the ISY and then return. Further, I do not think the log is what you want. It shows status changes, but not traffic. What you want is the event viewer. See the wiki article for details. The wiki is easy to get to as there is a link in the 'Help' section of the Admin Console that links there. Finally, I think while you are at the wiki, you should also investigate 'Scene Test'.

Florescent light in shop? You can view the log without Excel, just say no to open with excel and you should be able to save log as a .txt file. If I had to make a guess based on the factors you listed, the circuit the 6 button KPL is on is far away and on a different phase than the lights. When you turn the lights on the attached load is causing enough noise or absorption to interfere with the module hearing the off command from the 6 button KPL. Try connecting an incandescent test lamp instead of the current load to the module and then see if you can turn it on and off from the 6 button KPL

Personally I would stick with an iPod or iPad with the app of your choice running on it. There are several nice in wall mounting plates that provide constant power so you do not need to remove the device for charging. Plates for iPods run about $250, for iPad about $500

Interrupt the aux heat wire coming from the t-stat. Leave the Aux Heat wire connected to the terminal from the outdoor unit. That is where the call for Aux Heat during a defrost cycle will come from. As the others have said, never interrupt that! Not great for your equipment, and kinda uncomfortable.