Bumbershoot

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.

I've been looking through the product list, and it appears that I could replace a lot of my Z-Wave installation with YoLink devices. Hmmm. It looks like the API is cloud based, which is a disadvantage to Z-Wave. The good news is that I mostly want simple reporting when I'm away on many of my Z-Wave devices, so if the Internet is down, I won't get updates anyway -- no loss going with YoLink, provided their cloud is up. It looks like these are the supported devices in the node server: 'Switch', 'THSensor', 'MultiOutlet', 'DoorSensor','Manipulator', 'MotionSensor', 'Outlet', 'GarageDoor', 'LeakSensor', 'Hub', 'SpeakerHub', 'VibrationSensor', 'Finger', 'Lock', 'Dimmer', 'InfraredRemoter', I see most of what I'd want...

I see Yo Link as a thermocouple sensor, and they brag about the distance these things can transmit. You'd have to buy a hub and pay for the node server ($10/perpetual), so there's some expense. I agree with @vbphil on the range of the Wireless Tags. I've used several outside, and they worked reliably, even out towards 100'. They're in the 430-439MHz frequency range, so the signal propagates well. I have on in the freezer in the garage, probably 80' from the tag manager, and it never misses.

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.

Based on the use case I'm thinking of for a few of these devices, there doesn't seem to be any showstoppers in that they don't report "Status" based on local control. I don't think I would have any need for programs to evaluate the status of any of the devices. I would want to set up scenes, however, and possibly run a couple of "adjust scene" programs in the evening and early morning hours. I might just purchase a few and retire some Zen77's. Also, I like that they can act both as a dimmer and an on/off switch. Ergonomics matter, and I prefer the ergonomics (and performance) of Insteon hardware to the Zen77's.

The migration to an eisy will be mostly painless if you're not invested in Z-Wave. It amounts to not much more than backing up you ISY994i and restoring it to the eisy. You'll want to update both to the latest and greatest firmware before you do it, and there might be a few cleanup chores, but for the most part, it should be quite easy.

Ah, but there is. See this post. New PLM's are due in March.

Thanks for helping with this. It's a nice device, and it I hope UDI and Insteon can make it possible for IoX to support it.

No, it never occurred to me to do that. Good news, though, this data is from a quick on and off from the device: Mon 01/30/2023 14:32:13 : [INST-SRX ] 02 50 60.11.12 00.00.01 CF 11 00 LTONRR (00) Mon 01/30/2023 14:32:13 : [Std-Group ] 60.11.12-->Group=1, Max Hops=3, Hops Left=3 Mon 01/30/2023 14:32:13 : [INST-SRX ] 02 50 60.11.12 4A.A3.BA 40 11 01 LTONRR (01) Mon 01/30/2023 14:32:13 : [Std-Cleanup ] 60.11.12-->ISY/PLM Group=1, Max Hops=0, Hops Left=0 Mon 01/30/2023 14:32:13 : [INST-DUP 2 ] Previous message ignored. Mon 01/30/2023 14:32:13 : [INST-SRX ] 02 50 60.11.12 11.02.01 CF 06 00 (00) Mon 01/30/2023 14:32:13 : [Std-Group ] 60.11.12-->11.02.01, Max Hops=3, Hops Left=3 Mon 01/30/2023 14:32:13 : [INST-INFO ] Previous message ignored. Mon 01/30/2023 14:32:14 : [INST-SRX ] 02 50 60.11.12 00.00.01 CF 13 00 LTOFFRR(00) Mon 01/30/2023 14:32:14 : [Std-Group ] 60.11.12-->Group=1, Max Hops=3, Hops Left=3 Mon 01/30/2023 14:32:14 : [INST-SRX ] 02 50 60.11.12 4A.A3.BA 40 13 01 LTOFFRR(01) Mon 01/30/2023 14:32:14 : [Std-Cleanup ] 60.11.12-->ISY/PLM Group=1, Max Hops=0, Hops Left=0 Mon 01/30/2023 14:32:14 : [INST-DUP 2 ] Previous message ignored. Mon 01/30/2023 14:32:14 : [INST-SRX ] 02 50 60.11.12 4A.A3.BA 45 13 01 LTOFFRR(01) Mon 01/30/2023 14:32:14 : [Std-Cleanup ] 60.11.12-->ISY/PLM Group=1, Max Hops=1, Hops Left=1 Mon 01/30/2023 14:32:14 : [INST-DUP 2 ] Previous message ignored. Mon 01/30/2023 14:32:15 : [INST-SRX ] 02 50 60.11.12 13.02.01 CF 06 00 (00) Mon 01/30/2023 14:32:15 : [Std-Group ] 60.11.12-->13.02.01, Max Hops=3, Hops Left=3 Mon 01/30/2023 14:32:15 : [INST-INFO ] Previous message ignored.

Yes, it is. I found 3 instances of this device in the link table.

This may be interesting. If I turn on/off the scene from the other SwitchLinc dimmer in the scene (which is also a controller), then the "Status" for this i3 device updates in the AC. The "Status" only fails to update when the i3 device is controlled locally. Controlled from the AC or other linked devices, then the "Status" updates normally.

Okay, I did a restore. Here's a screenshot of the link tables. The device still isn't updating the status in the AC, however.

Here you go. This second screenshot may be more interesting:

Looks like it does work as a switch, as well. The instructions in the Quick Start Guide worked. EDIT: Successfully set it back to dimmer mode as well. That functionality seems to work.

There's nothing in the Event Viewer. I'll sniff around in the logs later today. EDIT: Gotta run for a bit, but here's a snippet from the system log (these are the two devices in the scene): Devices / dirGuestBedroom / sldGuestVanityLight Status Off Mon 2023/01/30 07:06:47 System Unknown 60.11.12.1 Status Off Mon 2023/01/30 07:06:47 System Unknown

I actually added it using UD Mobile. I just used the "Set" button to add it.

Later today I'll see if I can set it up as an On/Off switch.

The i3 dimmer does indeed control the load on the other SwitchLinc in the scene. The only difference I have found so far is that the "Status" isn't updated in the AC.