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.