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