Schlage Connect ZWave Locks

ptdalen · May 12, 2018, 6:15pm

I actually bought a new lock same model number just to check. Same exact behavior. No worries thanks. I think that there have been changes to how these zwave locks are handled and I’ll just have to wait.

One of the articles I posted above talked about index 200 user codes and the alert class with open zwave.

It’s like like code slot is now passed as a single number is a different sensor index 200. The other sensor which does report tells me locked manual or unlocked with code.

Here’s the details from ththe OpenZWave article

inally, some Event types expose additional information, such as Location, or UserCodes. These ValueID’s will be present at Index 200 and will be created and deleted as different Events occur (so you can’t expect them to be present all the time).

A example of a Event that has additional information is with the Alarm_Access_Control Type and Alarm_Access_Control_KeyPad_Lock Event exposes a Additional ValueByte containing the UserCode Position that was entered on the device.

ptdalen · May 14, 2018, 6:01pm

OK,
So, Here are all events from an unlock with keypad

2018-05-14 07:27:23.794 Info, Node081, Received Alarm report: sensorSrcID=0, type:Access Control event:Access Control - KeyPad Unlock, status=true
2018-05-14 07:27:23.794 Detail, Node081, Refreshed Value: old value=0, new value=0, type=byte
2018-05-14 07:27:23.794 Detail, Node081, Changes to this value are not verified
2018-05-14 07:27:23.794 Detail, Node081, Refreshed Value: old value=1, new value=6, type=list
2018-05-14 07:27:23.794 Detail, Node081, Changes to this value are not verified
2018-05-14 07:27:23.794 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 113, Index: 200
2018-05-14 07:27:23.794 Detail, Node081, Notification: ValueChanged
2018-05-14 07:27:23.798 Detail, Node081, Notification: ValueChanged
2018-05-14 07:27:23.803 Detail, Node081, Notification: ValueRemoved
2018-05-14 07:27:23.804 Detail, Node081, Notification: ValueAdded

Again, I’m focusing on this exact line

2018-05-14 07:27:23.794 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 113, Index: 200

I’m beginging to understand some of the underlying terms.

So I I understand correctly CC: 113 is command class and index 200 is of course index 200
So here is CC 113, index 200 from my ozwcache file

<Value type="byte" genre="user" instance="1" index="200" label="UserCode" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="1" />

I’m i’m reading the error correctly
No Entry for ValueID

I believe it’s trying to write the user code value to VALUEID, which does not exist, its Value. Just like all the other indexes in Command Class 113. That makes sense to me why when I restart HA, the last used usercode does in fact end up in the Value for CC113 index 200, but never updates.

ptdalen · May 14, 2018, 6:21pm

Looking at when HA was first restarted I see this in the logs as well. This specific series of events never appeared again over the next couple of days (last time I restarted), but I understood this should refresh every time there is a command class alarm event.

2018-05-12 10:40:46.663 Info, Node081, Value Refresh triggered by CommandClass: COMMAND_CLASS_ALARM, Genre: 1, Instance: 1, Index: 0 for:
2018-05-12 10:40:46.663 Info, Node081,     CommandClass: COMMAND_CLASS_DOOR_LOCK, RequestFlags: 0, Instance: 1, Index: 1
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 255
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 254
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 10
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 11
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 12
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 13
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 14
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 15
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 26
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 27
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 28
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 29
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 99, Index: 30
2018-05-12 10:40:46.684 Info, Value size is invalid. Only 1, 2 & 4 supported for node 82, class 0x71, instance 1, index 9
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 113, Index: 9
2018-05-12 10:40:46.684 Info, Value size is invalid. Only 1, 2 & 4 supported for node 82, class 0x71, instance 1, index 10
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 113, Index: 10
2018-05-12 10:40:46.684 Info, Value size is invalid. Only 1, 2 & 4 supported for node 82, class 0x71, instance 1, index 11
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 113, Index: 11
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 113, Index: 12
2018-05-12 10:40:46.684 Warning, Localization::SetupValue: Localization Warning: No Entry for ValueID - CC: 113, Index: 200

firstof9 · May 15, 2018, 3:37pm

You might want to raise an issue or question with the OZW devs to find out what’s going on.

ptdalen · May 15, 2018, 3:54pm

great idea, Sorry, you were so knowledgeable, I thought you were one. haha. Any idea where the best place to start with that would be. Thanks again

firstof9 · May 15, 2018, 3:55pm

They have a discussion board on google.
https://groups.google.com/forum/#!forum/openzwave

ptdalen · May 16, 2018, 1:18pm

@winter - Bringing this discussion over from HERE.

I suspect you have 7 sensors tied to your BE469

lock.back_door_lock
sensor.back_door_lock
sensor.back_door_lock_access_control
sensor.back_door_lock_burglar
sensor.back_door_lock_power_management
sensor.back_door_lock_system
sensor.back_door_lock_usercode

Is this correct? Also in your openzwave log, can you confirm you are running 1.5 or higher.

Can you confirm that " sensor.back_door_lock_usercode" does not update when you unlock the door, but if you restart HA, it will show the last used usercode, but then not change any more until another restart.

I supect sensor.back_door_lock_access_control will update immediately if you manually lock, unlock, keypad lock or unlock, but the lock itself will not update in the UI, unliess you lock/unlock with HA either via automation or script or UI.

Does that describe your current situation?

winter · May 16, 2018, 5:00pm

Yes I am running 1.5. I compiled the Dev branch yesterday so currently sits at 1.5.3108.

I also have all the related sensors you are seeing. User code is missing right now, but that’s likely because I repaired the devices yesterday (in an attempt to fix the lock sensor).

Yes the lock.* sensor doesn’t update unless initiated from HA. I remember having this exact problem before in 1.4 but somehow resolved it. I think this might have had something to do with pairing without the security key though so this would be unrelated.

I will try tonight:

Unlock different user codes and observer sensor.*_usercode
Observe sensor.*_access_control more closely, but so far it does appear to update immediately on all lock/unlock methods.
Take a look at the different between the master and Dev branches to see if I can understand why the lock.* behaviour has changed.

winter · May 16, 2018, 5:16pm

Looking at the lock zwave.py in HA, it does appear to be capturing the access_control information and using this to update the lock status. For some reason this isn’t working anymore. I will try and add some debug to this tonight to see what is going on here.

def update_properties(self):
    """Handle data changes for node values."""
    self._state = self.values.primary.data
    _LOGGER.debug("Lock state set from Bool value and is %s", self._state)
    if self.values.access_control:
        notification_data = self.values.access_control.data
        self._notification = LOCK_NOTIFICATION.get(str(notification_data))

        if self._v2btze:
            if self.values.v2btze_advanced and \
                    self.values.v2btze_advanced.data == CONFIG_ADVANCED:
                self._state = LOCK_STATUS.get(str(notification_data))
                _LOGGER.debug(
                    "Lock state set from Access Control value and is %s, "
                    "get=%s", str(notification_data), self.state)

    if not self.values.alarm_type:
        return

    alarm_type = self.values.alarm_type.data
    _LOGGER.debug("Lock alarm_type is %s", str(alarm_type))
    if self.values.alarm_level:
        alarm_level = self.values.alarm_level.data
    else:
        alarm_level = None
    _LOGGER.debug("Lock alarm_level is %s", str(alarm_level))

    if not alarm_type:
        return
    if alarm_type == 21:
        self._lock_status = '{}{}'.format(
            LOCK_ALARM_TYPE.get(str(alarm_type)),
            MANUAL_LOCK_ALARM_LEVEL.get(str(alarm_level)))
        return
    if str(alarm_type) in ALARM_TYPE_STD:
        self._lock_status = '{}{}'.format(
            LOCK_ALARM_TYPE.get(str(alarm_type)), str(alarm_level))
        return
    if alarm_type == 161:
        self._lock_status = '{}{}'.format(
            LOCK_ALARM_TYPE.get(str(alarm_type)),
            TAMPER_ALARM_LEVEL.get(str(alarm_level)))
        return
    if alarm_type != 0:
        self._lock_status = LOCK_ALARM_TYPE.get(str(alarm_type))
        return

winter · May 17, 2018, 7:05am

So as far as I can tell, the missing sensors is “alarm_type”. Without this the update function just returns and never gets to setting the lock status.

Why is alarm_type now missing? I have no idea…

ptdalen · May 17, 2018, 12:48pm

So am I. This is with two different schlage be469 deadbolts, I have paired them 6 inches from my controller, and across the house with the same results. I even went as far as buying a brand new deadbolt just to make sure it was not old firmware (mine were a couple years old), it was the same. The only thing I could see that made my install different than most is the 1.5 version of open zwave. Everyone else was either running the stock version (1.4) or were running 1.5 but not with the schlage.

Also eveyone else does not have the “usercode” sensor, which I could only assume was the “newer” way of passing usercodes, but is not fully working.

ptdalen · May 17, 2018, 5:33pm

Wanted to throw this out there as well. I have a few zooz 4 in 1 zwave plus motion sensors. They are actually the last of my zwave devices I’m moving over because I dont have much of a need for them in my setup.

Anyway, I’m finding that although they do pair successfully, none of the sensors are reporting motion alerts.

These devices pair with as a secure node, successfully. They also report temp, humidy, light, and those seem to work.

While reading and asking questions it seems as if I am missing a sensor, that people have used for motion.

Guess what it is

alarm_level

Also there is a missing
alarm_type sensor.

Same as the locks.
I don’t think its coincidence.

winter · May 17, 2018, 5:50pm

I think you might be onto something. I have a eco link motion sensor and this is also missing alarm_level/alarm_type. I’m pretty sure it used to be there.

winter · May 17, 2018, 6:39pm

The Alarm class in openzwave has changed significantly from master to Dev.

Specifically in the master branch I see the following which shows the alarm_type and alarm_level being raised (Release):

           ValueByte* value;
           if( (value = static_cast<ValueByte*>( GetValue( _instance, AlarmIndex_Type ) )) )
           {
                   value->OnValueRefreshed( _data[1] );
                   value->Release();
           }
           if( (value = static_cast<ValueByte*>( GetValue( _instance, AlarmIndex_Level ) )) )
           {
                   value->OnValueRefreshed( _data[2] );
                   value->Release();
           }

In the Dev branch, this is still there, but restricted to a version 1 block. There is new code to differentiate between a version 1 and 2 alarm. V2 is commented as having more detailed information about the alarm and has all sorts of additional stuff.

V2 it’s missing.

Looking through my OZW logs, seems to be that I’m received a v2 alarm based on the format of the log message I’m receiving for all three of my alarm devices (2 schlage locks and a ecolink motion sensor).

So, where to next?

The most obvious thing would be to move the alarm_type and alarm_level code out of the v1 if block, so it executes for both v1 + v2, which is the behaviour in the master branch. I suspect this will fix things.
Figure out why this change was made in the first place and then submit a PR to get this into the Dev branch!

winter · May 17, 2018, 6:48pm

I raised an issue in openzwave:

https://github.com/OpenZWave/open-zwave/issues/1510

winter · May 18, 2018, 6:00am

After patching the openzwave code, I managed to get the lock functionality working again, not sure how reliable it is. I realised that I’m pretty sure my ecolink motion sensor was working, even without the Alarm fix.

I wonder if the HA code should be updated to support the v2 alarm code instead of trying to get the v1 to work. I’ll have to investigate more.

ptdalen · May 18, 2018, 1:05pm

I’d love to try to do this as well, but admit that patching code is a little above what I’ve done so far, any chance you’d be willing to send me the steps, process. Or do you think I should wait for a bit?

winter · May 18, 2018, 5:30pm

Sure, let me check this into my forked github, then it’s just a couple of steps to get it going.

winter · May 18, 2018, 10:35pm

Clone my fork:
git clone https://github.com/ryanwinter/open-zwave.git
Switch to Dev branch
cd open-zwave
git checkout Dev
Point the openzwave environment variable to this code checkout (this is my path below, change it to yours).
setenv LOCAL_OPENZWAVE /mnt/homeassistant/tmp/open-zwave
Uninstall existing python-openzwave
pip uninstall python-openzwave
Install using the local code checkout, will use the LOCAL_OPENZWAVE variable to fine the code.
pip install python-openzwave==0.4.3 --install-option="–flavor=dev" -v

ptdalen · May 19, 2018, 4:07pm

thanks, I just pulled this down into my home directory for Home Assistant, ran into an issue with setenv “command not found”, I am running ubuntu, Sounds like its a bash vs cs issue (at least thats google info, haha)

I think EXPORT is equivalent, but stopped out of not wanting to mess anything up, haha.

Also quick question about step 5, It will just automatically use the local source? Not doubting, just trying to learn,
Thanks