johnnyt

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.

I'm dead in the water with my Polisy and no one from UDI Support has reached out yet (opened ticket about 4 1/2 hours ago. In fairness it's the weekend and I'm 3 hours ahead - but I am dead in the water so am urgently looking for solution to restore my HA) On possible solution I might have is to restore IoX and PG3x from backups onto an eISY I've been using for testing and, frankly, in case of a catastrophic failure, which I think this might be. (the /var/udx folder is missing so I suspect disk corruption) My eISY has it's own separate Zwave dongle (USB) and, from what I'm reading, I think I would need to create a "migration" backup (different from a regular one) on the Polisy in order to restore IoX on the eISY because of the different zwave dongles Is that right or am I misreading things? (I've posted the relevant user guide section below) If so - and I need to do step 3 below - that's a problem because I can't get into IoX on my Polisy to do that. If not, I do have a regular backup from a day or two ago I could use. Can someone confirm whether or not I would have to do a migration backup in order to be able to switch over to my eISY? Is an alternative to swap the guts of my USB dongle with the "on board" zwave dongle from the Polisy? Is that physically do-able? Any help would be appreciated.

Yes, I see a one liner there now. Thanks. Expected something here but that's fine. Not really sure what that feature is or would do for me though. I guess now what I'd like to know is if upgrading breaks anything. Maybe now that's it's been brought up here and is being mentioned in PG3 dashboard, folks braver than me will try it and report success (or problems) here.

I just got a message today that a new version of the plug-in is available. I don't see a post about it here. Is it somewhere else? I did also look in Current Release Announcements and it's not there either but I didn't expected to be. What's in the new version? Anyone try it yet?

Here's more data. Had a UD mobile "Failed" notice at about 9:05 AM today so I grabbed log info starting a bit before and ending a bit after. See attached. Also had UD report "Failed" for this instance of Airthings at the following times over the past few days: 01/17/24 10:01 PM 01/17/24 08:57 PM 01/17/24 12:09 PM 01/17/24 05:53 AM 01/17/24 03:37 AM 01/16/24 08:25 PM 01/16/24 03:45 PM 01/16/24 08:25 AM 01/15/24 11:13 PM 01/15/24 07:05 PM 01/15/24 05:45 PM 01/15/24 09:37 AM

Bump. Are these features just for developers, UDI Support, or for future use? If they're for regular users, where can one get more information on them? Trying to decide if I want to upgrade.

I changed log level from "Warning" to "Info" yesterday in hopes of catching more log entries at next disconnection and one did occur overnight, with multiple unhandled error messages. See attached. I left in a chunk before and after the errors so you could see what happened. Hope this is helpful UnhandledErrors-Jan08.txt

Hi, I'm wondering if there's any plans for an update to this NS. I think it's been over a year since the last major update https://forum.universal-devices.com/topic/39323-pg3-airthings-consumer-node-server-101/ Also, I see there are 6 official "open" issues going back to July 2022 https://github.com/UniversalDevicesInc-PG3/udi-poly-Airthings-Consumer/issues plus there a couple of recent feature requests: And possibly some bugs (TBD as of this posting) Thanks for considering it.

I have 3 Airthings hubs so three instances of the NS are active. I regularly though intermittently get messages from UD Mobile that Airthings fails and reconnects. I had some time today so I looked into it and, although there was nothing interesting in the logs when the disconnect/reconnect happened, I found that there were three unhandled errors in the logs I downloaded - two for one of the instances and one for another instance. The log entries are dated Jan 4th and Jan 5th, which seems weird as I thought logs reset at midnight everyday and today is Jan 7th - why would entries from Jan 4/5 show up in today's log download? The third instance doesn't show any unhandled errors but was full of these: 2024-01-07 00:05:11,717 Thread-2696 udi_interface WARNING Sensor:query: Unknown param virusRisk=7.0 It's strange to me that the above would be occurring for one but not the others. All instances are monitoring Wave Plus devices so technically it seems to me if it's reported for one, it should be reported for all. That said, I don't think Wave Plus devices provide a "risk" value. I believe that's a feature of the Wave Mini, not the Wave Plus, so it shouldn't be looking for this parameter at all. Attached are: the unhandled errors (downloaded today combined into one file) for NS instances in slot 1 and and slot 9 today's log for the instance in slot 8 showing all the instances so far today of the above message a screenshot showing example of the UD notifications I get periodically. It can happen a few days in a row then not at all for several days The good news is that my ISY nodes are still being updated so the errors appear to be relatively benign and/or self healing. AT-unhandled errors.txt AT-unknown param.txt

Where can I get more info on the new features below in 5.8.0? What do they do? How to enable 2nd one if I want to make use of it? I searched both forum and wiki but only results were forum posts listing these release note items. - Integration of sqlite database for recording events/property changes - Node property history database - disabled by default

While my upgrade from 5.6.4 to 5.7.1 (which turned out to be 5.7.1_03) went well, I've had 4 crashes in last 2 days. 1st crash during replacement of Insteon Motion Sensor, which did not complete and programs were not updated so all needed to be fixed later. - Sat 2023/12/02 02:07:27 PM 0 -5 Start Crashes during restart from 1st crash: - Sat 2023/12/02 02:08:05 PM 0 -5 Start - Sat 2023/12/02 02:08:30 PM 0 -5 Start Did an upgrade (to 5.7.1_07) after upgrading my spare eisy and reading this in sysconfig.txt: <strong>Release notes for: 5.7.1_07 - 12/01/2023</strong><br/> - Fix for subscription hang - Fix for 4.9 migration crash <strong>Release notes for: 5.7.1_05 - 11/29/2023</strong><br/> - Crash while initializing PLM (older versions)<br/> Today IoX crashed when I was looking at Notifications in UD Mobile Mon 2023/12/04 03:39:02 PM 0 -5 Start A ticket has been submitted. Just wanted to warn people who are waiting for a stable release.

This year for fun I disabled my web switch call and let things go through. The following problems occured: 1. Programs that are counters, i.e. increment a variable every minute, stop running. This time was no different and is a long standing issue. I suspect it affects all programs that are waiting when the time change occurs but I haven't been awake looking at my AC at 2:00:01 to catch that first hand. 2. I don't remember this from years ago when I would let things run through but this time I ended up with no (i.e. blank) "Last Run Time" and "Last Finish Time" for anything before the time change. This despite IoX having been running for well over a month since last reboot and not seeing any evidence of a restart. There should have still been a ton of programs with last run time going back a month+ I'm still looking for a way to remotely shutdown my Polisy safely so if anyone can help with that, it would be greatly appreciated.

RE: DST change issues For past several years I've used a web switch to power off ISY at 1:59, wait 2 mins, then power it on. This avoided issues I saw every DST change for years before I implemented that. This year for fun I disabled my web switch call and let things go through. 1. Programs that are counters, i.e. increment a variable every minute, stop running. This time was no different and is a long standing issue. I suspect it affects all programs that are waiting when the time change occurs but I haven't been awake looking at my AC at 2:00:01 to catch that first hand. 2. I don't remember this from years ago when I would let things run through but this time I ended up with no (i.e. blank) "Last Run Time" and "Last Finish Time" for anything before the time change. This despite IoX having been running for well over a month since last reboot and not seeing any evidence of a restart. There should have still been a ton of programs with last run time going back a month+ Now, full disclosure, I'm still on 5.6.4 but I thought I would mention these issues in case they still exist in 5.7.0 so that maybe they could be fixed too while DST issues are being looked at.

If you didn't believe me, have a look at the posts about DST change issues in IoX 5.7.0 Support today, the day after DST ended. This is from people who bothered to post. Suspect many just rebooted their system and didn't have time to post.

@Geddy I don't want a 8+ hour outage as my system controls my HVAC and morning alarm clocks but I can live with a 2 min outage in the interest of all my programs continuing to run properly. Yes, my Polisy is on a UPS, plus I have a generator so technically my Polisy is able to run 24/7/365 except for upgrades and the 2 min outages twice a year for time changes (that I could probably reduce to something like 20 secs if I wanted to). I actually also would love the ability to cleanly shutdown or restart my Polisy programmatically or by using REST call for other than time change reasons. So while it's not clean, yes, I can do a power cycle but is it 100% safe to do that? Unlike with 994i, there's an OS, PG3x, and IoX stuff that has to live through it a "crash". Only one of those has to end up corrupted to cause problems.