johnnyt

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.

HI, I noticed my log is full of these messages: (occurring every "short poll", which is set to 600 secs) 2023-10-11 02:35:23,170 Thread-1356 udi_interface WARNING query:_query_forecast: Failed to parse forecasted rain/snow data. 2023-10-11 02:35:23,171 Thread-1356 udi_interface WARNING query:_query_forecast: list indices must be integers or slices, not str 2023-10-11 02:45:23,161 Thread-1357 udi_interface WARNING query:_query_forecast: Failed to parse forecasted rain/snow data. 2023-10-11 02:45:23,162 Thread-1357 udi_interface WARNING query:_query_forecast: list indices must be integers or slices, not str Am running version 3.1.5 on PG3x 3.2.4 on a Polisy

Hi @Jimbo.Automates, As you know the Unix epoch timestamp is one of the fields available for each Airthings device (at least the Wave Plus devices anyway). I'd like to be able to use it to know how long it's been since a device was last updated in seconds or minutes and trigger an event/notification if it's been too long. I feel like I would need to either convert it to YYYYMMDDDHHMMSS or be able to get/calculate the current epoch time 'now' so I can do the math using ISY programs. About 99% of my google search results for the formula or algorithm to convert current time to unix epoch time were either online calculators for human consumption, how to do it in Excel, or talked about using built in linux or windows commands, e.g. date +%s in linux. (I tested the latter and it does work on the Polisy.) When I did find formula or algorithm info it was shell code or python, etc., which didn't translate well to ISY programming and made me think it was silly to try to do it using ISY programming. Instead I wondered if you could make the NS do the simple calculation of subtracting 'date +%s' from epoch time that the API provides (both have same 10 digit resolution) and display a "time since last updated" in minutes or seconds. As far as I'm concerned it could replace the current time field in NS/ISY because I can't see what other use the unix epoch time would have but if you wanted to have both, it's fine with me. Thanks for considering it.

I think I found the right search terms to use eventually (most posts about serial cable refer to PLM) Here's what I found for others' ease of reference: One would need to: (1) Acquire the USB to TTL Serial Cable (2) Gain Access to the Polisy Serial Console Connector (3) Tape or Tie Back the USB to TTL Serial Cable's Power Pin (4) Move the Jumper (5) Connect the Serial Ground (6) Connect the Transmit and Receive Data Wires etc. This is not for the faint of heart, and you need to order/wait for the cable to arrive. I'm going to add that project to my 'to do' list so I'm ready in case I need it.

I think I'm reading it's fixable by running some linux commands but not yet avoidable in 5.7.0. I would wait for a > 5.7.0 release and only IF the release notes say the bug was fixed AND a week or so after the release it has NOT been reported as still a problem AND you have a manageable amount of "leave disabled" programs where you either know what they are so you can easily re-disable them, or you can live with them becoming enabled while you get find/get the linux commands you need to run to fix it Unfortunately I don't think we can count on UDI to provide this information proactively based on what has happened regarding this bug with both this release and the previous one.

@btreinders I do feel your pain. My HA controller has certainly become mission critical equipment in my house. That's why I bought an eISY w/ USB Zmatter to have spare h/w in addition to doing periodic images of my Polisy, and have also asked UDI to consider providing imaging capability without needing to pull the SSD out of the box, or the ability to take a snapshot of everything that would allow one to roll back. I don't think it's practical to share my image. For one thing it's 32GB - too much for any the (free) cloud drive space I have. It's also got all my stuff, most notably and I think problematic, my ISY portal and node server license info or links to that info at UDI, not to mention the API token needed to access my system remotely. I'm not really clear on all this but, bottom line, I think you would need a barebones image if you don't have one of your particular system, then buy or transfer whatever licenses you need.

There should also be instruction on how to replace and a Polisy with an eISY with a new USB ZMatter dongle (and an eISY with another eISY / new dongle). Aside from the backup/image part, there are zwave and PG3 licensing issues tied to specific hardware - needs to be explained how that works.

I agree but in the mean time I got one of these https://www.amazon.ca/gp/product/B01MCV52TH/ref=ox_sc_act_title_1?smid=A3TUR5JBYCEPNE&th=1 and used Rufus to create my own image. Careful the adapter you choose. They aren't all the same. Here's a thread on this with more info and variations that worked for others

I'm talking about Init value. I save my variable data throughout the day, for example when a counter stops (in Else action) as well as at regular timed intervals. I don't think it's a good idea to save every increment as I think it would cause excessive SD wear over many years but that's kind of an assumption I made. Office Damper Counter - [ID 010A][Parent 0210] If 'HVAC / Furnace Area / Office Damper' Status is On Then Wait 5 seconds Repeat Every 1 minute $iHVAC.Count.OfficeDamper += 1 Else $iHVAC.Count.OfficeDamper Init To $iHVAC.Count.OfficeDamper I also have a "Save all Counters" program I call before a reboot or a backup that updates all my important usage init values. Would love if that could be called by IoX at shutdown, which reminds me that I have to submit a request for that feature.

I'm assuming it's a difficult bug to find/fix but I have to say I'm not sure if that's a correct assumption. What if it's just because it doesn't impact a lot of users, or it simply doesn't matter the severity of the impact to those affected? If one opens a ticket right now one will see there's a 5.7.1 and 5.7.2 release that haven't been actually released. Does one of those have the fix? Maybe. Maybe not. It's a guessing game. The problem is more about the lack of communication. Someone else made that point earlier in this thread and I couldn't have agreed more with that. Why not say "fix coming soon - just wait", or "it's a weird one; working on it - proceed with caution" It's concerning, actually, particularly when this release was announced to all on UDI mailing list as "official". Years ago (pre-zwave), official releases were after umpteen beta releases that were actually flawless most of the time (certainly by comparison to more recent times). Yeah, more complex solution today, for sure. Lots of moving parts. Which is why communication seems so much more important today.

So variables are backed up and restored. Data stored in devices, e.g. total energy, will remain and continue to update in the device itself I believe (I never actually checked that - it's just what would sense) The problem with variables and restores for me (and I suspect many others) is that I rarely want the old data from the backup to overwrite the data that's in the variables now. The most obvious use case (and I have tons of these) is for variables that store usage data, e.g. the time that the furnace fan is on increments a variable that I use to tell me when to change the filter based on usage. Really I can only think of one use case where I DON'T want to keep the old data, and that's if doing an SD card replacement. Maybe I'm not thinking of other ones right now but mostly I don't want the restore to overwrite the data in variables. I either would want the latest data or I simply don't care - the variable is for transitory data anyway. UDI told me they're considering a way to NOT restore variable data when doing a restore. I presume it will be an option (yes/no) because if I'm replacing an SD card with my restore I would want the value from the backup restored. I have no idea when that feature might come but maybe if others ask for it, it will come sooner rather than later

happened to me when I was running 5.6.4 after an upgrade that had a minor fix (was 5.6.4_1 if you looked at the version at OS level - something had been changed to quietly fix a bug). It's stunning to me that UDI is not releasing a fix (if there is one) or telling people to stop updating (if they don't have one) unless you only have a few disabled programs and can easily recover. This is a major bug for some us (I have about 1200 programs, of which about 350-400 are to be left disabled all the time) I RECOMMEND YOU DO NOT UPGRADE TO 5.7.0 UNLESS YOU CAN EASILY FIX THIS PROBLEM IF IT HAPPENS,

The key part of that statement is "that impacted lots of users". For the bug I'm thinking of currently in 5.7.0 (still being reported as occurring) that also occurred in 5.6.4 and enables all programs, it appears it's not impacting enough users to generate a fix given it's been 18 days since release of 5.7.0 plus a month before that for 5.6.4. But this bug is absolutely catastrophic for someone with 1200 programs of which 350-400 are supposed to remain disabled (and long before that number of programs is reached). While UDI did help when it happened to me in August (running 5.6.4), it was a major disruption to have to drop everything I was doing and had planned in order to, first of all troubleshoot/find/report what had messed up my automation big time, then try to recover with UDI (during their business hours in a different timezone) one email at a time, then make myself available to allow them to log into my system and sit there while they investigate and do the repairs. Perhaps they don't mind the cost of not being able to roll back but I did. While one can adopt a plan to always delay upgrades and read the forum carefully before doing one (and that's what I am/will be doing) that too has a cost, and it still doesn't provide any assurances I won't run into a catastrophic issue UDI didn't fix because there aren't enough people impacted. There seems to be so many moving parts that make things so brittle you'd think there would be value in having the ability to roll back. Maybe I'll put in a feature request for an OS snapshot capability or a system imaging utility that one can run before an upgrade.

Let's say I upgraded to latest IoX (using AC "Upgrade Packages" button) and it resulted in a major bug so I want to go back while waiting for a fix to be released. I have a backup from just before the upgrade and can restore it but does it actually go back to the IoX (n-1) version on the backup? If YES, what are the risks related to having upgraded the underlying OS components and PG3/PG3x but being a version behind with IoX? (Would newer OS/PG3 stuff be mostly backwards compatible?) If NO, it doesn't go back to IoX n-1 that's part of the backup, given there isn't a way (like there was with 994i) to download an older version of IoX, does that mean there simply is no way to go back?

Would like to stop an "Update with Interview" that keeps resetting to a high 500 timeout. Been running for about 20 mins How do I stop this? Pressing the "X" on the message box closes the box but doesn't stop the process. Tried the "Zwave -> Advanced -> Stop Adding or Removing Zwave Device" menu option but that didn't work either. Here's a tiny sample of the process that has repeated itself countless times: Fri 09/22/2023 11:53:33 AM : [Device 140] Waiting on interview complete (timeout in 597) Fri 09/22/2023 11:53:35 AM : [Device 140] Waiting on interview complete (timeout in 557) Fri 09/22/2023 11:53:37 AM : [Device 140] Waiting on interview complete (timeout in 591) Fri 09/22/2023 11:53:39 AM : [Device 140] Waiting on interview complete (timeout in 551) Fri 09/22/2023 11:53:41 AM : [Device 140] Waiting on interview complete (timeout in 583) Fri 09/22/2023 11:53:43 AM : [Device 140] Waiting on interview complete (timeout in 543) Fri 09/22/2023 11:53:45 AM : [Device 140] Waiting on interview complete (timeout in 575) Fri 09/22/2023 11:53:47 AM : [Device 140] Waiting on interview complete (timeout in 535) Fri 09/22/2023 11:53:49 AM : [Device 140] Waiting on interview complete (timeout in 567) Fri 09/22/2023 11:53:51 AM : [Device 140] Waiting on interview complete (timeout in 600) Fri 09/22/2023 11:53:53 AM : [Device 140] Waiting on interview complete (timeout in 559) Fri 09/22/2023 11:53:55 AM : [Device 140] Waiting on interview complete (timeout in 592) Fri 09/22/2023 11:53:57 AM : [Device 140] Waiting on interview complete (timeout in 551) Fri 09/22/2023 11:53:59 AM : [Device 140] Waiting on interview complete (timeout in 583) Fri 09/22/2023 11:54:01 AM : [Device 140] Waiting on interview complete (timeout in 543) Fri 09/22/2023 11:54:03 AM : [Device 140] Waiting on interview complete (timeout in 576) Fri 09/22/2023 11:54:05 AM : [Device 140] Waiting on interview complete (timeout in 535) Fri 09/22/2023 11:54:07 AM : [Device 140] Waiting on interview complete (timeout in 568) Fri 09/22/2023 11:54:09 AM : [Device 140] Waiting on interview complete (timeout in 528) Fri 09/22/2023 11:54:11 AM : [Device 140] Waiting on interview complete (timeout in 560) Fri 09/22/2023 11:54:13 AM : [Device 140] Waiting on interview complete (timeout in 592) Fri 09/22/2023 11:54:15 AM : [Device 140] Waiting on interview complete (timeout in 552) Fri 09/22/2023 11:54:17 AM : [Device 140] Waiting on interview complete (timeout in 587) Fri 09/22/2023 11:54:19 AM : [Device 140] Waiting on interview complete (timeout in 547) Fri 09/22/2023 11:54:21 AM : [Device 140] Waiting on interview complete (timeout in 580) Fri 09/22/2023 11:54:23 AM : [Device 140] Waiting on interview complete (timeout in 540) Fri 09/22/2023 11:54:25 AM : [Device 140] Waiting on interview complete (timeout in 572) Fri 09/22/2023 11:54:27 AM : [Device 140] Waiting on interview complete (timeout in 531) Fri 09/22/2023 11:54:29 AM : [Device 140] Waiting on interview complete (timeout in 564) Fri 09/22/2023 11:54:31 AM : [Device 140] Waiting on interview complete (timeout in 597) Fri 09/22/2023 11:54:33 AM : [Device 140] Waiting on interview complete (timeout in 557) Fri 09/22/2023 11:54:35 AM : [Device 140] Waiting on interview complete (timeout in 589)