Viessmann API und Node-Red – Teil 6b – Influx Diagramme

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

Solarthermie: Ertrag ohne Wärmemengenmesser ausrechnen

Obwohl die Viessmann API in der Lage ist, den Solarertrag anzuzeigen, ist das  entsprechende API Feature heating.solar.power.cumulativeProduced in machem (leider auch in meinem) Fall leer.

Das liegt daran, dass die Solarinstallation mit einem Wärmemengenmesser ausgerüstet sein muss. Dieses Gerät vergleicht die Solar-Vorlauftemperatur mit der Solar-Rücklauftemperatur und misst zusätzlich den Durchfluss. Bei moderneren Wohnungen wird über solche Geräte die Heizkostenabrechnung gemacht.

Wie finde ich nun heraus, wieviel Energie von meinen Solarthermiepanels erzeugt wird wenn ich kein Calorimeter habe?

Viessmann API und Node-Red – Teil 7 – Solarthermie Ertrag weiterlesen

Viessmann API und Node-Red – Teil 8 – Sonstiges Tipps

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

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.

 

InfluxDB: Probleme bei Installation und Update – Lösung

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

Geofencing Experimente mit der Locative App
Teil 1: PHP

Nach sehr langer Pause hat mich wieder einmal die Lust am Basteln und Experimentieren gepackt… Also, auf geht's:

Was ist Geofencing?

Im Zuge des Vormarschs von Internet of Things (IoT) Produkten kommt vermehrt auch Geofencing zum Einsatz. Geofencing ist ein Kunstwort, zusammengesetzt aus den Begriffen "Geo" (Erde oder auch abgekürzt für Geographie etc.) und "Fence" (engl.: Zaun). Ein Geofence ist ein virtueller Zaun um einen bestimmten Punkt herum, bei dessen Überschreiten in die eine oder andere Richtung ein Ereignis (Heizungssteuerung, Licht an/aus, Garagentor auf/zu etc.) ausgelöst wird. Geofencing Experimente mit der Locative App
Teil 1: PHP
weiterlesen