wmcneil

@danncas The sensor is running on batteries. You can tell this by the fact that there is a Wake Up device. In order to either read or write parameters, you will have to first wake up the sensor by pressing the zwave button once. The sensor will stay awake for a brief period, just long enough to read or write a parameter. You read a parmeter by right clicking on the Security Alarm device / Zwave / Set Configuration Parameter / Query. You write a parameter with the same interface, selecting Set instead of Query.

Some more info from UD (from my ticket dialog): Blank values are created by IoX only by the following two events: 1) Reboot 2) Query with blank result. So if the device is not awake when the query is done, and the query does not cause the device to wake, then the query will have a blank result. This is what is happening with my ZSE11. A workaround is to do a query only when the device is known to be awake. In the case of the ZSE11, I can follow a motion sense event (or the nth occurrence of a motion sense event, to reduce queries and therefore battery consumption) immediately with a query. So to summarize, the two behaviors that the ZSE11 has that create the issue are: 1) No ability to set a minimum interval for Battery Level reporting 2) Query does not cause the device to wake if it is sleeping

I have done more testing, and had interaction with both Zooz and UD support: When the Zooz ZSE11 800 sensor (firmware 2.30) is running on batteries, it does not have any minimum reporting interval for Battery Level. When not awake, a query is ignored. A workaround that will cause Battery Level to be updated: If an IoX program detects a Motion Sense change, and then immediately does a query to the ZSE11 Security Alarm device (this is the device that displays Battery Level), the Battery Level is updated. Clearly the Zooz design would be much improved if it supported a minimum interval for reporting Battery Level. I did not get any sense from their tech support that they took this point. In the past, I have observed that if a long period of time (not sure what the minimum is) goes by without a Battery Level value being reported, the Admin Console (AC) will eventually change the Battery Level field to be blank. I have asked UD (in a ticket), what value gets reported if a program is using the Battery Level status and it shows as blank in the AC, and have not heard back.

In the First Alert app, there is a message saying that it will be migrating to Resideo Connect.

I was able to get both of my Honeywell T10+ Pro thermostats paired by uninstalling/reinstalling HomeKitHub. My Lutron Caseta hub is still being added during the discovery process (not clear why it is being seen as a HomeKit accessory by HomeKitHub), but I am leaving it unpaired and it does not seem to be causing problems, AFAIK. The thermostats seem to be working properly.

I noticed something that may be a clue about something being wrong. In the table, the "LAN host:port from last DISCOVER (informational; optional)" has the value of the local IP of my Lutron Caseta hub. I am also running the Caseta nodeserver.

@Jimbo.Automates , I am trying to pair a Honeywell T10+ Pro for the first time. I believe I am following the directions exactly, and each attempt I make to do a DISCOVER and then save the pairing code. I am getting a "pairing code rejected" message. I have verified that the thermostat has not timed out of pairing mode at the time I enter the pairing code in the Custom Typed Configuration Parameters row. The node server is running on an eisy with software releases shown below inline. I have also attached the node server log file *** OS *** FreeBSD eisy 14.4-RELEASE-p6 FreeBSD 14.4-RELEASE-p6 #5 releng/14.4-n273726-3d95ec875867-dirty: Wed Jun 24 07:24:18 PDT 2026 root@bsdev144.isy.io:/usr/obj/usr/src/amd64.amd64/sys/eisy amd64 *** Hardware *** eisy-home-next (UPC: 00857386003206) *** Package Information *** ************ UDX ************ udx-5.0.0 Name : udx Version : 5.0.0 Installed on : Wed Aug 19 13:35:46 2026 EDT Origin : misc/udx Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : misc Licenses : Maintainer : michel@universal-devices.com ************ IoX ************ isy-6.1.1 Name : isy Version : 6.1.1 Installed on : Wed Aug 19 13:35:41 2026 EDT Origin : misc/isy Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : misc Licenses : Maintainer : michel@universal-devices.com ************ libwebsockets ************ libwebsockets-4.3.3 Name : libwebsockets Version : 4.3.3 Installed on : Wed Aug 19 13:36:21 2026 EDT Origin : net/libwebsockets Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : devel net Licenses : MIT Maintainer : ports@FreeBSD.org ************ tpm2-tools ************ tpm2-tools-5.6_2 Name : tpm2-tools Version : 5.6_2 Installed on : Wed Aug 19 13:43:31 2026 EDT Origin : security/tpm2-tools Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : security Licenses : BSD2CLAUSE Maintainer : tstruk@gmail.com ************ eisyui ************ eisyui-1.2.2 Name : eisyui Version : 1.2.2 Installed on : Sun Aug 23 15:27:53 2026 EDT Origin : misc/pkg Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : misc Licenses : Maintainer : benoit@universal-devices.com ************ iox_matter_bridge ************ iox_matter_bridge-1.3.24 Name : iox_matter_bridge Version : 1.3.24 Installed on : Wed Aug 19 13:35:38 2026 EDT Origin : misc/pkg Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : misc Licenses : Maintainer : benoit@universal-devices.com ************ mosquitto ************ mosquitto-2.0.18 Name : mosquitto Version : 2.0.18 Installed on : Wed Aug 19 13:36:21 2026 EDT Origin : net/mosquitto Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : net Licenses : EPL Maintainer : joe@thrallingpenguin.com ************ pg3x ************ pg3x-3.4.23 Name : pg3x Version : 3.4.23 Installed on : Sun Aug 23 15:28:00 2026 EDT Origin : misc/pg3x Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : misc Licenses : MIT Maintainer : benoit@universal-devices.com *** Networking Information *** re0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> ether 00:21:b9:02:67:e1 inet 10.55.83.194 netmask 0xffffff00 broadcast 10.55.83.255 inet6 2605:a601:9b42:5100::1006 prefixlen 128 pltime 4500 vltime 7200 inet6 fe80::7176:badd:1585:bdee%re0 prefixlen 64 scopeid 0x1 inet6 2605:a601:9b42:5133:964:eb02:8a54:e092 prefixlen 56 autoconf pltime 14400 vltime 86400 inet6 fdd0:3a7c:f054:b267:74c5:e0c0:6c7f:e092 prefixlen 64 autoconf pltime 1800 vltime 1800 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=1<PERFORMNUD> lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 groups: lo nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> *** USB Devices *** ugen0.1: <XHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen0.2: <CP2105 Dual UART Bridge Silicon Labs> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen0.3: <AX201 Bluetooth Intel Corp.> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) *** Upgrade Status **** UDX_UPGRADE_STATUS="inactive" HomeKitHub_8-28-2026_105843_AM.zip

My recent unsuccessful attempts are documented here Note that the First Alert app is going to be replaced by the Resideo Connect app. That will be the 4th name/app change so far.

Wow, that's some serious customization!.....I am using scenes as well.

Digging some more, I see the On command allows a % to be specified, and that is working.

I am using the ZMatter ZWave dongle. I have installed several Smartwings roller shades with ZWave motors. I am not seeing a way to request that a shade be moved to a partially open value. The various commands (EX: Fade Up, Fade Down) will cause the shade to open completely, or close completely, but I do not see a way to request partially open?

No. It showed 100% immediately after it was included, then subsequently became blank and has remained blank.

The battery level was reported after including the zse11 with batteries only. It subsequently became blank and has remained so.

After some 36 hours have passed, the Battery Level field is now blank. Per the documentation, it should be updating at least every 4 hours: I have the threshold parameters (183,184,185) set to zero, and the reporting frequency (172) set to 4 hours. The documentation states that parameter 172 is not applicable to the 800 series version of the zse11, but it is present and set to 4 in my zse11 800LR .

I updated from firmware 2.0 to firmware 2.30 . It was necessary to do an exclude, then an include with a power supply connected in order for the firmware update to work. After then excluding, then including with batteries only, the 1011 icons are now gone. The Battery Level is being reported as 100%. The batteries are fairly new, so it remains to be seen how the reporting works as the batteries age.

Update: In the AC, all the ZSE11 devices had the 1011 icon shown. I did a right click/Write Changes followed by a press of the zse11 zwave button. The Battery Level field then showed 100%. The 1011 icon remains after the Write Changes has (apparently) completed. I'll have to wait and see if the Battery Level field updates going forward. The 1011 icon is supposed to indicate that there are pending changes for the device. The fact that the icon persists may indicate an issue?

I have a Zooz ZSE11 800LR that uses battery-only power, and was included with battery-only power applied. I have parameter 172 Reporting Frequency set to 4 hours, and parameters 183-185 (temp, humidity, and lux reporting thresholds set to to 0). Per the zooz documentation (https://www.support.getzooz.com/kb/article/1003-zse11-q-sensor-advanced-settings/?section_id=251), this should result in battery level being reported every 4 hours, but the Battery Level field remains blank forever. Anyone else have this issue?

I have not used tasker. Could you provide more details on how to, say, have a alarm.com motion sensor being triggered be passed by tasker from the alarm.com app to the UD mobile app? thanks in advance!

So you are using the tasker mobile app? And updating variables via UD Mobile?

I have purchased a new home which has alarm.com security sensors cameras, and a Qolsys IQ Panel 4 control panel. I am curious if anyone has any experience with an integration path to eisy. For example, anyway to get motion sensor triggering out of alarm.com and into eisy? I have seen some tidbits that indicate that Home Assistant may be able to receive events, but I have never used Home Assistant, so that would be a big learning curve, and require HA hardware best I can tell. In general, the alarm.com system is intentionally all closed. No APIs for use with anything else. Another example, the security cameras are disabled from supporting onvif....I have to pay a monthly fee even for self monitoring. As someone who has installed Elk systems in all my previous homes, I am frustrated with the closed system aspect of alarm.com. The alarm.com mobile app is decent, but I have no integration with eisy. I am thinking through if I am frustrated enough to replace hardware and put in an Elk system. Putting in an Elk system is not a small expense or a small amount of work either. So I'm interested in feedback from anyone else that has gone down this road.

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?