Multiple PLMs

[Hurting2Ride]

I searched and didn't find anything so if this ends up a dup request I apologize in advance and please point me in the right direction. ?‍♂️

Is there anywhere on the roadmap where the ISY will support multiple PLMs simultaneously?  My main concern is with the failure issues around PLMs it would be fantastic if a 2nd PLM could be attached to the system where 

 1) My primary reasoning: the system maintains the 2nd PLM's links to keep them in sync with the main PLM.  In the event of a failure on the 1st PLM, the system could switch or be switched over to the second PLM in a matter of moments without having to go through a replace & restore process (that hopefully goes smoothly) during peak WAF.
 
      plus other potential benefits such as 

2) the ISY could split the links to devices between the PLMs in order to "speed up" the processing of Insteon commands by splitting the traffic?

3) the ISY could maintain the full links set of off both PLMs  in order to "speed up" the processing of Insteon commands by utilizing "fastest trip" or "most reliable" between the two PLMs?

4) work around the 1024 link max native to Insteon?

5) others?

[lilyoyo1]

3 hours ago, Hurting2Ride said:

I searched and didn't find anything so if this ends up a dup request I apologize in advance and please point me in the right direction. ?‍♂️

Is there anywhere on the roadmap where the ISY will support multiple PLMs simultaneously?  My main concern is with the failure issues around PLMs it would be fantastic if a 2nd PLM could be attached to the system where 

 1) My primary reasoning: the system maintains the 2nd PLM's links to keep them in sync with the main PLM.  In the event of a failure on the 1st PLM, the system could switch or be switched over to the second PLM in a matter of moments without having to go through a replace & restore process (that hopefully goes smoothly) during peak WAF.
 
      plus other potential benefits such as 

2) the ISY could split the links to devices between the PLMs in order to "speed up" the processing of Insteon commands by splitting the traffic?

3) the ISY could maintain the full links set of off both PLMs  in order to "speed up" the processing of Insteon commands by utilizing "fastest trip" or "most reliable" between the two PLMs?

4) work around the 1024 link max native to Insteon?

5) others?

The isy isn't the issue here with what you're asking. Most of it would be the insteon protocol itself and how it works. I'll explain each line to better help you understand the limitations and why it's a protocol situation vs. an Isy situation.

1) technically what you're asking for can be done now. Simply turn off your Isy, hook up the second plm, run restore plm/restore devices. This would save the link table in the new plm while the old one would still have it. The downside would be with the devices trying to communicate with it. Unless it was plugged in, your network would slow down simply from devices trying to report to the plm and not getting a response. To prevent that you would need to leave the plm plugged in exposing it to the very thing you're trying to prevent. 

2) Most likely with 2 plms going at the same time, you'll have more problems than you solve. Due to the way devices communicate, the potential for collisions and excess traffic would be exponentially greater. This could slow things down to a crawl. An extremely slow system daily is much worse than a couple hour restore once in a blue moon. 

3) The cause of most insteon communication issues is the powerline signal rather than the plm itself not working. Since interference can manifest in different ways, the ISY would need to constantly "test" to determine the fastest and most reliable. This would mean constant communication which would slow things down even more. Since interference can also crop up at any time, it would need to test prior to sending out a signal. In the time it takes for the isy to test both plms to see which has less noise the signal could have already been sent and received by the device. While this method would technically make the signal more reliable, the sacrifice in speed would likely negate any benefit of it. Also since insteon broadcasts it's messages (all devices repeat the signal), the path the plm chooses is irrelevant. What you're asking for would benefit something like zwave which uses routed messages.

4) 2 plms wouldn't work around the max link. In order to "hot swap" device links would need to already be stored in both plms. If 1 is already maxed out the second one would be as well defeating the whole purpose.

 

[MWareman]

Adding to this, the PLM address is stored in every device, and the device can only report its status to the one PLM it’s configured to report to via the link table.

In any changeover, it’s necessary to write the new PLM address to each link on every device. No way around that.

[Hurting2Ride]

On 3/25/2019 at 1:20 AM, lilyoyo1 said:

The isy isn't the issue here with what you're asking. Most of it would be the insteon protocol itself and how it works. I'll explain each line to better help you understand the limitations and why it's a protocol situation vs. an Isy situation.

Thank you.

On 3/25/2019 at 1:20 AM, lilyoyo1 said:

1) technically what you're asking for can be done now. Simply turn off your Isy, hook up the second plm, run restore plm/restore devices. This would save the link table in the new plm while the old one would still have it. The downside would be with the devices trying to communicate with it. Unless it was plugged in, your network would slow down simply from devices trying to report to the plm and not getting a response. To prevent that you would need to leave the plm plugged in exposing it to the very thing you're trying to prevent. 

I wasn't sure if there was a way around the duplicate links issue.  My thinking here was if the situation was a PLM "waiting in the wings" then it could (theoretically) be on a UPS. 

On 3/25/2019 at 1:20 AM, lilyoyo1 said:

2) Most likely with 2 plms going at the same time, you'll have more problems than you solve. Due to the way devices communicate, the potential for collisions and excess traffic would be exponentially greater. This could slow things down to a crawl. An extremely slow system daily is much worse than a couple hour restore once in a blue moon. 

At first I figured this would be a problem, then started guessing why it might still be viable if an 80/20 type situation existed where a small number of devices cause the a majority of the drops or slowdown.  But as per your point about routed messages below...not so much.

On 3/25/2019 at 1:20 AM, lilyoyo1 said:

3) The cause of most insteon communication issues is the powerline signal rather than the plm itself not working. Since interference can manifest in different ways, the ISY would need to constantly "test" to determine the fastest and most reliable. This would mean constant communication which would slow things down even more. Since interference can also crop up at any time, it would need to test prior to sending out a signal. In the time it takes for the isy to test both plms to see which has less noise the signal could have already been sent and received by the device. While this method would technically make the signal more reliable, the sacrifice in speed would likely negate any benefit of it. Also since insteon broadcasts it's messages (all devices repeat the signal), the path the plm chooses is irrelevant. What you're asking for would benefit something like zwave which uses routed messages.

Gotcha. 

On 3/25/2019 at 1:20 AM, lilyoyo1 said:

4) 2 plms wouldn't work around the max link. In order to "hot swap" device links would need to already be stored in both plms. If 1 is already maxed out the second one would be as well defeating the whole purpose.

This thought was for the scenario where the ISY would manage each of the PLMs as a separate network, especially in situations where there was good RF communication.  Except I keep forgetting that Insteon devices do not allow the PLC communication to be shut off.   And that as far as Insteon is concerned everything is just 1 big network.

I appreciate you taking the time to go through the list.