OH2 Z-Wave refactoring and testing... and SECURITY

No, not all all.

Hi Chris,

I’ll be preparing to move to zwave with security soon, I understand that the development and standard branches are incompatible with each other, but what makes it so? Is there anything we can do (or I can start looking into) to automate the transition?

I renamed a lot of command classes (i.e. most of them!) to be inline with the zwave standard. This means that all thing files are now different. In theory, you might be able to rename some of the configuration and it might work ok - or it might not as the database export is different. I probably wouldn’t recommend trying to write a converter - it will likely be error prone, and it will leave the thing configurations in some sort of unknown state, so if there are any problems, we really wouldn’t know what to do.

Theres’ not need to exclude/include - just delete the thing, hit the discovery button, and add the new thing.

Cheers
Chris

1 Like

I switched to the dev build
some of my plugs are not working due to erros generating the message.
any tips what I could try to solve this?

14:29:21.592 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'PLUG8_switch' received command ON
14:29:21.623 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: Command received zwave:device:15348538564:node29:switch_binary --> ON
14:29:21.628 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 29: Creating new message for application command SWITCH_BINARY_SET
14:29:21.630 [INFO ] [marthome.event.ItemStateChangedEvent] - PLUG8_switch changed from OFF to ON
14:29:21.634 [DEBUG] [ommandClassTransactionPayloadBuilder] - At build null
14:29:21.638 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 29: Encapsulating message, endpoint 0
14:29:21.643 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 29: SECURITY NOT required on COMMAND_CLASS_SWITCH_BINARY
14:29:21.647 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 29: Command Class COMMAND_CLASS_SWITCH_BINARY is NOT required to be secured
14:29:21.651 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 29: Node doesn't support get requests
14:29:21.655 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 29: Encapsulating message, endpoint 0
14:29:21.660 [WARN ] [converter.ZWaveBinarySwitchConverter] - NODE 29: Generating message failed for command class = COMMAND_CLASS_SWITCH_BINARY, endpoint = 0
14:29:21.664 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 29: No messages returned from converter

Well. Merry X-Mas! And, now I have time to try this out!

I was curious to try out the alternative binding to use the Secure Inclusion feature.
Wondering if anyone had any pointers as to what I may be doing incorrect.

Openhab 2.2: Main Branch, using Chris’s beta z-wave binding jar (2.2.0.201712100924 as per “list | grep ZWave”).
No other bindings. Was a fresh install. Added the z-wave jar to the addons folder and it picked it up on restart.

Yale YRD210: With Mainstream branch (previous install), using the mainstream z-wave binding, it detects it properly, mfg and all with channels, excluding security.
With the beta z-wave in the addons folder, the only way I can get secure inclusion to work is low powered inclusion only. That shows up in HABadmin as “Using Security - Check”. But the device is unknown still. Manufacturer shows up properly as 0129"ASSA ABLOY", Type/ID: 0004:0209

I have excluded the device, deleted, and re-added several times.

From the log I can gather this:
[Error] alization.ZWaveModeInitStageAdvancer - Node 11: SECURITY_INC status=complete
[warn] wave.discovery.ZWaveDiscoveryService - Node 11: Device discover could not resolve to a thingType! 0129:0004:0209::83.32

I’ve used the lock, pushed buttons etc to try to get the device to do something on the network, and have been waiting hours, but no luck. New user codes entered in, do not get pushed to the device (shows up in Web Interface as pending). And I do not have any device feedback channels to assign to Items. I set the device to communicate every 10 minutes, but assuming since it’s not refreshing I am assuming this is not applying.
I also noticed that when in HABmin, in Things, clicking on the Unknown device takes a long time to load. Clicking on the controller is quick.

Thanks!

Did you install the serial binding manually? If not this might be the problem. The Serial binding installed from the Paper UI will not effect the manually installed Z-wave experimental binding in the addons folder. You need to install the serial binding from console : feature:install openhab-transport-serial
https://community.openhab.org/t/danalock-v3-z-wave/35149/48?u=formula400pontiac

You are correct. I missed that portion.
So, went into the console, installed the feature. Restarted the service, excluded the lock, removed the controller, re-added. And still getting the error, “could not resolve to a thingType!”.
I am going to give this a shot tomorrow with a fresh mind. Will let you know how that works out.

Thank you!

One last tip. Make sure to have the unit close to the Z-wave controller or the other way around. I believe the secure connections is established with reduced radio signal output. Therefor this recommended close distance. At last i believe i have read this somewhere but i could be wrong. If i’m mistaken on this i will be glad if someone can correct me on this.

Nope, you are right :+1:

Nope - it uses full power inclusion, but it needs to be in direct contact with the controller.

I don’t believe that:
"feature:install openhab-transport-serial"
Is being installed properly by me. I should not need to download anything, correct?
When I run from the console: list | grep openhab, or just list | more, I don’t see it installed. Even after a service restart.
Tried list | grep serial.

I am doing high powered inclusion, with the lock sitting directly on the controller.

I can’t find it now, but there is/was a known issue regarding installing from Karaf. The recommendation was to only install bundles from PaperUI. You could also put it into addons.cfg. But just dropping in the jar should autoinstall the serial binding, which you must have based on the logs you’ve provided.

Did you try list|grep -i serial?
image

Originally I manually scrolled through and looked for anything openHAB/serial, and it was not there.
I installed it from PaperUI as suggested, and confirmed it was there from the console.
I have version 1.11, your screenshot shows 1.12.
image

I still cannot get the device to be recognized. Log shows the error, could not resolve to a thingType!
Guessing the next step should be to enable “debug”?

I am at Node 19 (because I was excluding). Is there a way to clear this? Apparently uninstalling and reinstalling doesn’t clear the database.

I’m using OH 2.3 snapshot 1149 (serial binding appears to be updated).

The nodes are stored in the controller. To clear them and restart from 1, you’ll need to reset it. If using a zstick, unplug and hold the button for 20s, but that’s from memory so could be completely wrong. :roll_eyes:

I recently had a similar issue with a BE469 that wouldn’t get recognized. There may be an issue with the binding, so some debug logs might help figure out if that is the case. Sometimes waiting for a day or two helps, but I got impatient and was able to get the lock identified by shutting down OH (binding may be enough) and editing the XML file (/userdata/zwave/…). Fortunately, I had a few other locks to copy it from. From the device db
image

… yours should look something like this (but someone with one of these locks could confirm)…

  <manufacturer>0x129</manufacturer>
  <deviceId>0xAA00</deviceId>
  <deviceType>0x0004</deviceType>

That is my lock indeed. I don’t have any security devices to compare against. Will see if I can mash an xml together to make the device work, it’s up on Chris Jackson’s site. Thanks for giving me a direction Scott.

I have just checked my setup and it seems like im missing the openhab-transport-serial. I suspect this might have happened due to a update done recently. I know for a fact it got installed and did run when i included my DanaLockv3.
Strangely my Z-wave lock still works without this and i have no serial binding installed in the Paper UI.

Trying to install the openhab-transport-serial from Karaf now and it returns with:

[06:51:16] openhabian@openHABianPi:~$ feature:install openhab-transport-serial
-bash: feature:install: command not found

Strange…

The dependency needed for the zwave binding if installed manually through dropping into the addons folder is not the serial binding, It is the serial transport driver, shown as nrjavaserial.

There is no need at all to install the serial binding from PaperUI.

By the way, when installing the zwave development/security binding through the Marketplace, this serial transport dependency is installed automatically and it is a lot easier to update the zwave binding: just uninstall/reinstall and you have the newest version:

Also I would avoid editing the xml files manually: after every nightly heal they get overwritten.

Ahhh.
I see…Then it is in fact still running.

openhab>  list | grep serial
 25 │ Active   │  80 │ 3.12.0.OH              │ nrjavaserial

Thank you for clearing up that misunderstanding

1 Like

Whoa… hold up. I only meant to suggest to add the id and type to an existing xml. My lock had an xml that looked pretty much complete, but was missing the id/type. I didn’t realize yours hadn’t been created yet for your device. Are you sure your lock is in range of the controller, or has other devices with beaming available to route through? Getting the lock to complete secure inclusion is the first hurdle… the next is to get it to communicate with the controller once it’s mounted!

How can nrjavaserial be installed without the serial binding? Or is this a new change where the serial binding is not needed? When I first setup the development zwave binding, I had to manually install the serial binding to get things working.

Node 2 xml already exists. It looks like the correct deviceID and deviceType is already in place.
image
The lock is directly on top of the controller. Cannot get it any closer until matter phasing tech is created :slight_smile: Secure inclusion is already complete.

I’ve tried using the alpha z-wave binding via the marketplace instead of directly in the addons folder, but similar results. I deleted Node2.xml, then re-added. It will not add it securely. When I replace Node2.xml, then it comes through securely. I had thought that removing Node2.xml and restarting the service would force the binding to recreate the xml file. I think I may need to exclude the device from the network, delete the xml, restart the service and try re-adding it. I’m away from home, so I cannot trigger the exclusion on the lock until I get back. I don’t know why the xml would not get created correctly in the first place, and I am unsure how to “fix” the xml so it is properly imported.

Also possible I just don’t understand something, or missing a component in my mind. Device should be added, show up in Secure inclusion mode. I was expecting it to Not be an Unknown Device, and thought I would see some Channels for it that I could assign to a Item. I believe there were channels before when included but not secure. I have other devices to add tonight once I acquire some 14GA wire.
image

nrjavaserial was always there on my installation, I didn’t have to do anything extra for that. I was always looking for openhab-transport-serial, thought this was the serial installation required.