Linear NGDZ00-4 Garage Door

Thanks @zarthan for suggesting to work on the xml configuration file, now I finally got it to work. I had a look at the xml configuration of the device that triggered the upgrade of the command class and it contained the key to success for setting up Thermostat Setpoint:

<CommandClass id="67" base="0" typeInterpretation="A" />

Suddenly the correct temperature settings were read from the device and changing the temperature actually works now… The key was typeInterpretation=“A” that refers to the Z-Wave public Command class specifications for Thermostat setpoint v2 and v3. Need a bit more work on the configuration file, but at least I’ve established contact…

Once you have a completed file, you might want to post something to the OZW developers so it can be included in future OZW updates.

@baardpt

So, I ultimately followed @winter to get my setup working. Before going down the github path, I did install the dev branch of openzwave. During that time period, I noticed what seemed to be a much more verbose setup for my 2gig adc2000 thermostats although I never got to the point of trying to configure them before going back to the master branch of openzwave with the linear garage door added locally.

Now I am at a stage where I need to get my thermostats working in Home Assistant.

Any assistance would be greatly appreciated. I have tried to find the github branch for the openzwave dev like I did for the garage door but have failed.

Thanks in advance.

P.s. I read your posts several times but can’t really comprehend what you are doing.

Hi, I’m really not an expert, started with Homeassistant and Z-wave a few weeks ago only.

I tried to find your device in the Z-Wave product catalogue, but could not. If the device is there, it will have a list of command classes and versions. The command classes of my HVAC adapter is listed here. If documentation of the device states that Thermostat setpoint version 3 is required, then you will need to run the ozwdev flavor, otherwise, it shouldn’t be necessary. Anyway, here is approximately what I did. Note that I started with a fresh Hassbian installation, without the python-openzwave installed at all, so I didn’t have to uninstall it first.

I followed the instructions from @ttaidapos in comment 507 above, but modified it so that I used a locally cloned development branch of Open-zwave. So follow the first 6 steps from @ttaidapos, then replace the git line with this

git clone -b Dev https://github.com/OpenZWave/open-zwave.git

Continue and complete the procedure.

As pointed out by @zarthan, you probably don’t need to clone anything locally, skip the git, chown and export statements and just the run pip3 install with flavor set to ozwdev instead of dev. The modified @ttaidapos procedure will then be (I have now tried this myself after a SD card failure):

sudo systemctl stop [email protected]
sudo su -s /bin/bash homeassistant
source /srv/homeassistant/bin/activate
cd /home/homeassistant/
pip3 install cython wheel six
pip3 install 'PyDispatcher>=2.0.5’
pip3 install --upgrade cython==0.24.1
pip uninstall -y python_openzwave
pip3 install python-openzwave --install-option="--flavor=ozwdev"
exit
sudo nano /srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/zwave/__init__.py //update the requirements to 0.4.4

I then created a new entry for my device in the manufacturer.xml with a new manufacturer folder and a new device XML in.

/srv/homeassistant/lib/python3.5/site-packages/python_openzwave/ozw_config/

For the device XML I fetched some information from the OpenHab device library and then found the key entry that made it all work in the Open-Zwave database for the Euro spiritz thermostat

<CommandClass id="67" name="COMMAND_CLASS_THERMOSTAT_SETPOINT" version="3" base="0" typeInterpretation="A" />

Edit: luckily I wrote this down… my SD card just failed, so I have to start over…

For anyone who uses docker, I got this working using winter’s openzwave fork. Unlike one of the previous Dockerfiles in here, I did not lose my device names (altho I migrated from a virtualenv installation which was already using winter’s fork). winter’s fork has some updated device files vs the version in pip, I think.

# need the git repo so that we can copy it into our docker image.
$ git clone https://github.com/ryanwinter/open-zwave.git

$ cat Dockerfile 
FROM homeassistant/home-assistant:0.66.0
ENV LOCAL_OPENZWAVE=/usr/local/src/open-zwave
COPY open-zwave/ $LOCAL_OPENZWAVE/
RUN set -e && \
  pip uninstall -y python_openzwave && \
  pip3 install --upgrade cython==0.24.1 wheel six && \
  pip3 install --no-cache-dir 'python_openzwave==0.4.3' --install-option="--flavor=dev" && \
  mkdir -p /usr/local/share/python-openzwave && \
  ln -s /usr/local/lib/python3.6/site-packages/python_openzwave/ozw_config /usr/local/share/python-openzwave/config

$ docker build -t homeassistant-with-barrier .

$ docker run \
  -d \
  --name=homeassistant \
  --restart always \
  --net=host \
  --device /dev/ttyUSB0 \
  -v /dev/ttyUSB0:/dev/ttyUSB0 \
  -v /dev/ttyUSB1:/dev/ttyUSB1 \
  -v /appconfig/homeassistant/config:/config \
  -v /etc/localtime:/etc/localtime:ro \
  homeassistant-with-barrier

I am new to Home Assistant and i am currently a smarthings hub user and looking to switch over to HA. I have a GoControl/Linear GD00Z-4 Z-Wave Garage Door unit. I read thru this thread it looks like pain to get this working. Has this gotten any easier to get installed?

Yup a single command: pip3 install --no-cache-dir 'python_openzwave==0.4.3' --install-option="--flavor=dev" then wait 30-45 mins for it to compile.

If you already have python_openzwave installed you need to do this command first: pip uninstall -y python_openzwave

So in order:

pip uninstall -y python_openzwave
pip3 install --no-cache-dir 'python_openzwave==0.4.3' --install-option="--flavor=dev"

It’s been a long while (my garage door has been sadly unautomated for months now) but do you need to patch/compile the open-zwave and open-zwave-control-panel libraries as well?

I tried installing the dev versioon of the python component but ran into this:

Installing collected packages: python-openzwave
Running setup.py install for python-openzwave … error
Complete output from command /opt/homeassistant/bin/python3.6 -u -c “import setuptools, tokenize;file=’/tmp/pip-install-nh8n8sce/python-openzwave/setup.py’;f=getattr(tokenize, ‘open’, open)(file);code=f.read().replace(’\r\n’, ‘\n’);f.close();exec(compile(code, file, ‘exec’))” install --record /tmp/pip-record-_7zdozya/install-record.txt --single-version-externally-managed --compile --install-headers /opt/homeassistant/include/site/python3.6/python-openzwave --flavor=dev:
sysargv [’-c’, ‘install’, ‘–record’, ‘/tmp/pip-record-_7zdozya/install-record.txt’, ‘–single-version-externally-managed’, ‘–compile’, ‘–install-headers’, ‘/opt/homeassistant/include/site/python3.6/python-openzwave’]
<pyozw_setup.DevTemplate object at 0x7fb576f3f390>
Fail to install minimal dependencies Cython
Can’t find openzwave
Traceback (most recent call last):
File “”, line 1, in
File “/tmp/pip-install-nh8n8sce/python-openzwave/setup.py”, line 43, in
print(current_template.ctx)
File “/tmp/pip-install-nh8n8sce/python-openzwave/pyozw_setup.py”, line 226, in ctx
self.finalize_context(self._ctx)
File “/tmp/pip-install-nh8n8sce/python-openzwave/pyozw_setup.py”, line 247, in finalize_context
ctx[‘define_macros’] += [(‘PY_LIB_FLAVOR’, self.flavor.replace(’–flavor=’,’’))]
TypeError: ‘NoneType’ object is not subscriptable

----------------------------------------

Execute this before the install of python_openzwave:

pip3 install --upgrade cython==0.24.1

So I’ve been quietly monitoring this recently. I’ve also got this great garage door opener, but I don’t necessarily want to give up all the work I’ve put in - it sounds as though I may be losing all the device names if I go this route. Is this in fact the case? And/or is it possible we are just any closer to actual support from OZW?

What do you mean?

This was mentioned shortly above. I also assumed in rebuilding the OZW component, I’d be having it start fresh at “naming” all my devices again. As you probably know, naming right now is a pain to get thru. So I won’t lost the pairings, I thought I would lose all my naming, and in turn, all my entity items being named properly as well until I go back through and do it all again.

I’m pretty new to this, but am running home assistant in a python VM on ubunu 17.10. I have not added any zwave devices yet, but planned on doing that this weekend. So all I need to do is run these two lines, and I’ll be good to go adding the linear opener?

Any downsides to doing this?

Use these 3 just in case:

pip3 install --upgrade cython==0.24.1
pip3 uninstall -y python_openzwave
pip3 install --no-cache-dir 'python_openzwave==0.4.3' --install-option="--flavor=dev"

are there any significant known issues with using the flavor=dev?
Thanks for the help

I haven’t run into any issues myself. YMMV

this breaks from the following:

python-jose-cryptodome 1.3.2 has requirement pycryptodome<3.4.0,>=3.3.1, but you’ll have pycryptodome 3.4.11 which is incompatible.
pyatv 0.3.9 has requirement aiohttp<3,>=2.3.0, but you’ll have aiohttp 3.1.1 which is incompatible.
netdisco 1.2.4 has requirement zeroconf==0.19.1, but you’ll have zeroconf 0.20.0 which is incompatible.
myusps 1.3.2 has requirement requests==2.12.4, but you’ll have requests 2.18.4 which is incompatible.
fedexdeliverymanager 1.0.4 has requirement beautifulsoup4==4.5.1, but you’ll have beautifulsoup4 4.6.0 which is incompatible.
fedexdeliverymanager 1.0.4 has requirement requests==2.12.4, but you’ll have requests 2.18.4 which is incompatible.
pyozwman 0.4.4 has requirement python_openzwave==0.4.4, but you’ll have python-openzwave 0.4.3 which is incompatible.
pyozwweb 0.4.4 has requirement python_openzwave==0.4.4, but you’ll have python-openzwave 0.4.3 which is incompatible.

ah right 0.4.4… so this small modification:

pip3 install --upgrade cython==0.24.1
pip3 uninstall -y python_openzwave
pip3 install --no-cache-dir 'python_openzwave==0.4.4' --install-option="--flavor=ozwdev"
1 Like

sadly same deal - installing cython==0.24.1 gives me this:

python-jose-cryptodome 1.3.2 has requirement pycryptodome<3.4.0,>=3.3.1, but you’ll have pycryptodome 3.4.11 which is incompatible.
pyatv 0.3.9 has requirement aiohttp<3,>=2.3.0, but you’ll have aiohttp 3.1.1 which is incompatible.
netdisco 1.2.4 has requirement zeroconf==0.19.1, but you’ll have zeroconf 0.20.0 which is incompatible.
myusps 1.3.2 has requirement requests==2.12.4, but you’ll have requests 2.18.4 which is incompatible.
fedexdeliverymanager 1.0.4 has requirement beautifulsoup4==4.5.1, but you’ll have beautifulsoup4 4.6.0 which is incompatible.
fedexdeliverymanager 1.0.4 has requirement requests==2.12.4, but you’ll have requests 2.18.4 which is incompatible.

Try installing cython w/o the version number. ie: pip3 install cython if it’s already installed you should be good to go.

1 Like