johnnyt

I noticed re-installing this plug-in overwrites the config. Got message about short poll. Change the poll values then nothing. it stopped updating. Had to restart plug-in to get polling working again. Maybe the restart is needed always after re-install. If so, could that be added to the documentation next time you're updating that? And could any existing configuration not get overwritten? Thanks for considering these things.

This morning I tried re-installing the plug-in in the slot that isn't showing up in the AC . Didn't fix the issue. Even after restarting both the plug-in and the AC and waiting a bit. Still nothing What is the next step in troubleshooting this?

at about 5:26 AM and 5:28 AM two of my three instances of the plug-in reported API Limit reached. They worked fine all day so I don't have them configured to poll too often. When I looked at the logs I see there were times that we flooded with warnings (up to 8 or more per second) and other errors. Things like: 2024-05-28 05:29:04,383 Thread-700 urllib3.connectionpool WARNING connectionpool:urlopen: Retrying (Retry(total=18, connect=30, read=28, redirect=None, status=None)) after connection broken by 'ReadTimeoutError("HTTPSConnectionPool(host='ext-api.airthings.com', port=443): Read timed out. (read timeout=10)")': /v1//devices/2930162741/latest-samples 2024-05-28 05:29:05,365 Thread-697 urllib3.connectionpool WARNING connectionpool:_put_conn: Connection pool is full, discarding connection: ext-api.airthings.com. Connection pool size: 10 2024-05-28 05:18:40,345 Thread-666 udi_interface ERROR pgSession:get: Connection error for https://ext-api.airthings.com/v1//devices/2930162741/latest-samples: HTTPSConnectionPool(host='ext-api.airthings.com', port=443): Max retries exceeded with url: /v1//devices/2930162741/latest-samples (Caused by ResponseError('too many 502 error responses')) 2024-05-28 05:28:04,528 Thread-547 udi_interface ERROR pgSession:response: Unauthorized: https://ext-api.airthings.com/v1//devices/2930162814/latest-samples: text: I didn't see anything about API limit reached so it seems to be an erroneous state got reported to IoX (which triggered an email to warn me). Maybe the flood of warnings lead to that? Would it be a good idea to put in a "wait" between retries to avoid possible race conditions, or at least reduce the clutter in the logs? (Unless there's value in having all of those entries.) Maybe there was a short break in service that affected 2 of the instances but not the third due to polling difference. The 3rd one did have a few warnings but maybe the break in service ended shortly after first few I've attached my 3 debug logs (one was only set to "Warning" level. I've changed it to "Info" for next time) Airthings-C_5-28-2024_62253_AM.zip Airthings-C_5-28-2024_62237_AM.zip Airthings-C_5-28-2024_61905_AM.zip

For what it's worth I tried flushing Java cache and restarting GUI (Admin Console) - still nothing for the one instance. So then I tried a another reboot (eISY) - still nothing. I see in the event viewer the following entries related to the plug-in in question. It seems like an incomplete update. I have 7 devices and just looking at "CO2LVL" and "BARPRES" there are only 4 of each one of those. A little later on there were 6. How come it's not 7 every time? I do see some of the new data values being received by IoX, e.g. GV5 (Seconds Since Seen), so it's an issue with GUI not adding the new element. Is this something I need to report to UDI support? Mon 05/27/2024 02:17:02 PM : [n008_s_2930037297] GV5 76 (uom=56 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930037297] CO2LVL 568 (uom=54 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930037297] BARPRES 9913 (uom=56 prec=1) Mon 05/27/2024 02:17:02 PM : [n008_s_2930037297] GV4 161 (uom=56 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930071732] GV2 1716833656 (uom=151 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930071732] GV5 169 (uom=56 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930071732] CO2LVL 528 (uom=54 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930071732] BARPRES 9913 (uom=56 prec=1) Mon 05/27/2024 02:17:02 PM : [n008_s_2930071732] GV4 106 (uom=56 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930029938] GV5 275 (uom=56 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930029938] GV3 -47 (uom=56 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930073475] GV5 266 (uom=56 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930073475] GV3 -60 (uom=56 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930033257] GV5 287 (uom=56 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930033257] GV3 -72 (uom=56 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930027997] GV2 1716833681 (uom=151 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930027997] GV5 144 (uom=56 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930027997] CO2LVL 526 (uom=54 prec=0) Mon 05/27/2024 02:17:02 PM : [n008_s_2930027997] BARPRES 9915 (uom=56 prec=1) Mon 05/27/2024 02:17:03 PM : [n008_s_2930027997] GV3 -60 (uom=56 prec=0) Mon 05/27/2024 02:17:03 PM : [n008_s_2930027997] CLITEMP 245 (uom=4 prec=1) Mon 05/27/2024 02:17:03 PM : [n008_s_2930027997] GV4 108 (uom=56 prec=0) Mon 05/27/2024 02:17:03 PM : [n008_s_2930206779] GV2 1716833605 (uom=151 prec=0) Mon 05/27/2024 02:17:03 PM : [n008_s_2930206779] GV5 220 (uom=56 prec=0) Mon 05/27/2024 02:17:03 PM : [n008_s_2930206779] CO2LVL 452 (uom=54 prec=0) Mon 05/27/2024 02:17:03 PM : [n008_s_2930206779] BARPRES 9919 (uom=56 prec=1) Mon 05/27/2024 02:17:03 PM : [n008_s_2930206779] GV3 -56 (uom=56 prec=0) Mon 05/27/2024 02:17:03 PM : [n008_s_2930206779] GV4 198 (uom=56 prec=0)

I restarted the IoX GUI - still nothing for one of the plug-in instances I don't see any data coming for the new nodes (or whatever you call those), e.g. GV6, ST, VOCLVL, with log at "Info" level

I have 3 instances of this plug-in running and was able to install new version for all three instances. The new info did not show up so I did the following, in order: 1. wait a bit. didn't do anything 2. restart each plug-in. nothing 3. re-launched IoX GUI - no joy 4. rebooted hardware - 2 of the three plug-ins now show the new data in IoX What is/are the step(s) needed after a re-install to get new info activated/passed on to IoX? If that fails, what is the step to force updates to be recognized and passed on to IoX? Am on PG3x 3.2.22 and IoX 5.8.3. Thanks

Wow. There's very confusing messaging going on. I read in other posts that the v3 plug-in is NOT using Onecall 2.5, which is the one that's end of life. It's using the free one from the "professional collections" offering. See circled item below in screenshot below It certainly looks from "My Services" in my account that I'm using the professional API (limited to 60 calls per min). Is this one coming of end of life any time soon? Can you confirm (deny) whether previous posts explaining this are correct?

Just wondering if one has to move to 4.0. From other posts I read here I got the sense things would still work for the foreseeable future using the current "professional API". Assuming one isn't forced to move to keep things working, what is the value of moving to the new OneCall 3.0 API? Of course, I presume that v3 of the plug-in will no longer see fixes and updates but I figure there's still time before that becomes an issue. Is that a fair assessment or are there some issues coming on the short term horizon? Also, I noticed when I went to subscribe to OneCall 3.0 API that it insists on my providing a credit card, even though I only want the free service and would want the service to stop working if some bug or accidental misconfiguration got introduced and the API got called more than 1000 times in one day. Is there a way around that I simply didn't see?

Hi @Jimbo.Automates, My perpetual license is not recognized meaning I would have to purchase another one to install v1.1.1. Is that the plan or do I need to talk to UDI support to get the new version to recognize my existing license? I did need to have the license transferred from my Polisy some time ago so maybe that has something to do with it?

the second example kind of worked but it returns more than just the serial number (e.g. 2930133445), which is all I want. It returns: node[n001_s_2930133445] With no "grep" function when creating custom messages, I have no way to take just the number I need out of the string created. So I guess I'll need to find a way to parse it out of the file after the fact if it's not easy to put it in as another device attribute. Not the end of the world.

How do I access node_name in a program, e.g. write it to a variable and/or write it to a file using custom messages and the built-in web server? It doesn't come up in the selection of options I see right now.

ok I change to the program logic (see below), with no variable in the condition - only the node state (True vs False) and each person having its own node and program but BOTH programs run every time I leave or come back. I've tried starting over 3 times now, i.e. delete both Geofences in UDM, resynchronize UDM, recreate separate Geofences, re-add command, i.e. "run then" for each command separately/respectively for each Geofence node. What am I doing wrong or not understanding? LT Enters Geofence - [ID 04A5][Parent 01E4] If 'Home / LT' Occupied is True Then Send Notification to 'me' content 'Generic Main Log' Wait 5 seconds $sHomeStatus.Lauren Init To 1 $sHomeStatus.Lauren = 1 Else - No Actions - (To add one, press 'Action') JT Enters Geofence - [ID 0499][Parent 01E4] If 'Home / JT' Occupied is True Then Send Notification to 'me' content 'Generic Main Log' Wait 5 seconds $sHomeStatus.Jean Init To 1 $sHomeStatus.Jean = 1 Else - No Actions - (To add one, press 'Action')

ok, I was clearly looking in wrong place when I tried to use a program initially because I only saw two options. When I look now I see all the normal options. So I will remove use of the variable now that I can call a program directly. Thanks.

I set up Geofencing on my iPhone a couple weeks ago and it works reliably so far. I used Occupancy v2.0 Node Server and followed the instructions found at https://wiki.universal-devices.com/index.php?title=UD_Mobile#Geofencing It took me a few tries to realize that the Enter command cannot be a program. May I suggest the doc on wiki make it clear what it could/needs to be? So what I did was have the Enter command change a state variable to 1, and the Exit command change the same state variable to 0. Then I wrote the two simple programs below for my wife and myself. For me it's worked fine so far but for my wife the "enter" program has triggered 4 times in past 4 days even though UD Mobile is not yet installed on her iPhone. For what it's worth there have been no Exit events, no eISY restarts, and no LAN/internet outage that anyone noticed. Before I start counting on this for locking/unlocking doors, turning off/on lights, and setting/disabling alarms, etc., what could be happening? Will a loss of communication with the UD mothership cause the "enter" program to run? Do I need to check that I have network connectivity before I do anything with a change in the node's state? Any info would be appreciated. Lauren Enters Geofence - [ID 04A5][Parent 01E4] If 'Home / Lauren' Occupied is True And $sHomeStatus.Lauren is 0 Then Send Notification to 'me' content 'Generic Main Log' Wait 5 seconds $sHomeStatus.Lauren Init To 1 $sHomeStatus.Lauren = 1 Else - No Actions - (To add one, press 'Action') Lauren Exists Geofence - [ID 04A6][Parent 01E4] If 'Home / Lauren' Occupied is False And $sHomeStatus.Lauren is 1 Then Send Notification to 'me' content 'Generic Main Log' Wait 5 seconds $sHomeStatus.Lauren Init To 0 $sHomeStatus.Lauren = 0 Else - No Actions - (To add one, press 'Action')

yes, I ended up rebooting and did yet another factory reset of the SS7. One thing I've found is that the SS7 do not exclude easily. Even Aeotec support said one often needs to "spam" the device by clicking it continuously during exclude process. I think that worked once for me, and this has been the case with two of them (not just one). So I've largely given up on exclude process for it and have been doing factory resets of it each time. I wonder, however, if I've been doing things wrong by doing a "Delete" of the device instead of a "Remove Failed Node". After I did the reboot and reopened the AC, I saw some previously deleted SS7 nodes had returned in the GUI. While the SS7 had been factory reset, maybe the Zwave dongle saw it as one of the previous nodes but not to the extent that reassigned/used that node. I've removed the remnants of failed nodes that showed up in AC (using "Remove Failed Node") and did a "Heal Network". I noticed it "healed" some devices that don't exist in AC and would have been numbers assigned to the SS7 (i.e. new node numbers). I restarted AC but those nodes still didn't show up in the AC even though the event viewer does report them as "healed". See attached screenshot -> In it the devices are sorted in reverse order, i.e. oldest nodes first, and you can see there's no sign of nodes 175, 176, 177 that were reported as "healed" in the event viewer.

I'm trying to "Update with Interview" an Aeotec Smart Switch 7 and have been getting "Waiting on interview complete" for over 90 mins since starting it. Attached is event viewer sample from 15 mins ago (process is still going on). The device has been hard to include - this is the 5th or 6th include. Either not all nodes get added, or the process fails with the green ">>>" symbol next to device, which "Write Updates" does not fix. I suspect hardware issue as I have had this and other SS7s include/work fine before. My question is how do I stop the interview process? The advanced "Stop adding or removing a Zwave device" doesn't work. I tried right clicking and doing "Remove failed node" but it fails to do that saying it's busy communicating with the device. Help! InterviewSuperLong.txt

Found the following in my logs while researching something else. Thought I would report it as instructed. Here are log entries from just before and after the error: 2024-04-07 10:12:20 info: NS: Player Volume: 44 2024-04-07 10:12:20 info: NS: Group Volume: 44 2024-04-07 10:12:20 info: POLY: Setting node 8326214 driver GV1: 44 2024-04-07 10:12:20 error: NS: uncaughtException REPORT THIS!: ReferenceError: finduuid is not defined at /var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/prototypes/Player/recalculateGroupVolume.js:7:9 at Array.find (<anonymous>) at /var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/prototypes/Player/recalculateGroupVolume.js:6:24 at Array.find (<anonymous>) at Player.recalculateGroupVolume (/var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/prototypes/Player/recalculateGroupVolume.js:5:30) at NotificationListener.notificationHandler (/var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/models/Player.js:370:25) at NotificationListener.emit (node:events:529:35) at /var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/NotificationListener.js:125:17 at process.processTicksAndRejections (node:internal/process/task_queues:95:5) 2024-04-07 10:12:20 error: POLY: uncaughtException: finduuid is not defined ReferenceError: finduuid is not defined at /var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/prototypes/Player/recalculateGroupVolume.js:7:9 at Array.find (<anonymous>) at /var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/prototypes/Player/recalculateGroupVolume.js:6:24 at Array.find (<anonymous>) at Player.recalculateGroupVolume (/var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/prototypes/Player/recalculateGroupVolume.js:5:30) at NotificationListener.notificationHandler (/var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/models/Player.js:370:25) at NotificationListener.emit (node:events:529:35) at /var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/NotificationListener.js:125:17 at process.processTicksAndRejections (node:internal/process/task_queues:95:5) 2024-04-07 10:12:20 error: NS: uncaughtException: finduuid is not defined ReferenceError: finduuid is not defined at /var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/prototypes/Player/recalculateGroupVolume.js:7:9 at Array.find (<anonymous>) at /var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/prototypes/Player/recalculateGroupVolume.js:6:24 at Array.find (<anonymous>) at Player.recalculateGroupVolume (/var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/prototypes/Player/recalculateGroupVolume.js:5:30) at NotificationListener.notificationHandler (/var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/models/Player.js:370:25) at NotificationListener.emit (node:events:529:35) at /var/polyglot/pg3/ns/<myISYMACaddr>d_3/node_modules/sonos-discovery/lib/NotificationListener.js:125:17 at process.processTicksAndRejections (node:internal/process/task_queues:95:5) 2024-04-07 10:12:24 info: NS: Starting Node Server 2024-04-07 10:12:24 info: POLY: Interface starting 2024-04-07 10:12:24 info: POLY: Getting config from environment 2024-04-07 10:12:24 info: POLY: MQTT client connected 2024-04-07 10:12:24 info: NS: MQTT Connection started 2024-04-07 10:12:24 error: POLY: Config has logLevel: INFO 2024-04-07 10:12:24 info: POLY: Loglevel: info 2024-04-07 10:12:24 info: NS: Config received has 7 nodes 2024-04-07 10:12:24 info: POLY: Setting node a980b70 driver GV0: 0 2024-04-07 10:12:24 info: POLY: Setting node a980b70 driver GV1: 0 2024-04-07 10:12:24 info: POLY: Setting node a980b70 driver GV7: 0 2024-04-07 10:12:24 info: POLY: Setting node a980b70 driver GV8: 0 2024-04-07 10:12:24 info: POLY: Setting node 8326214 driver GV0: 0 2024-04-07 10:12:24 info: POLY: Setting node 8326214 driver GV1: 0 2024-04-07 10:12:24 info: POLY: Setting node 8d9e68c driver GV0: 0 2024-04-07 10:12:24 info: POLY: Setting node 8d9e68c driver GV1: 0 2024-04-07 10:12:24 info: POLY: Setting node a980b70 driver GV0: 22 2024-04-07 10:12:24 info: POLY: Setting node 8d9e68c driver GV0: 50 2024-04-07 10:12:24 info: POLY: Setting node 831736c driver GV0: 0 2024-04-07 10:12:24 info: POLY: Setting node 831736c driver GV1: 0 2024-04-07 10:12:24 info: POLY: Setting node 831736c driver GV7: 0 2024-04-07 10:12:24 info: POLY: Setting node 831736c driver GV0: 50 2024-04-07 10:12:24 info: POLY: Setting node 75cc226 driver GV0: 0 2024-04-07 10:12:24 info: POLY: Setting node 75cc226 driver GV1: 0 2024-04-07 10:12:24 info: POLY: Setting node 8326214 driver GV0: 44 2024-04-07 10:12:25 info: POLY: Setting node 75cc226 driver GV0: 35 2024-04-07 10:12:29 info: NS: Discovering 2024-04-07 10:12:29 info: NS: Zone Coordinator: RINCON_B8E9377949FD01400 - Room TV Room 2024-04-07 10:12:29 info: NS: Members UUID: RINCON_B8E9377949FD01400, - Room: TV Room 2024-04-07 10:12:31 info: NS: Zone Coordinator: RINCON_7828CA980B7001400 - Room Portable 2 2024-04-07 10:12:31 info: NS: Members UUID: RINCON_7828CA980B7001400, - Room: Portable 2 2024-04-07 10:12:32 info: NS: Zone Coordinator: RINCON_000E58D9E68C01400 - Room Dining Room 2024-04-07 10:12:32 info: NS: Members UUID: RINCON_000E58D9E68C01400, - Room: Dining Room 2024-04-07 10:12:33 info: NS: Zone Coordinator: RINCON_000E5831736C01400 - Room Kitchen 2024-04-07 10:12:33 info: NS: Members UUID: RINCON_000E5831736C01400, - Room: Kitchen 2024-04-07 10:12:34 info: NS: Zone Coordinator: RINCON_B8E9375CC22601400 - Room Portable 2024-04-07 10:12:34 info: NS: Members UUID: RINCON_B8E9375CC22601400, - Room: Portable 2024-04-07 10:12:35 info: NS: Zone Coordinator: RINCON_000E5832621401400 - Room Rec Rm-Workshop 2024-04-07 10:12:35 info: NS: Members UUID: RINCON_000E5832621401400, - Room: Rec Rm-Workshop

I noticed a warning in plug-in log that this plug-in is using some deprecated stuff. Is it just a reporting issue? If not, will it be upgraded to remain compatible? Is it at or near end of life/support? What's the impact of this? 2024-03-17 09:40:07,331 MainThread udi_interface.interface INFO interface:__init__: Initialization received from Polyglot V3 3.2.20 [ISY: 5.8.0, Slot: 5] 2024-03-17 09:40:07,331 MainThread udi_interface.interface INFO interface:__init__: Connect: Network Interface: {'addr': '192.168.100.249', 'netmask': '255.255.255.0', 'broadcast': '192.168.100.255'} 2024-03-17 09:40:07,332 Interface udi_interface.interface INFO interface:_startMqtt: Connecting to MQTT... localhost:8883 2024-03-17 09:40:07,332 MainThread udi_interface.interface WARNING interface:start: No node server version specified. Using deprecated server.json version 2024-03-17 09:40:07,333 Interface udi_interface.interface INFO interface:_startMqtt: Using SSL cert: <myISYaddr>_5.cert key: <myISYaddr>_5.key ca: /usr/local/etc/ssl/certs/ud.ca.cert 2024-03-17 09:40:07,333 MainThread udi_interface INFO evldscns:<module>: Starting EnvisaLink DSC Nodeserver...

Oops, I should have posted this in the ST-Inventory forum. I pointed to the above in that forum so no need to answer here. I'm sure I'll get an answer over there.

Oops, I should have posted this question here

what version of ST-Inventory do you have as the latest? Am at v1.0.12 and don't have a message to upgrade but the change log for this latest version doesn't date the change or link it to this issue.

Oh I see. I ended up paying for portal access for the eisy (so didn't transfer that particular piece) because I plan to test some things that will need portal access on the Polisy once it's fixed. I might have to get support to fix this.

Following a major crash on my Polisy, I migrated everything to an eisy I had in part in case of just such an event. Is there a way to just swap everything in UD Mobile that is set up for my dead IoP to the eisy now driving everything? I added the eisy but all the favorites are for the IoP, and I don't see a "transfer" option. It appears I would need to delete the IoP (which I assume will clear the favorites) then recreate all my favorites for the eisy. Is there another way so I don't have to redo everything?

Thanks, @jec6613. It worked! One doesn't need a migration backup, a regular one will do, which makes sense and would be worth mentioning in user guide if anyone who can make changes to that is listening. Simply making it clear that a migration is only when moving from non-Zmatter to Zmatter would help because, to me, I was migrating from my Polisy to my eisy so was following that path. Here are the steps I followed that worked. Note that this is when one does NOT have access to "old" unit so can't do a backup but, of course, has a backup, including zwave, from hopefully not too long before disaster hit: 1. Power off old Polisy/eisy (or unplug/remove Zmatter) if it isn't already dead so the old zwave dongle isn't fighting with the new one. 2. On the new eisy (or Polisy) make sure to enable Insteon (if applicable) and Zwave support, do "Upgrade Packages", reboot and let it finish. Process is faster/cleaner on a 'blank' eisy than on a fully configured one but can still take a while. (at >283 zwave nodes, 180 Insteon nodes, and >1100 programs, a reboot for me takes almost 10 mins.) 3. I did a shutdown of new eisy here but not sure it's required. I used SSH but on eisy you can push button 6 times (on Polisy its 3 times) to shutdown. 4. Move PLM over, restore IoX, which results in a restart / need to re-login, restore Zwave, which did not need a restart, restore PG3, and reboot (PG3 said it needed a reboot) 5. Deal with fact that NS/plug-in licenses are tied to hardware and won't be active on your restored unit (although they will be there) I've asked UDI to transfer the licenses over to new eisy because I won't need them on my Polisy anymore. Once it's fixed, it will become my lab/test unit and a 'cold backup' for any future disaster recovery 6. If applicable deal with things that changed after your backup was taken. (nothing in my case that I can fix. I did lose all my web server files (couple months of data), because they don't get backed up as part of IoX backup. A reminder than I have to do separate manual backup of those more frequently. I also lost a couple of days of variable values that are long term counters (e.g. furnace filter use, etc.) Now just waiting for response from UDI Support about fixing my dead Polisy. Turns out it's missing /var/udx - a key folder - and the disk is 100% full (every mount point at 100% except /tmpfs). Not good - guessing fixing it will take a while and maybe that's why they haven't responding yet. At any rate I'm really glad my Disaster Recovery plan worked out. I've had duplicate hardware for a while but hadn't tested it yet. Too worried it would be fiddly but it was butter smooth as @jec6613 put it.

Both are Zmatter. Polisy has the one installed inside the box, while eISY has the external plug-in USB version. Yes, I do zwave backups in AC regularly before doing IoX backup. Can I not just restore IoX then do "Restore Zwave" on eISY given both are Zmatter? It doesn't say that in the user guide but that would be nice to allow for a cold standby solution to hardware failure.