Rozpocznij nowy wątek
Dyskusje Feature requests Device
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ł
153 komentarze/-ySorted by Najpierw najstarszy
Tedee team, you are making awesome HW, please do not make the mistake to destroy it with SW.

@Jakup - too late. They are also not publishing every post here and just deleted others  (your question regarding matter). I got screenshots of it. It's a shame how they cannot handle stuff.

Hi @Konrad :)

Any chance for GET webhooks? As you say smart home systems often require simpler contracts, Loxone is one example of such system, while great in some aspects, it is retarded in others - it cannot accept POST request sent to it.

Oh surprise Tedee got server issues and the locks only work with Bluetooth locally.

What I don't get though: Why is Homekit not working either? I thought this is the only way out of the cloud trouble here...

Okay, the homekit issue is not   related to the server trouble. I re-added the devices, the "old" homekit key was not working anymore though. Homeassistant presented me new ones. I was able to add them but the status still is unavailable. Yeah, good local control would be nice. Gotta ask the homeassistant guys whats going on.

Hi @Michal,


We are aware of this problem on Loxone. I have not see any webhook that work with GET and mostly because it would be hard to move all webhook data from Body to Query. @Michal do you know if Loxone would handle GET request with data in body (I even do not know if it is possible)?

@Konrad, you can add data to http body on a GET request, but it's against HTTP / REST Standart. I would never recommend to do this in a commercial product.

@Konrad, even body in GET request cannot be parsed so it would not help. I agree that moving all state to query is also not viable. I think the best solution here could be to add some kind of event callbacks - so define URL to call when lock gets locked, another URL when it gets unlocked, and one more when it fails to lock. Those 3 events are most important to get in real-time, all the other stuff like battery status etc can be polled and it will be fine. Alternatively a single callback URL with a placeholder which would get substituted with new state (locked, unlocked, blocked).

1 osoba lubi to
@Michal you are talking about webhook integration which I agree. There was already a discussion on page 2 of this thread about it. Cloud API seems to have one
Hi, As for loxone I can tell that the body of the http response can be read. It could work as following: - create a virtual output which calls tedee the GET /lock/{deviceid} endpoint - store the response of this virtual output in a local file of the miniserver - create an virtual input which reads the url of this local file every 10 seconds. The virtual input then has the option of reading out values of this local file (response from earlier) - the virtual output can be triggered using the loxone miniserver API. So we could give the tedee bridge the correct URL to trigger this VO thru the POST /callback endpoint. The problem with this solution is that the status is also only updated every 10 seconds due to the limitation to read the local file only every 10 seconds. So you can as well just directly call GET /lock/{deviceid} every 10 seconds in the virtual input. This is what we are doing right now. If loxone would give us the possibility to read values from the response also for virtual outputs instead of storing the response in a file the problem would be solved. I have already asked them if that is visible for them. Another solution would be Michals proposal which I really like! If the tedee bridge API could have different callback urls for different events we could use the loxone API to change states in real time. So one event if lock ID xyz changed to unlocked and one of it changed to locked. Basically all events you want in realtime. One thing that would also needed to be addressed in the tedee bridge API is that callback URLs with a username and password don’t seem to work. So right now it would not even work with the loxone API because this url callback does not work: Username:password@miniserverip/path I have tested this kind of authorization in another project and it did not work. Best Stephan
2 osób lubi to

hello, I can only agree with Ste Phan. 

A separate webhook for each status would be a solution that could be implemented in the short term. 

This would avoid the query time of HTTP inputs which are limited to 10 seconds in Loxone.

I can only ask you to implement this feature in this way, it would not bring any disadvantage and would give the whole Loxone community a great added value. 

The time delay of 10 seconds to know if the lock has really closed is not practicable for a security product.

Thank you!

I am a bit puzzled by this implementation. A local api is really useful and as a result home assistant has now also integrated Tedee via this api. Today the Azure webservice has an outage which has an impact on the remote function of the lock. So I thought that's not a problem as that is the purpose of a local Api right? But the bridge is not available anymore. The local api is dead, just the Bluetooth stuff via the api works. So what is the deal here?
2 osób lubi to

I can confirm Carsten's issue.  Locks are only available via Bluetooth. This is just not right Tedee.

Getting the key every other day is not what customers thought they will get when they bought the product to begin with, but this is just ridiculous!

Seriously, if you are not able to handle what you thought you would be able to and advertised (via resellers) to the customers, just sell your company already to someone who is capable of developing the software of this nice piece of hardware.

got the same problem with local api during outage, that's ridiculous that "local" api requires cloud, it's not local api at all

cannot update the previous post, so adding another one looks like it's not even possible to connect to the bridge via bluetooth in the app during that outage

Zaloguj lub Zarejestruj sięaby zamieścić komentarz
Więcej wątków w Device
Przeszukaj wszystkich 41 wątków
Oprogramowanie centrum pomocy przez Freshdesk Support Desk