I can take the same video right after lock is/was touched externally.
I am not trying to say @bcopeland was trying to cheat with us but the point is:
there is very easy to create a condition when lock works perfectly fine.
All what you have to do - is to touch lock either manually or with August app.
Unfortunately this working condition lasts only for 5-10 min.
I guess, until lock goes to sleep after inactivity timeout.
After timeout expires lock still responds to the "refresh" command from the HE.
However this very depend on HE SW.
With older 2.2.8.156 HE SW the response from lock to the "refresh" HE command
ALWAYS worked and reflected the correct lock status.
However with the latest 2.2.9.134 HE SW which suppose to fix many locks related
problems the things became broken.
This is very clear pointer to the HE SW unless it was a situation when
minus * minus = plus. Ie. some imperfectness in HE SW was compensated by
imperfectness in the lock firmware. Now assuming HE SW became cleaner but
does not play well with lock buggy firmware.
I am not a SW developer but I am writing a lot of Test SW in C/C++ for testing my HW.
For all variables the golden rule is - every variable must be initialised by the startup
routine. State for all Devices must not be assumed. It must be pulled from the
Device again during startup routine.
In short: All variables must be explicitly initialised and states for all devices must
be determined by reading devices status registers. No assumptions are allowed,
everything must be explicitly determined. If this is not done, different problems
sooner or later will randomly popped up and usually will byte hard.
I am waiting for the solution for this problem.
If problem is in the lock firmware It should/must be clearly communicated to
the August SW developers.
But if problem is in the HE SW it should/must be fixed by HE SW developers.
Just finger pointing to each other will not solve the problem.
Like I said.. I personally use this device.. As well as a Danalock V3 and a Yale.. It’s not just on a test bench, it’s being used in real world setup..
I don’t however ever control it physically or through the app.. But I did verify that physical control is producing reporting as well since this thread…
I personally trust you 10000%.
But I am trying to understand why the same HE SW + Lock FW combination
produces very different behaviour in different setups.
It could be tiny detail which leads to this conditions.
Something is definitely hiding somewhere.
The question is: what and where?
I know, lock firmware is not perfect. But lock firmware complexity is very
simple vs. complexity of the HE SW. The probability for the bug in the HE SW is
much higher. And as I already mentioned, upgrading HE to the latest 2.2.9.134
SW in my case immediately made things worse.
So, what I should think about?
Differences between z-wave meshes are sufficient to explain such differences. For example, I know that @bcopeland has a highly performant z-wave mesh with lots of 700-series devices (including repeaters). What does your mesh look like?
There is no ghosts.
Everything but August Lock (0x7C) is rock solid at this time.
I have one Aeotec 7 repeater (0x5c) which was added about half a year ago
but so far does absolutely nothing.
For the lock, if I send a "refresh" commend it instantly wakes up and
sending a response back to HE. The response was very reasonable
with HE SW 2.2.8.156 and immediately became bogus after I upgraded hub
to the 2.2.9.134 SW.
Taking all the above details in account at least in my case I don't think a
ZWave Mesh is a problem.
@aaiyar : I'm not too familiar with the nuances of Z-wave meshes. Could a difference in Z-wave meshes cause an issue to show-up in one version of the Hubitat firmware and not the other. . . without that issue being related to the Hubitat firmware? I've switched between Hubitat versions 2.2.8 and 2.2.9 a handful of times just to test things out, and I consistently have the issue on 2.2.9 and do not have the issue on 2.2.8.
I will not say "no" but it is very unlikely scenario.
ZWave is a Communication Transport Layer.
It either works or does not.
I have a Znifer and according to the Znifer traces lock always
wakes up and trying to respond to the HE commands.
Here is a results of testing I just did a minute ago:
Clicked "Refresh" button on the lock device page.
Here is a HE Log (only lock related):
Lock waked up and responded but HE recorded only Battery status.
With the older 2.2.8.156 all was the same except HE log recorded
status for Battery, Lock and Contact.
As I already mentioned, this is clear pointer to the problem with HE SW.
And here is HE Log after I clicked on "unlock" button:
Again I can see a lot of activity on Zniffer.
Lock somewhat responded to the "unlock" command (I have no idea how
to decode a response message) but it did not physically unlocked.
Here is a correspondent Zniffer trace:
Initially I thought lock was not able to wake up after it goes to sleep.
But according to my testing this is not a case, lock always wakes up
and trying to respond. Unfortunately something is not right and
lock is not working. Now I am almost convinced the problem is
in the HE SW. But what it is - is a big question.
Unfortunately @bcopeland setup is working as expected and therefore
he cannot reproduce the problem.
I am doing a lot a HW debugging and it is impossible to fix something
if problem cannot be reproduced.
It is what it is.
I tried few things in order to get my Augus Pro Lock working with HE
but ended up with no lock integration all together.
Unpaired lock from C-7 hub.
Updated C-7 and C-5 hubs to the latest 2.2.9.137 SW
Tried to pair lock to the C-5 hub.
Lock paired without any security but absolutely nothing
was working no matter what I tried (skipping long list of what I tried).
Unpaired lock from the C-5 hub.
Attempted multiple times to pair lock with C-7 hub.
Each time I had somewhat different pairing behaviour but ALWAYS
ended up with a ghost device. Removing these ghosts was not easy
but now I don't have neither ghost(s) nor paired lock.
I really low August Pro Lock as well as HE.
But at least at this time marriage between HE and August Lock
is completely broken. Both are screaming for the complete divorce.
So, they are divorced.
I was looking for the replacement but could not find any lock
with all function what August has. One or the other feature
is missing:
Door Sensor
This is very useful for the Auto-lock feature.
Lock will not lock if door left open longer than auto-lock timeout.
Remote Control via app (usually not a problem).
Reliable ZWave (questionable) or
Zigbee (many functions are not supported) communication with HE.
RFID or NFC unlock capability (does not exist together with other functions).
This will be really nice to have. I am thinking about this only because
auto-unlock (at least with my August Lock) is not very reliable.
And actually unreliable auto-unlock is a main reason why I need
my August Lock paired with HE.
Plus I am not sure if marriage with the HE will be successful.
I broke down about an hour ago and ordered the Danalock in Z-wave. This after my last two emails to August support bounced back because their account is "over its quota" (Go figure). I have another contact sensor on the door so Auto-Lock shouldn't be hard to replicate in RM. Of course I'll let you know how the Danalock works and if I ever receive that downgrade from August.
BTW, I considered going with the zigbee version but didn't feel like waiting for shipping from Romania or Lithuania.
Thank you very much for the info and update.
I emailed August about a week ago but never got any response at all.
I do have a separate Door Sensor but for the lock auto-lock
function HE RM must be involved. I am trying to avoid this.
My very strong preference is to have this function local to the lock.
Danalock V3 looks very good but HE does not provide a support
for the Keypad for the Zigbee lock version but ZWave should have it.
I am not sure what it is in a first place (the ability to manage lock codes
from HE, or so).
As I mentioned, my heed to pair lock with HE is only for improving
auto-unlock function. August native auto-unlock usually fails in my
case because I live in the apartment complex and WiFi and GPS signals
are not very stable (frequent on/off) while I am getting in the building.
Anyway, for now I will leave lock and HE separately.
Because the keypad is not exposed to zigbee or z-wave it's not configurable or controllable through the hub.. I'm not 100% sure how it works, but I know it has to be configured through the Danalock App via Bluetooth.. I'm not sure about the zigbee version, but the Z-Wave version bluetooth is enabled/disabled via z-wave..
Are you saying Bluetooth could be DISABLED via Zwave command?
I think, this very dangerous function and sounds like an easiest way to brick the lock.
(Just my opinion.)
Now I am very confused.
I thought the BT is a main communication protocol what app is using for
the initial setup.
And if it is disabled for the ZWave version how you are going to setup new lock?
