What is the best alternative to Tedee which overcomes the cloud problem? Nuki? Hm. Nuki offers a number of APIs, the Bridge API appears to be local and they are working on MQTT. Plus they have a huge ecosystem of additional products. But unless you are deaf, the Nuki is loud. And not as pretty as the Tedee. (The people building Nuki have a patent on their mechanism, which makes me believe that they won’t have a much quieter version soon.) Except for the local API, I believe the Tedee is the better product in every regard.
Actually I am pretty sure that a local api is high on the priority list as the new Tedee go has been launched and Matter support is being promised. Matter works locally so there must be relation there.
Good thinking. So let’s hope!
@Carsten, just remember: “must be” as well as “high on the priority list” does not mean anything with Tedee 
@Kaktus317: They just released a new, important product. Give them time to fix any urgent issues with that one. 
@Jens Stark, they should not have released any new product, since they did not deliver stuff promised on existing products to customers who already paid for it.
And yes, tedee/konrad may see that differently. But it does not matter much, because the customers perspective is the one which counts.
@Kaktus317: Getting a bit off topic here. I worked for a Fortune 500 company. It doesn’t work like that even there. Internally, you get a lot of product releae info - and the products these replace had annoying issues. But you would still hear “Next year’s model” and if you were lucky, you would actually get a solution. Remember that the older product is still being sold and maintained - so I would not give up hope. (If both products share a code base, which we don’t know, then fixes to one product may be retrofit to the other if there is space.) But releasing the GO was an important thing - it solves a number of mechanical issues, is more compact and if you don’t show progress on your products (unless you are selling screwdrivers or nails), you fall back behind the competition. If I was in their place, I would do exactly the same. Especiially with limited ressources (which you even have in a multinational company with 50000 employees.) What was the statement TEDEE gave out that guaranteed a local REST API?
I see the main problem in ECDSA key handling via the cloud. In my case, I’d be perfectly happy to be able to take care of key handling myself, then using the existing BLE API to talk to the lock. Problem solved.
@Jens Stark, I am sorry, but we are not talking about the same thing. There does not need to be a new product, so that the original one is getting fixed. And I am not talking about “getting maintained” either. I am talking about implementing really small stuff, what customers, who bought the product from the beginning, asked for years now. I am talking about a few lines of code, which would help some paying customers a lot. I am talking about software stuff, which the competition already offered when Tedee released their product. I am talking about stuff customers asked for and Tedee declined “because nobody needs this” and almost every competitors offers now. I am talking about stuff Tedee (or their direct distributors) advertised and have not delivered. And no, I am not giving up hope. I am totally pi**ed that a company does not implement features within years, but brings out a new product, which for most of the people the only benefit is that you don’t have to cut your key off anymore. Has a lot of disadvantages too: bigger, just plastic, horrible batteries, … But yeah, of course, this was a very important step. Forget about bringing your existing product from 80% to 100%…
@Kaktus317: You want to misunderstand me? There is an existing product line which seems to sell. Adding another product is the sole decision of the company building that stuff. You can cheer, you can ignore it, you can yell at it. That won’t change anything. Both of the products are alive and well - what they need is a REST API, either in the lock itself or in the bridge, which does not use the cloud. But - and this is a legal question - have they ever advertised the local REST API in public? And out of interest: NUKI offers very loud locks with a local API, but which other manufacturer does (and has public documentation, so DANALOCK is out.)
When the Thread/Matter firmware is released, can this be used without the Tedee bridge, so you can lock/unlock the door with a Thread Bridge (Thread Border Router)?
Some people in this thread need to calm down a bit. First of all, as far as I know, Tedee never officially promised this, so constantly crying about it is not really productive. Secondly Tedee already exposes a local API, it has for a long time now. It’s just not a HTTP API, but a BLE API. All that is left for all the whiners to do, is to integrate this API into their home automation platforms of choice. The only downside, as far as I can see, is that it requires short lived certificates, that need to be periodically renewed using cloud connection to Tedee servers. This is an issue, that we should push Tedee to solve. But even that is not a complete deal-breaker, since there are alternative ways to have limited local access without any cloud connection at all. For Tedee PRO there is available Homekit protocol, which is fully local. For Tedee GO there will be Matter, also fully local protocol. So please, everyone, stop whining already.
Good luck with implementing BLE using IOT - there are no examples much so you need to have experience doing with BLE. Give me a good example using ESP32 with bluetooth and I’m happy. Secondly - tedee servers responsivnes are jokingly 10 seconds during peak times. We need simple nice local API. Simple as that.
Martin, like with any such protocol there are libraries that make working with BLE quite doable, even for someone without prior experience. For ESP32 specifically you can for example flash it with ESPHome working as Bluetooth proxy and use it with Home Assistant without writing any code yourself.
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 and - 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. @Martin Vit 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. @Jens Stark 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. @Martin Vit 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.
Hi Guys, I follow this topic since quite a while and agree that having a local API is very important. If you check this thread here: 2022 summary and 2023 plans : Tedee 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. Stephan