Die grundsätzliche Frage ist ja, ob man einen erkannten Fehlerzustand als gesonderten Zustand in der weiteren Verarbeitung betrachten mag. So wie sich das für mich hier liest, ist das aktuell nicht der Fall und ein Fehlerwert wird nicht explizit als Fehler betrachtet. Da müsste also noch nachgebessert werden und bei jedem Messwert entschieden werden, wie im Fehlerfalle darauf zu reagieren ist.
Dass das nicht für alle gleich ist, kann man am fehlerhaften SoC schön erkennen: der eine will das Auto geladen haben, damit er morgens vom Hof kommt und der andere möchte lieber nicht laden, als zu riskieren inakzeptabel hohe Strompreise bezahlen zu müssen.
In der Konsequenz bedeutet das, dass es je Messwert und Entscheidung einstellbar sein muss, wie die Entscheidung bei einem Fehlerwert zu fällen ist. Ist ein Haufen voll Arbeit, den man sich damit so aufhalst.
Die generelle Aussage, im Fehlerfalle einen konstanten Wert anzunehmen und damit weiterzuarbeiten wäre handwerkich nicht in Ordnung halte ich auch nicht für grundsätzlich korrekt. Dafür habe ich in meinem
Leben schon zu oft das Ergebnis einer Division durch Null auf Null gesetzt, weil das in der Anwendung dem erwarteten Programmverhalten am Nächsten kam. Der Auftraggeber wäre in den meisten Fällen auch nicht in der Lage gewesen, da etwas besonderes uu spezifizieren. Und das gesamte Ergebnis einer Auswertung auf NaN, NULL oder n/a zu setzen ist aus Anwendersicht inakzeptabel.
Um nochmal auf den SoC und die Null zurückzukommen: zu laden obwohl der SoC nicht kommt ist ja letzten Endes nur dann doof, wenn man am nächsten Tag das Auto nicht braucht. Womit wir beim kalenderabhängigen Fehler-Default-Verhalten wären…
Zielladen trotzdem durchführen obwohl SOC fehlt
Re: Zielladen trotzdem durchführen obwohl SOC fehlt
Ja war auf 0 hat aber nicht geladen. Im Status gabs dann halt eine Fehlermeldung. Kann auch nach 8h auch keine logs mehr postet, weil die nicht so lange gehen.mrinas hat geschrieben: ↑Fr Jul 26, 2024 1:52 pm Hast Du Logs von dem Zustand? Denn eigentlich ist es so das bei mehrfach fehlgeschlagenem SoC dieser auf 0 gesetzt wird um genau solche Szenarien zu verhindern.
Kenne jetzt alle Details und Szenarien nicht, hier könnten die Logs helfen zu verstehen warum nicht geladen wurde.
Wenn jetzt wirklich jemand der Meinung ist, dass er das nicht möchte ist mir das Recht. Aber dann sollte wenigstens ein Slider in der Konfig sein, dass man bei Fehlern den Soc bzw. Tibber ignoriert. Ob jetzt 0% oder der letzte empfangene Soc wäre mir egal. Wobei ja 0% auf der Hauptseite stand und er gar nicht geladen hat. War auch jetzt schon das 2. mal. Vor ein paar Monaten hat Hyundai die Anzahl an Aktualisierungen runter gesetzt. Gab dann auch eine Fehlermeldung, dass zu oft abgefragt wurde. Hat dann auch nicht geladen. Es kann ja auch mal sein, dass das Internet ausfällt. Passiert bei mir zwar nie aber was würde er dann machen?Gero hat geschrieben: ↑Mo Jul 29, 2024 12:00 pm Die grundsätzliche Frage ist ja, ob man einen erkannten Fehlerzustand als gesonderten Zustand in der weiteren Verarbeitung betrachten mag. So wie sich das für mich hier liest, ist das aktuell nicht der Fall und ein Fehlerwert wird nicht explizit als Fehler betrachtet. Da müsste also noch nachgebessert werden und bei jedem Messwert entschieden werden, wie im Fehlerfalle darauf zu reagieren ist.
Dass das nicht für alle gleich ist, kann man am fehlerhaften SoC schön erkennen: der eine will das Auto geladen haben, damit er morgens vom Hof kommt und der andere möchte lieber nicht laden, als zu riskieren inakzeptabel hohe Strompreise bezahlen zu müssen.
In der Konsequenz bedeutet das, dass es je Messwert und Entscheidung einstellbar sein muss, wie die Entscheidung bei einem Fehlerwert zu fällen ist. Ist ein Haufen voll Arbeit, den man sich damit so aufhalst.
Die generelle Aussage, im Fehlerfalle einen konstanten Wert anzunehmen und damit weiterzuarbeiten wäre handwerkich nicht in Ordnung halte ich auch nicht für grundsätzlich korrekt. Dafür habe ich in meinem
Leben schon zu oft das Ergebnis einer Division durch Null auf Null gesetzt, weil das in der Anwendung dem erwarteten Programmverhalten am Nächsten kam. Der Auftraggeber wäre in den meisten Fällen auch nicht in der Lage gewesen, da etwas besonderes uu spezifizieren. Und das gesamte Ergebnis einer Auswertung auf NaN, NULL oder n/a zu setzen ist aus Anwendersicht inakzeptabel.
Um nochmal auf den SoC und die Null zurückzukommen: zu laden obwohl der SoC nicht kommt ist ja letzten Endes nur dann doof, wenn man am nächsten Tag das Auto nicht braucht. Womit wir beim kalenderabhängigen Fehler-Default-Verhalten wären…
Ich kann das auch sonst nicht meiner Freundin erklären wenn sie morgens vor dem leeren Auto steht und Termine auf der Arbeit hat. Sowas hat richtig Sprengstoff.
Mir würde eine Funktion reichen die bei Fehler Tibber oder SOC auf Softladen umschaltet. Lieber 2€ zu viel zahlen als zu spät zur Arbeit zu kommen.
Im Moment ist es so, dass wir gar nicht viel an der OpenWB rumfummeln. Meiner steht immer auf PV laden und ich komm damit gut durch. Ihrer steht immer auf Zielladen und sie stellt den nur Freitags auf PV laden und Montags wieder um. Das ist alles richtig gut und perfekt gelöst solange alles funktioniert.