johnnyt

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?

I have a ticket open that lists many (but not all) the problems I've all of sudden encountered. I would add that even if it turns out to NOT be the board that's the problem this time, I'd still like to know how to swap one (assuming it's doable - is it?). I'm hoping it's not unlike replacing a PLM in principle though hopefully not in frequency

I think the internal Zmatter board in my Polisy is failing and I have a USB ZMatter board I would like to swap in. I wanted to make sure the following is what I would need to do: 1) backup zwave in AC 2) power off Polisy and remove internal Zmatter board 3) plug in USB Zmatter and power ON Polisy 4) once booted up restore zwave 5) reboot Is that right? Also, before powering off (step 2) would it help if I disabled "Zwave Support" in AC then re-enable it after step 4?

It does have the makings of a great NS, and yeah, for sure I may put a wish list together. I'm only starting to try stuff so I'm focusing/posting on getting the initial stuff I want to do working. So far the only thing that's actually working for me the way I'd like/expect (that I've tried) is changing the volume on a speaker, however it doesn't work for the 'say' command I want it to work for (as mentioned in my other post on that subject). Unfortunately I'm not really getting much support for the problems I've listed so far (from other users or @bpwwer), and I've read somewhere else that Bob doesn't have any Sonos to try/fix stuff at home. Now maybe the lack of responses to my posts is because it's summertime and people are on vacation so I'm still hopeful, but I'm working on this now and have limited time to figure out if I want to keep working it or do something else. Here's another thing I just posted that I can't get working:

According to the info at the following link, I need to "Join" secondary speakers to the first one to make a 'group' under that first one. https://github.com/jishi/node-sonos-http-api#grouping I tried to do this with the following program: Announcement Test - [ID 0446][Parent 0445] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Wait 13 seconds Set 'ST-Sonos / Dining Room' Join Kitchen Wait 1 second Set 'ST-Sonos / TV Room' Join Kitchen Set 'ST-Sonos / Kitchen' Group Volume 20% Wait 1 second Set 'ST-Sonos / Kitchen' Say Test Phrase 1 Else - No Actions - (To add one, press 'Action') And I end up with this group in the app: Then the 'say' command only comes out the Kitchen speakers, not the group I made above, which is not surprising but not what I asked for. My 'Portable' speaker has never been grouped with the "Kitchen" and "TV Room" so all I can deduce at this point is that the NS did that, and that it's a bug. I ran the above program twice with same result. I also tried to group the latter two (Kitchen and TV Room) with a different speaker after ungrouping everything using the app and ended with the same thing. Why the "Portable" speaker becomes the parent doesn't make any sense. Anyone have any suggestions as to what I did wrong or might be happening?

Thanks, @landolfi, changed POST to GET and it worked. @lilyoyo1, as for limitations see: Problem 1 in above post was solved with restarts but problem 2 remains (limit of 10 phrases). Although this isn't a problem yet - I just started with this - I foresee it becoming a problem if I decide to keep going with this NS. Plus: - wanted to change language to French for some phrases and can't see how to do that with NS. Hoping Network Resources will help - My TV Room (a playbar with subwoofer and rear speakers) isn't able to "say" anything for some reason. I do need to try a few more things before posting on that, including trying it using Network Resource. - support seems to be very limited at best

Has anyone used Network Resources to call the underlying Sonos API that this NS uses? (https://github.com/jishi/node-sonos-http-api) My initial tests are not working but I'm far from a network resource expert so very likely have made some errors in the way I set it up. I'm hoping using Network Resources might allow me to get past some of the limitations I'm running into with this NS. edit: the URL works fine from browser:

Am not getting any of my Sonos speakers to "say all' a phrase. The phrase does work as a 'say' on a single speaker. So this works: Set 'ST-Sonos / Dining Room' Say Test Phrase 1 And this doesn't: Set 'ST-Sonos' Say All Test Phrase 1

Yes, for the first issue, "both" restarts was the correct answer PLUS some passage of time. It's not instantaneous. Looks like the NS was only built to support 10 phrases according to https://github.com/simplextech/pg3_docs/tree/main/ST-Sonos, so strange that there are 50 slots to select from in ISY. I (and others, it seems) don't have that many use cases yet but maybe adding support for more than 10 phrases (which does appear possible in the PG3 UI) could be on a request list if any such thing exists. In the meantime, it would be a good UX idea to remove any entries in AC or buttons in PG3 if that are not usable. Would save people some time. Thanks for considering these things.

I've set the volume to multiple values between 10 and 70 before calling the 'say' action and the message is always at the same volume. Fortunately not too loud for my current use case but also not quite loud enough in some situations. Aside from being able to adjust the volume for the particular speaker/room, I'd like to be able to set it according to the time of day, e.g. not as loud at night / early morning. So it's an important thing that I'd like to be able to change. I'll also likely eventually have a use case that will need lower voice volume, e.g. my bedside speaker. Below is my program but it doesn't matter what % value I use - the say command is at the same volume all the time. (I don't know if I need to do this but I add a short wait after command to adjust the volume.) Workshop Door Open Announcement - [ID 0444][Parent 0445] If 'Lights / Basement / Workshop / Workshop Lights' Status is Off And 'Lights / Basement / Workshop / Workshop Door Open Sensor' Status is On Then Wait 20 seconds Set 'ST-Sonos / Dining Room' Player Volume 50% Wait 1 second Set 'ST-Sonos / Kitchen' Player Volume 50% Wait 1 second Set 'ST-Sonos / Kitchen' Say Workshop door is open. Please close the door. Wait 10 seconds Set 'ST-Sonos / Dining Room' Say Workshop door is open. Please close the door. Else - No Actions - (To add one, press 'Action') I can see in the device node and the Sonos (S1) app that the volume is changed by the program. It's just the say command appears to override whatever the speaker is set to, then return it to that value. The latter is actually ideal functionality but I do need to be able to adjust the volume of the voice. I see in the underlying API functionality that the NS uses (https://github.com/jishi/node-sonos-http-api) that the command for TTS service has a switch to set volume: /[Room name]/say/[phrase][/[language_code]][/[announce volume]] Does the volume need to be sent in the action and it's not being done today? How do people change the volume for the "say' command?

ok, thanks. I changed it to '-' and all is good now. What about the usefulness (or not) of the "Discover" button? I'll assume it does nothing unless I hear otherwise.

Update: Looks like either a NS restart, or an AC restart, or both, and/or the passage of time pushed some of the the phrases out to IoX. I now see phrase 0 and 1 in program action. Not yet phrases 2 and above but maybe some more restarts and/or the passage of time will solve that? So it may only leave only the issue of adding phrases 10-49 and having them get saved/displayed (and hopefully passed along to ISY). I'm not in need of them in the short term as I experiment with use of this feature but it's certainly possible I'll want more than 9 in the not too distant future if it works as well as I'm imagining/hoping it will.