nodered – SmartHome im Eigenbau

Der aktuelle Aufbau

Dieser Artikel wird fortlaufend aktualisiert.

Seit Frühjahr 2019 bastle ich an meinem SmartHome herum – und zugegeben, es ist schon ganz schön angewachsen.

Die aktuell eingesetzten technischen Komponenten und Schnittstellen
Stand: 28.08.2022

Basis sind zwei Raspberry Pi 4B 2GB mit Raspberry Pi OS 32-bit.

Auf dem primären Raspberry Pi läuft das SmartHome auf Basis von ioBroker. Ein sekundärer Raspberry Pi überwacht den primären Pi, ist Node-RED-Spielwiese für Dinge, die nichts mit dem SmartHome zu tun haben und sorgt im Heimnetz für weitere Funktionen wie Etherpad, Pi-hole, Netzwerkspeicher …

ioBroker ermöglicht es, den zersplitterten SmartHome Markt zusammenzuführen, indem alle Protokolle mittels verschiedener Adapter auf eine gemeinsame Objekt-Basis runtergebrochen werden. Als Logik-Instanz kommt Node-RED zum Einsatz, über welches ich auch weitere Schnittstellen realisiere.

Aus der Auswahl der Funklösungen habe ich mich für ZigBee entschieden. Preise und Verfügbarkeiten der Komponenten erschienen mir 2019 besser als bei Z-Wave. Auch wenn OSRAM/ledvance nicht mehr alleinig auf ZigBee setzt (hier kommt vermehrt Bluetooth zum Einsatz), ist die Auswahl der Komponenten sehr reichlich und die Auswahl der Hersteller wird immer größer. Hauptsächlich setze ich Zigbee-Geräte von Xiaomi Aqara, Philips Hue und IKEA ein, zunehmend auch Sonoff und Tuya. Der Raspberry Pi kommuniziert mittels des ZigBee Sticks von Dresden Elektronik Conbee II mit den Sensoren, Schaltern, Dosen und Birnen. Mit einer Batterielaufzeit von mind. zwei Jahren (auf dem Papier, real teils länger, teils kürzer), lassen sich drahtlose Sensoren ohne viel Wartungsaufwand betreiben. WLAN-Akku-Geräte können hier aktuell nicht mithalten.

Als Schaltaktoren setze ich vor allem WLAN-Relais ein – hauptsächlich Shellys von Allterco Robotics. Als Unterputzmodule konstruiert, passen sie mit etwas Gefrickel in eine normale (tiefe) Hohlwanddose. Der Clou daran: der Schalter bleibt intakt. Genauso wie man den Verbraucher ab sofort durch das SmartHome schalten kann, wird die Betätigung des Hardware-Schalters an der Wand an den ioBroker gemeldet und kann so auch zusätzliche Funktionen auslösen. Die meisten WLAN-Aktoren arbeiten mit der OpenSource Firmware Tasmota.

Weiterhin sind inzwischen auch WLAN-Zwischenstecker in nennenswerte Zahl vorhanden, vor allem von Sonoff und Gosund. Auch purzeln einige Osram Smart+ Plugs (Zigbee) herum.

Die WLAN Komponenten kommunizieren über das Nachrichtenprotokoll MQTT mit dem ioBroker oder über die HTTP Schnittstelle direkt mit Node-RED. Über mein NodeRED Dashboad kann ich neue Firmware-Versionen von Shelly Firmware (Mongoose OS) und Tasmota ausrollen, sodass sich der Wartungsaufwand in Grenzen hält.

Neu/Ende Januar 2020

Ende Januar kam die Überwachung der Solaranlage und der Speichertemperaturen hinzu. Leider gab es hier seitens des Steuergeräts keinerlei Schnittstellen. Daher musste ich alle Werte selbst erheben: Temperaturen werden über 1-Wire-Temperatursensoren gemessen – die Laufzeit und Leistung der Solaranlage über eine WLAN-Steckdose (Gosund) mit Stromverbrauchsmesser erhoben.

Neu/Ende März 2020

In der Zwischenzeit habe ich weitere Wetterstationen aus der Nachbarschaft eingebunden. Neben Regenmenge, Windstärke und Windrichtung importiere ich Messungen bezüglich der Sonneneinstrahlung, den UV-Index und Feinstaubwerte.

Ende März nahmen die Probleme mit Zigbee überhand. Durch eine komplette Neuinstallation hoffe ich, die Probleme zu lösen. Ein Upgrade auf den Raspberry Pi 4 habe ich dabei direkt auch gemacht. Ein größeres Relais-Board ist eingetroffen, damit ich noch mehr Temperatursensoren manipulieren kann.

Neu/April 2020

Im April wurden ziemlich viele weitere Datenquellen integriert. Meteoalarm für Unwetterwarnungen, der Abfallkalender mit den Entsorgungsterminen, der Ferienkalender zur Steuerung der Weckerfunktion, die Abfahrtzeiten der lokalen Verkehrsbetriebe. Außerdem geht das Haustür-Klingeln als Signal auch direkt ins SmartHome.

Auch das Relais-Board wurde wieder fit gemacht – die Solar-Abkühlfunktion auf eine Platine gelötet und instand gesetzt und eine Anbindung der Heizung vorbereitet.

Ein neuer „Meldungen“-Bereich sammelt Informationen und Fehlermeldungen aus allen Bereichen und gibt diese prominent aus.

Oktober 2021

Da ein Aqara Bewegungsmelder unzuverlässig geworden ist, habe ich jetzt auch Bewegungsmelder von Sonoff und Tuya (beides Zigbee) im Einsatz. Durch andauernde Probleme mit dem Raspberry PI 4 habe ich ein Downgrade auf einen Raspberry Pi 3b+ gemacht.

Dezember 2021

Ein USB IR Lesekopf (Hichi) liest jetzt meinen Stromzähler aus. Die Installation war eine wahre Freude: Plug&Play in seiner besten Form. Dank 5m USB Verlängerung hängt er direkt am PI – seitens ioBroker werkelt der Adapter ioBroker.smartmeter. Es werde Licht im Dachgeschoss – dank Shelly 2.5 und Shelly i3.

Januar 2022

Für im Dach neu zugewonnene Zimmer wurden neue Sensoren (Aqara) ergänzt. Auch ein neuer Lichtwecker (Zigbee-Glühbirne) mit entsprechendem Zigbee-Taster (Ikea) wurde ergänzt. Nach längerer Zeit habe ich mich mal wieder an ESP8266-ESP32-Arduino-Basteleien versucht und neue Erfolge gefeiert. Eine kleine Ampel im Bad (Wemos D1 Mini + RGB Shield) gibt nun Auskunft über den Warmwasser-Bestand. Da der Pi 3b+ vom Backup-Prozess überfordert war, wurde ein neuer 4B beschafft und installiert.

Februar 2022

Eine smarte Steuerung und Überwachung der Konvektorheizungen im Dachgeschoss wurde realisiert.

April 2022

Die Auswertung des Stromverbrauchs wurde ausgeweitet. Verschiedene alte Flows wurden überarbeitet und optimiert. Mit der App JRW Json Response Widget (die eigentlich gar kein JSON verarbeitet) wurde ein schnelles und (aktuell) zuverlässiges Widget gebaut. Die neuen Velux Integra Solar Rolladen wurden smart gemacht.

August 2022

In der Zwischenzeit wurden weitere Datenquellen integriert, z.B. der Vertretungsplan der Schule und solar-wetter.com für eine Prognose des Photovoltaik-Ertrags. Die Daten des Wechselrichters wurden zunächst über die Cloud von Growatt eingebunden, später dann über eine modifizierte Logger-Firmware (Growatt Shine WiFi-X) direkt lokal über MQTT. Zur Maximierung des Eigenverbrauchs wurde eine HAMA Steckdosenleiste (4x Schuko + 4x USB einzeln schaltbar) auf Tasmota umgestellt. Entsprechende Flows prüfen, ob Strom „übrig“ ist und schalten die zu ladenden Geräte zu.

September 2022

Überschüssiger Strom aus der Photovoltaik-Anlage wird jetzt, wo es langsam kalt wird, vollautomatisch „verheizt“. Dafür kommen Konvektorheizer mit 500 und 750 Watt zum Einsatz, welche vom SmartHome je nach Stromüberschuss dank smarter Steckdosen zugeschaltet und abgeschaltet werden können. Dafür entsteht gerade ein – ich nenne es großspurig – Energie Management System (EMS), welches verschiedene Verbraucher verwaltet und diese dabei selbstständig, ergänzt durch Sensorwerten (Temperaturen) und Wettervorhersagen, priorisiert. Ein wenig ist hier aber noch zu tun.

Rund um Strom-Verbrauch und -Erzeugung wurden diverse Diagramme (Flot & NodeRED Dashboard) erstellt und informative Statistiken zusammengestellt. Dafür hat die Sortierung meines NodeRED Dashboards eine größere Überarbeitung erfahren.

Ein weiterer Lichtwecker wurde schnell zusammenkopiert. Ist ja nichts neues mehr. Morgens hat das SmartHome mit vier meist weitgehend parallel laufenden Lichtweckerprozessen nun gut zu tun. Überfordern tut das den Raspberry Pi 4b 2GB aber nicht.

September 2023

Bedingt durch einen neuen Wechselrichter musste ich mich mit der lokalen Integration eines Hoymiles HMS-800w 2t beschäftigen. Dank des hms-mqtt-publisher ging das dann schnell besser als gedacht.

Dezember 2023

Der unterstützende Pi, der nebenbei auch allerlei andere Aufgaben im Heimnetz übernimmt, wurde auf einen Pi 5 geupgraded. Eine aufwändigere Arbeit als erwartet.

Mai 2024

Neue Zigbee-Sensoren kamen in den letzten Monaten hinzu. Dabei bin ich tiefer in die Funktionalität von Zigbee und Deconz eingetaucht. Leider streiken die Wassersensoren gerade – ich hoffe das klärt sich …

Juni 2024

Mein EMS (Energie Management System) ist inzwischen erwachsen geworden. Viel Arbeit floss in den letzten Monaten hinein. Inzwischen können Verbraucher flexibel über das Frontend ergänzt, bearbeitet, aktiviert und deaktiviert werden.

Mehrere Geräte können gleichzeitig (automatisch) geschaltet werden. Dabei wird immer die optimale Kombination aus Geräten erhoben, welche das Stromangebot optimal ausnutzt.

Das Einschalten und Ausschalten der Geräte richtet sich nach diversen Bedingungen wie Temperaturen, Jahreszeiten, Tageszeiten, Schonzeiten, Mindestlaufzeiten, Pardonzeiträumen, Prioritäten …

Auf Wunsch wird ein abstufbar-umfangreiches Log geschrieben, welches alle Entscheidungen transparent macht – und das Debugging enorm erleichtert. Ebenso werden Statistiken geführt, wie z.B. Verbrauch und Einschalthäufigkeiten.

Bei einer Vielzahl von Sensoren den Akkustand prüfen

Inzwischen haben sich jede Menge Zigbee-Sensoren angesammelt. Diese halten mit einer Batterie echt lange durch. Viele zwei Jahre und mehr. Trotzdem geht die Batterie irgendwann mal zur Neige und davon möchte ich nicht überrascht werden. Also habe ich einen kleinen Flow in Node-RED, welcher die Akkustände jeden Tag einmal prüft und mich bei Bedarf benachrichtigt.

Um nicht für jeden Sensor neue Nodes ergänzen zu müssen, nutze ich die Möglichkeit, Nachrichten mit node.send(msg); asynchron zu versenden.

Sensoren zentral hinterlegen und einzeln durchgehen

var zigbeesensoren = [2,4,5,6,9,10,11,14,15,16,17,21,23,26,29,30,31,32,33,34,36,38,41,44,45,46,49,50,51,52,53,56,57,58];

zigbeesensoren.forEach(function(val) {
    msg.topic = "deconz.0.Sensors."+val+".battery";
    node.send(msg);
});

return;

Im Array zigbeesensoren sind einfach die abzufragenden Sensornummern (der ioBroker-Objekte) hinterlegt. Die forEach-Schleife sorgt dafür, dass das ganze Array durchgegangen wird und das richtige msg.topic für jeden Sensor gebaut und als Nachricht abgeschickt wird. So kann über „IoB read value“ jeder einzelne Batteriestand ausgelesen und in der Funktion „Batterie leer?“ geprüft werden. Wie gewohnt erstellt „UI Notification“ im Bedarfsfall die Benachrichtigung und leitet sie an das zentrale Benachrichtigungssystem.

Einen ähnlichen Aufbau kann man natürlich auch für beliebige andere Objekte nutzen, die vielfach ausgewertet werden müssen.

zigbee-batterie-flow Herunterladen

Eine eigene PHP-Web-API bauen

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.

Zum Einsatz kommt seitens Node-RED node-red-contrib-cryptography.

Ich generiere einen Auth Token, dieser basiert auf der aktuellen Zeit und einem geheimzuhaltenden Passwort, quasi einem Salt.

msg.payload = Math.round(Date.now()/10000) + "dasGeheimePasswort1234!";
msg.headers = {};
msg.headers["Content-Type"] = "application/x-www-form-urlencoded";
return msg;

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.

msg.payload = {
"auth": msg.payload,
"temperatur": msg.temperatur
};
return msg;

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.

<?php
   if($_POST["auth"] == hash('sha256',(round(time()/10))."dasGeheimePasswort1234!")) {
echo "true";
}
?>

Achtung! PHP arbeitet bei den Timestamps in Sekunden, während JavaScript in Millisekunden arbeitet. Daher ist hier nur eine Division durch 10 nötig.

Statt dem echo „true“; kann man natürlich beliebiges mit den mitgeschickten Werten anfangen.

Flot mit min / max / mittel nutzen

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.

Wetter selbst von yr.no abrufen

Update vom 12.01.2022

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.

Das Query-String für den Erfurter Dom wäre dann

https://api.met.no/weatherapi/locationforecast/2.0/complete?altitude=194&lat=50.97578937177409&lon=11.023335426472794

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:

msg.headers = {
    "User-Agent": "erfurter-dom-99084"
}
return msg;

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.

{
        "time": "2021-08-30T15:00:00Z",
        "data": {
          "instant": {
            "details": {
              "air_pressure_at_sea_level": 1018.5,
              "air_temperature": 13.8,
              "cloud_area_fraction": 100,
              "cloud_area_fraction_high": 57.8,
              "cloud_area_fraction_low": 100,
              "cloud_area_fraction_medium": 28.1,
              "dew_point_temperature": 12.9,
              "fog_area_fraction": 0,
              "relative_humidity": 94.4,
              "ultraviolet_index_clear_sky": 0,
              "wind_from_direction": 355.9,
              "wind_speed": 2.8
            }
          },
          "next_12_hours": {
            "summary": {
              "symbol_code": "lightrain"
            }
          },
          "next_1_hours": {
            "summary": {
              "symbol_code": "rain"
            },
            "details": {
              "precipitation_amount": 0.3
            }
          },
          "next_6_hours": {
            "summary": {
              "symbol_code": "lightrain"
            },
            "details": {
              "air_temperature_max": 13.9,
              "air_temperature_min": 13.1,
              "precipitation_amount": 0.6
            }
          }
        }
      },

(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:

3. Spalte (w0)

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

[{"series":["min °C","max °C"],"data":[[-0.6,-0.5,3.7,1.9,0.5,0.6,3.2,3.6],[1,2.5,5.8,3.8,1.3,2.1,5,4]],"labels":[1,7,13,19,1,7,13,19]}]

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.

yr.no Import Herunterladen

yr.no Node-RED Dashboad Chart Herunterladen

Diese Node-RED Nodes nutze ich

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
node-red-contrib-ical-events – NodeRed calender event adapter
node-red-contrib-influxdb – Node-RED nodes to save and query data from an influxdb time series database
node-red-contrib-os – Node-Red nodes for obtaining cpu system information.
node-red-contrib-presenchecker – Checks fritzbox, whether a given device (by mac address) is online or offline
node-red-contrib-schedex – Scheduler for node-red which allows you to enter suncalc events (e.g. goldenHour).
node-red-dashboard – A set of dashboard nodes for Node-RED
node-red-node-email – Node-RED nodes to send and receive simple emails.
node-red-node-pi-gpio – The basic Node-RED node for Pi GPIO
node-red-node-ping – A Node-RED node to ping a remote server, for use as a keep-alive check.
node-red-node-rbe – A Node-RED node that provides report-by-exception (RBE) and deadband capabilities.
node-red-node-twitter – A Node-RED node to talk to Twitter
node-red-node-xmpp – A Node-RED node to talk to an XMPP server

json auf Gültigkeit prüfen

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.

var json_valid = true;

try
{
   var json = JSON.parse(msg.payload);
}
catch(e)
{
  json_valid=false;
}
finally {
    if(json_valid === true) {
        node.status({fill:"green",shape:"dot",text:"Okay"});
        return [msg,null];
       
    }
    else {
        node.status({fill:"red",shape:"dot",text:"Error"});
        return [null,msg];

    }
}

httpStatic mit einer ioBroker Node-RED Installation konfigurieren

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)

Ein flexibler Benachrichtigungsbereich in Node-RED Dashboard

Vorgeschichte

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)

POST-HTTP Request mit Daten

Da ich mich sehr dumm angestellt habe und ewig brauchte, um mit Node-RED einen HTTP Request inkl. Daten zu versenden, dokumentiere ich hier – nur für mich (weil sich bestimmt niemand so umständlich anstellt) – die funktionierende Lösung.

Der simple Aufbau, ein Function-Node und ein HTTP-Request-Node:

Im Function-Node werden die zu übermittelnden Daten in msg.payload als JSON geschrieben. Außerdem wird
msg.headers["Content-Type"] = "application/x-www-form-urlencoded";
gesetzt.

Der HTTP-Request ist dann kaum zu konfigurieren. Methode = POST eintragen, dann noch die URL und fertig.