Tedee

Hi,

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 :) 

BR

To be honest I give up. We have been told that in the summer we whould have it. Now it is end of the year. I'm still with a product which does not work. Good luck with waiting another years for this. 

<quote>What is the best alternative to Tedee which overcomes the cloud problem? Nuki?</quote>

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.
 

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. :) 

@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.