[≈≈≈] DEBUG - Terminal Ausgabe konsolidieren

[karamo]

FW 4.35p

Die Ausgabe am Terminal ist extrem unruhig und schwer lesbar durch die sehr unterschiedlichen Ausgabeformate:

mit/ohne Zeitstempel

inkonsistente Struktur der Zeilenkennung:

• Zeilen ohne Kennung z.B. TripleClick
• Zeilen mit Kennung sehr unterschiedlich:
  • alles groß z.B. [BATT]
  • groß/klein z.B. [Web] [LoRa]
  • mit Leerzeichen z.B. [GPS ]
  • unterschiedliche Länge: da wurde tw. auf 4 Zeichen gestutzt, z.B. war[PSRAM]auf [PSRM], um dann aber doch bis zu 6 Zeichen z.B. [MC-DBG] Kennungen zu haben, oder auch mehr, z.B. [readBatteryVoltage] 22:06:56 ... 2.08 V 0% max_batt 4.125 V

Debug/Daten Ausgabezeilen:

Darüber kann man diskutieren, wie die gestaltet sein sollten/könnten:

• ich habe bei bei "meinen" Teilen die so gestaltet, dass man die nach der Kennung gefiltert gleich als CSV-Datei einfach weiter verarbeiten kann: Zeitstempel, Kennung, Daten; und Delimiter ";" z.B:

 21:45:35;[HEAP];131612;(free)
 21:45:35;[TEMP];27.90;off

• andere Zeilen enthalten "..." ohne Space vor & nachher, wofür ich keine Notwendigkeit sehe, und andere Eigenheiten, die ein Parsen erschweren:
  z.B. 22:06:56 [BATT]...reading: 694 factor: 3.0000 voltage: 2082.25 mV

• Zeilen mit Werten sind tw. in der Form

  • mit "=" z.B. wait=4605
  • mit ": " z.B. Date: 2000.00.00
  • mit ":" z.B. hdop:25.5

• ich habe in einem Fall bei der Angabe der Einheit eines Wertes diese mit "_" getrennt, um als Delimiter " " (space) anwenden zu können. Besser wäre aber durchgehend ";" als Delimiter
  z.B. NTC-Temp: 29.019_°C 2086_raw 1795.000_mV 8384.40_Ohm
  ev. besser: 21:54:12;[NTCT];29.019;°C;2086;raw;1795.000;mV;8384.40;Ohm
  Es wird dadurch zwar ncht unbedingt besser lesbar, aber viel leichter weiter auswertbar.
  Für bessere Lesbarkeit könnte man ein " " nach dem Delimiter einführen:
  21:54:12; [NTCT]; 29.019; °C; 2086; raw; 1795.000; mV; 8384.40; Ohm

Ich stelle das mal zur Diskussion mit der Frage, ob es nicht sinnvoll wäre, zu einer einheitlichen Struktur zu kommen?

[oe1kbc]

Gute Idee, wir werden über das logging einen eigene prog-thread aufmachen.

[karamo]

Ich würde das JSON-Format vorschlagen, wie ich es z.B. bei meinem Musterprojekt mache:

[TX_MQTT] {"date":"2026-03-24","time":"12:19:30","v":2,"Id":"18A629B4","cnt":77,"volt":5.243}

• Kennung in [...], "date" und "time" sind klar und immer vorhanden.
• "v" ist die Version, dh. was die folgenden Daten bedeuten.
• "Id" ist die Node-MAC
• "cnt" ist fortlaufender Zähler, um verlorengegangene Daten zu erkennen.
• "volt" ist schlussendlich der Datenwert, hier beispielsweise die Akku-Spannung

[karamo]

Der Datensatz für die NTC-Temperatur würde dann von derzeit:

NTC-Temp: 29.019_°C 2086_raw 1795.000_mV 8384.40_Ohm
oder
21:54:12; [NTCT]; 29.019; °C; 2086; raw; 1795.000; mV; 8384.40; Ohm

auf folgende geändert, wobei die Einheit der Werte in den Key eingebaut ist und der Lüfter-Status ebenfalls:

[NTC_Temp] {"time":"21:54:12", "temp_°C":29.019, "raw":2086, "mV":1795.000, "Ohm":8384.40, "fan":0}

• "raw" ist hier zur Kontrolle, ob ein 4095 Überlauf auftritt
• "mV" & "Ohm" sind informative Debug-Werte
• Leerzeichen nach jedem KEY:VALUE Paar dienen nur der besseren Lesbarkeit

[oe1kbc]

Diese Ideen werden umgesetzt jedoch ist eine Library angedacht welche noch im Test ist