HASS Addon TTLock offline integration

accelle · January 13, 2021, 6:50am

It’s ok, the lock is on a room so I get to reset and test it a lot.
I am wondering if it needs to be wakeup first before the system can lock/unlock it. The device sleeps as soon 2-3s after the last activity lol.

kind3r · January 13, 2021, 6:55am

My experience with the full lock is that:

if the lock is not paired (initialized) it will only activate the BLE while the keyboard is lit (about 10-15s or so)
if the lock has been paired, BLE will always be on so it’s discoverable and connectable, but it won’t keep idle connections for more than a few seconds (unless you add an IC Card in which case it will not timeout, but when adding fingerprints it will after 8s)

accelle · January 13, 2021, 1:15pm

BTW, how do you point the addon to a different mosquitto server and which topics?
My main hassio is running on NUC while this addon is on pi4. I believe there’s a gateway option but it might not be applicable if the pi4 is on hassos, so instead, I’m just planning this one to run on pi4 and send the messages to mqtt on my main hassio.

kind3r · January 13, 2021, 1:40pm

At the moment there are no config options for MQTT and it relies on HA’s service discovery for it. But I could add those options if needed. It could be an option for people running a separate MQTT broker from their HA instance. But this way you also separate some of the functionality. The HA instance running the addon would only offer the web UI and the HA instance running the MQTT would only be able to lock/unlock.

The gateway ‘server’ acts as a remote bluetooth adapter. It receives commands to start/stop scanning, will send back discovered devices, offer the possibility to remotely connect to those devices and read/write characteristics etc. It is not TTLock specific.

The server could be ran in theory on any OS that noble supports (you can find more info about it in my sdk repo https://github.com/kind3r/ttlock-sdk-js), no need for a HA instalation. In time, if there is interest, I could make it a separate project from the sdk and maybe even as a HA addon (tho installing HA just to use it as a gateway is kindof overkill IMHO). What I am focusing at the moment is implementing this gateway functionality on ESP32. I think this is what most people will be after.

So, from my point of view you’re better off instaling some linux distro on the PI and running the gateway server from ttlock-sdk-js repo. You can then also run other stuff on your PI and not be limited by what HA can or can’t do.

accelle · January 13, 2021, 1:50pm

Im using the pi 4 for testing/secondary adguard/switchbot-curtain controller. It was running supervised before but I switched to hassos recently because of the bluetooth issue during the testing. I’ll check if I can just migrate it back again or use the pi zero that’s running on raspbian.

accelle · January 14, 2021, 5:17am

I have managed to setup the server.js on my pi zero and transfer the addon to my main hassio vm on nuc via backup without re-pairing the lock.
For the server.js, I could change aesKey and credentials line on the code right? I’m going to try to use systemd so it can be started automatically.

kind3r · January 14, 2021, 6:27am

You can also use env vars for that:

WEBSOCKET_KEY=xxxxx WEBSOCKET_CREDENTIALS=user:pass npm run server-tool

As for running note stuff at startup there is PM2 https://pm2.keymetrics.io/

To backup a paired lock, in addon’s data folder (assigned by HA) there is a lockData.json file which you can copy. I plan to have an import/export for that in the UI. But for now HA’s backup should do fine.

accelle · January 14, 2021, 6:40am

Thanks for this. I changed ‘start’ to ‘run’ since it’s not working on my setup.

Still checking PM2.

kind3r · January 14, 2021, 6:42am

Ah yes, sorry, just woke up I fixed my post for posterity.

accelle · January 15, 2021, 12:09am

The lock and sensor entities goes to unknown/grayed out after hass restart. The lock only became active after I went to settings and it published homeassistant/lock/f6c5fbabd9f9/lock/config.

kind3r · January 15, 2021, 5:29pm

I made quite a lot of fixes and improvements to the connection mechanic (especially when signal is bad) and also now it detects the features available and filters the credentials (PIN, card, fingerprint) in the ui as well as in the communication with the lock.

Can you give the new version a try and see if it works for you ?

It should also fix startup issues like the sensors not being available as it now uses discovery data even if the lock won’t connect at startup.

accelle · January 16, 2021, 5:37am

The ttlock UI seems faster and reliable now. However, the sensors and lock are still unavailable after HA restart even after hitting settings and refresh on TTlock UI.
It only goes back after addon restart.
No remarkable or mqtt publish on the logs between the HA restart and addon restart.

kind3r · January 16, 2021, 7:26am

I see now what’s going on.

At a first glance, I thought that MQTT was being started after the addon, but that is not the case as the addon is supposed to be started last (as specified in it’s config).

The problem is that on HA restart, actually only HA core container is restarted, not the addons. I’ll look into how to detect that and re-publish the information (or make it persist restarts, I remember seing this somewhere).

kind3r · January 16, 2021, 9:01am

Ok, new version is up and now the state should persist across HA restarts, host reboots, MQTT restart etc.

accelle · January 16, 2021, 12:18pm

Thanks, it worked!

kind3r · January 17, 2021, 8:44pm

In case you’re interested I also added the auto-lock setting and editing for the lock pairing data (which you can copy and paste to another HA).

Is there any interest in cyclic credentials ? As in a specific credential (PIN, card, fingerprint) is only valid from monday to friday from 7AM to 8PM for example.

I was thinking of implementing passage mode next, but since you can set auto-lock to 0 it’s kindof the same thing, only cyclic.

Any other features (except for notifications about lock/unlock events pushed by the lock) that come to mind ?

accelle · January 18, 2021, 12:52am

yeah, saw it yesterday, it’s really great and I updated without issues. The cyclic credential sounds practical.
It might be handy too to set autolock via mqtt too.

I’m still troubleshooting why unlock/lock commands doesn’t work all the time (saying command already in progress or Invalid data length or decryption failed). I’m still troubleshooting and will open github issue once finished isolating and collected logs.
I have also separated the system that uses bluetooth for switchbot curtain, it looks like both are conflicting.

franke · January 23, 2021, 2:01pm

Hi Great work
I have manage to find my ttlock but it wont pair… maybe you can help me…
my log:

Error: NobleDevice is busy
at NobleDevice.checkBusy (/app/node_modules/ttlock-sdk-js/dist/scanner/noble/NobleDevice.js:46:19)
at NobleService.discoverCharacteristics (/app/node_modules/ttlock-sdk-js/dist/scanner/noble/NobleService.js:31:25)
at NobleService.readCharacteristics (/app/node_modules/ttlock-sdk-js/dist/scanner/noble/NobleService.js:49:24)
at TTBluetoothDevice.readBasicInfo (/app/node_modules/ttlock-sdk-js/dist/device/TTBluetoothDevice.js:80:35)
at async TTBluetoothDevice.connect (/app/node_modules/ttlock-sdk-js/dist/device/TTBluetoothDevice.js:45:17)
at async TTLock.connect (/app/node_modules/ttlock-sdk-js/dist/device/TTLock.js:52:27)
at async Manager._connectLock (/app/src/manager.js:504:21)
at async Manager.initLock (/app/src/manager.js:166:13)
at async WebSocket. (/app/api/index.js:51:30)
Connected to new lock F0:E7:7:8B:5B:6D
Connected to new lock F0:E7:7:8B:5B:6D
========= init
Error while initialising lock Error: Unprocessed responses
at TTBluetoothDevice.sendCommand (/app/node_modules/ttlock-sdk-js/dist/device/TTBluetoothDevice.js:129:19)
at TTLock.initCommand (/app/node_modules/ttlock-sdk-js/dist/device/TTLockApi.js:66:52)
at TTLock.initLock (/app/node_modules/ttlock-sdk-js/dist/device/TTLock.js:127:24)
at Manager.initLock (/app/src/manager.js:170:30)
at runNextTicks (internal/process/task_queues.js:62:5)
at listOnTimeout (internal/timers.js:523:9)
at processTimers (internal/timers.js:497:7)
at async WebSocket. (/app/api/index.js:51:30)
Error while initialising lock Error: Unprocessed responses
at TTBluetoothDevice.sendCommand (/app/node_modules/ttlock-sdk-js/dist/device/TTBluetoothDevice.js:129:19)
at TTLock.initCommand (/app/node_modules/ttlock-sdk-js/dist/device/TTLockApi.js:66:52)
at TTLock.initLock (/app/node_modules/ttlock-sdk-js/dist/device/TTLock.js:127:24)
at Manager.initLock (/app/src/manager.js:170:30)
at async WebSocket. (/app/api/index.js:51:30)
========= init
Disconnected from lock F0:E7:7:8B:5B:6D

kind3r · January 23, 2021, 2:36pm

To figure out what happend I would need more if the log. But you can try the following:

Restart addon
Go to UI and wait 30s for the initial scan to finish
Start scan again (resfesh icon top right) and then wake up the lock
Click pair as soon as the lock appears.

If pairing fails, repeat from step 1 (I have noticed errors during the process which I’m trying to figure out).

Also make sure the lock is in range of your HA (recommended under 2m)

franke · January 31, 2021, 5:09pm

Thanks it works now