Rozpocznij nowy wątek
Zaimplementowane

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ł

Any news on this @tedee support team?

1 osoba lubi to

I just gave it up. I'm sure they will even not release it in 2023. I moved with my tedee to another small hall where I dont care about security and stability and got a new device from a competitor at my home.


1 osoba lubi to

I've also been waiting for the local API for a long time, as I know it from other providers. Unfortunately, my internet connection often has problems, so I can't get into my house via the internet. The keypad is just a pretty ugly solution, which has no good place at my door.

I have integrated an Ekey finger scanner into the door and have so far connected it to a Burg Wächter Secuentry via a relay, which then Bluetooth sent to the lock. That was very failsafe. Unfortunately, the lock did not have a motor, which had some disadvantages.

The Tedee lock is almost perfect, except for the cloud connection. I often stand in front of the door for 30s until it opens. I find it bearable but not my wife and child. It would be good if there was an external input in the bridge to pass on direct signals. There lays safety is entirely in the hands of the user. Otherwise, a local API is of course the alternative for me, if not the best.
But definitely better than via cloud.

I am pleased to announce that we have started work on the local API. The API will allows you to:


  1. Get list of connected locks to the bridge
  2. Check the Lock state (unlocked/locked/...)
  3. Check the Lock battery level
  4. Operate the lock (unlock/lock/pull)
  5. Be notified when the lock state changes.



Please let us know which features you expect/need from the local API.

Hi. I'm happy to read that it's finally being done. Can you scream a documtation about the syntax...... Thank you.

 I join, very good news ! Many users have been waiting for this for a long time.

I think all the important points are listed.

It would may be interesting to know in what way the lock was opened or closed, possibly keypad, app, autolock, key (the old one from metal ;) etc ? So I can trigger various actions. But that maybe in the next step, if that delays the release.

 I would like to see Keypad integration as well:

  • PIN Code Management of Keypad: 
    e.g. assign PINs to a specific lock & task (lock/unlock)
  • Battery state of the keypad

@Konrad, regarding bulletpoint 4: So finally we can unlock Tedee without pulling the latch in the morning and still have geofence opendoor function with pulling the latch?
Great to read. Does bulletpoint 5 means webhook? If not, webhooks would be great to call by lock state change, ideally with custom configurable http headers. Will the local rest API work standalone? Like after general setup configuration via tedee mobile app, would the lock and bridge work without having access to the internet via the local rest API?

@kaktus You can unlock the lock in the morning without pulling the spring even now. Please check the documentation: Unlock — Tedee API documentation documentation (readthedocs-hosted.com)


@Jitterer Webhooks are now available for integrators who use OAuth (Webhooks overview — Tedee API documentation documentation (readthedocs-hosted.com)). point 5 is about local "webhooks". Why would you need custom headers? At first, we focus on local API, and the Bridge will require internet access from time to time.

@Konrad, I did not know that, because I am not using web API right now. I was waiting for local API.

Maybe even the local running homekit integration is enough for me, but I have to look into that as well.

Cloud API is currently working fine for me but  I would also like to see a local API for future proofing. 


I have a useless 'nello one' sitting in a drawer somewhere because it depends on the cloud and the manufacturer went bankrupt so the more independent a device is the better in my book!

"Bridge will have to access the Internet from time to time."

1) Why?
2) How often?

The point of a local API is that many of us trust ourselves more than (sorry) you or - even worse - your cloud provider to keep the lock usable and secure.

Local access is faster, more flexible,  and works without Internet access. Security is in the domain of the user. (Do you offer a way to remove the QR code and  numeric info from the back of the cylinder?)
You cannot switch to a subscription service later, stop supporting the product or simply go bankrupt. All of this has happened before with other companies and while I would not expect you to charge for unlocking and locking via micropayments, it would be nice that a product I buy is mine to keep and use, no matter what the company which produced it does. (Another question: will the GO have user-changeable accumulators?)


@Jens Stark,

Tedee Go, as far as the news from last year, will run on three CR123A/R (imho, an horrible idea).

Your other points are very valid ones!

@Kaktus 317
Expensive and not rechargeable. But at least an industry standard format.

Also, in the current version, you are supposed to uninstall your lock, send it somewhere with all it's data or execute the factory reset - which might not do what it is supposed to do - and wait for it to be returned, which can have an unknown turnaround time. Even given a long accumulator lifetime, this is hardly practical.

I really like the product. Nice form factor, probably not as loud as the main competitor, the GO easily able to interoperate with cylinders I trust and which fit my master lock scheme. But there are just these things which make it a no-go at the time being.
(Smart locks are not a highly secure solution. You have all the possible flaws of the mechanical cylinder PLUS all those of the smartlock. But few people need more than that. There are products for THAT market, but they are way more expensive and more laborous to install.)

@Konrad some bigger enterprise solutions like PaaS, Middlewares etc. requires custom http headers. E.g. to classify the authentication provider. It's not done by adding an oauth2 token there. Additionally, you can easily switch to e.g. basic auth with custom headers.


For what is the internet connection requried? certificate and key exchange? Can't we find a local solution for this aswell?

Zaloguj lub Zarejestruj sięaby zamieścić komentarz