Bumbershoot

@Chris Jahn, my GoControl garage door openers are now operating normally and reporting status. All other Z-Wave devices are operating correctly as well, as far as I have tested. I didn't migrate, however. I excluded on my Polisy and included them on my eisy. My Z-Wave network isn't all that extensive.

I'm not trying to be a jerk, but when you start working with libraries, package managers, file layouts, etc., it can be, and some of the solutions in this thread are wandering into that territory. But for the most part, it doesn't practically matter.

FreeBSD gents, not Linux. Lots of similarities, lots of differences.

I don't know what's going on here, but if you start reading at the post linked to below, you might see what has been happening: The solution in my case was to issue the following command at the command line: sudo service udx restart

If you're on a Polisy and know how to ssh into the box, then this worked for me yesterday: sudo service udx restart There's an upstream package associated with MongoDB that breaks things, and that has caused this problem for UDI and Polisy/eisy users. You might start reading at this post for more information:

This is on my eisy: I can't tell you when the updates were released to the repositories, but PG3x was upgraded on my machine to 3.1.22_3 on Feb. 8th in the afternoon. Again, on my machine only, IoX was upgraded from 5.5.5_1 to 5.5.5_2 on the morning of Feb. 6th. I never saw any release notes, so I don't know if anything interesting to the user community was fixed/changes. The updates could simply be due to compatibility reasons with other packages. UDX gets fairly frequent updates, and I've never seen release notes for that. I suspect UDI prefers to keep that secret sauce to itself.

Give restarting udx a try in you're comfortable at the command line: sudo service udx restart

Back up and running on both Polisy and eisy. sudo service udx restart

I got a response to my ticket. sudo service udx restart Back up and running.

Bingo... EDIT: I recall that a stated goal of PG3 was to get rid of MongoDB. Maybe UDI is getting ready a release that'll do just that, and this update somehow escaped into the wild a bit early.

I'm pretty sure this is PG3 related, and not due to changes in the network stack (I'm currently logged into both boxes from the command line). There are no PG3 instances on either machine at the moment. For the cause of this issue, my money is on either the mongo driver getting uninstalled, or a conflict with node19 and PG3.

Yep, I think you're right. I don't have a PG3 instance running on either Polisy or eisy at the moment. PG2 is running on my Polisy. UDX and ISY are running on both.

It has been rebooted, more than once.

Be careful updating the packages on either Polisy or eisy at the moment. I updated packages on both this morning - I used the "Upgrade Packages" button on the Configuration tab on the AC - and IoX isn't playing along on either machine after a reboot. I've opened a ticket. Below are the salient items from the log: Installed packages to be REMOVED: mongo-c-driver: 1.8.1 New packages to be INSTALLED: node19: 19.5.0 [udi] Installed packages to be UPGRADED: libbson: 1.8.1 -> 1.23.2 [FreeBSD] xmlsec1: 1.2.34_1 -> 1.2.37 [FreeBSD]

Until this morning. I just updated my Polisy, and IoX and PG3 aren't playing along (I can't get to the AC and automations aren't working). The portal shows the machine is offline. Below is a snip from the log... All repositories are up to date. Checking for upgrades (21 candidates): .......... done Processing candidates (21 candidates): .......... done The following 4 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: mongo-c-driver: 1.8.1 New packages to be INSTALLED: node19: 19.5.0 [udi] Installed packages to be UPGRADED: libbson: 1.8.1 -> 1.23.2 [FreeBSD] xmlsec1: 1.2.34_1 -> 1.2.37 [FreeBSD] Number of packages to be removed: 1 Number of packages to be installed: 1 Number of packages to be upgraded: 2 The process will require 43 MiB more space. 10 MiB to be downloaded. [1/3] Fetching xmlsec1-1.2.37.pkg: .......... done [2/3] Fetching node19-19.5.0.pkg: .......... done [3/3] Fetching libbson-1.23.2.pkg: .......... done Checking integrity... done (1 conflicting) - node19-19.5.0 [udi] conflicts with node18-18.13.0 [installed] on /usr/local/bin/corepack Checking integrity... done (0 conflicting) Conflicts with the existing packages have been found. One more solver iteration is needed to resolve them. The following 6 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: mongo-c-driver: 1.8.1 New packages to be INSTALLED: node19: 19.5.0 [udi] Installed packages to be UPGRADED: libbson: 1.8.1 -> 1.23.2 [FreeBSD] xmlsec1: 1.2.34_1 -> 1.2.37 [FreeBSD] Number of packages to be removed: 1 Number of packages to be installed: 1 Number of packages to be upgraded: 2 The process will require 43 MiB more space. Fetching node18-18.13.0.pkg: .......... done [1/6] Deinstalling mongo-c-driver-1.8.1... [1/6] Deleting files for mongo-c-driver-1.8.1: .......... done [2/6] Deinstalling node18-18.13.0... [2/6] Deleting files for node18-18.13.0: .......... done [2/6] Installing node18-18.13.0... [2/6] Extracting node18-18.13.0: .......... done [3/6] Upgrading xmlsec1 from 1.2.34_1 to 1.2.37... [3/6] Extracting xmlsec1-1.2.37: .......... done [4/6] Installing node19-19.5.0... pkg: node19-19.5.0 conflicts with node18-18.13.0 (installs files into the same place). Problematic file: /usr/local/bin/corepack Fri Feb 10 05:25:02 PST 2023|/usr/local/etc/udx.d/static/udxops.sh: upgrading packages successful ... Fri Feb 10 05:25:02 PST 2023|/usr/local/etc/udx.d/static/udxops.sh: checking base packages ... Updating FreeBSD repository catalogue... FreeBSD repository is up to date.

As I understand it, you can't use those accounts. They're used for node servers and other connecting devices.

PG3 on Polisy is back to working.

Just curious, but can't you bypass discovery by using a .yaml file? They're kind of a PITA to create, but this post indicates that this technique still works on an eisy. I'm still on Polisy, so I'm not having this issue.

I have a multimeter, but I'm none too proficient with it. I'll give it a go, though. There were no lights on the Polisy at all. When I plugged it in I could hear a faint ticking sound, but that even went away after a few minutes. I robbed another device, and I'm back in business. In true UDI fashion, I'm being sent another power supply. I've also ordered an eisy, so I'll have a useful backup system again... A few hours of down time, and all is well again.

Okay, I found one that fits (robbing Peter to pay Paul here), and yes, it looks like it's a power supply issue. Back up and running. Thanks.

My Polisy Pro decided not to boot up this morning. Seems odd, as it has been running without issue since I got it. The power adapter shows a very dim blue light when it's plugged in, and I'm wondering if that's not the problem. This is probably a dumb question, but how bright is the light on other folks power supplies? The light on mine can barely be seen if there's any ambient light. I don't know of any way to test it, other than plugging it in my Polisy.

On my iMac (Apple M1 chip running macOS Ventura 13.2) the Activity Monitor app reports that the ISY Launcher is using 1.81 GB of memory, using more memory than any other app on this system. EDIT: That's the running footprint for the AC, not the startup values for the Java app that launches it.

The passwords aren't connected. Change it in the console.

I think that the GPL license (which is a copyleft license) caused issues for UDI, ruling out Linux. The FreeBSD license is permissive. https://en.wikipedia.org/wiki/Permissive_software_license

I'm really not sure what you're trying to do, but I set the on level of several Insteon dimmers to a variable in a single program: KitchenLights - [ID 0077][Parent 000A] If $s.KitchenLights is not 1000 Then Set 'Devices / dirKitchen / sldKitchenSink' On '$s.KitchenLights %' Set 'Devices / dirKitchen / sldDining' On '$s.KitchenLights %' Set 'Devices / dirKitchen / sldKitchenIslandSouth' On '$s.KitchenLights %' Set 'Devices / dirKitchen / sldKitchenIslandNorth' On '$s.KitchenLights %' Set 'Devices / dirKitchen / sldTrackLightSouth' On '$s.KitchenLights %' Set 'Devices / dirKitchen / sldTrackLightNorth' On '$s.KitchenLights %' Set 'Devices / dirKitchen / sldUnderCounter' On '$s.KitchenLights %' Else - No Actions - (To add one, press 'Action') This program is used to interface with Alexa, and uses a STATE variable ($s.KitchenLights) to set a brightness value for the lights in the kitchen. "Alexa, set the kitchen lights to 50" will set the STATE variable to 50, which causes this program to run. I also use the "adjust scene" functionality on groups of dimmers that are included in a scene.