Describe which Smart Home Hub could be supported by an MQTT API and what is needed in order to integrate the Nuki MQTT API into it.
One major aspect is, how mqtt server connection details are brought to the Smartlock.
The Shelly devices offer a webpage to configure the mqtt details, as well as http rest calls to set server:port, topic, user/pass and the retain flag.
Users sometimes have troubles to know if the device is already connected to mqtt or not (troubleshooting). If possible in an easy way, it would be nice to get feedback that the mqtt connection is up or not.
SL3P can’t have a web page, because we do not have the resources to run an HTTP server.
The most common method would be provisioning via BLE (i.e. the Nuki App) and also checking the connection status via BLE. This is also from a security standpoint safe.
Something more user friendly which does not require to type in any credentials would be interesting though. So if you know of anyone doing this in a better way, please share it.
It would be also interesting to understand the efforts needed to setup and integrate an MQTT server in the Smart Hub that you’re familiar with (in your case Loxone).
BLE configuration of the mqtt settings via App is fine. As an http interface would again need attention for authentication and security, the BLE variant is just fine.
Loxone currently does not provide any mqtt server and client functionality natively, but only very very basic http rest and unidirectional tcp/udp message transport.
(but as of late Loxone uses mqtt internally to provide a kind of DynDNS functionality.)
MQTT functionality with Loxone currently is handled by LoxBerry MQTT Gateway (LoxBerry is a ready-to-use Raspberry or VM image). This MQTT Gateway on LoxBerry bidirectionally connects Loxone to MQTT. Therefore, it converts MQTT messages to HTTP REST requests for Loxone, and receives UDP messages from Loxone that are forwarded to MQTT).
As Loxone cannot parse json, also generic multi-level json parsing is done on the MQTT Gateway. As Loxone cannot handle strings, a string to number conversion is built into the MQTT Gateway.
On LoxBerry, the Mosquitto broker is automatically installed and configured with initially random mqtt credentials on LoxBerry. LoxBerry currently uses non-secure mqtt with authentication. Next LoxBerry version will (additionally to the 1883 port) provide also TLS-support with client certificate (the non-encrypted mqtt support additionally stays open, as TLS support is not very common on the low-budget IoT devices).
As LoxBerry is a plugin platform, plugins directly can access the mqtt server connection details from th MQTT Gateway without nagging the user with mqtt settings, and plugin developers can simply push to MQTT instead of nagging the user to provide connection data to Loxone.
For example, the Zigbee2Mqtt plugin does neither need mqtt connection nor Loxone connection configuration by the user.
An concrete example with Loxone and the MQTT Gateway, as Nuki supports MQTT:
To unlock the door, the user would configure the following UDP command in Loxone Config:
publish nuki/1234567/set unlock
To receive the state, the Loxone user would create a so-called “Virtual Input” in Loxone Config with the name
nuki_1234567_lockState (as Loxone does not support slashes in Virtual Inputs)
The MQTT Gateway will push the received lock state via HTTP REST to this “Virtual Input”.
1 Like
I have a Home Assistant install. Though I’m currently only using HTTP & z-wave integrations it’s easy to add an official Mosquitto broker addon to support MQTT calls
Can you elaborate a bit more on this please?
HomeAssistant does have auto discovery the other way round. i.e. when adding a device to the MQTT server it can announce its presence to /config and thus be added to HomeAssistant automatically. Is that something that would/could also be useful for LoxBerry? MQTT Discovery - Home Assistant
1 Like
As plugins are installed on the same device, LoxBerry-Core provides SDK functions (PHP, Perl) to get broker connection details, and for other programming languages a pre-defined file location that holds the mqtt credentials as a json file. It would be possible to aquire the connection details also via http json-rpc from a remote LoxBerry installation, but I am not aware that any developer is using that.
I also already read the Home Assistant Auto-Discovery feature and the Lock integration, and I like the feature set. As LoxBerry only acts as a gateway, and Loxone Config has no auto-discovery/auto-creation feature, I cannot use the auto-discovery messages to automatically configure something in Loxone, but the Gateway would have no problems with the messages.
If auto-discovery messages are implemented in the Home Assistant style, it would be possible on the LoxBerry side to implement a template generation in the LoxBerry-Nuki plugin. That is, what we currently do with the Bridge connected Nukis. Loxone Templates are xml files that can be imported into Loxone by the user, that create Virtual Inputs and Virtual Outputs.
Also without templates it is very easy to create inputs/outputs by the users.
One of the main avantages of using MQTT is that it’s controller / hub / system independent. With a proper implementation and supporting documentation any system will be supported and can map the device status to the corresponding device instance within the system.
Having said that, I’m a Home Assistant user and it helps if the MQTT device uses the HA discovery message. That avoids some manual configuration. But not mandatory at all, I have more MQTT devices with manual configuration.
Same goes for configuring the MQTT broker. It would be nice to have a option page in the app which synchronises the configuration over BLE. But I would be fine with having to set it up using the REST API. Systems that would like to integrate over MQTT could create their own setup page in their own ecosystem and update it over the REST API.
1 Like
+1 for home assistant auto-config. Makes the experience way smoother.
2 Likes
I would appreciate some feedback from Nuki on our input. Does it help in deciding this is a viable feature? I have a personal interest as well. The lack of local API support has kept me from upgrading. If I know this feature will eventually become available I can start thinking about an upgrade.
For HA, it would be quite easy when it is on MQTT.
I bet, those guys will implement it to their integration right away, as to get the best from NUKI in HA is their goal.
If not, it is easy to integrate the MQTT topics in HA config. There is even MQTT Lock template / support.
I’m the author of the first integration (Nuki Card) based on callbacks (no polling) for Nuki SL in HA. I made it as a big HA automation, then luckily Konstantin ported it to a custom component, and now we all migrated to the component obviously. If MQTT was already available for Nuki at the time of developing it, the integration would’ve been much more easier, so for sure we’ll integrate it asap in the component.
The great advantage of MQTT for Nuki is decoupling the bridge (or the SL integrated wifi when it will support an API): since the bridge is very limited hw-wise, it doesn’t support more than one connection at a time, so often there are http errors when querying the API. With MQTT the status and commands would be managed through a broker, so all the issues regarding communication would be solved by the new architecture. Nuki SL is a perfect use-case for MQTT integration in automation hubs.
But the unique differentiator in terms of functionality for Nuki SL integration is what Juergen wrote in the introduction, that would be available only via MQTT: much faster updates and transient states, that are the current weak points of the HTTP integration.
With these two HA features (discovery and MQTT locks), integration in HA will be very easy for the end user. MQTT lock supports device mapping (based on discovery) that essentially lets the device configure itself in HA device registry, it’s basically like PnP via MQTT:
1 Like
I agree with the above. Especially that automatic Discovery is important for easy integration.
Just I would like to be able to configure which commands are accepted through MQTT. It means to select in the configuration which action are allowed through MQTT: lock, unlock, activate ring-to-open, etc …
Usecase:
I want to see the lock status in HomeAssistant and I want them to issue Lock command from the automations like presence detection, delay lock on button press, closed door sensor, etc …
But I do not want the HomeAssistant to be able to unlock the door. I trust only the Nuki mobile application to do the unlock.
Come on guys at Nuki. Most of us have put effort into integrating Nuki in various home automation systems and have helped Nuki to become a popular product. We have taken te time to give some proper feedback on this subject. Dont you think the decent thing to do is to at least inform us on what is done with this feedback. The lack of response from Nuki on this is not very motivational.
I gave an update some time ago through a message that was sent to all group members. But yes, of course you deserve an update: We are working on a draft specification which we’ll share here and based on which we can continue the conversation.
Unfortunately the draft ist late (was planned for march and is still not there), but so is the Smart Lock 3.0 Pro too, which has been on sale for just 5 days since we announced it in November last year. Anyways things should get better now with chips becoming available. I hope that the same is true for the MQTT draft …
Just as a note: This is just an RFC for a spec. There is no guarantee that it will ever make it into a final product.
2 Likes
Thanks for the update. What will be the criteria for you to decide it will make it into the final product?
I can’t share any details, but certainly the number of potential users (% of Nuki customer base) and the complexity of the development requirements play a major role in the decision process.
Makes sense. You should also take into account all potential users that will look for easy integration before deciding to choose Nuki. If I had to change product, I would certainly use that as the main criteria (zigbee, mqtt, etc.)
Is there a deadline for this decision?
No
I join here late, without any prior Nuki experience. I just want to give more weight to the above statement: I’m currently looking around, thinking about buying a smart lock and Nuki looks like a very good candidate. However, this current feature is what would trigger the buy for me (or stated otherwise: I would not buy it without this feature).
(By the way, thanks @Juergen for adding me to the group, that’s very interesting to see such discussions and kudos to you to having these open discussions with your power users).