I built a custom integration to control Tedee smart locks directly over BLE no bridge needed.
I have a Tedee GO 2 and got frustrated with needing the bridge for any kind of automation. So I used the official documentation and SDKs of the BLE protocol (it’s basically TLS over Bluetooth, Tedee calls it PTLS) and built an integration that talks directly to the lock.
How it works: You need a free API key from the Tedee Portal (Device Certificates scope and Device reads to list devices). The integration uses it once to register and
grab a signed certificate, after that everything runs locally over Bluetooth. The cloud is only hit every few days to refresh the cert. Lock, unlock, open, all BLE, all local.
Entities:
Lock (lock/unlock/open, shows jammed state, last user & trigger source)
Door sensor (open/closed)
Battery (percentage + charging state)
State updates are pushed in real-time over BLE notifications, no polling. Connection stays alive with keep-alives and reconnects
automatically if it drops.
Also threw in a custom Lovelace card that auto-registers, shows lock state, door, battery, and last user in one row with contextual
buttons.
What you need:
Tedee GO 2 (other models might work, haven’t tested)
Sure, np, I will push later a version with more logging so we can debug this kinds of things. Also one thing I was wondering is that by keeping the BLE session non stop it could potentially drain the battery very very fast so I might make this configurable so it only connects when needed (like press lock/unlock) but you lose the synced state. Will watch closely over the following days if this truely happens.
It seems that they have added Matter support directly in the firmware, I will look into it if the matter integration provides everything and can replace this integration. The integration should still work (you need to readd the lock because the ble mac address changed) and can still be used by people without a thread border router.
Just checked the implementation with matter over thread. As i thought it is very hard to setup (cause of the whole mdns, ipv6 issues) and has lag because of the thread border router comms + it doesnt have info on partial unlocking/locking, door sensors and such so this integration is still relevant.
I am using the Tedee integration in Home Assistant with a Tedee GO lock and Tedee Keypad 2. I’ve noticed an entry in the logs that isn’t being correctly parsed.
When the lock is opened via the Keypad 2, the state/event shows up as:
Unlocking by 9 (unknown_0x17)
I would like to point out that other events, such as opening or closing the lock using the physical button on the device, are recognized and labeled correctly. This “unknown” status appears specifically and only when using the Keypad.
My questions are:
Could you please add support for mapping 0x17 to a human-readable status (e.g., “Unlocked by Keypad”) for the Tedee GO?
Is it possible to retrieve information within Home Assistant about which user or PIN was used to open the lock? This would be very helpful for security tracking and personalized automations.
Environment details:
Integration: Tedee
Device: Tedee GO 2 with Keypad 2
HA Version: [2026.3.0]
Thank you for your hard work on this integration!
Thanks for reporting this! I’ve pushed a fix that:
Maps 0x17 to “keypad” so you’ll see “keypad” instead of “unknown_0x17”
Resolves keypad PIN users to their name/alias using accessLinkId/pinAlias from the Tedee Cloud API activity logs
Please update to the latest version and try unlocking via the keypad again.
If the trigger name shows correctly but the user still shows as a number instead of a name, I’ll need your activity logs to see how the Tedee API reports keypad events. You can get them with these
two commands:
Feel free to redact any personal info — just replace with obvious placeholders like <REDACTED-USERNAME>, <REDACTED-PIN-ALIAS>, etc. The important parts are the field names and which ones are null vs populated.
