Linear NGDZ00-4 Garage Door

I had nothing to do with it, I just find work arounds for things not working like any good engineer :stuck_out_tongue:

Now we just need a way to get the zwave thermostats modes combined to 1 controlā€¦

1 Like

So I just noticed that HA has forked openzwave to add their own patches, and the first one includes the barrier class to support garage doors openers :slight_smile:

This means that in a future version, we will no longer have to maintain our own fork of openzwave for this purpose.

@firstof9, we need to work on figuring out the V3 setpoint upgrade in dev. I have been pulling my hair out trying to figure it out.

All the changes are listed here:

https://github.com/OpenZWave/open-zwave/commit/c0f0a47de6019291c92783b8cd4d9c82dc0f9ff6

Iā€™m sure if you contact the one in charge of the hass-ozw fork they could pull those files in for the next update.

@firstof9, thank you for your response. These are the four commits I identified as being pertinent:

  1. 64eb38524697b36e5b097d18a878a503ecabbb0a
  2. c0f0a47de6019291c92783b8cd4d9c82dc0f9ff6
  3. 03b46a499d3accfd3bf04eb6818522dc579e3c0d
  4. 47dcee16719eb0338342c372233fa86ce584b56e

You obviously mentioned #2. If I were to add the commits to my repo, would I need all four or just the one?

Appreciate the assistance as I am in uncharted waters.

Iā€™d have to say all 4 look required as they each build on the proper implementation of the Setpoint V3.

Hey folks,
So just (yesterday) pulled down the 0.82.0b4 docker beta to test the new HA OZW fork, and it builds without any extra intervention (WOOOHOOOO) and adds the barrier command class #winning

One thing to note is even after a few HEALs and Reboots i couldnā€™t get cover.garage to show up. The 0x66 command wasnā€™t being recognized by the node. Now iā€™m all too familiar with deleted all my z-wave stuff and rebooting (and the headache of renaming things) so I thought iā€™d find out why.

caveat - this could be beta, it could be just an issue I suffered, but thought this may save people time. Essentially in zwcfg___.xml under your node number for the garage door:
<Node id ="number"
should be a section starting with this:
<CommandClass id="102" name="COMMAND_CLASS_BARRIER_OPERATOR" version="1" issecured="true">

However I did not - so used the section from a backed up working version and BINGO!
After a reboot cover.garage was there in all its secure barrier class glory :slight_smile:

This is not really a garage door thing, but more of an OWZ question. So with the new fork coming out which fixes the barrier class, does anyone know what the process is to try to get other patches added to the fork. I have added the cover and a patch for zwave locks to my branch.

Soā€¦ My question is, how to I request adding this to the HA branch

thereā€™s a conversation about this going on right now on the #zwave of discord.

Seems code was already merged to fix the ā€œDelete Usercodesā€ issue:

This is only merged to anyones fork that they wanted to patch. The PR on the main OZW master branch is still open. I started doing some testing when the ha-ozw branch went live and it seems you cannot just ā€œpatchā€ inside of HA the same way that we have to date with our own forks. Unfortunately I think we still have to do the same method, just with the new branchā€¦ Pull down the ha-ozw branch locally, copy it via Dockerfile. No need to uninstall the new homeassistant-pyozw package I donā€™t think. Actually you might have to reinstall without the --install-option=" --flavor=dev.

UPDATE: So I tried forking the HA branch over, adding in the UserCode.cpp fix and then in my Dockerfile I initially just copied over the open-zwave folder and let HA install with its own homeassistant-pyozw.

That didnā€™t pick up the locally added open-zwave branch with the lock clear user code fix. I then uninstalled the homeassistant-pyozw and reinstalled it like weā€™ve been doing for a while now and that didnā€™t pull it over either. So Iā€™m not sure how this is going to work at this point.

not sure i fully understand the process, but cant we just push the lock clear user code fix to the HA OZW branch for the next release?
possibly add to 0.83 beta?

I asked Balloob and he said if its not a commit that has been merged to the master OZW branch, it shouldnā€™t be added. I also asked one of the OZW devs why this cannot be added and there are differences of opinions.

@ptdalen @pdobrien3 @firstof9 According to balloobā€¦

balloobToday at 1:49 PM

We just replaced the pypi ozw dependency in HA with our fork build. You can still patch things the same way, just now build our fork and point that at your branch.

So this is where Iā€™m confused. How do we point this at our branch?

Thanks @jaburgesā€¦

This solved it.

so @ptdalen this is the solution.

First clone the new HA open-zwave branch ā€œhassā€. Copy that to your build folder. Then your Dockerfile is as follows.

FROM homeassistant/home-assistant:0.82.0
ENV LOCAL_OPENZWAVE=/usr/local/share/open-zwave
COPY /open-zwave $LOCAL_OPENZWAVE

RUN set -e && \
    pip3 uninstall -y homeassistant-pyozw && \
    pip3 install --no-cache-dir homeassistant-pyozw==0.1.0 --install-option="--flavor=dev" && \

Funny. Docker install with the win and now venv install left in the dust.

So if the merge is in the Dev branch it wonā€™t be considered for addition to the ha open-Zwave fork?

Was there any more to that section that I can use in mine? Same boat here, added but no cover shows up. The rest of the <CommandClassā€¦ sections have other lines then end with

< /CommandClass > (I had to add spaces to make it show up in the comments)

Thanks.

Bash script to help you out:

#!/bin/bash

# Update homeassistant-pyozw

if [ "$(id -u)" != "0" ]; then
echo "This script must be run with sudo. Use \"sudo ${0} ${*}\"" 1>&2
exit 1
fi

echo "Changing to user homeassistant"
sudo -H -u homeassistant /bin/bash <<EOF
echo "Activating virtual environment"
source /srv/homeassistant/homeassistant_venv/bin/activate
echo "Updating homeassistant-pyozw to dev version"

# Change this path to your modified branch of homeassistant's openzwave fork
export LOCAL_OPENZWAVE=/home/homeassistant/open-zwave/

pip uninstall -y homeassistant-pyozw==0.1.0
pip install homeassistant-pyozw==0.1.0 --no-cache-dir --no-deps --install-option="--flavor=dev"

echo "Deactivating virtual environment"
deactivate
EOF
exit 0
2 Likes

Tbd but at the moment the HA branch is based on the hass branch which has barrier. Thatā€™s the one I used. Master doesnā€™t have it. Either way, venv can use the same as I did.

Aw, the new homeassistant-pyozw==0.1.0 doesnt install on freebsd, seems to be compilation errors in the branch of openzwave.

Back to my own branch :frowning: