TRÅDFRI im eigenem smart home – nahtlos!

Ikea hat mit den TRÅDFRI Produkten teilweise günstige und interessante Dinge im Programm. Ich habe mir mal testweise einen Bewegungsmelder, die kleine Schalterwippe und die runde 5-Knopf-Fernbedienung gekauft – für zusammen 26,-€. Da diese Sachen den Zigbee-Funkstandard verwenden, den ich bisher noch nicht verwendet habe, kam noch ein CC2531-USB-Stick mit Z-Stack Software dazu.

Als Gateway-Software habe ich mich für zigbee2mqtt entschieden. Die Übersetzung zu MQTT kommt mir im Umgang der Daten in node-red sehr entgegen.

Die folgenden Bestandteile werden verwendet:

• Docker Swarm – als Plattform
• koenkk/zigbee2mqtt:latest – Image für den Zigbee-Gateway-Dienst
• eclipse-mosquitto:latest – MQTT-Broker für die Bereitstellung der Zustände
• node-red – Flow basierte Logik zur Verarbeitung der Daten und Zustände
• ser2net – Bereitstellen der abgesetzten seriellen Schnittstelle auf einem Raspi
• CC2531-Stick – Hardware für die Zigbee-Kommunikation

Konzept

Ich habe eine Weile überlegt, wie ich die Gateway-Software am Besten integrieren kann, und trotzdem so viele Vorteile wie möglich nutzen zu können. Zum einen habe ich mit Docker Swarm eine Plattfom, die keine Zuordnung der Software zur Hardware verlangt. Zum anderen benötigt die Gateway-Software jedoch zugriff auf den CC2531-Stick. Sie sollte aber genauso gut gesichert laufen, wie der Rest.

Man könnte den Docker Container an einen Host binden, der den Stick stecken hat. Das finde ich aber entgegen der Denke des Docker Swarms.

Auf der Seite zigbee2mqtt.io sind mehrere Möglichkeiten aufgeführt, die Software zu verwenden. In einem Unterkapitel bin ich auf die Verwendung von ser2net gestoßen. Dieses Tool ermöglicht die Freigabe des seriellen Interfaces über das Netzwerk.

So konnte ich meinen Knoten entwirren:

• zigbee2mqtt läuft im Container
  • nutzt meine standard Computing Plattform mit allen Vorzügen
• ein kleiner alter Raspi mit CC2531
  • kann beliebig im Haus platziert werden
  • stellt Das Interface zum Stick über das Netzwerk bereit
  • hat keine spezifische Konfiguration, ausser Definition der Schnittstelle

Los geht’s… mit Stolpersteinchen

Bei der Inbetriebnahme von ser2net gab es einen Stolperstein. In der beschriebenen Konfiguration von zigbee2mqtt wurde nur der zu verwendene Port angegeben.

20108:raw:0:/dev/ttyACM0:115200 8DATABITS NONE 1STOPBIT

Normalerweise sollte der Dienst dann auf jedem Interface mit dem definierten Port (hier TCP20108) lauschen. Das tat er leider nicht. netstat -vatn zeigt uns was los ist:

$ netstat -vatn
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 :::20108 :::* LISTEN

Der Service erkennt wohl, dass IPv6 verfügbar ist und ignoriert IPv4. Durch Einstellen der eigenen IPv4 Adresse bewegt man den Deinst jedoch sehr leicht auch auf diesem Interface zu lauschen:

192.168.178.xx,20108:raw:0:/dev/ttyACM0:115200 8DATABITS NONE 1STOPBIT

Netstat zeigt dann die gewünschte Zeile:

netstat -vatn

 Aktive Internetverbindungen (Server und stehende Verbindungen)

 Proto Recv-Q Send-Q Local Address           Foreign Address         State

 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN

 tcp        0      0 192.168.178.xx:20108    0.0.0.0:*               LISTEN

Und zack, kann der entsprechend eingestellte zigbe2mqtt Container die Verbindung nutzen und zigbee Daten empfangen.

In der Konfiguration von zigbee2mqtt configuration.yaml müssen unbedingt de Optionen permit_join: true, der richtige eigene MQTT-Broker und natürlich der serial port, der über ser2net definiert wurde eingestellt sein:

serial:
port: 'tcp://192.168.178.xx:20108'

Hands on Devices

Ab jetzt kann das Pairen der Geräte beginnen. Dazu ist es hilfreich sich die Container-Logs von zigbee2mqtt anzuschauen. Oder direkt die Prozess-Logs, wenn die Software direkt im Host läuft.

Die Geräte der TRÅDFRI Serie haben alle einen Pairing Button, den man mindestens 10s drücken muss. Ausserdem sollte man das Gerät in unmittelbarer Nähe zum Pairing-Partner halten. Ich denke, das soll ein Stück Sicherheit bringen. Da wir erst später in node-red entscheiden, was mit den Befehlen passiert, ist das für uns aber eh unkritisch.

Sollte sich ein Gerät nicht zum Pairen bewegen lassen, kann es helfen, das Gerät einmal zurück zu setzen und einen erneuten Pairing Versuch zu starten. Dazu drück man innerhalb von 5 sec. die Pairing Taste 4x kurz. Dann wieder >10 gedrückt halten.

Ist das Gerät gepaired, kann man in den Logs jeden Tastendruck sehen und den dazugehörigen MQTT-Topic incl. Payload erfahren:

zigbee2mqtt:info 2010-07-29 16:48:42: MQTT publish: topic 'zigbee2mqtt/0xec1bbdfafe544ce9', payload '{"linkquality":2,"battery":87,"click":"off"}'

Ab jetzt können die Tastendrücke / Topics in Abhängigkeit der empfangenen Daten wie gewohnt in node-red verarbeitet werden:

Nur wenn hier eine definierte Weiterverarbeitung des Inputs geschieht, kann ein gepairtes Gerät verwendet werden, bzw. Einfluss ausüben, daher ist es eigentlich egal, ob jemand „versehentlich“ ein eigenes Gerät mit unserem Smart Home pairen will. Die Aktionen werden im Broker vielleicht noch bereitgestellt, aber niemand interessiert sich dafür.

Übrigends können über den Topic zigbee2mqtt/bridge auch Meldungen zum Pairing oder zum Status selbst abgefragt und verarbeitet werden. Sollte das Interface zum CC2531 einmal ausfallen, meldet sich zigbee2mqtt über den Topic zigbee2mqtt/bridge/state ab (offline) und wir können uns durch node-red informieren lassen, dass hier etwas nicht stimmt: