Guy Lavoie

Ok, I played around with scenes a bit. It's very well done, though not fully intuitive the first time. You bring up the scene, and you'll get the list on the right, with the controller(s) at the top and the responders below, and controller/responders below that. You try clicking on the items and nothing happens... What you're seeing is a summary of the scene, not an item select list. You need to click on the little ">" to the left of the controller line, which will expand the list to a series of boxes where you can then select and edit each individual item. You click on a box and you'll get an edit screen for On level, ramp rate, etc. One done, click on the "v" of the controller to collapse the list again. The listing of "Shared Comnmands", "No Conflict Commands" are an excellent addition, telling which commands will work for everything in your scene, vs which ones will only be meaningful for some devices. So a color change command won't do anything to a non-color device, etc. The link type shown is also a great improvement. Admin Console would show it, but no real explanations. Not something you'll usually need to mess with, but now you can make changes if needed. Hover your mouse pointer over the circled "i" for information. "Native" links are the ones where IoX "knows" that these device communicate directly, such as Insteon commands between linked devices. Default links are those where IoX knows it need to send a command to make something happen, such as send an On command to a zwave device in an otherwise Insteon triggered scene. Very well done!

Start by doing: sudo sh and enter the admin password. This puts you in superuser mode, and can go anywhere.

You access the main menu items by clicking on the three little lines at the top left corner. In the list, scroll down to Protocols -> Insteon. There you'll get a screen where you'll find all the options for configuring Insteon devices. I'm seeing this in eisy-ui 1.3.11-1

32 GB. A 64 GB will also work.

The X Y color chart is harder to use than RGB because it's not as intuitive in terms of numbers vs colors.

I'm actually going to study that more in depth. Eisy-ui shows more internal details about scenes that's very interesting, including what's done directly between devices vs done by the controller.

Yes, I used the 4th one down.

That's right, the ZMatter board ended up not having anything to do with Matter. It could have, but in the end, a border router turned out to be the way to get Thread functionality.

I'll eagerly await your follow-up on this.

Yes, and I've extensively used that, such as displaying a red, open shackled lock for unlocked, and a black, closed shackled lock when locked. Great feature! It would be great if we could create our own icons for this. The only current way is with a link to an image url. I'd like to create opened and closed garage door icons, for example.

Thanks for the detailed explanation. I'll certainly check that out. I like customization and this sounds interesting.

I'm interested in exploring this. Do you have an example of a REST command that does just that? I can't find any listing of the specific properties that would be added to a /rest/nodes/<node> command.

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.