openWB Forum

Angezeigte Reichweite halte ich für schwierig wenn Features wie "Lade bis xx%" aktiv sind und entsprechend dann nicht direkt schlüssig ist warum gerade geladen wird oder auch nicht.

...meine einfache Gedankenwelt ist, dass der Zusammenhang SoC% und Reichweite ein "einfacher Dreisatz" zum letzten Durchschnittsverbrauch und der Netto/Nutzbaren Kapazität der Fahrbatterie ist.
Entweder berechnet ihn ein intelligentes Auto selbst und schickt es über den "SoC-Link" mit oder die openWB macht das über den manuellen SoC-Modus.

Die Reichweite ist ein Zustand des EV, keine Aktivität/Zustand der openWB.
Wieso sollte jemand das miteinander verwechseln?

Wäre es ggf. eine Idee, den jeweils anderen Wert als Mouse-Over anzuzeigen?

openWB hat geschrieben: ↑Mo Apr 26, 2021 6:07 am Angezeigte Reichweite halte ich für schwierig wenn Features wie "Lade bis xx%" aktiv sind und entsprechend dann nicht direkt schlüssig ist warum gerade geladen wird oder auch nicht.

ich könnte mir vorstellen, dass der SoC/km-Wert rot wird, wenn er der Grund für eine "Ladesperre" wird.

bye
TW

Bei Maisbedienung denkbar, auf dem Touch Display am Handy, oder Tablet ist Mouse Oberfläche eher schwierig
Und auf dem Handy ist bereits jetzt die SoC Anzeige/ Refresh sehr klein, aber ja ich hätte das auch gerne irgendwie visualisiert, sehe es aber eher als nachrangig zu SoC.

VG
Det

derNeueDet hat geschrieben: ↑Mo Apr 26, 2021 6:46 am Bei Mausbedienung denkbar, auf dem Touch Display am Handy, oder Tablet ist Mouse Oberfläche eher schwierig
Und auf dem Handy ist bereits jetzt die SoC Anzeige/ Refresh sehr klein, aber ja ich hätte das auch gerne irgendwie visualisiert,

Wie wäre es mit Umschalten durch drauf tippen?
Standard wäre "SoC", auf den auch beim Neuladen der Seite zurückgekehrt wird (keine Konfiguration nötig).

derNeueDet hat geschrieben: ↑Mo Apr 26, 2021 6:46 am sehe es aber eher als nachrangig zu SoC.

VG
Det

bye
TW

Also mein simpler request wäre es, die über die soc Module ermittelte original Reichweite (ist) in der openWB verfügbar zu machen. (Mqtt).

Anzeige ist noch was anderes, aber da wird bei soc auch nur stumpf der aktuell ermittelte wert angezeigt.

Eine Berechnung funzt nur bedingt, daher KISS-Prinzip

FosCo hat geschrieben: ↑Mo Apr 26, 2021 8:23 am Also mein simpler request wäre es, die über die soc Module ermittelte original Reichweite (ist) in der openWB verfügbar zu machen. (Mqtt).

dem Topic ist es egal, woher es kommt...kann auch ein andere Mechanismus sein.
Im manuellen SoC Modul gibt es auch eine SoC Anzeige.

Anzeige ist noch was anderes, aber da wird bei soc auch nur stumpf der aktuell ermittelte wert angezeigt.

...da widersprichst Du Dir selbst bzw. gibst schon die Antwort.
Es sind nur zwei Implementierungs-Schritte...zuerst die Daten erfassen (SoC-Link aktives Modul/manuelles Modul und im mqtt bereitstellen) und dann die Daten nutzen, zB anzeigen.
Ich habe nix dagegen zunächst nur Schritt eins umzusetzen....wofür gibt es denn Releases

Eine Berechnung funzt nur bedingt, daher KISS-Prinzip

Die Berechnung ist nur für den manuellen SoC- Modus notwendig, aber alle Daten sind doch heute schon in der openWB vorhanden.
Die geladenen km werden doch auch schon berechnet.
Ich würde schon dafür plädieren so ein Feature nicht von einzelnen SoC-Modulen abhängig zu machen.
Ob die Berechnung, je nach Modul, genauer ist oder nicht, steht auf einem anderen Blatt.

Die Berechnung kann leider nur unscharf sein, macht aber nichts bei geladenen km. Die Hersteller Anzeige bezieht halt noch Umgebungsdaten (Temperatur, Verbrauch bei Fahrweise, etc) mit ein.
Wenn wir nen generelles range MQTT topic haben, was ein soc Modul befüllt (befüllen kann), bin ich glücklich

P.S. Mit ein paar stupsen in die richtige Richtung eines generischen Ansatzes helfe ich gerne! Aber die MQTT Verwaltung kriege ich noch nicht auf die Pfanne...

Soweit ich das aus dem Mercedes EQ SoC Modul weiß,
arbeiten die SoC Module mit der Ramdisk und nicht direkt mit Mqtt. Da der SoC ja aber in Mqtt auch ankommt, ist irgendwo im Core der openWB dieser Feed implementiert. Bedeutet also, zuerst müsste eine entsprechende Datei für die Ramdisk definiert werden (pro LP) und der Core entsprechend erweitert werden.

... oder es kommt erst mit V2.0.

Ja, das läuft über die ramdisk, genau das verwirrt mich noch in der Struktur.

Mein Usecase, den Range ausschließlich über das SoC Modul zu beziehen ist ja etwas kurz gegriffen, da hat hominidae schon vollkommen recht.

Aber dann wird eine Umsetzung sehr langwierig, zumindest wenn ich mir die mqtt und soc bezüge so in den verschiedenen Files anschaue.


Wo wäre denn eine "gemeinsam genutzte" range variable gut aufgehoben?

Da "die 2.0" bisher für mich eine BlackBox ist (funktional und zeitlich gesehen) habe ich keine Ahnung inwiefern es sich noch lohnt, da jetzt aufwändig was in die aktuelle Umsetzung reinzufrickeln. Auf meinem Flurdisplay reicht mir meine simple "lineare Faktorberechnung" erstmal, aber zum Winter hin wird's dann wieder interessant mit den Originaldaten ohne Umweg über die Hersteller-App.