Konrad wrote this almost a year ago: “At first, we focus on local API, and the Bridge will require internet access from time to time.”
well ok, time to time is managable, though its not perfect. so how is the API - anyone tested it? or are we talking about nothing here again?
What means it’s manageable? It’s horrible! The entire thing still would be unusable if Tedee goes out of market (what they will imho, when they keep up this road).
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.
@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.
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.).
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 Tedee 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.
@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)
@Martin We release updates in batches. Just wait, your bridge should receive it by Friday.
The necessity to have internet connection is really bad idea, If it is just for start than OK, but this should be fixed.
“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.
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.
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? Best Stephan
@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.