Nuki Bridge MQTT Support

Product name

Nuki Bridge

Summary

Support MQTT binding for status and commands

Features

Basics:

  • Topic base configurable
  • Subtopic Bridgeid
  • Subtopic Nukiid
  • LWT for Bridge State
  • Broker Hostname:Port
  • Authentication
  • Payload may be plain or json

Publish Nuki status:

  • Locked/Unlocked state
  • Door open/closed state
  • Bridge online state
  • Nuki online state

Commands

  • Lock/Unlock commands from the Bridge API
  • Possibly all the commands from the Bridge API

The MQTT settings may be configured via the App

Reason

  • Clean implementation of status push
  • 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.

Due to the lack of MQTT support I have written a service that enables MQTT for the bridge if you’re interested: https://github.com/bluewalk/NukiBridge2Mqtt

2 Likes

Is this feature planned for near feature?

Would also love to see that happen.

+1 for MQTT support.

1 Like

+1 for MQTT support, too

+1 for MQTT support. It would make it easier to justify the need for the Bridge when using the Opener.

+1 for MQTT support

+1
by the way: MQTT nowadays is a common standard in homeautomation - please wake up nuki-team!

1 Like

+1

+1 now that IFTTT has become paid!!!

:heavy_plus_sign: :one: from me as well.

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.

4 Likes

Is it likely that this most chosen feature will be implemented?
The possibility of integrations will raise exponentially :smiley:

+1

That would really be a huge improvement. However, judging by persistent silence of Nuki employees in this forum, we might not see an implementation.

Patrick

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.

2 Likes

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.

If you would like to participate, please send a request to join this user group: Mqtt (closed group) - Nuki Developers

1 Like

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.