Linear GD00Z-4 Garage Door Opener Remote Controller
that is connected via Zwave and shows up on the Overview page with no errors and shows it is ready.
But it does not show a tile for me to control it. Any thoughts? I do have another Zwave device that is working and is controlable
Garage Door
16 minutes ago
Ready
node id
4
node name
Linear GD00Z-4 Garage Door Opener Remote Controller
manufacturer name
Linear
product name
GD00Z-4 Garage Door Opener Remote Controller
query stage
Complete
is awake
true
is ready
true
is failed
false
is info received
true
max baud rate
40000
is zwave plus
false
capabilities
listening, routing, beaming
neighbors
1, 2
sentCnt
3
sentFailed
0
retries
0
receivedCnt
0
receivedDups
0
receivedUnsolicited
0
sentTS
2018-06-20 19:36:11:888
receivedTS
2018-06-20 19:36:11:366
lastRequestRTT
25
averageRequestRTT
44
lastResponseRTT
0
averageResponseRTT
0
I have the same desire. I am moving over to HASS from SmartThings and would like my GD00Z-4 to work with HASS. I am using the hassbian version not hass.io.
I found this thread on the device but it has over 600 posts on the thread I still don’t really understand how to make the device work from reading a LOT of them. Not all yet so hopefully I just missed the key post
I wonder if we can turn this thread into the new “accurate” source of how to make this device work. Trying to read the other thread so far has been so confusing. It’s several years old so full of outdated info. I can’t believe this device doesn’t just work in the new build at this point. That has me very worried about how difficult it will be to make this switch.
This post looks the most promising. I just don’t understand the risks of building the open zwave code this way and replacing what comes with HA. Doesn’t this mean future updates from HA may break and that I am now stuck with this version of the code unless I self maintain it somehow?
In addition the posts after this post discuss issues with the steps not working so still trying to digest it all to know what I need to do and how risky it is to do it.
@ptdalen maybe you can help us understand what is being done with these steps and the risks of doing so? If you don’t mind.
I was in on that thread trying to get the gocontrol to work and i was never successful. I eventually returned it and went a different route using a z wave dry contact switch and a tilt sensor. it was cheaper and WAY easier to get working.
I can only help a little, For the most part I’m just good at reading directions and following them haha. My steps above are really pretty much a copy of someone elses steps above mine.
At the time I really did not even really understand what I was doing other than I wanted my garage door opener to work. I am running Home Assistant in a VENV (not hasbian, or hass.io)
So here is my bes explination. Open Zwave is an open source project for zwave devices. It is currently at version 1.6.xxx. Home Assistant uses Open Zwave for its Zwave controls. But it’s currently only using 1.4.xxx for compatability reason, i think.
So, Open zwave 1.4.xxx has issues and does not support the linear DG00Z-4 garage door opener. aka Cover. Cover is the term used for anything that opens/closes, garage door openers, shades, etc.
1.5.xxx does support the garage door opener. So Open Zwave is made up of lots of files. A few of them (3 I think) are the ones that are part of the Cover class required for the garage door opener. So someone used git to branch (fork?) the currently supported version of Open Zwave (1.4.xx) and then took the 3 cover files that work with the garage door. Then you are compiling the modified version and using that for your install.
I chose to create a branch of that on my git repository so that I am in control of my own files, just in case.
There are very simple steps on this thread to use the dev flavor as well. This will use the current development branch of openzwave with your build, and requires no compiling, git, etc. Although it worked, for me and a few others, there were issues with a couple of other devices. Schlage locks were the main one.
I cannot give any steps on how to do this stuff with hasbian or hass.io. But hopefuly this explination, which is probably only 90% correct, will help you to better understand whats going on in the background
I had created a simple to use/modify bash script to install the dev version that supports the GDO:
You’ll need to modify the paths, but once you execute it (while HASS is not running) it will install the OpenZwave dev version that has cover support. This version might have issues with other Zwave devices in your network, ie Shalge Connect Door locks due to the devs continuous work on the project. I personally have not run into any issues with any of my Zwave devices using this version currently. YMMV
I thought that adding a node securely accomplished the basically the same thing where the zwave side was concerned. as far as the rolling code security of the standard remote control of the newer style garage door opener itself that should be separate from the z wave operability.
Or am I incorrect there?
And besides that my old garage door opener doesn’t have the newest security technology as in the newer devices (which allowed me to use a regular dry contact switch in the first place) so I haven’t lost any more security than I had before (assuming what i said above is correct…)
Just adding the node securely does not accomplish the task. The device has to have the ZWave security functions in order to function as a secure node. Using “Add Secure Node” activates the pairing handshake and if the device has the security function it starts the AES key exchange, if it’s a non-secure node, it just pairs normally no security involved.
Basicly as is, someone could record your ZWave packets to the relay then replay them to open your garage door as they are unsigned/unsecured packets.
But if the switch supports security then what I said above is true, correct?
It’s been a while since I installed the switch but I think i remember it being secure. I’ll have to double check it tho. It was the first z wave device i ever added so i could be mis-remembering.
But, again, I’m using an old garage door opener (that is itself prone to sniffing and copying) with it so I don’t think I’m any less secure than without it.
Eventually I may make the switch to a newer one but living in a small midwestern town and with a detached garage i don’t think I’m at too big of a risk.
Thanks for the heads up tho.
edit: just checked the website and it states it is “security compatible” so I think I should be ok on the z wave side.
You did a great job. As a developer I understood all of it. You do have impressive reading skills.
On issue I worry about is that by switching the OpenZWave code used by HA to your own version which you maintain via your own (or someone else’s) fork things may work when you update HA in the future. Assuming they upgrade the OpenZWave version they are using. Of course that said it sound like they have been sticking with a pretty old version for a while now anyway. The original GD00Z-4 thread was started in July 2016 and it seems still no progress to get this working has been made in the official version.
Why does this break security?
Thanks for sharing your version. I have a bunch of questions about your technique if you don’t mind.
Your script is basically the same thing that ptdalen did but you used the official DEV version of 0.4.3 instead of the forked version, correct? Why is that better?
Your other script doesn’t use the dev version. What is the reason to use one vs the other?
What is this step for?
pip3 install --upgrade cython==0.24.1
Also you are lowering the version you use? @ptdalen mentions that HA uses 1.4 instead of the current 1.6 version. You are downgrading to 0.4.3. I would think that would have fewer devices not more. That has me completely confused.
I have these, so looks like your solution may not be best for me.
Confused again. You stated earlier that taking these steps breaks security. So I assumed your version doesn’t (not sure why), but now you are saying the device will connect secure?
I don’t see why upgrading the OpenZwave library would break security. I can see downgrading breaking it because older versions of ZWave didn’t even have security.
Anyway thanks folks. I really think we should but together a GD00Z-4 documentation page and include this info. I am willing to help do that if we can.
Depends on the device, I’ve seen some Zwave relay switches that do not have the security option. Without the encryption a replay attack could be used to trigger the relay to open the garage, but his has this feature so he is fine.
Installs cython for compiling the openzwave libraries used in the python-openzwave package.
No.
1.4 of OpenZwave library. 1.5 is the dev version of the OpenZwave library.
0.4.3 is the python-openzwave version, these are to separate software packages.
It’ll work, you just won’t be able to see which user code was used to open the lock, if I recall that was @ptdalen’s problem as he uses that data for his automations. The dev version is ever changing and a future version my resolve the issues he had…
@firstof9 was responding to the first post I made above about my alternative garage door opener setup maybe not being secure. I don’t think he meant to say that using his method or the @ptdalen version of OZW will be less secure. At least I don’t think he was…
Ah, since this seems to be the package we are swapping I thought that was the one being discussed. Thanks for the clarification.
No worries, it’s good to get all these details.
I don’t worry too much about garage door security because I have inner secured doors and I figure if a thief is sophisticated enough to watch my zwave packets and copy them then they will find a way in anyway Nice that it is secure though.
Not sure if this goes here or not but I have searching for 4 days ugh. Is anyone aware, after device is integrated, to bypass the beeping and flashing lights?
I would much rather it work as a normal garage door button and when I press it on my phone the door just opens without the delay
Where would I be able to find more information on this? I haven’t located any laws on it. A hand held remote opener is essentially the same concept but doesn’t have the delay, lights or beeping.
If it’s something I can’t work around I suppose I’ll just ditch the go control and use remotes I just hate trying to keep track of things lol
