Start a new topic
Implemented

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 people like this idea

@Carsten, just remember: "must be" as well as "high on the priority list" does not mean anything with Tedee ;)

@Kaktus317: They just released a new, important product. Give them time to fix any urgent issues with that one. :) 


@Jens Stark, they should not have released any new product, since they did not deliver stuff promised on existing products to customers who already paid for it. And yes, tedee/konrad may see that differently. But it does not matter much, because the customers perspective is the one which counts.

@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.

@Kaktus317: Getting a bit off topic here.
I worked for a Fortune 500 company. It doesn't work like that even there. Internally, you get a lot of product releae info - and the products these replace had annoying issues. But you would still hear "Next year's model" and if you were lucky, you would actually get a solution. Remember that the older product is still being sold and maintained - so I would not give up hope. (If both products share a code base, which we don't know, then fixes to one product may be retrofit to the other if there is space.)
But releasing the GO was an important thing - it solves a number of mechanical issues, is more compact and if you don't show progress on your products (unless you are selling screwdrivers or nails), you fall back behind the competition. If I was in their place, I would do exactly the same. Especiially with limited ressources (which you even have in a multinational company with 50000 employees.)
What was the statement TEDEE gave out that guaranteed a local REST API?


I see the main problem in ECDSA key handling via the cloud. 
In my case, I'd be perfectly happy to be able to take care of key handling myself, then using the existing BLE API to talk to the lock. Problem solved. 

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.

@Jens Stark,

I am sorry, but we are not talking about the same thing.

There does not need to be a new product, so that the original one is getting fixed. And I am not talking about "getting maintained" either. I am talking about implementing really small stuff, what customers, who bought the product from the beginning, asked for years now. I am talking about a few lines of code, which would help some paying customers a lot. I am talking about software stuff, which the competition already offered when Tedee released their product. I am talking about stuff customers asked for and Tedee declined "because nobody needs this" and almost every competitors offers now. I am talking about stuff Tedee (or their direct distributors)  advertised and have not delivered.


And no, I am not giving up hope. I am totally pi**ed that a company does not implement features within years, but brings out a new product, which for most of the people the only benefit is that you don't have to cut your key off anymore. Has a lot of disadvantages too: bigger, just plastic, horrible batteries, ... But yeah, of course, this was a very important step. Forget about bringing your existing product from 80% to 100%...

@Kaktus317: You want to misunderstand me? 
There is an existing product line which seems to sell. Adding another product is the sole decision of the company building that stuff. You can cheer, you can ignore it, you can yell at it. That won't change anything.
Both of the products are alive and well - what they need is a REST API, either in the lock itself or in the bridge, which does not use the cloud. But - and this is a legal question - have they ever advertised the local REST API  in public? 

And out of interest: NUKI offers very loud locks with a local API, but which other manufacturer does (and has public documentation, so DANALOCK is out.)

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.

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

When the Thread/Matter firmware is released,  can this be used without the Tedee bridge, so you can lock/unlock the door with a Thread Bridge (Thread Border Router)?

Login or Signup to post a comment