ah ok, so OZW is the one to wait for. Thanks!
Looks like this is the issue thread - https://github.com/OpenZWave/open-zwave/issues/490
Don’t hold your breath with OZW. That fix went in 2 years ago and we are still waiting 
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 
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 
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=trueTry 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)