Improve data storage from unstructured .csv to a structured, self documenting format to overcome it's current shortcomings for even better usability

[mi-hol]

Updated 16May2026 12:34

Development of sml script features are progressing extremely fast and provide usability improvements I had only dreamed about a few months ago :)
I'm very grateful to gemu2015 and ottelo9 for driving these improvements!

An example is persistent storage of collected data via .csv files, that did only appear around Jan2026.

With new features, new dreams of next features to go even further, start to build too.

A new use case I dream of is:

Storing data points created every 15 minutes over a rolling period of i.e. 2 years and analyse the collected data later via spreadsheet app like LibreOffice Calc.

Loading the currently created data.csv file into LibreOffice Calc shows some shortcomings I'll detail below.

Current shortcoming:

• structure & content of file data.csv is only understandable by looking at the specific definitions in the script that created it, but the script name & version is not contained in the data
• the data period is not captured in the data and the scripts assume it currently to be from "Verbräuche / Einspeisungen (Jahr 2025/2026)" via hard-coded title in chart => will be incorrect starting 1Jan2027!
• Number of data points stored is currently hard-coded => customization requires edit & fork of several scripts and introduces the risk of errors interpreting/analysing the data

Idea:

• use structured format to store data, like XML or JSON, that can be correctly interpreted by LibreOffice Calc and similar apps
  OR
• would a (time series) database with filter and export to XML or JSON be the even better option?

@gemu2015 @ottelo9 may I kindly ask for your views on this topic?

[mi-hol]

• structure & content of file data.csv is only understandable by looking at the specific definitions in the script that created it

@gemu2015 as a first step to prevent undesirable drift, could perhaps Claude change all scripts to use common code for writing data.csv via include statement?

[gemu2015]

Data Format is now selectable via #define between binary and tab delimited as in scripter

[mi-hol]

a day later the 4h chart shows ;)

updated to TinyC 6.16 (tough only indicator of version is the build date :( )

and waited over 5 Mins but 4h chart is again empty

Data Format is now selectable via #define between binary and tab delimited

Great first step! Would I find details about that in the docs?

[mi-hol]

1. 4h chart is empty

a day later the 4h chart shows ;) Maybe the scaling had to adapt.

the 24h chart seems to confirm my guess

[mi-hol]

weiteres Problem ist die Datumsanzeige im US Format, obwohl der Rest auf DE Format gestellt ist

[mi-hol]

weiteres Problem ist die Datumsanzeige im US Format, obwohl der Rest auf DE Format gestellt ist

• Im Vergleich zum Original .tas finde ich die vollständige Datum und Uhrzeitanzeige tatsächlich besser, nur sollte das Format zum Setting passen.
• Das Diagram in .tas koloriert auch die Fläche, was für die Lesbarkeit besser ist
• im .tas wird bei "Restart" alle Daten vorher gespeichert, um Lücken in den Charts zu vermeiden

[gemu2015]

Danke fürs ausführliche Testen! Die Punkte aus deinem letzten Kommentar sind umgesetzt (Pull nötig — Firmware und die gebündelte tinyc_ide.html.gz):

• Datum DE-Format: 4h/24h-Charts zeigen im Tooltip jetzt dd.MM.yyyy HH:mm, unabhängig von der Browser-Locale.
• Gefüllte Fläche: 4h/24h sind jetzt gefüllte Area-Charts, wie im .tas.
• Speichern bei Restart: CleanUp() (Restart/OTA) und OnExit() (Slot-Stop/Reload) sichern die Chartdaten → keine Lücken mehr nach Neustart (entspricht >R). Die Arrays sind zusätzlich persist.
• Dunklerer Hintergrund: jetzt auch auf den drei Spalten-Charts (Tage/Einspeisung/Monate), passend zu den Linien-/Area-Charts (#f0f2f5).

Dahinter steckt ein neues generisches Builtin WebChartJS("…"): eigenes JS an einen WebChart hängen (läuft im Draw mit dt/o/el; o.done=1 übernimmt das Zeichnen selbst). Damit brauchen künftige Chart-Anpassungen keine Firmware-Änderung mehr. Doku: TinyC_Reference.md, Abschnitt WebChart.

Datenformat binär vs. tab-getrennt: per #define CHART_CSV im Script wählbar (Kommentar in sml_chart_common.tc). Den leeren 4h-Chart und die .tas-Migration (data.csv) schaue ich separat an.

[mi-hol]

Pull nötig — Firmware und die gebündelte tinyc_ide.html.gz

Super!!
Es ist also TinyC 6.17 notwendig, aber die ist noch nicht auf den Releases verfügbar.
Wird es die heute noch geben?

[mi-hol]

• Datum DE-Format: 4h/24h-Charts zeigen im Tooltip jetzt dd.MM.yyyy HH:mm, unabhängig von der Browser-Locale.

mit 6.20 getestet und ist perfekt!

Im oberen Teil der WebPage gibt es aber jetzt gemischte Dezimaltrenner (, und .)

Verbesserungsvorschläge:

1. Könnte man in dem Zusammenhang vielleicht auch die Ausrichtung der Zahlenwerte nach dem Dezimaltrenner (wie in einer Tabellenkalkulation) einführen?
2. Könnte man mehrspaltige Anzeige ermöglichen?
   Beispiel:
   statt: "M100 Leistung_L1 18 W"
   neu: "M100 L1 Leistung/Spannung 18 W / 238 V"

[mi-hol]

3. die im obigen ScreenShot gezeigten Monats- & Tageswerte sind wohl wegen fehlenden Logik in der Initialisierung identisch zu den Jahreswerten, ich meine das .tas hatte da eine passende Logik, bin aber nicht sicher

[mi-hol]

Wie "aktiviere" ich jetzt mittels sml_chart_editor.html korrigierte Monats- & Tageswerte?

• Reboot würde die korrigierten Werte überschreiben
• "Zählerwerte initialisieren" und "Balkendiagramme zurücksetzten" habe ich erfolglos probiert

Fehlt ein "Lade Werte aus gespeicherten Diagrammdaten" als Button?

[gemu2015]

Kurzes Update zum leeren 4h-Chart (nach Pull):

Ursache gefunden — der Schreib-Index des 4h-Charts (((hour-4)%24)*120+…) lag nur in den Stunden 04:00–08:00 unter der < 480-Grenze. Außerhalb dieses Fensters wurde gar nichts ins 4h-Array geschrieben → Chart leer (der 24h-Chart war nie betroffen, weil sein Index hour*60+min den ganzen Tag abdeckt). Das erklärt auch, warum er „einen Tag später" mal etwas zeigte.

Fix: der 4h-Chart ist jetzt ein 240-Slot-Ring à 1 min ((hour*60+min)%240) — speichert zu jeder Uhrzeit, gleitend die letzten 4 h. Nebenbei stimmt damit auch die X-Achse: 240 Punkte bei interval=1 ergeben eine echte 4-h-Achse (vorher wurden 480 30-s-Punkte über 8 h gezeichnet). Auflösung jetzt 1 min statt 30 s, wie beim 24h-Chart. Das Speicherformat ändert sich nicht.

Zur .tas-Migration / Datenformat: mit #define CHART_CSV (im Script-Kopf, vor dem Include) werden die Arrays als TAB-getrennte, les- und editierbare CSV (/sml_chart*.csv) statt binär gespeichert — der „erste Schritt" für die Migration, den du angesprochen hattest, im selben Stil wie der Scripter. Standard bleibt binär (kompakter).

[mi-hol]

Standard bleibt binär (kompakter)

Damit dann Daten von Benutzern bearbeitet/weiterverwendet werden können, planst Du einen "Editor" für binär gespeicherte Daten und im-/export Funktionen ?

[gemu2015]

du kannst doch jederzeit die andere Version nehmen, sind doch beide im Quelltext

[mi-hol]

Das ist jetzt nicht direkt eine Antwort auf die Frage.
In meiner Welt ist nun mal die Usability für Endbenutzer die Entscheidungsgrundlage für "Standards", deshalb würde ich den Standard anders setzen. ;-)

[gemu2015]

so das hat Claude in nicht mal 5 Minuten für dich gebaut!!!!! (sml_chart_editor.html: siehe letzter push)

[gemu2015]

Hi mi-hol,

zu Deinem Wunsch, die Roh-Chart-Dateien ansehen und editieren zu können — ein kleiner HTML-Editor steht jetzt bereit, wahlweise lokal oder direkt auf dem Gerät:

• Tool: sml_chart_editor.html — eine einzige HTML-Datei, keine Installation. Liest/schreibt /sml_chart.bin (4-Byte Little-Endian float32, ohne Header) und das #define CHART_CSV Tab-Format. Pro Array Chart + editierbare Werte-Box + min/max/avg.
• Auf dem Gerät (ab TinyC 1.6.21): vorgefertigtes sml_chart_editor.html.gz (~7 KB) im Dateimanager (http://<gerät>/ufsd) hochladen, dann http://<gerät>/cedit im Browser öffnen. Load from device → editieren → Save to device + restart slot. Kein manuelles Herunterladen/Hochladen mehr.

Kurzanleitung mit Endpoints + Troubleshooting: sml_chart_editor_on_device.md. Live verifiziert auf einem ESP32-S3 (Load → einen Wert geändert → Save → erneutes Lesen liefert byte-genau die geänderten Bytes).

Dezimaltrennzeichen-Locale (Komma vs. Punkt) ist getrennt eingeplant.

[mi-hol]

• eine echte data.csv als Referenz

von meinem C3 der das Ottelo PV script vom 24.01.2026 ausführt
data.zip

Testen mit sml_chart_pv.tc — das war zwei Probleme in einem:

Wie gedacht, kannte ich wohl eine Annahme nicht, aber es hat sich ja jetzt alles geklärt :)

[gemu2015]

@mi-hol Danke für die data.csv — damit war die Migration entscheidbar. Format-Reverse-Engineering aus ottelos 2_SML_Chart_PV.tas:

fwa(s4h fr)     → line 0  (481)
fwa(s24h fr)    → line 1  (1441)
fwa(dcon fr)    → line 2  (31)
fwa(dprod fr)   → line 3  (31)
fwa(mcon fr)    → line 4  (24, [0..11]=Verbrauch via sml[2], [12..23]=Erzeugung via sml[3])

Der TinyC-Port (sml_chart_pv.tc) splittet das eine mcon[24] in zwei Arrays (sml_mcon[12] + sml_mprod[12]) und ordnet die Tail-Sektion um zu dcon | mcon | dprod | mprod. Macht Summe = 2008 Floats wie schon im Preset hinterlegt.

Importer ist drin (Commit 44a0ac2d1 auf universal):

• Neuer Button "Import Scripter data.csv (PV)" im Editor (unter der Drop-Zone)
• Validiert die 5 Zeilen mit den erwarteten Spaltenzahlen
• Macht die Umordnung + mcon[24]-Split automatisch
• Wählt das pv-Preset, lädt die 2008 Floats in die Editor-Sektionen → du kannst alles durchsehen
• Dann ein Klick auf "Save to device + restart slot" → /sml_chart_pv.bin ist geschrieben, sml_chart_pv.tc wird neu geladen

Verifiziert mit deiner echten data.csv: Spaltenzahlen stimmen, 2008 Floats produziert, die Monatswerte sehen nach realem PV-Jahresmuster aus (Januar 183 kWh Verbrauch / 0,71 kWh Erzeugung → April 28 kWh / 73 kWh).

Pull universal, sml_chart_editor.html.gz aufs Device, /cedit neu laden — der neue Button erscheint unter dem Drop-Bereich.

— gemu (via Claude)

[mi-hol]

Pull universal

Bringt mir leider nichts, da ich keine Umgebung zum kompilieren habe. Ich warte auf den nächsten Release um weiter zu testen.

[mi-hol]

Pull universal

Bringt mir leider nichts, da ich keine Umgebung zum kompilieren habe.

@gemu2015 vielleicht darf ich in dem Zusammenhang an #65 erinnern

Wäre dein Repo fork mit dem upstream synced, könnte ich unabhängiger von Releases testen

[mi-hol]

Pull universal

Bringt mir leider nichts, da ich keine Umgebung zum kompilieren habe.

@gemu2015 vielleicht darf ich in dem Zusammenhang an #65 erinnern

@gemu2015 da wohl gestern Dienste bei Github ausgefallen waren, bin ich nicht sicher, ob Du diese Kommentare gesehen hast. Momentan bin ich fürs weitere Testen deshalb blockiert.

[mi-hol]

Nächster Test mit TinyC v1.6.23 zeigt noch nach Import von data.csv ein fehlerhafter Chart "Monatsverbraeuche / -einspeisungen Jahresansicht", wobei die Werte von den korrekt angezeigten im SML Chart Data Editor abweichen!

Korrekt im SML Chart Data Editor:

Falsch im Hauptmenü:

[mi-hol]

Habe ich vielleicht eine falsche Version vom sml_chart_pv.tcb?
Muss auch das sml_chart_pv.tc vorhanden sein?

[mi-hol]

Habe ich vielleicht eine falsche Version vom sml_chart_pv.tcb?

@gemu2015 auch nach nochmaligem .tcb download und slot restart passen die Charts nicht zu den Daten!

[mi-hol]

@gemu2015 auch nach nochmaligem .tcb download und slot restart passen die Charts nicht zu den Daten!

@gemu2015 @ottelo9 könnten wir bitte in die Datenübernahme von data.csv zu sml_chart_pv.bin nochmal reinschauen?
Aus meiner Sicht ist das der letzte Blocker um von Ottelos .tas auf die neuen .tc Skripte umzustellen.

[gemu2015]

@mi-hol Gefunden — und es ist genau die Datenübernahme, kein Skalierungs-/Datenfehler.

Ursache

Der TinyC-Port sml_chart_pv.tc legt die Daten in zwei Dateien ab (nicht in einer):

• /sml_chart.bin = s4h | s24h | dcon | mcon → 1965 Floats (Verbrauchsseite, aus sml_chart_common)
• /sml_chart_pv.bin = dprod | mprod → 43 Floats (Einspeiseseite, aus sml_chart_pv_common)

Das Monatschart („Monatsverbräuche / -einspeisungen") liest sml_mcon aus /sml_chart.bin und sml_mprod aus /sml_chart_pv.bin.

Der data.csv-Import im SML Chart Data Editor hat aber eine einzige kombinierte Datei mit 2008 Floats nach /sml_chart_pv.bin geschrieben. Folge:

• Die Firmware liest aus /sml_chart_pv.bin nur die ersten 43 Floats als dprod/mprod — das ist aber der Anfang des 4h-Charts → Müll bei der Einspeisung.
• /sml_chart.bin (Verbrauch) wurde vom Import nie geschrieben → sml_mcon blieb alt/leer.

Der Editor selbst zeigte korrekt an, weil er die Datei mit seinem eigenen (veralteten) 2008-Modell wieder einliest — daher „im Editor richtig, im Hauptmenü falsch".

Fix

Der data.csv-Importer schreibt jetzt beide Dateien passend zur Firmware:
sml_chart.bin (1965) und sml_chart_pv.bin (43).

Mit deiner angehängten sml_chart_pv.bin gegengeprüft — nach dem Fix kommt es bei der Firmware korrekt an:

• mcon (Verbrauch): 183.44, 130.64, 70.49, 28.84, 5.49, …, 168.25
• mprod (Einspeisung): 0.71, 0.99, 1.74, 73.67, 79.70, …, 0.48

So gehst du vor (nach dem nächsten Pull von universal):

1. Editor neu laden (http://<device>/cedit, ggf. Cache leeren).
2. Button „Import Scripter data.csv (PV)" → deine data.csv wählen.
3. Es werden zwei Dateien heruntergeladen: sml_chart.bin + sml_chart_pv.bin.
4. Beide über den Tasmota-Dateimanager hochladen.
5. Slot neu starten (TinyCStop 0; TinyCRun /sml_chart_pv.tcb).

Damit sollte das der letzte Migrations-Blocker gewesen sein. Dein größeres Thema (selbstbeschreibendes Format / Zeitreihen-DB) ist davon unberührt — das diskutieren wir hier separat weiter.

[mi-hol]

Damit sollte das der letzte Migrations-Blocker gewesen sein

@gemu2015 Sieht bei mir auf TinyC Test Build v1.6.28 immer noch nicht richtig aus. Brauche ich einen neueren Build?

Die Claude Kommentare "Verified against mi-hol's attached 8032-byte sml_chart_pv.bin: after the split, simulating the
firmware reading both bins yields the correct monthly values (mcon 183.44/130.64/70.49/...,
mprod 0.71/0.99/1.74/73.67/79.70/...)" zeigen ja leider nicht das Endergebnis

Bitte mach doch mal selbst den ganzen Prozeß durch und poste einen ScreenShot.

Was ich bekomme:

[gemu2015]

@mi-hol Ich habe den kompletten Ablauf jetzt mit deiner angehängten data.csv auf einem echten ESP32‑S3 durchgespielt — und den eigentlichen Fehler gefunden. Es lag nicht am Importer (der war korrekt), sondern an einem Auto‑Rückschreiben beim Slot‑Neustart.

Ursache: sml_chart_common.tc schreibt seine Daten beim Beenden des Slots (OnExit/CleanUp) zurück nach /sml_chart.bin. Im Ablauf „Bin hochladen → Slot neu starten" feuert dieses Rückschreiben des alten Slots nach deinem frischen Upload und bevor die neue Instanz liest → dein Import wird überschrieben. /sml_chart_pv.bin wird beim Beenden nicht gespeichert — deshalb blieb die Einspeisung korrekt und nur der Monatsverbrauch war falsch (genau dein Symptom). Live reproduziert: /sml_chart.bin wurde beim Neustart auf 48 Byte gekürzt.

Beweis — mit deiner data.csv in einem frischen Slot geladen, liefert das Gerät exakt diese Monatswerte (die echte Chart‑Tabelle vom Gerät, keine Simulation):

Monat   Verbrauch / Einspeisung
Jan     183.44 / 0.71     Feb 130.64 / 0.99     Maer 70.49 / 1.74
Apr      28.84 / 73.67    Mai   5.49 / 79.70      ...   Dez 168.25 / 0.48

Fix (committet auf universal):

• sml_chart_common.tc: ein dirty‑Flag — der Exit‑Rückschreib läuft nur noch, wenn der Zähler die Daten seit dem Laden tatsächlich verändert hat. Ein Ablauf Slot stoppen → Bins hochladen → Slot starten überschreibt deinen Import jetzt nicht mehr.
• sml_chart_editor.html: „Save to device" macht jetzt stop → upload → run (vorher upload → stop → run, was den Clobber ausgelöst hat).

Was du brauchst: den nächsten Test‑Build (enthält den Importer‑Fix und diesen neuen Fix). Beim manuellen Weg dann bitte: erst TinyCStop 0, dann beide Dateien (sml_chart.bin + sml_chart_pv.bin) über den Dateimanager hochladen, dann TinyCRun 0. Wenn du den Editor direkt am Gerät unter /cedit benutzt, macht er die richtige Reihenfolge jetzt automatisch.

[mi-hol]

@gemu2015 Danke für die End2End Prüfung, jetzt funktioniert der Datenimport korrekt!
Ein kleine Nebenwirkung gibt es allerdings:

SML disabled (Rule1 off)

Konsole Log:

12:56:44.166 CMD: TinyCRun /sml_chart_pv.tcb
12:56:44.174 TCC: heap handle 1 invalid (data=0 handles=0 alive=0)
12:56:44.175 TCC: heap handle 2 invalid (data=0 handles=0 alive=0)
12:56:44.175 TCC: heap handle 3 invalid (data=0 handles=0 alive=0)
12:56:44.311 TCC: heap handle 1 invalid (data=0 handles=0 alive=0)
12:56:44.311 TCC: heap handle 2 invalid (data=0 handles=0 alive=0)
12:56:44.311 TCC: heap handle 3 invalid (data=0 handles=0 alive=0)
12:56:44.446 TCC: Loaded /sml_chart_pv.tcb (8013 bytes) into slot 0
12:56:44.468 TCC: persist layout changed (B1E02919->E3FC8452) — rotating /sml_chart_pv.pvs
12:56:44.508 TCC: persist /sml_chart_pv.pvs -> /sml_chart_pv.pvs.bak (recoverable)
12:56:44.509 TCC: VM task started (/sml_chart_pv.tcb)
12:56:44.510 TCC: Program started (/sml_chart_pv.tcb)
12:56:44.510 RSL: RESULT = {"TinyCRun":"Done"}
12:56:44.575 TCC: smlScripterLoad('/sml_meter.def') = 0 (>F=0 >S=0)
12:56:44.576 TCC: sml_chart_pv: started rx=-1 tx=-1 meter=0 activ=0 sndpwr=0
12:56:44.578 TCC: Halted after 129 instr, 6 callbacks
12:56:44.708 SML: init skipped - because disabled (Settings->rule_enabled bit 0 == 0)
12:56:44.709 RSL: RESULT = {"Time":"2026-06-02T12:56:44","SML":{"CMD":"restart"}}

[gemu2015]

@mi-hol Super, danke fürs Bestätigen — freut mich, dass der Import jetzt sauber durchläuft!

Zu den heap handle invalid-Zeilen: harmlos, kein Datenverlust. Das ist VM-Log-Rauschen während des Teardowns beim allerersten Start des neuen .tcb:

• Der Fix hat eine (nicht-persistente) Variable ergänzt → dadurch hat sich die Persist-Layout-Prüfsumme geändert (dein Log: B1E02919→E3FC8452) → einmalige .pvs-Rotation.
• Beim Aufräumen werden die Heap-Arrays kurz nach dem Heap-Free noch aufgelöst → die VM gibt sicher null zurück (kein Crash) und hat das nur zu laut als ERROR geloggt.
• Tritt beim nächsten Neustart nicht mehr auf — deine .pvs passt jetzt zum neuen Layout.

Zwei Hinweise:

1. Die Chart-Daten überleben die Rotation (die liegen in /sml_chart.bin und werden beim Start neu geladen) — deshalb ist dein Import korrekt.
2. Die Rotation hat den Config-Persist einmalig auf Default zurückgesetzt — dein Log zeigt rx=-1 tx=-1. Prüf bitte deine SML-Pins (RX/TX) und stell sie ggf. neu ein.

Die Log-Zeile hab ich entschärft (ERROR→Debug, wenn der Heap beim Teardown ohnehin weg ist) — kommt mit dem nächsten Build, dann ist auch das Rauschen weg.

[gemu2015]

Ja ok dann weis ich nicht was deinen bootloop verursacht hat. Der bootloop schaltet sowohl sml als auch Tinyc ab

[mi-hol]

@gemu2015
Bootloop wird durch folgenden Eintrag erzeugt

;Meter ID des Netzbetreibers
1,0x0100000000ff,SID,,meter_id,0

Der kommt von https://tasmota-sml-parser.dicp.net/decode

Dekodierte SML Nachrichten:

OBIS (hex) OBIS Name Wert Einheit Parsed
0x0100000000ff 0.0.0 Unbekannter Datentyp 1ESYxxxxxxx Unbekannte Einheit 1ESYxxxxxxxUnbekannte Einheit (Unbekannter Datentyp)

Die "Unbekannte Einheit / Unbekannter Datentyp" könnten die Ursache sein

[gemu2015]

das ist ein Syntax Fehler, alle Zeilen müssen am Ende des Decoders ein "@" Zeichen haben.
1,0x0100000000ff@#,SID,,meter_id,0

Wir können nicht wirklich alle Syntax Fehler abfangen, haben aber das jetzt behoben
Im nächsten test build wir es drin sein.

[mi-hol]

Wir können nicht wirklich alle Syntax Fehler abfangen

Aber es scheint, dass hier "optimistische" Codierung die falsche Annahme ( daß alles richtig definiert wurde) trifft und dann im Fehlerfall keinen Fehler an den Caller zurück gibt. Könnte das auf "pessimistische" Codierung (erst wenn alle Inputs Validierung bestehen) geht es weiter, verbessert werden?

[gemu2015]

Nein, du vergisst wie sind auf einem minimalem System und wenn wir wirklich alles abfangen würden würde das viel zu viel Flash Speicher verbrauchen.