johnnyt

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)

The ISY (994i) can't run more than 1000 programs. Needs to be Polisy or eisy. The latter also have a deeper event queue. Reboots were problematic for me on 994i starting around 800 programs or so with a frequently blown event queue. Had to jump thru hoops to stagger things and minimize the losses at startup and could never completely eliminate problems. All better now (on Polisy). No more complex startup programming. I could probably start to use tags like Chris suggested on top of using folders to help me manage/find things. I do often ask myself "where did I put that set of programs again?"

it's happening now. others have reported it with this upgrade. did not see it in ISY myself but it happened to me a few weeks ago not long after upgrading to 5.6.4. had no choice but to restore a 3 day old backup because trying to figure out what ~400 of 1100 programs were disabled would have taking way too long. This caused me to lose a bunch of changes but more impactfully, it caused loss of data in variables that track usage of various things. (UDI is thankfully considering option for not restoring variables when doing a restore.)

Can you please expand on how you did this?

Does this actually prevent the enable-all bug from kicking in?

@Chris Jahn, great idea. Could UDI append #Disabled when a program is saved without the enable box checked? I have > 1100 programs with close to 400 disabled. going through 400 programs to add this hashtag would not be easy.

Is there a way to upgrade PG3x without upgrading IoX? If not, could something be implemented so one can fix/improve something in PG3 without implementing a problematic release of IoX?

yes, I do. thanks. do you have any experience with the steps I'm thinking need to be followed? does it work? does disabling zwave support help, hurt, or make no difference?