Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung Nächste Überarbeitung | Vorherige Überarbeitung | ||
mqtt:start [2016/04/26 05:56] – [Wie] chaser | mqtt:start [2019/12/15 00:06] (aktuell) – updated domains raven | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== MQTT ====== | + | ====== MQTT [deprecated] |
===== Was ===== | ===== Was ===== | ||
https:// | https:// | ||
Zeile 8: | Zeile 8: | ||
MQTT hat den Vorteil das jedes Gerät nur seine eigene Funktion kennt. | MQTT hat den Vorteil das jedes Gerät nur seine eigene Funktion kennt. | ||
- | Misst ein Sensor | + | Misst ein Sensor |
Diese Nachricht wird dann von Node-Red gelesen, verarbeitet und einem entsprechende Aktion an einem Aktor (Lampe, Heizungsthermostat, | Diese Nachricht wird dann von Node-Red gelesen, verarbeitet und einem entsprechende Aktion an einem Aktor (Lampe, Heizungsthermostat, | ||
Zeile 17: | Zeile 17: | ||
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. | 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: | + | Der Aktor muss so programmiert werden das er eine entsprechende Nachricht an den Broker (mosquitto auf pizza.binary.kitchen sendet, siehe auch [[mqtt: |
Node-Red liest dann die Nachrichten, | Node-Red liest dann die Nachrichten, | ||
Ein Aktor sollte niemals direkt auf ein MQTT-Topic eines Sensors subscribed werden sondern ausschließlich auf Topics die von node-red generiert werden. | Ein Aktor sollte niemals direkt auf ein MQTT-Topic eines Sensors subscribed werden sondern ausschließlich auf Topics die von node-red generiert werden. | ||
Zeile 29: | Zeile 29: | ||
==== Nachrichtenformat ==== | ==== Nachrichtenformat ==== | ||
- | Jede Nachricht besteht aus einem Topic und einem Value | + | Jede Nachricht besteht aus einem Topic und einem Payload |
Das **Topic** muss folgendes Format erfüllen: | Das **Topic** muss folgendes Format erfüllen: | ||
Zeile 39: | Zeile 39: | ||
^ ::: | ::: | kitchen/ | ^ ::: | ::: | kitchen/ | ||
^ ::: | ::: | kitchen/ | ^ ::: | ::: | kitchen/ | ||
+ | ^ ::: | ::: | kitchen/ | ||
^ Aktor (subscriber) | ^ Aktor (subscriber) | ||
+ | ^ ::: | ::: | kitchen/ | ||
- | Der **Value** ist immer ein String hat aber keine Formats- bzw. Typenkonvention. | + | <note important> |
- | Das Parsen des Values muss in Node-Red entsprechend durchgeführt werden. | + | |
+ | Die **Payload** ist immer ein String und sollte ein Command und eine Value entsprechend folgender Tabelle enthalten: | ||
+ | ^ Message ^ Command ^ Value ^ potentielle Interpretation| | ||
+ | ^ colorchange: | ||
+ | ^ colorchange: | ||
+ | |||
+ | Command und Value müssen durch eine Raute (#) getrennt werden, Werte innerhalb der Value werden durch Doppelpunkte getrennt. | ||
+ | |||
+ | <note important> | ||
===== Abschaltung ===== | ===== Abschaltung ===== | ||
Zeile 52: | Zeile 61: | ||
===== Software ===== | ===== Software ===== | ||
+ | ==== Libraries zum entwickeln ==== | ||
+ | |||
+ | < | ||
+ | |||
==== Linux-Server ==== | ==== Linux-Server ==== | ||
- | Broker und Node-Red sind im Kitchen-Wlan unter **sushi.binary.kitchen** verfügbar. | + | Broker und Node-Red sind im Kitchen-(W)Lan |
=== Broker === | === Broker === |