Guy Lavoie

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

Yes, I'd boot it up into bios configuration mode and check settings.

I'd quesdtion the USB-A to USB-C adapter before the USB-C port on the eisy, especially if your old 2413S was working fine on that same USB-C port.

The only thing that comes to mind: did you also remove the USB to serial adapter?

You can view release notes in eisy-ui. Go to the System page, and for the very latest updates (staging release) enable the staging repository and then click on the question mark to see the release notes.

No, 6.1.1 is the current production release.

Your "pkg upgrade" includes udx? If so, I'm puzzled.