Due to the random ALL ON event issue, I may have to remove the ISY control box from my setup.  We have a very dangerous event happen today due to this (garage door opened by itself, whole house fan turned on with windows closed), and my wife is none to happy with me. If we had not been home, it would have been bad.  So I need a safe backup plan.   I know I will lose all programming as well as ELK integration, but there may be no choice.  So, that raises the question of how to do it?  I want to keep all of the linkages and scenes if possible.  Can I just power down the ISY and keep the PLM plugged in?  I assume all scenes will continue to work, right?

 

If I do need to unplug the PLM, should I just do a PLM remove in ISY before disconnecting the ISY?  Otherwise, my switches will try to talk to the PLM and when they get no answer will do that funny blinking to show the comm error.  

 

I guess I will keep the ISY for modifying scenes (much easier than doing from the switches) and for if/when the ALL ON issue is resolved.  

 

Thanks,

 

Blueman2

Edited March 10, 201510 yr by blueman2

I hope you can get the All On fixed without having to abandon your ISY setup, but do understand the possible need to do it.

The Delete Modem function will remove the PLMs ID from all the Insteon Modules.

Listed on this wiki page.

http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:File_Menu&redirect=no#Delete_Modem_.28PLM.29

Edited March 10, 201510 yr by Brian H

Worth mentioning, since the all-on is triggered by the motion sensor (or other activated device), it cannot happen when nobody is home! Also, Insteon is not secure. Relying on it for access control is not safe regardless.

 

The delete modem will remove the links, and you will have to revert back to managing links from the switches.

 

A better approach may be to disable all programs until the all-on is resolved.

Edited March 10, 201510 yr by MWareman

Where is the "All-On" command in the ISY994i?

 

This may have been handy for use in some programs.

Edited March 10, 201510 yr by larryllix

Where is the "All-On" command in the ISY994i?

 

This may have been handy for use in some programs.

 

Pick your top level scene that has all of your devices in it.  Turn it on.  Additionally, there is an All On and All Off button on the main scene at the bottom of the console. 

 

-Xathros

Pick your top level scene that has all of your devices in it.  Turn it on.  Additionally, there is an All On and All Off button on the main scene at the bottom of the console. 

 

-Xathros

That was probably the a scene I deleted from the ISY on first running and haven't seen it since. I have also tried many times to rid myself of some ADR thing that consumes space but with no success.

 

Why would one scene become a problem being randomly initiated?

Maybe start with less harsh steps? Like disable all programs and enable one by one slowly?

It's actually not the ISY randomly sending an All On to a scene.  It appers to be a collision/corruption of an insteon message that looks to all of the responders like an AllOn message.  See this thread for more: http://forum.universal-devices.com/topic/10516-random-all-on-event/

 

-Xathros

blueman2

 

If not happy with disabling Programs or not able to correct the conflicts, unplug the ISY.  Leave the PLM connected.  Be sure to take/have a current ISY Backup before unplugging ISY.  A Delete Modem (PLM) prevents using the ISY for device/Scene management.  

Great input, guys.  I would normally agree that taking a step by step approach to debugging is the way to go, and would normally just delete programs that I suspect cause the issue, or delete them all and add them back one by one.  That is what debugging is all about.  But my concerns are:

 

1) We apparently do not really know the full root cause of this.  So any action we take is only a guess.  

2) Some of us have devices controlled by Insteon that are a danger if they turn themselves on without warning and stay on

 

Given the safety issue involved here, guessing is really not good enough.  I only see 2 options

 

1) remove any device from Insteon control that I am not comfortable turning itself on at any time of the day and staying on indefinitely if I am traveling

2) remove my ISY

 

Frankly, I am not sure there is enough value left to ISY if I have to go with step 1.  But definitely something to consider down the road.  Option #2 seems the only prudent option. 

 

Folks, we are talking SAFETY here.  I don't want to have to 'debug' safety related issues.  Too much risk.  Either UD/ISY or Insteon (or both) needs to make a very public disclosure about this issue and fast.  Also, Smarthome needs to stop selling Garage Modules immediately if their system is not safe for access control.  And they need to disclose that none of their switches or devices should be installed on a device that cannot safely turn itself on at any time and remain on indefinitely if no one is home.    

Edited March 10, 201510 yr by blueman2

Great input, guys.  I would normally agree that taking a step by step approach to debugging is the way to go, and would normally just delete programs that I suspect cause the issue, or delete them all and add them back one by one.  That is what debugging is all about.  But my concerns are:

 

1) We apparently do not really know the full root cause of this.  So any action we take is only a guess.  

2) Some of us have devices controlled by Insteon that are a danger if they turn themselves on without warning and stay on

 

Given the safety issue involved here, guessing is really not good enough.  I only see 2 options

 

1) remove any device from Insteon control that I am not comfortable turning itself on at any time of the day and staying on indefinitely if I am traveling

2) remove my ISY

 

Frankly, I am not sure there is enough value left to ISY if I have to go with step 1.  But definitely something to consider down the road.  Option #2 seems the only prudent option. 

 

Folks, we are talking SAFETY here.  I don't want to have to 'debug' safety related issues.  Too much risk.  Either UD/ISY or Insteon (or both) needs to make a very public disclosure about this issue and fast.  Also, Smarkhome needs to stop selling Garage Modules immediately if their system is not safe for access control.  And they need to disclose that none of their switches or devices should be installed on a device that cannot safely turn itself on at any time and remain on indefinitely if no one is home.    

 

Blueman2,

 

If you have been here long enough and have read my past replies here and abroad the SH forum. You know I have no problem throwing Smartlabs / Smarthome under the bus when warranted.

 

Having said that, Smarthome / Smartlabs does not advertise their wares are security devices and makes in big bold print common sense and related hardware must be used at all times to ensure health and safety for all.

 

At this point the easiest thing to do is remove the ISY for awhile and sit and wait. If the ALL ON / ALL OFF comes back there are other outside factors causing this. I've asked many people to follow this simple yet effective line of thought and trouble shooting and not one has ever done so, none.

 

You will be the first to drop the hammer and see what happens.

 

The reality is as many have already stated this issue has never been seen before. Now, we see a smattering of people having this erratic behavior from time to time. As you may be aware the latest PLM v2.0 with firmware v.9E has removed the ALL ON / ALL OFF command from its table.

 

Yet this issue continues to persist this isn't a PLM issue at this point in time. Smartlabs is also in the middle of removing this command from all future Insteon devices also. The reality is if you remove both the controller / PLM and you still see this issue you have bigger worries moving forward. 

Great input, guys.  I would normally agree that taking a step by step approach to debugging is the way to go, and would normally just delete programs that I suspect cause the issue, or delete them all and add them back one by one.  That is what debugging is all about.  But my concerns are:

 

1) We apparently do not really know the full root cause of this.  So any action we take is only a guess.  

2) Some of us have devices controlled by Insteon that are a danger if they turn themselves on without warning and stay on

 

Given the safety issue involved here, guessing is really not good enough.  I only see 2 options

 

1) remove any device from Insteon control that I am not comfortable turning itself on at any time of the day and staying on indefinitely if I am traveling

2) remove my ISY

 

Frankly, I am not sure there is enough value left to ISY if I have to go with step 1.  But definitely something to consider down the road.  Option #2 seems the only prudent option. 

 

Folks, we are talking SAFETY here.  I don't want to have to 'debug' safety related issues.  Too much risk.  Either UD/ISY or Insteon (or both) needs to make a very public disclosure about this issue and fast.  Also, Smarkhome needs to stop selling Garage Modules immediately if their system is not safe for access control.  And they need to disclose that none of their switches or devices should be installed on a device that cannot safely turn itself on at any time and remain on indefinitely if no one is home.    

 Item #1 is the smart move.  I moved my garage doors off to an ethernet controlled relay (DIN Relay) that I can control from the ISY or directly if needed.  This eliminated my garage doors from being affected by an all on.  Since you have an Elk, I would recommend moving control of the garage off to the Elk.  Thats where it should be to begin with.  As for the whole house fan, I would consider a ZWave option for that or a load controller relay tied to the Elk.  Either way, you can maintain ISY control and eliminate the threat of an All On hitting those devices.

 

-Xathros

Teken, your points are well taken.  And anyone who is completely ignorant of safety, or who does not understand the risks we take in doing this type of 'hobby', simply should not be doing this type of 'hobby'.  

 

But what is the rationale for Smarthome to sell a Garage Door Controller?  You cannot sell a device you know is inherently unsafe, and then try to protect yourself by putting a label on it saying 'unsafe'.  Of course, there is not even that label.  All I have seen is a vague warning not to use unless someone is near to door to watch for safety.  I see nothing that says 'warning: do not use this on a garage door because it might open itself at any time'.  

 

Guys, this is a serious safety problem.  It needs to be well disclosed to consumers.  UDI and Smarthome have a responsibility here.  This problem has apparently been around for many months.  There should have been a very clear and LOUD disclosure before now about the safety issues involved with this bug.  

Edited March 10, 201510 yr by blueman2

Xathros,

 

just read your post.  You are 100% right.  This is exactly what I am going to do.  I am personally comfortable with any other device turning on and staying on.  But my garage door and whole house fan cannot. So I have already put my door on my ELK (it was a trivial switch over since both are in the garage), and will replace my whole house fan controller with a z-wave switch and leave it air-gap off until I do.  

 

But I still think UDI/Smarthome have a responsibility to quickly and fully disclose to all consumers the safety issue involved with this bug.  

Edited March 10, 201510 yr by blueman2

Teken, your points are well taken.  And anyone who is completely ignorant of safety, or who does not understand the risks we take in doing this type of 'hobby', simply should not be doing this type of 'hobby'.  

 

But what is the rationale for Smarthome to sell a Garage Door Controller?  You cannot sell a device you know is inherently unsafe, and then try to protect yourself by putting a label on it saying 'unsafe'.  Of course, there is not even that label.  All I have seen is a vague warning not to use unless someone is near to door to watch for safety.  I see nothing that says 'warning: do not use this on a garage door because it might open itself at any time'.  

 

Guys, this is a serious safety problem.  It needs to be well disclosed to consumers.  UDI and Smarthome have a responsibility here.  

 

Well, the reality is all of us are guilty in circumventing what isn't supposed to be there from the start. This time five years ago Liftmaster never had a remote access GDO, they do now. But, before that the GDO was line of sight and that was on purpose because you had to be in view of this device to operate it.

 

Given the massive emergence of remote connectivity this has cascaded in allowing all of us the ability to control almost anything in and around the home.

 

The GDO kit and its like has never been a endorsed piece of hardware from any GDO maker. We all simply did this so the fault is on the end user not the maker who simply wanted to fill a market space of wants.

 

Xathros suggestion is the best solution moving forward since you have the hardware in place. 

Edited March 10, 201510 yr by Teken

Something to keep in mind is that while Insteon-type products give you tremendous flexibility to make a system exactly how you want it, it is a trade-off as opposed to ready-made solutions that you just plug in without have to understand how it works. In doing so, you are also taking on the responsibility for the integrity/robustness of the code, as well as mitigating any IT security risks.

 

As to the garage door control, there seems to be mixed messages being sent, at least in my opinion. Smarthome, as well as Sears/Craftsman, Chamberlain, etc., all seem to market the wonderful convenience of never having to wonder if you left the door up, and being able to close it from anywhere in the world, if you did leave it open. But as others stated, the "fine print" included with these kits state that you shouldn't ever operate the door without watching it directly yourself. (I know some options include a webcam pointed at it so that you could see it operate).

 

 

It comes down to what the comfort level is for the individual, and what risks they're willing to accept - and being aware of them. As blueman2 noted above, I sure hope people aren't blissfully ignorant of the real risks that come with automating certain things.

 

Personally, I flatly refuse to connect my garage door control to a home automation system, particularly one that is Internet-facing. I may be paranoid, but I'd much rather keep the controls offline and not be subject to unforeseen scenarios that could arise from a goof in my code, or an online attack. I set it up for monitoring only.

blueman2

 

Your assumption this is a problem that applies generally would not be accurate. I've never seen an All On after years of running an ISY (actually two most of the time). RF devices send redundant commands without any knowledge of what may already be on the Insteon network. Knowing this I always add a delay in a Program triggered by RF device before issuing an Action that produces an Insteon message. Hard to prove a negative so no way to "prove" this is why I have never seen an All On.

blueman2

 

Your assumption this is a problem that applies generally would not be accurate. I've never seen an All On after years of running an ISY (actually two most of the time). RF devices send redundant commands without any knowledge of what may already be on the Insteon network. Knowing this I always add a delay in a Program triggered by RF device before issuing an Action that produces an Insteon message. Hard to prove a negative so no way to "prove" this is why I have never seen an All On.

 Thanks, Lee.  This probably should be in the Bugs thread in the other forum area, but in my case there was no RF device apparently involved.  I say apparently because I do have several RF devices, but they were not involved in any of the scenes that might have triggered the event based on the logs.  It was either a program looping itself (I am still investigating that) or a command from an ELK motion sensor (hard wired to the ELK) that somehow triggered the event.  I did recently install a DB device, but in another part of the house and apparently unrelated to this event.  Only thing that has changed was a new PLM the day before (my old one had a capacitor failure so I placed with a new v2.0 PLM.  Before that, I have 3 years of no issues.  

 

So I think it is fair to say that we are still not sure what is causing this.  We have working theories, but no hard proof.  Given that, I think prudence dictates we take a safe approach and assume this ALL ON event can happen anywhere at any time.  Over time, this bug will be resolved.  But until then, and until we are Five9s sure what the root cause is, we should all take the safe approach and assume it can happen.  

Edited March 11, 201510 yr by blueman2

Something to keep in mind is that while Insteon-type products give you tremendous flexibility to make a system exactly how you want it, it is a trade-off as opposed to ready-made solutions that you just plug in without have to understand how it works. In doing so, you are also taking on the responsibility for the integrity/robustness of the code, as well as mitigating any IT security risks.

 

As to the garage door control, there seems to be mixed messages being sent, at least in my opinion. Smarthome, as well as Sears/Craftsman, Chamberlain, etc., all seem to market the wonderful convenience of never having to wonder if you left the door up, and being able to close it from anywhere in the world, if you did leave it open. But as others stated, the "fine print" included with these kits state that you shouldn't ever operate the door without watching it directly yourself. (I know some options include a webcam pointed at it so that you could see it operate).

 

 

It comes down to what the comfort level is for the individual, and what risks they're willing to accept - and being aware of them. As blueman2 noted above, I sure hope people aren't blissfully ignorant of the real risks that come with automating certain things.

 

Personally, I flatly refuse to connect my garage door control to a home automation system, particularly one that is Internet-facing. I may be paranoid, but I'd much rather keep the controls offline and not be subject to unforeseen scenarios that could arise from a goof in my code, or an online attack. I set it up for monitoring only.

 

Agreed on many points listed above.

 

This is probably why I have waited so very long in integrating my HVAC to Insteon. Given I have seven T1800 at the ready for install they simply monitor temperature / humidity in specific zones in the home.

 

I live in the cold *** north and I can't allow anything to cut off the heat when its -45'C!

 

This is probably why I have spent so much time designing and integrating so many environmental fail overs that at some point will bolster the Insteon TSTAT to ensure there is always a 3rd party device collaborating the temperatures in and around the home.

 

Sometimes its the KISS principle we all should follow and adhere to. As much as I like to automate my life and my home there is a constant reminder some of this will be abused, or falter at some point. I am interested in seeing what the OP does moving forward with the ISY because this will be quite telling for those who follow.

....Sometimes its the KISS principle we all should follow and adhere to. As much as I like to automate my life and my home there is a constant reminder some of this will be abused, or falter at some point.

 

 

 

Yes, as I think you and I have laughingly traded posts on before, we all should take a page from Battlestar Galactica.  Integration and automation are all well and fine until they go horribly wrong!     

Yes, as I think you and I have laughingly traded posts on before, we all should take a page from Battlestar Galactica. Integration and automation are all well and fine until they go horribly wrong!

So say we all. . . [emoji4]

 

 

Ideals are peaceful - History is violent

Update.  I now have my Garage Door being controlled by ELK (should have done that long ago!), I have removed 80% of programs that were not critical, have added 1-2 second program delays where recommended in the master thread on the ALL ON bug, and have Air Gap shut off my whole house fan until summertime.  Given all these changes, I think I will be able to survive another ALL ON event should one occur.  Only issue I see is WAF.  If she gets woken up at 3:30am as has happened with some, or if it occurs when I am traveling, I will pretty much be forced to remove the ISY and perhaps even all the Insteon devices.  

 

Fingers crossed.  

I have had one all on event recently after adding a motion sensor to my system. The motion sensor turns on the laundry room lights which are controlled by a 6 button kpl. Michel posted that this is/may be related to a program or scene triggered by the load button of a kpl controlling a secondary button on the same Kpl. I thought these events were typically related to garage door control which I do not have (just an io linc sensor to tell me if the door is not closed). Fortunately I have not had a repeat of this. My plm is more than a year old so not the latest version.

We are all interested in solving this issue or at least figuring out the cause.

It's actually not the ISY randomly sending an All On to a scene.  It appers to be a collision/corruption of an insteon message that looks to all of the responders like an AllOn message.  See this thread for more: http://forum.universal-devices.com/topic/10516-random-all-on-event/

 

-Xathros

My belief is that some handshaking may not be functioning correctly.

 

There appears to be handshaking problems between MS units and the PLM or with the Insteon protocol, in general.

 

Here were some event recordings from an MS unit that was tying my system up for long periods of time. I don't pretend to understand it anymore or ever but it would seem that MS units not in scenes never get their signals acknowledged and keep retrying, jamming up the Insteon traffic.

http://forum.universal-devices.com/topic/14219-motion-sensors-2842-222-and-retries/

 

 

Also, I have found that some handshaking between the PLM and ISY may be missing. This is exampled by sending X10 codes and Insteon signals in sequence to find that some are just not ever transmitted. Since putting Waits behind every X10 command things work better.

 

Why does an ALL ON command even exist in Insteon? Perhaps a carry-over from X10?

Hello blueman2,

 

Please review my other post with steps to drastically reduce the probability and possibly completely eliminate these events.

 

As far as disclaimer, all ISYs come with a disclaimer the copy of which is also here:

http://www.universal-devices.com/prod-disclaimer.pdf

 

The same disclaimer is presented the first time you access ISY and you must have agreed to it otherwise you would get prompted every time you access the Admin Console.

 

The disclaimer explicitly discusses use cases related to security and health.

 

Do I think the disclaimer is sufficient? Absolutely not. Folks get ISY to automate and garage doors are natural for automation. In an ideal world we would have found a fix alas it is out of our hands. This said - and again - extensive testing has been done and we do know when this happens and thus the recommendation.

 

With kind regards,

Michel