RESTART im Webfrontend resettet Werte nicht

[rejoe2]

Vorab - ähnliche Issues:

• Tagesertrag zurücksetzen (Ahoy DTU mit Batteriespeicher) #1515
• [Frage] Reset von Werten, wie am besten? #1383

Ahoy (Variante von 0.8.122, betrifft aber auch offizielle Vorgängerversionen) läuft auf einem ESP32, Kommunikation etc. sonst ist stressfrei, kein reboot@midnight oä., der ESP läuft durchgehend und ohne erkennbare Aussetzer, es sind einige Inverter, die abgefragt wird, darunter ein Inverter, der konstant und unterbrechungsfrei an einem Akku hängt.

Ziel wäre es, die Tageserträge (nur) dieses Inverters (HM-400, das Verhalten kann aber auch an anderen Typen reproduziert werden) zurückzusetzen. Lt. dem ersten o.g. issue ( #1515 ) sollte dafür ein reboot ausreichen. Tut er auch - wenn man den reboot über das Flole-Tool veranlasst und danach die Werte wieder mit Ahoy ausliest, aber:

Weist man über das Webinterface von Ahoy die Aktion "REBOOT" an, erhält man eine Bestätigung, dass der Befehl ausgeführt wurde. Aber weder werden die o.g. Werte zurückgesetzt, noch erscheint in der Alarm-Liste der aktualisierte restart-Zeitpunkt.

Allerdings scheint der Inverter trotzdem irgend eine Aktion auszuführen, denn anschließend sind vorher gesetzte (temporäre) Limits nicht mehr wirksam.

[lumapu]

kann es evtl. damit zusammenhängen, dass Ahoy sich die Yield-Werte über den Tag merkt?
Ich meine z.B.

• Feature Request: Verhindern der YieldDay Rücksetzung bei Neustart bis Tagesende #848

kann man dem flole Tool auf die Finger schauen, was genau es bei einem Reboot macht?

[rejoe2]

kann es evtl. damit zusammenhängen, dass Ahoy sich die Yield-Werte über den Tag merkt? Ich meine z.B.

Könnte sein... Da man die Inverter in Ahoy deaktivieren muss (oder Ahoy ganz abschalten), um das Tool zu nutzen, greift ggf. die Funktion nicht, die sich die Werte merkt. Hätte halt angenommen, dass sich zumindest der "start"-Alarm ändert. Ist aber auch nicht der Fall...

kann man dem flole Tool auf die Finger schauen, was genau es bei einem Reboot macht?

Nicht direkt, man müßte einen sniffer für den Funkverkehr basteln (bzw. konfigurieren?). Leider wußte flole das auch nicht aus dem Kopf, was da gesendt wird; er hat sich nach Angabe jedenfalls nicht am Ahoy- oder OpenDTU-Code orientiert.

[rejoe2]

Nachtrag noch: Falls es die interne Datenhaltung ist, sollte man die m.E. in dem Fall nicht verwenden, wenn man aktiv einen reboot oä. veranlasst (sei es via MQTT, sei es via Web-Interface).
Der verlinkte fix ist ja "nur" für den Fall, dass die Sonne zwischenzeitlich aus ist...