Funkprotokolle

Hardware, Node-RED

Ein gravierender Vorteil von Open-Source Smarthome-Projekten wie HomeAssistant, OpenHAB, fhem oder eben Node-RED ist die Freiheit bei der Auswahl der verwendeten Protokolle. Man ist nicht auf die Auswahl des Herstellers beschränkt (der seine Unterstützung zudem womöglich irgendwann einstellt), sondern kann sehr viele (Funk-)Protokolle benutzen und hat damit eine größere Auswahl an Geräten, die ins Smarthome eingebunden werden können.

Als kommerzielle Alternativen sind auch der Brain Cube von homee erwähnenswert, der neben dem standardmäßigen WLAN über zusätzliche Würfel weitere Protokolle einbinden kann: EnOcean Cube, Z-Wave Cube und/oder Zigbee Cube. Oder auch Homey, das (mit der Homey Bridge) alle hier beschriebenen Protokolle einbinden kann.

Ich selbst nutze mit Node-RED:

WLAN wird vor allem für Steckdosen oder Leuchtmittel genutzt, die eh am Stromnetz hängen. WLAN ist im Vergleich zu den anderen Protokollen stromhungriger, was eher gegen einen Batteriebetrieb spricht. Shelly hat allerdings einige Sensoren im Portfolio, die ihre Statusmeldungen per WLAN absetzen. Allerdings sind diese Sensoren nicht ständig über ihre IP-Adresse per Browser erreichbar, um Strom zu sparen, sondern aktivieren WLAN nur beim Versenden von Statusänderungen.

Für Node-RED empfehle ich smarte Steckdosen, die bereits mit Tasmota geflasht sind, z.B. die Nous A1T.

Hier gibt es Lampen, Thermostate, Schalter, Temperatur- und Kontaktsensoren, viele davon mit Batteriespeisung, deren Batterien auch wirklich lange halten. Ein Mesh-Netzwerk wird mit Hilfe der (meisten) Geräte mit externer Stromversorgung aufgebaut. Deshalb macht es Sinn, Leuchtmittel mit Zigbee Protokoll (wie die Birnen von Ikea) gut verteilt im Haus zu platzieren. Ein Zigbee-Gateway von Philips (Hue-Bridge) oder Ikea wird nicht benötigt, wenn ein Zigbee-Stick zusammen mit Zigbee2MQTT eingesetzt wird. Weitere Infos zu Zigbee siehe mein Glossar zu Zigbee.

Bisher habe ich einen Fenstergriff zum Testen der Einbindung dieser Technologie in Node-RED im Einsatz. Wie bei vielen EnOcean-Produkten funktioniert die Übermittlung der Statusmeldungen ganz ohne Stromversorgung, nur mit Hilfe der kinetischen Energie, die beim Drehen des Griffs entsteht.

Besitzer einer AVM Fritzbox, die auch Schnurlostelefone verwalten kann, können auch Heizkörper-Thermostate oder smarte Steckdosen mit dem DECT Protokoll steuern. Diese Steuerung kann über eine geeignete Erweiterung auch aus Node-RED heraus erfolgen.

Seit über 50 Jahren gibt es für die Fernsteuerung von Fernseh- und Hifi-Geräten Infrarot-Fernbedienungen, für die eine Sichtverbindung zwischen Sender und Empfänger erforderlich ist. Dies schränkt zwar die Nutzung erheblich ein, aber es gibt IR-Sender/Empfänger-Boxen von Athom, die bereits mit Tasmota geflasht sind, mit deren Hilfe man sowohl Fernbedienungen auslesen und damit Smarthome-Aktionen per IR-Fernbedienung anstoßen kann, als auch bestehende Fernbedienungen simulieren und somit Geräte statt über die Fernbedienung per Smarthome ansteuern kann.

LoRaWAN ist ein Funkprotokoll, das auf minimale Datenpakete über maximale Entfernungen spezialisiert ist. Laut Wikipedia Eintrag: „Es ist asymmetrisch und auf Energieeffizienz für Reichweiten über 10 km für die Uplink-Kommunikation (also das Senden vom Endgerät an das Netz) ausgerichtet. Die Datenübertragungsrate reicht von 292 bit/s bis 50 kbit/s.“ Damit bietet es sich für drahtlose Sensoren und Tracker (Ortungsgeräte) an, wird aber hauptsächlich im Profibereich bzw. in Kommunen (SmartCity) genutzt.

Ich habe einen SenseCAP M1 (Raspberry Pi 4 mit LoraWAN-Modul in einem ansprechenden Metallgehäuse), der ursprünglich im Helium-Netzwerk eingebunden war, mit Hilfe eines Artikels aus der c’t 27/2023 (dürfte hinter einer Paywall liegen) in The Things Network gezogen.

Dazu habe ich mir den TrackerD von Dragino gekauft und kann zumindest dessen Alarmmeldung aus dem Things Network in Node-RED auslesen. Die Bestätigung, dass ich den Alarm vom Tracker empfangen habe, kann ich jedoch noch nicht zurück an den Tracker schicken.

Möglich wären noch:

Auch hier gibt es ähnlich wie bei Zigbee Mesh-Strukturen für eine gute Netzabdeckung. Mich hat allerdings die Auswahl an verfügbaren Geräten nicht überzeugt.

Fehlende Mesh-Funktionalität und geringe Reichweite sprechen gegen den Einsatz von Bluetooth. Als zusätzliches Protokoll ist es aber interessant, z.B. als Anwesenheitserkennung durch Verbindung mit Smartphones, die zuvor gepairt wurden oder für die Erkennung von Beacons wie AppleAirtags oder Tiles. Dazu teste ich gerade das Projekt OpenMQTTGateway.

Schreibe einen Kommentar