Das Node-Red hat von Haus aus einige nette grafische Elemente zum Visualisieren und Manipulieren von Werten, die auf unterschiedlichste Weise generiert und eingesammelt wurden. Manchmal hätte man aber gerne etwas mehr:
Viessmann API und Node-Red – Teil 5 – Dashboard Tipps weiterlesen
Wenn du schon eine Weile mit Node-Red gearbeitet hast, wist du festgestellt haben, dass Node-Red schlagartig alle bisher aufgelaufenen Diagrammwerte vergisst, wenn Node-Red oder der Server neu gestartet werden. Das ist unschön. Auch Werte, die vor einiger Zeit angefallen sind (z.B. Verbrauchsdaten) werden von Node-Red nicht so einfach für weitere Analysen vorgehalten. Dasselbe mit allen Werten, die links aus einem Node-Red Diagramm rausgelaufen sind.
Hier brauchen wir eine Datenbank! Aber welche? Man könnte sich jetzt ein System aus MySQL basteln oder textbasierten Dateien. Da wir es bei unseren Anwendungsfällen meist um Zeitreihen handelt, ist Influx die erste Wahl, da diese Datenbank speziell für diesen Zweck entwickelt wurde.
Viessmann API und Node-Red – Teil 6a – Influx installieren weiterlesen
Um es vorweg zu sagen, ich beschäftige mich in diesem Artikel mit Influx zur Erzeugung von Diagrammen ausschließlich in Node-Red. Es gibt auch andere, leistungsfähigere Diagrammlösungen wie Grafana. Die dabei zu durchlaufende Lernkurve ist allerdings sehr steil und außerdem haben wir anschließend ein weiteres System an der Hand, so dass wir zwischen Diagrammen und Einstellungen immer hin- und herspringen müssen. Ich finde, Analysen und Befehle auf einer einzigen User-Interfaceschicht besser. Auch wenn Node-Red, was Diagramme angeht, nicht so viel kann, für den Hausgebrauch reicht es. Ein weiterer Vorteil von Node-Red ist, dass die Darstellung auf mobilen Endgeräten besser ist.
Viessmann API und Node-Red – Teil 6b – Influx Diagramme weiterlesen
Viessmann API und Node-Red – Teil 7 – Solarthermie Ertrag weiterlesen
Im Laufe der Zeit baut man immer wieder kleine Verbesserungen in die Flows ein, um Performance, Transparenz oder Betriebssicherheit zu steigern. In loser Folge sind hier meine Erkenntnisse dazu zu finden.
Leider sind die Viessmann Server alles andere als zuverlässig. So kommt es immer wieder zu Timeouts, fehlgeschlagenen Authentifizierungen oder Komplettausfällen. Okay, als User des kostenfreien Basisangebots will ich mich nicht all zu laut beschweren.
Kommunikationsfehler könnte man durch jeweils einen debug Node hinter einem http request Node anzeigen lassen. Angezeigt werden sollte dabei das "komplettte Nachrichtenobjekt". Das ist zum Testen ganz okay, aber auch flüchtig.
Um solche Fehler in ein Log zu schreiben, brauchst du einen switch node, der z.B. bei leerem Refresh Token zu einem write file Node verzweigt und die Payload dort hineinschreibt. Den write file Node muss man eventuell über die Palettenverwaltung nachinstallieren. Das funktioniert ganz gut, ist aber umständlich, da ich den Switch hinter jedem http request Node einbauen muss und dann unter Umständen viele Spaghettis zu dem write file Node ziehen muss. Bei Autentifizierungsfehlern ist das aber die beste Möglichkeit der Fehlerbehandlung (siehe unten).
Eine schöne Möglichkeit bietet der catch Node: Der catch Node ist eine Art Mülleimer für alle Arten von Fehlern. Ich stelle ihn so ein, dass er alle gewünschten Nodes, in diesem Fall alle http request Nodes überwacht, das Ergebnis anschließend angereichert und mit dem write file Node in ein Log (Textdatei) geschrieben wird.
Der Flow sieht so aus:
Die Nodes simpletime (über Palettenverwaltung nachinstallieren) und create error msg function Node erzeugen einen aussagekräftigen Eintrag im Log. Siehe JSON
|
1 |
[{"id":"9bcfca998ffaad65","type":"file","z":"31c57f8640528976","name":"","filename":"/home/pi/refresh_error.log","filenameType":"str","appendNewline":true,"createDir":false,"overwriteFile":"false","encoding":"none","x":2390,"y":820,"wires":[[]]},{"id":"b53c3d8b942ddacd","type":"catch","z":"31c57f8640528976","name":"","scope":["eb4771b87fc1270f","d6e3257c9c2d54ad","c765f5d53247981e","3d828c3c867062b0","d189c65f2d221d39","f52e123cdd02a6bc","934155ca818ec102","70ab63bf7d6ee874","71289c1dc9738a4c"],"uncaught":false,"x":1870,"y":820,"wires":[["bc0237c216acaaf6"]]},{"id":"a600cbb060c0019d","type":"function","z":"31c57f8640528976","name":"create error msg","func":"msg.payload = msg.myrawdate + \" \" + msg.error.message + \" \" + msg.error.source.name \nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":2180,"y":820,"wires":[["9bcfca998ffaad65"]]},{"id":"bc0237c216acaaf6","type":"simpletime","z":"31c57f8640528976","name":"","mydate":false,"myymd":false,"myyear":false,"mymonth":false,"mymonthn":false,"mydom":false,"mydoy":false,"myday":false,"myhourpm":false,"myhour":false,"mytime":false,"mytimes":false,"myminute":false,"myminutes":false,"mysecond":false,"mymillis":false,"myepoch":false,"myrawdate":true,"mypm":false,"x":2010,"y":820,"wires":[["a600cbb060c0019d"]]}] |
Wichtig ist ferner, den oder die http Request Nodes so einzustellen, dass sie mit "Only send non-2xx responses to Catch node" alle Kommunikationsfehler an den catch Node weiterleiten:
In der Console eures Rechners (bei mir ein Raspberry Pi) sieht das so aus:
Bei mir immer wieder "Keine Antwort vom Server" oder etwas kryptischer "getaddrinfo EAI_AGAIN api.viessmann.com" was aber auch ein Fehler auf der Viessmann Seite sein dürfte. So habt ihr zumindest etwas in der Hand um bei den Friendly Moderators bei Viessmann nachzufragen.
Übrigens: das von mir im Viessmann Forum bemängelte Problem The-Viessmann-API/Access-Token-erneuern-schlaegt-alle-paar-Stunden-fehl, tritt nicht mehr auf. Ob das mit der Umstellung auf die Catch Node Fehlerbeandling zurückzuführen ist, weiß ich allerdings nicht.
Wichtig: Leider fängt der Catch Node Fehler der Art "INVALID TOKEN" oder "TOKEN EXPIRED" nicht ab.
Hier muss explizit über die Abfrage der Rückgabewerte msg.payload.message, msg.payload.errorType, msg.payload.error oder msg.payload.statusCode gearbeitet werden. Diese Werte sind null, wenn alles okay ist.
Der direkt hinter einem http request einzubauende switch Node sieht dann so aus:
Ausgang 1 wird benutzt wenn die Abfrage ordnungsgemäß durchgelaufen ist, Ausgang 2 sobald in msg.payload.message (oder msg.payload.error etc.) etwas drin steht also ein Fehler aufgetreten ist.
