OpenHab2 and Linear NGD00Z-4 Garage Door Controller

5iver · May 21, 2019, 1:23am

If that is all the funcitonality you need, then you’re not missing anything. I have all my garage door openers and outer door locks in a group that lets me know if all outer doors are locked. And I have rules that turn on lights, notifications, etc. For this, I need a switch items.

Robbie · May 21, 2019, 4:12pm

Thanks @5iver, still lots for me to learn.

A group for all of the garage doors like below seems to provide the correct overall status. I assume this group could also be part of a subgroup now that its just a switch?

Group:Switch:AND(OFF,ON) Garage_Doors_State

Number Doors_Outside_GarageOne "His [MAP(garagedoor.map):%s]" <garagedoor>  (Garage_Doors_State) {channel="zwave:device:839cd123:node9:barrier_state"}
Number Doors_Outside_GarageTwo "Hers [MAP(garagedoor.map):%s]" <garagedoor> (Garage_Doors_State)  {channel="zwave:device:839cd123:node10:barrier_state"}

5iver · May 21, 2019, 5:05pm

Correct, but it could have been an a group before adding the aggregation function too. Now it reports state updates automatically. I use OR(ON,OFF), but that is logically the same as AND(OFF,ON)…

Robbie · May 21, 2019, 8:20pm

I chose AND because the state being evaluated is OFF, and that’s the same zero value as CLOSED. So my logic was ‘are all doors closed’. My guess was OR(ON,OFF) would not work since ON=1 / OPEN=255? To be clear I just added the Group:Switch for each door’s numeric barrier state channel. There isn’t a virtual switch or rules involved.

5iver · May 21, 2019, 9:10pm

Are you saying this is working? TMK, a group with type Switch will only aggregate Items of type Switch.

Robbie · May 21, 2019, 11:57pm

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.

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

5iver · May 22, 2019, 9:41am

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.

roy_liao · August 11, 2019, 9:41am

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!

chris · August 11, 2019, 9:58am

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

roy_liao · August 11, 2019, 5:50pm

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.

sihui · August 11, 2019, 5:54pm

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

roy_liao · August 11, 2019, 5:56pm

Yes, and yes

sihui · August 11, 2019, 5:58pm

Then I have no idea, sorry.

5iver · August 11, 2019, 8:16pm

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.

roy_liao · August 12, 2019, 12:42am

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

5iver · August 12, 2019, 12:46am

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.

roy_liao · August 12, 2019, 12:47am

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

roy_liao · August 14, 2019, 10:25pm

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

5iver · August 14, 2019, 10:53pm

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.

mhilbush · November 9, 2019, 1:04pm

@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.