Door locks that support open/close detection

Add-ons Bindings
1

My August lock reports not only the condition of the lock, but it also reports whether the door is opened or closed based on a sensor that’s integrated into the lock. This negates the need for a separate open/close sensor. Other locks may have this functionality, but I don’t specifically know of any at this time.

The door open/close indicator is included in the doorcondition byte in position bit 0 (Table 36 in the Z-Wave Command Class spec).
doorcondition

Currently, it looks like the binding doesn’t do anything with the doorcondition field. This field could be used to populate a sensor_door or sensor_binary channel.

@chris WDYT?

2

This should be possible. I suspect many locks don’t provide this, but we can probably have the option to add this channel into the database, and then populate it if it exists.

Let me have a look at it over the next couple of days.

3

Thanks. Makes sense.

Want me to add an issue so that it can be tracked? Or, hold off on that until you look at it more closely?

4

For others who want to see if their door lock reports open/close status, there’s a debug statement that starts with Door-Lock state report that shows the value of the doorCondition byte. Bit 0 would change based on the door being opened or closed.

5

Yes please.

Please link to the database for your lock so I can add the channel without having to work out exactly which database entry it is :slight_smile: .

6

@mhilbush note that the channels will change as the current door channel uses the sensor_door channel. I will change this to what it should be which is lock_door and then use the sensor_door for the door state.

Sorry for changing the channels - I know you’re not so happy with such change, but I think it’s the best approach.

7

I agree it’s the best approach. My main objection concerned the deletion of channels for no obvious reason (at least it wasn’t obvious to me). :wink:

Thanks!

8

I’m officially confused.

My current item definition is this, which already uses lock_door.

Switch BasementDoorLock "Basement Door Lock [%s]"  { channel="zwave:device:zstick:node94:lock_door"}

And the thing definition in the current binding also shows lock_door.

    <channels>
      <channel id="lock_door" typeId="lock_door">
        <label>Door Lock</label>
        <properties>
          <property name="binding:*:OnOffType">COMMAND_CLASS_DOOR_LOCK</property>
        </properties>
      </channel>
    ...
    </channels>
9

Then I’m confused as well, as the database doesn’t show this -:

image
image.png652×630 37.9 KB

This shows that the sensor_door channel already exists, and the lock_door has been added.

However, in the documentation (which also comes from the database, but a slightly older version), it does confirm what you see -:

image
image.png1012×324 28 KB

So, I guess that someone has updated the channels in recent times :frowning: . Anyway, this will move it back again.

1 Like
10

FTR -:

@mhilbush there is a link on GH to a precompiled version - it would be great if you can test this.

11

Working on it now. Thanks!

12

@chris When I deleted and rediscovered the lock, I’m not seeing the door_sensor channel.

While the database entry looks right, I don’t think the August ASL-03 thing definition got updated to include the new channel.

13

Hmmm - I did a complete database update, so I assumed it should have been included…

14

Just looked at that PR. There’s a wording change to the asl-03, but the new channel’s not there.

15

Strangely it doesnt seem to be there…

16

Ok, I think the issue is the exporter isn’t expecting multiple channels for this command class, so it’s just exporting the first one it finds…

I’ll update this…

17

Ah, that would explain why the channel wasn’t there when I did an export…

18

Yep - I think so :slight_smile:

The exporter is updated - I’ll do a build in a few minutes…

19

Ok, the JAR is updated. I kept the link the same, so the JAR has the same filename as before - slightly confusing with the time, but the link remains the same…

20

One thing I want to mention unrelated to this change…

After installing the new binding (this latest one and the previous one), all my nodes are showing Request NIF in HABmin, although in the log I clearly can see the nodes completing initialization. Did something change that would cause this?