as I'm asking once in a year for the local REST API, I'll do it here aswell in the hope, that it become a better priority :)
I want that the very nice REST API is available just locally in my LAN
Why I want this:
- Security reasons: I want to be responsible on my own and this is only possible with a local REST API
- Availability: Sometimes, the currently available REST API in your cloud is pretty slow. I'm waiting 10 seconds for a response which is a no go. Also: when tedee shut down their services, I can trash my bridge and I'm not able to use this smart lock anymore (because I _never_ use the phone app, I just use my openhab integration and the App HTTP Shortcut which sends a request to an own build REST API which not just opens the main door, it also opens the entry door where no tedee is possible (build in electrical lock)
Please keep in mind, that the only reason why I chose Tedee over a competitor is, that before I bought it over a year ago, I got a response on my request from you, that "soon" a local API is available at the bridge.
I was thinking about to create an "offical" openhab binding for Tedee but if this feature is not upcoming in the next 12 months, I'll sell it and buy something from competitors which has the local API available.
Please take this also as constructive critics :)
Artur Pragacz - any working example? I do not use home assistant - I'm using openhab but I want to implement it purely using internal ESP32 features. The API page on tedee is not informative enough to get working example so I would have to research how to prepare and get it to work - which I can but lack of the good tutorial is missing for now. (I can code of course)
Okay. Let us assume that we can use the BLE API. That would be a workable solution for many (I use OpenHab as well).
But that still leaves three issues:
- Certificate handling via own CA
- working with the lock without creation of an account
- using the keypad without using the cloud (a third party tag reader/keypad would be an alternative).
Would that be an agreeable minimum feature set?
From what I can read even with the bluetooth proxy ppl are struggling with delays - is there any person on this planet who successfully implemented tedee with BLE access using ESP32 or any other way?
Ok, I tried to post this comment twice already, but the forum doesn't let it through. This is my third and final attempt, hopefully it works this time.
Sorry, I don't use OpenHAB, so cannot help you there. I do have to say though that implementing it directly in the ESP seems like not the best idea, it would be much better to just proxy the Bluetooth traffic to some proper server than to try to implement it all inside a small microcontroller. Much more maintainable and future proof that way.
I agree with you when it comes to certificates and said as much in my first post. This is a real issue that Tedee should aim to alleviate. I have to add as well that I found your comments in this thread the most reasonable and if others were as level-headed as you in their comments, it would be much more productive.
When it comes to other stuff I personally more than support for the keypad would like for Tedee to implement in their BLE API support for setting all the configuration parameters of the lock, so it's not necessary to use the app every time in order to change those.
I have it working right now. My setup:
Home Assistant server
ESP32 Bluetooth Proxy
Homekit over BLE (using the Homekit Device integration)
It works quite well. Delay seems very reasonable (<2sec.). The only problem I have is that sometimes the lock state gets stuck if the lock is opened manually or with the button, so I have an automation that detects it and refreshes the state when it happens. It's a minor issue though.
I can't believe this discussion now. People all over the world just go (seemingly) pragmatic ways and workarounding all the stuff instead of creating well described issues or threads like this with something similar like a user story into it. Ppl are lazy in some kind of areas and really struggle to solve the actual problem just because it means not to go into contact with a company who might be requesting some more information on feedback or whatever the reason is that somebody write some hours code for BLE API instead of creating a user story first.
1. there is a bridge out which is/should be already my proxy REST2BLE Adapter
2. my server isn't close enough to the lock for BLE API without a proxy
3. no way to workaround after multiple years and reinvent something which is partly there already
There is a reason why competitor is well known on the market and tedee is not. There is a reason why competitor is everywhere adapters in homeautomation solutions like home assistant, openhab and so on and tedee not. There are easy to use APIs, widely open for developers and a great community support. The lock itself of the competitor isn't better and is not the reason why they grow with a much higher curve than tedee. It's the whole eco system where even external parties provide stuff like fingerprint which is the most comfortable way (next to ring2open or fully auomatically open with somehow a presence detection) to open doors.
I follow this topic since quite a while and agree that having a local API is very important. If you check this thread here:
You can see that Point 4 of the upcoming features in the priority list was recently finished. Next up is "local API on the Bridge" so it is the currently on top of the list. I assume there will be something soon.
It is quite straightforward. I don't know what you already have, so let me describe all the steps from scratch.
1. Install Home Assistant. There is many ways to do it, consult documentation for details.
2. Install Bluetooth Proxy on ESP32 and connect it to Home Assistant. There is a website that automates this whole process.
3. Reset the Tedee lock and add it via Homekit Device integration to Home Assistant. Then calibrate the lock using the Tedee app.
That's it really. If you have additional questions or problems, I suggest you visit the Home Assistant forum, as it is the proper place for those issues.
@Artur Pragacz, that's the most informative post yet. :)
Bike manufacturer VanMoof is a good current example of what can happen if you trust the cloud.
Customers have issues unlocking their bicxcles after the company went bankrupt.