Linear NGDZ00-4 Garage Door

still will not pair any ideas

What procedure are you following to pair? Did the logs change since you moved the hub closer? I found the hub had to be very close to get a successful pairing.

Razorface was able to get it paired, it actually paired the first go the log was showing something about node 62 when their device paired as node 57.

The main issue was not having a network key for secure network inclusion.

Putting this here for anyone that comes along later as I had to dig through the thread to put things together.

  1. The GSZ00-4 does work, I am using Home Assistant 0.110.1 in docker and it appears as a cover and a few sensors. If you only see one sensor, it failed to add as a secure device.
  2. It is a secure device, the secure key MUST be set in HA for zwave
  3. If you have had zwave setup from before the GUI was added and you never set the network KEY you will have to fix that BEFORE adding the device.

If you are already setup the secure key currently can’t be fixed from the UI or by putting an entry back in the config…

You will need to search .storage/core.config_entries for network_key , if it is NULL then it isn’t set.

You will need to stop HA, replace the NULL with a new KEY that will be quoted and look like:
“0xDE, 0xAD, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0xBE, 0xEF”

There is a guide on generating a key.

If you already attempted to add it without the key being setup in Zwave you will need to completely delete the device and start over.

After the device is added it will initiatilly show as unknown, just go to the zwave section select the unknown node and select refresh.

If all else fails restart HA and the name and the cover and sensors should be added when HA starts.

2 Likes

I just went through the pain of getting these set up with HA (converting from Smart Things) and finally got it all working. A few points to add to the excellent summary by @BlinkyLights:

  • Don’t add any custom entries to a custom openzwave config folder. If you did (like I did) this won’t work and you need to remove them and exclude the openers that you added when they were in place.
  • You must do Add Secure Node
  • After hitting Add Secure Node hit the button on the side of the controller once. It will beep, then go “beep-beep-beep”. Then…
  • WAIT. Wait a while. Like a minute or two or three. Suddenly the controller will go “beep-beep-beep” again and voila! It’s in Home Assistant.

Phew!!!

1 Like

If you’re running the new OpenZwave beta integration here’s an MQTT cover to help while they finish up cover support, just make sure you adjust your ValueIDKey to whatever the value is under .../commandclass/102/:

cover:
  - platform: mqtt
    name: "Garage Door"
    device_class: garage
    command_topic: "OpenZWave/1/command/setvalue/"
    state_topic: "OpenZWave/1/node/6/instance/1/commandclass/102/value/281475083239444/"
    qos: 0
    retain: true
    payload_open: '{"ValueIDKey" : 281475083239444, "Value": 4}'
    payload_close: '{"ValueIDKey" : 281475083239444, "Value": 0}'
    state_open: "Opened"
    state_opening: "Opening"
    state_closed: "Closed"
    state_closing: "Closing"
    optimistic: false
    value_template: "{{ value_json.Value.Selected }}"
1 Like

How do you find the ValueIDKey? I am looking and I think I am looking in the wrong place.

Steps:

  1. Use MQTT Explorer to connect to your MQTT Server
  2. Go to OpenZWave/1/node/<NODE OF YOUR GDO>/instance/1/commandclass/102/value
  3. Find the Value in this branch that has "Label": "Barrier State" in it, that’ll be the ValueIDKey to use

Example screenshot:
image

I’m not 100% sure the ValueIDKey is unique so it’s always good to check your own.

Thank you I was looking in the wrong spot!

1 Like

Barrier support should be in 0.113, no more having to use a MQTT work around :slight_smile:

This was helpful! Curious, how do you know if a device needs to be added as a secure node?

Usually by reading the manual :stuck_out_tongue:

I’m having trouble connecting and accessing the actual switch to control the garage door.

I’m able to see two devices only and neither seem to control the door.

sensor.gd00z_4_garage_door_opener_remote_controller_basic
binary_sensor.gd00z_4_garage_door_opener_remote_controller_sensor

I’m running HASSIO 0.116.2 and utilizing the Add-on for OpenZWave 0.5.2

I clicked “Add Node” in OpenZWave and it asks “Do you wish to include the new device with encryption?” which I assume to be a secure node.

Any ideas?

Did you set your network key?

I stopped the network on OpenZWave and setup ZWave from the integration page, added the network key, added a secure node and it worked.

But yes, I had previously setup a network key on OpenZWave.

I also did the reverse, shut down ZWave, reinstalled OpenZWave with a network key and no cover option.

It has to be the same network key that you used for the ZWave integration.

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.