Home Assistant Lock Status

[jxbrown]

          The integration works great, thanks!

However, the state of the lock only updates when locking/unlocking through Home Assistant or the TTLock APP. The state of the lock does not update itself in HA when operating the lock manually or via the TTLock app.

Can I update how often the lock status updates Home Assistant?

Originally posted by @jxbrown in #1 (comment)

[noizo]

I have same problem.
I'm using DS2 door sensor, and when it's paired with lock, lock is closing automatically after i close a door.
HA unfortunately still indicates that lock is unlocked.
For that matter, it would be nice to have sensor battery level near lock battery level.

My setup described here #1 (comment)

[Kevin4999]

Same issue with mine:

I got my Hornbill lock from Amazon to show up in Home Assistant.
Lock: https://www.amazon.com/gp/product/B08Z7LRPPF/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&th=1

I can lock and unlock through Home Assistant. Sometimes on the first attempt, I get call service failed. It works on the second try. However, the state of the lock only updates when locking/unlocking through Home Assistant. The state of the lock does not update itself when operating the lock manually or on the TTLock app even after a month of testing thus far.

The other sensors are as follows:
Battery: Works fine
Last Operator: Not updating. Always saying "Unknown"
Last Trigger: Not Updating. Always saying "Unknown"
Passage Mode: Off (Did not attempt to change this)

[jbergler]

I'm not sure about the door sensor, I don't have one myself and some of the events get notifications via the ebhook, while others (like auto lock after a configured delay) don't get notifications and need a local implementation within the integration to emulate the status changes.

First question is the webhook setup and working for you? If you're not seeing the trigger/operator sensors updating its unlikely.

What I think I'd need is some pretty detailed logging - easiest way is probably to put this in your configuration.yaml and restart home assistant

logger:
  logs:
    homeassistant.components.webhook: debug
    custom_components.ttlock: debug

Just a warning though - I'm reasonably busy through til Christmas, so I don't know if I'll find the time to do much with the logs before then but I'll do my best.

[alloro72]

The same issue; I didn't receive the notification with the webhook URL to use as Callback on TTLOCK portal; how to view the URL?

[jbergler]

The same issue; I didn't receive the notification with the webhook URL to use as Callback on TTLOCK portal; how to view the URL?

The notification should return until the first time it gets hit, if you want to look it up after that check your home assistant logs, should look something like this

2023-10-16 07:57:19.252 INFO (MainThread) [custom_components.ttlock] Webhook registered at https://...

[cameronbowe]

I've noticed the lock status is always incorrect unless I use it only on HomeAssistant, but that's not gonna work when people unlock the door without it..

[thefunkygibbon]

I have the same issue. The lock is set to auto lock after 5 seconds, but it seems that the integration doesn't poll the lock for its status at all. If i use the app and check the status , i can see that it indeed unlocks ok via home assistant, and checking it again 5 seconds later it says it is locked again, but HA still says it is unlocked. so it seems that it is either not checking the status again or maybe the plugin doesn't support polling for status. ??

also last used and last operator are always "unknown"

edit: ok i didn't do the callback url thing. added that and the status seems to be ok , as does last operator etc.
maybe the others in this thread didnt do that too?

[pazoozoo123]

Hi,
I just installed my new TTLock based door lock and installed this integration using HACS, setup the web hook etc.
Everything works except the actual lock status which never gets updated to locked state unless the lock is operated using HA ( I guess since I have a door sensor and don't use the auto lock timer feature).
If I unlock the door HA updates the lock state to unlocked and allows locking but I have the door sensor and as soon as the door is closed the lock engages automatically however HA still thinks the lock is unlocked.

I turned on debug mode and looked at the logs and it seems TTLock web hook only reports a lock being unlocked but not locked, I am however getting an additional web hook record for my TTLock door sensor, first it would be nice to get a binary sensor based on this data telling HA when the door is open or closed, secondly you could infer from the door closed message that the lock has engaged as until this point my lock has always locked itself after the sensor reported closed.

I am attaching the logs of the door sensor web hook to aid in figuring out how it operates.
The first message is the unlock event received, then a door open message and finally a door closed but no door locked message from TTLock.

2023-12-01 12:35:32.408 DEBUG (MainThread) [custom_components.ttlock] Got webhook data: <MultiDictProxy('lockId': 'REDACTED', 'notifyType': '1', 'records': '[{"lockId":REDACTED,"electricQuantity":72,"serverDate":1701426932371,"recordTypeFromLock":20,"recordType":8,"success":1,"lockMac":"REDACTED","keyboardPwd":"REDACTED","lockDate":1701426883000,"username":"REDACTED"}]', 'admin': 'REDACTED', 'lockMac': 'REDACTED')>
2023-12-01 12:35:32.408 DEBUG (MainThread) [custom_components.ttlock.coordinator] Lock ttlock-REDACTED received id=REDACTED mac='REDACTED' battery_level=72 server_ts=datetime.datetime(2023, 12, 1, 12, 35, 32, 371000, tzinfo=zoneinfo.ZoneInfo(key='Asia/Jerusalem')) lock_ts=datetime.datetime(2023, 12, 1, 12, 34, 43, tzinfo=zoneinfo.ZoneInfo(key='Asia/Jerusalem')) event=Event(EventDescription(action=<Action.unlock: 3>, description='unlock by fingerprint')) user='REDACTED' success=True
2023-12-01 12:35:32.408 DEBUG (MainThread) [custom_components.ttlock.coordinator] Auto-lock is disabled
2023-12-01 12:35:32.408 DEBUG (MainThread) [custom_components.ttlock.coordinator] Manually updated ttlock data
2023-12-01 12:35:33.172 DEBUG (MainThread) [custom_components.ttlock] Got webhook data: <MultiDictProxy('lockId': 'REDACTED', 'notifyType': '1', 'records': '[{"lockId":REDACTED,"electricQuantity":72,"serverDate":1701426932992,"recordTypeFromLock":31,"recordType":31,"success":1,"lockMac":"REDACTED","keyboardPwd":"","lockDate":1701426924000}]', 'admin': 'REDACTED', 'lockMac': 'REDACTED')>
2023-12-01 12:35:33.172 DEBUG (MainThread) [custom_components.ttlock.coordinator] Lock ttlock-REDACTED received id=REDACTED mac='REDACTED' battery_level=72 server_ts=datetime.datetime(2023, 12, 1, 12, 35, 32, 992000, tzinfo=zoneinfo.ZoneInfo(key='Asia/Jerusalem')) lock_ts=datetime.datetime(2023, 12, 1, 12, 35, 24, tzinfo=zoneinfo.ZoneInfo(key='Asia/Jerusalem')) event=Event(EventDescription(action=<Action.unknown: 1>, description='Door sensor open')) user=None success=True
2023-12-01 12:35:33.172 DEBUG (MainThread) [custom_components.ttlock.coordinator] Manually updated ttlock data
2023-12-01 12:35:34.320 DEBUG (MainThread) [custom_components.ttlock] Got webhook data: <MultiDictProxy('lockId': 'REDACTED', 'notifyType': '1', 'records': '[{"lockId":REDACTED,"electricQuantity":72,"serverDate":1701426934225,"recordTypeFromLock":30,"recordType":30,"success":1,"lockMac":"REDACTED","keyboardPwd":"","lockDate":1701426925000}]', 'admin': 'REDACTED', 'lockMac': 'REDACTED')>
2023-12-01 12:35:34.320 DEBUG (MainThread) [custom_components.ttlock.coordinator] Lock ttlock-REDACTED received id=REDACTED mac='REDACTED' battery_level=72 server_ts=datetime.datetime(2023, 12, 1, 12, 35, 34, 225000, tzinfo=zoneinfo.ZoneInfo(key='Asia/Jerusalem')) lock_ts=datetime.datetime(2023, 12, 1, 12, 35, 25, tzinfo=zoneinfo.ZoneInfo(key='Asia/Jerusalem')) event=Event(EventDescription(action=<Action.unknown: 1>, description='Door sensor closed')) user=None success=True
2023-12-01 12:35:34.320 DEBUG (MainThread) [custom_components.ttlock.coordinator] Manually updated ttlock data

Edit:
Went to the models.py file and edited line 134 from:
30: EventDescription(Action.unknown, "Door sensor closed"),
to
30: EventDescription(Action.lock, "Door sensor closed"),

This gives me the basic behavior I want of HA detecting when the door is locked again but obviously a proper door sensor implementation will be greatly appreciated.

[cloudbr34k84]

Im reporting the same issue as well with Lock. Any updates on this??

[rodrigofragadf]

I'm also having the same problem. Is there any solution?

[jbergler]

@pazoozoo123 thanks for providing logs that's starting to help paint a picture of what's going on here.

This log message suggests that the integration doesn't think the lock has auto lock configured.

2023-12-01 12:35:32.408 DEBUG (MainThread) [custom_components.ttlock.coordinator] Auto-lock is disabled

I need to get the reported configuration of the lock to dig into this further. Are you able to share a new set of logs, this time including the initial fetch of the lock details when the integration reloads?

[pazoozoo123]

I turned on debug mode in the integration and reloaded it, here is what the logs contained:

2024-02-19 19:07:14.139 DEBUG (MainThread) [custom_components.ttlock.api] [98b3] Sending request to https://euapi.ttlock.com/v3/lock/list with args={'pageNo': 1, 'pageSize': 1000}
2024-02-19 19:07:14.603 DEBUG (MainThread) [custom_components.ttlock.api] [98b3] Received response: status=200: body={'list': [{'date': 1701112850000, 'specialValue': REDACTED, 'lockAlias': 'Home', 'noKeyPwd': REDACTED, 'electricQuantityUpdateDate': 1708334667000, 'lockMac': REDACTED, 'passageMode': 2, 'timezoneRawOffset': 7200000, 'lockId': REDACTED, 'featureValue': REDACTED, 'electricQuantity': 95, 'bindDate': 1701112850000, 'lockData': REDACTED, 'hasGateway': 1, 'keyboardPwdVersion': 4, 'wirelessKeypadFeatureValue': '0', 'lockVersion': {'showAdminKbpwdFlag': True, 'groupId': 10, 'protocolVersion': 3, 'protocolType': 5, 'orgId': 34, 'logoUrl': '', 'scene': 2}, 'lockName': 'LL70_a80f07'}], 'pageNo': 1, 'pageSize': 1000, 'pages': 1, 'total': 1}
2024-02-19 19:07:14.603 DEBUG (MainThread) [custom_components.ttlock.api] [edb5] Sending request to https://euapi.ttlock.com/v3/lock/detail with args={'lockId': REDACTED}
2024-02-19 19:07:14.681 DEBUG (MainThread) [custom_components.ttlock.api] [edb5] Received response: status=200: body={'date': 1701112850000, 'lockAlias': 'Home', 'lockSound': 1, 'modelNum': 'SN9246-M-469_PV53', 'lockMac': REDACTED, 'privacyLock': 2, 'deletePwd': '', 'featureValue': REDACTED, 'adminPwd': REDACTED, 'soundVolume': 1, 'hasGateway': 1, 'autoLockTime': -1, 'wirelessKeypadFeatureValue': '0', 'lockKey': REDACTED, 'isFrozen': 2, 'lockName': 'LL70_a80f07', 'resetButton': 1, 'firmwareRevision': '6.5.07.220531', 'tamperAlert': 1, 'specialValue': REDACTED, 'displayPasscode': 0, 'noKeyPwd': REDACTED, 'passageMode': 2, 'passageModeAutoUnlock': 2, 'timezoneRawOffset': 7200000, 'lockId': REDACTED, 'electricQuantity': 95, 'lockFlagPos': 0, 'lockUpdateDate': 1708334656000, 'keyboardPwdVersion': 4, 'aesKeyStr': REDACTED, 'hardwareRevision': '1.3', 'openDirection': 1, 'lockVersion': {'groupId': 10, 'protocolVersion': 3, 'protocolType': 5, 'orgId': 34, 'scene': 2}, 'sensitivity': -1}
2024-02-19 19:07:14.681 DEBUG (MainThread) [custom_components.ttlock.api] [4c4b] Sending request to https://euapi.ttlock.com/v3/lock/queryOpenState with args={'lockId': REDACTED}
2024-02-19 19:07:17.132 DEBUG (MainThread) [custom_components.ttlock.api] [4c4b] Received response: status=200: body={'state': 0, 'sensorState': 1}
2024-02-19 19:07:17.132 DEBUG (MainThread) [custom_components.ttlock.api] [2e1d] Sending request to https://euapi.ttlock.com/v3/lock/getPassageModeConfig with args={'lockId': REDACTED}
2024-02-19 19:07:17.211 DEBUG (MainThread) [custom_components.ttlock.api] [2e1d] Received response: status=200: body={'autoUnlock': 2, 'weekDays': [], 'passageMode': 2}
2024-02-19 19:07:17.212 DEBUG (MainThread) [custom_components.ttlock.coordinator] Finished fetching ttlock data in 2.608 seconds (success: True)
2024-02-19 19:07:17.212 INFO (MainThread) [custom_components.ttlock] Webhook registered at http://192.168.10.10:8123/api/webhook/REDACTED

Indeed I don't have auto lock enabled, it is currently set to disabled, the lock still auto locks it self because of the attached door sensor when it detects the door is closed.
If I enable auto lock after set time it simply locks the door after the time has elapsed or the door sensor reports the door as closed, obviously auto lock is problematic if the door is kept open and the time elapses as now you have a door that will not close until you instruct it to open again and then physically move it to the closed position.

[jbergler]

Yeah that makes sense. What is the ‘featureValue’ for these locks?

It’s easy enough to plumb the door sensor closed message up so that it marks the door as locked but I don’t know if it’s safe to assume that closing the door also results in it being locked? Is that configurable?

[pazoozoo123]

The feature value is:

'featureValue': 'C2F5435CCF5F7'

After adding the DS2 ttlock door sensor to the lock using the app the only options available are:
Name, Battery, Update, Door-not-locked alert
These are self explanatory, there is no way as far as I can tell to disable the lock upon door closed detected feature of the lock paired with the sensor, maybe by running it in passage mode but I never tried that.

[lsellens]

Same issue with my setup. I did use the callback url but when unlocking by fingerprint when the lock relocks HA does not get a updated status. I noticed in the logs on lock2.ttlock.com it only logs unlocks unless you manually lock the lock. Maybe this is why?

[philippeantonietti]

I got the same problem here =[

[ashtonaut]

Same issue here. Webhook URL setup appeared to work fine and no errors in log. Lock will unlock from HA web interface as expected. However, it's set to auto lock after 5 seconds, and when this happens the HA status still shows 'unlocked'. Re-loading the TT Lock integration fixes the issue and the status is correctly reset to 'locked'.

Also, when logging in at lock2.ttlock.com I can see all unlocking history, but agree with earlier poster that auto-lock events aren't shown. However, the lock status reported in that web UI does update and always shows the correct status, so I assume it should be possible to be pulling the correct status. No idea of an auto lock event triggers the webhook, perhaps that's the issue, given reloading the integration (which I assume pulls a fresh status) does capture the correct lock status.

Edit: Further to my above comments, the status did update back to 'locked'! It just took 5 minutes after the door auto-locked. Is the webhook setup supposed to update the status faster than that?

[square-spade]

Yeah that makes sense. What is the ‘featureValue’ for these locks?

It’s easy enough to plumb the door sensor closed message up so that it marks the door as locked but I don’t know if it’s safe to assume that closing the door also results in it being locked? Is that configurable?

If the lock has a door sensor then it is safe to assume it's locked when closed. This setting is not configurable.
I would love for the door sensor to be part of the integration, seems an easy add with the https://euapi.ttlock.com/v3/doorSensor/query call. Would be nice to have a door sensor opened notification also.

[jbergler]

From a design perspective, I'd prefer not to rely on the query endpoints as these make calls to the lock, which ends up destroying battery life if we poll it.

I think in terms of implementing this the process is something like:

• Figure out how we identify locks that have a sensor attached, the docs suggest that bit 13 of featureValue has this info. This needs to be added to the Feature class.
• Add the logic to the api abstraction for fetching the sensor state (using the url above)
• Add the relevant fields to the LockState class and wire up the init and webhook paths to update the fields when data comes in.
• Add a binary sensor that exposes the door sensor if the lock supports it.

[square-spade]

As far as featureValue 13 I'm pretty sure that is just an indication of whether the lock has door sensor capabilities (which 3 out of the 4 I have have) not if the lock HAS a door sensor, so I'm not sure if there's any point using that info, but totally your call.
During init couldn't we just add an initial query call for the sensor as most if not all of the LockState fields for the sensor will be updated during the Lock Record Notify callback (as well as the manual API https://euapi.ttlock.com/v3/lock/queryOpenState which will return the state of the sensor if present)

[jbergler]

Could you share the feature value from a lock that has the capability but no sensor attached and another one with a sensor attached? That'd be useful in understanding the behavior.

I agree we can make the call on startup, but since the APIs are rate limited we want to avoid hitting it if we can avoid it.
There are some users with 50+ locks and for them an extra call makes a huge difference.

[isaackehle]

@jbergler After setting up a notebook to query the API, bit 13 for me is a 1. Tomorrow I'll disconnect the sensor from the lock and see if it changes to a 0. That'd be a good test of validity for that bit.

[isaackehle]

FWIW, querying the queryOpenState endpoint returns the following for my lock with the connected sensor:

{'state': 0, 'sensorState': 1}

That's door locked and closed. When open, I get:

{'state': 0, 'sensorState': 0}

and apparently, when I am too far away from the door lock, testing the sensor in another room, I get this:

{'state': 0}

I imagine that if there isn't a valid sensor reading, the sensor state will be undefined/None.

[isaackehle]

From a design perspective, I'd prefer not to rely on the query endpoints as these make calls to the lock, which ends up destroying battery life if we poll it.

Does the API/webhook give a status update when status has changed?

I think in terms of implementing this the process is something like:

• Figure out how we identify locks that have a sensor attached, the docs suggest that bit 13 of featureValue has this info. This needs to be added to the Feature class.

This is probably necessary to expose the binary_sensor. I guess it could be in an Unavailable state if the API returns no value for sensorState?

• Add the logic to the api abstraction for fetching the sensor state (using the url above)

Agreed

• Add the relevant fields to the LockState class and wire up the init and webhook paths to update the fields when data comes in.

I'd suggest a new SensorState class separate from LockState.

class SensorState(Enum):
    open = 0
    closed = 1
    unknown = None

• Add a binary sensor that exposes the door sensor if the lock supports it.

Agreed