Hello,
possibly because of Corona it was silent in here for the last few weeks.
I just wanted to ask, first of all, all people healthy at Nuki? 
There are some feature requests out there for the Bridge API, e.g. door open/closed state, opener ringing, and my ābabyā, MQTT support 
Can you give us a short message, and possibly some spoilers, what we can joy to be waiting for? 
Thanks and keep healthy!
Christian
Thanks for asking. Like many other consumer facing companies we were immediately affected by the restrictions in terms of sales revenues. We also had to take measures in order to protect ourselves (Homeoffice, ā¦) and are now working on slowly returning back to business. Luckily we had no case in our office. Everybody is healthy.
When resources are restricted we have to focus even more on the most important things and that - unfortunately - is not good for everything around the bridge API as it is used only by a quite small fraction of our user base. However it looks like we are able to squeeze some things into the upcoming (beta) releases for the next months ā¦
Hmm,
First nice to here that all of you are well.
I also like the bridge API more then the web api.
Since I use it for KNX Integration.
And so Iām indipendent from the internet. Just intranet.
MQTT would be awesome and exactly the perfect integration for the lock. No need for HTTP or callbacks any more. And of course support in numerous platforms.
Patrick
Moving to MQTT to communicate with the bridge would be a great improvement and would hopefully put an end to the bridge going into a sulk if itās queried too quickly
For all who desire mqtt, Please keep in mind, that a lot of IOT devices and of course IFTTT use http for communication. So mqtt should never replace the http api but only be an addition. For me, as a early early kickstarter user and developer of the homebridge plugin, I never hab a problem using the http api. Just sayin.
@Juergen if ony a fraction of user use the http api of the bridge, how about open sourcing that part of the bridge and add a mechanism to apply this to the bridge by users? As a software developer I know, that maintaining something that only a few people use is not quite motivating and this part will never get as much attention as the few people would like.
You donāt remember the http 500 issue?
Or the hard to manage callback feature?
Of course, already implemented apiās cannot be replaced. I already would be happy if all existing apiās would support the current feature set of the hardware.
Nevertheless, I hope that the door sensor is on the roadmap for callback, or something completely redesigned. JĆ¼rgen hasnāt announced anything above.
@benzman81 No, worries the HTTP-API is not going away.
Unfortunately itās not as easy at it seems. The current round of firmware updates (for both Smart Locks & the Opener) lay an important foundation for a future extension of the API.
Correct me if Iām wrong, but IFTTT shouldnāt be able to call the local bridge API anyways. And that a lot of IoT devices use http shouldnāt be an excuse to ignore a better suited protocol for progressive devices.
The problem might be storage limitations on the ESP. Concerning integration: Most if not all modern home automation systems support mqtt, including homebridge. If not, a workaround might be to implement a compatibility layer as a separate service to emulate the http api for legacy systems.
However, this is all theoretical as I donāt think that dropping the http api will happen.
Patrick