Um Daten aus dem SmartHome auf eine eigene Website zu bringen, habe ich mir eine Authentifizierung gebaut, die es mir erlaubt, per POST Request Daten bereitzustellen – und zwar nur mir. Einfach nur ein festes Passwort war mir da zu unsicher. Daher habe ich eine zeitbasierte Komponente mit eingebaut.
Beim Token habe ich mich für eine Gültigkeit von 10 Sekunden (daher geteilt durch 10.000) entschieden, dann sind minimale Ungenauigkeiten bei den Uhrzeiten zwischen SmartHome und Webserver nicht so dramatisch. Der Payload wird dann durch die hash-Funktion sha256 gehasht. Anschließend wird der POST Request mit Daten bepackt und der http request abgeschickt.
Um dem POST Request zu empfangen und zu authentifizieren muss die PHP Gegenstelle den gleichen Token generieren und mit dem mitgeschickten Token abgleichen. Dazu braucht die Gegenstelle natürlich auch den auf 10 Sekunden gerundeten Timestamp und das gleiche geheime Passwort, wie es im Node-RED hinterlegt ist.
Ich schätze Flot als schlankes Tool um ansehnliche Diagramme zu zeichnen. Diese binde ich per iframe in Node-RED Dashboard ein. Bisher war es mir jedoch nicht gelungen, die Daten abseits der Glättung zu aggregieren und die Eingangsdaten-Arten min, max und mittel zu nutzen. Dabei ist es eigentlich einfach und logisch. Im Reiter „Zeit“ muss nur unter „Aggregation“ der Schritttyp auf Sekunden und die Sekunden entsprechend angepasst werden. Für eine tageweise Aggregation zum Beispiel 86400.
Neben SmartHome Themen, gibt es jetzt vielleicht ab und zu auch ein paar Beiträge zu Nextcloud, zum Beispiel diesen Tipp.
Bei meinem Sohn ging die CalDAV-Synchronisation via DAVx5 nicht mehr. Die App warf immer einen Error 500 (PUT /remote.php/dav/calendars/ […]) aus. Alle anderen Nutzer und Kalender hatten diesen Problem nicht, sodass ein generelles Problem ausgeschlossen werden konnte.
Nach einigem hin und her, konnte das Problem auf einen defekten Serientermin eingegrenzt werden. Nach Löschen & Neuanlegen der Serientermine ging es wieder.
Jetzt mit Details zu Dashboard-Ausgabe, inkl. Vorhersage-Chart.
Wetterdaten fürs SmartHome
Rund ums Wetter sammle ich mir eine Vielzahl an Daten aus verschiedenen Quellen. Die Wettervorhersage beziehe ich vom Norwegischen Wetterdienst yr.no, Live-Wetterdaten erhebe ich selbst oder hole sie mir über openSenseMap und Weather.com (Weather Underground) von Wetterstationen aus der Nachbarschaft. Wetterwarnungen kommen vom DWD und ein schickes Niederschlagsradar vom Wetterdienst eines (ehemals) bekannten Wetter-Moderators.
Vorgeschichte
Bisher habe ich für die Wettervorhersage via yr.no den ioBroker-Adapter genutzt. Doch seit der Umstellung der API von xml auf json ist die Anzahl der verfügbaren Werte und damit auch die Anzahl der ioBroker-Objekte explodiert – vieles davon ohne Mehrwert für mich. Dies war mir ein Dorn im Auge, versuche ich doch die Anzahl der Schreibvorgänge auf die SD-Karte klein zu halten.
Also wollte ich die API von yr.no/met.no selbst anzapfen, mit Node-RED ja kein Problem.
So mach ich es
Wenn man die API-Dokumentation aufmerksamer ließt als ich, kann man das ganze recht schnell durchschauen. (Ich brauchte dementsprechend eine Weile.) Man hat die Wahl zwischen dem classic, compact und complete Bericht. Mich interessieren die Temperaturen, die Wetterlage und die erwarteten Niederschlagsmengen. Diese bekomme ich im complete-Bericht.
Man benötigt seine Position als lat/lon. Google Maps verrät beim Rechtsklick auf jeden beliebigen Punkt der Erde die entsprechenden Werte, der erste ist dabei der Breitengrad (lat), der zweite der Längengrad (lon). Ergänzen kann man noch die Höhe über Meeresspiegel – dies ist jedoch optional.
Es ist nötig, einen eigenen User-Agent als Identifikation bei der Anfrage mitzusenden, sonst bekommt man einen Fehler „403 Forbidden“. Hier kann man beliebig kreativ sein. Das setzen des Headers geht ganz einfach mit einem Function-Node vor dem HTTP-Request-Node:
Wenn man alles richtig gemacht hat, erhält man als Rückgabe einen wirklich umfangreichen JSON-Datensatz. Dieser enthält Vorhersagedaten für die nächsten 9 Tage. Mich interessieren tatsächlich nur die nächsten 48 Stunden. Auf weiterreichende Wetterentwicklung reagieren meine Flows nicht, und ich habe nicht den Elan, ein allzu umfangreiches Wetter-Dashboard zu bauen. Außerdem ist mir eine weitere Vorhersage eh zu sehr Wahrsagerei.
Die Auswahl der Daten
Da man die API nicht zu oft abfragen darf (und auch nicht will), sollte man die Vorhersagedaten bis zum nächsten API-Abruf zwischenspeichern. Dazu muss man sich überlegen, welche Daten man benötigt.
Beim Stöbern im JSON-Datensatz bin ich darauf gekommen, dass die interessantesten Daten für mich im Bereich der „next_6_hours“ stecken. Sowohl der Symbolcode (= die Wetterlage), als auch die Min-/Max-Temperaturen und die Niederschlagsmenge werden für diese Zeit-Korridore mitgeliefert – und das anfangs stündlich.
(Nicht verwirren lassen! Alle Zeitangaben sind in UTC)
Die Logik dabei ist:
Zum Zeitpunkt 30.08.2021 17:00 Uhr schaue ich mit „next_6_hours“ auf den Zeitraum zwischen 17:00 und 23:00 Uhr. Auch für den Zeitpunkt 30.08.2021 18:00 Uhr gibt es die „next_6_hours“, welche sich dann auf den Zeitraum 18:00 bis 0:00 Uhr beziehen.
Auf Kosten der Genauigkeit (die bei einer Vorhersage eh relativ ist) und zugunsten der Datensparsamkeit speichere und verarbeite ich also nur jeden sechsten Datensatz bis 42 Stunden in die Zukunft (+6 hours ergibt die 48 Stunden die ich betrachten möchte).
Für diese acht Datensätze (8*6=48 Stunden) habe ich acht Objekte im ioBroker angelegt (bei mir n0, n6, n12, n18, …), in welche ich die inzwischen von JSON in ein JavaScript Objekt konvertierten Daten der „next_6_hours“ als Objekt abspeichere.
Datenaufbereitung
Vor dem Speichern bereite ich die Daten noch ein wenig auf. Ich ordne den Symbolcodes zusätzlich die deutschen Bezeichnungen der Wetterlage zu, ergänze den Wochentag und bereite die Zeit auf, indem ich den Zeitraum errechne, für den diese Werte eine Gültigkeit haben (z.B. Dienstag, 06 – 12 Uhr). Zudem wird der Timestamp des Gültigkeitsstarts errechnet und mit abgelegt.
Nutzung der Wetterdaten
In definierten Regeln
Meine Vorhersage-Objekte (n0 – n42) sind immer aktuell, da ich die Wetterdaten einmal die Stunde abrufe. Somit weiß ich immer, im welchen Objekt welche Zeiträume stecken. Je nachdem wann ein Flow das Wetter abfragt, muss ich also nur den entsprechenden Betrachtungszeitraum festlegen.
Schaut die Rollo-Steuerung zum Beispiel um 9 Uhr, ob sie die südlichen Fenster abschatten sollte, dann schaut sie u.a. nach den Höchstwerten von „n0“, also wie warm es maximal zwischen 9 und 15 Uhr wird. Soll das Haus am Abend Bescheid sagen, dass die Fenster dank kühler Abendluft endlich geöffnet werden können, dann schaut es erst, wie warm es am nächsten und übernächsten Tag wird („n18“, „n42“).
Im Dashboard / UI
Natürlich schauen nicht nur automatische Steuerungen nach dem Wetter – ich gebe die Vorhersage auch im Dashboard aus. Neben der noch ausbaubaren tabellarischen Aufbereitung habe ich dafür inzwischen auch ein Temperatur-Vorhersage Chart.
Da ich die Daten direkt als JavaScript Objekt in das ioBroker Objekt abspeichere, kann ich auch direkt nach dem Auslesen des Objekts auf die Werte zugreifen.
msg.payload.details.air_temperature_max
Die tabellarische Ausgabe basiert somit auf einfachen Abfragen und Textausgaben, da alle Daten ja schon passend aufbereitet wurden.
Die entsprechenden ui_text – Nodes, welche durch CSS Klassen etwas gestaltet werden:
Für das Temperatur-Vorhersage-Diagramm müssen alle Objekte (iobroker list Node) geladen und daraus die passende Chart-JSON generiert werden. (siehe Flow Download)
Beispielhafte JSON zur Befüllung eines Node-RED Dashboard Charts
Da der abzubildende Zeitraum in der Zukunft liegt, können die Werte nicht anhand eines timestamps verortert werden, sondern brauchen feste Bezeichnungen. Hierbei habe ich mich für die Mitte des sechs Stunden Zeitraums entschieden.
Flows als Download
Wer es ausprobieren möchte, braucht im ioBroker unter 0_userdata.0.Vorhersage entsprechende Objekte und kann nach dem Import des folgenden Flows direkt loslegen.
Genau wie es Murphys Gesetz verlangt, müssen technische Probleme mit dem Smart Home natürlich im Urlaub auftreten – dann, wenn man auf Automatiken und Überwachung eigentlich besonders Wert legt und die Reparaturmöglichkeiten begrenzt sind.
2019
Schon vor zwei Jahren hatte ich den Fall, dass nach der Hälfte des Urlaubs mein Smart Home nicht mehr erreichbar war. Weder die Weboberflächen von ioBroker und nodered noch das SSH des Raspberry Pi waren erreichbar und ich hatte damals keine Möglichkeit, den Pi neuzustarten. Seitdem hängt der Raspberry Pi an einer WLAN Steckdose, sodass ich diesen zur Not stromlos machen kann, um ihn hart neuzustarten. Der Status wird zudem inzwischen von einem zweiten Raspberry Pi überwacht, welcher nach einer gewissen Spanne der Unerreichbarkeit den Neustart auch selbst einleiten kann. (auf diesem läuft auch ein Node-RED, allerdings ohne iobroker)
Um dabei keine Probleme zu erzeugen, sollte die Konfiguration des Raspberry Pi und die Programmierung im Node-RED natürlich bootfest sein.
2021
Dieses Jahr begann es mit einem Shelly 2.5 zur Rolladensteuerung, der einfach Ausstieg und nicht mehr ansprechbar war. Mein integriertes Meldungssystem schickte brav die Fehlermeldung, dass beim Fahren des Rollos ein Fehler aufgetreten sei. Was genau mit dem Shelly los ist, muss ich noch untersuchen. Das Relais klackert ununterbrochen, wenn der Shelly am Netz ist.
Nach gut einer Woche kam es dann dazu, dass der schon vermutete langsame Tod der SD-Karte des Raspberry Pi unübersehbar wurde. Das Betriebssystem lief noch, doch der ioBroker wollte nicht mehr starten.
Dank WLAN Steckdose konnte ich den Raspberry PI dann immerhin abschalten, um die Relais, welche die Sensorwerte von Solarthermie-Steuergerät und Gastherme (eh gerade abgeschaltet) zur Steuerung „manipulieren“, sicher auf ihren Standard-„Notfallposition“ zu wissen.
Es zeigt sich, wie wichtig es ist, die Schaltung richtig aufzubauen, damit im Ernstfall (stromlos) das Relais den sicheren Kontakt herstellt.
Und nun?
Jeden Morgen wird ein vollständiges Backup gezogen, sodass keine Daten verloren gegangen sind und die Wiederherstellung nach Rückkehr aus dem Urlaub in rund einer Stunde durchgeführt war.
Dass SD-Karten in Smart Home Pi’s nicht das ewige Leben haben, ist ja bekannt. Ich vermute, dass die Raumtemperatur von bis zu 50 Grad (bedingt durch die Solarthermie) hier auch nicht unbedingt förderlich ist. Ich versuche es jetzt erstmal mit einer SanDisk Pro Karte, die angeblich mehr aushalten soll. (Aber auch mit diesen habe ich schon von ähnliche Vorfällen gehört.)
Hoffnungsvoll stimmt mich die Entwicklung bzgl. der besseren SATA-Unterstützung beim Raspberry Pi OS, was vielleicht/möglicherweise/bitte (!) auch ein Zeichen für einen SATA Port auf einem zukünftigen Raspberry PI Modells ist? Der 4B kam ja schließlich auch schon vor zwei Jahren heraus…
Man wird ja wohl noch träumen dürfen.
Update 20.08.2021:
Und schon wieder war er aus. Liegt es vielleicht doch am Netzteil? Zum Einsatz kommt ein Original Raspberry Pi 4 Netzteil – mhhh. Getauscht und im Test.
Update 31.08.2021:
Der Shelly scheint richtig kaputt zu sein. Alle Reset-Versuche sind fehlgeschlagen, auch bei meinen bisherigen Flash-Versuchen (von original Firmware auf Tasmota) zuckt er bisher nicht. Inzwischen ist ein Garantie-Ersatzgerät von Allterco Robotics unterwegs.
Nachdem der Raspberry Pi auch bei einem zweiten Original Raspberry Pi 4 Netzteil kaum zwei Tage durchhielt, verheißt der Test mit einem Dritthersteller-Netzteil gerade Besserung. Er läuft seit sieben Tagen durch – das hatte ich lange nicht mehr.
Update 21.10.2021
Das Problem ist trotz neuem Netzteil wieder akut geworden. Tägliche Aussetzer waren die Folge. Heute habe ich von Raspberry Pi 4b auf Raspberry Pi 3b+ downgegradet. Der 3b+ hatte ich noch da. Dank Abwärtskompatibilität musste ich nur sämtliche GPIO Kabel, Conbee II, microSD und LAN umstecken und auf ein Micro-USB Netzteil wechseln – in weniger als 10 Minuten war es erledigt. Mein SmartHome-Pi braucht im Mittel 700 MB RAM, sodass es auf dem 3b+ auch mit zufriedenstellender Performance läuft. Ich bin gespannt ob es tatsächlich am Raspberry Pi selbst liegt und der 3b+ jetzt durchläuft.
Update 13.12.2021
Der Raspberry Pi 3b+ läuft ohne Probleme durch. Scheinbar hat der ehemals eingesetzte 4b einen Sprung in der Schüssel – schade! Da der 3b+ gut läuft und auch die Raspi-Preise ordentlich gestiegen sind, werde ich mit einem „Upgrade“-Ersatzgerät warten.
Die Auswahl an Node-RED Nodes ist riesig und dadurch ziemlich unübersichtlich. Daher finde ich es immer spannend, welche Nodes tatsächlich von anderen Nutzern genutzt werden. Um anderen genau diesen Einblick zu ermöglichen – und den ein oder anderen vielleicht auf Ideen zu bringen, hier meine Liste, die ich sicher in unregelmäßigen Abständen aktualisieren werde.
Stand: 22.01.2022
node-red
node-red-contrib-astrodata – Nodes for calculation of sun and moon position, sunset, sunrise etc.
node-red-contrib-combine – Node-RED Nodes that output combinations of consecutive incoming messages
node-red-contrib-cryptography – Simple cryptography, hash with SHA-256 and RIPEMD-160
Es ist mal wieder soweit – die Schnittstelle von opensensemap.org streikt. Da dies immer mal wieder (nicht nur dort) vorkommt, habe ich vor einiger Zeit eine Prüfung des JSON-Response eingebaut, sodass ich diese Fehler abfangen kann.
Damit ich dieses Code-Snippet nicht immer suchen muss, sei es hier archiviert. Vielleicht hilft es jemandem anders ja auch weiter.
Inzwischen lässt sich httpStatic über die Konfiguration in ioBroker festlegen. (Adapterversion 3.2.0)
Um Bilder, welche man mit Node-RED verarbeitet hat, auch über Node-RED Dashboard z.B. in einem Template-Node ausgeben zu können, muss man diese irgendwo ablegen. Um nicht einen extra Webserver dafür betreiben zu müssen, bietet Node-RED in der settings.js die httpStatic Option an.
// When httpAdminRoot is used to move the UI to a different root path, the
// following property can be used to identify a directory of static content
// that should be served at http://localhost:1880/.
//httpStatic: '/home/nol/node-red-static/',
Leider bietet der iobroker.node-red Adapter diese Einstell-Möglichkeit noch nicht an, sodass man selbst aktiv werden muss. Ein entsprechendes Issue liegt schon vor – wann es umgesetzt wird, ist aber noch nicht ersichtlich.
Achtung: diese Einstellung muss man nach jedem Update des iobroker.node-red Adapters erneut vornehmen.
Der Adapter iobroker.node-red generiert die settings.js des Node-RED über ein gleichnamiges Script, welches sich bei mir an diesem Ort befindet: /opt/iobroker/node_modules/iobroker.node-red/settings.js
Die Option httpStatic ist hier aktuell hart auskommentiert – ändert man sie entsprechend, findet sie beim nächsten Speichern der Einstellungen im ioBroker auch Eingang in die generierte Node-RED settings.js.
(Bei mir läuft der Node-RED Prozess über den User iobroker – der entsprechende httpStatic-Ordner sollte also für diesen User les- und schreibbar sein, damit es funktioniert.)
Update 17.11.2021: Nachdem ich wieder selbst reingefallen bin, nochmal: Diese Einstellung muss man nach jedem Update des iobroker.node-red Adapters erneut vornehmen.
Update 18.01.2022: In einem der nächsten Releases des iobroker.node-red Adapters wird die Einstell-Möglichkeit vrstl. vorhanden sein.
Update 27.02.2022: Menno, ich möchte bitte einmal direkt dran denken, dass man diese Einstellung nach jedem Update des iobroker.node-red Adapters vornehmen muss.
Update 16.04.2022: Inzwischen lässt sich httpStatic über die Konfiguration in ioBroker festlegen. (Adapterversion 3.2.0)
Als das SmartHome immer weiter wuchs, kam ich irgendwann an den Punkt, dass ich mir eine einheitliche Vorgehensweise für Benachrichtigungen überlegen musste. Viele Informationen braucht man nur, wenn sie akut sind. Diese über das ganze Dashboard zu verteilen und abzuklappern, wäre unpraktisch, denn Benachrichtigungen entstanden an immer mehr Stellen (der Versuch einer Sammlung):
Unwetterwarnungen
Meldung von technischen Problemen bei Schnittstellen
Meldung von technischen Problemen bei Sensoren
Update-Benachrichtigungen für Geräte-Firmware
Batterie-Meldungen von Sensoren
Indoor und Outdoor Temperaturwarnungen
Türklingel
Warnung bei hoher CPU Auslastung
Verkehrsmeldungen aus dem ÖPNV
Warnmeldungen zum Warmwasservorrat
Müll-Entsorgungsankündigungen
Geöffnete Türen oder Fenster (mit KWL kommt das nicht so häufig vor)
tägliche Niederschlagsmenge (ab einem bestimmten Grenzwert)
Da meine Heizung und Solarpumpe ziemlich un-smart sind, greife ich im Heizraum verschiedene Temperaturen mittels DSB18B20 Sensoren über 1-Wire selbst ab. Doch das 1-Wire zickte immer ziemlich rum. Sensoren waren teilweise vorhanden, dann wieder verschwunden. Unterschiedliche Kabellängen zu den Sensoren wirkten sich massiv auf die Zuverlässigkeit aus.
Der mutmaßliche Grund: der PullUp Widerstand war viel zu hochohmig. In vielen Anleitungen im Netz stehen Werte von 4K7 (4,7 KΩ) für den nötigen PullUp Widerstand. Ich hatte bereits „nur“ einen 3K2 verbaut – trotzdem zu viel, wie ich inzwischen herausgefunden habe. Denn der 4K7 Widerstand bezieht sich auf eine Spannung von 5V. Betreibt man 1-Wire am Raspberry Pi mit nur 3,3V muss der PullUp Widerstand deutlich geringer bemessen werden.
Ein interessantes Dokument zum Thema empfiehlt bei 3,3V einen Widerstand zwischen 725Ω bis 1000Ω. Und schon funktioniert es (zumindest bei mir).
Achtung Nutzt man einen zu geringen Widerstand bei einer Spannung von 5V können Sensoren und Raspberry Pi Schaden nehmen!
Noch ein Wort zum selber „abgreifen“ der Sensorwerte. Das funktioniert tatsächlich super! Im Speicher fand ich für die Sensoren Platz in den gleichen Messöffnungen, wo auch die Hausgeräte ihre Werte messen. Während zwischen meiner Messung und der Messung der Solarpumpe keine Abweichung erkennbar ist, liegt die Gastherme bei einer Abweichung von 1,3 Kelvin, was sich über ein Offset ganz einfach ausbalancieren lässt. Über den Parser-Adapter des ioBroker kommen die Werte der Sensoren ganz einfach ins SmartHome.