johnnyt

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

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

Updated my Polisy today, which was at latest I could get before this update, i.e. 13.2 and 5.8.4, and it worked fine. I was an early buyer of the Polisy but I went through the pain of getting updated BIOS, etc. some time ago. I made some popcorn and watched it happening in real time by opening a Putty session and typing in: sudo tail -f /var/udx/logs/log It did appear to skip some things (like OS upgrade) the first time around to do some other things first then go back to do the things it skipped, with long pauses along the way so that's why I guess it takes a while. Guessing 15 mins in my case. I saw a lot of messages about things not needed or up to date, so that helped timewise in this case.

Thanks for that bit of info. Can anyone confirm my understand that all insteon signals from both insteon networks will be repeated for all to hear? Also, do zwave repeaters (built solely for that) repeat signals from both zwave networks or just the ones they see when initially powered on? Finally, anyone actually have experience with this?

Yes, it works. Thank you!

I'd like to push the content of a variable from one eISY/IoX to a second one. I know how to push a static value, such as '1', to a variable on the second IoX using Network Resources and REST but can't find how to send the dynamic content of a variable. Is there a way to, in effect, have the contents of a variable end up where the '1' is at the end of the "Path" in the screenshot below? I didn't see a way here https://wiki.universal-devices.com/ISY_Developers:API:REST_Interface#Networking I also browsed the documentation on SOAP API, which has a Get Variable option, but I can't find info/examples of if/how I can use Network Resources to achieve my objective using SOAP API instead of REST.

I want to separate my workload (~1400 programs, 751 total nodes, 328 Zwave, 179 Insteon) from one eISY to two eISY's, one for lighting, one for HVAC. Lighting is mostly Insteon with some zwave, while HVAC is mostly Zwave with some Insteon. I don't have any ZMatter or Zigbee at this point but may want to add some in the future. While I've seen Insteon and Zwave co-exist with a couple of test devices using a separate Polisy I have for testing and as a backup in case my eISY fails, I'm wondering if it will scale, particularly for Zwave and Zmatter/Zigbee when devices are spread out further away from their respective controllers, and particularly if there are only a few devices on the 2nd controller For Insteon, I believe all devices repeat all insteon signals no matter which controller/PLM is sending/receiving, meaning both Insteon networks will help each other. (Please correct me if I'm wrong) - Can the same be said about Zwave? As I understand it, I would end up with two separate Zwave networks that will NOT help each other. - What about with Zigbee/ZMatter? Also, worse than not helping each other if that's the case, could/will devices from separate networks actually interfere with each other? Any info would be appreciated.

the CL command to change the log size does not work using SSH lowercase either

Not surprised. So how do I increase the log size in eISY? My log file rotates after about a day and a half and getting at and reading the old files for days past is a PIA.

Am trying to increase my log file file size using the CL command outlined here https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Advanced_Configuration_Guide by telnet'ing into eISY following the instructions here https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Quick_Start_Guide#Connecting_to_the_ISY_Shell but I get a message "Could not open connection..." Is this an outdated way of doing it? Is there a way to do this using Putty/SSH (which is working fine)?

I make *extensive* use of this capability. I don't know how people troubleshoot anything more than simple problems with just the log and error log. (Full disclosure: I have over 1300 programs) I just wish I didn't have to click every small '+' sign to get to the folder where the files are each time I go to the web server tab. I also wish there was a better folder view with last changed date/time, file size, and files sortable by those various columns. Be aware that the data is NOT backed up as part of the backup function. You need to go pull the files manually and it's a bit of a process because they are in a folder with restricted access.

I removed an airthings device by deleting it using the plug-in config page and after that the following error kept happening every short poll: 2024-09-22 13:24:04.648 Thread-107 (handler_poll) udi_interface ERROR pgSession:response: Not Found: https://ext-api.airthings.com/v1//devices/3220001054/latest-samples: text: {"error":"NOT_FOUND","error_description":"segment for user <myapikey> does not exist"} 2024-09-22 13:24:04.648 Thread-107 (handler_poll) udi_interface ERROR Controller:api_get: failed to parse res={'code': 404, 'data': {'error': 'NOT_FOUND', 'error_description': 'segment for user <myapikey> does not exist'}} Traceback (most recent call last): File "/var/polyglot/pg3/ns/<myeisy>_8/nodes/Controller.py", line 251, in api_get LOGGER.warning(f"Service returned code {code} {res['data']['message']}") ~~~~~~~~~~~^^^^^^^^^^^ This caused the "server status" in IoX to become false and it triggered a program to notify me of that every short poll. I didn't notice until I checked my email later to see an inbox full of notifications. It's like the polling temporarily changes the status to something other than false but then back to false, causing the program to trigger each time. IMO, I should have only received one notification when it went false the first time. The problem stopped after I restarted the plug-in but I'd suggest that, if possible, some cleaning up could be done within the plug-in when one deletes a node so one does not have to restart to avoid this error. Alternatively the plug-in could restart itself (if that's possible) or a message to restart the plug-in could be provided, although these are less elegant solutions. The problem with restarts is that they reset the polling timer to zero, which causes the API limit to be reached. Of course this is not critical. Just something to maybe consider the next time the plug-in is opened up for changes. Thanks for all the good work you've done on this plug-in to make using these devices in my automation possible.

The other error has not re-occurred. Maybe I just needed to reboot/restart PG3. (I did a reboot)

It happened again the night after I installed 1.2.2 so I went in and turned on debug log level (because the reinstall returned log level to warning only) but it hasn't happened since. Maybe I needed to restart PG3, which I think I did later the next day. Anyway, all is good now. Thanks

Hold on publishing that change. I got a ton of these errors last night again, which you suggested was fixed in 1.2.2: Have turned on debug level for logs - hopefully it happens again soon. Could be tonight because it's been happening almost daily since I reported it. It requires a restart, which then causes API limit to be reached not long after the restart. I wish there was a way to stop/start plug-in from IoX so I could heal things programmatically instead of manually.