johnnyt

ok, can I un-purchase the NS trial until I've had a chance to migrate to PG3x? I'm holding off on doing that move for now for a few reasons (stability, lack of automated PG3x restore on eisy from Polisy, which is my backup hardware, etc.) I'm sure I'll do it at some point; just not in the next 6 days I have left in the trial version. I do like the features it offers, and only need them to work with the legacy Sonos S1 app so hopefully don't need much, if any, support going forward (which seems to be a little on the light side.) But given this NS is not free (and actually comparatively expensive), plus some recent bugs that, as of right now, may not get fixed (but might not be a problem for me) it's going to be important to try before I buy.

Does this NS work? I purchased free trial, installed it, and started it. It said it started successfully but it didn't really. I tried to look at the NS logs but it said 'file not found'. Here's what PG3 had to say about it in its log: 7/25/2023, 16:27:55 [pg3] info: startNs:: ST-Sonos 7/25/2023, 16:27:55 [pg3] info: startNs:: ST-Sonos is valid 7/25/2023, 16:27:55 [pg3] debug: checkLicense:: ST-Sonos Getting node server store entry 7/25/2023, 16:27:55 [pg3] debug: checkLicense:: ST-Sonos Getting node server purchase record 7/25/2023, 16:27:55 [pg3] debug: Getting status for ST-Sonos 00:0d:b9:53:c7:dc 82a81345-75e8-48c1-87fc-60e4cfd46860 7/25/2023, 16:27:57 [pg3] info: checkLicense:: ST-Sonos Valid subscription license found. Expires: 2023-07-31T18:20:13.000Z 7/25/2023, 16:27:57 [pg3] info: startNs:: ST-Sonos finished update check 7/25/2023, 16:27:57 [pg3] info: [ST-Sonos(10)] :: Starting NodeServer - Version 1.0.8 7/25/2023, 16:27:57 [pg3] info: startNs:: ST-Sonos updating database (enabled, timestarted) 7/25/2023, 16:27:57 [pg3] debug: [MESSAGE_PUBLISHED] Client pg3_client has published message on udi/pg3/frontend/clients/aef56f72-00cc-48c3-a122-fcdd3e3ac5fd to broker pg3_broker 7/25/2023, 16:27:57 [pg3] debug: [MESSAGE_PUBLISHED] Client pg3_client has published message on udi/pg3/frontend/clients/aef56f72-00cc-48c3-a122-fcdd3e3ac5fd to broker pg3_broker 7/25/2023, 16:27:58 [pg3] error: [ST-Sonos(10)] :: STDERR: node:internal/modules/cjs/loader:1042 throw err; ^ Error: Cannot find module '/var/polyglot/pg3/ns/000db953c7dc_10/st-sonos.js' at Module._resolveFilename (node:internal/modules/cjs/loader:1039:15) at Module._load (node:internal/modules/cjs/loader:885:27) at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) at node:internal/main/run_main_module:23:47 { code: 'MODULE_NOT_FOUND', requireStack: [] } Node.js v18.13.0 7/25/2023, 16:27:58 [pg3] info: [ST-Sonos(10)] :: Exit cause code: 1 - signal: null 7/25/2023, 16:27:58 [pg3] debug: [MESSAGE_PUBLISHED] Client pg3_client has published message on udi/pg3/frontend/clients/aef56f72-00cc-48c3-a122-fcdd3e3ac5fd to broker pg3_broker 7/25/2023, 16:27:58 [pg3] info: startNs:: ST-Sonos starting polls 7/25/2023, 16:27:58 [pg3] info: Starting ST-Sonos Expire Check timer 7/25/2023, 16:27:58 [pg3] info: Checking if ST-Sonos has expired 7/25/2023, 16:27:58 [pg3] info: Starting ST-Sonos Info timer 0 7/25/2023, 16:27:58 [pg3] info: Starting ST-Sonos Version Check timer 7/25/2023, 16:27:58 [pg3] debug: MQTT Results: [frontend/ns/admin] :: {"startNs":{"success":true}} 7/25/2023, 16:27:58 [pg3] debug: [MESSAGE_PUBLISHED] Client pg3_client has published message on udi/pg3/frontend/clients/aef56f72-00cc-48c3-a122-fcdd3e3ac5fd to broker pg3_broker 7/25/2023, 16:28:02 [pg3] debug: Sending logfile to frontend :: /var/polyglot/pg3/ns/000db953c7dc_10/logs/debug.log am running PG3 3.1.21 and IoX 5.6.2 on Polisy

What if one's functioning Polisy stopped functioning? I don't think one can get a Polisy anymore so I think it should be viewed as important to help Polisy users be able to move to eisy. In fact, I bought an eisy when it came out in part to have backup hardware in case my Polisy fails. I was contemplating going to PG3x on my Polisy once 3.1.37 beta became stable release. From reading this thread I probably shouldn't move yet to preserve what's there in terms of migrating to eisy. While I'm okay to wait, as PG3x grows and PG3 falls behind, its likely going to have stuff I want, not to mention increasingly better support.

@landolfi, @Techman, @AKAPADIA, have you solved or made progress on your problems since upgrading to 5.6.3? For those looking to provide feedback about Zigbee or request device support, please consider using one of the separate threads for that so this thread can focus on the non-Zigbee related IoX 5.6.3 issues. Thanks for considering it.

IoX refuses to recognize Celsius temperature reports for my three Aeotec Multisensors and the two Aeotec aerQ sensors I tried. Read somewhere that this is a known issue on the UDI 'to do' list but this is second hand info. I suspect issues I had with aerQ and a Zooz ZSE44 - excessive battery-killing reporting - to be unique to Zmatter board (based on feedback from Aeotec and Zooz support) but did not open a support ticket to get UDI confirmation or troubleshooting advice. I simply returned the aerQ sensors while I still could and gave up on using the ZSE44. I will say that I do have another ZSE44 that works ok so, for that sensor, I suspect the sensor itself is the problem or part of it. (Yes, I upgraded to latest firmware and did factory reset, etc. etc.) I don't know if all the migration issues I reported (summarized briefly in my original post) were fixed and won't be able to tell as I only had one 994i and it's now fully migrated to IoP. The only net new Zwave devices I added after moving to IoP are the aerQ sensors I tried and returned, and a ZEN32 Scene Controller. The latter communicates fine but is clunky to work with (see this post and this post). It certainly isn't the replacement for a KeypadLinc that I had hoped it would be, although that appears to be related to IoX support for it based on what Home Assistant can do with it so maybe it will one day be better than a KeypadLinc thanks to its multi tap capability.

I don't want to overstate the problem but I also don't think it should be dismissed or minimized. For sure when everything is fine... well... everything is fine. What distinguishes a good product/solution/vendor from a bad one is how it deals with problems - and the need for upgrades when it comes to this kind of thing. Things should be as easy as possible to configure, fix, upgrade, and replace. Although they aren't "easy" by any means right now (i.e. don't try this if you don't have patience and determination), anything that moves things closer towards 'easy' and away from "holy-sh*t-what-a-hassle!" is valuable.

anytime I've excluded/re-included a device it's gotten a new zwave address. that's the issue. too bad there isn't a way to manually (re)assign an address to a zwave device and end up with all the program and other relationships intact.

Is the messing up of programs following an exclude/include only an issue with ISY? I thought it was a general zwave issue affecting all HA controllers.

I moved to IoP (IoX 5.6.0 on Polisy) over a month ago and it's fixed a whole bunch of problems I was having. Also allowed me to dust off automation ideas I had put on the back burner because: - I had reached the 1000 program limit (about a year ago) - now at 2000, I think. I was at 980 programs and if I wanted to add anything meaningful I needed to give something up - Simple automations were slow, even insteon triggered ones like motion turning on a light, which used to work flawlessly before I added a bunch of zwave devices. Everything is back to flawless... well 99% flawless... there are always the odd glitches with Insteon. - Nodeservers (5 of them) were retrying constantly and sometimes failing to communicate. That's no longer a problem. - Startups would exceed event queue capacity and there was no way to figure out what events were missed. To mitigate this I had developed a complex startup routine that only enabled programs and did device queries in chunks with regular delays in between. I must have spend 100's of hours building and refining that and, while it was better, it was far from perfect. - Admin Console loading and backups were exxxxtra suuuper sloooow. These are not quick things by any means, but, relatively speaking, they are notably better now. The migration wasn't flawless by any means but it was far less painful than I expected. The biggest issue was that about half a dozen zwave devices (out of an estimated 70) remained as "Placeholders" after migration. An "Update with Interview" would fix them temporarily but at next reboot they would come back as placeholders. A couple magically fixed themselves (some kind of sun and moon alignment thing is all I can think of) but many needed to be excluded/re-included, which messes up all the programs those devices are in. Support tickets about those placeholders remain unanswered to this day. There are also zwave devices for which I reported issues that weren't there with 994i and did not hear anything back so not hopeful they will be fixed. That said, overall zwave stuff is working light years better than it was. Moving of 994i was definitely worth it.

Just so it's clear on a few things: the wakeup interval I use is 14,400 (4 hours) I do have one of these that's working fine both worked fine on the 994i (and were hard to setup there too) before I had to exclude/re-include them when I moved to IoP/Zmatter

a worn battery always reports good to excellent on my battery tester after it's no longer working in my ZSE44. I don't have anything else to use with it but I bet it would still work in many other devices. Also battery level is not reliable. It goes all of the place. On one of them right now it's been at 0% for couple weeks but still reporting temp/humidity. Getting these buggers linked requires a lot of perseverance and repeated tries. Also had to set 'keep awake' time to 10-15 secs in order to make it through interview (or write changes after the interview didn't work). Also to help with configuration, and to allow time for "Update Neighbors" after I moved it from the "bench" (close to Polisy), where I have to bring it to configure it, to it's ultimate destination. And, initially, they wouldn't work in their ultimate destination until I put a repeater in the same room. Just outside in the hall wouldn't work. Don't forget to turn 'keep awake' off once it works unless you're okay with replacing the battery every couple weeks... For one of the two ZSE44s I have, I've had repeated emails with zooz support after moving recently to Polisy with ZMwatter from 994i because it constantly wakes up / goes to sleep Here's a tiny sample from a program I wrote to capture activity: 2023/05/20, 09:40:32 , Main bath sensor, ASLEEP 2023/05/20, 09:40:47 , Main bath sensor, AWAKE 2023/05/20, 09:40:53 , Main bath sensor, ASLEEP 2023/05/20, 09:40:54 , Main bath sensor, AWAKE 2023/05/20, 09:40:59 , Main bath sensor, ASLEEP 2023/05/20, 09:41:04 , Main bath sensor, AWAKE 2023/05/20, 09:41:16 , Main bath sensor, ASLEEP 2023/05/20, 09:41:20 , Main bath sensor, AWAKE Have gone through probably 3 batteries trying multiple things over several days until Zooz support finally relented and said "send it back". It's about a year old and, yes, I did update the firmware to latest version as part of the multiple things I tried. I really want to move off these and just tested some Aeotec aerQ's. I like the form factor and features but, interestingly, both sensors I just got way over report the temperature. Aeotec support can't figure out why. I'm starting to wonder if Zmatter dongle is the cause or part of the problem. Both ZSE44 and aerQ devices are overreporting situations, and both vendors are acting like this is the only time they've ever heard of this problem (which I normally doubt but this time it has me doubting my equipment). I may raise the issue with UDI but they would probably need to get those devices to do proper testing/troubleshooting - something I doubt they would do unless there was significant demand form the masses. I'm finding they're generally ignoring the zwave device problems I've reported since moving to Polisy. Maybe they're looking at them - maybe they're not. They're not telling me and, except for one device (ZEN17), they're not asking for more info so I can't tell.

I'd like several of my 'Favorite' tiles (or whatever they're called) to show a second sub-node (or whatever they're called) instead of the primary one. For example I have smart switches that show, in this order, Total Energy, Current Power, Current Voltage, and Current Current. I added the tile to my favorites and it shows the first number (Total Energy) but I want "Current Power" to show. See screenshot below. Of course, I'm referring to the favorites screen (back from this one.) This actually wasn't a problem when I was using 994i. Only after I moved to IoP 5.6.0. Sorry if this is explained somewhere already. I looked around, including wiki, and didn't find it.

Thanks. Found the setting you're talking about inside the "Wake Up" node, which I had buried in a "Not Used" folder along with all but the nodes I use in my programs. Hopefully this fixes two issues I'm having. I have one of the two sensors that works for a short period but then shows the green arrow indicating need to update (and "Write Change" doesn't work). I was able to write changes this morning but I'll have to wait and see if the fix is permanent. I also have not been able to "Update Neighbors" when I move the sensor back from the "bench" to it's ultimate destination,. In part, I think, because I had to run between where my AC is running and that ultimate destination.

I upgraded the device firmware to ver 1.30 and they now work. I was at original v1.10. It looks like in the new world order I need to start command to queue it up, then wake the sensor up, the command is sent and the device is immediately put back to sleep. On 994i I had at least 30 secs of awake time to do a couple of things. It appears though I can queue several commands and they are all sent. No good for when I need to view multiple parameters - have to press wake up for each one, which is a bit of pain. These are my only battery zwave devices - is this behavior for all zwave battery devices? Is there a way to change this in IoX to delay the return to sleep? (looked but didn't see one). There's no setting in ZSE44 but I don't think it's the one putting itself back to sleep.

oh yes, that makes sense. Now I need to figure out if I have to migrate to PG3x on Polisy in order to be able to restore one of those backups on an eisy. I was holding off on that because I think there are still some growing pains with PG3x on Polisy and no new features I need yet... unless recovering a dead Polisy on an eisy is one of those features that is...

but that was there all along, even when there was a "Migrate to ZMatter Z-Wave" button and a clear distinction made that a migration backup was different than a regular backup. Hopefully it's all in one backup now and the wiki page hasn't been updated yet. I'd rather not have to do two backups every time. I just haven't read or seen anything about that.

If my Polisy was to suffer a catastrophic failure I'd like to be able to recover using an eisy. I was looking up the migration steps at https://wiki.universal-devices.com/index.php?title=Eisy:User_Guide#Preparing_for_Migration_from_Eisy_/_Polisy and don't see where the "Migrate to ZMatter Z-Wave" option is in my AC today. I do remember seeing that option in the past (before I migrated off my 994i to IoP). Did it go away in 5.6.0? There's a warning further down that "A migration backup is different than a regular backup" Here's what I see when I go to the Configuration tab: Does this mean one would only need to restore a regular backup, even with a different Zmatter dongle?

I migrated 994i to IoP (IoX 5.6.0) this past weekend and my two Zooz ZSE44 temperature/humidity sensors won't wake up long enough for me to do anything with them. The are put (or put themselves) back to sleep a microsecond after being awakened. Mon 05/01/2023 05:14:45 PM : [ZY104_199 ] ST 100 (uom=51 prec=0) Mon 05/01/2023 05:14:45 PM : [ZY104_199 ] DON 100 (uom=78 prec=0) Mon 05/01/2023 05:14:45 PM : [ZY104_199 ] ST 0 (uom=51 prec=0) Mon 05/01/2023 05:14:45 PM : [ZY104_199 ] DOF 0 (uom=78 prec=0) They're stuck waiting to write updates. I've tried multiple times to right-click and "Write Changes" to no avail. Multiple Interview attempts also fail, as do "Update Neighbors". I can't view or change any parameters either, of course. Each time clicking the button 4 times to wake it up, of course, and seeing the LED flash but immediately stop flashing. When I used these with 994i the flashing would keep going while it was awake. I was able to exclude / include them and did that several times for each one in case something about the process was flaky but there were no noticeable hiccups or differences. I've tried with "all" and with "no" security. Same result. It does seem to add all the nodes but then something happens and they stop listening and won't let anything wake them up. Anyone see this?

yes that worked. in addition to deleting the *udi* files in temp folder per the wiki, I also cleared Java cache for what that's worth. udi_launcher.state wouldn't delete until I restarted machine. It was allegedly 'in use' even though IoX Finder wasn't running.

I migrated to IoP 4 days ago after upgrading Java and ever since IoX Finder does not remember the IoP link I added. I've added it many times and it's not working. Strangely it does remember 994i link, which is now offline. Both my 994i and Polisy are on their own VLAN subnet so I always need to add the IoX IP address but it's always remembered them until now. This morning I tried the launcher on a PC that is still at previous Java version and it remembered my IoP (and 994i), so I think there's something about the latest Java version that's at least part of the problem. @SHM you may want to check the Java version on the different machines you're using to see if that's the problem in your case too. It's strange that it remembers the now missing 994i but not IoP. The latter was on the list before I migrated to it. Since I did "Upgrade Package" to 5.6.0 from 5.5.9 before migrating, it could also be 5.6.0 related - or combination of the two.

I do have the zmatter board in it and it's been there for a couple of months, although it and CPU were mostly idling until I migrated to IoP a couple of days ago. Before that it was only running 4 node servers. I went through my e-junk drawer and found a 2.5A PS with same polarity (+ on the inside) so I'm using that now.

Mine is one of the first ones made, which came with a 1A power supply

Interesting. Although I've been using Polisy (one of the first ones out) for PG3 for a while now without problem, I just moved to IoP 2 days ago and had a spontaneous reboot last night. Of course it could be unrelated but maybe adding the zmatter board and the new processing demands of IoP is taxing the PS. Does anyone know what size the connector into Polis is?

good point. I wanted UD mobile to make things available remotely so never went there. Thanks.

Interesting. I just used the default inclusion on 994i. I think it was S0. I didn't/don't really feel I personally need high security, and question why it should it be needed. It usually adds processing overhead as the trade off and, other than for maybe door locks, which I don't have, I don't see including things with high security as a requirement. None of my neighbors have or care about taking over my lights or HVAC, which is what I use the ZEN17s for. (If I'm missing something on this front, let me know.) I know you're just saying what worked in the end but I'm just saying that it's an issue if the fix is what level of security I used when I included it... I did upgrade firmware to 1.20 before adding to 994i so that's not the issue.