Inzwischen hat mich auch das Solarfieber gepackt. In loser Folge werde ich hier meine Anlage beschreiben und Einzelaspekte herauspicken.
Mein "Guerilla-Kraftwerk" erzeugt theoretisch 1760Wp. Aufgrund der suboptimalen Ausrichtung nach WNW waren es im vergangenen Sommer lediglich ca. 1300W Maximalleistung. Die Module liegen mit 12° recht flach, was die schlechte Ausrichtung etwas kompensiert.
Solar - Pylontech Akku (C-Serie) über Konsole aufwecken 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.
Die Genies bei Influx.com haben Ende Januar 2023 geruht, aus Sicherheitsgründen eine sogenannte Key-Rotation zu veranstalten. Das führt allerdings in erster Linie dazu, dass der Server Administrator rotiert, weil es beim Befehl sudo apt update zu einer Fehlermeldung kommt. Das passiert sowohl beim normalen Update des Systems als auch beim erstmaligen Installieren des InfluxDB Repositories. InfluxDB: Probleme bei Installation und Update - Lösung weiterlesen
Eins der beliebtesten Projekte für Arduino oder Raspberry Pi ist wohl der Aufbau einer Wetterstation mit Anzeige der Temperatur, der Luftfeuchtigkeit oder des Luftdrucks. Also fleißig ans Basteln, einen DHT22 Sensor (Temperatur und Luftfeuchtigkeit) oder einen BMP180 (Luftdruck und Temperatur) oder BME280 (Temperatur, Luftdruck und Luftfeuchtigkeit) mit dem Controller oder Pi verbunden, ein Messprogramm geschrieben, eine schöne grafische Ausgabe gebaut und fertig.
Komischerweise unterscheidet sich der angezeigte Luftdruck - je nach Wohnort - meist von der "offiziellen" Angabe im Wetterbericht. Woran liegt das?
Wenn man mit dem Flashspeicher eines ESP8266 oder ESP32 basierenden Microcontrollers herumspielt, kann es vorkommen, dass man beim Laden und Ausführen eines neu entwickelten Skripts eine fatal exception im Serial Monitor angezeigt bekommt. Es läuft eine unendliche Fehlermeldung mit lauter hex-Werten durch.
