Fail-over ability with multiple PLM's

[BCreekDave]

For the next generation hardware and considering the known issues with the Smarthome PLM's, particularly the 2413S, it would be good to have a way to connect to two independent "hot" PLM's and be able to quickly switch connection to a standby PLM in the event of a primary PLM failure.  This functionality should also include email or SMS notification of the failed PLM.

 

When my particular PLM failed, the ISY 994 seemed to recognize it as it did post error messages.  Not sure that this happens in every case.  

 

You would probably have to program interval based interrogation of the primary (and secondary PLM for that matter) to verify that it was still functioning.

 

Right or wrong, people are using these systems more and more for critical monitoring-control applications such as leak detection and smoke alarm detection.  Since Smarthome does not seem to want to cooperate with UDI's desire to create more reliable in-house PLM, this may be the only way to ensure reliability.

 

Thank you for the great product.

 

Dave

[MWareman]

Failing over the plm will require new link records to be written to all devices - and manual intervention for all battery powered devices. It's just the way Insteon works - without a 'virtual' PLM (doesn't exist) able to inherit the address of the failed PLM there is no way to do any kind of failover.

[BCreekDave]

Hmm, I see what you mean. The only workaround would be to somehow clone the primary Plm's address, which is not possible I think as it is hard coded into the insteon chip. When my plm failed, I repaired it by recapping it. That's why I did not have to write new link records. Oh well.

 

 

Sent from using Tapatalk

[Grizzy]

Just wondering,

 

If all control was done via programs, there were not any scenes, and there were not any device to device links.

And

You had 2 separate ISY / PLM setups.

And

Every device was added to each setup

And

There was a state variable that determines if the program in which ISY actually executed.

OR

Maybe a power / isolation throw over relay that switched to the standby ISY / PLM on fail over.

And

A failure would flip the variable and cause the standby ISY to take control and remove control from the primary.

 

I realize it would mean giving up some bells and whistles, but maybe for some folks having a fail over system is worth that. If this is possible it requires absolute attention to detail to assure the ISY's are a mirror image of each other.

 

Oh well I'm probably missing something, but just thought I'd mention it as it has been a future concern of mine as well.

 

Don

[larryllix]

This could be done with duplicate ISY units and each with their own PLMs.

 

All programs and scenes would have to be duplicated in each ISY and programs be contained in a folder with an enabling variable.

 

One group of programs would, on a timed basis, send a token back and forth. If the token ceased to be sent both would change their variable to enable and disable their folders. The running ISY would then disable all it's running  programs and ISY2 would get enabled and continue.

 

Keeping the two units synchronised may take some thinking on this one. I worked with SCADA systems that ran using this method. One was in complete control and the other listened keeping it's database synchronised. A few variables would need to get duplicated and reciprocally synchronised using the REST interface and Network Modules. The Node method coming may help immensely.

 

Failing back to ISY1 can take some doing also but usually done under manual control.

[MWareman]

Main thing to watch out for - when ISY1 writes link records to any device, it will remove any link records it does not have native knowledge of (such as the records to ISY2's PLM). This would render ISY2 unable to control the devices.

 

You cannot add a device to one ISY/PLM without breaking its communication with another ISY/PLM.

[paulbates]

Dave

 

I've run two PLMs managing the same devices (for non DR reasons) and its a very slippery slope. Its a lot of work and validation each time you add devices, or change links in a device like a keypad or motion sensor. To be candid, its more likely that managing this approach on two PLMs on a regular basis will unintentionally cause more 'outages' than it is intended to prevent.

 

I would instead:

• Use a hardened, proven system like Elk to control those things like alarms that are more critical.
   
• Make sure that you are using the latest version of PLMs, which are reported to be of better quality, If you order a new PLM as a backup,swap it to be online and use the current PLM as the backup.
   
• Take preventative measures, like insuring your electrical system has some level of surge protection on it to lower the exposure to powerline based devices like the PLM, so that they don't get knocked out to begin with.
   

Paul

[BCreekDave]

Paul,

 

Thank you very much for your the benefit of your experience in response to my post. This is a good example of what makes the ISY system so strong. Not only the quality of the hardware, but the strong community support of the product.

 

I've taken what I consider reasonable measures to protect the devices by installing a whole house surge protector along with surge devices at the point of use. My only loss was several years ago when a lightening strike in the neighborhood entered via the cable TV line and took out the cable box and then went via the HDMI cable to take out a receiver and the HDMI port on the main TV.

 

I agree also with your suggestions concerning the Elk system for mission critical protection and safety devices. That's really what that system was built for. It is really obvious to me now after reading about the Insteon device reliability that it is really intended only for convenience items such as lighting. In not sure I would even trust it with temperature control.

Thanks again for the reply.

Dave

 

 

Sent from using Tapatalk

[paulbates]

You're welcome Dave. I think the ISY is a great system and reliable is a term I use for it. Reliable, though needs to be applied in a relative way. To your point, I think the underlying technology, Insteon, does a lot of great things and I do rely on it for HVAC, comfort and lighting management. 

 

For other things like the insteon smoke bridge.. I have that, I use it,.. but its not my primary solution. Its purpose is to shut off heaters on a CO alert, and shut off dampers and fans on a fire alert. I've never been able to test it thoroughly, and I'm going to guess that smartlabs does not consider it lab tested and managed primary alarm component. It has an important job, that's not a substitute for a dedicated alarm/fire protection system.

 

Paul

[larryllix]

For HVAC there is a definite difference between depending on Insteon and Insteon monitoring and tweaking the system.

 

Things like temperature setback and set up, as well as humidity control, ventilation  and air circulation, I would trust but never the main control over the heating fires. The consequences of mishaps has to be weighed.

 

Then is the potential of hackers.....

[junkycosmos]

Insteon or Zwave enabled Tstats going to Zone control board works well here.  

 

Zone board hardwired on furnace provides hardware smarts that override the silly things the stats have done in the past (one heat one cool at same time) ... also the zone board on the furnace provides dead min / max temps.    For example on Heat Pump systems you can wire an I/O link into an additional zone input on EM heat to control gas/electric fail back but the zone board will override if temps are too low and the i/o linc is set incorrect. 

 

If someone does eventually figure out this dual PLM business that would be really interesting, Even if it took 2 ISYs connected together (ouch costly) but I bet there are some 'power' users here who really might like the idea of being able to have a PLM burn up and not having to immediately loose the entire network.