Another ALL ON Event

[marvel]

Just experienced it again. This time nothing was going on that I know of. I hit my "sleep" scene at 9:02:38pm. Climbed in bed, was reading a book, nobody else in the house. Right about 9:30 every light & device in the house just snapped on to 100%. 

[stusviews]

The latest (currently shipping) serial PLM (2413S) is purported to have removed the All On/Off command.

[Michel Kohanim]

Hi marvel,

 

Please send your log and error log to support@universal-devices.com + the approximate that it happened. 

 

With kind regards,

Michel

[marvel]

I bought a new PLM recently in an attempt to address this issue - it shows up as v9E in the ISY. Don't know if that's the latest firmware or not. 

 

Michel, I'm sending the logs over now. Thank you for your help.

[kmhpaladin]

The latest (currently shipping) serial PLM (2413S) is purported to have removed the All On/Off command.

 

SH has done something. They removed the All On/Off command from all shipping devices some months ago. Albeit, it doesn't help those with earlier devices. I'm not sure what else they can do that wouldn't wreak havoc on their finances.

 

Apologies for bumping a thread that hasn't been updated in several months. I've been reading through the forum and saw chrishick's recent thread about experiencing an All On condition and started going back looking for prior discussion of the problem.

 

Because I recently installed an Insteon garage kit and my garage faces a street with a decent amount of foot traffic (to say nothing of the possessions inside the garage or the point of entry to the house) this was a bit of a chilling realization.

 

Based on the quoted posts above, it seems Smarthome has removed the "All On" function from both new hardware and new PLMs. I did also see this recent thread that seems to confirm newly shipped devices don't respond. If this is the case I believe anyone in my situation (with new or relatively new hardware) does not need to worry about the possibility. However the major feedback I've seen from Michel while reading this thread has indicated a 'race condition' is the usual cause of this event and somehow triggers an "All On" command.

 

To sum it up into one question - if my whole system has been purchased in the last ~2 months, is there any reason to worry about this? I'd like to programmatically incorporate some motion sensors and door/window sensors which may influence Keypadlincs, and want to determine how concerned I should be.

[jerlands]

To sum it up into one question - if my whole system has been purchased in the last ~2 months, is there any reason to worry about this? I'd like to programmatically incorporate some motion sensors and door/window sensors which may influence Keypadlincs, and want to determine how concerned I should be.

 

The source for the all on has never been fully exposed but some speculate packet collisions caused by low battery condition in motion sensors or other battery operated devices could be a fault.  I personally think it best to only use the sense of the IOLinc and not control the garage door opener with it.  There's a lot of discussion on the safety involved using auto closure so ensuring proper operation of garage door closure safety features regularly is a must before implementing.

 

 

Jon...

[kmhpaladin]

thanks for the input Jon. I guess if there are collisions caused by battery operated device communications, would that matter if none of the devices (being new in my case and supposedly after Smarthome revised the devices) respond to an "All On" command? the proverbial tree in the forest situation?

 

from the perspective of the IOLinc and the garage door, I appreciate the safety concerns but I don't have roommates, kids etc. so I'm not overly worried about operation at this time.

[jerlands]

 would that matter if none of the devices (being new in my case and supposedly after Smarthome revised the devices) respond to an "All On" command? the proverbial tree in the forest situation?

 

I'm sure others can interject with more knowledge but my understanding is the only device that had any firmware change in response to "all on" was the PLM.  I'm thinking packet collisions can affect any device linked to battery operated devices and in particular the motion sensor as they seem to send out fast series of On conditions when battery is low.  And, although extremely rare you can see in the forum reports of devices operating unsolicited and it seems these events get tied in one way or another to battery operated devices which usually are the motions sensors.  I've never had any aberrant operation though I don't have any devices directly liked to motion sensors but many do without incident and I don't think there's a real good explanation.  As for immunity..  I wouldn't count on it but consider the possibility.

 

 

Jon...

[LeeG]

kmhpaladin

 

I have never seen an All On locally (as well as many other ISY users) and I use 2 ISYs.   Others have experienced the All On/Off many times.  There are programming styles that may generate an All On situation which I avoid using.   

 

I don't think all devices have had their firmware updated to ignore an All On message.   Most of my devices are old enough not to have updated firmware.   The newest PLMs (hardware v2.x, firmware v.9E) have been changed not to generate an All On originated by a message collision. 

[stusviews]

There are programming styles that may generate an All On situation which I avoid using.   

 

Can you be more specific about which styles should be avoided?

[LeeG]

There is information generated by UDI that covers the possible issues.   Not sure if that has been rolled into Wiki or the original All On forum discussion.

 

The first one I pay attention to is the Program triggered by a battery device and what the Then/Else clause does in response..   The Motion Sensor, for example, generates a series of Insteon messages.  Best not to overlap those inbound messages with a cluster of outbound activity generated by the Then/Else.  I'm running a PLM with v.9B firmware (no All On changes) without ever generating an All On.

 

There are suggestions/recommendations by UDI regarding the KPL for which I do not have the details.   I'll see if I can find what UDI has published.  

 

 

EDIT: The Wiki has this item about All On

 

 

http://wiki.universal-devices.com/index.php?title=INSTEON_Random_All_On_Events

[larryllix]

I have ten MS units, have never avoided any particular programming style, and have never experienced an AllOn in my two years and half years with ISY. I always respond with no Wait inserted. I replaced my PLM about 6 months ago to have a good backup unit on hand.

 

My battery operated MS units do not produce random or spurious On commands when the batteries are low. The LEDs flash multiple times when triggered by motion so the user can see the alert..

 

They may produce multiple On commands at the same time, but they are never random or spurious.

[Jimbo.Automates]

I have ten MS units, have never avoided any particular programming style, and have never experienced an AllOn in my two years and half years with ISY. I always respond with no Wait inserted. I replaced my PLM about 6 months ago to have a good backup unit on hand.

 

My battery operated MS units do not produce random or spurious On commands when the batteries are low. The LEDs flash multiple times when triggered by motion so the user can see the alert..

 

They may produce multiple On commands at the same time, but they are never random or spurious.

Do you have any programs that update scenes which contain KPL buttons of the same KPL that a MS controls? That seems to still be an issue for me.

 

Sent from my Pixel C using Tapatalk

[larryllix]

Do you have any programs that update scenes which contain KPL buttons of the same KPL that a MS controls? That seems to still be an issue for me.

 

Sent from my Pixel C using Tapatalk

I only have one 6 button KPL, and it is with an MS  in the same room.

The MS is direct linked (scene) to the KPL and turns on the lights.

ISY then switches off the lights based on a wait statement.

I don't bother changing brightness on that KPL based on ToD. The potlights are LED and the room can be a little shady, anyway, even in full daylight.

I do change the LED brightness based on ToD.

 

I have noticed in my events logs that the MS puts out a tonne of commands if a device does not answer the On command. IIRC the MS repeatedly sent out close to a dozen On commands and they registered in ISY until I direct scene linked it to the KPL dimmer. Now it puts out two or maybe three. I figured it was looking for confirmation of the command from somebody and kept trying until somebody answered and ISY wasn't doing it properly or too late do to I/O processing or whatever.

 

 

Wait...!  Who is ToD?

[Algorithm]

I don't think all devices have had their firmware updated to ignore an All On message.   Most of my devices are old enough not to have updated firmware.   The newest PLMs (hardware v2.x, firmware v.9E) have been changed not to generate an All On originated by a message collision. 

 

When we moved to a new house last August, I installed all new Insteon (dual-band) devices, both in-wall, and in-pedestal (KPLs).  The new PLM is V2.1, firmware 9E, date code 1530.  On January 18, we experienced the only ALL-ON event we have ever had, either before moving or after.  So, the new PLM is no guarantee against ALL-ON events, though I have no way of knowing whether or not the PLM played an active role in that event.

 

Al

[Jimbo.Automates]

I only have one 6 button KPL, and it is with an MS  in the same room.

The MS is direct linked (scene) to the KPL and turns on the lights.

ISY then switches off the lights based on a wait statement.

I don't bother changing brightness on that KPL based on ToD. The potlights are LED and the room can be a little shady, anyway, even in full daylight.

I do change the LED brightness based on ToD.

 

I have noticed in my events logs that the MS puts out a tonne of commands if a device does not answer the On command. IIRC the MS repeatedly sent out close to a dozen On commands and they registered in ISY until I direct scene linked it to the KPL dimmer. Now it puts out two or maybe three. I figured it was looking for confirmation of the command from somebody and kept trying until somebody answered and ISY wasn't doing it properly or too late do to I/O processing or whatever.

 

 

Wait...!  Who is ToD?

 

I think that is why you never see a problem.  From my understanding, the majority of the problems are caused by what I mentioned.   I have this:

 

Scene: KitchenUnderCabinet

  KU.SWL is a controller

  K.MS is a controller

  K.KPL.B is a responder

 

Scene: KithenIsland

  KI.SWL is a controller

  K.KPL.B is a responder

 

Scene: KithenCans

  KC.SWL is a controller

  K.KPL.B is a responder

 

Scene: AllKitchen

  KU.SWL is a responder

  KI.SWL is a responder

  KC.SWL is a responder

  K.KPL.B is a controller

 

Scene: AllKitchen-Button

  K.KPL.B is a responder

 

So, when any kitchen light is turned on, the AllKitchen Scene comes on, so one button K.KPL.B can turn off all kitchen lights.

 

The problem is, if you turn on KU.SWL, KI.SWL, and KC.SWL then turn off KI.SWL, then the AllKitchen Scene show off.  So I have a program that turns on AllKitchen-Button if K.KPL.B is off and any of the SWL's are not off.  I have delays in this program, but you never now when the MS is going to send a on, so I still have the issue occasionally.

 

Is there a better way to do something like this?  I use this in a few places for an "All Area Off" button, but I'm going to have to get rid of them since I'm pretty sure 

[larryllix]

I willhave to spend some time and draw that one out. I think I understand it mostly.

Is K.KPL.B a button LED?

 

I assume KDPL.B is a typo?

 

 

Another thing that crossed my mind is that I don't issue scene commands from ISY in response to controllers. I mostly just issue device commands except for a few like ALL lights and doorbell On/Off.

 

The MS always does the scene ON and ISY Waits and then turns devices off, not scenes. I don't think it would matter after a 45 second delay though, just at the ON stage.

 

All my MS/Lamp  passthrough programs have a first line Wait X seconds. I don't have a device turn on from ISY in the MS programs from ISY so no interference should be seen with the MS multiple command sends.....maybe?

 

If

    MS is switched On

 

Then

   Wait 45 seconds   <--the scene direct linked communication has already turned the lamp on no Set Lamp 'On' and especially no Set Scene 'On'

    Set Lamp 'Off'

Else

 ---

 

 

Another thing is that I do not play with my KPL LEDs. Perhaps the echoing of scene signals around causes some clashing. You could try removing them from scenes, put them in separate scenes, alone,  and operate them for ISY programs after a few second delay.

[Jimbo.Automates]

Yes, it was I typo and I fixed it, thanks.  Yes, K.KPL.B is the Kitchen KeypadLinc B button.

 

I also do not have the MS's send off commands, only turn scenes on and the ISY turns them off.  But, I almost always have the ISY turn the scene off, not the device since there is typically a KPL button for the scene that I want to turn off as well.

 

I have lots of KPL buttons, and like to play with them  But having all-on's occasionally is making me not want to anymore.  Although, after reviewing my programs I made a slight change that will hopefully stop it from happening.

[Algorithm]

We've just had our second ALL ON event.  This time, I was at the computer with the Admin Console open, and I noticed something else.

 

Normally, I have lights come on to 90%.  After this ALL ON event, lights that had already been on, at 90%, were now on at 100%, as confirmed by a QUERY ALL.  So, were the devices seeing an "ON to 100%", or a "FAST ON", or something else?  I don't know whether or not this has been previously reported, or whether it will help.

 

Al

 

[Michel Kohanim]

Hi Al,

 

I am so very sorry to hear. Can you look at your logs and see what else was happening at the time?

 

With kind regards,

Michel

[Algorithm]

Hi Al,

 

I am so very sorry to hear. Can you look at your logs and see what else was happening at the time?

 

With kind regards,

Michel

 

Hi Michel,

 

Here is the relevant section of the log:

88568 Scene:2Lvl / 2s Main Bath Fan         Off       0 Tue 2016/04/05 05:41:33 PM Program Log		
88569 2Lvl / 2d Main Bath Fan               Status   0% Tue 2016/04/05 05:41:33 PM System  Log		
88570 Scene:Scenes / sbAll                  On          Tue 2016/04/05 05:41:34 PM Program Log		
88571 Scene:Scenes / sbAll Except MBR       On          Tue 2016/04/05 05:41:34 PM Program Log		
88572 4Lvl / 4d Stairs Light - Top          Status  90% Tue 2016/04/05 05:41:35 PM System  Log		
88573 4Lvl / 4d Stairs Light - Bottom       Status  90% Tue 2016/04/05 05:41:35 PM System  Log		
88574 Scene:4Lvl / 4s Rec Room Track Lights On          Tue 2016/04/05 05:41:35 PM Program Log		
88575 4Lvl / 4d Rec Room Track Lights       Status  90% Tue 2016/04/05 05:41:35 PM System  Log		
88576 Scene:4Lvl / 4s Rec Room Track Lights On          Tue 2016/04/05 05:41:36 PM Program Log		
88577 Scene:4Lvl / 4s Rec Room Track Lights On          Tue 2016/04/05 05:41:36 PM Program Log		
88578 Scene:Scenes / sbAll                  On          Tue 2016/04/05 05:41:37 PM Program Log		
88579 Scene:Scenes / sbAll Except MBR       On          Tue 2016/04/05 05:41:37 PM Program Log		
88580 Scene:Scenes / sbLaundry              On          Tue 2016/04/05 05:41:41 PM Program Log		

Nothing else for seven minutes prior, and nothing following for three minutes.

 

At 05:41:33 a program turned off the main bathroom fan (88568); the following two scenes are KPL buttons, indicating that something is on.  Two seconds later, at 05:41:35 (88572) a motion sensor turned on the 4th level stairway lights; the motion sensor is scene-linked to the switches at the top and bottom of the stairs.  When that happened, a program turned on the Rec Room lights, as expected (88574).

 

It was at this point that the ALL ON event occurred.

 

Lines 88574-88575 are expected, but lines 88576 and 88577 are not expected; I cannot account for them.

 

The last three lines are KPL button scenes, and are expected.

 

Al

[Michel Kohanim]

Hi Algorithm,

 

Thank you. I would start with figuring out why lines 88574 and 88575 were triggered and, more importantly, in the same second. Since those were activated by a program, please use Find/Replace on program and look for the occurrences of Rec Room Track Lights .

 

With kind regards,

Michel

[Algorithm]

Hi Algorithm,

 

Thank you. I would start with figuring out why lines 88574 and 88575 were triggered and, more importantly, in the same second. Since those were activated by a program, please use Find/Replace on program and look for the occurrences of Rec Room Track Lights .

 

With kind regards,

Michel

 

Hi Michel,

 

As per previous post, lines 88574 and 88575 are expected.  Did you mean lines 88576 and 88577?

 

The scene 4s Rec Room Track Lights appears in only one program[*]--that is the program which activated lines 88574 and 88575 as expected.  So, still not sure what caused lines 88576 and 88577.

 

Also, the device 4d Rec Room Track Lights does not appear in any programs as being controlled (THEN/ELSE), only as giving status (IF).

 

[*] Actually, the scene does appear in one other program, but that program is not enabled, and is called only by a KPL button press.  It could play no part in the above event.

 

Al

[Michel Kohanim]

Hi Al,

 

Sorry and, yes, correct:

88576 Scene:4Lvl / 4s Rec Room Track Lights On Tue 2016/04/05 05:41:36 PM Program Log

88577 Scene:4Lvl / 4s Rec Room Track Lights On Tue 2016/04/05 05:41:36 PM Program Log

 

As you can see, they were activated by a program. So, there must be a program that controls them.

 

With kind regards,

Michel

[marvel]

the new PLM is no guarantee against ALL-ON events

 

I can confirm this. I specifically bought a new PLM, v9E, when I was troubleshooting my ALL ON events. The new PLM made no difference; I still experienced events 2 to 3 times per month. They did seem to be related to motion sensors triggering programs. I opened a trouble ticket with Smarthome and they said the problem is unique to UDI and "No other software that works with Insteon has this issue." For whatever that's worth.

 

Of note, neither of my PLMs ever captured the ALL ON, nor did it show up in any of the ISY logs.

 

I may have resolved my issue. I noticed one of my KPLs flashing its LEDs in an odd pattern one day that I didn't recognize. On a hunch, I pulled the air gap and left it. This was several months ago and I have not seen another ALL ON since. I tried everything, too. Lots of modifications to my programs were made (suggested by others here) involving adding WAITS and not doing certain things. The mods made my programs slower and less useful and still didn't help with the problem. I'm going to slowly start putting my programs back the way they were and see if the problem comes back, but I don't think my programs are/were to blame.