Schlage lock tamper alarm configuration in homeassistant

I have 5 Schlage Connect BE469NX locks which are working well for the basic lock/unlock functionality. They also have a built-in alarm system which sounds an alarm when there is too much vibration or pressure on the deadbolt while locked, 3 possible settings. These are all configurable, and it all works and is configurable in homeassistant except for the z-wave part of the alarm response functions.

  1. Through experimentation I learned that the “burglar” entity for the alarm changes value from 0 to 2 on a tamper event. This is detectable the first time in homeassistant.
    However, it won’t change back. For the lock I’ve been testing, the burglar sensor reported value stays at 2 through reboots, lock power cycles, and unplugging the Aeotec z-wave stick. It can be reset to 0 though the homeassistant web interface but then on reboot, there is state stored either in the lock or in the z-wave stick that resets it to “2” again. All the others are at 0. I may have to unpair-repair to get it back to 0.

  2. One of the other locks must be on a different firmware revision. It doesn’t report a “burglar” entity but has a spurious “flood” component that the others don’t have. What’s up with that? How can I see or upgrade the firmware revision?

  3. I’d love to be able to use the built-in alarms to set off all 5 locks, would be plenty loud as our alarm siren for any intruder event but can’t figure out how to trigger the alarm from a z-wave instruction. How to do that?

  4. Curiouser and curiouser: The lock I’ve been testing has trifurcated into three “entities for this node” on the z-wave panel in homeassistant, it has “Locked”, “Burglar” and “Alarm Level” listed as separate entities, but the rest of the locks just show only the “Locked” entity. What makes the entities visible in that list?

  5. Siri (homebridge) can lock and unlock the locks but reports that the lock didn’t respond. It works but homebridge apparently reports it didn’t. Is this a known bug?

I know most details of these locks are probably known by RBoy who developed the widely-praised add-on Smartthings app but I’d rather have it directly in homeassistant and haven’t bought the Smartthings controller. Is that the only reasonable way to include these functions in Home Assistant? RBoy doesn’t seem to be able to set off the alarm remotely either, but he can report an alarm event and probably reset the lock alarm state.

Any approaches or results on any of my items would be appreciated.

Thanks in advance,

This sounds like an issue with the device, not home assistant.

I believe that’s a newer lock. @ptdalen has a few locks and I reemmeber him talking about a flood sensor.

I did have issues with my Schalge when running the Dev branch of Open Zwave. I did have one of the sensors being incorrectly identified as a flood sensor.

Looking back at my old posts ( I dont have access to my system right now to verify, I believe that these are the possible values for “Burglar”

		<Value type="list" genre="user" instance="1" index="10" label="Burglar" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" vindex="0" size="0">
				<Item label="Not Active" value="0" />
				<Item label="" value="0" />
				<Item label="Burglar Intrusion" value="1" />
				<Item label="Burglar Intrusion" value="2" />
				<Item label="Burglar Tamper - Cover Removed" value="3" />
				<Item label="Burglar Tamper - Invalid Code" value="4" />
				<Item label="Glass Breakage" value="5" />
				<Item label="Glass Breakage" value="6" />
				<Item label="" value="8" />
				<Item label="Burglar - Unknown" value="254" />

I wonder if it requires another event to “clear” the value and reset back to ‘0’

It could be a reporting option for the device

I will defintiely say, there is no water leak sensor. :slight_smile:
Once I got the dev flavor removed, and removed and repaired, it was gone. I will say that when I was running the dev flavor, no matter how many times I removed and repaired, it was always detecting as flood sensor.

Also I was very familair with the rboy smartthings device handler, good stuff. Getting pretty close here. Figuring out the alarms and sensors, will be good. I have a nice code manager already working pretty well.

1 Like

Yeah, my memory of our convo is shaky. I just remember you going through this. I thought you could help out. You’re pretty much the schlage lock master atm.

1 Like

@tldavis can you confirm that you are or are not running the dev flavor of openzwave?

On a side note, I’ve noticed that I’ve had poor or no success making some of these changes throught the control panel. For example I set the alarm mode to “Activity” for one of my locks. It did not take, reverted back to Off, then the lock became unavailable as a device. I restarted, HA and it made no difference, neither did a heal on the device. I unplugged the lock and upon plugging back in it had lost 1/2 its battery, but worked, and I was able to set the mode to activitiy. On my second BE469, I was not able to set it at all. Restarted, unplugged, etc. I did not have time to do more testing. Not sure if its the openzwave control panel via the HA UI, or the devices?

I am running 72.0, I did notice that my zwave devices in general seem a bit less stable since I upgraded. Anyone else notice any zwave issues with 72.0? I did not see any notes in the 72.1 about zwave, so not sure

I finally got my lock to report a burglar event value 2. Just like the initial post I’m unable to get it to report anything else. Stuck on 2. Not sure how you clear the event.

I’m using hassio, latest version.
Here’s the top of OZW_Log.txt:

2018-06-26 20:48:48.993 Always, OpenZwave Version 1.4.2926 Starting Up
2018-06-26 20:49:01.485 Info, Setting Up Provided Network Key for Secure Communications
...

I haven’t tried un-pairing and re-pairing in quite some time. Maybe doing that will fix my issues, with a “newer” version of the Z-wave stuff.

Of interest, everything seems to be stored in zwcfg.xml. I could edit the values in there or move it and perhaps it would be rebuilt with more “correct” values…

I haven’t heard back about whether anyone can trigger the siren on these things via z-wave. That would be great. If you could we could use them for all sorts of alarms!

My next ideas are to learn more about ozwcp (which I can’t use apparently in hassio), the zwcfg.xml file and hacking it, and unpair-repair the silly locks. Finally would be to harvest the config files and rebuild hassio from scratch. Not eager.

Thanks for the help so far!

is there a manual for these devices?

Operations manual, but I have not been able to find anything pertaining to zwave configuration.

I believe a value of 2 is tamper, so I’m trying to figure out how to “clear” that. Found some older posts in a smarthings forum from a few years ago, that was in the ballpark.

I feel like there must be something out there or it might be common info across most zwave locks. For example someone was able to get the info for another one of the sensors as while ago
sensor.lock_deadboltName_alarm_type
There are about 6-7 values to determine manual lock, unlock, keypad, lock, etc

burglar sensor might have something similiar
value 2 = tamper, , value 0 is clear, not sure of any other values, but if I could get some I could make a template sensor, like I’ve seen/used for alarm type

here’s the xml for the command class alarm where burglar lives. I’m sure there is a way to get the details for the possible values for the other areas. Alarm type and alarm level deal with unlock/lock and user codes

			<CommandClass id="113" name="COMMAND_CLASS_ALARM" version="3" request_flags="2" issecured="true">
				<Instance index="1" />
				<Value type="byte" genre="user" instance="1" index="0" label="Alarm Type" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
				<Value type="byte" genre="user" instance="1" index="1" label="Alarm Level" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
				<Value type="byte" genre="user" instance="1" index="2" label="SourceNodeId" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
				<Value type="byte" genre="user" instance="1" index="9" label="Access Control" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="1" />
				<Value type="byte" genre="user" instance="1" index="10" label="Burglar" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="2" />
				<Value type="byte" genre="user" instance="1" index="11" label="Power Management" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
				<Value type="byte" genre="user" instance="1" index="12" label="System" units="" read_only="true" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="1" />
				<TriggerRefreshValue Genre="user" Instance="1" Index="0">
					<RefreshClassValue CommandClass="98" RequestFlags="0" Instance="1" Index="1" />
				</TriggerRefreshValue>
				<TriggerRefreshValue Genre="user" Instance="1" Index="0">
					<RefreshClassValue CommandClass="98" RequestFlags="0" Instance="1" Index="1" />
				</TriggerRefreshValue>
			</CommandClass>

So I’m looking at my zwave motion sensor. it also has an alarm class that uses a burglar sensor.

It reports 8 for motion
and it reports 3 for tamper.

I have a feeling that these values are common across zwave devices using the buglar sensor. I’m going to now see if I can find a list of values for that sensor across any device, and see if they match

Since I was a former Smarttthings user, and used the code manager from rboy, I looked through the code for the lock. Since this is paid code, I wont post anything here, but I will say there is a specific section of code that clears the tamper alert after a delay. It is specifically there because the schlage does not clear the tamper level itself. Probably because from a door lock perspective it’s really not necessary for it to work and alert with tampering at the door. Now for HA/Smartthings thats a little different if you want do do things with the sensor.

Is there a way using the current zwave options to send a value to a specific sensor?

In this case I’de like to send the value of “clear” to
sensor.lock_back_door_deadbolt_burglar

Almost like this, except the burglar value is not one of the “config parameters”

{
“node_id”: 82,
“parameter”: 10,
“value”: “clear”
}

I submitted a bug to OpenZwave

Not sure if its an openzwave issue or a HA issue. I’m not anywhere near good enough to begin to understand how to send zwave commands programatically, but I believe that is generally the only way to clear the burglar level. Again I see that smartthings, sends a “clear” command 60 seconds after the tamper is received. So… Is that something OpenZwave should do, or… HA should do?

There is a bigger issue I discovered with Open Zwave on hassio: The file "zwcfg_???.xml doesn’t show up until I click the “SAVE CONFIG” button in the HA z-wave control panel. I found the setting of “2” on the burglar set in there, and read the docs saying it was only a cache and could be deleted. So I renamed the file and rebooted, which lost all the custom names I had given to the z-wave devices through the HA z-wave control panel.

But the z-wave system did update the lock to baseline values!

I don’t know where the data (e.g. node names) were being stored before the “SAVE CONFIG” button press, perhaps in a separate directory or different docker container. I think this is a bug.

Well, my bug was closed in the open zwave repository as “it’s working as expected”, which is fine. So, I guess I’ll come back to this. From looking at the smartthings device handler, it also acknowledges that the Schlage lock does not clear this Sensor. So after 60 seconds it sends a zwave command to “clear” the sensor.

Sending a value of ‘0’ to the sensor does not seem to be something I can figure out how to do.

So just a simple starting question, not necessarily tied to this lock. Can you send a value to a zwave device. I’m understand you can do this will the configuration class area of the zwave parameters, but this is not a parameter.

Well at least for homeassistant there’s a workaround to change the value of a read-only parameter: Edit the zwcfg xml file and kill and restart z-wave (without allowing it to overwrite the file first). That works. I do it by editing and then literally pulling the power plug on the raspberry pi. I haven’t tried exclude/include but that probably would work as well. There needs to be some way to query the actual device for the parameter rather than rely on the cached value. That would be the ticket.

According to the openzwave documents, ozwcfg it is supposed to be only a cache, but the system can’t function without it after being written if names are to be kept. I don’t know if homeassistant is misusing the cache to add its name changes, but if so then openzwave would still be “working as designed.” If openzwave API functions are being called to change entity names, then there is a bug: all user-defined names disappear when cache is cleared.

There is an openzwave call to update node state:

bool RequestNodeState (uint32 const _homeId, uint8 const _nodeId)

Trigger the fetching of dynamic value data for a node. Causes the node’s values to be requested from the Z-Wave network. This is the same as the query state starting from the associations state. More…|

http://www.openzwave.com/dev/classOpenZWave_1_1Manager.html