Bei Verbesserung der Telemetrie für den Freifunk-OpenMPPT-Solarladeregler haben wir die Telemetriedatenübertragung für den DIY MPPT, FOSS und OSHW Solar-Bleiakku-Lader von @elektra an MQTT und Grafana angeschlossen.
Hier geht es nun um eine sinnvolle Darstellung im Grafana. @wtf könnte da u.U. etwas dafür tun.
Schon. Aber so nicht! Wat für Einheiten und Größenordnungen sollen des alles denn sein? …Voltage kann ick mir denken. Aber: timeToShutdown? Ist des Minuten? Und ne Temperatur, die bei -142 $Irgendwas liegt? Sind das imperiale Kelvin oder wat?! Und wat is Health? Nen ICD-Code? Und wat is Capacity? Farad? Prozent? micro, nano, mega, yotta? Und dieset Status?
ps.: Und wat soll das sein, timeToShutdown? Ab dann passiert was? Wird das System gebricked? Akku voll? Reboot? Lastabwurf?
cc @elektra
Und wann gibts wieder Daten? Da ist schon fast 1.5h Funkstille! ;)
Ich war unterwegs und habe zum Firmware-Tüfteln ein generisches NodeMCU-ESP32-Developerboard benutzt. Zur Arbeit an der Firmware reicht das, wenn es nicht um die Kontrolle der MPPT-Peripherie geht. Da hängt keine Hardware an den ADCs, kein Akku und kein Solarmodul - daher die absurden "Mess"werte. Time to Shutdown ist ein Timer, der bei 0 das System neu startet. Der Wert ist in Minuten. Die HEX-Statuscodes bestehen aus Signalbits zur Kommunikation des Systemzustands. Es macht wenig Sinn daraus einen Graphen zu machen. Hier ist die Aufschlüsselung der ISEMS Bit-Codes:
(Big endian: Bit_0 left, Bit_11 right)
Bit_0: 1 = Charging
Bit_1: 1 = Discharging
Bit_2: 1 = Fully charged
Bit_3: 1 = Healthy
Bit_4: 1 = Warning: Battery level low. Increased battery wear.
Bit_5: 1 = Error: Energy storage capacity too small. Check battery size and/or wear.
Bit_6: 1 = Warning: Temperature sensor not connected.
Bit_7: 1 = Error: No communication with solar controller.
Bit_8: 1 = Battery overheating.
Bit_9: 1 = Low battery temperature.
Bit_10: 1 = Firmware upgrade not allowed
Bit_11: 1 = (Currently unused)Werte wie LAT und LONG, Batteriekapazität in Ah, Modulleistung in Watt sind statisch und werden im Node in die Konfigurationsdatei eingetragen.
Was die Kommunikation der Telemetriedaten angeht - MQTT funktioniert, aber HTTP (noch) nicht.
Danke für die Details! Des hilft ja schonmal weiter 
Korrekt, keinen Graphen. Aber auch Codes lassen sich ja mittels des discrete-panels auch recht schön darstellen, wie etwa bei
LTE-Cell/Location-IDs:
Zuständen des Wetters:
oder etwa von phänologischen Daten:
Aktueller Status-Code: 0x486
Entspricht Bitstring: 0100 1000 0110
Bit_0: 0 = Charging (Ganz sicher nicht!)
Bit_1: 1 = Discharging
Bit_3: 0 = Healthy == KRANK!
Bit_4: 1 = Warning: Battery level low. Increased battery wear. (3.2 Volt!)
Bit_5: 0 = Error: Energy storage capacity too small. Check battery size and/or wear. (Nicht ermittelt.)
Bit_6: 0 = Warning: Temperature sensor not connected (Liest ja eine Temperatur, wenn auch sehr Niedrige ;)
Bit_7: 0 = Error: No communication with solar controller (Bekommt Daten!)
Bit_8: 0 = Battery overheating. (Ganz gewiss nicht bei -140 Grad Celsius!)
Bit_9: 1 = Low battery temperature. (Ohh, ja!)
Bit_10: 1 = Firmware upgrade not allowed (Lieber nicht, denn die "gemessene" Akkuspannung ist 3,2 Volt - der Tiefentladeschutz hätte das System längst abschalten müssen!)Die ADC-Pins, die normalerweise Eingangsspannung des Solarmoduls und Akkuspannung messen sind gerade free floating, weil ich immer noch das generische Dev-Board benutze. Mal wird die Akkuspannung höher als die Solarspannung “gemessen”, mal nicht. Deshalb sprint das Ergebnis zwischen 0x886 und 0x486.
Hier der aktuelle Inhalt der lokalen Statusseite:
Summary: Charging. Warning: Battery level low. Increased battery wear. Low battery temperature.
Charge state: 0%
Next scheduled reboot by watchdog in: 3572 minutes
Battery voltage: 2.708 Volt
Battery temperature: -129.23°C
Battery health estimate: 100%
Power save level: 0
Solar panel open circuit voltage: 2.765 Volt
MPP-Tracking voltage: 2.765 Volt
Low voltage disconnect voltage: 11.9 Volt
Rated battery capacity (when new): 8 Ah
Rated solar module power: 10 Watt
Unix-Timestamp: 1579721797 (local time)
Solar controller type and firmware: FF-ESP_1A
Latitude: 52.52
Longitude: 13.4
Status code: 0x886
Free RAM in Bytes: 151580
Uptime in seconds: 1747
Der Code aus der ISEMS-App könnte für die Analyse der HEX-Codes nützlich sein 
Ähm, kann so was grafana überhaupt oder macht es mehr Sinn das auf dem node zu dekodieren und als einzelne Variablen mit 0/1 rüberzuschieben?
Ich freue mich sehr, dass es bereits Graphen auf mqtthub gibt. Zusätzlich den Status-Code zu analysieren, wäre das Tüpfelchen auf dem i. Dazu gibt es bereits Code. Wer es als Inspiration versteht - wunderbar.
Aber es gilt: Alles kann, nichts muss.
Ich kenne mich mit Graphana nicht aus. Der HEX-Statuscode ist gedacht, um den Zustand des Systems möglichst bandbreitensparend zur ISEMS-APP zu kommunizieren. Das wieder umzudrehen wäre aus meiner persönlichen Sicht eine Rolle rückwärts ;)
Wir können auch [am grafana-ende] eine große Lookup-Table nehmen, die jede mögliche Kombination in einen eigenen String mapt! ;)
Aber wenn ick mal die Mathe verstanden hab, seh ick da auch Chancen das innerhalb der Datenbank-Abfragesprache unseres Vertrauens (flux) aufdröseln zu können … nur hab ich danach ja keine Zahlen, sondern [auch noch mehrere] Zustände in der Hand! Ohje. Vielleicht doch die Lookup-table vong Größe.
Man sollte wie vorgesehen auf jedes einzelne Bit schauen und die entsprechende Info ausgeben. Sonst sind es zu viele Möglichkeiten, auch wenn es nicht tatsächlich 2^11 Kombinationen sind, solange ich nicht anfange, das 12. Bit zu verwenden ;)