#Z-Wave Door Sensor Missing Events

1 messages · Page 1 of 1 (latest)

knotty sentinel
#

TL;DR: I have a Zooz door sensor that misses open/close events often enough to be annoying - maybe 1 in 20. I’ve tried everything I can think of to eliminate the usual suspects (usb extension, 800LR, direct line of sight, beefier HA host, fresh battery, firmware updates).

Looking for ideas on what to check next to see what might be happening.

The long version:
I have a Zooz ZSE41 door sensor on my front door that misses open or close events often enough to be problematic - missing ~1 in 20 or more. I live in a concrete condo building, my unit is about 1200sqft, my HA host and Zooz ZST39LR controller are roughly central. The front door is a metal fire door. The sensor is mounted to the door, the magnet on the frame. I’ve done the following (not in order) things to try to eliminate the usual suspects:

I migrated my HAOS host from a Raspberry Pi to a much beefier Proxmox VM on a very well provisioned host to eliminate concerns with memory/cpu constraints and power availability for the USB Z-wave controller; I added a 2M/6.6ft USB 2.0 extension cable to get the controller as far away from everything else that has power or radio, dangling in free air, with direct line of sight to the door sensor at a distance of 20 feet 9 inches unobstructed; I updated the firmware on the controller to the latest 1.50; I updated all HAOS and Z-WaveJSUI components to the latest available versions; I excluded the door sensor and re-included it as an 800LR device to eliminate any issues with repeaters or extra network hops; I replaced the battery with a brand new fresh name brand battery (without the bitter coating); I enabled the indicator light on the sensor to visually confirm that it recognizes each physical open/close action (it does); I setup an automation to know when HA thinks the door is propped due to a missed close event; I checked the Z-Wave logs when a close event was missed and confirmed I see the open event and there were no log entries generated when the door was closed.

stone trail
#

Sounds like you have done a good job at eliminating the most common issues. I still think it's a connectivity problem.

Is there a chance you can bring the controller close to the end device for a test or vice versa?

If it then keeps working it would confirm the suspicion.

keen urchin
#

I had a door sensor that acted like that, the problem was the magnet was slightly too far away for it to be reliable. Behavior would fluctuate as the temperature changed.

knotty sentinel
# keen urchin I had a door sensor that acted like that, the problem was the magnet was slightl...

that was my first thought -- i've had suspicions about door sensors being really finicky and not recognizing doors - especially metal doors, and especially when being slow closed. i turned on the indicator LED and tested all manner of opening and closing (slow, fast, slam, etc)... and i also watch every time i open and close the door now and it registers 100% of the time - I have never in the last 10-15 weeks of testing seen it miss an open/close event according to the LED indicator - even when the event doesn't register with ZUI/HA.

knotty sentinel
# stone trail Sounds like you have done a good job at eliminating the most common issues. I st...

thanks for the tips and links! the door sensor is glue adhesived to the door so nothing I can do there. the proxmox host is mounted to a small network rack in a closet that's about 19 feet from the door. I have the controller on a 2 meter usb2 extension connected to a usb2 port. I have it hanging in the doorway of the closet right now so that it has about a 20'9" direct line of sight to the door sensor. best I could do here is rig up some string to hang it in the middle of the hallway get that down to maybe 19'.

i'd like to turn on supervision for the door sensor. i don't have a very chatty network -- a handful of water sensors, 3 door sensors, and a few temp/humidity sensors that i've configured the report intervals to be relatively quiet. i found that Zooz ZSE41 supports Supervision V1 but... for the life of me I can't figure out how to turn it on in ZUI?

keen urchin
#

There's no option to do so, you'd have to ask Zooz if they could enable that in firmware

knotty sentinel
#

I have the ZSE41 800LR

keen urchin
#

It means the controller (driver) can issue commands with Supervision

#

Well it could mean both, but not guaranteed that the device sends commands with supervision

knotty sentinel
#

i'd see that in the current log if it was, yes?

keen urchin
#

right

#

My smoke alarms use supervision to send notifications, which makes perfect sense

#

You could argue a door sensor should too

#

Pretty sure my zsse41 is using supervision actually for reports

knotty sentinel
# 
2025-02-06 19:53:57.933 INFO Z-WAVE: [Node 256] Value updated: 113-0-alarmLevel 0 => 0
2025-02-06 19:53:57.935 INFO Z-WAVE: [Node 256] Value updated: 113-0-Access Control-Door state (simple) 23 => 22
2025-02-06 19:53:57.936 INFO Z-WAVE: [Node 256] Value updated: 113-0-Access Control-Door state 23 => 22
2025-02-06 19:54:00.413 INFO Z-WAVE: [Node 256] Value updated: 113-0-alarmType 0 => 0
2025-02-06 19:54:00.415 INFO Z-WAVE: [Node 256] Value updated: 113-0-alarmLevel 0 => 0
2025-02-06 19:54:00.416 INFO Z-WAVE: [Node 256] Value updated: 113-0-Access Control-Door state (simple) 22 => 23
2025-02-06 19:54:00.417 INFO Z-WAVE: [Node 256] Value updated: 113-0-Access Control-Door state 22 => 23
2025-02-06 19:54:00.488 INFO Z-WAVE: [Node 002] Value updated: 38-0-targetValue 99 => 0
2025-02-06 19:54:00.489 INFO Z-WAVE: [Node 002] Value updated: 38-0-currentValue 99 => 0
2025-02-06 19:54:01.573 INFO APP: GET /health/zwave 301 0.302 ms - 162```
keen urchin
# 
Feb 06 16:54:57 zui[33589]: 16:54:57.829 DRIVER « [Node 060] [REQ] [BridgeApplicationCommand]
Feb 06 16:54:57 zui[33589]:                       │ RSSI: -52 dBm
Feb 06 16:54:57 zui[33589]:                       └─[Security2CCMessageEncapsulation]
Feb 06 16:54:57 zui[33589]:                         │ sequence number: 94
Feb 06 16:54:57 zui[33589]:                         │ security class:  S2_Authenticated
Feb 06 16:54:57 zui[33589]:                         └─[SupervisionCCGet]
Feb 06 16:54:57 zui[33589]:                           │ session id:      21
Feb 06 16:54:57 zui[33589]:                           │ request updates: false
Feb 06 16:54:57 zui[33589]:                           └─[NotificationCCReport]
Feb 06 16:54:57 zui[33589]:                               notification type:   Access Control
Feb 06 16:54:57 zui[33589]:                               notification status: 255
Feb 06 16:54:57 zui[33589]:                               notification state:  Window/door is closed
# 
Feb 06 16:54:57 zui[33589]: 16:54:57.838 DRIVER » [Node 060] [REQ] [SendDataBridge]
Feb 06 16:54:57 zui[33589]:                       │ source node id:   1
Feb 06 16:54:57 zui[33589]:                       │ transmit options: 0x24
Feb 06 16:54:57 zui[33589]:                       │ callback id:      0
Feb 06 16:54:57 zui[33589]:                       └─[Security2CCMessageEncapsulation]
Feb 06 16:54:57 zui[33589]:                         │ sequence number: 228
Feb 06 16:54:57 zui[33589]:                         │ security class:  S2_Authenticated
Feb 06 16:54:57 zui[33589]:                         └─[SupervisionCCReport]
Feb 06 16:54:57 zui[33589]:                             session id:          21
Feb 06 16:54:57 zui[33589]:                             more updates follow: false
Feb 06 16:54:57 zui[33589]:                             status:              Success
Feb 06 16:54:57 zui[33589]:                             duration:            0s
knotty sentinel
#

[SupervisionCCReport]

#

neat

keen urchin
#

There's no configuration knob, so not sure how many times it will try

knotty sentinel
#

i'm trying sillylogs now

keen urchin
#

no, just debug

#

silly is overkill for 99% of the time

#

If writing to log files is not a huge concern, just leave debug logging on permanently

knotty sentinel
#

now that i'm not on an rPi i could do that....

# 
2025-02-06 20:06:29.817 DEBUG MQTT: Publishing to zwave/Kitchen/Front_Door_Sensor/113/0/alarmType: { time: 1738890389817, value: 0 } with options { qos: 1, retain: true }
2025-02-06 20:06:29.818 INFO Z-WAVE: [Node 256] Value updated: 113-0-alarmType 0 => 0
2025-02-06 20:06:29.819 DEBUG MQTT: Publishing to zwave/Kitchen/Front_Door_Sensor/113/0/alarmLevel: { time: 1738890389818, value: 0 } with options { qos: 1, retain: true }
2025-02-06 20:06:29.819 INFO Z-WAVE: [Node 256] Value updated: 113-0-alarmLevel 0 => 0
2025-02-06 20:06:29.821 DEBUG MQTT: Publishing to zwave/Kitchen/Front_Door_Sensor/113/0/Access_Control/Door_state_simple: { time: 1738890389821, value: 22 } with options { qos: 1, retain: true }```
#

that's the open event, don't see anything about supervision in this (or any other) message in the log so far

keen urchin
#

wrong logs

knotty sentinel
#

door sensor is [Node 256]

keen urchin
#

nope, not driver logs

#

check the link again

knotty sentinel
#

yep I was on the wrong section on the doc you sent (I'll blame that I'm on a Mac which i'm very much not used to) -- this should be the driver log:
https://pastebin.com/fDtcqyLE

interesting bits start around here:

                                  │ RSSI: -87 dBm
                                  └─[Security2CCMessageEncapsulation] [INVALID]
                                      error: Security2CC_NoSPAN
2025-02-07T02:09:07.787Z CNTRLR » [Node 256] No SPAN is established yet, cannot decode command. Requesting a non
                                  ce...
2025-02-07T02:09:07.789Z DRIVER   one or more queues busy```
keen urchin
#

that one would be normal

#

if the event does not show up in the driver logs, then the controller did not see it

#

thus HA could not possibly see it. so you'd need to establish one or the other.

knotty sentinel
#

boggles the mind that with a completely silent network, the door sensor is configured for Supervision, the LED indicator fires and the message (and any retries) don't make it to the controller

keen urchin
#

You'd basically need to setup a Zniffer to see if the device is sending the message.

#

If the debug log doesn't show the message, than either the device never sent it, or it was somehow missed.

#

Maybe Zooz didn't program Supervision to do anything

#

I could probably sniff my network and see if it does

knotty sentinel
#

Zniffer was next on my list of things to try. I found the docs and a video on the HA/ZUI site -- but wasn't 100% clear. do I need a second controller to run the regular network and Zniffer at the same time?

keen urchin
#

you'd need the 800 dev kit to sniff LR

#

yes they are separate

#

You can run both in a single instance of ZUI though, or on a separate host. Or windows Zniffer software as well.

knotty sentinel
#

got it - I have a spare identical ZST39 800LR controller, but it's not at firmware 1.50 yet

#

one thing I did notice, on all my zooz sesnors (door and temp) the payload always says "request updates = false"

                                  │ RSSI: -93 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 51
                                    │ extensions:
                                    │ · type: SPAN  sender EI: 0x664be9dd6d479676b1cf2421c6c84906
                                    │ security class:  S2_Authenticated
                                    └─[SupervisionCCGet]
                                      │ session id:      21
                                      │ request updates: false
                                      └─[NotificationCCReport]
                                          notification type:   Access Control
                                          notification status: 255
                                          notification state:  Window/door is open```
#

but on my homeseer hsm200 motion sensor, it's always true:

                                  │ source node id:   1
                                  │ transmit options: 0x25
                                  │ callback id:      184
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 222
                                    └─[SupervisionCCGet]
                                      │ session id:      36
                                      │ request updates: true
                                      └─[ColorSwitchCCSet]
                                          Red:      0
                                          Green:    0
                                          Blue:     255
                                          duration: default```
keen urchin
#

This flag is used to allow a receiving node to advertise application status updates in future Supervision Report Commands.

As an example, this flag must be set to allow a supporting node to immediately advertise the <WORKING> status in a Supervision Report Command and subsequently advertise the <SUCCESS> status in another Supervision Report Command once the operation has been completed.

#

I don't quite understand what that means, but in my log I posted above, Z-Wave JS responded regardless of that flag.

#

I think it just means it can respond with Working or Success. Not sure ZJS needs to respond with Working.

#

Makes more sense for something like an actuator that is in the process of doing something, I think.

#

Also, the flag means:
Value Required Behavior
‘0’
Only return a report now
‘1’
Return a report now and more later if needed

knotty sentinel
#

been running some of this thru chatgpt, had this to say re: request updates:
request updates: false means the sensor does not expect periodic updates (just a one-time confirmation).

keen urchin
#

I guess that sounds about right

#

The ColorSwitchCCSet log is also a request coming from Z-Wave JS, it's not a request from the device. ZJS is requesting status updates.

knotty sentinel
#

any value in trying to include the sensor w/o security?

keen urchin
#

I'd say no, but you could try. You'd have to exclude and re-include w/o LR.

knotty sentinel
#

LR forces security?

keen urchin
#

Yes, it's a requirement

knotty sentinel
#

woof

keen urchin
#

Everything uses S2 now

#

At least with S2 it's possible to see if something was corrupted (decryption failed). No security it could flip bits into some other message.

knotty sentinel
#

ChatGPT seemed to think these RSSI numbers are pretty bad:
2025-02-07T02:20:14.625Z DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -108 dBm
channel 1: -110 dBm
channel 2: -110 dBm
channel 3: -98 dBm

keen urchin
#

lol

#

stop talking to chatgpt

#

-110 is probably the best you can achieve with a 800-series

#

-98 could be better, I think that's the LR channel

#

power with LR is dynamic, your report above was showing -93 dBm which seems a bit low though.

#

don't confuse the background RSSI (noise floor) with the end device signal strength

knotty sentinel
#

Node 258 is a bit farther away than Node 256... but still maybe only 30 feet direct line

#

I think I might be down to Zniffer to see if literally anything is coming out of the door sensors. the way the debug logs look... even unexpected encrypted messages for which there is no existing SPAN are logged ... i'd expect the ZUI Debug to show something - even if it was jibberish at this point

#

unless DEBUG log doesn't show events where the driver picks up nonsense and drops it silently

keen urchin
#

I think it should at least show a SERIAL log

knotty sentinel
#

that's what I would expect

#

and if supervision works anything like TCP... even if the first message got completely lost to the ether, or stepped on.... statistically you'd expect the retry to come through

#

I did open a ticket with Zooz on the Supervision side... will see if they have any wisdom

keen urchin
#

I don't think a retry is guaranteed

#

I can configure my smoke detector to have 0 retries

#

not sure why you'd use supervision in the first place then

#

(kind of the point)

#

I predict Zooz will ask you to factory reset it

knotty sentinel
#

my temp sensors have supervision which i'd love to be able to turn off

keen urchin
#

Zooz or something else? Doesn't look like mine are using it.

knotty sentinel
#

Zooz ZSE44

keen urchin
#

Same, no supervision here

Feb 06 15:01:56 zui[33589]: 15:01:56.750 DRIVER « [Node 259] [REQ] [BridgeApplicationCommand]
Feb 06 15:01:56 zui[33589]:                       │ RSSI: -63 dBm
Feb 06 15:01:56 zui[33589]:                       └─[Security2CCMessageEncapsulation]
Feb 06 15:01:56 zui[33589]:                         │ sequence number: 20
Feb 06 15:01:56 zui[33589]:                         │ security class:  S2_Authenticated
Feb 06 15:01:56 zui[33589]:                         └─[MultilevelSensorCCReport]
Feb 06 15:01:56 zui[33589]:                             sensor type: Air temperature
Feb 06 15:01:56 zui[33589]:                             scale:       Fahrenheit
Feb 06 15:01:56 zui[33589]:                             value:       69.3
knotty sentinel
# 
                                  │ RSSI: -83 dBm
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 25
                                    │ extensions:
                                    │ · type: SPAN  sender EI: 0xb90699f28ddaaabc8b1d04673a292747
                                    │ security class:  S2_Authenticated
                                    └─[SupervisionCCGet]
                                      │ session id:      8
                                      │ request updates: false
                                      └─[MultilevelSensorCCReport]
                                          sensor type: Humidity
                                          scale:       Percentage value
                                          value:       78```
keen urchin
#

weird.

knotty sentinel
#

mine isn't the 800LR version

keen urchin
#

I was going to ask

knotty sentinel
#

I do have some of those, but not at this location. i don't have access to the other location at the moment

keen urchin
#

fw version?

knotty sentinel
#

1.30.1

keen urchin
#

latest, wonder if they changed it for 800

#

Apparently my ZEN15 is using it for meter reports. That's not critical for my purposes, I'd turn it off.

#

lol, that's even in the docs there "devices enable this for power meters."

knotty sentinel
#

omg. i have one of those on my washing machine at the other location. chattiest thing ever

#

even with the updates dialed way back it still talks a lot - didn't realize it was doing that supervised

#

i'll see what kind of guidance I can get out of Zooz

keen urchin
#

FYI, ran zniffer to capture the ZSE41, when the controller is offline there's no retry

#

n/m, it actually does. 4 times.

#

It's interesting though:

  1. If controller is plugged in and ZJS is shutdown, the controller will Ack but there's no Supervision Report response, still ZSE41 will not retry
  2. If controller is unplugged, there is no Ack from the controller and ZSE41 will retry the command 3 times
#

The retries (if that's what they are) are also pretty aggressive? delta 81ms, 43ms, 26ms.

stone trail
stone trail
keen urchin
keen urchin
#

also, since it's LR there's no other route. 🙂

stone trail
#

Timeouts for LR are really short

keen urchin
#

is 4 the backup channel?

stone trail
#

I don't actually know. So far I though there are only 4 and the devices use one or the other as #3

keen urchin
#

the last one was on channel 4, usually 3

stone trail
#

Plenty of people I'll see today that I can ask 🤣

keen urchin
#

Cool, have fun.

#

Line 7 is when I shutdown ZUI, but left the stick powered

#

Funny the Ack was good enough

#

Line 24 when I unplugged it

keen urchin
#

Ahh, I guess it was those channel 4 messages that tripped up the Z-Wave JS Zniffer.

#

maybe

stone trail
#

Maybe

#

Could actually be that it tries the backup channel once, Z-Wave JS doesn't expect that

knotty sentinel
#

I’m still waiting to hear back from Zooz on how they (think they) handle supervision retries, but— even if the retry interval under normal circumstances was 80/40/20ms — I’d think at least one of those would have made it to the controller on a quiet network. Even if it showed up just as a serial message it couldn’t decode.

#

Looking into Zniffer, I assume it’s not recommended (or even possible) to use a spare ZST39 800LR- better to get a dedicated setup like ZGM230-DK2603A 800 series development kit

keen urchin
#

Yeah, not possible

#

The retries in that zniffer are on the protocol (RF?) level, not from Supervision, only occur if the controller doesn't Ack. The device does not care if a Supervision Report was returned or not, based on the controller Acking but the software being offline.

#

Pretty sure the device should check for a Supervision Report, otherwise their was no point in using it.

knotty sentinel
#

well this is a bit of a disappointing response from Zooz:

Since this is a coin battery-operated device, we also carry about battery lifespan, and that is one of the reasons we do not implement any re-tires in lost messages by the controller on the application level.```

i'm going to ask if the firmware could be made flexible to allow retries to be configured by the end users rather than just outright disabled. next to smoke detectors, i'd argue that door open/close messages are probably the most important signals you can send - and maybe motion. if messages can just be lost to the ether it really erodes any confidence in the system and we'd be better looking to more robust devices :/
knotty sentinel
#

this is what I've sent in case you are feeling spicy and want to request the same:


I kindly request the option to enable and configure retransmissions as a configuration parameter, allowing users to balance reliability and battery life based on their needs. Thank you for considering this enhancement!```
keen urchin
#

I wonder why they are using Supervision at all.

#

I'm not sure they know the answer.

knotty sentinel
#

I did ask that in my email 🙂