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