Linear NGDZ00-4 Garage Door

Yea saw that. Sucks.

I need to re-read this post and see if it is worth just loading the dev branch. My only concern is something I currently have breaking. I just need the time to review and ensure.

Switching between the ozwdev flavor and ā€œregularā€ flavor is a simple flag in the command and a restart of Home Assistant, quite easy to flip back. I have yet to run into any issues using the dev flavor.

1 Like

do you have the command handy? I am curious. Thanks!

Hereā€™s a script with the commands needed. Note these are for the venv installs, YMMV.

OZWDev:

#!/bin/bash

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

# install cython if not already installed
pip3 install --upgrade cython==0.24.1

# remove previously install python_openzwave
pip3 uninstall -y python_openzwave

# install ozwdev flavor of python_openzwave
pip3 install --no-cache-dir 'python_openzwave==0.4.3' --install-option="--flavor=ozwdev"

echo "Deactivating virtual environment"
deactivate
EOF
exit 0

Regular flavor:

#!/bin/bash

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

# install cython if not already installed
pip3 install --upgrade cython==0.24.1

# remove previously install python_openzwave
pip3 uninstall -y python_openzwave

# install ozwdev flavor of python_openzwave
pip3 install --no-cache-dir 'python_openzwave==0.4.3'

echo "Deactivating virtual environment"
deactivate
EOF
exit 0
1 Like

Cool thanks. I run HA in a docker container so I will spin up a dev container and put it on the dev flavor OZW and see what happens.

Thanks!

I have just upgraded from 1.4 to the latest 1.5 dev branch (had to make a couple of patches for freebsd). I was just finding that my schlage locks, and the linear garage door would just fall off the radar occasionally and require a power cycle.

Hopefully this will fix my problems :slight_smile:

Which model of schlage do you have? BE469? If so Iā€™d be curious to find if you now have a new sensor named USERCODE

FreeBSD is a fickle beast.

1 Like

I donā€™t have a sensor names usercode. What is this for?

Actually only a couple of tiny line changes were needed! If I get time I will submit back into openzwave.

actually usercode just showed up for one of my BE469ā€™s.

1 Like

It will show up usually right after using a code to unlock for the first time. Just curious to see if it updates. Iā€™ve found that it shows the last used usercode slot that unlocked the door, butā€¦ Only updates after a restart

Ah it just showed up when my wife unlocked the door, and it has a ā€œ1ā€ in it which I assume corresponds to the 1st usercode.

The problem I have right now is that I am getting data in the access control telling my the door is locking/unlocking, however my lock.front_door state is not changing to reflect :expressionless:

2018-05-15 14:43:53.841 Info, Node022, Received Alarm report: sensorSrcID=0, type:Access Control event:Access Control - KeyPad Unlock, status=true
2018-05-15 14:44:01.719 Info, Node022, Received Alarm report: sensorSrcID=0, type:Access Control event:Access Control - Manual Lock, status=true

Try another code. Iā€™d bet the number will stay at one unless you restart HA. Also the lock/unlock will show for manual locks but not for the lock itself. One of the sensors will show as you mentioned. Locked with keypad. Etc. you can probably still lock/unlock from you though

Iā€™ll give that a try tonight.

I was a little confused about your second part. My lock.front_door doesnā€™t ever reflect the manual or keypad changes. I can, however, unlock and lock the door through HA perfectly fine.

I remember having this issue when I first onboarding to openzwave back some time last year, and then did something and suddenly everything worked as expected.

Iā€™ll say. Iā€™ve been running the dev flavor since I started. I needed it for my garage door opener. The garage door opener has been great. The bahvior of my schlage as far as sensors, etc seems to have been different than most everyone else in the community. Iā€™ve come to believe that there is a bug in version 1.5 when it comes to the schlage be469 deadbolts. I just posted some details today to an OpenZWave group. Weā€™ll see how that goes.

What you are experiencing seems to match what Iā€™ve experienced

1 Like

The best place to continue this discussion is here Schlage Locks.

Lots of ā€œgoodā€ info there, butā€¦ I suspect like me you will find that your locks does not have the same sensors as everyone else.

any idea after an update to 0.70 why this is happening?

terminate called after throwing an instance of ā€˜OpenZWave::OZWExceptionā€™
what(): Manager.cpp:2018 - InvalidValueIDError (101) Msg: Invalid ValueID passed to GetValueAsBool
Aborted (core dumped)
(tried 0.4.3 and 0.4.4 - going to try non dev flavor of OZW)

adding some additional context in the hope it may help:

Traceback (most recent call last):
  File "src-lib/libopenzwave/libopenzwave.pyx", line 494, in libopenzwave.notif_callback (src-lib/libopenzwave/libopenzwave.cpp:5908)
IndexError: list index out of range
2018-05-27 23:05:05 ERROR (Dummy-16) [libopenzwave] notif_callback exception
Traceback (most recent call last):
  File "src-lib/libopenzwave/libopenzwave.pyx", line 494, in libopenzwave.notif_callback (src-lib/libopenzwave/libopenzwave.cpp:5908)
IndexError: list index out of range
2018-05-27 23:05:05 ERROR (Dummy-16) [libopenzwave] notif_callback exception
Traceback (most recent call last):
  File "src-lib/libopenzwave/libopenzwave.pyx", line 494, in libopenzwave.notif_callback (src-lib/libopenzwave/libopenzwave.cpp:5908)
IndexError: list index out of range

it seems something in 0.70 is causing the issue, as reverting back to using 1.4 & 0.4.4 allows z-wave to load, but the issue is then with the cover component. Iā€™m now struggling to dig any deeper in to troubleshooting