Unable to add Zwave secure device (Danalock)

Hi,

I am trying to include a Danalock V3
to my Z-Wave network. Since it´s a security device it requires to communicate with
encryption and must be included to the network with secure inclusion. Can be
included without but will be with very limited functionality.

I am trying to include it by
activating inclusion within Openremote software (that is working with
non-secure devices) but the device is only included as a non-secure device. I receive
the error “The se

curity enabled Z-Wave node has been
added to the NON SECURE Z-Wave network bec

ause failed to set the network key.”

I have changed the default
encryption key in the <OpenRemote

/webapps/controller/WEB-INF/classes/zwave.properties file, is
there anything more I have to do?

I am running Openremote (ver 2.6.0 Beta
3 with Z-Wave version 3.3.0) on Windows with the Aeon Z-wave USB stick “S2”
(model DSA02203-ZWEU).

I am attaching the Zwave logfile, any
help appreciated .

Regard

NIls

Z-WaveLog_Secure_inclusion.txt (35.6 KB)

I think I’ve figured out what’s going wrong. There seems to be a timing issue with the OpenRemote Z-Wave implementation during execution of the COMMAND_CLASS::SECURITY_SCHEME_GET command.

Usually the following happens when a command like COMMAND_CLASS::SECURITY_SCHEME_GET is sent to a Z-Wave device:

1.) The command COMMAND_CLASS::SECURITY_SCHEME_GET is transmitted to the Z-Wave stick via the serial API

2.) The Z-Wave stick confirms that is has received the command (RETURN_VALUE_TRUE)

3.) The Z-Wave stick confirms that is has sent the command to the device (TRANSMIT_COMPLETE_OK)

4.) The Z-Wave stick transmits the received reply COMMAND_CLASS::SECURITY_SCHEME_REPORT to the OpenRemote Z-Wave implementation

In the log file I can see that step 4.) happens before step 3.). This never happened before but I could imagine that this is possible with brand new Z-Wave devices that are super fast. The current implementation is not prepared for this scenario (receiving the reply from the Z-Wave device before the Z-Wave stick confirms that is has sent the command to the device).

I’ll let you know when a bug fix for this issue is available.

Greate Rainer,
Let me know, also if you want to do any tests.

Thanks!

Regards

Nils

Hi Nils,

with the following Z-Wave version it should be possible to include the Danalock V3 as expected: Z-Wave 3.4.0-Beta1

If inclusion works as expected you could also check if status update (locked/unlocked) works when the lock is operated manually. I’ve tested a few locks in the past and I’ve noticed that these devices do not use COMMAND_CLASS_LOCK in order to send the status update. Maybe a new generation device like the Danalock V3 behaves differently in this regard.

Hi Rainer!

Thanks for
the update. I have now tried to use the 3.4.0_beta1 version but I get the same result,
I think. Seems like the device is included as an unsecure device anyway. I have
attached a new Zwave logfile (look for node 61) along with the xml file created
during inclusion. During startup and in the log I get confirmed that Openremote
is using the new 3.4.0-Beta1 version. Any ideas?

Regards

Nils

zwavelog_With3.40_beta1.txt (34.9 KB)

node61.xml (1.31 KB)

I’ve overlooked a small detail in the first log file that you’ve sent to me which led to a misinterpretation. The following version contains a bug fix for secure device inclusion: Z-Wave 3.4.0-Beta2

You should see the following sequence in the log file which indicates that the bug fix works:

DEBUG 2020-02-27 09:04:40,885 : Secure_Inclusion_Manager : Node ‘125’ : [COMMAND_CLASS_SECURITY::SECURITY_SCHEME_GET]


DEBUG 2020-02-27 09:04:40,994 : Secure_Inclusion_Manager : Node ‘125’ : [COMMAND_CLASS_SECURITY::SECURITY_SCHEME_REPORT, Schemes=[SECURITY_SCHEME_0]]

``

The second log file that you’ve sent to me looked strange because the device didn’t respond to the command COMMAND_CLASS_SECURITY::SECURITY_SCHEME_GET at all. Maybe you have to reset the Z-Wave device (see manual) before secure inclusion of the device will be successful.

Hi Rainer,

Thanks for your update!

Have tested
your new Z-Wave 3.4.0-Beta2 update. After resetting the Danalock inclusion was successful,
I have attached the log here and to me it seems OK (node 63). Unfortunately, the
Danalock does not get Initialized correctly after that and due to that I don’t get
any .xml file or connection to the lock. I can see some errors about that in the
console output file attached here as well.

There is
also some other strange behavior in this new Z-wave version. Some devices that
has been working before (Fibaro wallswitches) stops working and every time I
try to turn on the switches I get an error on the Openremote console (se
attached output file). It complains about some sensors the does not exist in
the device state cach.

Additionally,
I have some temperature sensors that suddenly reports temperature with decimals
witch was not the case in earlier versions.

So the
inclusion now works, but the initialization problem and sensor errors on the
other devices I don’t know how to fix.

/Nils

Successfull secure inclusion node 63.txt (88.3 KB)

Console output 3.4_beta2.txt (16.5 KB)

Hi Rainer,

Some updates
regarding this. As I wrote earlier the Danalock was inserted OK in secure mode
but no .XML file was created for some reason. After a while it was created (probably
due to a wakeup from Danalock) but I noted the in the XML file it was initialized
as a NON-Secure device.

So I
excluded the device from the network again, made a factory reset of the
Danalock and tried to include again in secure mode. Have tried several times
but with no luck, the device is included as a NON secure device all times. All
this is done with the Z-wave 3.40_Beta2.

As I describe
earlier, I have some other issues with 3.40 version (unable to turn on/off some
other Zwave devices for example) and therefor I have been forced to go back to
my original 3.30 version when not doing the tests for the Danalock. For some
strange reason I am now unable to add other Z-Wave devices (Fibaro FGS-222)
that I have needed to add. This has worked before but now the only way to
include Z-wave devices is to temporary start up with 3.40 version to make the
inclusion and then go back to 3.30 version.

Have the
3.40 version made some other changes to the system that can make this behavior?
So, you might say that I am stuck between the 3.30 and 3.40_Beta2 version.

I attach
another log example along with the created .xml file (device id 69). Is there anything more we can do to make 3.4 version work? :slight_smile:

Thanks,

Regards

Nils

Node69SecureInclusionFails.txt (153 KB)

Node69.xml (1.31 KB)

The Z-Wave version 3.4.0 contains new features like a device database that are intended for the new OpenRemote v3 software. The new version also contains a new API that coexists with an API that is needed for the OpenRemote v2 controller. I could imagine that this API coexistence could create minor problems but I don’t think that these issues are severe so that the whole Z-Wave network doesn’t work anymore. In theory it should be possible to replace v3.3.0 with v3.4.0 and vice versa because I haven’t changed the format of the nodeX.xml files.

In the terminal log (Console output 3.4_beta2.txt) I’ve seen that inclusion of the Danalock v3 failed because the version of COMMAND_CLASS_DOOR_LOCK couldn’t be read from the device. That means the secure inclusion procedure (key exchange) went well and most probably secure communication with the device in general also works but for whatever reason the device doesn’t respond to a version request for COMMAND_CLASS_DOOR_LOCK.

WARN 2020-03-03 19:46:52,528 : Node_Initializer : Node ‘63’ : [COMMAN
D_CLASS_VERSION::VERSION_COMMAND_CLASS_GET (Retry=‘1’), CommandClass=‘COMMAND_CL
ASS_DOOR_LOCK’] failed : ‘COMMAND_CLASS_REPORT_TIMEOUT_ERROR’.

``

I’ve also seen in the log that I’ve mentioned before that there’s a XML parser issue

ERROR [pool-3-thread-4]: Node_Initializer : Node ‘41’ : Failed to loa
d device info from device database - Manufacturer=‘280’, ProductTypeID=‘0x0003’,
ProductId=‘0x0002’.

``

Please execute the following instruction so that I have a chance to fix the issues with the Danalock v3 in combination with Z-Wave v3.4.0

1.) Replace the XML parser library xercesImpl-2.6.2.jar with the following more recent version: xercesImpl-2.7.1.jar

2.) Use or-zwave-3.4.0-Beta2.jar

3.) Exclude the Danalock v3 from the Z-Wave network

4.) Include the Danalock v3 to the Z-Wave network (secure inclusion) and send me the whole log file. I need to see the WHOLE log until to the point when the COMMAND_CLASS_LOCK version request fails

5.) Exclude the Danalock v3 from the Z-Wave network

6.) Include the Danalock (non secure inclusion) and check if it works (nodeX.xml file is created). If it doesn’t work send me the log file.

With step 5.) and 6.) I’m able to see if there’s a general problem or if the issue exists only in combination with secure inclusion.

I’ll help you fix the other issues but let’s concentrate on the Danalock communication problem and thanks for your cooperation and patience.

Hi,

Replaced
the file you sent and tested the 3.40_beta2 again. Followed your steps and attached
the logfiles here. Made a factory reset of the lock before every inclusion.

.XML files
are created both times (secure/nonsecure) but it only includes the lock as non-secure.

Let my know
if you need anything more. Glade you can help me and if I can contribute to a
better Openremote. :slight_smile:

/Nils

NonSecureInclusionFails-ID72-.log (70.9 KB)

SecureInclusionFails-ID71-.log (553 KB)

I want to let you know as an intermediate update what’s going on in regard to the Danalock v3 issue. It seems that the Danalock doesn’t respond from time to time when it receives an encrypted GET Z-Wave command class request for whatever reason. I couldn’t find a bug in the OR Z-Wave implementation so far but I could imagine that it’s caused by a nasty timing issue. I’ve decided that it’s worthwhile to get hold of a test device. I’ll receive this test device in the next couple of days.

Hi Rainer,

Thanks for the update, appreciate the time and effort you put in to this to make it work.

Thanks!

/Nils

I’ve received the test device and was able to include it to the Z-Wave network as expected with the following version: Z-Wave 3.4.0-Beta3

Hi,

Made
another try with the beta 3 version. Unfortunately, I am still unable to do the
inclusion with secure mode. I have attached logs and .xml file created.

Tried three
times with the same result, also made a reset of the Danalock before inclusion. I got the 0.14.6 firmware on my Danalock, do you
have the same?

/Nils

Node75Inclusion.zip (49.7 KB)

The Danalock V3 is a so called FLiRS (Frequently Listening Receiver Slave) device in order to save battery life but at the same time also provide short latency and short responding times. At startup time of the OpenRemote controller the whole Z-Wave network is scanned for existing or new devices respectively. In an early version of the OR Z-Wave implementation all Z-Wave nodes were scanned in parallel. I’ve changed this procedure to a sequential scheme because scanning door locks failed from time to time. I’ve got the feeling that these FLiRS devices do not respond properly if the Z-Wave controller communicates with other devices in parallel. I’m not sure about how the multiple access protocol of these FLiRS devices work.

I’ve seen in the log that the controller polls several sensors. This could theoretically lead to the “multiple access” issue that I described before. I’ve created a rule that polls two sensors with a frequency of 1 sec in order to simulate your system but inclusion of the Danalock V3 never failed. Nevertheless I’ld suggest that you deactivate polling sensors temporarily before you try to include the Danalock to the Z-Wave network the next time.

Is your Z-Wave Stick S2 in close proximity (1 meter) at inclusion time of the Danalock V3 ?

Hi,

Thanks for the update.

Yes, the Danalock is located 10 cm from the Zwave USB stick. I tried to remove all my Drools rules that are trigging the sensor updates and after that made another try but still the same thing. Checked the Zwave log before I made the inclusion again and there were no other activities when I fired off the secure inclusion.

Don’t know what other differences we have between or Openremote installations. Since I don’t have any other “secure” device included in my Z-Wave network I will try to test and include anther type of device in secure mode to see if that works. Will get back to you with the result. Any other ideas?

Regards

Nils
PS: Attaches the latest Z-wave log from inclusion.Node76SecureInclusionFails.txt (35.2 KB)

Hmmm, how do I upload log files to the new forum? :smiley:

As a new user you were unable to upload any file. You can reactivate your old account (login with your old email and reset password). Anyway, I’ve bumped your user level so you should be able to upload a file. Simply drag-and-drop works, what I’ve just done.

Core Kubernetes 1P Review Source Code.zip (11.1 KB)

1 Like

Please note that it’s always a good idea to remove a device from the Z-Wave network before you add it to the Z-Wave network. Therefore I’ld suggest the following procedure for your next test:

1.) Remove the the Danalock from the Z-Wave network
2.) Make sure that the nodeX.xml (most probably node76.xml) file has been deleted in the ‘/webapps/controller/zwave’ directory
3.) Add the Danalock to the Z-Wave network in secure mode

I could reproduce the system behaviour that I’ve seen in the log files you’ve sent to me with the following procedure:

1.) I’ve added the Danalock in non secure mode to the Z-Wave network
2.) I’ve tried to add the Danalock again in secure mode without removing it before

Hi Rainer,

I always removed the Danalock with a “exclusion” in Openremote before I try to include again. The console confirms the exclusion and the .xml file is removed.
I used the following procedure:

  1. Exclude the Danalock device from Z-Ware network
  2. Verifies this by checking the .xml file and console output.
  3. Remove the Danalock from the iPhone app
  4. Make a factory reset of the Danalock (10 clicks on the Danalock microswitch)
  5. Registered the lock to the iPhone app again.
  6. Enables secure inclusion in Openremote.
  7. Start inclusion of the Danalock from the iPhone app (also tried by using the alternative method by clicking the microswitch one time on the lock).

I have now also tested to include another Z-Wave device securely to my Openremote. I successfully made a secure inclusion of a Fibaro FGS-223 switch, so this must be related to the Danalock.

After that I made another try with the Danalock, but still gets the two errors in Z-wave log:

[COMMAND_CLASS_SECURITY::SECURITY_SCHEME_GET] failed : ‘COMMAND_CLASS_REPORT_TIMEOUT_ERROR’.
The security enabled Z-Wave node has been added to the NON SECURE Z-Wave network because failed to set the network key.

Do you know what firmware level you have on your Danalock? Maybe I could open a case with Danalock support, but not sure if they will help.

What more can a man do? :stuck_out_tongue:

/Nils