Rozpocznij nowy wątek
W trakcie

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ł

@csaba: It is defintiely unacceptable to force a customer for a primitive security solution to keep am important component - the certificate - in the hands of people who could possibly store it in plain text on an US server run by a Russian oligarch, for all we know.

Bad enough that we do not have independent third-party audits for the firmware (which would, of course, make the product way more costly), this product is built by people who either have a hidden agenda we do not know about or who believe that the customers are too stupid to handle that  stuff themselves.
(There is a third and a fourth reason ccompanies would do that: vendor lock in is one. The stupid idea that people would pay to use a cloud service they do not actually need is the other one.)

Besides, good luck with the cloud solution once the manufacturer stops to support it - or goes out of business.

We will probably never know. I can still  use the installed mechanical locks until  some manufacturer not only has nice hardware (here, Tedee clearly delivers)  but also a firmware/software solution to match (where some competitors run circles around Tedee.).


4 osób lubi to

In progress. We are in the testing phase.


4 osób lubi to

We are thrilled to announce that the Bridge API is now available for public preview! We promised you it this year, and we delivered.  


Join the Public Preview:

  • Make sure you have enabled "Beta tester" in your account settings
  • Make sure your Tedee app is updated to version 1.184 or higher
  • Make sure your Bridge firmware to version 2.2.15876 (published today).
  • Check out our detailed documentation at https://docs.tedee.com/bridge-api to get started.


We encourage everyone to share their feedback, thoughts, and experiences as we move forward. However, we also want to remind our community to engage with respect and understanding. Every piece of feedback, when communicated constructively, is invaluable. We are a community united by our passion for innovation and excellence in smart home technology, and maintaining a positive and supportive environment is key to our collective success. 

  • Please be specific about your experiences, both positive and challenges you face.
  • Offer solutions or suggestions that you think could enhance the Bridge API.
  • Remember to keep discussions respectful and focused on the product.


Important Note on Internet Connectivity

We've noticed some discussions around the requirement of an internet connection for the Bridge. I’d like to clarify that the primary goal of the Bridge API is not to enable operation without an internet connection. Instead, its purpose is to allow you to develop integrations that work within your local network, enhancing speed and reliability.


3 osób lubi to

Regarding Internet connectivity:

Sorry.. Buying a competitor product now, as you appear to insist on you (an unreliable entity)  having access to and generate certificates. Congratulations on the release, but I assume that not very few IT security people will find your implementation worth  further consideration.


Best regards,

      Jens 
      (Former Manager Information Securuty & Solutions, SHARP  (Europe) , now retired)


3 osób lubi to

It's not only the possibility of a shitty integration. I used Nello and just had a useless device when they went bankrupt and did not implement any way to still use the hardware without their servers.


Letting their vendors tell the customers that a local API will follow and then releasing an API almost 3 years later which is not fully local is just false advertisement and I dislike this kind of ... very much. This and lot's of other reasons discussed here leads to my form of communication, I am just very disappointed of Tedee.


2 osób lubi to
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
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
An API documentation would be helpful so that smart home integrations could use the local api.

2 osób lubi to
@csaba even I dislike the kind how Kaktus communicate he is more right than you IMO. It has nothing to do about security. Changing certificates can also be done by every user (as long as tedee let the user do and integrate such a function). I can just repeat how shitty the certificate rotation with danalock worked: absolutely shitty and they locked out themself (and myself). But however.. It is how it is. Tedee will proceed with their roadmap.

1 osoba lubi to

Hi Jan, The Local API will be delivered this year. It will be our priority in following months.


1 osoba lubi to

@Konrad for your information: 23.11.2020 I have send multiple emails to your distributor smartlock.de. They answered me in an email (in german):

 "...currently the API is cloud only. But they are work_ing_ at a local version (with bridge)...".


So yes, my fault that I trust a distributor and not tedee hq. But there were communication running 3 years! ago as long your distributor wasnt lying.


Immidiately after this email response, I bought your lock. Without this quote above, I wouldn't have bought it.


1 osoba lubi to
"Instead, its purpose is to allow you to develop integrations that work within your local network, enhancing speed and reliability." Local network advantage is the enhanced speed. Reliability is just partly true because when your certificate change fails or your whole company crashes or stop the cloud service, it's absolute unreliable. So what I take out of it: you just developed this feature to reduce load of your cloud services. Because the 300ms latency in worst case (as long as you deliver a good cloud service) is nothing to open the lock. For me I don't see any improvement apart from that there will be no 20 seconds delay out of your bad cloud service (to be fair: it went much better and I can't remember such a delay for the last months). But how ever: thanks for the try. It doesn't fit my own acceptance criterias I had/have as I initially opened this feature request here.

1 osoba lubi to

Just to make sure I understand this. The certificates are required for the Bluetooth clients (i.e. the bridge/phones) to identify themselves to the lock?


I also don't like that my lock is dependent on a third party in order to function because I've been burned by IOT companies going out of business in the past.


I like the callbacks feature though and at least local integrations should be robust against temporary internet connection issues.




1 osoba lubi to

@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

@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
Zaloguj lub Zarejestruj sięaby zamieścić komentarz