For those confused, using flavor=ozwdev uses the entire dev branch of openzwave. I found that using the dev branch broke more than it fixed.
Using my fork, or the directions to build your own, you get the master branch of open zwave with the barrier cover class files from the dev branch. Your files are also stored locally.
Once installed, I have upgraded multiple times without having to install anything. I used the 0.4.3 version of open zwave as it is the one recommended for use with Home Assistant. For clarity, I am not sure of the difference as I understand you are installing from local files so this is a bit confusing to me.
I end up with version 1.4.2957. I am installing on a raspberry Pi 3 in a virtual environment. Those trying to do it in docker, I can not help. I also believe I am running Python 3.5.3. Not sure exactly how to check but I opened python 3 from the raspi desktop and that is what it reported.
The steps I listed are what I did EXACTLY. I was very careful to document everything I did to a T
Can you please tell me where this file is on your system? I also modified this a while back when I installed the dev version. I am pretty sure I put it back to it’s original state when I when back to my fork, which I think was blank, but I would like to check and report back.
It gets overwritten when you update HA.
In a venv it’ll be something like /srv/homeassistant_venv/homeassistant/lib/python3.5/site-packages/home-assistant/component/zwave/__init__.py
This was very confusing to me also in the beginning. Using install option --flavor=dev uses the files locally on your device. Using --flavor=ozwdev uses the dev branch of open-zwave.
FROM homeassistant/home-assistant:0.70.0
RUN set -e && \
pip3 uninstall -y python-openzwave && \
pip3 install --upgrade cython==0.24.1 && \
pip3 install --no-cache-dir 'python_openzwave==0.4.3' --install-option="--flavor=ozwdev"
For each new HA release, I check the python_openzwave version used for the release and adjust 0.4.3 if needed. Change the the HA version 0.70.0 to the new release I want to upgrade to and docker build.
One thing to note, it will only work with the following version right now (ozwdev manufacturer_specific.xml)
<Product type="4744" id="3030" name="GD00Z-4 Garage Door Opener Remote Controller"/>
<Product type="4744" id="3530" name="GD00Z-4 Garage Door Opener Remote Controller"/>
<Product type="4744" id="3531" name="GD00Z-7 Garage Door Opener Remote Controller"/>
If your id doesn’t match, we need to get it added to the manufacturer_specific.xml on both master and Dev branches of openzwave. I got 3530 (mine) and 3531 added.
I spun up a container with :latest and works well - except for i lost my Schlage Connect alarm level (so cant tell who unlocks the door)
[its always something lol]
Pointed open-zwave-control-panel over to the patched open-zwave library and think I figured out part of what might be going on. Looks like OZCP also only shows a barrier level and not any way to make the garage door go up or down? I tried the latest open-zwave as well (1.5) and tried removing/re-adding (secure) it in. I even hard reset the opener. Not sure what’s going on at this point or if it’s even an OZ issue.
I think I figured out part of the issue, woohoo?! I managed to get the garage door to beep like it’s about to open or close the door, then it does nothing. It makes me think something is up with the cables that connect to the opener. I reseated them into the actual garage opener itself and tried hooking a multimeter to it to see if I could detect a signal but nothing. So I suspect the cable is bad or perhaps a connection internal to the Linear came undone as a guess. I think the Z-Wave side at this point is actually working.
There’s no signal, you’ll be looking for continuity. When you set it to “opened” the relay trips after the beeps and you should get a moment of continuity between the 2 posts for a quick bit.
Hmm yeah that’s not happening even cracked it open and checked the terminals the wire connects to, although I haven’t checked it with an oscope (just a continuity tester) - I suppose if it’s really fast it might not register on my multimeter but I haven’t had that happen before so I kinda doubt it. I thought perhaps the solder joints on the terminals might be the issue. Garage gets up to 40C/104F some days in the summer but I have other electronics in there with no issues. Those are on the bottom of the board so I’ll need to pull it apart to better check.
Yes, I applied a patch to add the alarm level mode back in on the dev branch. They actually didn’t show up as the right names in HA, but it did work in enabled the lock to work correctly again.
I have since reverted back to the stable version with the cover patch. The dev branch was just too unstable for me and the whole HA process would crash each day.
It doesn’t appear to be the meter (I always check to make sure it beeps) and seems to work on other tests. I tried to reflow the solder around the terminals but to no avail. Pretty sure it’s the unit. But the good news is that, otherwise, the steps up above DO work - my problem was/is the opener itself.
I had pondered switching to the Aeon Labs garage door opener but for some reason it’s not available here in the states shrug
thanks for confirming - so you are using the current master OZW branch then just added the patch for the cover?
Could you confirm how that was done? is it possible to just amend the 3 files within the HA structure, or do you need to compile OZW with those files in place?
Trying to get to the same end result in a docker container (so these changes need to be made as i build the container (or in theory copy the files in after)
So I seem to have garage door and the Schlage connect door lock now all working in a docker.
However i’m getting VERY slow load times of battery operated sensors.
Weirdly locks and the siren load fine, but door sensors and motions sensors (including a multi sensor) are taking around 10 mins to move from CacheLoad
Remember, battery operated sensors have a COMMAND_CLASS_WAKE_UP interval. This is how often they wake up and try to communicate to the hub (outside of triggers). This could be 1 second or longer and you can adjust them as needed (more often, faster battery drain).
I have sensors that are set to 240, 1200, 3600 seconds. My guess yours are set to 600.
I just went back to my last post in Jan. There are a lot of post so I could have easily missed something, bottom line, barriers are still not fixed in the OZW version loaded from the HA update. Is this correct?
even cracked it open and checked the terminals the wire connects to, although I haven’t checked it with an oscope (just a continuity tester) - I suppose if it’s really fast it might not register on my multimeter but I haven’t had that happen before so I kinda doubt it. I thought perhaps the solder joints on the terminals might be the issue. Garage gets up to 40C/104F some days in the summer but I have other electronics in there with no issues. Those are on the bottom of the board so I’ll need to pull it apart to better check.