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.