OpenHab2 and Linear NGD00Z-4 Garage Door Controller

Reading the forum often helps:

Yep, latest snapshot is yielding different results.

Everything is working now… Found two more issues after updating OpenHab, and now the door works as expected (freaked the wife out since she was at home, and I was at work, lol).

Hello,
I’m very new to openHAB, and am coming from a Vera. I have 2 of the NGD00Z-4 Garage Door Controllers that I’m trying to setup. I’ve read through a number of posts, which seem to contain piecemeal information on this. Is there a how-to for getting this setup from start to finish somewhere? It seems like it should be much easier than what it appears to be. Thanks

After 8 hours of working on it, I’ve got it on the network but still not functioning. Any help is appreciated.

position

This is my 2CarDoor.items file contents:

Switch    2car_Grg_Pwr   "2-Car Door Power"   <poweroutlet>   (Garage, gPower)      {channel="zwave:device:01FFFFFF-FFFF-FFFF-FFFF-160118150928:node5:switch_binary1"}
Switch    2car_Grg_Lts   "2-Car Lights"   <light>   (Garage, gPower)      {channel="zwave:device:01FFFFFF-FFFF-FFFF-FFFF-160118150928:node5:switch_binary2"}
Switch    2car_Grg_Dr    "2-Car Garage Door [MAP(garagedoor.map):%s]"    <garagedoor>    (gGarageDoor,gSleep_Security)
Number    2car_Grg_Dr_Psn    "2-Car Garage Door Position [MAP(garagedoor.map):%s]"    <garagedoor>    (gGarageDoor,gSleep_Security)    {channel="zwave:device:01FFFFFF-FFFF-FFFF-FFFF-160118150928:node6:barrier_state"}```


And my default.sitemap file contents:


sitemap default label="AH Home" {

    Frame {

        Text label="2-Car Garage" icon="house" {
			Default item=2car_Grg_Pwr
			Default item=2car_Grg_Lts
            Switch item=2car_Grg_Dr
			Text item=2car_Grg_Dr_Psn 
        }


        Text label="1-Car Garage" icon="house" {
            Default item=1car_Grg_Pwr
			Default item=1car_Grg_Lts
        }

    }
}

The barrier_state channel should be linked to a Number Item, and will report:

255 (open)
254 (opening)
253 (stopped)
252 (closing)
0 (closed)

It is also used to control the garage door, by sending 255 (open) and 0 (close). You should setup a Switch Item that you can set to ON or OFF through a rule, based on the barrier_state, and to control the door. I have two NGD00Zs, and this is an example of how I used them in the Rules DSL…

I haven’t looked at this for a while, as I now use JSR223-Jython, but I could provide my current working example, if it could be of use.

I had also added the alarm_raw channel, but as of yet, I have not seen it report anything. The Z-Wave spec says that it would be used for safety report, like if the door closed on a car or something.

Thanks for the reply. I have the following in garagedoor.map:

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

As I understand, the last 2 lines in my 2CarDoor.items file have the switch and the position indicator, am I wrong?

Switch    2car_Grg_Dr    "2-Car Garage Door [MAP(garagedoor.map):%s]"    <garagedoor>    (gGarageDoor,gSleep_Security)
Number    2car_Grg_Dr_Psn    "2-Car Garage Door Position [MAP(garagedoor.map):%s]"    <garagedoor>    (gGarageDoor,gSleep_Security)    {channel="zwave:device:01FFFFFF-FFFF-FFFF-FFFF-160118150928:node6:barrier_state"}

Do I not have the barrier state linked properly? I’m only seeing a NaN in the paperui.

Your Channel looks odd. Confirm it in Paper UI> Configuration> Things> your opener, and verify the Chanel you have configured matches. If it does, you’ll need to enabled debug logging for the zwave binding and see why the door is not reporting.

Wait a second… your Items start with a number… I’m pretty sure you can’t do that!

Nope…

You should be seeing errors in VS Code, on OH startup, or after saving the file.

1 Like

Sorry to invade on this thread.

I’m considering getting one of these devices. Before I pull the trigger, I’m interested in anyone who can weigh in on the long-term reliability. A number of Amazon reviews complain about the device failing after a number of months. I’m curious if anyone here has had a similar experience.

Thanks for the reply. I was unable to reply last night due to new user forum rules. Sorry for the double post, I was initially posting for one problem, that then merged into the same problem. I didn’t see any errors with the number or character but changed them all anyway. Still no luck.

default.sitemap

sitemap default label="AH Home" {

    Frame {

        Text label="Two Car Garage" icon="house" {
			Default item=twoCar_Grg_Pwr
			Default item=twoCar_Grg_Lts
            Switch item=twoCar_Grg_Dr
			Text item=twoCar_Grg_Dr_Psn 
        }
    }
}

And my updated twoCarDoor.items:

Switch    twoCar_Grg_Pwr   "Two Car Door Power"   <poweroutlet>   (Garage, gPower)      {channel="zwave:device:01FFFFFF-FFFF-FFFF-FFFF-160118150928:node5:switch_binary1"}
Switch    twoCar_Grg_Lts   "Two Car Lights"   <light>   (Garage, gPower)      {channel="zwave:device:01FFFFFF-FFFF-FFFF-FFFF-160118150928:node5:switch_binary2"}
Switch    twoCar_Grg_Dr    "Two Car Garage Door [MAP(garagedoor.map):%s]"    <garagedoor>    (gGarageDoor,gSleep_Security)
Number    twoCar_Grg_Dr_Psn    "Two Car Garage Door Position [MAP(garagedoor.map):%s]"    <garagedoor>    (gGarageDoor,gSleep_Security)    {channel="zwave:device:01FFFFFF-FFFF-FFFF-FFFF-160118150928:node6:barrier_state"}

Do the other zwave items that you’ve listed work? This should eliminate the odd ChannelUID.

Could you be more specific :slightly_smiling_face:. Does the barrier_state Item change values when the door is manually operated, and does the door open/close when sending 255/0 to barrier_state? You could quickly test this in Karaf…

smarthome:send twoCar_Grg_Dr_Psn 255

I have used one of these for about 3 years, and another for about 1.5. The only issue I’ve had was with losing security keys (device no longer responds and Habmin shows red check, and restarting does not help), which all of my secure devices seem to occasionally do. This might be a binding issue… still trying to track it down. They’ve worked well for me.

Hi,
Yes, the other items all work as expected. The barrier state didn’t change at all when the door is moved.

position

I logged into the karaf console with

 openhab-cli console

Sent the command:

smarthome:send twoCar_Grg_Dr_Psn 255

And now the paperui looks like this:

255

Your Items look good then. And looking back in the other thread, this shows the device is securely included. There is an odd message in alarm raw though (BARRIER_ERROR_UL_REQUIREMENT…), which is kind of cool, since this shows the device will actually use that channel… and I’ve never seen anything come out of it.

How is the device hooked up to the garage door opener, and which one are you using? I’m thinking OH is setup OK, but that you’re not connected properly to the opener. Another possibility, is that you include the device close to the controller, but since mounting it, you are out of range of the controller or another device with beaming.

That error you saw is now gone since my SmartStick+ reconfigured itself after a reboot or two after the SNAPSHOT upgrade. That’s when I started to get the new nodes with the bajillion Fs.

I don’t totally remember how it is exactly connected to the opener. I have been using this controller with a micasa verde for the past 2yrs or so, and haven’t changed any of the controller connections since switching it to OH. It’s within range of the controller ( <20’ away) and surrounded by other relays that are now connected. I’m fairly convinced that I’m doing something wrong as I’m not a programmer type at all, but I just can’t seem to figure out what.

OK, then it must be hooked up right too. But this…

… I don’t understand, so lets’s go back to secure inclusion, because it sounds like you may have needed to include it again. What do you see in Habmin> Configuration> Things> the device> Attributes?

BTW, this is definitely not a normal amount of hassle when setting up OH… so hang in there!

Okay. I did exclude/include again, but it’s easy enough if I have to do it another time. Thanks for all your help BTW.

Nah… that looks like it’s still securely included. But I think I understand your issue now, which I should have noticed in your other screenshot. The device is reporting that this is a Z-Wave Plus device. Here is mine…

The device db includes the Type:ID for your device, in the same entry as the non-plus version. We may need to make a new entry for the plus version. @chris may have a thought on this, but he goes to bed early (UK).

Just for kicks, what do you have under associations?

Something else that may/may not be noteworthy is that the scene_number isn’t showing up from a light switch I’m using either. Only displays as a “-”. Hmmm… it also happens to be listed as a plus device. Maybe this is an issue with both?

None of the association groups are selected from the list. Only showing it for informational purposes.

Doubtful that the issue is related… save that for later.

I doubt this will do anything, since it would only help with receiving reports from the device, but try setting the Group 1 Association to the controller and see what happens. Probably nothing.

If you do the same for the other device, it may help too, but it will probably be labelled Lifeline.

I took a look at your other device in the db, but there are two (1, 2) devices with the same Type:ID listed, and only one of them is zwave plus… something else for Chris to take a look at.

Okay. I’m attempting to set the group, but it just continues to say “pending”. Am I supposed to be doing something else as well?