paulbates Posted January 24 Share Posted January 24 The AC wasn't available to me at the time to report the FW versions of recent devices that "All On"-ed 2450 iolincs .41 Micro dimmer 2442-222 .49 Siren 2868-222 .46 2 Link to comment
paulbates Posted January 24 Share Posted January 24 13 hours ago, dbwarner5 said: Hmm.. I have two breaker boxes, so in theory, four legs to cover. My PLM is on a plug that is hardwired, 4' away to one leg on one breaker box. With ~250 insteon devices with 98% of them dual bridge I would be surprised if that is the issue. If you look at the 2 screen shots in the Insteon forum post, those show the difference- # of hops before and after throwing the breakers for the signal linc. That was my last house where I had a number of dual bands. That screenshots are of the homeseer plugin, from homeseer that I no longer have. I don't have homeseer at the new house, but I did use the event viewer and on/off and query every Insteon powerline capable device several times after the installing the parts. Everything has 3 hops left almost every time. Maybe an audit of ~5 devices and try that yourself.. but also add any problem devices like micro module.. how many hops average? Link to comment
IndyMike Posted January 24 Share Posted January 24 14 hours ago, dbwarner5 said: Hmm.. I have two breaker boxes, so in theory, four legs to cover. My PLM is on a plug that is hardwired, 4' away to one leg on one breaker box. With ~250 insteon devices with 98% of them dual bridge I would be surprised if that is the issue. However, there is an ice maker nearby this micro dimmer and could possibly be causing some weird interference. I have an old Range Extender, which is also a bridge. I will play around with it, moving it around to see if I can bridge better and eliminate the gremlin. Thanks! @dbwarner5, I you have a single power meter, your breaker boxes are wired in parallel - you need only 1 signalinc on the legs of 1 box. If you have two separate power meters, you are correct that you need a sginalinc on each panel. You would also need RF linking between the panels. 1 Link to comment
IndyMike Posted January 24 Share Posted January 24 14 hours ago, kzboray said: @paulbates I had no idea the "ALL ON" button in AC would activate the ALL ON bit in FW. I always thought it would just send an ON to all devices. I had never tried it until your post. Thank you! @kzboray, Very curious about the "ALL ON bit IN FW" that you referenced above. Can you elaborate? Link to comment
Michel Kohanim Posted January 24 Share Posted January 24 @kzboray, If you don't see those events reflected in the IoX log, then it's definitely an All On/Off event. This happens for one reason and one reason only: IoX receives an event (usually from RF/dual band devices that send duplicates), a program runs in IoX and sends a group command (scene) at/around the same time. The result is that the group command is corrupted by the PLM (All devices) or something in between (Some devices). From experience, the majority of the time the issue happens when you try to control KPL backlights based on status of some other devices and/or sensors. Some remedies are outlined here: https://wiki.universal-devices.com/INSTEON_Random_All_On_Events Link to comment
kzboray Posted January 24 Share Posted January 24 @IndyMike Prior to 2016/17 most Insteon devices had an ALL ON function in FW. It was notorious for causing ALL ON events unexpectedly so they removed it reportedly from all devices, but as it turns out it's still present in PLM's, Micro Modules, and IOLinc's. It may be present in other devices as well. i3 devices seem to be free from ALL ON in FW. I am going to start replacing all IOLinc's and Micro Modules with similar Shelly devices to eliminate as many potential ALL ON Events as possible for my clients. There's nothing to be done about the PLM except to put pressure on Insteon to fix it. In the mean time I will also be removing all programs that change back lighting because Michel has indicated this is a common cause of ALL ON events (See the post above.). Some of my clients will hate this and I will need to evaluate each situation independently, but I can't have pumps running dry, security gates opening, or fire-pits coming on unattended. Michel also detailed how this happens and given the processing speed increase with Polisy and eisy, it makes sense to me that this can occur more often. So as indicated I am going to start replacing HW to eliminate this possibility. Link to comment
IndyMike Posted January 24 Share Posted January 24 (edited) @kzboray, As Michel indicated earlier, the problem exists between the PLM and the ISY. I am paraphrasing here - when the PLM is hit by multiple requests/transmissions (like a RF motion sensor) while a scene/program is being activated by the ISY a collision can result. The resulting collision corrupts the scene command and can produce the all-on/all-off or A DIFFERENT SCENE COMMAND. As I posted earlier, the differences in commands is slight. The first command below turns on 3 devices in my basement scene. The second command activates any Insteon device linked to the PLM. I can go into far more detail if needed... Wed 08/02/2023 12:10:09 PM : [INST-TX-I1 ] 02 62 00 00 27 CF 12 00 Wed 08/02/2023 09:17:29 AM : [INST-TX-I1 ] 02 62 00 00 FF CF 12 00 I had thought that the All-on/all-off command had already been removed from the PLM. In retrospect, this may not be an easy thing to accomplish. For users however, it is ABSOLUTELY the easiest path to remediation. Far easier to replace 1 PLM vs 100's of devices (stating the obvious). I do agree that Insteon devices are inappropriate for applications that are critical (pumps, gas valves) or require security (door locks, garage doors, etc). If Insteon eliminates the ALL-On command from devices, that does not make them secure. It does make them somewhat more reliable. There are some home automation technologies that are secure Edited January 24 by IndyMike 2 Link to comment
kzboray Posted January 24 Share Posted January 24 (edited) Thank you @IndyMike I especially appreciate the testing methodology and tools. Your detailed post of the bit difference that creates an all on event is exactly the kind of info I've been trying to figure out. Edited January 24 by kzboray Link to comment
GSpitale01 Posted February 29 Share Posted February 29 On 1/24/2024 at 4:20 PM, IndyMike said: @kzboray, As Michel indicated earlier, the problem exists between the PLM and the ISY. I am paraphrasing here - when the PLM is hit by multiple requests/transmissions (like a RF motion sensor) while a scene/program is being activated by the ISY a collision can result. The resulting collision corrupts the scene command and can produce the all-on/all-off or A DIFFERENT SCENE COMMAND. As I posted earlier, the differences in commands is slight. The first command below turns on 3 devices in my basement scene. The second command activates any Insteon device linked to the PLM. I can go into far more detail if needed... Wed 08/02/2023 12:10:09 PM : [INST-TX-I1 ] 02 62 00 00 27 CF 12 00 Wed 08/02/2023 09:17:29 AM : [INST-TX-I1 ] 02 62 00 00 FF CF 12 00 I had thought that the All-on/all-off command had already been removed from the PLM. In retrospect, this may not be an easy thing to accomplish. For users however, it is ABSOLUTELY the easiest path to remediation. Far easier to replace 1 PLM vs 100's of devices (stating the obvious). I do agree that Insteon devices are inappropriate for applications that are critical (pumps, gas valves) or require security (door locks, garage doors, etc). If Insteon eliminates the ALL-On command from devices, that does not make them secure. It does make them somewhat more reliable. There are some home automation technologies that are secure Is there a known PLM "batch" that has this removed, or is there another way to update PLM firmware? Link to comment
Techman Posted February 29 Share Posted February 29 @GSpitale01 The PLM firmware cannot be updated. Take a look at this link: INSTEON Random All On Events - Universal Devices, Inc. Wiki (universal-devices.com) Link to comment
GSpitale01 Posted February 29 Share Posted February 29 @SMorgan apologies for hijacking your thread. @Techman I did read the INSTEON link and I don't have any of those circumstances. I am using the IO Linc as a garage door control/sensor, and had a bunch of random open/close events so am trying to hunt down potential causes. I'm aware of the security risks but want to figure out why the random events are happening. Link to comment
Techman Posted February 29 Share Posted February 29 @GSpitale01 Take a look at your event log. Do you see a command to open the door, if so look at the commands above it to see if there's a device that triggered just before the door opened. If you don't see a command to open the door when the door was opened then it's most likely a spurious command coming from the PLM not the controller. In that case it could be noise on the powerline that's triggering the PLM. It could also be the garage door motor/controller. I have mine plugged into a filterlinc. 1 Link to comment
Brian H Posted February 29 Share Posted February 29 4 hours ago, GSpitale01 said: Is there a known PLM "batch" that has this removed, or is there another way to update PLM firmware? We can't update the firmware. Technically the folks at Insteon could. The PLM has two programming connectors. One for the RF controller and the other main controller. Though you need a programmer used for the model controller chip being used and the Source Code and we know that will probably never be made public. Link to comment
GSpitale01 Posted March 1 Share Posted March 1 I had completely forgotten about the filterlinc. I do have a bunch of UPS’s in the house, so certainly could be line noise. Appreciate the help and suggestions. I’ll do some troubleshooting this weekend. Link to comment
Brian H Posted March 1 Share Posted March 1 UPS units have a power line conditioner in them. That see Insteon and X10 power line signals as noise and absorb the signals. So another possibility is the UPS is absorbing the signals. Fix is the same a FilterLinc on the UPS AC input. I have a FilterLinc on my UPS and the 2413S PLM on the unfiltered outlet on the front. Link to comment
GSpitale01 Posted March 1 Share Posted March 1 7 hours ago, Brian H said: UPS units have a power line conditioner in them. That see Insteon and X10 power line signals as noise and absorb the signals. So another possibility is the UPS is absorbing the signals. Fix is the same a FilterLinc on the UPS AC input. I have a FilterLinc on my UPS and the 2413S PLM on the unfiltered outlet on the front. I don't have any issues with commands not executing ... I have issues with un-commanded action with the IOLinc/2450 controlling the garage door. I do remember from my setup on a previous home, years ago, that I had to use FilterLinc devices on some of my noisy electronics to help with dropped commands - but have never seen this un-commanded action before. Link to comment
beninsteon Posted March 3 Share Posted March 3 The solution to the all on trouble is simple. Replace old switches/dimmers with newer versions that don't respond to the all on command. Most importantly don't use the iolinc relay for critical or security related actions (garage doors, fireplaces, etc). Use another relay the isy can control with network resources (eg global cache ip2cc). Link to comment
Recommended Posts