Rozpocznij nowy wątek
W trakcie

local REST API in Bridge

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


4 osób lubi ten pomysł

@Jitterer we Thank you for feedback. We will add the custom headers configuration.


Yes the internet connection is required for certificate exchange.

So what happens after four days of interrupted Internet? What will work and what won't?

After 10 days, Bridge will not be able to communicate with the lock, and the local API will not work.

Ouch


I see a solution. :)

You could allow the user to run his own CA and his own cloud solution (or HA or whatever) as an option in the GUI. Make it very clear that that leaves the security in the responsibility of the user. 

But I see no way to leave the certificates for lock-bridge communication in the hands of a manufacturer or some third party - nor do I see a product I would buy which would stop working after a couple of days without Internet. This is not a problem for a LOT of users - but the cert issue alone is a possible manufacturer backdoor.

(Note: I do not claim that most other manufacturers are better in that regard. If they are, their hardware is crappy, though. I also assume that you, as the manufacturer, are not evil. But you could become so, willingly or, more likely, unwillingly, in the future. So could the cloud provider etc.pp.)

I agree with Jens.  When Tedee mentioned local API, when the lock came out, I assumed it meant full local control and it was one reason of buying into Tedee. This is disappointing.

Hi @Konrad! Do you guys maybe have a target date of possible completion and rollout of the local API? Thanks!

Hi, It should be ready around the vacations.


1 osoba lubi to

I recently had a smarthome system installed in my new apartment, and as I've heard good things about the Tedee from the installer, I started to consider it.


When I found out that it only operated via the cloud, it was a deal-breaker. Local-only or no deal for something so security-oriented.


Now I found this thread, and while it's great that you will have a local API coming soon, unfortunately requiring internet access every X days is a deal breaker, once again.


Now, if it will just disable the cloud functionality (app and all that) after X days then that is fine, but what is the reason to disable the local API as well? This will be for power users likely myself, and it will be on us to guarantee the security of our local network. 


To be clear: I just want a lock that opens/closes via a local API, allows querying open/close status via API, and nothing more. Oh, and that doesn't phone home or connect to the cloud. No offence intended, but you guys are a lock company, and while I trust you with this, I don't necessarily trust you with internet security.


Of course the average user doesn't know or care and will use the cloud features, but if you can support both of our needs with the same hardware, then why not make us both happy? Perhaps hidden behind an "advanced" flag or something. You will be both the best choice for the average consumer, and also the power-user darling.


Anyways, just my two cents here. I will follow the thread and hope you take this constructive criticism to heart, and one day I can get a Tedee that can operate in local-only mode :) 

The people asking for a local API also have no problems selecting or setting up a different CA. Imagine buying a product in which certificates are maintained in a foreign country.

Hmm, I thought the device could work truly independently of the cloud in Bluetooth only mode. 

I didn't realise that *any* communication with the lock is dependent on having a certificate issued by Tedee within the last ten days.


Not very happy about that since I've been burnt by IOT companies going out of business before, but on the other hand, as a product manager I can understand the problem with allocating expensive development resources to a feature that's likely to have negligible impact on sales.


I am curious how the lock can check whether the certificate has expired when it has no time reference though.

> feature that's likely to have negligible impact on sales.


I wouldn't be so sure about this. After all, who buys stuff like this? Geeks, that's who. And geeks want to control their own infra. I don't have any numbers of course, but I'd guess it's at least a double-digit percentage that this could affect.


Also, who recommends products like this to their non-geek friends/family? You guess it – geeks :)

Hi, 


the cloud service is totally unacceptable to the point that my wife and kids wants me to trash the tedee. I'm using the cloud HTTP API but during the busy hours unlocking takes even 10 seconds. I do not want to rely on any of your cloud services anymore. I'm also not sure if I'm able to code myself the bluetooth API into my custom built key lock door opener which runs on ESP32. The ideal solution would be using the local API which does NOT query the cloud during the opening process of the tedee lock. I do not mind tha the wifi bridge needs internet connection time to time but the local API MUST open the tedee lock in a milliseconds once I will command it over the local API. Please tell me when do you release the local API feature. 

Any update on the  ETA possible? I'm currently looking to buy a smartlock with a local API and would prefer to buy a Tedee lock. Is it worth waiting for? 

Do not buy teede until this feature is done. Otherwise you will end up waiting 10 seconds in front of door waiting for the open. 

Zaloguj lub Zarejestruj sięaby zamieścić komentarz