Guy Lavoie

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.

So it's not fully working? Where are you seeing the FreeBSD version? I check ith with "uname -a", and it says 14.3 Release p5. Have you tried a full reboot, with power off?

if you did the full update command posted earlier in this thread (sudo pkg upgrade udx isy eisyui pg3x) your version of FreeBSD should be 14.3. Don't forget that you might need to enable the repository every time from now on (sudo repo.util prod) for upgrades to work. Yes, you should be able to point your browser the the ip address and get a login prompt, asking for your UDI account login.

For my experience, I've been running on the latest production version (6.1.1) just fine on my eisy. I try the beta stuff on a Polisy that I use for testing.

Yes, it actually upgrades things during the reboot. It's not automatic, you need to tell it to reboot. Do : sudo reboot Eisyui does install and work on a Polisy. That's what I'm using to test out these new versions (I have three Polisys that I use for testing). Maybe eisyui couldn't upgrade because it wasn't there to begin with, coming from 5.9.1. Do the reboot, and then try the eisyui pkg upgrade again after. You might need to use "pkg install eisyui" instead of "pkg upgrade eisyui"

Failure is not an option! 😄 This is also a golden opportunity to add new functionality, and some of these new features are already showing up.

More like later today! @Techman just alerted me to a new PG3x update 3.4.24. I installed it and it fixed my plugin update issue. Thanks to UDI for the quick fix!

I just came across this, and updated to 1.3.7. But I still cannot update a plugin. It just doesn't do anything when I click on update.