Danalock V3 - Z-Wave

z-wave
danalock
v-3
Tags: #<Tag:0x00007f18273d3a10> #<Tag:0x00007f18273d37b8> #<Tag:0x00007f18273d34c0>

(Joe Ru) #1

Hi all,
i guess - i’m one of the first to bought Danalock V3 / Z-Wave edition - as it is released only a few days.
I tried now to add it to openhab - but did not manage to find it in the z-wave scan.
So: My question - is there a way to find the communication details on what openhab and danalock v3 exchange - or any details at all - and how am i going to check it?

For more Details you can have a look here in the Manual (german):


[SOLVED] After upgrading to 2.3 Zwave doorlock stopped working
(Chris Jackson) #2

You need to use the development version of the binding to use secure devices -:


(Austris V) #3

@JoeRu, you are not alone!:slight_smile:

I’m also (to be) happy user of Danalock V3 / Z-Wave edition.
y-day switched over OH to a snapshot. Reinstalled Z-Wave “binding-zwave - 2.2.0.SNAPSHOT”. When searching for supported things, can see three entries w Danalock:

  • Danalock V3-BTZE Z-Wave Controlled door lock with Bluetooth Smart zwave:polycontrol_btze_01_002
  • BTZW125 Danalock v2 circle zwave:polycontrol_btzu125_00_000
  • Danalock V3-BTZE Z-Wave controlled door lock with Bluetooth Smart zwave:polycontrol_btze_00_000

The thing is found, but showing up as Unknown device. In the habmin interface Manufacturer and Type are empty (see attached picture)

In the openhab log there is:
[WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 10: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0

@chris, I wonder, maybe device has corrupt/wrong metadata (Manufacturer empty)? Or development version is not the same as snapshot and I should be switching over to it for testing?

Thank You so much for the amazing work!


(Angelos) #4

Nice!

I have been waiting for this thing to hit the market!

Can you post the xml for this node?


(Chris Jackson) #5

This probably means the device isn’t communicating. Are you sure you’re using the right version (ie the development version). It’s strange that the “Using security” box is a yellow question mark which leads me to think it’s the wrong version?


(Austris V) #6

looks like the snapshot I had was few days old. updated, refreshed to latest:
191 │ Resolved │ 80 │ 2.2.0.201710241652 │ ZWave Binding

Uninstalled binding, installed back, added Thing - same result.

Managed to switch on debug log (first attempt, sorry if too long; deleted bunch of “checkin…”).

00:22:20.503 [DEBUG] [zwave.discovery.ZWaveDiscoveryService] - NODE 10: Device discovery completed
00:22:20.527 [DEBUG] [zwave.discovery.ZWaveDiscoveryService] - NODE 10: Checking zwave:zooz_zse09_00_000
00:22:20.574 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 10: Stage MANUFACTURER. Initialisation retry timer triggered. Increased to 640000
00:22:20.625 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer - MANUFACTURER: queue length(0), free to send(true)
00:22:20.665 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 10: Initialisation retry timer started 640000
00:22:20.713 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer: loop - MANUFACTURER try 1: stageAdvanced(false)
00:22:20.765 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer: MANUFACTURER - send ManufacturerSpecific
00:22:20.832 [DEBUG] [ZWaveManufacturerSpecificCommandClass] - NODE 10: Creating new message for command MANUFACTURER_SPECIFIC_GET
00:22:20.868 [DEBUG] [zwave.discovery.ZWaveDiscoveryService] - NODE 10: Checking zwave:evolve_lpm15_00_000
00:22:20.895 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer - queued packet. Queue length is 1
00:22:20.945 [DEBUG] [ave.internal.protocol.ZWaveController] - Message queued. Queue length = 0. Queue={}
00:22:20.943 [DEBUG] [tocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
00:22:21.045 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 0A 02 72 04 25 37 89
00:22:21.137 [DEBUG] [ding.zwave.handler.ZWaveSerialHandler] - NODE 10: Sending REQUEST Message = 01 09 00 13 0A 02 72 04 25 37 89
00:22:21.203 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
00:22:21.288 [DEBUG] [ave.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
00:22:21.383 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
00:22:21.456 [DEBUG] [ave.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
00:22:21.515 [DEBUG] [ave.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
00:22:21.597 [DEBUG] [ol.serialmessage.SendDataMessageClass] - NODE 10: Sent Data successfully placed on stack.
00:22:22.436 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 37 00 00 7C A0
00:22:22.503 [DEBUG] [ave.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
00:22:22.546 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 37 00 00 7C 00 00 AE
00:22:22.604 [DEBUG] [ave.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 37 00 00 7C 00 00 AE
00:22:22.673 [DEBUG] [ave.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=37 00 00 7C
00:22:22.736 [DEBUG] [ol.serialmessage.SendDataMessageClass] - NODE 10: SendData Request. CallBack ID = 55, Status = Transmission complete and ACK received(0)
00:22:22.760 [DEBUG] [zwave.discovery.ZWaveDiscoveryService] - NODE 10: Checking zwave:vision_zp3102_00_000
00:22:22.792 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Config, dest=10, callback=55, payload=0A 02 72 04
00:22:22.851 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=37 00 00 7C
00:22:22.905 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=55, expected=ApplicationCommandHandler, cancelled=false      MISMATCH

(Chris Jackson) #7

I’m pretty sure you’re not running the right version. This log comes from the master version that doesn’t include security.

This binding is only in the resolved state - it’s not actually running.


(Austris V) #8

hmmmm, it might be I copied the “bundle:list” output to early. Just checked

165 │ Active │ 90 │ 2.2.0.201710241652 │ openHAB Core
191 │ Active │ 80 │ 2.2.0.201710241652 │ ZWave Binding

also in the log file I see

2017-10-25 00:10:08.055 [DEBUG] [org.openhab.binding.zwave ] - BundleEvent STARTING - org.openhab.binding.zwave
2017-10-25 00:10:08.217 [DEBUG] [inding.zwave.internal.ZWaveActivator] - Z-Wave binding started. Version 2.2.0.201710241652
2017-10-25 00:10:08.249 [DEBUG] [org.openhab.binding.zwave ] - BundleEvent STARTED - org.openhab.binding.zwave
2017-10-25 00:10:09.618 [DEBUG] [org.openhab.binding.zwave ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=org.openhab.binding.zwave.internal.ZWaveHandlerFactory, component.id=192, service.id=306, service.bundleid=191, service.scope=bundle} - org.openhab.binding.zwave
2017-10-25 00:10:11.922 [DEBUG] [org.openhab.binding.zwave ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.ConfigOptionProvider, org.eclipse.smarthome.config.core.ConfigDescriptionProvider}={component.name=org.openhab.binding.zwave.ConfigDescription, component.id=193, service.id=307, service.bundleid=191, service.scope=bundle} - org.openhab.binding.zwave

If it is a wrong version then running out of ideas how to update/get rid of the old one:( willl give it a fresh restart and another clean try in evening, then report back.


(Matt) #9

i had something similar in the beginning by some reason.
what i did was:

  1. ensure that no Z-Wave binding is installed via “Paper UI”, iw anything is there uninstall it
  2. check Karaf for any installed Z-Wave binding, uninstall from there. bundle:uninstall
  3. delete any Z-Wave binding from your Addons folder.
  4. restart OH2, check if no Z-Wave binding is loaded via Karaf.
  5. download current Dev. version of the binding (http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.2.0-SNAPSHOT.jar)
  6. restart OH2

i know there is a much shorter way but i wanted to be sure that nothing else is getting loaded so i did it this way.
after all this i excluded the Lock from the controller and re-included it.


(Chris Jackson) #10

I’m not really sure what’s happening then. The first log you provided above has lines like the following -:

This is definately from the old binding as this log entry doesn’t exist in the development version. So, at least at some recent point you were still running the old binding.


(Austris V) #11

here is full log from last night’s experiment openhab.7z. Matt gives a hope he also has seen smthg like that - will get back to it at evening, follow his steps and hope to get over:) Thanks!


(Chris Jackson) #12

This file all comes from the old binding so hopefully if you can resolve the issue of what version is running, it will hopefully work :wink: .


(Austris V) #13

did what I can w uninstall/restart/install voodoo.
from UI side can’t see any differences.
Is this time the log any better?
openhab.7z

Also, just in case … ‘development version’ is the same as ‘snapshot’
?


(Chris Jackson) #14

No - they are not the same…

The development version is the one described here -:


(Austris V) #15

mea culpa … my fault, sorry :frowning:
will have to learn how to manually install binding and will be back:)


(Austris V) #16

mkey … uninstalled all I can, verified there is no zwave bundle in list. deleted to suspicious jars.
copied over .jar from cd-jackson site to the /usr/share/openhab2/addons
had to install the serial feature in karaf manually and binding got activated.

does not see it recognized yet, though the log looks different to my eye. I hope it’s the right binding finally:slight_smile:
openhab.7z


(Chris Jackson) #17

I don’t seem to be able to extract the log :frowning:


(Austris V) #18

is it better now?


(Chris Jackson) #19

Yes - it looks ok. I think you need to exclude node 10 and reinclude it again. Inclusion must be done through HABmin or PaperUI.


(Austris V) #20

wow, I did not know it can be done through UI as well… giving it a try

here is log openhab.7z, Node 12 this time