wmcneil

I figured it out - as is frequently the case, it's a dumb mistake - numeric IP address was off by 1.

My Hue Emulator node server no longer has any entries in its Spoken Device Table. I have attached the log, and provided a snipet below. The messages indicate that the node server is not able to communicate with the eisy. A couple of days ago I updated from IoX 6.0.4 to 6.0.5, but I'm not absolutely certain whether the problem with the Hue Emulator started at that point, or possibly at some earlier point. Here are the exact versions of everything as reported in eisy-ui: IoX 6.0.5_10 UDX 4.5.0_7 PG3x 3.4.19 eisy UI 1.0.9 Matter Bridge 1.3.24 mosquitto 2.0.18 libwebsockets 4.3.3 2026-07-05 00:00:02.139 Thread-23579 (handler_poll) udi_interface ERROR Controller:shortPoll: Thread is dead, restarting. 2026-07-05 00:00:02.608 ConnectISY udi_interface WARNING Controller:set_listen: Set to 1 2026-07-05 00:00:02.609 ConnectISY pyisy ERROR connection:request: ISY Could not receive response from device because of a network issue. 2026-07-05 00:00:02.610 ConnectISY pyisy ERROR isy:__init__: PyISY could not connect to the ISY controller with the provided attributes. 2026-07-05 00:00:02.610 ConnectISY ISYHueEmu ERROR ISYHueEmu:connect: ISY not connected, will try again 2026-07-05 00:00:02.696 Thread-23580 (handler_poll) udi_interface WARNING Controller:longPoll: Listen Count = 5 HueEmulator_7-5-2026_101052_AM.zip

Update: I tried to revert to Resideo Smart Home app (from First Alert app). This was not successful. One of my Honeywell thermostats would not register with the Resideo Smart Home app, and resideo tech support directed me to use First Alert app instead of Resideo Smart Home (since they are migrating everyone - new installs and anyone who calls with a problem). After I got both my thermostats working with the First Alert app, I tried again to authorize the API client. When prompted for the resideo credentials, I used my First Alert credentials, and I am getting a "username or password is incorrect" message. So since the Honeywell node server is no longer being maintained, it looks like things are not going to work with the First Alert app. For the benefit of anyone trying to use a Honeywell thermostat, I can confirm if you use the zwave version instead of the wifi version you will be able to natively add the thermostat to IoX. (I purchased a home that has the wifi versions, but I have used zwave versions in past houses with no issues.)

When I attempt to authorize the API client to communicate with Honeywell by going to https://udi-honeywellhome-auth.azurewebsites.net , entering my Client Id and Secret, I receive the prompt to log in to Honeywell Home. When I enter my credentials, I get a message stating "Please use an account with one or more devices installed." The Honeywell Home credentials I am using are the ones I use for the newest Honeywell Home app on my phone. That app is the First Alert app, and that app shows two thermostats present. If anyone else has encountered this, and found a workaround for it, please reply. It may be the case that only accounts using the Honeywell Home app are supported, and not those using the First Alert app? The Honeywell Home app is still available, although supposedly it will eventually be replaced by the First Alert app.

I don't see query as a choice. If I select Action / Your Devices / <Office Shade> the three choices I have are: Open Close SetOpenLevel Is there some other way to specify a query?

Update: After restarting the Caseta node server, shade device status seems to be updating promptly in AC.

I observe that updates to a shade status (posiition) that occur from a physical pico remote or the Lutron mobile app are not reflected in IoX for what appears to be a very long time. Is there a way for an IoX program to force a query?

Yes, using multiple device commands in an IoX program results in them being executed sequentially, so the multiple shades are not synchronized. Yes, I tried creating Lutron scenes and that works to keep the multiple shades in sync.

In my eisy, the pico-main device has no available status that a program could use. The pico-fav device does have available status. It is certainly possible to have an IoX program control multiple shade devices at the same time. I have tried this, and it works. The shades do not move together in nearly perfect synchronization as they do when the physical pico remote is controlling them, but they do arrive at the requested setting. I tried using an IoX scene to group the shades. That did not work well. Not all the shades moved properly, and the status of shades became confused in IoX

I have a Pico PJ2-3BRL which is programmed to operate multiple Lutron shades simultaneously. I am using a Lutron L-BDFPRO2 hub. After installing the Caseta nodeserver, the IoX AC shows two pico devices, a pico-main and a pico-fav (each shade is also present as a separate device). The pico-main has no available commands or status. The pico-fav has six available settings for "send command": On Off Brighten Dim FastOn FastOff. How in IoX can I perform the equivalent of, for example, pressing the Open button on the physical Pico remote?

Yes, there are a least a couple ways to bridge it over, either electrical relay or audio detection.....I'm trying to figure out how much is or is not possible with the alarm.com hardware....I'm a long time eisy and blue iris user, and the alarm.com system is really "against my religion".

I have purchased a home which has alarm.com sensor hardware (mostly zwave), and a Qolsys IQP4003 panel. If anyone has found a path to control at least the security functions via eisy I would be most interested. The alarm.com is a closed system, and even with the subscription, there are some huge missing features. Like no bridge between the smoke alarms and the security panel!

The credentials that are required are a function of what port you are attempting to access, not what method you are using to access the box. Here is a summary: Access methods available with any version of IoX: Interface protocol port Credentials Invocation --------------- -------- ---- ----------- --------------------------------- AC http 8080 local start.jnlp -> http://BOX_IP_ADDRESS:8080 AC https 8443 local start.jnlp ->https://BOX_IP_ADDRESS:8443 Additional access methods available when IoX >= 6.0.0 : Interface protocol port Credentials Invocation --------------- -------- ---- ----------- --------------------------------- EISYUI http 80 ISY_Portal http://BOX_IP_ADDRESS EISYUI https 443 ISY_Portal https://BOX_IP_ADDRESS AC http 80 ISY_Portal start.jnlp ->http://BOX_IP_ADDRESS AC https 443 ISY_Portal start.jnlp ->https://BOX_IP_ADDRESS

UD asked me to upgrade packages and try again. I did so and then tested with three users defined (user 2 and 1, as well as the default user 0 which is reserved for manual turns of the deadbolt) Everything seems to be working correctly now. These are the updates that were applied: IoX 6.0.3_3 -> 6.0.4_1 UDX 4.2.0 -> 4.2.0_2 PG3x 3.4.6 -> 3.4.9

I have opened a ticket. Michel responded and reported that myself and another user reported the problem. UD is investigating root cause.

Yes, the update to 6.0.3 happens on any reboot, without having pressed the update button. More info about that here: https://forum.universal-devices.com/topic/46113-reboot-automagically-causes-update-to-iox-603_3/#findComment-400793 There are additional upgrades available(to UDX 4.2.0, PG3x 3.4.6, and easyui 0.8.5), I have applied them, and the problem with my kwikset deadbolt user number reporting remains.

Thanks, yes, I have now fixed the version number in my post.

I have an eisy running IoX 6.0.3_3, and the zmatter dongle. I have a kwikset zwave 620 deadbolt. The deadbolt has been in my zwave network for over 1 year. The following behavior has started recently: When the deadbolt is unlocked by a human entering any valid user code on the keypad, the User Number reported in the Access Control Alarm entry in the AC is a 10-digit number. It is a constant value, regardless of which user code is entered. Previously, the User Number would be the correct user number corresponding to the code that was entered. Since the 620 supports only 250 users, a 10-digit number should not be possible. Before I start trying to chase this further, I thought I would see If anyone else has seen this behavior. If so, please post. Thanks.

@mmb, I also had the same problem with Firefox. Completely clearing the cache solved the problem for me.

@bmercier, since your statement above that "There are no cases where updates would be done automatically" is not correct (per Michel's response above), if possible, please remove the Solution tag from your post further above.

Explanation from Michel in response to the ticket I opened as to why 6.0.3 installs automatically upon reboot (without update button having been pressed): "...the reason is that 6.0.0 had an issue with libxml-2 library. So, once the packages were upgraded, it would no longer start and thus would not even give you the ability to login to the Admin Console to do the upgrade. Since we removed the capability for upgrade using the front power button (it had its own issues), our only choice was to reinstall it upon reboot. "

I have opened a ticket. Will post back with update once it is resolved.

It seems likely that the update to 6.0.3 is happening "automagically" on reboot without the update button having been pressed. If anyone else has experienced this, please post and let me know, so I can be absolutely certain before I open a ticket.

Hmmm, this happened on two different boxes, an eisy, and a polisy. In both cases, prior to the reboot, they were running IoX 6.0.0_4 . I could see that maybe I accidentally clicked on update on one of the boxes without realizing it, but seems less likely that it happened on two different boxes. The only package that actually "automagically" updated was IoX, so if your theory is correct, I would have had to accidentally done the update on both boxes before about 12/1, otherwise other packages would have updated too....Anyway, thanks for the pointer, good to know.

Rebooting either an eisy or a polisy (yes, I have both) that is running IOX 6.0.0_4 causes an update to 6.0.3_3 , WITHOUT any update being requested. Why is the update occurring when no update was requested? After the reboot and automagic update to IOX 6.0.3_3, eisy-ui / settings / system shows the following additional updates now available: UDX available update from 4.0.4 to 4.2.0 PG3X available update from 3.3.23 to 3.4.6 eisy-ui available update from 0.7.2 to 0.8.5 There is no release announcement for IOX 6.0.3 . Will there no longer be release announcements?, or was the one for 6.0.3 an accidental "miss"?