Linear NGDZ00-4 Garage Door

Man did I miss that… :slight_smile:

@firstof9 has been a while since I messed with this. I had a different device acting as my hub and I wrote a custom integration. When you were helping me through all the barrier issues. I am guessing all the zwave changes they have made over the last few years all is working. Anyway, my hub is starting to crash, so it time to move over. Right now I have two controllers. 1 is for a two-car door and the other is one car door and that is how I identify them.
I have had the 2-car hooked up on the other hub since day one. The 1-car was paired with the other hub but never installed. So last night I defaulted the 1-car and paired it with HA. Little confusing after it paired. Seem to take a while “initializing”. The one that starts with the cover. works as expected, but what do all the others do? 4 sensors and a binary sensor. What are the best practices for renaming the entity?

All you need is the cover, you can ignore the rest, they are for if someone climbs up and tinkers w/ the device and such.

As I said, I have two and I moved the second one over to HA last night. It seemed to have discovery issues and I thought it might have issues and that is why it was not working with my Almond+. So I mounted the one that was for the 1-car and swapped the sensor also. I don’t know how they are linked to each other. For more information than you care, I will include an email I just sent to GoControl to ask that very question. All seemed to work till I renamed the entity. I used the developer/state tab to do it. Then I added a friendly name in customize.yaml. The door open/close seemed to work, but the sensor did not. I thought I broke some relationships between the entities’ names. This morning, automation that knows when I am leaving for work did open the door and the sensor seemed to report correctly. Also, the old one seemed to work also, although I did not flip the sensor around to see if it was reporting. I just fired it from the Andriod app and it flashed and beeped.
Does it take that long for zwave to settle down before it is responsive? Did I break something by renaming just the covers (both 1 and 2 car entities)?

For more context, here is the email question I sent to GoControl this morning …

My bottom-line question is how does the door sensor link back to the controller?
Is it paired at the factory? Are they, all the same, it goes off the range?
What about a third one?

More context:
Right now I have two (1 car and 2 car). I just added an opener to my shop garage door and if after some testing looks like the range is good, may have a third. I have had the second one for a couple of years and never installed it. The first one was installed in the two-car and the second one was for one car. My controller was Almond+. For my home automation, I use Home Assistant. For years Home Assistant (HA) has had barrier issues with the OZW that they used. I am guessing that has been fixed, but I wrote a custom component to make my Almond+ work as a hub to HA. This worked great for a couple of years, but we recently had an ice storm and it did not work after that. Other z-wave did, so I figured something happens in the pairing. I took that opportunity to start moving my z-wave to HA. So I paired the non-production one (1-car) first. Took some fiddling. Pressing 5 times did not seem to reset it, so I tried to hold down the button while powering up. Restarted a couple of times. Tried the 5 buttons again and at some point, it paired. The discovery took some time. But I could flip the door sensor sitting on the table and it seemed to report correctly. Then I paired the second one. The discovery was taking so long that I thought it failed. So I used the non-production controller in place of the old one. I had pulled the production one down so I could place it next to the zwave controller. So I put up the non-production one and replaced the sensor on the door with the one that came with it. After some testing, the door command worked, but the sensor seemed not to respond. This morning it showed the correct status and I watched it on the app as I left for work and it seemed to work. Also, this morning the old one that was in production was powered up on the table and when I activated it, it did flash and beep like it was going to work. I did not test the sensor.

So before I buy a third one, I just wanted to understand the relationship between the controller and sensor. How does it know which one to report back? Is the sensor its own z-wave node?

In the for what it is worth category. My issue with the one car was the pairing of the tilt sensor. I found on Amazon where they were selling the tilt sensor how to pair it. If anyone runs across this, you hold the button on the controller for 8 seconds, then it will make a quick beep. Then tilt the sensor from closed to open, then wait for the controller to beep again and the light will flash. That it. I don’t know if tilting from close to open would still work. I know what I did seems to have fixed it. So now I have two controllers paired.

Before installing the one-car, I am going to test it from a distance perspective on the shop door. If that works I may buy a third one. If not then I may go with the ESP route, just would like something more secure.

You have the sensor paired to two openers?

Sorry, I miss spoke. My tilt sensor is now paired with its controller.
Two controllers (openers) and two sensors.

One controller and sensor worked out of the box. The other controller work, but the sensor not so much, it seemed if I let it sit it might report. After paring between controller and tilt sensor it now reports as expected within the expected time frame.

As mentioned before, it seems to work on the bench, the next step is to test the range and see if it will work from the shop. If it does, then I might install it there. IOW it will change from “1-Car Garage Door” to “Shop Garage Door” and I will buy a third one for the 1-car. The 1-car is where we keep the 02 Mustang convertible and it is not driven that much.
The reason for automating the 1-car even if we don’t drive it that there is no easy way into it. There are no doors from the house into it like the 2-car. So I aways have to get an existing remote from one of the cars to open it. I am hoping to have a HASP up and make it simple. The shop is for my daughter when she visits. If I am not working on something, she parks in there out of the weather. She can download the app and open it.
But, my confidence that z-wave is now stable, compared to dot forty-something, is getting there.

Should work fine as long as range isn’t an issue, but even if it becomes an issue, with the OpenZWave beta you can put a Pi out there with a zwave stick and connect the Pi to your Wifi or ethernet and have it run as instance 2 to have a 2nd zwave network.

Looks like range is an issue. Did not think about the second Pi. If it was not for wanting to get rid of the Alomnd+ I could move that out there. I have pulled most of my z-wave switches. They were only good up to 7amps and I kept poping the relays in them. I did try and move one that was pulled to see if it would mesh up, but that did not work either. Oh and besides distance my shop is a metal building. I am sure that does not help.

Not sure what I want to do at this point. I will say that both doors opener 1 and 2 car does seem to work correctly.

Trench an outdoor rated ethernet cable to it :stuck_out_tongue:

Already done. When the trench was done for the electrical, I also ran a 1" for low voltage. A little bit of a pain, but I pull 6 cat 6 out there. Currently have an AP. IP network out there is not an issue, just zwave. :slight_smile:

The first picture was before I go a deal at work for a network cabinet, second picture.


So what you can do, with the new ozw is connect a Pi out there with a zwave stick, connect the zwave opener to that stick, and have the pi report back to the MQTT broker on instance 2, all controllable from your main Home Assistant :slight_smile:

Has anyone switched over to the Z-Wave JS? It says it supports barrier now.

Garage doors have been supported by the zwave_js integration since HA 2021.3.

In particular, the barrier part that this thread fought for so long, correct?
I could not find it anywhere in the document except for a version/feature matrix. That did have the barrier checkmark. I just wanted to make sure, my only zwave is Linear NGDZ00-4.

Yes. It was mentioned in the release notes for that release: https://www.home-assistant.io/blog/2021/03/03/release-20213/#z-wave-js-update

This thread was started in 2016 for the original z-wave integration. It’s not really relevant anymore. I wish threads like these would be closed…

I was only asking here because I knew there would be people that had the NGDZ00-4 :slight_smile: But I do know what you are talking about. When I was trying to get text-to-speech (TTS) working I got confused by some deprecated instructions.
Any gotchas before I switch?
Thanks for the info.

No worries, the comment was not directed at you in particular, just something that continues to bug me about these forums. :slight_smile:

As to advice about switching, the main advice I would recommend would be to read the docs in their entirety before doing anything. Doing so will answer most questions. The second would be if you use addons, to consider up front whether you want the advanced control of zwavejs2mqtt or would be content with the more basic functionality of the official zwave-js addon (which gains more and more functionality with each release via HA). It’s easier to choose one at the beginning and stick with it, but it’s also easy to switch later if needed (see docs), and the docs describe both.

The migration path is manual, be ready to rename devices and entities. Guides exist in these forums.

As for GDOs, there’s nothing in particular, they function the same between all integrations. Just make sure you transfer your network key over correctly, it is required to maintain functionality.