Broker handles multiple connections from Clients (subscriptions), not the Bridge webserver
Defined heartbeat by LWT
Auto-discovery possibly by announce pushes
QoS is part of the protocol
No need to manage/process multiple callbacks
Serialization is done by the broker
Lightweight binary protocol
It’s a Standard
Examples
Easy integration in:
FHEM
Home Assistant
IOBroker
Loxone
Direct Communication between infinite MQTT Client Devices
I know that this is currently not on the roadmap.
But if the discussion comes to a new interface, keep mqtt in mind as a standardized protocol over any foreign- or own-proprietary implementations.
One use case I have in mind is a Home Assistant automation which would trigger hallway lights once door is opened. Current poll-based integration introduces a significant delay which makes it unusable in similar scenarios.
Obviously, one could use additional (MQTT-enabled) door sensors, but since from a technical perspective Nuki already has everything to cover that, it’s a shame there’s no native MQTT support.
Could we get a reaction from the Nuki team on this? A lot of people would like to see this feature, is it ever gonna happen? Now that SL3.0 has onboard WiFi it should even be easier to implement.
We would like to start a discussion with you about the specification of a potential MQTT API that could make it into Smart Lock 3.0 Pro. If you have knowledge in that area and would like to participate, please send a request to join this user group: Mqtt (closed group) - Nuki Developers
Only members of this group will have access to the (hidden) discussion.
Just a quick reminder for everyone who is interested in MQTT and has upgraded to a Smart Lock 3.0 Pro: The MQTT API for SL3P is available in Beta since some time and we’re searching for beta users.
Is it planned to extend the bridge with MQTT additionally to the actual bridge HTTP API?
I eventually won’t be concerned by the bridge soon since I upgraded to the 3.0 pro after con stating the bad liability of the old door sensor with a door stayed open but automatically locked so without warn me there was a problem but it might be interesting for other users of the smart lock 2.0.
I also have a Lock 3 (not Pro) and a bridge. From a Marketing perspective, it’s OK to try pushing customers to purchase the most expensive product, but the Lock 3.0 + bridge is just 9€ cheaper than the 3.0 Pro, so features like this should also be present on the bridge.
By the way, I created another feature request that could be useful for users with home automation systems such as OpenHAB or Home Assistant with the Lock (Standard/Pro) + bridge:
from me as well.