Shelly Plug S mit HomeKit-Unterstützung nachrüsten

Der Shelly Plug S unterstützt, wie andere Shelly-Geräte, von sich aus kein HomeKit. Allerdings existiert eine alternative Firmware, über welche diese Unterstützung nachgerüstet werden kann.

Der Shelly Plug S

Zur Installation muss ermittelt werden, unter welcher IP-Adresse der Shelly Plug S erreichbar ist. Diese wird im Browser aufgerufen und anschließend sollte ein Update durchgeführt werden.

Die Firmware sollte auf die aktuelle Version geflasht werden

Ist dies geschehen, kann die Installation der alternativen Firmware durchgeführt werden. Dazu wird die IP-Adresse des Shelly Plug S mit einem neuen Parameter aufgerufen:

http://192.168.1.42/ota?url=http://rojer.me/files/shelly/shelly-homekit-ShellyPlugS.zip

Es wird anschließend ein JSON ausgegeben:

{„status“:“updating“,“has_update“:false,“new_version“:“20230913-113421/v1.14.0-gcb84623″,“old_version“:“20230913-113421/v1.14.0-gcb84623″,“beta_version“:“20231107-164219/v1.14.1-rc1-g0617c15″}

Nach etwa einer bis zwei Minuten ist das Firmware-Update komplett und eine neue Oberfläche erscheint, beim Aufruf der IP-Adresse im Browser.

Die neue Oberfläche

Mit der neuen Firmware kann der Shelly Plug S als HomeKit-Gerät eingebunden werden. Dazu muss der Setup-Button in der Weboberfläche aktiviert werden. Anschließend kann das Gerät über die Home-App unter iOS hinzugefügt werden. Es ist auch möglich, die Factory-Firmware wieder aufzuspielen, sodass der Shelly Plug S wieder wie gewöhnlich genutzt werden kann.

State of Matter

Der Smarthome-Standard Matter ist gekommen, um den Markt aufzurollen. Doch wie sieht es mit der Umsetzung aus und kann der Standard seinem Versprechen gerecht werden?

Nachdem der Standard, knapp drei Jahre in der Entwicklung war, wurde er schlussendlich im November 2022 offiziell auf einem Launch-Event in Amsterdam vorgestellt.

Bereits damals kündigten viele Hersteller ihre Unterstützung an. In der sich für den Matter-Standard zuständig zeichnenden Connectivity Standards Alliance (CSA), finden sich über 500 Firmen, die unter dem Dach der Organisation vereint sind.

Darunter sind klingende Namen, wie Amazon, Apple, Google, Nordic Semiconductor, NXP Semiconductors, Samsung, Silicon Labs und viele mehr. Doch wie sieht es aus mit der Unterstützung des Standards?

Android und iOS

Matter unterstützt sogenannte Multi-Admin-Funktionalität. Dies bedeutet, dass eine Matter-Installation von unterschiedlichsten Geräten gesteuert werden kann. Für diese Steuerung wurde in unterschiedlichste Betriebssysteme mittlerweile entsprechende Unterstützung eingebaut. Diese wird meist im Rahmen der jeweiligen Smarthome-Strategie der Hersteller ausgestaltet.

So ist die Matter-Unterstützung unter iOS in die Home-App integriert. Eingeführt wurde diese Unterstützung mit der Version 16.1 von iOS. Mit diesen Updates im Oktober 2022, wurden auch andere Systeme wie watchOS mit einer Matter-Unterstützung versehen.

Unter Android wurde die Unterstützung für Matter ab Version 8.1 eingeführt, sofern die Play-Dienste ab Version 22.48.14 installiert sind. Auch hier kann das Smarthome unter Nutzung des Matter-Standards über die Home-App genutzt werden.

Smarthome-Ökosysteme

Interessant ist auch die Unterstützung der jeweiligen Home-App von Google und Apple auf dem Konkurrenzsystem. So sind die Home-Apps von Apple und Google auch auf Android respektive iOS verfügbar und unterstützen dort ebenfalls den Matter-Standard.

Andere Ökosysteme für Smarthomes sind mittlerweile ebenfalls auf den Matter-Standard angepasst. So unterstützt SmartThings von Samsung seit einiger Zeit Matter unter iOS und Android. Allerdings ist diese Unterstützung nicht komplett. So werden unter anderem Bridges, welche im Matter-Standard vorgesehen sind, durch die App noch nicht unterstützt.

Bridges dienen zur Anbindung von nicht direkt kompatiblen Systemen, an ein Matter kompatibles System. Ein solche definiert sich im Standard dadurch, dass sie ein Matter-Knoten darstellt, welcher ein oder mehrere Nicht-Matter-Geräte darstellt.

Die Alexa-App unterstützt, analog zu den anderen Systemen, seit einiger Zeit den Matter-Standard. Dies ging einher mit der Aktualisierung vieler Alexa-Echo-Geräte, insbesondere in den neuen Generationen der Gerätereihe. Mit Home Assistant verfügen Open Source-Lösungen mittlerweile auch über Unterstützung für Matter.

Border-Router und Controller

Bei Matter wird für die Kommunikation der Geräte untereinander Wi-Fi, Ethernet oder Thread benutzt; für die Kommissionierung Bluetooth LE. Näheres dazu findet sich im entsprechenden Hintergrundartikel.

Ein komplexes Matter-Netzwerk

Thread versteht sich als selbstheilendes Mesh-Netzwerk. Es ist darauf ausgelegt, Geräte miteinander zu verbinden, welche eine geringe Datenrate benötigen und möglichst wenig Energie verbrauchen sollen. Das Protokoll besticht durch sein simples Design und ermöglicht niedrige Latenzen.

Basierend auf IPv6 wird somit bei Matter ein Netz gebildet, über welches die unterschiedlichen Geräte miteinander kommunizieren. Zur Anbindung eines Thread-Netzwerks an das Matter-Ökosystem werden Border-Router benötigt, welche die Verbindung zum hauseigenen LAN herstellt.

In vielen Haushalten müssen diese allerdings nicht extra angeschafft werden, da bestehende Geräte, wie einige Smart-Speaker von Amazon, per Update zu solchen Border-Routern aktualisiert werden konnten.

Hintergrund hierfür ist, dass Thread auf IEEE 802.15.4 aufsetzt, bei welchem es sich um einen Standard für kabellose Netzwerke mit geringen Datenraten handelt. In IEEE 802.15.4 ist die Bitübertragungsschicht (Physical Layer) und die Data-Link-Schicht definiert.

Neben Thread setzt unter anderem auch ZigBee, ebenfalls ein Mesh-Protokoll, auf IEEE 802.15.4 auf, was eine Aktualisierung solcher Geräte, hin zu Thread, perspektivisch möglich macht. Damit sind viele Funkchips welche ZigBee unterstützen in der Theorie für Thread geeignet.

Apple hat die Unterstützung für Matter mit der HomePod-Version 16.1 implementiert. Auch der Apple TV kann in bestimmten Generationen als Border-Router verwendet werden. Aktuell werden der Apple TV 4K in der zweiten und dritten Generation neben dem HomePod Mini und dem HomePod in der zweiten Generation unterstützt.

Bei Amazon wurde mittlerweile eine kleine Armada an Geräten mit einer Matter-Unterstützung ausgestattet. So unterstützt der Echo der vierten Generation die Thread-Funktechnik und kann als Border-Router verwendet werden. Daneben können die Geräte Echo, Echo Plus und die Echo Dot-Serie als Matter-Controller verwendet werden. Hier wird gewöhnlich ab der zweiten und dritten Generation der Geräte eine Unterstützung geliefert.

Die eero-Router, hergestellt von einer Tochterfirma von Amazon, können als Border-Router genutzt werden. Hier findet sich eine entsprechende Unterstützung in den Modellen eero 6, eero 6+, eero Pro, eero Pro 6E und eero Pro 6.

Google verfügt über eine Reihe von Geräten, welche mittlerweile Matter unterstützen und als Border-Router genutzt werden können. So werden die Smart-Speaker Google Home, Google Home Mini, Nest Mini, Nest Audio und die Displays Nest Hub (1. Generation), Nest Hub (2. Generation) und der Nest Hub Max unterstützt. Auch der Nest Wifi Pro (Wi-Fi 6E) Router verfügt über eine entsprechende Unterstützung.

Neben den Geräten von Big Tech, finden sich in vielen Haushalten, Router der Firma AVM, namentlich die FRITZ!Box. Die neuen Modelle 5690 XGS & 5690 Pro, welche noch in diesem Jahr erscheinen sollen, verfügen neben dem von AVM bevorzugten DECT ULE auch über Unterstützung für ZigBee. Basierend auf dieser Möglichkeit, soll eine spätere Matter-Unterstützung Einzug halten. Das FRITZ!Smart Gateway soll in Zukunft ebenfalls Unterstützung für Matter erhalten.

Daneben finden sich einige andere Hersteller, welche mittlerweile entsprechende Unterstützung bzw. Border-Router liefern, namentlich der Aeotec Smart Home Hub, einige Geräte der Nanoleaf-Produktpalette und der Samsung SmartThings Hub in Version 3.

Bei anderen Geräten, wie dem Dirigera-Hub von Ikea, fehlt eine angekündigte Unterstützung immer noch.

Hardware

Doch wie sieht es bei den Herstellern der eigentlichen Smarthome-Geräte aus? Erst durch sie wird das Smarthome steuer- und erfahrbar. Neben den Konzernen Apple, Amazon und Google, welche sich in vielen Fällen mit entsprechender Software-Unterstützung und dem Bau von Border-Routern und Controllern beschäftigen, existieren auch die Firmen, welche Sensoren und Aktoren liefern.

In diesem Feld sind unter anderem Aeotec, Eve Systems, Signify und einige andere Anbieter unterwegs. Dagegen haben Hersteller, wie Belkin, ihre Unterstützung für Matter mittlerweile zurückgezogen.

Ein Sensor von Fibaro

Firmen wie Fibaro, haben sich trotz einer großen Auswahl an Smarthome-Produkten bisher nicht zu Matter geäußert. Doch wie sieht es bei den Herstellern im Einzelnen aus?

Aeotec

Aeotec, hervorgegangen aus den Aeon Labs, ist mittlerweile eine Firma mit Hauptsitz in Hamburg. Bekannt geworden ist die Firma primär durch Smarthome-Geräte, welche den Z-Wave-Standard unterstützten.

Mit dem Aeotec Smart Home Hub liefert Aeotec einen zu Matter und dem Thread-Funkstandard kompatiblen Hub. Der ZigBee-Stick, mit dem Namen Zi-Stick, soll in Zukunft, per Update, auch das Thread-Protokoll unterstützen.

Ansonsten setzen die Aktoren und Sensoren von Aeotec nicht auf Matter, sondern auf das Z-Wave-Protokoll und die entsprechende Funktechnik auf.

Eltako

Im professionellen Bereich bietet die Firma Eltako mittlerweile Matter zertifizierte Geräte an. Hier handelt es sich unter anderem um Beschattungsaktoren, ein Stromstoß-Schaltrelais und Dimmaktoren.

Damit ist es möglich, bestehende Installationen über Matter einzubinden. Neben der Matter-Integration verfügen sie unter anderem über eine REST-API, sowie eine Apple Home-Integration.

Eve Systems

Eve Systems, früher als Elgato Systems bekannt, bietet Smarthome-Geräte für unterschiedlichste Bereiche an. Mittlerweile werden von der Firma auch erste Matter-Geräte angeboten.

Der Bewegungssensor Eve Motion

Darunter fallen die schaltbare Steckdose Eve Energy, die Kontaktsenoren Eve Door & Window und der Bewegungssensor Eve Motion. Teilweise agieren die Geräte als Matter-Controller sowie als Border-Router für das Thread-Protokoll.

Die Produkte Eve Shutter Switch und Eve Flare unterstützen bereits das Thread-Protokoll und sollen mit einem späteren Update, entsprechende Matter-Unterstützung erhalten. Das Gleiche soll auch für die Produkte Eve MotionBlinds, Eve Thermo, Eve Light Switch, Eve Weather und Eve Room gelten. Für diese Geräte war eine entsprechende Unterstützung bis Ende 2022 angekündigt, wurde allerdings bisher noch nicht ausgeliefert.

Govee

Govee ist seit 2017 im Smarthome-Bereich tätig und hat unterschiedlichste Produkte wie LED-Streifen und Sensoren im Angebot. Bekannt geworden sind sie auch durch eine kurzzeitige Auslistung bei Amazon, was wohl auf das Verpackungsdesign einiger Produkte zurückzuführen war. Diese besaßen eine auffällige Ähnlichkeit mit den Philips Hue-Produkten von Signify.

Mit dem Govee RGBIC LED Strip M1 hat Govee mittlerweile sein erstes Matter fähiges Produkt auf den Markt gebracht.

Leviton

Der nordamerikanische Hersteller Leviton, ist in Europa, aufgrund seines Zuschnitts auf den amerikanischen Markt, eher weniger bekannt. Dafür liefert er in seiner Heimat entsprechende Hardware mit Matter-Unterstützung.

Zu dieser gehört ein Smart Switch, eine schaltbare Steckdose und einige Dimmer. Konkret sind dies die Geräte Smart Wi-Fi 2nd Gen D26HD Dimmer, D215S Switch, D215P Mini Plug-In Switch und der D23LP Mini Plug-In Dimmer, welche über ein entsprechendes Firmware-Update aktualisiert werden können.

Andere Geräte von Leviton, sollen in Zukunft per Update in den Genuss einer Matter-Unterstützung kommen.

Nanoleaf

Nanoleaf wurde 2012 gegründet und finanzierte erste Produkte über Kickstarter. Mittlerweile liefern sie eine Reihe von ausgefallenen Beleuchtungslösungen.

Nanoleaf stellt ungewöhnliche Beleuchtungslösungen her

Neue Produkte, wie der Essentials Matter Lightstrip und die Essentials Matter Smart Bulb, sind von Werk aus mit einer Matter-Unterstützung versehen und können in entsprechende Ökosysteme eingebunden werden.

Bestehende Produkte der Essentials-Reihe können nicht per Update auf den Matter-Standard gehoben werden, da dies seitens der Hardware nicht unterstützt wird. Ob die Produktreihen Elements, Lines und Shapes eine entsprechende Aktualisierung auf Matter erhalten ist zurzeit noch unklar. Angebunden werden diese Systeme per WLAN. Daneben arbeiten diese Geräte bereits heute als Thread-Border-Router.

Signify

Das unter der Marke Philips vertriebene Lichtsystem Hue, ist bereits seit 2012 auf dem Markt. Entwickelt und vertrieben wird es von dem mittlerweile unabhängigen Unternehmen Signify, welches früher unter dem Namen Philips Lighting firmierte.

Das System, welches auf ZigBee basiert, ist so zumindest funktechnisch unter Umständen auf Thread aktualisierbar. Die Leuchtmittel sollen allerdings nach Aussage von George Yianni, seines Zeichens Head of Technology Philips Hue bei Signify nicht auf Thread aktualisiert werden.

Hier wird seitens Signify die Strategie gefahren, nur den Hue Hub mit einer Matter-Unterstützung zu versehen. In der FAQ wird dies wie folgt beschrieben:

Alle Philips Hue Lampen und intelligentes Zubehör wie der Hue Dimmschalter und Hue Smart Button funktionieren mit Matter, wenn sie über die Philips Hue Bridge verbunden sind. Die einzigen Ausnahmen sind die Philips Hue Play HDMI-Sync Box und der Tap Dial Switch.

Auch dieses Update lässt allerdings noch auf sich warten, bzw. findet sich in einer Beta-Version, welche für Entwickler freigegeben wurde.

Der Hintergrund für diese Herangehensweise ist, dass die Hue-Bridge nicht nur als einfache Verbindung zwischen dem WLAN und den angeschlossenen ZigBee-Geräten gesehen wird, sondern als Zentrale für Abläufe und Automatisierungen.

Solche Funktionalitäten sollen nicht direkt in die Leuchtmittel eingebaut werden. Es wird befürchtet, damit die Komplexität des Systems zu erhöhen. Auch die Entscheidung, die Geräte mittelfristig nicht auf Thread umzurüsten, wird entsprechend begründet. Hier wird argumentiert, dass das entsprechende Mesh-Netzwerk über ZigBee im Laufe der Jahre produktionsreif gemacht wurde. Bei Thread steht die Befürchtung im Raum, dass hier noch viele Kinderkrankheiten und Inkompatibilitäten zu beheben sind, bis ein vergleichbarer Stand, wie mit der aktuellen Implementierung erreicht werden kann.

Mittlerweile ebenfalls zu Signify gehörend ist das ehemalige Start-up Wiz, welches auch Beleuchtungslösungen anbietet. Diese werden per WLAN angebunden und arbeiten ohne Bridge.

Bei Wiz wird Matter bei Leuchtmitteln und Smart Plugs, welche ab dem zweiten Quartal 2021 produziert worden sind, unterstützt. Die entsprechenden Updates für die meisten Bestandsgeräte sind hierbei mittlerweile erschienen.

SwitchBot

Die 2016 gegründete Firma befasst sich mit der Entwicklung von Smarthome-Geräten, wie Schlössern, Kameras und Schaltern.

Mit dem SwitchBot Hub 2 brachte sie ihr erstes Matter fähiges Produkt auf den Markt. Über diesen können andere Geräte wie SwitchBot Curtain ebenfalls per Matter angebunden werden.

Weitere Produkte sollen folgen, sind aber im Moment noch in Entwicklung. Hier sind Erscheinungstermine für das dritte und vierte Quartal 2023 anvisiert.

TP-Link

Neben Netzwerkprodukten bietet der chinesische Hersteller TP-Link mittlerweile auch eine Palette von Smarthome-Produkten an. Diese firmieren unter den Marken bzw. Unternehmen Tapo und Kasa.

Anfang des Jahres wurde mit dem Tapo P125M, einer schaltbaren Steckdose, ein Matter fähiges Produkt aus dieser Produktreihe vorgestellt.

In Zukunft sollen Matter-Updates für weitere Steckdosen, Schalter, Leuchtmittel und Thermostate erscheinen.

Tridonic

Tridonic, eine zur Zumtobel Group gehörende Firma, ist vorwiegend im professionellen Bereich bekannt. Auch hier wird an Matter-Lösungen gearbeitet, bzw. solche werden angeboten.

Die Matter-Produkte von Tridonic

Hierbei werden ein Wireless Matter Treiber, mit 24 V Konstantspannung, erhältlich in 35 W, 60 W, 100 W, 150 W, sowie ein Wireless Matter to DALI Passivmodul und ein Wireless Matter to DALI SR Modul angeboten. Über die Wireless-Module können bestehende Systeme nachgerüstet und somit Beleuchtungen Matter fähig gemacht werden.

Angebunden sind die Module per Thread. Für diese Module wurden Updates angekündigt, welche unter anderem die Änderung der Farbtemperatur möglich machen sollen, sobald dies vom Matter-Standard unterstützt wird.

Xiaomi

Unter der Marke bzw. der Tochterfirma Aqara bietet Xiaomi mittlerweile ebenfalls Matter kompatible Geräte an.

So unterstützt der Hub M2, ab der Firmware Version 4.0.0 Matter in einer Betaversion. Dabei dient dieser dann auch als Bridge, für Nicht-Matter-Geräte, wie die angeschlossenen ZigBee-Geräte. Das Update dient der Einbindung des Hubs in Matter-Umgebungen, ändert allerdings nichts am verwendeten Funkstandard im Hub selbst. Auch der Hub M1S wurde mittlerweile mit einem entsprechenden Update versehen, welches die Matter-Unterstützung im Beta-Stadium nachrüstet.

Neben diesen Hubs existieren im Portfolio von Aqara einige andere Hubs, wie der Hub E1 oder die Camera Hub-Serie. Auch diese sollen perspektivisch Updates für Matter erhalten. Angekündigt waren diese Updates für den Lauf des Jahres 2023.

Allterco

Während die Firma Allterco den wenigsten ein Begriff ist, sieht es bei der Marke Shelly anders aus. Unter dieser werden günstige Smarthome-Komponenten wie schaltbare Steckdosen, Unterputzschalter, Sensoren und einige andere Produkte angeboten.

Der Shelly Plug S

Angesteuert werden die Geräte meist per WLAN oder Bluetooth. Für die Produkte der Plus- und Pro-Reihe wurde Unterstützung für Matter für das zweite Quartal 2023 angekündigt. Allerdings wurde die Veröffentlichung zu diesem Zeitpunkt wieder abgesagt und auf die Zukunft verschoben. Damit ist unklar, wann mit ersten Matter-Geräten unter der Marke Shelly zu rechnen ist.

Bosch

Die Firma Bosch mischt beim Smarthome mit dem System Bosch Smart Home mit. Anfang des Jahres wurde angekündigt, dass das System kompatibel mit dem Matter-Standard sein wird.

So wurde mitgeteilt, dass unter anderem der Smart Home Controller II Matter unterstützen wird. Aktuell wird allerdings nur beschrieben, dass die Geräte auf den Standard vorbereitet sind. Ein kostenloses Update soll später folgen.

Ikea

Der schwedische Möbelproduzent wollte mit dem Dirigera einen Hub mit Matter-Unterstützung auf den Markt bringen. Während der Hub seit Ende 2022 erworben werden kann, sieht es mit dem entsprechenden Update bisher weniger erfreulich aus.

Dieses sollte im ersten Halbjahr des Jahres 2023 erscheinen. Andere Smarthome-Geräte aus dem IKEA-Bestand unterstützen gegenwärtig kein Matter. Auch entsprechende Ankündigungen sind bisher nicht erfolgt.

Da die IKEA Produkte auf ZigBee aufsetzen, wäre, wenn die entsprechenden Funkcontroller dies zulassen, ein Update auf Thread im Rahmen der Matter-Unterstützung denkbar.

Nuki

Die Firma Nuki ist vorwiegend für ihre Türschlösser bekannt. Die Kommunikation der Schlösser läuft über das Bluetooth Low Energy-Protokoll, welche auch über die Nuki Bridge eingebunden werden können und damit indirekt per WLAN ansteuerbar sind.

Eines der Smart Locks von Nuki

Auch wenn die Firma bisher keine Matter-Produkte anbietet, wurde bereits an ersten Prototypen gearbeitet. Eine Aktualisierung bestehender Produkte auf den Matter Standard ist hierbei nicht geplant.

Schneider Electric

Der französische Konzern Schneider Electric hat seine Pläne für Matter mittlerweile verkündet. So sollen die neuste Generation der Wiser Gateways mit Matter kompatibel sein. Dieses dient als Bridge für die angeschlossenen ZigBee-Geräte. Auch die Wiser Home-App soll in Zukunft mit einer entsprechenden Unterstützung versehen werden.

Die ersten Produkte, welche Matter unterstützen sollten, sind das Wiser Gateway und der Wiser Smart Plug. Allerdings ist dies bisher aus den Spezifikationen der Produkte nicht ersichtlich.

Shortcut Labs

Shortcut Labs, eine schwedische Firma, entwickelt und vertreibt mit Flic einen smarten Bluetooth-Taster und dem Flic Hub eine zentrale Steuerungsmöglichkeit für Smarthome-Geräte.

Zur Matter-Unterstützung hat sich Shortcut Labs vor etlichen Monaten geäußert. Diese ist für das Jahr 2023 anvisiert und soll sich auf sämtliche Produkte der Hub-Serie erstrecken. Bisher sind allerdings noch keinerlei Updates für diese Produkte verfügbar.

Weitere Hersteller

Neben den besprochenen Hersteller existieren noch andere Hersteller, welche das eine oder andere Matter fähige Produkt in ihrem Portfolio haben oder solche angekündigt haben. Zu diesen gehören unter anderem Mediola, Netatmo, Sonnof und Ubisys.

Interessant ist auch die angekündigte Unterstützung von Smart-TVs der Hersteller LG und Samsung. Diese sollen in Zukunft über Matter-Unterstützung verfügen und sich so zur Steuerung von Matter-Geräten eignen.

Fazit

Nach einigen Startschwierigkeiten, finden sich nun die ersten Hersteller, welche fertige Produkte für den neuen Standard ausliefern.

Allerdings scheint es auch, dass viele Hersteller die Komplexität von Matter unterschätzt haben und hier auf einen späteren Einstieg in den Markt hinarbeiten. Hier hat Matter bis zu einer entsprechenden Durchdringung des Marktes noch einiges vor sich.

Gemeinsam haben die Ankündigungen, dass sich die Matter-Unterstützung meist verspätet und gar ganz abgekündigt werden.

Ob hier die Komplexität, des doch recht umfangreichen Standards, unterschätzt wurde, darüber kann nur spekuliert werden. Daneben bedeutet eine Unterstützung für Matter nicht automatisch volle Kompatibilität. So wird auf den Echo-Geräten, in den ersten Iterationen, nur eine Handvoll Produktkategorien des Standards unterstützt. Namentlich sind dies Lampen, Schalter und Steckdosen.

Dies führt z. B. zu dem Problem, dass Matter-Bridges im Amazon-Kontext aktuell nicht genutzt werden können. Das Gleiche gilt für SmartThings von Samsung.

So fühlt sich der Matter-Start in vielen Fällen holprig an und kommt nur Stück für Stück voran. Es bleibt abzuwarten, ob hier in Zukunft, nachdem der Standard etabliert ist, Besserung kommt.

Die Einfachheit, welche dem Endbenutzer versprochen wurde, erstreckt sich leider nicht auf die Implementation seitens der Hersteller. Dies zeigt, wie herausfordernd es ist, einen neuen Standard in einem bereits etablierten Markt zu implementieren. Trotz der Versprechen von einfacher Handhabung und nahtloser Kompatibilität ist die Realität oft eine andere. Die Implementierung von Matter erfordert eine genaue Planung und sorgfältige Ausführung. Viele Hersteller scheinen sich noch in der Anfangsphase dieses Prozesses zu befinden.

Allerdings sollte berücksichtigt werden, dass diese anfänglichen Herausforderungen nicht unbedingt auf langfristige Probleme hindeuten. Sie könnten viel mehr als Wachstumsschmerzen betrachtet werden, die oft mit der Einführung neuer Technologien einhergehen.

Ein bedeutsamer Aspekt, der im Kontext von Smarthome-Installationen hervorgehoben werden sollte, ist die Langlebigkeit einer solchen. Sie ist nicht auf einen kurzen Zeitraum von wenigen Jahren ausgelegt, sondern soll teilweise Jahrzehnte genutzt werden. Hier muss der Matter-Standard sich ein entsprechendes Vertrauen erarbeiten und die Hersteller eine langfristige Unterstützung bereitstellen.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

MQTT unter Java nutzen

Für den Datentransfer zwischen Systemen existieren in der IT-Welt unzählige Protokolle und Verfahren. Mit MQTT existiert ein Protokoll, welches sich unter anderem für Kommunikation im IoT-Bereich gut eignet.

Zugutekommt MQTT hier, dass es unter anderem für die Nutzung über Verbindungen mit geringen Datenraten, z. B. die Nutzung über Satellitensysteme, optimiert wurde.

Neben den Grundlagen und einem Verständnis für das Protokoll, ist auch die Nutzung interessant. Aus diesem Grund soll im Rahmen dieses Artikels, eine kleine MQTT-Umgebung unter Verwendung von Java implementiert werden und mit dieser einige Konzepte und Möglichkeiten rund um MQTT dargestellt und erläutert werden.

Das große Ganze

Als Szenario für eine beispielhafte Implementation wird ein Smart-Home-System angenommen.

Die Räumlichkeiten für das Smart-Home-Szenario

In diesem Szenario existieren Räume, in diesen ein paar Lampen, einige Sensoren und Schalter. All diese Geräte kommunizieren über MQTT mit einem Broker und sind so miteinander verbunden. Auch das Steuerungssystem des Smart-Home-Systems ist per MQTT über den Broker angebunden.

Die Struktur des MQTT-Clients und des Brokers untereinander

Am Ende steuert das Smart-Home-System anhand von Eingaben, z. B. der Nutzung eines Schalters, die entsprechenden Deckenlampen.

Abgebildet werden die Geräte über die entsprechenden Topics im MQTT-Broker. Ein solches Topic könnte z. B. bad/deckenlampe sein und adressiert somit eine Nachrichtenquelle bzw. einen Empfänger.

Das Smart-Home-System abonniert einen Großteil dieser Topics und erhält damit die Daten der Geräte und kann basierend darauf neue Nachrichten an den MQTT-Broker und die entsprechende Topics verschicken.

Broker

Für MQTT zwingend notwendig ist ein Broker. Dieser bildet das zentrale Herzstück für die MQTT-Kommunikation. Er stellt Topics bereit, welche abonniert werden können und zu welchen Nachrichten gesendet werden können. Diese Funktionalitäten hören im MQTT-Kontext auf die Namen Subscribe und Publish. Jeder Client, welcher ein solches Topic abonniert, enthält anschließend die entsprechenden Nachrichten.

Alle Clients sind mit dem Broker verbunden

Auf dem Markt existieren eine Reihe von Brokern z. B. HiveMQ oder Mosquitto. Bei diesen Brokern handelt es sich meist um dedizierte Applikationen. In den meisten real existierenden Szenarien wird ein solcher zentraler Broker aufgesetzt und genutzt.

Daneben existieren auch Broker, welche direkt in eine Applikation integriert werden können, wie Mosquette; welches im beschriebenen Szenario zur Anwendung kommt.

Szenario

Als Anwendungsszenario des fiktiven MQTT-Systems soll besagtes virtuelles Smart-Home-System erstellt werden. In diesem existieren unterschiedlichste Endgeräte, welche mit dem Broker kommunizieren und entsprechende Topics abonnieren bzw. ihre Nachrichten an ein solches Topic senden.

Im Großen und Ganzen werden dazu drei kleine Projekte erstellt, ein Gerätesimulator, welcher die MQTT-Nachrichten der Sensoren und Schalter simuliert, ein MQTT-Broker und das Smart-Home-System, welches die entsprechende Steuerung vornimmt.

Broker selbst gebaut

Da es in diesem Artikel um die Einführung in die Nutzung von MQTT unter Java gehen soll, wird auf den Aufbau eines größeren Services verzichtet und stattdessen mit einem relativ minimalen Starterprojekt begonnen.

Bei diesem Projekt handelt es sich um ein minimales Java-Projekt, welches einige häufig genutzten Abhängigkeiten mitbringt und uns als Startpunkt dienen soll. Es setzt auf Java 17 auf und nutzt Maven als Build-Werkzeug und für das Paketmanagement.

Die drei Projekte sollen die Namen Broker, Devices und System tragen. Im ersten Schritt wird mit dem Broker-Projekt ein Projekt für den MQTT-Broker erstellt. Genutzt wird hierfür Moquette, welcher embedded genutzt werden kann.

Zu Beginn wird die pom.xml des Projektes um eine neue Abhängigkeit erweitert:

<!-- MQTT broker for communication -->
<dependency>
    <groupId>io.moquette</groupId>
    <artifactId>moquette-broker</artifactId>
    <version>0.16</version>
</dependency>

Diese neue Abhängigkeit wird im Dependencies-Block der Datei eingetragen. Damit wurde der Moquette-Broker eingebunden, welcher direkt im Projekt integriert ist und es uns damit ermöglicht seine Funktionalität zu nutzen.

Einbindung

Nachdem die Abhängigkeit eingebunden wurde, kann damit begonnen werden, die Broker-Funktionalität zu nutzen. Dazu wird eine Klasse namens Broker erstellt, in der der Broker mitsamt weiterer Funktionalität gekapselt wird.

Neben der Instanz der Klasse Server, für den MQTT-Broker ist das Herzstück der Klasse die Methode startServer:

public void startServer() {

    // Load class path for configuration
    IResourceLoader classpathLoader = new ClasspathResourceLoader();
    final IConfig classPathConfig = new ResourceLoaderConfig(classpathLoader);

    // Start MQTT broker
    LOG.info("Start MQTT broker...");
    List userHandlers = Collections.singletonList(new PublisherListener());

    try {
        mqttBroker.startServer(classPathConfig, userHandlers);
    } catch (IOException e) {
        LOG.error("MQTT broker start failed...");
    }

    // Publishing topics
    LOG.info("Pushing topics...");

    List lines = Resources.getLines("config/topics.conf");

    for(String line: lines) {
        pushTopic(line);
    }

    LOG.info("Topics pushed...");
}

Bei der Bereitstellung der Konfiguration wird ein InterceptHandler mit dem Namen PublisherListener definiert. Dieser verfügt über keinerlei Funktionalität für die Nutzung des Brokers, sondern dient dazu, entsprechende Meldungen über empfangende Payloads der MQTT-Nachrichten im Log des Brokers anzuzeigen:

INFO org.example.broker.mqtt.PublisherListener - Received on topic: multisensor/temperatur / Content: {"temperature":15.7,"unit":"°C"}

Anschließend wird der Broker gestartet und die Topics werden geladen und an den Broker gepusht, ergo erstellt. Hierfür dient die Methode pushTopic:

public void pushTopic(String topic) {

    LOG.info("Push topic: {}", topic);

    MqttPublishMessage message = MqttMessageBuilders.publish()
            .topicName(topic)
            .retained(true)
            .qos(MqttQoS.EXACTLY_ONCE)
            .payload(Unpooled.copiedBuffer("{}".getBytes(UTF_8))).build();

    mqttBroker.internalPublish(message, "INTRLPUB");
}

In dieser Methode wird eine MQTT-Nachricht erstellt und mit dieser Nachricht wird das entsprechende Topic über die interne Publishing-Methode an den Broker versendet.

Konfiguration für den Broker

Damit der Broker erfolgreich hochfahren kann, wird eine entsprechende Konfiguration benötigt. Eine minimale Konfiguration könnte hierbei wie folgt aussehen:

##############################################
#  Moquette configuration file. 
#
#  The syntax is equals to mosquitto.conf
# 
##############################################

port 1883

host 0.0.0.0

allow_anonymous true

Neben dem zu nutzenden Port, wird eine IP-Adresse definiert, an welche sich der Broker binden soll, sowie der anonyme Zugriff erlaubt.

Diese Konfiguration wird im Pfad src/main/resources/config des Broker-Projektes in der Datei moquette.conf hinterlegt. Im gleichen Pfad wird ebenfalls eine Datei mit dem Namen topics.conf erstellt.

Diese erhält die Topics, welche der Broker anlegen soll:

bad/deckenlampe
kueche/deckenlampe
wohnzimmer/deckenlampe
multisensor/temperatur
multisensor/bewegung
schalter1/status
schalter2/status
schalter3/status

Shutdown-Handler und Einsprungspunkt

In der main-Methode der Klasse Starter, welche unseren Einsprungspunkt für die Broker-Applikation darstellt, wird die Broker-Klasse instanziiert, der Broker gestartet und ein Shutdown-Hook definiert.

public static void main(String[] args) {

    // Init and start broker
    LOG.info("Init broker...");

    Broker broker = new Broker();
    broker.startServer();

    // Bind a shutdown hook
    LOG.info("Bind shutdown hook...");

    Runtime.getRuntime().addShutdownHook(new Thread(() -> {
        LOG.info("Stopping broker...");
        broker.stopServer();
    }));
}

Der Shutdown-Hook dient dazu, es zu ermöglichen, den Broker wieder sauber herunterzufahren. In der Konsole kann dies z. B. durch einen Druck auf die Tasten Strg + C ausgelöst werden. Damit würde der Broker entsprechend gestoppt und die Applikation beendet.

Erster Test

Damit ist der Broker im Grunde, dank der Nutzung von Moquette, fertiggestellt und kann einem ersten Test unterzogen werden.

Über MQTT Explorer wird sich mit dem Broker verbunden

Für diesen Test kann MQTT Explorer verwendet werden, um einen ersten Request per MQTT zum neuen System zu senden. Nachdem sich mit dem Broker über MQTT-Explorer verbunden wurde, können die Topics in diesem eingesehen werden.

Nach der erfolgreichen Verbindung können die Topics des Brokers eingesehen werden

Auch lassen sich über den MQTT Explorer Nachrichten an die entsprechenden Topics senden. Allerdings ist dies wenig zielführend, da im Moment, bis auf MQTT Explorer, niemand die Topics abonniert.

Gerätesimulation

Damit die Topics, welche der Broker bereitstellt bespielt werden, soll im nächsten Schritt ein Projekt aufgesetzt werden, welches dies bewerkstelligt.

Im Rahmen des Szenarios, einer Smart-Home-Umgebung, werden hierbei einige Schalter und ein Multisensor simuliert. Im Einstiegspunkt des Projektes Devices sieht, das Ganze wie folgt aus:

public static void main(String[] args) throws InterruptedException {

    LOG.info("Init Dummy device simulator...");

    // Create list of Dummy devices
    List devices = new ArrayList<>();

    devices.add(new Multisensor("multisensor/bewegung", "multisensor/temperatur"));
    devices.add(new Switch("schalter1/status"));
    devices.add(new Switch("schalter2/status"));
    devices.add(new Switch("schalter3/status"));

    while(true) {

        LOG.info("Send dummy data...");

        for(Device device: devices) {
            device.sendData();
        }

        // Sleep 15 seconds
        Thread.sleep(15000);
    }
}

Im Grunde werde einige virtuelle Geräte definiert, welche entsprechend mit ihren Topics verbunden werden und an diese Topics jeweils eine Payload senden sollen. Dies geschieht für die Simulation alle 15 Sekunden.

Schon an dieser Stelle fällt auf, dass die Schalter hier nur ein Topic benötigen, während an den Multisensor mehrere Topics übergeben werden.

Hier wird sich der hierarchische Aufbau der Topics in MQTT zunutze gemacht. Technisch wäre es kein Problem nur das Topic multisensor zu definieren und an dieses eine entsprechende Payload auszuliefern:

{
  motion: true,
  temperature: 24.6,
  unit: "°C"
}

Stattdessen werden in diesem Szenario die Topics:

multisensor/temperatur
multisensor/bewegung

definiert. Dadurch können Applikationen genau auf die Topics zugreifen, die sie interessieren. So kann ein Gerät, welches mehrere Funktionalitäten vereint, diese über separate Topics einzeln zur Verfügung stellen.

In der Praxis sollte sich das Design der Topics an den Anwendungsfällen orientieren. Werden die Daten für Bewegung und Temperatur immer in Verbindung benötigt, so könnten sie auch über ein Topic ausgeliefert werden.

MQTT-Client unter Java

Damit die virtuellen Geräte ihre Daten an den Broker senden können, wird ein entsprechender MQTT-Client benötigt. Auch hier ist die Auswahl groß.

In diesem Beispiel wird der HiveMQ-Client genutzt, da er neben dem etablierten MQTT-Protokoll in Version 3 auch die relative neue Version 5 unterstützt. Nachdem die entsprechende Abhängigkeit in der pom.xml definiert wurde:

<!-- MQTT-Client -->
<dependency>
    <groupId>com.hivemq</groupId>
    <artifactId>hivemq-mqtt-client</artifactId>
    <version>1.3.0</version>
</dependency>

kann der Client genutzt werden. Der Client unterstützt blockierende und asynchrone APIs. Im Falle der Gerätesimulationen wird auf die blockierende API mit der MQTT-Version 3 gesetzt.

Die simulierten Geräte implementieren ein Interface mit dem Namen Device, welches eine entsprechende Methode mit dem Namen sendData vorschreibt. In der Klasse, welche für Schalter zuständig ist, ist diese wie folgt implementiert:

public void sendData() {

    if (client == null) {
        // Create MQTT client
        client = Mqtt3Client.builder()
                .identifier(UUID.randomUUID().toString())
                .serverHost("localhost")
                .buildBlocking();

        client.connect();
    }

    client.publishWith()
            .topic(topic)
            .qos(MqttQos.AT_LEAST_ONCE)
            .payload(getSwitchPayload().getBytes())
            .send();
}

In der Theorie könnte der Client für alle Geräte global definiert werden, dies wird hier aber aus einer Erwägung, auf welche später noch eingegangen wird, nicht getan. Stattdessen verfügt jedes simulierte Gerät über einen einzelnen MQTT-Client.

Dieser wird beim erstmaligen Aufruf instanziiert und verbindet sich anschließend mit dem entsprechenden Server, welcher auf Localhost lauscht. Anschließend wird mit der publishWith-Methode des Clients eine Nachricht erzeugt, diese mit einem Topic und einer Quality of Service-Stufe versehen.

MQTT beherrscht drei verschiedene Stufen des Quality of Service (QoS). Stufe 0 ist vom Modell her Fire-and-Forget; die Nachricht wird einmal versendet und danach vom Broker vergessen. Ob sie ankommt, ist auf dieser QoS-Stufe nicht relevant. Bei Stufe 1 garantiert der Broker, dass die Nachricht mindestens einmal zugestellt wird, sie kann aber auch mehrfach bei den Clients ankommen. Stufe 2 hingegen garantiert, dass die Nachricht exakt einmal ankommt. Bei den QoS-Stufen muss beachtet werden, dass jede Stufe mehr Overhead erzeugt als die vorherige Stufe.

Nachdem die Payload erzeugt und übergeben wurde, wird die entsprechende Nachricht an den Broker und dort an das gewählte Topic versendet. Die Payload ist in diesem Fall eine JSON-Struktur:

{
  "enabled":false
}

In der Payload einer MQTT-Nachricht können beliebige Daten versendet werden, von Text bis zu Binärdaten. Grundsätzlich sollten hier die Limits von MQTT berücksichtigt werden, so ist die Länge eines Topics auf 64 Kilobyte beschränkt und die Länge der Payload ist auf 256 Megabyte beschränkt.

Dabei handelt sich allerdings nur um theoretische Werte, gemäß der Spezifikation, welche im jeweils gewählten Broker bzw. dessen Einstellungen abweichen könnten. Die Payload sollte hier nach der Faustregel, so viel wie nötig, so wenig wie möglich designt werden.

Die Topics werden von der Gerätesimulation befüllt

Damit ist die Gerätesimulation implementiert und die entsprechenden Topics werden nun mit sinnvollen Werten befüllt. Damit wird der Broker zwar genutzt, aber die entsprechenden Topics werden bisher nur geschrieben, niemand abonniert diese bisher.

Smart-Home-System

Im letzten Schritt soll das Smart-Home-System implementiert werden. Dieses abonniert Topics und führt basierend auf diesen Topics Aktionen durch. Während diese bei einem praxisnahen System konfigurierbar wären, sind sie in diesem Beispiel fest kodiert.

Auch in diesem Projekt wird wieder der HiveMQ-Client genutzt und entsprechend als Abhängigkeit dem Projekt hinzugefügt. Nachdem dort der Client erstellt wurde, kann die Verbindung aufgebaut werden:

client = Mqtt3Client.builder()
        .identifier(UUID.randomUUID().toString())
        .serverHost("localhost")
        .buildBlocking();

// Connect to MQTT server
client.connect();

Anschließend werden bestimmte Topics abonniert, das bedeutet, die Nachrichten der Topics werden vom Broker empfangen und sollen anschließend verarbeitet werden:

// Subscribe to topics
client.toAsync().subscribeWith()
        .topicFilter("schalter1/status")
        .qos(MqttQos.AT_LEAST_ONCE)
        .callback(Starter::switchMessageReceived)
        .send();

client.toAsync().subscribeWith()
        .topicFilter("schalter2/status")
        .qos(MqttQos.AT_LEAST_ONCE)
        .callback(Starter::switchMessageReceived)
        .send();

client.toAsync().subscribeWith()
        .topicFilter("schalter3/status")
        .qos(MqttQos.AT_LEAST_ONCE)
        .callback(Starter::switchMessageReceived)
        .send();

client.toAsync().subscribeWith()
        .topicFilter("multisensor/bewegung")
        .qos(MqttQos.AT_LEAST_ONCE)
        .callback(Starter::multisensorMotionMessageReceived)
        .send();

In diesem Fall sind es die Topics für die drei Schalter sowie das Topic für die Bewegung im Multisensor. Jedem Topic, welches abonniert wird, wird eine entsprechende Callback-Methode mitgegeben. Für den Multisensor wäre dies z. B. der Callback zur Methode multisensorMotionMessageReceived:

private static void multisensorMotionMessageReceived(Mqtt3Publish mqtt3Publish) {

    LOG.info("Receive message: {}", mqtt3Publish);

    String payload = getPayloadAsString(mqtt3Publish.getPayload().get());
    LOG.info("Payload: {}", payload);

    if (payload.length() <= 2) { // Ignore empty JSONs, from publishing topic
        return;
    }

    Motion motion = new Gson().fromJson(payload, Motion.class);

    client.publishWith()
            .topic("bad/deckenlampe")
            .qos(MqttQos.AT_LEAST_ONCE)
            .payload(getLampPayload(motion.motion).getBytes())
            .send();
}

In dieser Callback-Methode wird die Payload mittels der Methode getPayloadAsString entpackt:

private static String getPayloadAsString(ByteBuffer buffer) {
    byte[] payload = new byte[buffer.remaining()];
    buffer.get(payload);
    return new String(payload, StandardCharsets.UTF_8);
}

Hier wird der ByteBuffer genauer gesagt sein Inhalt, welcher vom Client geliefert wird, in einen String konvertiert. Anschließend wird aus der Payload über die Serialisierungs- und Deserialisierung-Bibliothek Gson, ein Java-Objekt aus der Payload erzeugt und mit diesem weitergearbeitet.

In diesem Beispiel wird der Wert des Bewegungsmelders weitergeleitet an den Topic bad/deckenlampe, um damit die Deckenlampe zu schalten.

Bei den Schaltern wird ähnlich verfahren, allerdings wird hier für alle Schalter die gleiche Callback-Methode genutzt:

private static void switchMessageReceived(Mqtt3Publish mqtt3Publish) {

    LOG.info("Receive message: {}", mqtt3Publish);

    String payload = getPayloadAsString(mqtt3Publish.getPayload().get());
    LOG.info("Payload: {}", payload);

    if (payload.length() <= 2) {// Ignore empty JSONs
        return;
    }

    Switch switchStatus = new Gson().fromJson(payload, Switch.class);

    // Define link between switch and lamp
    String targetTopic;

    switch (mqtt3Publish.getTopic().toString()) {
        case "schalter1/status" -> {
            targetTopic = "bad/deckenlampe";
        }
        case "schalter2/status" -> {
            targetTopic = "kueche/deckenlampe";
        }
        case "schalter3/status" -> {
            targetTopic = "wohnzimmer/deckenlampe";
        }
        default -> {
            LOG.info("Ignore unknown topic...");
            return;
        }
    }

    client.publishWith()
            .topic(targetTopic)
            .qos(MqttQos.AT_LEAST_ONCE)
            .payload(getLampPayload(switchStatus.enabled).getBytes())
            .send();
}

Stattdessen wird in der Methode das Topic extrahiert und anhand dieses eine Entscheidung zum passend verknüpften Zieltopic getroffen und an dieses eine neue Nachricht geschickt.

Der letzte Wille

Die Geräte, wie Schalter und der Multisensor, senden Nachrichten an den MQTT-Broker und diese Topics werden von unserem Smart-Home-System abonniert.

Nun könnte in einem beispielhaften Fall einer der Schalter die Nachricht an das Topic senden, dass der Schalter aktiviert wurde. Damit würde dann über das Smart-Home-System die entsprechende Lampe eingeschaltet werden.

Wenn dieser Schalter jedoch keine Verbindung mehr mit dem MQTT-Broker aufnehmen kann oder schlicht und ergreifend defekt ist, würde das Licht in diesem Szenario immer aktiv blieben.

Hier bietet MQTT, ein Feature, das sogenannte Testament bzw. den letzten Willen. Meldet sich ein Gerät bzw. allgemeiner ein Client beim Broker an, kann dieser ein solches Testament hinterlegen. Infolgedessen erhielten die virtuellen Geräte im Gerätesimulator jeweils ihren eigenen Client. Im Kontext der Switch-Klasse im Gerätesimulator würde dies wie folgt aussehen:

// Create MQTT client
client = Mqtt3Client.builder()
        .identifier(UUID.randomUUID().toString())
        .serverHost("localhost")

        // Last will
        .willPublish()
        .topic(topic)
        .payload(getSwitchPayload(false).getBytes())
        .applyWillPublish()

        .buildBlocking();

client.connect();

Beim Testament wird ein Topic gesetzt und eine entsprechende Payload. Im Fall des Schalters würde somit die Payload, welche signalisiert, dass der Schalter abgeschaltet wurde, an die Clients geschickt, welche das entsprechende Topic abonniert haben.

Das Testament wird hierbei nicht bei einer normalen und gewünschten Trennung der Verbindung gesendet, sondern nur im Falle einer ungewollten Trennung des Clients.

Diese kann auftreten, wenn der Broker nicht mehr mit dem Client kommunizieren kann oder die Netzwerkverbindung getrennt wird, bevor eine entsprechende DISCONNECT-Nachricht beim Broker eingetroffen ist.

Was in dem Beispielszenario eher geringere Auswirkungen hat, kann in industriellen Anwendungen von Belang sein, da hier über das Testament Geräte, im Falle von Problemen, in definierte Zustände gebracht werden können.

Jenseits von Java

Nachdem bisher alle Beispiele für das Smart-Home-System in Java umgesetzt worden sind, kann das MQTT-Protokoll auch auf vielen anderen Geräten und Sprachen genutzt werden.

So könnte z. B. eines der virtuellen Geräte mit einem Arduino nachgebaut und dort die Daten des Gerätes per MQTT an den Broker gesendet werden. Hierfür stehen für unterschiedlichste Sprachen und Umgebungen entsprechende Bibliotheken zur Verfügung.

MQTT 5

Daneben wurde die etablierte Version 3 von MQTT in diesem Beispiel genutzt, da Moquette aktuell noch an einer Umsetzung für MQTT 5 arbeitet. 2019 wurde die Spezifikation für die Version 5 von MQTT ratifiziert und sollte, wenn möglich, in neuen Projekten genutzt werden.

In die Version 5 sind Verbesserungen eingeflossen, die unter anderem für eine Verbesserung bei der Skalierbarkeit sorgen, der Erkennung der Fähigkeiten des Servers dienen, sowie Erweiterungsmechanismen im Rahmen des Protokolls beinhalten.

Sollte es sich also anbieten, sollten Projekte idealerweise mit der Unterstützung für MQTT in Version 5 begonnen werden.

Retained Messages

Auch könnte das gezeigte System um weitere Möglichkeiten von MQTT erweitert werden. Es ist es z. B. möglich vom Broker eine Nachricht zu erhalten, sobald ein Topic abonniert wird.

So könnte für den Multisensor die Temperatur als Retained Message bereitgestellt werden. Damit erhält der Client, welcher das Topic abonniert, sofort einen Status für das entsprechende Topic und muss nicht erst auf eine neue Meldung des Temperatursensors warten.

Erstellt wird eine solche zurückbehaltende Nachricht, indem bei der Erstellung der Nachricht, das Retain-Flag gesetzt wird:

client.publishWith()
        .topic(temperatureTopic)
        .retain(true)
        .qos(MqttQos.AT_LEAST_ONCE)
        .payload(getTemperaturePayload().getBytes())
        .send();

Wichtig ist es zu beachten, dass immer nur eine Retained Message pro Topic erlaubt ist und eine neue Nachricht mit dem Retain-Flag eine alte Nachricht ersetzt.

Fazit

Im Rahmen eines fiktiven Beispiels wurde ein Broker aufgesetzt und im Zusammenspiel mit virtuellen Geräten ein minimales Smart-Home-System implementiert. Damit wurde die Zusammenarbeit zwischen den Subscribern und den Publishern in einem MQTT-System gezeigt. Der Quellcode der kompletten Projekte kann über GitHub eingesehen und ausprobiert werden.

Allerdings ist MQTT nicht auf solche Anwendungsszenarien beschränkt. So kann es z. B. auch als Event-System genutzt werden, um z. B. Exporte zu triggern, welche, sobald auf dem Topic zu Einlieferung neue Daten auftauchen, diese in andere Formate exportieren und wiederum eine entsprechende Nachricht versenden.

Auch sind Sicherheitsaspekte in diesem Szenario nicht weiter bedacht. So können z. B. neue Topics von jedem Client angelegt werden. Daneben bietet MQTT noch weitere Features, welche je nach Einsatzzweck genutzt werden können. Dazu gehören persistente Sessions, welche unter anderem verhindern, dass Nachrichten verloren gehen, wenn der Client zum Zeitpunkt der Nachricht nicht mit dem Broker verbunden war.

MQTT bzw. der nachrichtenbasierende Workflow kann genutzt werden, um Systeme voneinander zu entkoppeln und bietet für zukünftige Erweiterungen Platz. Je nach Anwendungszweck sollten die Möglichkeiten von MQTT möglichst sinnvoll in eigenen Projekten genutzt werden.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

myStrom WiFi Switch ohne WPS verbinden

Wer einen WiFi Switch von myStrom sein Eigen nennt und diesen in das heimische WLAN einbinden möchte, der soll hierfür laut Anleitung WPS für eine einfache Konfiguration nutzen. Problematisch wird das Ganze, nur wenn kein WPS am Router zur Verfügung steht, oder dieses nicht genutzt werden soll.

Der WiFi Switch von myStrom

Für die manuelle Konfiguration stellt das Gerät in den Werkseinstellungen ein WiFi-Netzwerk zur Verfügung, mit welchem sich verbunden werden kann. Die SSID beginnt mit my- gefolgt von einer sechsstelligen ID. Wurde die Verbindung mit dem Gerät hergestellt, kann im Browser die IP-Adresse 192.168.254.1 aufgerufen werden.

Der Weboberfläche des Gerätes

Dort kann nun das entsprechende WiFi-Netzwerk, mit welchem das Gerät dauerhaft verbunden sein soll, eingestellt werden. Nachdem dies geschehen ist und das korrekte Passwort für das Netzwerk eingegeben wurde, startet die schaltbare Steckdose neu und verbindet sich anschließend mit dem eigentlichen WiFi-Netzwerk.

Wiki für Smart Home Hardware

FHEM ist ein freies Projekt welches sich mit einer Server-Lösung auf Perl-Basis zur Verwaltung und Steuerung eines Smart Home beschäftigt. Ich persönlich bevorzuge für diesen Zweck die Lösung Home Assistant. Trotzdem ist neben dem eigentlichen Projekt die FHEM Wiki sehr interessant.

Die FHEM Wiki

Dort findet man neben den eigentlichen Informationen über FHEM, viele Informationen rund um Smart Home Hardware, wie z.B. verschiedenen Aktoren und Sensoren. Die Inhalte der Wiki sind unter der GNU Free Documentation License lizenziert. Entdeckt werden kann die Wiki unter wiki.fhem.de, das zugrundeliegende Projekt ist auf fhem.de zu finden.