johnnyt

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.

@joembz and @ISY4Me, I just migrated from 994i to IoP 5.6.0 - starting the process that it is late 2 days ago. One of the issues I'm seeing is that, although all my ZEN17 nodes were there on 994i, I lost both sensors and can't seem to get them back using methods other than excluding and reincluding them at this point. I'm saving that as the last resort. Aside from the pain of firing up a laptop to bring my AC close to each device it will break multiple programs that will need to be fixed afterwards. So far UD support suggested power cycling the ZEN17 (after checking that the parameters were ok - they were) but that didn't fix the problem. I've done lots of "Update with Interview", "Update Neighbors", and "Heal Network", as well as querying other device nodes in case that would help but no joy. UD Smart add would certainly make getting close the three ZEN17s I have in use however my portal license didn't move over to IoP despite my following the instructions, so I can't use UD mobile until that gets fixed. I presume UD smart add implies exclude/include process but please correct me if it can do some magic without that. I haven't used UD Mobile for anything but the occasional viewing of some device states, and in an attempt to set up an eisy, which didn't work at all (probably because I have my untrusted IoT devices - where UD mobile runs - are on a separate VLAN/subnet as my HA (ISY) stuff, with both separate from my trusted devices) FWIW, my parameters 2/3 are 10 (dry contact), and params 10/11 are at 0 to decouple sensors and relays. More to come on this.

Am hoping to move from 994i to IoP this weekend. I don't believe any of my zwave devices linked with any security (or should I say they are linked with S0 if I understand correctly). What happens during migration? I'm guessing I end up with all/only S0 security on all my devices and that I would need to exclude/include every device (and fix every programs that points to it) if I wanted to link them with more than S0 security. It's in that context that I ask how important is Zwave security?. I don't have any close neighbors with any zwave devices, assuming that would be part of the calculation. any info would be appreciated.

Consider trying this (at your own risk, of course): Take two backups. With one of the backups, open it using 7z and look for file "NTCLIST.CFG " in the MAIL subfolder. If it's there, delete it and restore that modified backup to see if it fixes the problem. If it causes problems rather than fix them, you will have the other untouched backup to restore. I recently saw my backup shrink without justification and, worried about my upcoming migration to IoP, I looked for file differences between the smaller and last larger backups. I found the smaller one did not have "NTCLIST.CFG ", which was a comparatively large xml file full of my custom notifications. Despite it not being there, all my custom notifications were still there, and a restore of the file on a blank (test) eisy (minus NODES and SCENES because I did not want it to take over my devices) showed the notifications where still there. I asked UDI support about this and they told me the file is "a cached version of some of the information stored in the custom notifications. It may disappear at times but can always be recreated when needed". They may not suggest doing something that requires you to mess with the backup so maybe that's why they didn't offer you a fix. Or maybe it's completely unrelated, but, if it goes as it did for me, you at least won't be any worse off. And if you are worse off, you have the untouched backup to restore. Be warned that ISY backups don't save web server files if you use the built web server for logging as I do. (If you don't know what I'm talking about, it won't be a problem) Hope this helps.

@dwengrovitz Was this fixed in 5.6.0? I don't see it mentioned explicitly in the release notes but was it maybe included under "Minor bug fixes"?

Is there a way - in PG3 - to migrate the node servers I have linked to my 994i to IoP, or do I have to reinstall each one again and configure them from scratch (what I ended up doing in the past during some testing)? Both are using the same PG3 3.1.20 instance on the same Polisy, and both have an active portal license. If this is done automagically during migration from 994i to IoP, that's what I'm really looking for right now. Even if this is the case, knowing how to do this outside the context of a h/w migration would be good to know as I will eventually want to also use some of the NS on IoP on an eisy. Not having to re-install/reconfigure them one at a time would be a time saver. (Any required NS license purchases for new h/w would be done, of course.) Apologies if this is posted somewhere. I looked but didn't find the info.