August plugin reports the wrong lock state (gen4, doorman l3) #54722
Comments
|
august documentation |
|
Hey there @bdraco, mind taking a look at this issue as it has been labeled with an integration ( |
|
The doorman l3 isn't supported at this time. |
d96moe
changed the title
|
Please turn on debug logging for |
|
I tied to set up debug log for yalexs and pubnub, but it's not working. logger: |
|
|
wow that was quick @bdraco! I will test it as soon as I get home. |
|
Here is what I hope is the relevant log lines. Please let me know if I should try to finde some other info. Did also try the doorbell, but haven't found the relevant log lines yet. I will look for them now. |
|
'status': 'securemode' Looks a bit interesting
Can you lock the lock and show which messages appear when it’s locked
Also repeat the process for unlocking
Thanks
…Sent from my iPhone
On Sep 7, 2021, at 5:44 PM, Morten Vinding Svendsen ***@***.***> wrote:
Here is what I hope is the relevant log lines.
I have tried to obfuscate it a bit (the XXX's), hope the meaning is still pressent.
2021-09-07 21:25:49 DEBUG (MainThread) [pubnub] {'t': {'t': '16310427496482006', 'r': 12}, 'm': [{'a': '5', 'f': 0, 'i': 'pn-bd5311e3-f983-4a3c-b0dc-XXXXXXXXXXXXXXX', 'p': {'t': '16310427496480796', 'r': 12}, 'k': 'sub-c-1030e062-0ebe-11e5-a5c2-XXXXXXXXXXXX', 'c': 'c3650509-4214-45d3-b120-XXXXXXXXXXXX', 'd': {'status': 'securemode', 'callingUserID': 'fb0edfd1-1af6-4925-b760-XXXXXXXXXXXXX'}}]}
2021-09-07 21:25:49 DEBUG (MainThread) [yalexs.pubnub_async] Recieved new messages on channel c3650509-4214-45d3-b120-XXXXXXXXXXXX for device_id: A5XXXXXXXXXXXXXXXXXXXXXXX with timetoken: 16310427496480796: {'status': 'securemode', 'callingUserID': 'fb0edfd1-1af6-4925-b760-XXXXXXXXXXXXX'}
2021-09-07 21:25:49 DEBUG (MainThread) [pubnub] GET https://ps.pndsn.com/v2/subscribe/sub-c-1030e062-0ebe-11e5-a5c2-XXXXXXXXXXXX/c3650509-4214-45d3-b120-XXXXXXXXXXXX/0?tt=16310427496482006&tr=12&pnsdk=PubNub-Python-Asyncio%2F5.1.4&uuid=pn-FB0EDFD1-1AF6-4925-B760-XXXXXXXXXXX&l_pres=0.1216728687286377 None
2021-09-07 21:25:52 DEBUG (MainThread) [pubnub] {'t': {'t': '16310427526422576', 'r': 12}, 'm': [{'a': '5', 'f': 0, 'i': 'pn-11805b84-e8f3-4d8e-a046-b682aee0fe32', 'p': {'t': '16310427526432774', 'r': 12}, 'k': 'sub-c-1030e062-0ebe-11e5-a5c2-XXXXXXXXXXXX', 'c': 'c3650509-4214-45d3-b120-XXXXXXXXXXXX', 'd': {'status': 'securemode', 'callingUserID': 'fb0edfd1-1af6-4925-b760-XXXXXXXXXXXXX'}}]}
2021-09-07 21:25:52 DEBUG (MainThread) [yalexs.pubnub_async] Recieved new messages on channel c3650509-4214-45d3-b120-XXXXXXXXXXXX for device_id: A5XXXXXXXXXXXXXXXXXXXXXXX with timetoken: 16310427526432774: {'status': 'securemode', 'callingUserID': 'fb0edfd1-1af6-4925-b760-XXXXXXXXXXXXX'}
Please let me know if I should try to finde some other info.
Did also try the doorbell, but haven't found the relevant log lines yet. I will look for them now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
hmm can't seem to find anything relevant to the doorbell. This is what I can find in the last status update from the lock: The doorbell button was pushed between 19:26:17 and 19:26:25 |
|
BTW: |
|
Looks like the events are there but they are slightly different so we can’t parse them. Sadly, I won’t be able to make any adjustments to yalexs without the actual dumps (replacing the unique identifiers with dummy identifiers would work as long as the same identifier is used consistently) since there isn’t enough data in the posted snippets to understand where the data is in the structure.
…Sent from my iPhone
On Sep 7, 2021, at 6:09 PM, Morten Vinding Svendsen ***@***.***> wrote:
hmm can't seem to find anything relevant to the doorbell.
Maybe we need to request updates for that separately?
This is what I can find in the last status update from the lock:
$ head -n 1563 yale-lock2.log | tail -n 1 | grep -o "\[{.*\]" | jq "." | grep -i action
"action": "lock",
"DateLogActionID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX+Tue Sep 07 2021 19:35:40 GMT+0000 (Coordinated Universal Time)lock"
"action": "doorclosed",
"DateLogActionID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX+Tue Sep 07 2021 19:26:31 GMT+0000 (Coordinated Universal Time)doorclosed"
"action": "dooropen",
"DateLogActionID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX+Tue Sep 07 2021 19:26:25 GMT+0000 (Coordinated Universal Time)dooropen"
"action": "doorclosed",
"DateLogActionID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX+Tue Sep 07 2021 19:26:17 GMT+0000 (Coordinated Universal Time)doorclosed"
"action": "dooropen",
"DateLogActionID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX+Tue Sep 07 2021 19:26:12 GMT+0000 (Coordinated Universal Time)dooropen"
"action": "doorclosed",
"DateLogActionID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX+Tue Sep 07 2021 19:26:09 GMT+0000 (Coordinated Universal Time)doorclosed"
"action": "dooropen",
"DateLogActionID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX+Tue Sep 07 2021 19:26:07 GMT+0000 (Coordinated Universal Time)dooropen"
"action": "unlock",
"action": "unlock",
"DateLogActionID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX+Tue Sep 07 2021 19:26:06 GMT+0000 (Coordinated Universal Time)unlock"
"action": "lock",
"action": "lock",
"DateLogActionID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX+Tue Sep 07 2021 19:25:49 GMT+0000 (Coordinated Universal Time)lock"
"action": "doorclosed",
"DateLogActionID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX+Tue Sep 07 2021 19:25:43 GMT+0000 (Coordinated Universal Time)doorclosed"
The doorbell button was pushed between 19:26:17 and 19:26:25
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Home Assistant doesn’t have a secure locked state https://developers.home-assistant.io/docs/core/entity/lock
That would probably need to be represented as an attribute
…Sent from my iPhone
On Sep 7, 2021, at 6:13 PM, Morten Vinding Svendsen ***@***.***> wrote:
BTW:
My Home Assistant history log show the lock and unlock state correct, all though it doesn't distinguish between normal locked and secure locked.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Thanks @bdraco It a bit late here now, so I will try to get a "clean" log for secure locking and unlocking tomorrow. And use consistent obfuscating on the ID's tomorrow. I personally is not to interested in the secure lock, after all my HA is representing the lock state correctly, and I don't think I will use the secure mode much (you have to manually activate it each time). But I would be very interested if it was possible to get the doorbell notifications, so it could trigger my surveillance cameras. |
|
I expect the most useful logs will come from the yalexs library, but I’m guessing how they choose to implement it
…Sent from my iPhone
On Sep 8, 2021, at 1:00 AM, Morten Vinding Svendsen ***@***.***> wrote:
Thanks @bdraco
It a bit late here now, so I will try to get a "clean" log for secure locking and unlocking tomorrow. And use consistent obfuscating on the ID's tomorrow.
I personally is not to interested in the secure lock, after all my HA is representing the lock state correctly, and I don't think I will use the secure mode much (you have to manually activate it each time).
But I would be very interested if it was possible to get the doorbell notifications, so it could trigger my surveillance cameras.
Is there any specific logs you will need for that? (other than a "clean" log, with consistent obfuscated ID's).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
okay I will try to get a log. |
UniFi 5.60.9 firmware? If so grab 50.60.13 from the beta channel |
yes. Do you self use 5.60.13, and do you feel any difference? I will test the doorbell and get the logs as soon as I have the time (when the family isn't sleeping 😉) |
Yes, with .9, I can't keep the connects online. .13 is stable for me. I upgraded all of sites and haven't had an issue since. |
|
cool! hope it will be the same for me then 👍 |
|
didn't seem to help. here is the anonymized log from that. the time where I pushed the doorbell is in the middle separated with a couple of newlines. (2021-09-15 09:30:02) what I guess is status updates just before and after, is coming every 10 seconds. I hope it is useful. |
|
There doesn't seem to be anything related to the doorbell in the log. Does it show up in the activity log in the app? |
|
yes it's in the log in the app: I just tried again but could not see anything in the log. |
|
Good that its showing up in the app as that usually means it is in the activity feed. It may not be showing up though because of the wifi issue |
|
Yes I hope. Just had a look through the activities in home assistant log "Updating device activity for house id ....." Is the activity feed build according to request (so you specify types of activities to retrieve) or is it just general? If it's the last thing, I'm pretty sure the doorbell is not in it, and the app must receive it from somewhere else. |
|
by no signs of the doorbell in home assistant log I mean: but there is lots of info about open/close/lock |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
I was also tracking this as I have the same issue. Also on Gen4 of the lock. I noticed it because I have a mobile hass app alert when the door remains open for more than 5min. The alert now fires about a minute or two after the door is closed and locked about 6min after the elapsed time. Hass is not registering the closed/locked state which triggers the notification. This all changed a few months ago and it was working 100% for a very long time. In my case, the integration doesn't get the updated status as the OP mentioned.
|
|
There haven't been any significant changes to the underlying api module https://github.com/bdraco/yalexs/tags since March If something isn't working now its likely:
Either way, we probably can't fix this |
Thanks for the prompt reply. This is a gen4 lock, not sure if it works differently. WiFi is built-in therefore there's no issue with the connect module like gen3 locks. Strong signal in both of my locks and same issue. I'll re-install the integration again to be sure but I have a feeling it's an API issue. |
|
I have 52 august locks in service without the problem. However I have trashed all the August connects and replaced them with the new Yale connect modules. None of them are the gen4 or the doorman l3 so it might be something new in these models, and thus something new in the api |
|
It wouldn't surprise me if its something new in the gen4 since #57024 also shows they changed the battery reporting |
Has to be and it makes sense since I also have the battery issue. To be honest though, August has been harassing me for critically low battery for two weeks now lol HA is showing 55%, go figure. They do however send the same email even if your keypad is low on batter and your lock isn't! My keypad has been on 10% for two weeks and just today it flipped to "very low". I'll see how long I can ride this and adjust my HA notifications accordingly. Back to this though, yes, wrong status is definitely being reported. For gen3 I used z-wave vs. WiFi for integration, much faster and accurate. |
bdraco
changed the title
|
#64027 might help with this issue, but since I've never actually seen it happen, I'm not sure either way |
|
If anyone feels comfortable sharing their lock, I setup an account for testing/dev. It was helpful for fixing the Gen1/Gen2 locks: |
|
sorry if I pollute this thread but I think this might be the best place to ask: When someone unlocks my Yale Doorman L3 I (normally) immediately get an update in HA about the lock being unlocked, but only after 15 seconds (seems to be consistent) is the "operator" updated. the problem is, that I would like to use the unlock state to disarm my alarm system (also in HA), but ONLY if it wasn't manually unlocked (don't want an intruder to be able to disarm by simply unlocking the door ;) ) |
There isn't a faster way to do it since we have to poll for the operator when we get a locked event |
wow you are FAST! (faster than the August servers :) ) so the 15 seconds is the time it takes to poll the August servers? And there is now way this could be shortened? |
Nope. There are two different endpoints. The one that provides the operator is always a few seconds behind the pubsub one |
okay. thank you for your prompt replies. or getting the zigbee module I know exists but Yale refuses to sell me :( |
|
The offline key is in the lock detail payload. |
WHAT? so you are saying I can get it from the logs? or am I missing something? |
|
Turn on debug logging for |
wow it is indeed! obfuscated awesome! thank you! |
|
If someone wants to take me up on the offer to share their lock please send me an email and see #54722 (comment) Since we use GitHub for tracking issues, not for providing support or tracking feature requests, I'm going to close this now as support for the doorman l3 amounts to a feature request, and with no access to the lock, it isn't likely to come soon unless someone is willing to share. |
The problem
The August plugin reports the Doorman L3 as unlocked when you lock it in secure (or secured away) mode.
What is version of Home Assistant Core has the issue?
core-2021.8.6
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
August plugin
Link to integration documentation on our website
https://www.home-assistant.io/integrations/august/
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: