Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung Nächste Überarbeitung | Vorherige ÜberarbeitungLetzte ÜberarbeitungBeide Seiten, nächste Überarbeitung | ||
mqtt:start [2016/04/25 12:29] – [Linux-Server] chaser | mqtt:start [2016/05/11 16:04] – [Libraries zum entwickeln] chaser | ||
---|---|---|---|
Zeile 14: | Zeile 14: | ||
===== Wie ===== | ===== Wie ===== | ||
- | <hier node-red einfügen> | + | <hier node-red |
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 **Nachrichtenformat**) | + | Der Aktor muss so programmiert werden das er eine entsprechende Nachricht an den Broker (mosquitto auf sushi.binary.kitchen sendet, siehe auch [[mqtt: |
+ | 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. | ||
FIXME - Ausführlicheres Node-Red Howto | FIXME - Ausführlicheres Node-Red Howto | ||
+ | |||
+ | ===== Sicherheit ===== | ||
+ | |||
+ | FIXME - TLS/Auth etc. | ||
===== Konventionen ===== | ===== Konventionen ===== | ||
==== 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: | ||
^ Typ ^ Topic ^ Beispiel | | ^ Typ ^ Topic ^ Beispiel | | ||
- | ^ Sensor | kitchen/< | + | ^ Sensor |
^ ::: | ::: | kitchen/ | ^ ::: | ::: | kitchen/ | ||
^ ::: | ::: | kitchen/ | ^ ::: | ::: | kitchen/ | ||
^ ::: | ::: | kitchen/ | ^ ::: | ::: | kitchen/ | ||
^ ::: | ::: | kitchen/ | ^ ::: | ::: | kitchen/ | ||
- | ^ Aktor | kitchen/< | + | ^ ::: | ::: | kitchen/ |
+ | ^ 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 46: | 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 === | ||
Zeile 67: | Zeile 86: | ||
Doebis pubsubclient https:// | Doebis pubsubclient https:// | ||
+ | |||
+ | Boilerplate: | ||
=== Linux === | === Linux === | ||
Zeile 75: | Zeile 96: | ||
Ich gehe nicht davon aus das irgendjemand im Kitchen jemals Hardware auf Basis von Windows IoT Core bauen wird. Falls doch => FIXME | Ich gehe nicht davon aus das irgendjemand im Kitchen jemals Hardware auf Basis von Windows IoT Core bauen wird. Falls doch => FIXME | ||
- | |||
- | |||