@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.
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.
I forgot to mention, please also update your lock firmware: PRO - 2.0.15964 GO - 2.0.15968
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 endpoints data types in response, starting with a missing “success”/“errorMessage” 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 “portal.tedee.com” 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: it will not support everything that cloud must do Smart Home Systems often require simpler contracts for seamless integration. The bridge itself has limited resources. Differences you mentioned: Endpoint and parameters should be the same as a cloud with some exceptions datatypes are also very similar. Yes, we do not return success/errorMessage to simplify the contract 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.
Tedee team, you are making awesome HW, please do not make the mistake to destroy it with SW.
@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.
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.
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.
Hi @Michal, We are aware of this problem on Loxone. I have not see any webhook that work with GET and mostly because it would be hard to move all webhook data from Body to Query. @Michal do you know if Loxone would handle GET request with data in body (I even do not know if it is possible)?
@Konrad, you can add data to http body on a GET request, but it’s against HTTP / REST Standart.
I would never recommend to do this in a commercial product.