I join, very good news ! Many users have been waiting for this for a long time. I think all the important points are listed. It would may be interesting to know in what way the lock was opened or closed, possibly keypad, app, autolock, key (the old one from metal 
etc ? So I can trigger various actions. But that maybe in the next step, if that delays the release.
I would like to see Keypad integration as well: PIN Code Management of Keypad: e.g. assign PINs to a specific lock & task (lock/unlock) Battery state of the keypad @Konrad, regarding bulletpoint 4: So finally we can unlock Tedee without pulling the latch in the morning and still have geofence opendoor function with pulling the latch?
Great to read. Does bulletpoint 5 means webhook? If not, webhooks would be great to call by lock state change, ideally with custom configurable http headers.
Will the local rest API work standalone? Like after general setup configuration via tedee mobile app, would the lock and bridge work without having access to the internet via the local rest API?
@kaktus You can unlock the lock in the morning without pulling the spring even now. Please check the documentation: Unlock — Tedee API documentation documentation (readthedocs-hosted.com) @Jitterer Webhooks are now available for integrators who use OAuth (Webhooks overview — Tedee API documentation documentation (readthedocs-hosted.com)). point 5 is about local “webhooks”. Why would you need custom headers? At first, we focus on local API, and the Bridge will require internet access from time to time.
@Konrad, I did not know that, because I am not using web API right now. I was waiting for local API. Maybe even the local running homekit integration is enough for me, but I have to look into that as well.
Cloud API is currently working fine for me but I would also like to see a local API for future proofing. I have a useless ‘nello one’ sitting in a drawer somewhere because it depends on the cloud and the manufacturer went bankrupt so the more independent a device is the better in my book!
“Bridge will have to access the Internet from time to time.” 1) Why? 2) How often? The point of a local API is that many of us trust ourselves more than (sorry) you or - even worse - your cloud provider to keep the lock usable and secure. Local access is faster, more flexible, and works without Internet access. Security is in the domain of the user. (Do you offer a way to remove the QR code and numeric info from the back of the cylinder?) You cannot switch to a subscription service later, stop supporting the product or simply go bankrupt. All of this has happened before with other companies and while I would not expect you to charge for unlocking and locking via micropayments, it would be nice that a product I buy is mine to keep and use, no matter what the company which produced it does. (Another question: will the GO have user-changeable accumulators?)
@Jens Stark, Tedee Go, as far as the news from last year, will run on three CR123A/R (imho, an horrible idea). Your other points are very valid ones!
@Kaktus 317 Expensive and not rechargeable. But at least an industry standard format. Also, in the current version, you are supposed to uninstall your lock, send it somewhere with all it’s data or execute the factory reset - which might not do what it is supposed to do - and wait for it to be returned, which can have an unknown turnaround time. Even given a long accumulator lifetime, this is hardly practical. I really like the product. Nice form factor, probably not as loud as the main competitor, the GO easily able to interoperate with cylinders I trust and which fit my master lock scheme. But there are just these things which make it a no-go at the time being. (Smart locks are not a highly secure solution. You have all the possible flaws of the mechanical cylinder PLUS all those of the smartlock. But few people need more than that. There are products for THAT market, but they are way more expensive and more laborous to install.)
@Konrad some bigger enterprise solutions like PaaS, Middlewares etc. requires custom http headers. E.g. to classify the authentication provider. It’s not done by adding an oauth2 token there. Additionally, you can easily switch to e.g. basic auth with custom headers. For what is the internet connection requried? certificate and key exchange? Can’t we find a local solution for this aswell?
@Jitterer we Thank you for feedback. We will add the custom headers configuration. Yes the internet connection is required for certificate exchange.
So what happens after four days of interrupted Internet? What will work and what won’t?
After 10 days, Bridge will not be able to communicate with the lock, and the local API will not work.
I see a solution. 
You could allow the user to run his own CA and his own cloud solution (or HA or whatever) as an option in the GUI. Make it very clear that that leaves the security in the responsibility of the user. But I see no way to leave the certificates for lock-bridge communication in the hands of a manufacturer or some third party - nor do I see a product I would buy which would stop working after a couple of days without Internet. This is not a problem for a LOT of users - but the cert issue alone is a possible manufacturer backdoor. (Note: I do not claim that most other manufacturers are better in that regard. If they are, their hardware is crappy, though. I also assume that you, as the manufacturer, are not evil. But you could become so, willingly or, more likely, unwillingly, in the future. So could the cloud provider etc.pp.)
I agree with Jens. When Tedee mentioned local API, when the lock came out, I assumed it meant full local control and it was one reason of buying into Tedee. This is disappointing.
Hi @Konrad! Do you guys maybe have a target date of possible completion and rollout of the local API? Thanks!
Hi, It should be ready around the vacations.
I recently had a smarthome system installed in my new apartment, and as I’ve heard good things about the Tedee from the installer, I started to consider it. When I found out that it only operated via the cloud, it was a deal-breaker. Local-only or no deal for something so security-oriented. Now I found this thread, and while it’s great that you will have a local API coming soon, unfortunately requiring internet access every X days is a deal breaker, once again. Now, if it will just disable the cloud functionality (app and all that) after X days then that is fine, but what is the reason to disable the local API as well? This will be for power users likely myself, and it will be on us to guarantee the security of our local network. To be clear: I just want a lock that opens/closes via a local API, allows querying open/close status via API, and nothing more. Oh, and that doesn’t phone home or connect to the cloud. No offence intended, but you guys are a lock company, and while I trust you with this, I don’t necessarily trust you with internet security. Of course the average user doesn’t know or care and will use the cloud features, but if you can support both of our needs with the same hardware, then why not make us both happy? Perhaps hidden behind an “advanced” flag or something. You will be both the best choice for the average consumer, and also the power-user darling. Anyways, just my two cents here. I will follow the thread and hope you take this constructive criticism to heart, and one day I can get a Tedee that can operate in local-only mode
The people asking for a local API also have no problems selecting or setting up a different CA.
Imagine buying a product in which certificates are maintained in a foreign country.
Hmm, I thought the device could work truly independently of the cloud in Bluetooth only mode. I didn’t realise that any communication with the lock is dependent on having a certificate issued by Tedee within the last ten days. Not very happy about that since I’ve been burnt by IOT companies going out of business before, but on the other hand, as a product manager I can understand the problem with allocating expensive development resources to a feature that’s likely to have negligible impact on sales. I am curious how the lock can check whether the certificate has expired when it has no time reference though.