Wir hatten schon länger mit einem Smart Lock geliebäugelt, um nachts automatisch die Haustür abzuschließen. Also haben wir bei der letzten Angebotsaktion ein Nuki Smart Lock Pro (4. Generation) erstanden und in Betrieb genommen. Die Einrichtung sowie die Zeitsteuerung funktionierten hervorragend. Nur ein Problem blieb: Wenn abends automatisch die Tür von innen verschlossen wird, kann sie nicht mehr über den RFID-Chip an der DoorBird-Türsprechanlage entriegelt werden (siehe DoorBird – Installation). Auch die übrigen Arten der Entriegelung wie über HomeKit oder Loxone Touch würden nachts nicht mehr funktionieren, denn alle verwendeten denselben Mechanismus, den Türöffner (Summer) über einen Relais-Ausgang zu aktivieren, und der ist bei abgeschlossener Tür wirkungslos. Es musste also eine Lösung her, um das Nuki Smart Lock über Loxone zu entriegeln.

Ohne Gateway keine Option: Lokales HTTP

Meine erste Anlaufstelle war die Home-Assistant-Integration für Nuki. Diese kommuniziert via HTTP mit einer Nuki Bridge, um das Smart Lock über das lokale Netz zu steuern. So weit, so gut. Einziges Problem: Das Pro-Modell der 4. Generation nimmt direkt Verbindung zum WLAN auf und kommt komplett ohne Bridge aus. Es hat aber auch keine eigene HTTP API, kommt also nicht für die Verwendung mit der genannten Integration in Frage. Wenn man ein Modell mit Bridge verwendet, ist dies vermutlich die einfachste Variante.

Einfach, aber langsam: Home Assistant und Nuki Web API

Die nächste Art, das Smart Lock Pro ohne Gateway per HTTP(s) anzusprechen, schien mir die Nuki Web API. Auch wenn ich aus verschiedenen Gründen eigentlich nicht wollte, dass der Loxone Miniserver im Keller über das Internet mit dem Smart Lock im Erdgeschoss kommuniziert, erschien mir das als die am einfachsten umzusetzende Lösung. Also überwand ich meine anfängliche Skepsis, aktivierte die Web API in meiner Nuki App und machte mich daran, die Lösung umzusetzen. Das macht der Miniserver der ersten Generation einem nicht wirklich leicht, da er kein HTTPS beherrscht. Natürlich ist die Nuki Web API ausschließlich per HTTPS verfügbar, so dass ich den Umweg über meinen Home Assistant nehmen musste. Die Details erspare ich euch, weil ich ohnehin nicht dabei geblieben bin, aber die Idee war ein rest_command Template, das ich dann aus Loxone heraus via /services/ API ansprechen konnte.

Zuerst die gute Nachricht: Dieser Weg funktionierte. Man konnte die Tür wie geplant entriegeln. Allerdings war die Latenz viel zu groß um praktikabel zu sein: Wenn man draußen den RFID-Chip an den Leser hielt, ertönte nach ca. 1 Sekunde der Bestätigungston des RFID-Lesers, dass der Chip erkannt wurde, und erst ca. 2-3 Sekunden später öffnete sich (meistens) die Tür – spät genug, um zu bezweifeln, dass die Kommunikation überhaupt funktioniert hat, und den Chip ein zweites Mal an den Leser zu halten. Bei Besuch war Ähnliches zu beobachten: Die Verzögerung zwischen Klingeln und Öffnen der Tür führte meistens dazu, dass entweder ein zweites Mal geklingelt oder direkt der Rückweg angetreten wurde – und das nicht nur bei Paketdiensten. Die User Experience war schlicht inakzeptabel. Also zurück auf Start.

Schnell und praktisch: Lokal via MQTT

Ich brauchte einen Weg um das Smart Lock direkt im lokalen Netz anzusprechen: Da das Gerät gerade erst auf den Markt gekommen war, gab es noch nicht viele Erfahrungsberichte in diese Richtung. Ein Blick in die Nuki App offenbarte in den Geräte-Einstellungen den Bereich „Smart Home“:

Die Matter-Integration hatte ich schon aktiviert. Damit konnte ich das Smart Lock auch über Apple Home ver- und entriegeln, aber die Tür nicht komplett öffnen („unlatch“). Also blieb nur MQTT als Integrationslösung übrig.

Update Januar 2025: Seit Anfang Dezember 2024 kann der Miniserver mit Loxone Config und App Version 15.3 selbst als MQTT Client fungieren – der Weg über Home Assistant ist also nicht mehr zwingend erforderlich. Außer, man nutzt wie ich einen Miniserver Gen 1. Der kann nämlich auch mit Version 15.3 kein MQTT, daher blieb mir nur der Weg über Home Assistant.

Die Dokumentationsseite der MQTT-Integration für Home Assistant erwähnt:

Your first step to get MQTT and Home Assistant working is to choose a broker.
The easiest option is to install the official Mosquitto Broker add-on.

Diese Option schied für mich allerdings aus, weil ich Home Assistant selbst als Docker-Container betreibe und Add-Ons in dieser Umgebung nicht verfügbar sind. Weiter heißt es:

Alternatively, you can use a different MQTT broker that you configure yourself, ensuring it is compatible with Home Assistant.

Ok, also einen weiteren Container mit Mosquitto aufsetzen und los geht’s. Die Authentifizierung zu konfigurieren war etwas hakelig, aber letztlich machbar. Dann jeweils in Home Assistant und in der Nuki App die Server- und Zugangsdaten zu Mosquitto hinterlegen, und das Türschloss erschien als Entität in Home Assistant:

Der „Unlatch“ Button konnte nun in der Loxone Config als virtueller Ausgang angelegt werden:

Zuletzt einfach den bisherigen Relay-Ausgang durch den neuen virtuellen ersetzen:

Ergebnis: Das Schloss öffnet sofort – im Falle des RFID-Readers sogar trotz der Kommunikation DoorBird → Loxone → Home Assistant → Mosquitto → Nuki noch bevor der Bestätigungston erklingt. Damit ist die User Experience endlich wie erwartet, und die Anschaffung hat sich letztlich gelohnt.

Das Aufsetzen des MQTT-Brokers hat sich ebenfalls gelohnt, denn damit kann ich nun endlich auch den Ladezustand meines Autos überwachen und zum Steuern des Ladevorgangs verwenden (siehe MG4 intelligent laden mit Loxone und Home Assistant).