great idea, Sorry, you were so knowledgeable, I thought you were one. haha. Any idea where the best place to start with that would be. Thanks again
@winter - Bringing this discussion over from HERE.
I suspect you have 7 sensors tied to your BE469
lock.back_door_lock
sensor.back_door_lock
sensor.back_door_lock_access_control
sensor.back_door_lock_burglar
sensor.back_door_lock_power_management
sensor.back_door_lock_system
sensor.back_door_lock_usercode
Is this correct? Also in your openzwave log, can you confirm you are running 1.5 or higher.
Can you confirm that " sensor.back_door_lock_usercode" does not update when you unlock the door, but if you restart HA, it will show the last used usercode, but then not change any more until another restart.
I supect sensor.back_door_lock_access_control will update immediately if you manually lock, unlock, keypad lock or unlock, but the lock itself will not update in the UI, unliess you lock/unlock with HA either via automation or script or UI.
Does that describe your current situation?
Yes I am running 1.5. I compiled the Dev branch yesterday so currently sits at 1.5.3108.
I also have all the related sensors you are seeing. User code is missing right now, but that’s likely because I repaired the devices yesterday (in an attempt to fix the lock sensor).
Yes the lock.* sensor doesn’t update unless initiated from HA. I remember having this exact problem before in 1.4 but somehow resolved it. I think this might have had something to do with pairing without the security key though so this would be unrelated.
I will try tonight:
- Unlock different user codes and observer sensor.*_usercode
- Observe sensor.*_access_control more closely, but so far it does appear to update immediately on all lock/unlock methods.
- Take a look at the different between the master and Dev branches to see if I can understand why the lock.* behaviour has changed.
1 Like
Looking at the lock zwave.py in HA, it does appear to be capturing the access_control information and using this to update the lock status. For some reason this isn’t working anymore. I will try and add some debug to this tonight to see what is going on here.
def update_properties(self):
"""Handle data changes for node values."""
self._state = self.values.primary.data
_LOGGER.debug("Lock state set from Bool value and is %s", self._state)
if self.values.access_control:
notification_data = self.values.access_control.data
self._notification = LOCK_NOTIFICATION.get(str(notification_data))
if self._v2btze:
if self.values.v2btze_advanced and \
self.values.v2btze_advanced.data == CONFIG_ADVANCED:
self._state = LOCK_STATUS.get(str(notification_data))
_LOGGER.debug(
"Lock state set from Access Control value and is %s, "
"get=%s", str(notification_data), self.state)
if not self.values.alarm_type:
return
alarm_type = self.values.alarm_type.data
_LOGGER.debug("Lock alarm_type is %s", str(alarm_type))
if self.values.alarm_level:
alarm_level = self.values.alarm_level.data
else:
alarm_level = None
_LOGGER.debug("Lock alarm_level is %s", str(alarm_level))
if not alarm_type:
return
if alarm_type == 21:
self._lock_status = '{}{}'.format(
LOCK_ALARM_TYPE.get(str(alarm_type)),
MANUAL_LOCK_ALARM_LEVEL.get(str(alarm_level)))
return
if str(alarm_type) in ALARM_TYPE_STD:
self._lock_status = '{}{}'.format(
LOCK_ALARM_TYPE.get(str(alarm_type)), str(alarm_level))
return
if alarm_type == 161:
self._lock_status = '{}{}'.format(
LOCK_ALARM_TYPE.get(str(alarm_type)),
TAMPER_ALARM_LEVEL.get(str(alarm_level)))
return
if alarm_type != 0:
self._lock_status = LOCK_ALARM_TYPE.get(str(alarm_type))
return
1 Like
So as far as I can tell, the missing sensors is “alarm_type”. Without this the update function just returns and never gets to setting the lock status.
Why is alarm_type now missing? I have no idea…
So am I. This is with two different schlage be469 deadbolts, I have paired them 6 inches from my controller, and across the house with the same results. I even went as far as buying a brand new deadbolt just to make sure it was not old firmware (mine were a couple years old), it was the same. The only thing I could see that made my install different than most is the 1.5 version of open zwave. Everyone else was either running the stock version (1.4) or were running 1.5 but not with the schlage.
Also eveyone else does not have the “usercode” sensor, which I could only assume was the “newer” way of passing usercodes, but is not fully working.
Wanted to throw this out there as well. I have a few zooz 4 in 1 zwave plus motion sensors. They are actually the last of my zwave devices I’m moving over because I dont have much of a need for them in my setup.
Anyway, I’m finding that although they do pair successfully, none of the sensors are reporting motion alerts.
These devices pair with as a secure node, successfully. They also report temp, humidy, light, and those seem to work.
While reading and asking questions it seems as if I am missing a sensor, that people have used for motion.
Guess what it is
alarm_level
Also there is a missing
alarm_type sensor.
Same as the locks.
I don’t think its coincidence.
I think you might be onto something. I have a eco link motion sensor and this is also missing alarm_level/alarm_type. I’m pretty sure it used to be there.
The Alarm class in openzwave has changed significantly from master to Dev.
Specifically in the master branch I see the following which shows the alarm_type and alarm_level being raised (Release):
ValueByte* value;
if( (value = static_cast<ValueByte*>( GetValue( _instance, AlarmIndex_Type ) )) )
{
value->OnValueRefreshed( _data[1] );
value->Release();
}
if( (value = static_cast<ValueByte*>( GetValue( _instance, AlarmIndex_Level ) )) )
{
value->OnValueRefreshed( _data[2] );
value->Release();
}
In the Dev branch, this is still there, but restricted to a version 1 block. There is new code to differentiate between a version 1 and 2 alarm. V2 is commented as having more detailed information about the alarm and has all sorts of additional stuff.
V2 it’s missing.
Looking through my OZW logs, seems to be that I’m received a v2 alarm based on the format of the log message I’m receiving for all three of my alarm devices (2 schlage locks and a ecolink motion sensor).
So, where to next?
- The most obvious thing would be to move the alarm_type and alarm_level code out of the v1 if block, so it executes for both v1 + v2, which is the behaviour in the master branch. I suspect this will fix things.
- Figure out why this change was made in the first place and then submit a PR to get this into the Dev branch!
After patching the openzwave code, I managed to get the lock functionality working again, not sure how reliable it is. I realised that I’m pretty sure my ecolink motion sensor was working, even without the Alarm fix.
I wonder if the HA code should be updated to support the v2 alarm code instead of trying to get the v1 to work. I’ll have to investigate more.
1 Like
I’d love to try to do this as well, but admit that patching code is a little above what I’ve done so far, any chance you’d be willing to send me the steps, process. Or do you think I should wait for a bit?
Sure, let me check this into my forked github, then it’s just a couple of steps to get it going.
-
Clone my fork:
git clone https://github.com/ryanwinter/open-zwave.git -
Switch to Dev branch
cd open-zwave
git checkout Dev -
Point the openzwave environment variable to this code checkout (this is my path below, change it to yours).
setenv LOCAL_OPENZWAVE /mnt/homeassistant/tmp/open-zwave -
Uninstall existing python-openzwave
pip uninstall python-openzwave -
Install using the local code checkout, will use the LOCAL_OPENZWAVE variable to fine the code.
pip install python-openzwave==0.4.3 --install-option="–flavor=dev" -v
thanks, I just pulled this down into my home directory for Home Assistant, ran into an issue with setenv “command not found”, I am running ubuntu, Sounds like its a bash vs cs issue (at least thats google info, haha)
I think EXPORT is equivalent, but stopped out of not wanting to mess anything up, haha.
Also quick question about step 5, It will just automatically use the local source? Not doubting, just trying to learn, 
Thanks
I think you are right, I’m on FreeBSD so dont have export 
But yes, you just want to set the environment variable with the appropriate command.
Yes, with step 5 it will use the local source code the variable points out. That’s what the “-flavor=dev” is telling the package to do. Check out GitHub - OpenZWave/python-openzwave: Python wrapper for openzwave for more information on what the command line means, they explain it pretty well.
dev : for python_openzwave developers. Look for openzwave sources in a local folder specified by the LOCAL_OPENZWAVE environment variable (defaults to ‘openzwave’).
1 Like
Received a few errors
Skipping bdist_wheel for python-openzwave, due to binaries being disabled for it.
pyatv 0.3.9 has requirement aiohttp<3,>=2.3.0, but you’ll have aiohttp 3.1.3 which is incompatible.
and
error
Cleaning up…
Removing source in /tmp/pip-install-mpbtyxyf/python-openzwave
Command “/srv/homeassistant/bin/python3 -u -c “import setuptools, tokenize;file=’/tmp/pip-install-mpbtyxyf/python-openzwave/setup.py’;f=getattr(tokenize, ‘open’, open)(file);code=f.read().replace(’\r\n’, ‘\n’);f.close();exec(compile(code, file, ‘exec’))” install --record /tmp/pip-record-252ql5vn/install-record.txt --single-version-externally-managed --compile --install-headers /srv/homeassistant/include/site/python3.6/python-openzwave [Gflavor=dev” failed with error code 1 in /tmp/pip-install-mpbtyxyf/python-openzwave/
I’m sure its me and my learning, So, I ran these commands as the home assistant account while my python VM was activated. Was that correct?
Er, I have a pretty different setup I think. I ran this as root in a freebsd jail.
But looking at your message, I have version aiohttp 3.1.3 which is correct and the version my python-openzwave is using
PyAtv looks like some kind of apple TV thing which appears to depend on an older version of aiohttp, so pip cant install both versions at the same time so has an unresolvable conflict… Do you use some Apple TV thing here? If not then I would just “pip3 uninstall pyatv”.
If you want to keep it, then it seems that pyatv has updated their dependencies in the source code, but haven’t yet released a new version. Whether you could install the dev branch version instead, or just wait for the next release to fix the dependencies…