OpenHab2 and Linear NGD00Z-4 Garage Door Controller

zwave
z-wave
linear
Tags: #<Tag:0x00007f0142c2ba60> #<Tag:0x00007f0142c2b920> #<Tag:0x00007f0142c2b7e0>

(Mark) #102

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.


(Wes Warner) #103

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"}

(Scott Rushworth) #104

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.


(Wes Warner) #105

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


(Scott Rushworth) #106

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.


(Wes Warner) #107

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.


(Scott Rushworth) #108

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!


(Wes Warner) #109

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.


(Scott Rushworth) #110

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?


(Wes Warner) #111

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.


(Scott Rushworth) #112

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.


(Wes Warner) #113

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?


(Scott Rushworth) #114

No… since this device is mains powered, it should go through very quickly. I suspect the device db may need some cleanup for your device. Let’s see what Chris says.


(Wes Warner) #115

Roger. Thanks again for your help.


(Chris Jackson) #116

It probably isn’t a bad idea, although if the channels and parameters are the same, it probably won’t change anything if there is some sort of issue?

Eg if the only difference are command classes such as the ZWAVE_PLUS_INFO, then it won’t make any difference to anything. If parameters are different, or possibly associations, then we should probably split things out. In the new binding Lifeline is handled automatically, so this in itself won’t make any difference.


(Scott Rushworth) #117

The only difference I can see is the Z-Wave Plus Info CC. There are no config parameters and the associations are the same. It looks like everything is setup properly. The only thing left to do is to take a look at some logs to see what’s going on.

@ufoDziner, did you change the node ID in the Items after reincluding the device? Double check Habmin shows two channels active. Also, have you restarted OH at all? Might as well give that a try that too.

If the device still doesn’t respond, and Habmin shows the device as securely included, then in the Karaf console, run log:set DEBUG org.openhab.binding.zwave, and restart OH again. When the device has completed initialization (you can see the status in Habmin), try to operate the device through OH and also manually, then you’ll want to set the logging back to log:set WARN org.openhab.binding.zwave. The log will be too big to post in the forum, but you could use Google Drive, Drop Box, etc. and share a link to it. But be aware that the log will have security info in it, so you may not want to post it for everyone to see. If not, you can also register on Chris’ website (the one with the device db), create a ticket, and post it there securely.


(Wes Warner) #118

I did not change the node ID of the the item. Haven’t done that for any of the items. OH has been restarted a number of times as I add other items in other parts of the house (easier to take the rpi with me than move the item).

Channels shown below:

I changed the logging, rebooted, logged into the openhab-cli then ran:

smarthome:send twoCar_Grg_Dr_Psn 255

after that I then ran

smarthome:send twoCar_Grg_Dr_Psn 0

Those commands didn’t actuate the door.

Then I opened and closed the garage with the button attached to the garage door opener.

/var/log/openhab2/openhab.log and /var/log/openhab2/events.log submitted to cd-jackson.com via ticket. Let me know if there is anything else you need. Thanks.


(Scott Rushworth) #119

That’s odd… I thought you had reincluded it, which would have changed the node id. Also, it looks like you have two Items linked to barrier_state. Shouldn’t be an issue, but there must be another Item out there. Paper UI will actually show better info for tracking it down.

If Chris has the log, your in good hands. Not much more I can do.


(Wes Warner) #120

I have re-included it more than once. I thought you meant manually changing it somehow. Each time that I re-included it, there were no other additions prior, so I thought it kept the same info. If not, then I misunderstood. Here is a shot from PaperUI.

paperui

Thanks again for your help. I appreciate it.


(Wes Warner) #121

@5iver A small update. I just received a second Door controller to put on my single door, and to help troubleshoot the other. This one connected quickly, and I can read a number back on paperui, so there is definitely something wrong with the binding on the other. I will attempt to remove and rebind it for the 4th time. This time though, I’m going to try using the zensys-tools as they let my get my laptop right up to the controller.