OpenHab2 and Linear NGD00Z-4 Garage Door Controller

Add-ons Bindings
,
144

Correct. I just added the Group:Switch and it works great.

The Concepts section of the documentation states:

Group:Switch:AND(ON,OFF) sets the Group state to ON if all of its members have the state ON , OFF if any of the Group members has a different state than ON .

Group members sounds generic to me.

image
image885×507 5.81 KB

image
image883×503 5.84 KB

Sitemap

Text item=Garage_Doors_State labelcolor=[ON="red",OFF="green"] valuecolor=[ON="red",OFF="green"]
Setpoint item=Doors_Outside_GarageOne minValue=0 maxValue=255 step=255
Setpoint item=Doors_Outside_GarageTwo minValue=0 maxValue=255 step=255
1 Like
145

Excellent… I was not aware that groups behaved this way! I thought that the value was NULL if any member’s Item.type != baseItem.type of the group. I’ll have to test this out… my memory is that it wasn’t always like this.

I still need rules and SwitchItems though… Alexa control, Habpanel, identifying which door is open (possible with your solution, but more complex), etc.

146

Does the latest zwave binding snapshot allow for secure inclusion with the GD004-Z?

I’m on 2.5.0.201908091758, and can’t get the garage controller included securely after over 10 tries (normal door locks worked fine for secure inclusion). I’ve confirmed the following:

  • Running OH 2.5. Latest snapshot zwave binding.
  • Set to high power inclusion mode
  • Set secure inclusion mode to “all devices”
  • Changed security key

Any help is appreciated!

147

I see comments further up this thread where people are securely including the device.

148

Right. That’s what’s puzzling me. Can’t figure out why it’s not letting me securely include. Thought it might be the binding version.

149

Did you factory reset the device between the attempts?
Did you finish including the device within 15 seconds after the controller starts the inclusion?

150

Yes, and yes :slight_smile:

151

Then I have no idea, sorry.

152

How close were the controller and device? I’ve never been able to include these devices unless they were very close to the controller and sometimes it still took many attempts. It always goes better to wait after a binding restart too, until the network settles down.

153

Thanks for all the suggestions everyone. Good news and bad news.

Good news! Secure inclusion finally worked, but only by doing a hardware reset on the Aeotec Z stick. Was hoping to avoid going so destructive, but it worked.
Bad news. There are still only two channels appearing:1) Barrier State and 2) Alarm (Raw). Is this the expected behavior? I had read there should be four channels as long as secure inclusion was completed successfully, but I know things can change quickly.

Ultimately, I’d like to be able to read the status of the door and open/close it through openhab. Haven’t had time to play with it after getting the device paired

154

Glad you got it included! This is expected. This topic and the forum is full of discussions and examples of how to use them. Let me know if you have trouble getting them working.

155

Ah, great, thanks! Good to know. I’ll make sure to read up when I get back

156

Thanks to the great suggestions and rules from @5iver , I’ve got the garage partially working with his code from this post: OpenHab2 and Linear NGD00Z-4 Garage Door Controller

However, when I manually operate the garage, the log shows the following error and the item state doesn’t change. Has anyone run into this? Might it be caused by an unstable zwave sensor state? As far as I can tell, everything from the rule seems to check out.

2019-08-14 13:48:29.436 [INFO ] [eclipse.smarthome.model.script.Rules] - Lock: Garage door events: update switch after barrier_state change [GarageDoorOpener]=ON
2019-08-14 13:48:29.472 [INFO ] [eclipse.smarthome.model.script.Rules] - Lock: Garage door events: Start: input item state [GarageDoorOpener_Position]=[0], initial action item state [GarageDoorOpener]=[ON]
2019-08-14 13:48:29.474 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Lock: Update garage door item states': cannot invoke method public java.lang.String java.lang.Object.toString() on null
157

I’ve updated the rule to removed the lambda (there was no reason to use a lambda) and to use the “Member of” trigger. Each time the rule is triggered, it will trigger the rule a second time, confirming the new state update was successful. The old rule worked, and my guess is that you didn’t have both ‘received command’ and ‘changed’ triggers.

158

@5iver I finally got around to installing my Linear garage door opener. It included securely on the first try (yay!). Since I don’t run a nightly heal, after I got the device installed in its final location, I ran a heal on it, as well as several of the devices that are located near it. It seems to be communicating fine with the binding.

Using this little interface device I got, I’m also successfully able to control my Liftmaster garage door.

A couple things I noticed…

  • The device seems to report it’s status asynchronously about every 20 minutes. Is this normal?

  • When operating the door manually, the device isn’t reporting it’s open or closed status. I’m not happy about this. Is this normal? I haven’t checked the logs, but since the rule is using received update, even if the state didn’t change, the rule should be triggered.

  • When operating the door by sending 0 and 255 to the barrier_state channel, sometimes the device doesn’t report the final state of the door. So, for example, when closing the door, sometimes the final state gets stuck at CLOSING (252), or when opening the door, sometimes the final state gets stuck at OPENING (254). This is more annoying than it is a real problem. Is this normal?

Edit: BTW, thanks for the rule and item definitions posted earlier in this thread.

159

You mean just randomly reporting it’s state? This does not sound normal. Though, in string winds, the doors on one of the garages moves enough that the door senses it’s opening. Not so good in the middle of the night! Tightening the door up helped.

That is definitely not normal. Did you install and pair the sensor? There is a little piece of tape over the battery… make sure that is removed. Also check that it is installed in the correct orientation. The batteries seemed to last for years, but you may need to check that too. IIRC, there is a pairing procedure in the manual after the device is included. I think it was just manually opening and closing the door to get it to sync up.

Not normal… sounds related to #2

Are you using the rules DSL or Python version? Both of my NGD00Zs have lost their security keys, which happens more often than I’d like. Your post will incite me to get them reincluded this weekend and to post the Python version of the rule!

160

Not exactly randomly… In the zwave log I can see it reporting its state every 20 minutes. It’s very consistent, so it has nothing to do with movement of the door.

Yes. And I did the open/close procedure to do the pairing. The fact that it reports the proper status sometimes, I suspect its paired properly. The sensor is located in the upper corner of the door, and the device is located above the opener. I can’t image that spacing (maybe 20 ft) is a problem…

Rules DSL.

My opener is reporting firmware version 2.1.

I may need to mess around with it some more when I get home tomorrow.

161

I wrote a simple rule to log every time the item is updated. You can see it updating every 20 minutes.

2019-11-09 06:02:40.517 [INFO ] [thome.model.script.garagedoor-linear] - LINEAR: Received status update: 0 (CLOSED)
2019-11-09 06:22:40.953 [INFO ] [thome.model.script.garagedoor-linear] - LINEAR: Received status update: 0 (CLOSED)
2019-11-09 06:42:41.390 [INFO ] [thome.model.script.garagedoor-linear] - LINEAR: Received status update: 0 (CLOSED)
2019-11-09 07:02:41.835 [INFO ] [thome.model.script.garagedoor-linear] - LINEAR: Received status update: 0 (CLOSED)
2019-11-09 07:22:42.241 [INFO ] [thome.model.script.garagedoor-linear] - LINEAR: Received status update: 0 (CLOSED)
2019-11-09 07:42:42.677 [INFO ] [thome.model.script.garagedoor-linear] - LINEAR: Received status update: 0 (CLOSED)
162

@mhilbush Did you ever come to a resolution of this problem? I’m reading this thread and my device seems to be exhibiting some similar behaviors. Mine is also exactly 20 minutes…

2021-04-09 20:34:09.718 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-09 20:54:09.793 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-09 21:14:10.246 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-09 21:34:10.696 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-09 21:54:11.148 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-09 22:14:11.600 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-09 22:34:12.052 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-09 22:54:12.503 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update

The device has been working perfectly for years (opens and closes garage door), but recently, I tried to create a log of the last 10 state changes, and it’s been a headbanging exercise, mostly because I can never figure out what state the item is currently in and what state it is transitioning to. For example, (I believe)

Device will be closed 0, and report an update, but I don’t know what’s “triggering” the update, the device state is still 0 (see log above)

Device will be closed 0, and report an update to 255, then report an update to 254 (another state update), then report 255 (another state update)

Device will be closed 0, and report an update to 255, then report an update to 255 (another state update)

These values seem to be “random”. If the door is closed and when the rule is triggered, curr (see code below), can be 0, 255, or 254, and prev can be 0, 255, or 254.

rule "New Event Log"
when
    Item F1_Garage_Door received update
then
    logInfo("garagedoor", "F1_Garage_Door: received update")

    val curr = F1_Garage_Door.state
    val prev = F1_Garage_Door.previousState.state

Any help would be greatly appreciated!

Gah!

SixO

For completeness:

Number   F1_Garage_Door                     "Garage Door: [MAP(garagedoor.map):%s]"     <garagedoor>       (F1_Garage)                      ["Door"]                           {channel="zwave:device:e321a338:node20:barrier_state"}

0=CLOSED
252=CLOSING
253=STOPPED
254=OPENING
255=OPEN
255.0=OPEN
=UNKNOWN
163

Here are some of my actual log files for clarity:

2021-04-11 08:19:49.997 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-11 08:19:50.001 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: curr: 0
2021-04-11 08:19:50.001 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: prev: 0.0
2021-04-11 08:39:19.338 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-11 08:39:19.342 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: curr: 255
2021-04-11 08:39:19.342 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: prev: 0.0
2021-04-11 08:41:48.102 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-11 08:41:48.105 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: curr: 0
2021-04-11 08:41:48.105 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: prev: 255.0
2021-04-11 09:00:48.749 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-11 09:00:48.751 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: curr: 255
2021-04-11 09:00:48.751 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: prev: 0.0
2021-04-11 09:20:49.220 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-11 09:20:49.223 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: curr: 255
2021-04-11 09:20:49.223 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: prev: 255.0
2021-04-11 09:40:49.665 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: received update
2021-04-11 09:40:49.668 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: curr: 255
2021-04-11 09:40:49.669 [INFO ] [openhab.core.model.script.garagedoor] - F1_Garage_Door: prev: 255.0

Unrelated to my problem, I suspect that it’s a simple variable type bug in “previousState.state” that is outputing a decimal instead of an integer.