johnnyt

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.

In >10 yrs of having ISY, time change has never gone well for me (and others too). Not sure why (and not saying it doesn't work for some) but I gave up just letting it happen a couple years ago. A restart after 2:00 AM eliminates all the problems.

With the upcoming time change this weekend, I'd like to shutdown Polisy cleanly at 1:59 AM using an ISY program. Unless there's a better way, I think I need a way to run "sudo shutdown -h now" remotely. Is there a way to do that, or another alternative? For completeness of story, I have a Web Switch that's controllable via ISY Network Resource that can run a script to power off outlet for Polisy, wait 2 mins, then power it on again. That's what I would do with my 994i and it always recovered fine, but given the complexity/fragility of things now, I really don't want to power cycle a running Polisy unless I absolutely have to.

I had put in lat/lon coordinates for my house thinking it would find closest station but clearly it doesn't so I went to web site, looked up my city, and entered the coordinates it display for it. Works now

Next time you have this plugin "up on the hoist", would you be able to add the device serial as a value one could use in a program? I record my readings in an ISY web file (e.g. @webpage:@append:mydir/VOCdata.htm) and use excel to analyze my data, and I'm considering something more sophisticated using PowerBI or InfluxDB. The only thing that remains unique over time for some of my devices is the device serial number because I move them around and rename them to something representing the location they are in at that time. I need both a consistant unique identifier and a meaningful short name as separate data fields. Thanks for considering it.