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 :)
I understand your need, the local REST API would be useful.
1. It is not easy to prepare a secure local API on the IoT device. Other lock vendors are doing this without any or minimal layer of security and we do not want to do the same.
2. Availability. We continuously improve the performance of the backend system according to the load. The latest version released on the previous Monday should significantly improve the response time.
We do not plan to add the local REST API in near future. I am really sorry if you were misled into buying.
Before you decide to change the lock please first check:
2. How does the competitor implement the local REST API and is it enough secure for your purpose
Thank you for your feedback, we appreciate it.
thanks for your response. I appreciate your honest. Sadly it doesn't make it much better.
to 1: I'll have a look in the Bluetooth API in the next weeks. But I believe, I need some bluetooth device connected on a PC and then this bluetooth hardware has to be near to tedee smartlock, correct? My server is 7m away with brick wall between the lock so I'm sure, it wouldn't work (checked with the phone app if it reaches the lock without bridge just via ble)
to 2: tbh: I don't get the security question. At the bridge needs to run a webserver with https TLS certificate for encrypted traffic. That's all you need. To secure your LAN/wifi/infrastructure I am responsible for. Of course you can always search for security holes etc. but there is not much difference between a bridge, which is already included in the wireless network and receives commands from the internet or a bridge, which has a running local webserver which receives commands from the LAN.
I assume the main challenge is to implement the very good cloud REST API to a local one running on a microcontroller unit. But to be honest: I don't see any sense migrate and harmonize all these functions to a local REST API. If you are able to without much effort, of course do it. But a simple API request for opening / closing the lock would already be a good start, isn't it ? And I think, that's not too difficult (apart from testing firmware updates OTA with webserver stuff etc. which all has to be included).
What does "we do not plan in the _near_ future" means? It sounds like it will never happen. I really hope it will not be so. That it will not happen fast, I already was aware of. But a 12 month time frame I hopefully assumed it would be possible. A concrete answer on it, with a timeframe from to on the current planned roadmap would be really nice to see.
Don't get me wrong: your lock is really great. (rechargable!) battery life time compared to the size and the noise level is perfect! the internet REST API is wonderful and perfectly described via swagger. It is just the single thing, which can occurs for some people like me a huge impact on decisions.
I understand Marcel's frustration with this topic. When the lock came out "local API coming soon" was advertised by Tedee and Marcel and I are not the only customers who are "misled into buying", if you check topics regarding tedee from about a year ago in smarthome forums. For example an answert someone apperently got from Tedee support in a German forum from a year ago:
" Aktuell ist das nicht möglich. Eine lokale Bridge API hat aber gerade die höchste Priorität im Entwicklungsteam weil es sich do viele Kunden wünschen. Für weitere Fragen stehe ich Geren zur Verfügung. Viele Grüße" Similar quotes can be found in openhub forum etc
Hence your statement: "We do not plan to add the local REST API in near future." now is very disapointing and scratches the subject of false advertisement!
Kaktus and Jitterer, the best source of information about new features is this forum. We work closely with our partner from Germany but we do not follow their forum. I can assure you that he didn't mean to mislead anyone, the topic of local API was discussed by Tedee team but other user needs as Keypad pushed it down. It doesn't mean that we will never provide a local API. This feature is still on our list but I want to make it clear that this is not our priority at the moment and we can come back to this topic in 12 months' time.
Thanks for your reply. This forum did not excist, when you advertised "local API coming soon". And this was not just by German distribution, but if I remember correctly also on your website. I just wanted to point out that we are not the only ones, who read/heard about and are waiting for it.
And yes, we - at least I - have no idea about the size of the team and the capabilities and possibilities of it. There are several items I would like to see released. As you know I am waiting on the keypad for a year now and I was first told it comes in the first half of 2021. I just hope not everything is worked on one after another, because then this would take quite some years ;)But what I do tell people and I appreciate so far: You delivered what you promised. Maybe that's why I got upset from your post, because I know an advertised feature from another smartlock company, which was never implemented.
Hello I bought this device because it was promised that there will be a local api. I live in an area where the internet connection is rather bad and that's why it is better for me if there will be a local api. When it comes to security, please let the user decide if you tick the box in the app whether he would like to use it or not.
I hope that the implementation will take place in the near future, otherwise the device is unusable for me.
thank you for your understanding.
oh an just fyi @Konrad Sikorski the German Youtube Channel from Spiel und Zeug reviewed the lock as you propably know. Check out how many people just there comment that they will not use a lock in a cloud based system. Maybe you should work on this local API to push your sales, before they all end up at Nuki 3.0...