✎ mqtt:start [Binary Kitchen]

Eine ältere Version des Dokuments wurde geladen! Beim Speichern wird eine neue Version des Dokuments mit diesem Inhalt erstellt.

====== MQTT ======
===== Was =====
https://de.wikipedia.org/wiki/MQ_Telemetry_Transport
===== 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 sushi.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 =====

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 sushi.binary.kitchen sendet, siehe auch [[mqtt:start#nachrichtenformat|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.

FIXME - Ausführlicheres Node-Red Howto
=====  Konventionen ===== 
==== Nachrichtenformat ====

Jede Nachricht besteht aus einem Topic und einem Value

Das **Topic** muss folgendes Format erfüllen:

^ Typ ^ Topic ^ Beispiel |
^ Sensor | 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 |
^ Aktor  | kitchen/<type>/<location><mac> | kitchen/heating/kitchen/00:0a:95:9d:68:16 |

Der **Value** ist immer ein String hat aber keine Formats- bzw. Typenkonvention.
Das Parsen des Values muss in Node-Red entsprechend durchgeführt werden.

=====  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 =====

==== Linux-Server ====

Broker und Node-Red sind im Kitchen-Wlan unter **sushi.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

=== 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 => FIXME

What's the answer to life, the universe and everything? Dieses Feld bitte leer lassen:

Zusammenfassung