openWB Forum

openWB hat geschrieben: Fr Apr 03, 2026 3:20 pm Wie kommst du darauf das diese Temperatur ein Problem darstellt?
Davon ab, bitte einen extra Thread, hat mit der Beta nichts zu tun.

Meine Vermutung ging dahin, dass die CPU in der 2.2 zunehmend throttelt und ggfs. einige Prozesse in den Timeout laufen.

Konnte mittlerweile ein Problem mit der MQTT-Brücke und Firewall ausmachen, werde meine Story in einen eigenen Thread posten.

Aktueller master (2026-04-02 10:32:33 +0200 [7dcf4b0a2]), Leistungswerte EVU und Hausverbrauch fehlen im Cards Display Theme.
Auf dem Display (Cards-Theme) fehlen bei EVU und Hausverbrauch die Leistungswerte, die Balken passen:

Zur allgemeinen Info (Support weiß bereits Bescheid):

Mit aktiver BV: 2x Duo

- Bei der Beta habe ich festgestellt, dass im Ladelog im Dienstwagenabrechnungs Portal die RFID Kennung fehlt. Diese fehlt aber auch im normalen Ladelog in der Open WB selbst. Interessanter Weise muss aber der RFID Tag selbst korrekt erfasst worden sein, da sonst das Fahrzeug inklusive dem passenden lademodi nicht hätte ausgewählt und korrekt im Ladelog hinterlegt werden können.
Positiv: es hat zuverlässig geladen.

- Ebenso fehlen die Daten in dem Mieterstrom Abrechnungsportal, obwohl die Daten lokal vorliegen.

- "Mqtt Fehler Ladepunkt" ist weiterhin vorhanden. Anscheinend aber nur bei der Master dafür dann bei LP1&2. Bei der Slave mit LP3&4 kommt die Meldung nicht. ( Siehe Screenshot)

Bin um zu sehen, ob die Daten nun wieder korrekt in dem Dienstwagen Portal und Mieterstrom Portal ankommen wieder auf die Release gewechselt. Sollte das funktionieren, ist vielleicht was in der 2.2.0 Beta noch nicht für die Portale programmiert oder es ist ein Bug drinnen. - hierzu gebe ich morgen Rückmeldung.

Dienstwagen- und Mieterstromportal sind immer nur auf das aktuelle (und vergangene) Release ausgelegt.

Wenn wir dem Release näher rücken wird es im Portal dann die Möglichkeit geben einen Nutzer zu definieren der die benötigten Daten abfragen darf wenn die Benutzerverwaltung genutzt wird.

Nicht ganz aktuelle Version, müsste aber in diesem Punkt dem aktuellem Stand entsprechen (2026-04-01 13:04:26 +0200 [f32b15ebe])
Ich habe gerade die SoC-Grenzen des Speichers im Koala-Theme gefunden, folgende Anmerkungen hierzu:

Wenn ich die Einstellung am Handy mache, überdecken meine "Wurstfinger" die Zahlen für die Einstellung, habe es mit viel Mühe trotzdem geschafft.
Ich brauche meist 94% bis 98%, die untere Zahl wird aber von der oberen überlagert.
Vielleicht wäre es hier besser, auch 2 Regler für untere und obere Grenze einzubauen?
Wenn die Prozentzahl dann links oder rechts neben dem Regler erscheint, wäre der Finger auch nicht mehr im Weg.
Ein Plus/Minus Button wäre zur Feineinstellung auch ganz nett.

Hallo,

aus dem Changelog zur 2.2.0 Beta 1:

Datenvalidierung: Für alle Module (Zähler, PV, Speicher) wurde eine zentrale Logik implementiert, welche fehlerhafte Daten/Auslesungen erkennen und herausfiltern soll. Speziell bei einigen per Modbus angebundenen Modulen kam es vermehrt zu Lesefehlern und unrealistischen Leistungsspitzen in den Auswertungen.

Bei meinem VARTA Batteriespeicher sehe ich weiterhin die Datenfehler (SOC geht auf Null):
Log:
https://paste.openwb.de/pOTbWkiXf46qXUN

Grüße
Proxima

Proxima hat geschrieben: Mo Apr 06, 2026 4:13 pm Hallo,

aus dem Changelog zur 2.2.0 Beta 1:

Datenvalidierung: Für alle Module (Zähler, PV, Speicher) wurde eine zentrale Logik implementiert, welche fehlerhafte Daten/Auslesungen erkennen und herausfiltern soll. Speziell bei einigen per Modbus angebundenen Modulen kam es vermehrt zu Lesefehlern und unrealistischen Leistungsspitzen in den Auswertungen.

Bei meinem VARTA Batteriespeicher sehe ich weiterhin die Datenfehler (SOC geht auf Null):
SOC.jpg


Log:
https://paste.openwb.de/pOTbWkiXf46qXUN

Grüße
Proxima

Die Datenvalidierung gilt nur für die Leistung der Module, nicht des SoC's. Es ging hier um die Peaks die zeitweise entstanden sind.

Dein Varta Speicher ist einfach nicht erreichbar, die Fehlermeldung im Log "[Errno 104] Connection reset by peer". Da würd ich mal das Netzwerk prüfen.

Hallo,

mein Netzwerk werde ich auf jeden Fall mal prüfen, jedoch hängen oWB und der Speicher am gleichen Switch und auch die Kabellängen sind mit max. 5m nicht besonders lang. Ggf. tausche ich die Kabel mal aus.

Dennoch würde ich dafür plädieren, auch die SoC's in die Datenvalidierung mit auf zu nehmen, oder bei Nichterreichen von Komponenten lieber keinen Wert als eine Null zu schreiben.

Grüße
Proxima

oder bei Nichterreichen von Komponenten

Einen leeren Wert wäre gerade für angeschlossene System noch kritischer.
Die Thematik letzter Wert oder 0 gab es auch öfter. Vielen fällt dann schlichtweg nicht auf das es nicht läuft.
Am besten ist immer noch das eigentlich Problem zu beheben anstatt es zu kaschieren.

Um es mal auszuformulieren: ein Fehlerwert statt einer Null wird i.d.R. sich statt an der Null am zuletzt bekannten Wert orientieren. Am Beispiel des Fahzeug-SoCs illustriere ich mal die Auswirkung: bekomme ich beim Laden das Fahrzeugs gerade mal keinen richtigen Wert des SoCs, bin ich mit dem zuletzt bekannten erst einmal gefühlt auf der richtigen Seite. Doof wird es, wenn es die verpasste Entladung ist: kommt das Auto nämlich mit unbekannten SoC, aber real leeren Akku an die Ladestation, wäre es in diesem Falle besser zu laden statt sich auf den letzten bekannten Wert zu berufen.

Bei stationären Akkus oder anderem Gerät gilt das natürlich analog.

Eine wegen Fehlerwert nicht durchgeführte Berechnung eines neuen Ergebnisses wiederholt das letzte bekannte Ergebnis. Das selbe wird mit einer erneuten Berechnung mit dem letztbekannten Ablesewert erreicht.

Und eine situationsabhängige Schätzung des nicht ablesbaren Werts (womöglich basierend auf vielen bekannten Vergangenheitswerten) möchte man nicht implementieren: Zu aufwendig für das erwartbare, potentiell immer noch falsche Ergebnis.