Rozpocznij nowy wątek

local REST API in Bridge


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 :) 


4 osób lubi ten pomysł

Hi Martin,

I am testing the Bridge-API since a couple of weeks extensively and do not experience these delays. May I ask how you send the Requests? Directly from the Browser or Postman? Or is it part of an automation software? Do you know if the response from the bridge is coming right away or is the response also delayed?



@Kaktus I assume you had some Link or Word which triggered the freshdesk filter and you post is now somewhere in "messages to check" folder.

@Ste Phan,

I posted it yesterday. Rewrote it today and it has not been published. Does not contain any link. And talking about the words: I don't even use the ones which come into my mind, because people seem to have feelings here... Hence, to be honest I don't know what triggers the filter.

@Kaktus I wrote a Post a couple of days which contained the Link of the Bridge-API Documentation which is also not published yet. I guess there is simply nobody checking the potential spam messages.

1 osoba lubi to

 I would not say nobody is checking the potential spam messages. They will be probably right on it after activating NFC of the keypad...

@StePhan - I'm not sure why I have never tried to test the wifi connection - it showed that the ping was fluctuating between 10ms - 3500ms so the whole time it was just poor wifi connection omg. 

1 osoba lubi to

I forgot to mention, please also update your lock firmware:

  1. PRO - 2.0.15964 
  2. GO - 2.0.15968 

1 osoba lubi to

Is it also possible to update the Fibaro Tedee app to use the local api? Or is this app not developed by Tedee?

the integration is managed and implemented by Fibaro. While we at Tedee have already been in contact with them regarding this, it currently does not hold a high priority status in their development queue. I encourage you to directly reach out to Fibaro with your request. Community interest and demand can significantly influence their prioritization of such integrations.

@konrad sikorski - what if your company will shutdown or cloud will not work anymore - the connection between the bridge and the lock will stop working once keys will not regenotiate? 

Thanks @Konrad for this introduction.

For me it was not clear that I need to set my account to be "Beta tester" in the app, I tried first to do so in the portal - since it is my computer that I use for dev purpose...

I can follow your arguments for the need of internet access for the app to renew certificates.

For me as representative of a company integrating your bridge-API in our physical access management solution, this is really all we need and demand.

But I can also add my knowledge about customers - and especially big players can't accept this for different security and reliability reasons. Think of banking or other regulated businesses, which even have regulatory issues when relying on 3rd party clouds without the chance to remedy issues on their own.

Don't get me wrong: a strong certificate chain is really needed, but a trust chain must rely on trusted partners, which you might not be for everyone.

My first feedback to the Bridge-API:

  • well documented, thanks for that
  • works well and has all operation and status responses needed so far I can see after some quick tests
  • it's quick, very low latency compared to cloud in certain test scenarios
  • ...but: it is strange for me, that the local API is completely different to the cloud API
  1. endpoints 
  2. data types in response, starting with a missing "success"/"errorMessage"
  3. HTTP GET in local API vs. POST in cloud API
This results in two completely different integrations for the same device, depending on local or cloud access.

I also claim my demand for having access to the API key on "" account details as for the cloud API keys. It seems not to be integration-friendly to let the end-user read the API token in his app and write it down in a configuration tool for whatever integration. I do not even understand why there is a different authorization procedure as for the cloud API?
Sorry probably stupid question but how do you set your account to be beta tester? I can't find any beta tester entry on the play store and no setting in the app itself. Might be blind..

@Carsten: it is in the App, and you have to open the menu and select your account there (should be the first entry in the menu).

On the  account page, the 4th entry is "Beta-Tester". If it's not there, you have an old version of the app, I think...

@Michael thank you for feedback.

I understand the need for more offline option. The local API is not the final iteration. We're committed to evolving it based on customer feedback like yours.

We designed the local API to match our cloud API as closely as possible. We simplified the local version because:

  1. it will not support everything that cloud must do
  2. Smart Home Systems often require simpler contracts for seamless integration.
  3. The bridge itself has limited resources.

Differences you mentioned:

  1. Endpoint and parameters should be the same as a cloud with some exceptions
  2. datatypes are also very similar. Yes, we do not return success/errorMessage to simplify the contract
  3. HTTP GET vs POST - there should be no differences. Please give more examples.

Your point about the inconvenience of having to build a new integration for the local API is well-taken. We’re open to suggestions on how to make this process smoother.

We have different authorization methods for local API because these are two separate APIs. We do not expose the local API token over the internet to keep it secure and to reduce the dependencies with a cloud.

@Ste Phan, mystery solved: Tedee deletes criticism here and obviously  does not publish everything. I don't appreciate censorship and how they handle critic.

Zaloguj lub Zarejestruj sięaby zamieścić komentarz