Splitting IoX instance into two

[johnnyt]

I'm considering splitting up my eISY workload into 2 separate (smaller) IoX instances - one that will continue to run on the same eISY, and one that will run on a currently unused Polisy. I'm hoping to get some help understanding what might be missing in the migration steps I list below, as well as if something simply won't work the way I'm expecting it to work (most notably on the Insteon side). 

For those curious about my motivations, I've attached more info with context and some of the reasons for wanting to do this (which is not the focus for this thread)

 

Before getting into the migration steps, here are a few important notes about the plan:

- A key element of my plan is to use a remote eISY (connected through a VPN but completely disconnected from my Insteon and Zwave devices) to pare down my 'prod' IoX into its two distinct (smaller) "images" that I would then restore onto my existing main eISY and a 'blank' Polisy respectively as an initial load that would take me 90% of the way there.

- On the zwave side, I know I would need to exclude/include any/all zwave devices (and fix a bunch of programs) that I now want to control using the IoX instance on the blank Polisy, a.k.a IoP (with a separate Zwave dongle). That's fine as there are only a handful of them. The Polisy will be controlling mostly Insteon stuff.

- What isn't clear to me is whether I can avoid having to unlink/relink all the Insteon devices and recreate all the scenes that I now want to control using IoP. One veteran opinion I got was that I may not have to but it hasn't been proven so to be safe I should plan to start over.  If I did have to unlink/relink everything, the cost would be high and it would pour a lot of cold water on this idea pretty quickly. 

My own assumption - and it's a critical one - is that, because Insteon linking uses the hardware's address directly (xx.xx.xx), unlike zwave which creates an arbitrary logical address (e.g. ZY001), I would just be able to do a "Restore PLM" on IoP (with new/blank PLM) and everything will simply work on IoP as they did on the eISY's IoX instance. 

Stated more explicitly, a Restore PLM on IoP would simply go to every device it knows about using the xx.xx.xx address it has for it and tell those devices that it is now the PLM in charge. Any Insteon devices that I would have deleted when creating the IoP "image" (half a dozen or so) will simply not be queried/updated by IoP since it doesn't have those devices in the PLM table it maintains. The latter devices would therefore still continue to respond to the main eISY/PLM combo.

If this assumption is wrong I'd like to know why it doesn't work this way. What am I not understanding about how insteon and "Restore PLM" works?

Assuming that my assumption is correct, below are the steps I put together for splitting an IoX instance into two.

Note that the image creation prep work (Phase 1) has been tested/refined using my remote eISY. Everything worked as described below and the fixing/cleanup involved was very manageable. Also, all my devices and programs have been organized by folders according to their intended destination, i.e. "eISY" vs "Polisy", to make the deletion process really easy.

Phase 1 - Prep work using a remote eISY with its own PLM/zwave

Create Polisy 2.0 starter image 
1. load current prod eISY backup onto remote eISY
2. restore zwave & disable automatic writing for Insteon
3. delete eISY related programs folder 
4. delete eISY related devices folder (mostly zwave with a few Insteon)
5. Zwave | Synchronize | New & Deleted
6. Remove Failed Nodes for all the deleted devices now appearing in root folder
7. take zwave and IoX backup for use in phase 2

Create eISY 2.0 starter image (with only a handful of Insteon devices)
8. load current prod eISY backup onto remote eISY
9. restore zwave & disable automatic writing for Insteon
10. delete Polisy related programs folder 
11. delete Polisy related devices folder (mostly Insteon with a few zwave)
12. Zwave | Synchronize | New & Deleted
13. Remove Failed Nodes for all the deleted devices now appearing in root folder
14. take zwave and IoX backup for use in phase 2

Phase 2 - Deployment (starting with Polisy)

15. shutdown prod eISY and unplug its PLM
16. power ON Polisy (with its own PLM/zwave)
17. load Polisy 2.0 starter image
18. restore zwave & disable automatic writing for Insteon
19. exclude zwave devices that are needed on Polisy (and still exist in the image)
20. factory reset zwave dongle (to start clean)
22. re-include zwave devices that are needed on Polisy
23. fix programs
24. Restore PLM
25. shutdown Polisy while eISY is being updated

26. plug in PLM and power ON prod eISY
27. load eISY 2.0 starter image
28. restore zwave backup
29. restore PLM
30. Zwave | Network | Heal Network

Anyone ever do something like this? Any thoughts/comments on whether this should work? Any missing or out-of-order steps?

 

whysplit.txt

[larryllix]

On 3/20/2025 at 12:18 PM, johnnyt said:

I'm considering splitting up my eISY workload into 2 separate (smaller) IoX instances - one that will continue to run on the same eISY, and one that will run on a currently unused Polisy. 

I attempted this when I moved from ISY994 to polisy.

I found most of it wasn't worth it but I think it may work with one CapU handling all Insteon comm devices while the other handled all WiFi and other protocols.

The comm protocols are the bottleneck for the PLM and multiple PLMs will not help due to echoing them all over the house.

It is easy to comm between ISY devices using Network resources talking to the other cpu device. Bidirectional gets a little trickier.

Sent from my SM-S711W using Tapatalk
 

[johnnyt]

12 hours ago, larryllix said:

I attempted this when I moved from ISY994 to polisy.

I found most of it wasn't worth it but I think it may work with one CapU handling all Insteon comm devices while the other handled all WiFi and other protocols.

The comm protocols are the bottleneck for the PLM and multiple PLMs will not help due to echoing them all over the house.

It is easy to comm between ISY devices using Network resources talking to the other cpu device. Bidirectional gets a little trickier.

Sent from my SM-S711W using Tapatalk
 

Thanks @larryllix. You raise a good point of discussion about doing this. I did post not long ago looking for recent feedback/experience on having 2 insteon and 2 zwave networks co-existing together. While there hasn't been any confirmation there that it works (or doesn't) as of the time I write this, it did get a comment from a long time user that supported my own understanding that it should work.

I also recall a long time ago (pre zwave 994i days) asking if having 2 insteon networks works, and the answers I got from several people, including UD Support, were basically "yes but you have to know what you're doing". You'll see in that other thread I do ask if someone can confirm whether both insteon networks are helping each other by passing all messages on, what I assume you mean by "echoing", which is how I think it would work. No one has answered that yet so if you know from experience whether/how it works, can you elaborate on that in the other thread?

Thanks again

 

 

[Guy Lavoie]

5 minutes ago, johnnyt said:

I do ask if someone can confirm whether both insteon networks are helping each other by passing all messages on, what I assume you mean by "echoing", which is how I think it would work. No one has answered that yet so if you know from experience whether/how it works, can you elaborate on that in the other thread?

 

That's a question that comes up now and then. I don't have an official answer but my theory on it is that yes, messages would be passed on. Contrary to Zwave and other networks where devices are "included" into the network, Insteon is based on direct links between devices that need to talk to each other. There are no required links to intermediate devices to create the mesh network. It is a well known practice to use lamplincs to help powerline only modules like the iolinc with reliability, even though you don't need to set up any links to the lamplinc itself. Even Insteon (the company) mentions doing that as a workaround in their recent webinar.