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.
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.
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.
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 ?
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.
@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 ?
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.
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.
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 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 (Product Command 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"}
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!