[Request] Store Important Logs in a Ringbuffer for 10 Minutes

[stefan123t]

Is your feature request related to a problem? Please describe.

See the discussion started here: #1216 (comment)

Okay, d.h. wenn man nicht beim Booten die Serial Console / USB beobachtet dann geht einem das verloren.
Würde es Sinn machen solche Punkte die über das übliche Serial Log bzw die Kommunikation mit dem WR hinausgehen ggf im Speicher in ein Log zu schreiben oder haben wir nicht genügend RAM für so etwas ? Evtl in das PSRAM ?
Ich wäre prinzipiell dafür unterschiedliche Log Level und ggf auch einzelne Log Module / Tags einzuführen.
Und empfangene Kommandos per MQTT / Rest API würde ich dann als Info / Warn loggen.
Die WR Kommunikation (sehr viele Hex Werte die historisch meist nicht mehr relevant sind) evtl nur als Debug / Verbose.

@schlimmchen:

Joar, das ist eine schöne Idee. Also Tags und Levels usw. geht mir zu weit. Insbesondere ist das hinderlich, wenn Leute dann die falschen Tags filtern wenn wir Logs anfordern. Da soll einfach alles drin sein. Es ist schon "kompliziert" genug, dass wir verbose logging einschalten lassen müssen. Im Downstream haben wir ja sowas wie verbose logging bei vielen "Modulen".

Allerdings ist es eine gute Idee, die frühen Nachrichten von der Initialisierung pauschal einzusammeln im RAM und dafür ein paar Kilobyte zu spendieren. Ich stelle mir das dann so vor, dass der Speicher automatisch nach einer bestimmten Uptime wieder freigegeben wird. Wenn man an den einmaligen Ausgaben beim Start interessiert ist, ist es zumutbar, die innerhalb von beispielsweise 10 Minuten nach dem Start anzuschauen, und zur 10 Minuten Marke wird der RAM dann freigegeben.

Oder man belegt immer einen kleinen Block RAM und puffert dort die letzten Nachrichten. In einem schnellen Test mit MQTT und DPL verbose logging stelle ich fest, dass 65k Text produziert werden in ca. 40 Sekunden. So ein Ringpuffer macht also wenig Sinn, denn man kann zeitlich gesehen nur ein sehr kleines Fenster festhalten, also etwa 30 Sekunden, schätze ich mal.

Magst du mal ein Request Issue erstellen für das Einsammeln und zeitlich begrenzte Vorhalten der frühen Nachrichten?

Describe the solution you'd like

The solution I'd like distinguishes between at least two log levels / tags.

• important: Info / Warn
• temporary interesting: Debug / Verbose

All messages logged to the important destination would be written to this Ring Buffer and printed verbatim in the normal Serial Log as the temporary interesting stuff, like DTU -> WR communication too.

E.g. in this example log here there is only a small amount of requests from external to the DTU or where the DTU actually tries to control the Inverter.
#809 (comment)

07:48:55.671 > Websocket: [/livedata][11] connect
...
07:49:00.325 > TX PowerControl 865.00 MHz --> 51 91 43 32 52 80 10 26 80 81 00 00 B0 01 E5 
...
07:49:02.318 > Success

To be honest I do not even care too much for the PowerControl and its subsequent Success message.
Only the REST API and MQTT Commands sent and received by the DTU, or some other control messages received via the CAN bus would be interesting.

This would allow to have a kind of "important events" log which is available ~ 10 minutes after a reboot.
When you open the Serial Console, these important events could be dumped first and then the lower level messages from the Debug / Verbose log level would be appended as we watch the Serial Console window.

Describe alternatives you've considered

Alternative is to ask users to provide USB Serial Logs instead of Web Serial Console logs, which is more difficult to retrieve for most users.
Especially when their OpenDTU is not connected via USB because being in a remote location.
Also setting up USB Serial logging is a major effort for many users.

That way we would be able to easily spot control commands / external influence on the OpenDTU, which is eventually overriding some default or internal settings.

Additional context

Having Log Levels and/or Tags / Modules for each Log Message would still allow such a default setting which stores only the most important messages in such a ring buffer.
On demand we could select to store specific Modules / Tags and/or Log Levels into the longer term memory log (PSRAM?).

If we are able to allocate a specific, dedicated memory region for the pointer into and this longer term memory, we could eventually even use it across reboots ?
Maybe even the boot / reboot reason messages could be stored somehow in such a ring buffer, e.g. for debugging nasty boot loops, etc.