FYI next release of HASS we won’t need to update openzwave anymore, they have forked the repos and added the barrier support.
Link in case anyone wants to review.
2 Likes
Figures… I just got this working last night lol.
Thanks to everyone who made this happen, especially @firstof9
I had nothing to do with it, I just find work arounds for things not working like any good engineer 
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 
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:
- 64eb38524697b36e5b097d18a878a503ecabbb0a
- c0f0a47de6019291c92783b8cd4d9c82dc0f9ff6
- 03b46a499d3accfd3bf04eb6818522dc579e3c0d
- 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 
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
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.