Node-RED: Der Neustart
Nachdem ich mein ersten begeisterten Node-RED Gehversuche wieder eingestellt hatte, da die FRITZ!Box wohl nicht so viel Spaß an den ständigen Abfragen des Node-RED-Servers hatte, habe ich nun eine komplett neue Flow-Konfiguration aufgesetzt. Wieso es damals nicht so rund lief, weiß ich bis heute nicht. Entweder habe ich zu viele Abfragen gemacht, oder es lag an der Labor-Version der 6591. Zumindest habe ich bei laufendem Node-RED Server min. einen bis zu stündlichen Hänger/Reboot am Tag von der Box gehabt.
Jetzt ist ja aber einige Zeit vergangen, es gibt eine neuere Node-RED-Version und auch bei der Firmware der Box sind wir weiter vorangeschritten.
Ich habe also angefangen, einige Hue-Stecker und Bewegungssensoren einzubinden und abhängig davon etwas zu schalten. Das lieft nun einige Wochen sehr stabil, so dass ich nach und nach mehr nodes/flows angelegt habe. Dann hat mich wieder das Fieber gepackt und ich habe alles eingebunden, was ich hier an IoT in der Wohnung habe, nur die FRITZ!Box ist dieses mal außen vor.
Hier eine Auflistung welche Nodes ich verwende und wofür:
| Node | Verwendung | Quelle |
|---|---|---|
| node-red-contrib-aedes | MQTT-Server direkt in Node-RED ohne extra Server Installation. | https://flows.nodered.org/node/node-red-contrib-aedes |
| node-red-contrib-state | Sichern einiger Werte, um späteren Auslesen für Alexa-Status-Infos und um an Werte zu kommen, die nur gepushed werden und nicht online abgefragt werden können. | https://flows.nodered.org/node/node-red-contrib-state |
| node-red-contrib-alexa-remote2 | Zur Sprachausgabe an Alexa und um auf Routinen zu reagieren. | https://flows.nodered.org/node/node-red-contrib-alexa-remote2 |
| node-red-contrib-combine | Einige Tools um Differenzen zu ermitteln oder Nachrichten auf Basis von Schwellwerten (z.B. Temperaturschwankungen) weiterzuleiten. | https://flows.nodered.org/node/node-red-contrib-combine |
| node-red-contrib-huemagic | Hue Steuerung mit sehr vielen Möglichkeiten. | https://flows.nodered.org/node/node-red-contrib-huemagic |
| node-red-contrib-lametric-notification | Texte an die Lametric-Laufschrift-Uhr senden. | https://flows.nodered.org/node/node-red-contrib-lametric-notification |
| node-red-contrib-sun-position | Timestamps umwandeln und Trigger starten anhand von bestimmten Tagesereignissen sowie Nachrichten nur zu bestimmen Zeiten durchleiten. | https://flows.nodered.org/node/node-red-contrib-sun-position |
| node-red-contrib-netatmo | API-Abfragen an Netatmo Geräte. | https://flows.nodered.org/node/node-red-contrib-netatmo |
| node-red-node-tail | Neue Zeilen in meinem ohnehin durchgeführten Speedtest-Log abzufragen und im Dashboard das Ergebnis anzuzeigen. | https://flows.nodered.org/node/node-red-node-tail |
| node-red-node-rbe | Nachrichten nur einmal Triggern bei Änderungen. | https://flows.nodered.org/node/node-red-node-rbe |
| node-red-dashboard | Das Node-RED Dashboard zur Anzeige einer Webseite mit den gesammelten Infos. | https://flows.nodered.org/node/node-red-dashboard |
| ycardon/gigaset-elements-proxy | Eigentlich kein Node-RED Node sondern ein Proxy für die Gigaset-Elements-API die den Status und Änderungen der Elements-Module per MQTT publiziert. Ein super Projekt! | https://github.com/ycardon/gigaset-elements-proxy |
| node-sonos-http-api | Auch das ist kein Node-RED Node aber funktioniert ähnlich wie der Gigasetproxy. Man kann via lokalen HTTP-Requests die API der Sonos-Boxen steuern. Quasi eine SOAP-API-SONOS to REST-API Konvertierung. | https://github.com/jishi/node-sonos-http-api |
Das Nuki-Schloss und den Opener frage ich über die lokale API der Bridge ab. Dazu habe ich einen CallBack in der Bridge hinterlegt, der bei Events einen WebService in node-RED aufruft. Das JSON wird in dem Flow als Status gespeichert und für Trigger via MQTT publiziert. So kann ich auf Statusänderungen sofort reagieren und auch später den letzten Stand abfragen, ohne nochmal die API zu triggern. Beim ersten Start (Deployment) wird einmal die API abgefragt, um den ist Zustand zu bekommen, danach werden nur Änderungen gepushed. Da ich inzwischen mitbekommen habe, dass die Bridge sich auch mal Aufhängen kann, habe ich einen Restart Trigger eingebaut, der dann startet, wenn die Callbackmeldung die jeden Tag zu einer bestimmten Zeit gesendet wird, nach 5 Minuten noch nicht erkannt wurde. Dann wird die Bridge neu gestartet, ich bekomme eine Mail und nach 1 Minute wird dann nochmal der Init-Trigger gestartet um den ist Zustand abzufragen.
So und der Rest wird nun in einem Video erklärt und gezeigt:
Da die Nodes schon recht speziell auf meinen Workflow angepasst sind, spare ich mir hier mal alle Flows zu posten. Bei speziellen Fragen kann ich das ggf. individuell beantworten. Aber da ich auch noch in der Anpassungs–/Optimierungsphase bin, würde es ja ziemlich schnell nicht mehr aktuell sein. Z.B. ist der oben beschriebene Bridge-Restart auch erst nach dem Video dazu gekommen, weshalb ich den hier beschrieben habe.