Sonstige Tipps & Ticks
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.
Kommunikationsfehler abfangen
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.
