OpenHab2 and Linear NGD00Z-4 Garage Door Controller

I am trying to use Linear NGD00Z-4 Garage Door Controller with OH2. It needs the Security Classes to be included.

I am able to successfully include it in the network with OpenHab2. However, it only shows 1 channel: “BARRIER_POSITION” with type Number. There is no channel to Open/Close the Garage Door.

As per this post, it should work with OH1: Unknown device with Linear NGD00Z-4

As per this post, OH2 binding now has security. OH2 Z-Wave refactoring and testing... and SECURITY

What am I missing ? Has anyone tried this Garage Door Controller with OpenHab2 ?

Are you actually using the binding version that is linked from the top of this post?

No I assumed that the binding would have made its way to the latest SNAPSHOT.

I have the latest SNAPSHOT running. How can I run the binding linked to the top of the post ?

  1. Uninstall SNAPSHOT Binding
  2. Download the Binding from the top of the post and put into /opt/openhab2/addons ?

Or some other steps ?

Thanks

No - it’s not in master branch yet.

Yes, fundamentally you are right about the install - take a look a few posts down from the top of the thread - there are some instructions and also some comments about how to resolve the dependencies.

Ok I downloaded the zWave OH2 with Security Binding from (OH2 Z-Wave refactoring and testing... and SECURITY)

I reset my controller, deleted the original OH2 binding and then added the binding from above.

I then turned on Secure Mode for All Devices.
Then tried to Include the Linear NGD00Z Garage Door to the network.
Habmin reported that Secure Inclusion failed. I then tried Secure Inclusion from PaperUI and switched to Habmin to check the status. This time Habmin reported that Secure Inclusion succeeded.

The UI also shows Security is On.

However, I still see only 1 channel (BARRIER_POSITION). There is no channel to Control the Garage Door.

Attached below is my log file for secure inclusion.

@Chris - Any advice ? Is the Database complete for this device ? If not could we please add this to the database ?
GarageDoor-Log.xml (825.7 KB)

Seems from the logs that Security was successful. So not sure why I see only 1 channel for Door Position.

As per this post (Anybody interested in BARRIER_OPERATOR Zwave Command Class?), the 2nd channel should be: BARRIER_OPERATOR zWave Command Class and it has been available in OH2 for a long time. Then why do I not see the BARRIER_OPERATOR channel ?

@Chris - Any thoughts ?


Issue #2:
PS: Also after using the Secure Binding, I am no longer able to control my dimmers. They show unknown even though the device exists in the database (Reference ID: 556, Manufacturer: 001d. Type: 3201:0001). I was able to get the dimmers working with the latest snapshot binding.

@Chris - Could you please update the Secure zWave Binding to include the latest Database changes ?

Not without seeing a logfile. I would suggest to delete the XML for this device, restart the binding and send me the log by creating a ticket on my website and I’ll take a look when I get a chance - probably in a few days.

Ok Will do. Thanks.

@Chris how about the missing updates for the Leviton Dimmers (Reference ID: 556, Manufacturer: 001d. Type: 3201:0001). They are not recognized by the development z-Wave binding, but are recognized by the SNAPSHOT binding.

Would you be able to update the Dev binding to recognize the above Dimmers ?

Yes - I’m not sure I’ll get to do it tonight, but if not I’ll do it tomorrow.

Perfect. Thank you for your support.

Updated now…

@chris I have created a Ticket #T9JHVYw2PKX)

The latest code resolved the Dimmers. So thanks for that.
For Garage Door Controller (NGD00Z-4), I noticed in the log file:

2017-04-07 14:22:24.053 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Initialising cmd channel zwave:device:dfa4d57c:node33:barrier_position for DecimalType
2017-04-07 14:22:24.053 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Initialising state channel zwave:device:dfa4d57c:node33:barrier_position for DecimalType

It seems it is creating the Barrier_Position channel for both the Command Channel and State Channel. Is this a bug ?

Apart from the BARRIER_OPERATOR and BARRIER_POSITION, there should also be an ALARM channel to report Battery and Block problems with the controller. I see that in the XML but they are never instantiated.

Ticket #T9JHVYw2PKX has all of the log files and XML file.

Thanks again for your help.

Was this ever resolved? I saw for the zwave device database entry for the NGD00Z-4 you updated BARRIER_POSITION to BARRIER_STATE. I have mine connected securely and I’m trying to send it 255 mapped to a switch to BARRIER_STATE but nothing happens.

Is it true that BARRIER_OPERATOR and BARRIER_STATE use the same channel? I see BARRIER_OPERATOR nowhere.

Any insight would be appreciated.

Try barrier_position as a number item.

Thanks for the suggestion Scott but barrier_position doesn’t show as a linkable channel…only barrier_state. Not sure what I should do.

Strange… I’m using version 2.1.0.201707291849 of the test zwave binding and have barrier_position:

image

Which version are you using?

How do I check the exact version and build?

I tried going into the Karaf Console but it just shows I’m not using 2.2 snapshot:
openhab-binding-zwave1 | 1.11.0.SNAPSHOT | | Uninstalled | openhab-addons-legacy-2.2.0-SNAPSHOT | Z-Wave Binding (1.x)
openhab-binding-zwave | 2.2.0.SNAPSHOT | | Uninstalled | addons-2.2.0-SNAPSHOT | Z-Wave Binding

I think I have the 07292017 version of the snapshot and I do have this file in the addons directory:
http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar

But this is what I see:

One other thing I notice is that barrier_state for me shows 253 regardless if I send 0 or 255.

I don’t see barrier_position at all below the screenshot so I’m wondering what’s wrong with my configuration. Thanks again for the help.

To find the version of the binding, do this in the Karaf console:

bundle:list | grep ZWave

Thanks for the command. Looks like I’m using the same version as you.

openhab> bundle:list | grep ZWave
217 | Active | 80 | 2.1.0.201707291849 | ZWave Binding

Bizarre…do you think it has something to do with me using Openhab 2.2.0 snapshot vs release?

I just looked at the XML in the binding and see BARRIER_STATE and all the other channels you are seeing. I didnt realize the device database was updated back in April. I haven’t deleted (or reinitialized) the Things for my garage openers, which would have picked up these changes!

So, I reinitialized them and am in the same state as you (I’m also on 2.2.0 snapshot). I swapped my items from barrier_operator to barrier_state and everything is behaving as before. I tried the other channels and nothing came through. Which I’m not surprised about, since the device does not use the ALARM CC (http://products.z-wavealliance.org/products/1298/classes).

The items for one of my garage doors:

Switch	    GarageAttached_Door	            "Garage Door (Attached) [MAP(garagedoor.map):%s]"	        <garagedoor>	(gGarageAttached,gLock,gGarageDoor,gSleep_Security)
Number	    GarageAttached_Door_Position	"Garage Door (Attached) [MAP(garagedoor.map):%s]"           <garagedoor>	(gGarageAttached,gGarageDoor,gSleep_Security)     {channel="zwave:device:07cb40a2:node177:barrier_state"}

garagedoor.map:

0=CLOSED
ON=CLOSED
252=CLOSING
253=STOPPED
254=OPENING
255=OPEN
OFF=OPEN
-=Unknown
NULL=Unknown

This rule sends a 255 or 0 to open and close the door, based on the switch state:

rule "Lock: Update garage door barrier_state after switch state change events (GarageAttached_Door)"
when
	Item GarageAttached_Door changed
then
    if (GarageAttached_Door.state == ON) {//closed
		GarageAttached_Door_Position.sendCommand("0")
        logDebug("Rules", "Lock: Update garage door barrier_state after switch state change events (GarageAttached_Door_Position) [{}]",GarageAttached_Door_Position.state)
    }
    else if (GarageAttached_Door.state == OFF) {
		GarageAttached_Door_Position.sendCommand("255")
        logDebug("Rules", "Lock: Update garage door barrier_state after switch state change events (GarageAttached_Door_Position) [{}]",GarageAttached_Door_Position.state)
	}
end

The number items change if the remote for the garage doors are used, so this rule keeps the state of the switch correct:

rule "Lock: Update garage door states after barrier_state events (GarageAttached_Door_Position)"
when
	Item GarageAttached_Door_Position received update
then
    if (GarageAttached_Door_Position.state == 255 && GarageAttached_Door.state == ON) {
		GarageAttached_Door.postUpdate(OFF)
        logDebug("Rules", "Lock: Update garage door states after barrier_state events (GarageAttached_Door) [{}]",GarageAttached_Door.state)
    }
    else if (GarageAttached_Door_Position.state == 0 && GarageAttached_Door.state == OFF) {
		GarageAttached_Door.postUpdate(ON)
        logDebug("Rules", "Lock: Update garage door states after barrier_state events (GarageAttached_Door) [{}]",GarageAttached_Door.state)
	}
end

EDIT: Here is an updated version that uses a lambda to avoid duplication of code when more than one NGD00Z is being used.

@ashgupta, you added a number of channels that this device does not support. I’m thinking these should be removed to clean up the database, but I don’t know your reasoning for adding them and don’t want to mess anything up!