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

I am trying to enable secure communication with a Fibaro Dimmer 2 (FGD-212) - as far as I can determine from their documentation they should support secure zwave? I have set the “Secure Inclusion Mode” to “All Devices” under the serial controller. Am I correct in thinking once working, all comms would be encrypted, and the device should not accept non-encryped attempts to control it?

Starting from a clean OpenHab with this latest binding installed (today), the device will be included but remain as “unknown device” (without any attributes) this continues even after a restart of OpenHab. If I then delete and include again within habmin (without excluding) the device is identified correctly, properly added, and shows with “using security”. On subsequent restarts of Openhab the device is stuck showing “Node Initialising STATIC_VALUES” in habmin (I guess this correlates with the device’s configuration parameters in habmin not reflecting that of the actual device).

Is this relevant in the logs (device is NODE 11)?

2017-02-24 12:38:15.190 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 11: No data from device, but it was ACK’d. Possibly not supported? (Try 5)

I take it the device is not responding causing the process to hang? or is this business as usual?

I’m not sure - this is down to the device. For most devices, it’s probably a correct statement - most devices stop accepting unencrypted commands once securely included.

Probably this is the case, but it’s hard to say without seeing a debug log.

@whwkins - ok as a followup, I think I might see what I’m missing, but want to clarify.

I’ve securely included the Linear GD00Z-4. It shows up in OH properly. But I’m only seeing 1 Channel labeled “Barrier Position”. This channel seems to be the one mapping to the status of the door (aka 0=Closed, 255=Open, etc).

  • Are you seeing more than 1 channel for your device?
  • I was expecting to see 2 channels - 1 for Barrier Position (Open, Close, Opening, etc) and 1 for Barrier Operator to send an Open/Close or On/Off signal to control the door.
  • If only 1 device, then do I need to create a switch mapped as well to Barrier Position with 2 possible mappings?

The device only has one channel defined in the database.

@chris - Ok, I think I’m narrowing down the issue here. I’ll send you a reply to my earlier message with a second set of logs. I do see some security class errors, and I’m noticing 2 different sets of info coming into the DEBUG logs referencing 2 different items that I believe need mappings to a channel.

1 is an Alarm state which is reporting the #(0, 255) that is being translated to the channel (I believe), and the second is a STATE_OPEN/STATE_CLOSED request to process the open/close of the door.

If I’m correct, the COMMAND_CLASS_BARRIER_OPERATOR is the Class containing the open/close commands, and the COMMAND_CLASS_ALARM is the Class containing the value of the door status. Since I know you may not have one of these devices, I’ll outline that there are functionally 2 working parts - 1 is the sensor on the door for open/close status, which I believe is mapped to the ALARM, and 1 is the actual relay part which I believe sends the low voltage on/off trigger to the Garage Door controller to actuate the opening/closing of the door which is mapped (again my guess) to the BARRIER_OPERATOR class.

EDIT: It seems perhaps these 2 items are in tandem? I’m hoping @whwkins can help shed some light on how he has this configured successfully so I can attempt to emulate and validate.

Ok - that’s fine. I see that there are alarms supported that aren’t linked to channels, so the database may not be fully defined…[quote=“shawnmix, post:309, topic:21653”]
and the COMMAND_CLASS_ALARM is the Class containing the value of the door status

This may be right, but it is also defined by the barrier command class. The alarm class may also provide events, but I would not use them - I would stick to using the barrier since linking an alarm to another item will not be simple. You want a single item on your UI that shows the state of the gate/door, and can also be controlled. So, it should (I think) be the same as a switch - you want to be able to show its state as ON/OFF, but also to turn it on and off. You don’t want a button to turn it on and off, but an alarm when someone manually changes it (at least that’s what I would expect).

The barrier command class defines the states as follows -:

        STATE_CLOSED(0x00, "Closed"),
        STATE_CLOSING(0xFC, "Closing"),
        STATE_OPENED(0xFF, "Open"),
        STATE_OPENING(0xFE, "Opening"),
        STATE_STOPPED(0xFD, "Stopped");

Thanks, I’ll take a look this afternoon then and see if I can define this properly. When I initially set it up with HABmin, it seemed to want to put it as a contact sensor type. So that’s what threw me off initially. re-reading @whwkins message, it seems perhaps that is what he was describing setting up as well as a single item. I for some reason expected 2 channels.

I’ll test this afternoon and see if I can get some more positive results and respond appropriately (hopefully on a successful) working garage opener.

Thanks for the help as always and sorry to hijack and throw a bunch of info here. Hopefully it can help someone else stuck in the same boat/thought process as I. :slight_smile:

Correct, there is only one channel that shows status and controls the garage door.

I also saw the two alarm instances, but they don’t appear to do anything. I’ve setup logging and done a local modification for exposing them and haven’t seen either the access_control nor the burglar alarms change on the GD00Z.

Here is my garage door item linked to the GD00Z “Barrier Position”:

Then I have the following in my sitemap to show status and allow control of the garage door:

Switch item=GarageDoorPosition mappings=[0="CLOSED", 255="OPEN"]

Whats the best way to post logs as they are hugely verbose?

I also notice the following in the logs:

[DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 11: Skipping secure inclusion

This suggests the device is not included securely. What logic causes this? This is strange because habmin showed security as on after it was included (after deleting the unknown device and adding it again).

Unfortunately I excluded the device and started with a fresh copy of Openhab, and this time the behaviour was different again, the device initially added as unknown but with specific attributes (manufacturer / ID etc). Seems something non-deterministic going on…

email should normally be ok - up to around 20MB.[quote=“Boycee, post:314, topic:21653”]
What logic causes this?

I think it’s only related to the setting in the controller as to what devices should be securely included.[quote=“Boycee, post:314, topic:21653”]
Seems something non-deterministic going on

Maybe - maybe not. I think there’s an issue when new devices are added in this binding - it’s discussed elsewhere in this thread. Try stopping the binding and restarting.

@chris: First I want to thank you very much for your great work!

I updated today to the new test binding. Most of my nodes are working so far - despite my NQ-9021 NorthQ Electrical Meter, which has some strange behaviour. Based on the documentation this one has no push for the meter report but only a pull, why I set up a polling interval of 300s and the wake up interval also fo 300 s.

Sometime the METER_REPORT is updated correctly:

But sometimes the answer of BASIC_REPORT is given back to “meter_kwh”, what from my understanding can’t be correct and also isn’t the case in the version of the master branch:

Therefore the result of meter_kwh is now “jumping” between the correct value and “1”.

Plesase give me an hint if you need the debug log for further analysis.

Kind regards,


What is the tool being used to view the logs as you are? I’d love to be able to use this view to make log review a little easier.

It is available on the homepage of chris:


1 Like

@adb76 Fantastic!! Thanks!!

@chris and @whwkins - thanks for your help in shepherding me to the answer here. It looks like I’m just a fool misinterpreting what I was seeing. We are all good, the device looks to work fine. I mapped out a simple HabPanel button to test out. In doing so, the Linear device lit up and started its 5 second warning before acting. Then I pulled apart the control that I need to solder and tested the leads on the contacts, and presto!! Abra kadabra open my garage!

Thanks for the help guys and please keep up the amazing work on this binding. This binding is honestly the core of my entire smart system as I’ve felt ZWave provides the best mechanism over the other protocols at this point. Now on to soldering … :rolling_eyes:


This is caused because the METER command class was linked to the BASIC command class in the database - I’ve removed this link now so hopefully this should stop when I update the binding next (I’ll try and do this tonight).

Thank you very much!

Additionally I’ve found out that I have the same issue for all of my FGWP101 as @fonz:

They are staying now for hours in the status “UPDATE_DATABASE”. The newer ones FGWP102 are working ok:

Restarting of openHAB or deleting and readding the Z-Wave nodes didn’t fix the problem. Here you can find the debug log:

You can look e.g. to the nodes 28, 33, 36, 41 and 42. What seems strange for me is that the all show Firmware Version “0.0” - e.g. Node 33:

Trying to understand how things work…
@chris you mentioned that:
"Note that secure inclusion can ONLY occur within the first 20 seconds or so following the inclusion. If it doesn’t work during this time, then it will never work and you need to exclude and re-include the device from the controller. "

My Danalock is included and have a green check in Using security . It still doesn’t react when I try to unlock or lock. No errors shown!

I now try the option Reinitialize the device and after a while the green check in Using security becomes a red cross. Will this always fail since it’s out side the 20 seconds?

I’ve tried both GUI and text files. Funny, nothing is showing in the logs.

I’ve updated the binding here. This does have a potentially useful fix for multi-instance devices, although it probably still doesn’t solve the latency issue yet.