Guy Lavoie

I agree with @Geddy here, 5.9.1 is probably the oldest release that you can still directly upgrade from...for now. Play it safe: do backups of IoX, zwave and anything else you have. And don't do an upgrade on a Friday night, where getting help from UDI would be more difficult for a few days.

Any progress or update on this?

Yes, now that you have the ability to reimage it. The new image also probably has it as a newer release to begin with, making any problem that much less likely.

It might be that if you upgraded the bootloader prematurely, that intermediate version upgrades might not be compatible. That kind of thing can happen.

Being of the "if it ain't broke, don't fix it" school of thought, I thought I'd wait a bit to see how this played out for the others trying it first. But thanks to @junkycosmos for taking the plunge and getting a discussion going on this previously overlooked subject. After seeing the discussion for a few days, I thought I'd take the plunge today. I have two of these ZMatter boards, one on my production eisy, and another one on one of my test Polisys. So I went ahead and did the test Polisy first. Both of my boards were originally installed as internal boards on Polisys, so I figured they would have the older firmware. Both have since been "donglized", so easy to upgrade. The ability to confirm it in the xray, DH controller screen showed they were both 7.32. A few notes about the upgrade process: for the virtual serial port I chose the "CP210x Windows Drivers" option (4th choice down), unzipped it to a new directory on my PC, and then opened that directory and ran "CP210xVCPInstaller_x64" on my Windows 11 PC. The program found my ZMatter dongle and confirmed it was 7.32. The upgrade choice was 7.45. I didn't get the intermediate version 7.35 others have seen. That went well. I then not only needed to reboot (unplug and replug the dongle) but also exit and reenter the upgrade program in order to detect the upgraded dongle again. That made for a few tense moments...) Then as suggested by the original poster, I had to upgrade the bootloader in order to finally upgrade to 7.46. I also clicked on the additional features link to enable the long range and faster communications options, and as @junkycosmos noted, the options aren't stilll checked as installed in the updater, though the options link show them as installed. That's not clear. After all that was done, I put the dongle back on the test Polisy and rebooted it. It worked 😊. And my existing devices were still there, both zwave and zigbee. Emboldened, I then proceeded to do the same with my eisy dongle, and everything worked the same way. PS I didn't know I could hold my breath for so long!

One question: did your existing Zwave network stay intact after doing these updates, or was a backup first needed then a restore? Also, any updates pertaining to zigbee?

Being at a version older than 5.9.1, you'll probably need UDI's help to upgrade, which means opening a support ticket.

Are all your devices zwave, or do you also have Insteon (especially in your initial list of "about 35 switches/dimmers, and probably 12 or so outlet plugins", and various battery sensors? If you have a mix of technologies, that might help in getting an idea if it's a communications issue or the controller itself. If you do have Insteon, are there any pending writes (little red wave icons beside some devices in admin console)? That can slow things down while updates are being attempted. Another Insteon communications issue hint is direct commands between devices, like scenes triggered from a switch or keypad. If those are sometimes slow, then there might be a problem there. If both insteon and zwave become slow at the same time, then it does sound more like a controller issue. A tight loop in a program can be hard to find.

Ugh...

Hah, Like I said I have very few zwave devices, and 5 of them are locks. Still, I just thought I'd give the Replace Failed Node thing a try, and it doesn't seem to work very well... I tried it on my test Polisy that has a ZMatter dongle. I started by adding a simple zwave on/off plug in module. Then I did the Replace Failed Node command on it, which caused the related nodes to disappear. No ther messages or anything. Then I plugged in another zwave mode of the same type and pressed the link button. It linked the new module and gave it the same node names...but trying to use the node name in any program wouldn't work. I'd get nothing on the program line. Saving an reloading the program would then show "Response type 0" on the invisible line I had added. Then trying to add it again to a program shows "Set '<not specified>' DON". So that feature doesn't seem to work. The IoX backup you mention backs up programs, variable, nodes, etc but not your hardware zwave dongle data. That is done by clicking on Backup under the Zwave menu. That is meant to save the network configuration, such that you should be able to put in a new replacement dongle and then click on Restore to get back your existing zwave network. That's what I meant in my previous post about having a zwave backup. With the earlier Zooz dongle, this wasn't even offered. I initially had the Zooz dongle and when I tried the documented migration process to ZMatter, it never worked,a nd was told it indeed wasn't functional. Zwave can be a bit nasty for that.

Well, if it turned out to be some kind of migration configuration or driver issue, they'll update the process to avoid whatever the issue was. You might be one of the first to go from a Zwave board to Aeotec dongle, and on a Polisy too. That will also help in keeping the Polisy alive 😊. About redefining your devices: did you have a zwave backup (and restoring didn't work)? Or you just didn't have a backup at all? The thing with the zwave backup is that there is only one file, that gets overwitten everytime you do a backup, so you can't easily try older backups. Then there's the fact that node names will usually be different for a different zwave interface. Replacing a ZMatter board with another ZMatter board would be easier. If your old device nodes are all still there in your device list, you can use search and replace in programs to adjust the programs to the new node names. It's a manual process and it's a pain, but there just are no shortcuts. And that's after having excluded and re-included every zwave device to begin with. I went through that when I went from the Zooz 700 dongle to ZMatter. Thankfully I only had about 8 or 9 devices.

Let us know how it gets solved!

Zwave tab disappearing is odd. You could try setting zwave to on instead of auto in Configuration and reboot, see if that helps. Otherwise, open a ticket. The Aeotec dongle support is still new.

It should detect the USB device automatically. On one of my test Polisys, I took out the ZMatter board that was in it, turned it into a USB dongle, and simply plugged it in. If you just plugged it in, make sure you power cycle the Polisy after. That migrate option in the Configuration tab is a default thing with the rollback to Zooz. I don't have one of the newer zwave/zigbee dongles so I don't know how it gets configured, though the release announcement for 6.1.1 said that the dongles are now "detected automatically". I don't know if that Migrate option in the Configure tab has to be clicked for that to be enabled. You could try that. You might try opening a ticket with UDI. But are you saying that zigbee is working? With the new dongle? That would indicate that the USB port is indeed working and seeing the dongle, and that it's a zwave configuration thing.

Something you could try: enter the following url on your browser: http://<your_IP_address>:8080/rest/zmatter/zwave/deactivateZMatterZWave This should tell the Polisy to ignore the zmatter board and revert to looking for a Zooz stick. Then plug in your Aeotec stick and reboot the Polisy. See if that helps. But back up your zwave first (under the zwave menu), though I'm not sure if that will work if the board is bad.

Well, viewing the System menu in eisy-ui comes close to that. You can see the available upgrade versions, and those in beta and staging repositories too. You can also view their release notes, before upgrading.

Well launching updates from UDM isn't currently recommended, given the various implications with plugins, eisy-ui, etc.

What he's asking about is if we could add a way to programmatically enable/disable automatic writes to battery powered devices. By default this is enabled, and IoX tries to write the updates periodically, which slows down other Insteon communications. In admin console, this is triggered here:

Ah yes, found the following in the udx startup script: restart_timeout=20 #IF YOU WANT AUTO RESTART in case of failure, this has to be there . /usr/local/etc/udx.d/static/udx.rc So the remaining question remains why udx fails periodically on one of my Polisys. I should add a line to write the date and time to a log file in the same spot where the script beeps.

I'm trying to solve a little mystery here. I have three Polisys stacked, in my little lab setup. I use them for testing. Just this morning as I was doing other stuff, one of them beeped twice, like a Polisy does during a reboot (though a full reboot beeps three times). I don't know which one, but I've only really been using one of them a lot lately for testing the new releases of IoX and eisy-ui. This beep thing also happened a number of days ago. My first thought was to ssh into each one and look at the unix uptime: no reboots on either one. From my previous endless poking around in these things, I know that some of the beeps come from the udx startup scripts. So I looked at the running udx processes. The "Startup" column in ps -aux shows that udx_svc and udx_cmd have been running for some time, but then I sometimes see a second instance of one or both of these commands, with the startup time of the current time, as I issue the ps -aux command. These second copies quickly terminate. Seems to be happening quite often (I run a while loop every 5 seconds to see the udx processes). In one instance, I also saw it actually try to run the udx startup script, /usr/local/etc/rc.d/udx. I guess the attempt is so short that I just have to be lucky to catch the process on the fly. I'm not getting beeps, so it must always be failing the startup because udx is already running, though those beeps I heard means it must succeed every few days. I was thinking that maybe this is normal, to restart it in case udx failed for whatever reason. Just to be sure, I ran the same loop on the other two Polisys and on my eisy. Yes, they seem to be attempting regular restarts like that. So it means that I might be getting periodic udx dying events. The udx log file doesn't show anything unusual for the time when I heard the beeps this morning. Has anyone else noticed this kind of thing on their Polisy? It's not a problem or an operation issue for me, so I'm only asking casually, in the name of science! 😄

If you want to see the release notes, access your controller with eisy-ui and go gown to the System page. Beside each package version you'll see a question mark. Click on it to see the release notes for that package.

try this: log into admin console using IoX finder, but select "Admin Console (Cloud)" this time, which should upgrade your local copy of admin console on your controller, Then retry launching it from eisy-ui again.

That's the way I understand it, from Michel's explanation. So it is recommended to remove the inactive boot environment once the new one is validated to be working correctly.

Well, there seems to be enough survivors here saying that it works. Unless your application is very mission critical, I would be confident enough. Your call really. The release notes for that staging version do mention a fix to scheduled times.

In eisy-ui, go to System, and select the Staging repo, which will allow you to upgrade to 6.1.2_7