@kind3r have you opened up these lock to see what processor is inside?
If I understand well, these locks come in a Tuya and a TTLock version, with the Tuya one having wifi and BT and the TTLock only having BT.
If we could reprogram the Tuya version with new firmware, this would become a great piece of hardware. Since it looks like you got a Tuya version that you’re not using, would you mind opening it up and taking some pictures of the PCBs?
I’m also wondering if the TTLock version is just a firmware change, or if it actually uses a different processor.
I looked into the Tuya version (I have one) and it’s a separate Tuya serial wifi module. Unfortunately based on the Tuya documentation you can’t do much with it as the module is designed to be mostly powered down and there is no BLE. Also it is very well locked down to only connect to Tuya’s servers.
The only way I see to convert a Tuya into a TTLock would be to write new firmware for the lock MCU and add a separate BLE module. Too complicated given the fact that a TTLock is around $100.
In theory it would be possible if you sniff the initial pairing to get the AES key and admin credentials and then put them in the addon’s config. But the whole purpose of this addon is to use the lock offline and not rely on the TTLock cloud infrastructure. That’s what HA is mostly about.
Is the BLE module in the TTLock version also connected over serial?
Would there be potential to exchange the Tuya or BLE module with an ESP32? It’s a little bit more of a hardware hack, but could still be interesting to get an open lock on wifi.
I have an X6 TTLock version on the way, so I’ll report back.
I also noticed there is a zigbee version of these locks, which might be interesting for people with existing zigbee networks.
On TTLock there is a single board with all the components, no ideea what MCU it uses as it is on the other side of the board so you need to take it appart, which I did not yet.
In order to replace the board with an ESP32 (plus a custom PCB and some aditional components) drivers would be needed for the keypad and fingerprint sensor which I’m not sure they exist. Again, this would require too much development effort to make it worth since all the basic stuff mostly works as is for now.
The issues that still exist right now are related to the inconsistent BLE signal strength due to the lock being all metal an lacking a proper antena, the PI is also known for it’s weak wireless performance (I have to do the external antena mod on it at some point) and also Noble (the BLE library the addon uses) having lots of quirks I have to work around especially when working with this type of unstable connections. But after all, the lock was designed to be operated using a smartphone at close range or via WiFi by using a gateway. And for this purpose I did make a PoC gateway software that runs on ESP32 which actually performs better than the BLE on the PI both in range (with external antena) and stability. I will be working on addon support for multiple such gateways in the future as it seems to be a popular request with people having more than one lock spread throughout a larger area and one gateway is not enough.
Opening it up, all the electronics are on the outside part of the lock. The inside part just has the battery holder, the lock switch, reset button and the speaker. Outside part has 2 PCBS 1 for the touch panel and RFID and one for the main MCUs and interface drivers. All pcbs are covered in conformal coating and connectors have glue on them.
Main MCU seems to be an nRF51802 (U1), programming header seems to be accessible. There’s also a footprint for a ufl connector, so technically you could put that one on there and route a coax through the door and mount the BLE antenna on the inside of the door for better reception.
Other chips:
U9: RFID-> Kencent NZ3801
U1 (bottom pcb): Cap Touch sensor → TSM12
U6: ?? → HC32L110 → ARM-M0 not sure what this one is used for, doesn’t look like it’s for the
fingerprint sensor. Maybe it’s to play the audio files?
U10 is probably the amp for the speaker
U2 probably an H-bridge for the lock motor
U4 maybe memory for the audio clips
Doesn’t look like there’s anything super unknown on there, so making a custom firmware for the NRF51 would definitely be possible.
Converting this model to WiFi with an ESP32 would mean redesigning a whole new main PCB and is probably not worth it, it’s much easier to use @kind3r their gateway.
i want help with automationfor the door lock, i have remote RF i want use one button in remote to lock and unlock the TTLock BLE-based door lock with toggle command but i can’t find way to do it,any help ?
My TTLock is working. I wish there was a simple way to create the BLE gateway and the internal Bluetooth range for the door is too limited. Any updates coming soon ?
Then, some issues during build process - mostly like
Generating partitions .pio\build\esp-wrover\partitions.bin
In file included from src/security.cpp:1:0:
src/security.h:4:26: fatal error: hwcrypto/aes.h: No such file or directory
compilation terminated.
In file included from src/gw_settings.h:5:0,
from src/gw_settings.cpp:1:
src/security.h:4:26: fatal error: hwcrypto/aes.h: No such file or directory
compilation terminated.
Compiling .pio\build\esp-wrover\libf69\WiFi\ETH.cpp.o
Compiling .pio\build\esp-wrover\libf69\WiFi\WiFi.cpp.o
Compiling .pio\build\esp-wrover\libf69\WiFi\WiFiAP.cpp.o
Compiling .pio\build\esp-wrover\libf69\WiFi\WiFiClient.cpp.o
*** [.pio\build\esp-wrover\src\security.cpp.o] Error 1
*** [.pio\build\esp-wrover\src\gw_settings.cpp.o] Error 1
In file included from src/gw_settings.h:5:0,
from src/web.h:16,
from src/web.cpp:1:
src/security.h:4:26: fatal error: hwcrypto/aes.h: No such file or directory
compilation terminated.
*** [.pio\build\esp-wrover\src\web.cpp.o] Error 1
In file included from src/gw_settings.h:5:0,
from src/noble_api.h:12,
from src/noble_api.cpp:1:
src/security.h:4:26: fatal error: hwcrypto/aes.h: No such file or directory
compilation terminated.
*** [.pio\build\esp-wrover\src\noble_api.cpp.o] Error 1
In file included from src/gw_settings.h:5:0,
from src/main.cpp:7:
src/security.h:4:26: fatal error: hwcrypto/aes.h: No such file or directory
compilation terminated.
*** [.pio\build\esp-wrover\src\main.cpp.o] Error 1
Then when you follow the build and install instructions it’ll then download the correct build environment files. Then it’ll build install, and it works great. I’m using it now.
I did manage to install the addon seamlessly on my RPI3. Following your instructions, the pairing was successful right away. I actually tried it a couple of times with 4 different locks (same brand) and pairing always succeeded on first shot.
However, I couldn’t do anything from the Web UI beyond the pairing. Unlock, change settings, retrieving/setting credentials they all fail. I turned on the debug settings and below is the log. I will appreciate any guidance.
Thanks!
[10:40:31] ERROR: Got unexpected response from the API: Service not enabled
IGNORE CRC TRUE
Debug communication ON
[email protected] start
node ./index.js
Monitor started
Discovered paired lock: 8B:F5:A8:29:A3:D7
Server started
Monitor stopped
Peripheral connect start
Peripheral connect triggered
Peripheral state: connected
Device emiting connected
BLE Device reading basic info
BLE Device discover services start
BLE Device discover services end
BLE Device read characteristics start
BLE Device read characteristics end
BLE Device read characteristics start
BLE Device read characteristics end
BLE Device read basic info
BLE Device subscribed
Connected to known lock, reading general data
========= feature list
Sending command: 7f5a0503010001000101aa001c0d0a
Lock waiting for connection to be completed
Received response: 7f5a050302000a002254aa20a4f4f6bdaf84476905cf151c7d3a668880fb279904e46b3e602afc1c3cb7c85f9a0d0a
Command: 20754cd1f700000f440000000000000000
<Buffer 20 75 4c d1 f7 00 00 0f 44 00 00 00 00 00 00 00 00>
========= feature list Set(18) {
0,
1,
2,
4,
5,
6,
7,
8,
12,
14,
15,
18,
19,
22,
24,
28,
29,
30
}
========= check admin
Sending command: 7f5a0503010001000141aa106f78b19fc4a5ff0c9a084ac28f7d54e4700d0a
Received response: 7f5a050302000a002254aa1019b3c4287b28599cb580e2afd2b15426130d0a
Command: 00009cc0
========= check admin: 40128
========= check random
Sending command: 7f5a0503010001000130aa102fdeed08f211fd9486653efb7e3a07b3920d0a
Received response: 7f5a050302000a002254aa10dca39d10ac99a8904e0df1038db9762cd50d0a
Command: 20
========= check random
========= autoLockTime
Sending command: 7f5a0503010001000136aa10623b625846dbd13cbe994d6b5cd74459890d0a
Received response: 7f5a050302000a002254aa10c7948a939daa78d185a2b83278a552023d0d0a
Command: 2001000500010384
========= autoLockTime: 5
========= lockSound
Sending command: 7f5a0503010001000162aa10623b625846dbd13cbe994d6b5cd74459770d0a
Received response: 7f5a050302000a002254aa10a7dbb05a70eade41051fbecd1322831c150d0a
Command: 200101050102
========= lockSound: 1
Connected to paired lock 8B:F5:A8:29:A3:D7
Successful connect attempt to paired lock 8B:F5:A8:29:A3:D7
Disconnected from lock 8B:F5:A8:29:A3:D7
Connect allready in progress
Connect to lock failed 8B:F5:A8:29:A3:D7
Connect allready in progress
Connect to lock failed 8B:F5:A8:29:A3:D7
I had those same problems. Was thinking it was broken, but ended up building the wifi/BLE gate way linked above, and here just to be easy. It’s working fine now. Getting the thing to build was a bit tricky because the development libraries changed and it hadn’t been updated in a while, but there’s been a lot of activity in the project since then so that’s probably not the case anymore.
I also suspected some Bluetooth reliability issues. However, the fact that the pairing process seems to work consistently every time on first shot made me think that there was a reasonable connection. Also, every time I start the addon, the paired lock detection and fetching of its attributes seems to work fine. I was hoping there could be something in the log that could hint to the problem.
The bluetooth issues I had connecting to the Pi directly were it’d pair sometimes. IF I got it to pair it’d start erroring out putting in credentials. If I managed to put in a key fob, or a passcode it’d still soon disconnect and refuse to work. Never did figure out the issue, but decided to give the gateway a go and it’s been pretty solid.
I can’t say for sure about a WROOM. The project does have this comment:
At the moment, the project is only configured to work on ESP32-WROVER boards. If you have a different board, you need to edit the platformio.ini file and create your own env configuration. As of this writing the code takes about 1.5Mb so I’m using the min_spiffs.csv partition scheme in order to be able to hopefully do OTA in the future.
So possibly. All I know for sure is by that point I was pretty frustrated and just got a WROVER board, and it worked solid once it built and installed it on the WROVER board.
That said getting VScode to build it was it’s own little bit of fun. The build instructions are bit hackish to start, but still don’t work. I tracked the issues down to two problems in the platformio.ini file:
line 20: [email protected]:h2zero/NimBLE-Arduino.git#refactor-advertised-device
Somehow there’s a comment on the same line as library dependency
Change that to:
line 20: [email protected]:h2zero/NimBLE-Arduino.git
#refactor-advertised-device
or just delete the comment.
line 23: platform_packages =
line 24: platformio/framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git
Comment out these or delete them. Otherwise you’ll get lots of build failures. They cause VScode to get the wrong dependencies.
Here’s what I’ll use for wroom, it was able to build but I will try to upload it on one of my wroom. I was using a pi zero w before but I needed to reuse it for room-assistant.
EDIT: wroom only has 4mb flash size and the bin file is 1.4mb so cannot do OTA. I haven’t tried uploading this yet.
): in the platformio.ini there is the branch linked, which seems doesn’t exist: