Tedee

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

So according to last info internet connection is needed to rotate certificates in every 10 days to keep things secure. I think it is fair. It is the vendor's call to decide adding an option for the user of "I hereby accept that not updating certificates is a security risk and I will not put any responsibility on the vendor". If Tedee doesn't want to add the switch opting in something like that, it is completely reasonable and acceptable.

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.

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

@konrad - I have set beta tester in my account few days ago - but it seems that in the tedee app I cannot update bridge to the beta version - it does not offer update to 2.2.15876

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)

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.

curl -X 'GET' 192.168.0.177/v1.0/lock -H 'accept: application/json' -H 'api_token: XXXX'

{"error-description":"Invalid token"}

I have double checked the token and even regenerated new one in the tedee app but I'm getting invalid token always 

nevermind I have reread the doc and it is working now 

so, now my posts are not beeing published anymore?

sometime I have still 3-5 seconds delay when unlocking with local API - I guess the lock is in some sleep state and it still takes time to wake it up - otherwise I do not know what might be the reason to wait >2 seconds from opening the lock by directly query the lock.