Inhaltsverzeichnis
MQTT [deprecated]
Was
Warum
Aktuell kennt jedes unserer selbstgebauten Hardwareprojekte seine eigene Funktion und die Funktion seines gegenübers. Das ist zwar funktional erfordert aber, bei jeder Änderung das entsprechende Gerät mit einer neuen Firmware zu versorgen was das ganze System unflexibel macht.
MQTT hat den Vorteil das jedes Gerät nur seine eigene Funktion kennt. Misst ein Sensor (Schalter, Temperatursensor, Fenstersensor, Türschloss etc.) ein Event setzt dieser nur eine entsprechende Nachricht auf dem Broker (mosquitto auf pizza.binary.kitchen) ab.
Diese Nachricht wird dann von Node-Red gelesen, verarbeitet und einem entsprechende Aktion an einem Aktor (Lampe, Heizungsthermostat, Web-API, Twitter etc.) ausgelöst.
Wie
<hier node-red screenshot einfügen>
Ein einfaches System besteht aus einem Senor und einem Aktor (es können aber theoretisch beliebig viele Sensoren mit beliebig vielen Aktoren verknüpft werden. Der Aktor muss so programmiert werden das er eine entsprechende Nachricht an den Broker (mosquitto auf pizza.binary.kitchen sendet, siehe auch Nachrichtenformat). Node-Red liest dann die Nachrichten, bereitet sie auf (manipulation per Javascript ist möglich), erstellt daraus eine neue MQTT-Nachricht (unter einem Topic auf das der Aktor subscribed und löst damit die entsprechende Reaktion am Aktor aus) oder triggert eine Web-Api etc. Ein Aktor sollte niemals direkt auf ein MQTT-Topic eines Sensors subscribed werden sondern ausschließlich auf Topics die von node-red generiert werden.
- Ausführlicheres Node-Red Howto
Sicherheit
- TLS/Auth etc.
Konventionen
Nachrichtenformat
Jede Nachricht besteht aus einem Topic und einem Payload
Das Topic muss folgendes Format erfüllen:
| Typ | Topic | Beispiel |
|---|---|---|
| Sensor (publisher) | kitchen/<type>/<location>/<mac> | kitchen/switches/cellar/00:0a:95:9d:68:16 |
| kitchen/switches/portable/00:0a:95:9d:68:16 | ||
| kitchen/temperaturesensor/toilet/00:0a:95:9d:68:16 | ||
| kitchen/lock/frontdoor/00:0a:95:9d:68:16 | ||
| kitchen/windowstatus/cellar/00:0a:95:9d:68:16 | ||
| kitchen/switches/android/00:0a:95:9d:68:16 | ||
| Aktor (subscriber) | kitchen/<type>/<location><mac> | kitchen/heating/kitchen/00:0a:95:9d:68:16 |
| kitchen/notificator/android/00:0a:95:9d:68:16 |
Die Payload ist immer ein String und sollte ein Command und eine Value entsprechend folgender Tabelle enthalten:
| Message | Command | Value | potentielle Interpretation |
|---|---|---|---|
| colorchange:lamp1#FFFFFF | colorchange | lamp1#FFFFFF | Schaltet Lampe 1 auf Weiss |
| colorchange:lamp2#000000 | colorchange | lamp2#000000 | Schaltet Lampe 2 aus |
Command und Value müssen durch eine Raute (#) getrennt werden, Werte innerhalb der Value werden durch Doppelpunkte getrennt.
Abschaltung
Jeder Aktor muss ich am Broker (unabhängig von Node-Red) für das Topic kitchen/shutdown subscriben. Dieses Topic enthält keinen Value. Die Aktoren müssen intern entsprechend auf dieses Event reagieren. Das Topic dient dazu um beim Ausfall von Node-Red oder beim Abschließen des Kitchen die Möglichkeit zu haben die Aktoren sauber abzuschalten bzw. Herunterzufahren.
Software
Libraries zum entwickeln
Linux-Server
Broker und Node-Red sind im Kitchen-(W)Lan unter pizza.binary.kitchen verfügbar.
Broker
http://mosquitto.org/ (lässt sich über die meisten Packagemanager installieren Default-Port: 1883)
Noder-Red
http://nodered.org/ (Installation über npm, Default http-Port: 1880)
Client
Android / ESP8266 / Node-MCU
Doebis pubsubclient https://github.com/doebi/pubsubclient
Boilerplate: Arduino Code für rudimentären Client: - Auf GitHub veröffentlichen
Linux
Für die meisten Distributionen: mosquitto-clients
Windows
Ich gehe nicht davon aus das irgendjemand im Kitchen jemals Hardware auf Basis von Windows IoT Core bauen wird. Falls doch ⇒