Mitigating All On

[MarkJames]

So I had an issue with all on's every few days some months ago.  I replaced my PLM and that seemed to solve it though to be safe I moved my fireplace and garage door on to Elk output relays from Insteon contact closures.

 

All was well but since last week I've had two all ons.  It's quite disturbing as every single light in my home is Insteon so having 140 odd switches pop on at 5am for no apparent reason is, in no uncertain words, a piss off.  One that I've lived through more times than I should have to for the amount I have invested in this.

 

This morning at 6:30am I had another all on event.  My log shows my last ISY activity at 6:27 so it's not something to do with ISY traffic and I have no Insteon motion detectors so it's not that either.  

 

I'm sick and tired of replacing PLM's and the hassle that goes with that - not to mention the expense - so I've decided to try something and wanted to run it past the community for an opinion.

 

I've got a couple of IOLincs (2450) that I'm not using.  My plan is to link one to the PLM via the ISY but leave its link table otherwise blank - that way I know that it's not being activated by another device or by the ISY itself.  My understanding of the ALL-ON is that the PLM sends an on signal that triggers everything in its link table.  So - an ALL-ON *should* trigger a 2450 - at least it did when I used the 2450 as a GDO - that's why I moved to Elk - my garage door would open when an ALL-ON happened and then my alarm would go off.

 

I'm going to connect the NO contact pair on the 2450 to my Elk as a non-burglar alarm zone.  The ISY can then monitor the status of that zone.  When an ALL-ON event occurs it should cause the relay on the 2450 to close.  When the relay closes the Elk will know it so the ISY will know it.  I keep a table of variables of the desired state of all devices in my house so the ISY could then run a program to simply turn every device back to the state it should be in.

 

This seems like a workaround to the problem.  I know it's not a solution but I don't think there IS a solution to this.  This is a huge failing imho of Insteon.  It's enough that it would be a deal killer for me if I were to be just starting off.

 

Does anyone see a problem with this idea?

 

Mark

[Teken]

Hello Mark,

 

I think your little test makes sense but it doesn't really address the key issues. If you haven't reviewed your programs its highly suggested you place a few *Waits* in programs that might be tightly looped. Since you don't have any motion sensors you should be checking any other battery operated devices you may have like open-close, hidden door sensor, leak sensor etc.

 

Again, you may want to consider placing a wait statement in the programs that monitor said device. 

 

If you have the latest 2.XX PLM using v9E firmware its been stated this and many other Insteon devices are void of the ALL ON / ALL OFF command broadcast message.

[MarkJames]

Hi Teken!

 

The thing is that I've done all that already.

 

My newest PLM is a v2.2 with firmware 9E.  I have a spare of that as well.  That replacement was in response to my last go with this. So.. if there is a claim that it can't broadcast ALL-ON then I call BS.  It's done it and it's doing it.  When an ALL-ON happens the lights don't go on in a progression the way they would programmatically.  They just go BANG and everything is on.  I don't even HAVE a program that would turn them all on nor do I have a scene that contains all my lights.

 

I got rid of all my battery powered devices in my last battle with this so that's not it.

 

I rewrote my program code last go round so I have a variable called 'OKtoGo'.  It's used globally such that when a program wants to turn off multiple lights it has to wait for 'OKtoGo' to be be true.

 

It works like this for example

 

 

Program turn off all upstairs

If OKtoGo = true

  OKtoGo=false

  run program bathroomoff then path

  wait 1 second

  run program bedroom1off then path

  wait 1 second

  etc

  OKtoGo=true

Else

  wait 2 seconds

run program turn off all upstairs

 

As you can see there is no way for there to be a tight loop - there are built in pauses between scene offs and between program executions.  AND... in todays ALL-ON there was 3 minutes of inactivity between the last ISY event and the ALL-ON.

 

We have had power outages here recently because of the snow so it may be related - or perhaps the PLM got damaged by the unstable power.  That's possible but I have no way to confirm that.

 

It's a hugely frustrating problem.

 

mark

[Teken]

Hi Teken!

 

The thing is that I've done all that already.

 

My newest PLM is a v2.2 with firmware 9E.  I have a spare of that as well.  That replacement was in response to my last go with this. So.. if there is a claim that it can't broadcast ALL-ON then I call BS.  It's done it and it's doing it.  When an ALL-ON happens the lights don't go on in a progression the way they would programmatically.  They just go BANG and everything is on.  I don't even HAVE a program that would turn them all on nor do I have a scene that contains all my lights.

 

I got rid of all my battery powered devices in my last battle with this so that's not it.

 

I rewrote my program code last go round so I have a variable called 'OKtoGo'.  It's used globally such that when a program wants to turn off multiple lights it has to wait for 'OKtoGo' to be be true.

 

It works like this for example

 

 

Program turn off all upstairs

If OKtoGo = true

  OKtoGo=false

  run program bathroomoff then path

  wait 1 second

  run program bedroom1off then path

  wait 1 second

  etc

  OKtoGo=true

Else

  wait 2 seconds

run program turn off all upstairs

 

As you can see there is no way for there to be a tight loop - there are built in pauses between scene offs and between program executions.  

 

It's a hugely frustrating problem.

 

mark

 

Hello Mark,

 

The ALL ON / ALL OFF has nothing to do with the 2413S PLM sending out this message. It doesn't matter what anyone tells you that is an empirical fact that many are simply not accepting.

 

One of the key problems which you can't avoid at the moment is you have lots of legacy hardware like me. Which does include the ALL ON / ALL OFF command class. So unless your willing to replace all your insteon hardware with new gear that is void of this command class expect to see this problem again.

 

I've asked countless people over the years to perform one simple test and that is to yank the controller out of the system and report back what happens.

 

As of this writing not one single person has ever done so, none . . . 

[MarkJames]

What controller are you referring to?  Do you mean the PLM?  If so it's purely not practical for me to do so.  There are a lot of lights and scenes that only work from the ISY - I could be waiting  a week or more for an ALL-ON event that may or may not come.

 

And are you saying that *any* of my legacy devices could be sending the ALL-ON message?  

 

 

mark

[MWoods329]

Hello Mark,

 

The ALL ON / ALL OFF has nothing to do with the 2413S PLM sending out this message. It doesn't matter what anyone tells you that is an empirical fact that many are simply not accepting.

 

One of the key problems which you can't avoid at the moment is you have lots of legacy hardware like me. Which does include the ALL ON / ALL OFF command class. So unless your willing to replace all your insteon hardware with new gear that is void of this command class expect to see this problem again.

 

I've asked countless people over the years to perform one simple test and that is to yank the controller out of the system and report back what happens.

 

As of this writing not one single person has ever done so, none . . .

 

Two comments, don't know if these will be of much use to anyone....

 

1. Out of total luck one time a week or so ago I had an All-ON event while I had the Event Viewer open and set to level 3 and I was sitting in front of my computer. Don't know if this addresses Teken's point about this controller (seems related), but I could see the PLM sending out the ON command to each and every Insteon device.

 

2. Recently, I came to agree with the opinion that it's not the PLM (maybe this is contradicting my last point). But; I have a long dark hallway that I wanted to make sure I caught any motion in so anyone leaving a bedroom would have the lights turned on for them. I erroneously thought the best way to do this would be to set up multiple motion sensors with overlapping coverage. I also set PLM communication to 1 Retry on each, as well as the switches which I had set up as a virtual 3 way.

The more aggressive I got about overlapping coverage of the area, the more frequently I got All On events. In fact, every All On event occurred when someone was in that hallway.

Looking at just the common factors; I decided to remove some of the motion sensors so that there was no overlap. I also set PLM communication to No Retries.

Haven't had an All-On event since.

[MarkJames]

(maybe this is contradicting my last point). 

 

 

I don't think it contradicts it but rather supplements it.

 

It seems to me that the only device in the network that has access to every other device is the PLM.  That's the only one that should have matching links for each device itself as well as the only one that each device should have a link for. 

 

Now I'm working under the assumption that the ALL-ON command (whatever its nature) still obeys the controller-responder link relationship.  If that's not true then all bets are off.  I guess it could be determined by plugging in a device, not linking it to the PLM, and seeing if it turns on in response too.  

 

What I would suspect is that the motion sensor you had the problem with is causing the PLM to send the ALL-ON.  

 

Of course this is all SWAG (scientific wild-assed guessing) so there you go.

 

In the meantime I think it's safe to say that the PLM prior to 9E WAS the cause of the ALL-ON event.  When I replaced my earlier version with the 9E my ALL-ON's stopped for at least a few months without changing a single other thing.  If there's another cause for this besides the PLM I'd like to know what the technical nature of it could be as I've exhausted all the 'guesses' out there (motion sensors, looping, etc.)

 

mark

[MWoods329]

I guess it could be determined by plugging in a device, not linking it to the PLM, and seeing if it turns on in response too.

 

mark

 

Can confirm - I have an Insteon switch which was directly linked to another switch but never linked to the PLM.

The one never linked to the PLM has never turned on in an ALL-ON event.

[MWareman]

Can confirm - I have an Insteon switch which was directly linked to another switch but never linked to the PLM.

The one never linked to the PLM has never turned on in an ALL-ON event.

What version is the switch? All newer ones don't have the all-on code in them.

 

Best to switch it around with another device that is an known all-on sufferer and reproduce. That way you know for sure.

[MarkJames]

Interesting....

 

Well - I realized that I do have one wireless device - a motion sensor that I use for dusk/dawn detection.  I removed it and have set up my Homeseer app to inform ISY when sunrise and sunset is.  I guess I'll see if it was the one little wireless guy that was doing this.  The log doesn't show it sending anything prior to the ALL-ON events but I got nothing else to try.

 

Thanks for the input!

 

mark

[MarkJames]

Hey Mike!

 

When you say 'don't have the all-on code' in them do you mean that the firmware does not contain code to SEND an ALL-ON command or does not contain code to RECEIVE an ALL-ON command?

 

I've got a LOT of devices - nearly 150 now.  Some of them are less than 6 months old so they would (I hope) have the most recent firmware.  These new ones STILL turned on in the most recent ALL-ON event so if there is a code change it would have to be in what these send - not what they respond to.

 

mark

[MWoods329]

What version is the switch? All newer ones don't have the all-on code in them.

 

Best to switch it around with another device that is an known all-on sufferer and reproduce. That way you know for sure.

 

It's one of the old ones. 2476D. RF-only.

Don't recall the firmware version but I can pull the switch plate off and take a look if that helps further the learnings here.

[MWoods329]

What version is the switch? All newer ones don't have the all-on code in them.

 

Best to switch it around with another device that is an known all-on sufferer and reproduce. That way you know for sure.

I second the question about "don't have the all-on code" comment.

All of my new devices have been impacted by the all-on as well as the old devices (with the exception of the one not linked to the PLM).

[MWoods329]

Interesting....

 

Well - I realized that I do have one wireless device - a motion sensor that I use for dusk/dawn detection. I removed it and have set up my Homeseer app to inform ISY when sunrise and sunset is. I guess I'll see if it was the one little wireless guy that was doing this. The log doesn't show it sending anything prior to the ALL-ON events but I got nothing else to try.

 

Thanks for the input!

 

mark

Do you have a list of all your devices that you can post? I've been dying to do a correlation analysis of devices in common.

[MarkJames]

Do you have a list of all your devices that you can post? I've been dying to do a correlation analysis of devices in common.

 

For you, Mike?  I even made it purty.  There are a few devices missing.  Couple of EZFloras are waiting new PLM's and I've had some device failures where I've started replacing them with old-fashioned on-off switches (I know - scary, huh?)

 

https://1drv.ms/i/s!Aq5Z1mepjZh3gbdcNEBKdlx1qYgTHw