Issues with security V1 inclusion


I’m having some issues with an implementation of the SECURITY class V1. Occasionally I see devices not responding to the SECURITY_SCHEME_GET request, and ultimately this leads to the failure of the secure inclusion.

The log below shows the serial API frames logged during an inclusion and the key exchange. This shows the node being added (ie the end of the inclusion), and then I request a node identity from the controller, and then move on to request the SECURITY_SCHEME_GET. This is well within a few hundred milliseconds of the inclusion completing, and I’m assured by the user that in this case the device had been reset (ie it was not already included).

I continue to request SECURITY_SCHEME_GET until an internal timer decides to give up on secure inclusion (15 seconds later), but there is no response and the controller is returning NO ACK after around 150mS (+/-, which does seem quite short).

I don’t believe from the above that I’m violating any timers or other requirements of the SECURITY class. Some users have stated that if they hard reset the controller, then security works fine until they have many other devices on the network. Given that there is no traffic with other nodes seen during these key exchanges, I don’t understand how this could be linked.


Never had this issue with our security V1 implementation (FHEM). There are a few other issues resulting in CAN, but not this one…

I am a little bit unsure what this “IdentifyNode” is. What command class / command is this? I think that we don’t have anything between the “Add_Node_Done” and the “Scheme_Get”. Is this a controller command or something that is actually send to the node?

Do you know what device this is? It is stated “secure_keypad_door_lock” but I am not aware of such devices with FLIRS and would be interested in that device…

The specification is not very clear about the retry time after a NO_ACK, maybe a longer delay before sending the command again can help…

Off-Topic: Did you already start to implement V2?


Thanks for your thoughts…

This is a controller command - it gets the information such and the FLiRS / Listening flags, device classes etc. It could probably be removed at this point, but as it’s a controller command, I would be surprised if it’s an issue (but, I’ll try this :wink: - maybe under the hood the controller interacts with the device).

I think this specific log was from a Yale lock, but the issue is not limited to a single type of device. I have reports of this issue with Schlage as well (in fact, mostly Schlage locks).

I think that my lock (also a yale) reports this class. Certainly, it’s a door lock, and it supports FLiRS (I assume most locks should - otherwise response would be non-real time right?).

I have tried some different delays - maybe not the retry time, but I have put a delay in following the initial inclusion (a few hundred milliseconds I think) and I’ve not managed to resolve it. Part of the issue is as well that I can’t reproduce the issue myself which means I need to rely on feedback from others which always slows down the debugging cycle.

No, I’ve not really looked at this yet and I’m guessing that other than it being a requirement for certification, it’s probably still not that widespread yet. Most locks seem to use quite old implementations (ie older CCs) still.


Ok, if it is a controller command I would also not expect that it interfere with the inclusion.

So it is a complete lock WITH a keypad… I was thinking of a numberpad that “pairs” with a lock. I have a Danalock V2, and there is no number pad included. They announced a keypad to pair with the lock since one year but did not yet release it. The lock itself uses FLIRS. So this was a misunderstanding.

Trying to solve such an issue just with logs can be a real pain. Had this also several times in the past and sometimes it is just a problem with something else in the installation or the environment and not the code that triggers some problems…

Some devices I have will not “finish” the secure inclusion, but will work just fine. Can’t find the reason for that as well. The devices are described to blink a LED during inclusion and that should stop when the inclusion is finished. Some of them will not stop blinking even the inclusion and all the security stuff went through without any problems/errors.
But there a some devices out there in the field that makes me wonder how they got there certificate…

For S2 I already have a keypad that supports it (only the version without the printed verification code on the device). I have started with the implementation but having some issues with implementing these “nonce generators”. I am getting an encrypted answer from the device but haven’t started with the decoding function…