ZWave-JS created a door status sensor - is this a bug?

So I have a Yale YRD210 deadbolt lock. It has no way of knowing whether the door is physically closed or open. To solve this I’ve added a separate door sensor. However, the ZWave-JS integration created a door status sensor for this door.

What is this sensor for? Is it a bug?

It’s a sensor for the door latch, not the door. Is the confusion about the name of the entity in HA?

EDIT: Actually, the value you highlighted in zwavejs2mqtt is not the same entity. It appears to be the one named 11-98-0-doorStatus.

So the “door status” is something the lock reports as part of the door operation report. It’s one of the “Door condition” fields. Here’s what the spec says:

I’ll admit, reading that doesn’t really answer the question for me either, but the “door status” sensor is the bit 0 value of that field.

1 Like

Yea, thanks for the help, but now I’m even more confused. The language is confusing in that screenshot. It has latch, (dead)bolt, and door. I have no idea what latch could be and the lock doesn’t have a way to detect if the door is open or closed.

That sensor has not changed state since I last restarted HA two weeks ago. And that door gets used plenty. So I don’t think it can be tied to anything that actually gets operated. From what what I recall, it also doesn’t have any way detect the battery door being off.

Any further help is appreciated!

FWIW - it seems Zwave-JS and lock states are generally broken. I have two Kwikset locks and, while I can trigger them, no entity Zwave-JS provides will show me the current lock state other than always “open”. Looking in the Zwave-JS GUI console I can see the state is triggered there. I don’t know if it is “them” or “us” (the integration).

There is a blueprint that will update the status for 910 locks.

What’s 910 locks?

It’s not generally broken. Some older Kwikset models send alarm codes instead of state values. You can manually refresh them using an automation when an alarm comes in signaling a state change. We’re working on adding a workaround.

I’d agree with @majorsl that from the perspective of the user, the lock state reporting is broken. It sounds like you can do a workaround to make it function, but out of the box, it’s broken. This is the same for my lock. Although I’m not sure if there’s anything else not working as all of my nodes (3 total) aren’t working correctly.

Yeah, to someone new it appears to be broken because “it just doesn’t work”. Can and have I worked around it? Yes. That might not be true for everyone.

HOWEVER, with that said, both Zwave-JS and this integration are still new. The sheer amount of improvement with both each time I upgrade is just amazing. The people who work on this are gods among men to me.

It’ll get it there.

1 Like

This should be fixed and was fixed several versions ago (last 2-3 weeks). If you’re still seeing it not work you need to open an issue on the project so we can find out why. It should just work now without the refresh.

Yes, it definitely has. I noticed that my 910 started working a couple of months ago. My converted 888 didn’t start working until very recently.

That’s because you’d need to reinterview the device for it to pickup the new config file. Likely something happened to cause it to reinterview (e.g. you changed a setting).