22 hours ago22 hr I have a random event which starts when a motion sensor (2844-222) triggers a scene for basement lights, but (not related) my garage door (IOLinc) opens and a light (LampLinc) turns on.This is very rare event occurring once every 4 weeks ... The motion sensor is top of basement stairs and controls basement light scenes ... Post event, looking through LOG (Tools) the motion sensor, the garage door (IOLinc) or the LampLinc do NOT appear when this event log and when I look at the LampLinc status, it shows off state, and If I look at a scene containing the LampLinc, it shows OFF status, but a mini remote button (4 Scene) shows ON associated with the LampLincI have run Tools / Diagnostics / Event Viewer for weeks hoping to catch what triggers this event ... no luck ...Looking for direction on how to capture / diagnose this random event Cheers
22 hours ago22 hr If the ISY has no knowledge of the event, and the Event Viewer isn't showing anything, this would appear to qualify as an "all on"event. Motion sensors and KPL's calling programs that in turn call scenes involving the triggering device are known instigators. The Wiki Guidance is below. There are also numerous posts on the forum.Smartlabs has removed the all-on command from some recently produced devices (V.45). Your IOLinc is probably susceptible. The second link below shows how to test for susceptibility. The 3rd link shows devices that have been tested for susceptibility and have passed.As a precaution, you should probably perform a "restore device" on your problem units to make sure no extraneous links have crept in over time.Wiki link on preventing all on eventshttps://wiki.universal-devices.com/INSTEON_Random_All_On_EventsYou can test for susceptible all on devices as shown here: Edited 22 hours ago22 hr by IndyMike
22 hours ago22 hr Author 8 minutes ago, IndyMike said:If the ISY has no knowledge of the event, and the Event Viewer isn't showing anything, this would appear to qualify as an "all on"event. Motion sensors and KPL's calling programs that in turn call scenes involving the triggering device are known instigators.Appreciate the response and I think I understand what you are suggesting by "instigators", but there are no associations of my basement light control via programs, sensors or KPL's here to my garage door control or a standalone light .... I also discovered today, the garage light was also turned on ... which is new
21 hours ago21 hr 57 minutes ago, jim_ said:Appreciate the response and I think I understand what you are suggesting by "instigators", but there are no associations of my basement light control via programs, sensors or KPL's here to my garage door control or a standalone light ....I also discovered today, the garage light was also turned on ... which is newThe "Random" event is caused by a communication collision at the PLM. The result of the collision is an Insteon "All-On" command sent to all devices. Devices that have not had the command removed will be affected.
21 hours ago21 hr Insteon MS and other Insteon wireless devices are near the top of the instigators list.Is the MS on batteries? In addition to the restore device suggestion, you can try factory resetting it and adding new batteries and then restore device. My experience is that lower the battery voltage gets on the MS, the more un predictable the behavior gets. I eventually put my MSs on a spring/fall battery rotation, ignoring the battery node from the device... and factory resetting them / restore device every time
19 hours ago19 hr Author 1 hour ago, IndyMike said:The "Random" event is caused by a communication collision at the PLM. The result of the collision is an Insteon "All-On" command sent to all devices. Devices that have not had the command removed will be affected.learning enabled ... I understand a collision @ PLM, but not understanding "All-On" + "Devices that have not had the command removed will be affected" How does one remove the command "All-On" per device ?1 hour ago, paulbates said:Insteon MS and other Insteon wireless devices are near the top of the instigators list.Is the MS on batteries? In addition to the restore device suggestion, you can try factory resetting it and adding new batteries and then restore device. My experience is that lower the battery voltage gets on the MS, the more un predictable the behavior gets. I eventually put my MSs on a spring/fall battery rotation, ignoring the battery node from the device... and factory resetting them / restore device every timeMS is hardwired to 5v and was factory reset ~ 6 months ago, but days after this random event was still occurring. I'm not convinced it's the MS as root cause ... Since it's always the same devices affected (Lamp, Garage Door, and Garage Light (wife confirmed specifically these 3 only) and there is zero association with the MS / basement lights, we do know that when after 60 second-ish the MS is triggered, then these other 3 devices are affected. Since its not practical to share all my devices and related programs, but there are KPL's with control for this group of devices as well as others .... is it possible for data collision in a KPL ? (and yes the KPL(s) have been reset) .... Back to the question of tools ... should I expect to see messaging in event viewer or is there other tools that I should explore or I'm SOL from a logging perspective ?
17 hours ago17 hr If it's workable, I'd pull the plug on the MS for the approximate amount of time it takes the ALL ON event to happen and see if it happens again. I had an MS 2 in my garage for a couple of years, on power not batteries. Worked perfectly during that time, ... until recently....It recently started having problems and I tried all of the suggestions I gave above and had problems changing parameters such that they would stick. It was sending A LOT of messages for its motion sense. Factory resetting, etc had no effect so I replaced it with something else.
4 hours ago4 hr 14 hours ago, jim_ said:learning enabled ... I understand a collision @ PLM, but not understanding "All-On" + "Devices that have not had the command removed will be affected" How does one remove the command "All-On" per device ?The All-On is a valid Insteon command. When a communication collision at the PLM occurs, a valid outgoing scene command is corrupted into an "All-ON or All-Off" scene command. All older Linked Units will respondIn recent years, Smartlabs began removing the "All-On/All-Off" command from individual devices. Many dimmers/relays with firmware newer than V.45 have had the command removed and will Not respond. One of the links I provided describes how to test for this.15 hours ago, jim_ said:lMS is hardwired to 5v and was factory reset ~ 6 months ago, but days after this random event was still occurring. I'm not convinced it's the MS as root cause ...Since it's always the same devices affected (Lamp, Garage Door, and Garage Light (wife confirmed specifically these 3 only) and there is zero association with the MS / basement lights, we do know that when after 60 second-ish the MS is triggered, then these other 3 devices are affected. Since its not practical to share all my devices and related programs, but there are KPL's with control for this group of devices as well as others .... is it possible for data collision in a KPL ? (and yes the KPL(s) have been reset) ....Back to the question of tools ... should I expect to see messaging in event viewer or is there other tools that I should explore or I'm SOL from a logging perspective ?While it's possible to have a data collision at the KPL, it shouldn't produce an "all-on". The reason are rather dry and technical.It is completely possible for the KPL to cause a collision at the PLM. This typically occurs when the KPL is a scene controller and also triggers a program.MS's are high on the list of instigators because they have the annoying of sending multiple communications to the PLM (increasing the likelihood of a collision).To your last question on messaging - is this is a true "all-on" event you will not see evidence in the event viewer. You may be able to isolate the trigger event through the process of elimination (as you are doing), the the event will look like a normal trigger.Having said the above, one of our forum members has noted communication errors between the PLM and EISY ( @kclenden ). Would you mind posting a level 3 event viewer capture? We could go through the PLM/ISY communications to see if errors exist.
1 hour ago1 hr Author Thanks for the descriptive reply, this helps me understand .... 2 hours ago, IndyMike said:Having said the above, one of our forum members has noted communication errors between the PLM and EISY ( @kclenden ). Would you mind posting a level 3 event viewer capture? We could go through the PLM/ISY communications to see if errors exist.Just to clarify .... request to post L3 events log > would this be a general capture (normal MS activation of basement lights ) or specific to the random event ?
Create an account or sign in to comment