Rückmeldungen 2.1.8 Release & Release Patch 1

[Gero]

...bin ich dazu gezwungen täglich wenn ich abends mein Auto anstecke zu prüfen ob auf Ziel Laden steht und nicht wieder PV gezogen wurde und mein Auto dann über Nacht nicht lädt

Dann stell doch Zielladen im Ladeprofil ein. Da ist ja PV enthalten.

Oder halt ein topic je ladepubkt das man einfach mit dem gewünschten lademodi beschreibt ...

Hatten wir ja drüben schon - da schreib' ich mal einen Feature-Requiest, damit an der richtigen Stelle eine Erinnerung steht.

[odoll]

Und ein mehr genereller Kommentar zu dem Update Prozess: (Ich meine) früher wären die Namen der verfügbaren Versionen "sprechender" gewesen?

Klick auf Änderungen und du siehst es. Dort ist alles detailliert aufgelistet.

OK, danke für den Hinweis. Das hilft MIR (als einem "einäugier Nerd" evt. schon mal weiter), finde aber weiterhin ein paar Haare in der Suppe
(Aber löst erst mal euren wirklichen Problem in 2.1.8Px bevor es ans UI geht! Ich bleibe erst al auf 2.1.7 auch wenn ich ja per Backup zurück könnte,habe aber keine Lust "Werte" Daten für des "Ausfallzeitreaum" zu verlieren und dann mit einer Lücke im Datensatz leben zu müssen.)

Die "Haare":
Warum werden nicht trotzdem die Releases "sprechender" benannt? Geht doch bei den Feature-Release auch!

Zuddem: Kann ich als DAU verstehen, dass wenn in den Änderungen steht

2025-09-22 12:33:58 +0200 [f5d2fba8a] - Update version 2.1.8

auf welches dort angezeigte Release sich diese Änderung bezieht? (Steht vielleicht irgendwo in der Doku?)
Und selbst, wenn ich denke die Änderungen beziehen sich auf das neu angebotene Release, kann das nicht auf einfach bedeuten, dass auch die Version 2.1.8 mit den Änderungen versorgt wurde? "Update Release to version 2.1.8" wäre vielleicht wieder sprechender?

Allein, das ich als Einäugiger darüber stolpert, scheint mir Indiz genug zu sein, dass man daran feilen kann, oder?!

Trotzdem nochmals danke für den Hinweis: Zumindest ich weiß jetzt besser wie die Einträge zu interpretieren sind.

[Meth]

[/quote]
Dann stell doch Zielladen im Ladeprofil ein. Da ist ja PV enthalten.

Aber da zieht es sich die Einstellung preisbasiert
Und er ladet wenn es für das zielladen Günstig wäre.
Rein nur Pv mit Speicher Vorrang geht nicht .
Zumindest nicht so als wenn man pv als lademodi nimmt
da anscheinend diese unterschreitung der preisobergrenze vor der pv integrierung in Zielladen greift

Sonst wäre mir das doch vollkommen egal

[AlSi_8480]

• Automatisches Update für Secondaries: Wenn Primary und Seconary im Release-Zweig sind, kann das automatische Update aktiviert werden. Die Updates werden nur für Release-Versionen automatisch durchgeführt.

Nice-to-have: Die Master lädt das Update und stellt dann das Image für die Secondarys bereit.

Hintergrund:
Für Netzwerkgeräte die nicht zwingend Online sein müssen habe ich eine Internetsperre aktiviert (Switche, Drucker, SmartHome Devices, Shellys und auch die oWB Secondarys), etwaiger Zugriff von Unterwegs erfolgt per VPN. Für das Update auf 2.1.8 hatte ich die Sperre aufgehoben und dann die Master alle Updates erledigen lassen. Das ging einwandfrei und die 2.1.8 läuft anstandslos auf allen drei Boxen. Mit wieder aktivierter Sperre ging dann heute kein automatisches Update der Secondarys von 2.1.8 auf 2.1.8-Patch.1, ich vermute weil jede oWB eigenständig nach Hause telefonieren will.

[openWB]

Die Master lädt das Update und stellt dann das Image für die Secondarys bereit.

Da das Update u.a. über die Github Server läuft und auch Pakete des Systems geupdated werden wäre das ein immenser Aufwand.
Wenn du Updates machen möchtest einmal Internetzugriff gewähren, danach kann wieder zu.

[Gero]

Aber da zieht es sich die Einstellung preisbasiert

Ehrlich? Ich hätte erwartet, dass das preisbasierte Laden nur bis zum SoC geht (also genauso wie Sofortladen wenn man keine dynamsichen Preise konfiguriert hat) und es dann mit PV weitergeht bis das Auto nicht mehr will.

Ich hab' halt weder dynamische Preise noch brauche ich Zielladen von daher bin ich da raus.

[LenaK]

Seit dem 2.1.8 bzw. Patch1 funktioniert bei mir der evcc SoC nicht mehr. In der Konfiguration fehlt jetzt evcc komplett in der Auswahl "SoC-Modul des Fahrzeugs".
Meine existierende Fahrzeug Konfiguration hat zwar noch die "evcc" Formular Felder, aber scheinbar ohne Funktion. Auch wenn ich ein neues Fahrzeug Anlege, fehlt "evcc" in der Auswahlliste.

Im SoC Log sind auch keine Einträge, auch nicht wenn ich auf debug/details stelle.

Was bei dem Update auffällig war, sowohl 2.1.8 als auch patch1 ist, dass die openwb nicht wieder automatisch gestartet ist bzw. Beim Neustart hängen blieb und ich den Strom trennen musste, dann ist sie aber problemlos gestartet (bis auf das evcc Problem natürlich). Das hatte ich bisher bei keinem Update seit ich die openwb seit etwa 1 jahr habe.

Main log: https://paste.openwb.de/WKudxLkABE18j4O
Interner Ladepunkt Logs: https://paste.openwb.de/tp2MrHvElgoNd1w

Kann mir da jemand helfen? Soll ich den Support kontaktieren? Welche Logs wären denn noch sinnvoll/hilfreich?

Screenshot_20250924-221607.png

Bitte ein Ticket erstellen.

[k0aLa]

Hallo zusammen,

zunächst erst einmal vielen Dank an alle fleißigen Entwicklung und Tester des R. 2.1.8 + Patch 1.

Ich bin heute problemlos von dem Release 2.1.7 Patch 5 auf das Release 2.1.8 Patch 1 umgestiegen.
Wie üblich habe ich vor und nach dem Update der Box ein Backup erstellt. Ich bin allerdings etwas irritiert, dass das Backup des aktuellen Release deutlich kleiner ist als die Sicherungen der vorangegangenen Versionen:

BackUp-Größe.png (32.88 KiB) 130 mal betrachtet

Wurde mit dem neuen Release an der Komprimierung etwas geändert oder gibt es hier ein Problem, dass nicht alle Daten & Konfigurationen in der Backup-Datei landen?

[shesse]

1. Das Verhalten mit den deutlich kleineren Backup-Dateien kann ich bei mir nachvollziehen. Bei mir ist es zwar nicht so deutlich, aber von 31 auf 11 MB runter.

2. Kann es sein, dass das automatische Update für Secondaries nicht für Patches funktioniert? Beide Boxen sind bei mir auf Release, aber der Patch 1 ist nur auf der Hauptbox angekommen:

Screenshot 2025-09-25 135553.jpg (212.3 KiB) 111 mal betrachtet

Gruß,
Stefan

[kai9555]

Das Forum benutzt nur ein Bruchteil der openWB-user.
Wenn ich "Home Assistant + Modbus Proxy + openwb2mqtt" in deiner sig lese, ist deine Installation - so leid es mir tut - kein Standardfall, den openWB supportet.

Außerdem - wenn man auf 100% Funktion warten würde, ginge nie eine neue Version online. Software ist fast immer ein Kompromiss.

-> Blick weiten.
Wenn z.B. 90% user mit Standardkonfig keine Probleme haben, geht die sw raus. Der Rest wird on the fly gefixt, aber eben ohne andere Aufgaben zu vernachlässigen.

Du kannst nicht erwarten, dass das Team individuelle Probleme mit Eingriff ins Getriebe (MQTT) auf Abruf und ohne Rechnung löst. Das geht wirtschaftlich nicht abzubilden. Es ist immer eine Frage von Aufwand, Kapazitäten und Finanzierung. Bitte habe dafür Verständnis.

Ins Getriebe greife ich dahingehend ein, dass ich den SOC und die Reichweite beider Fahrzeuge an die openWB übermittle. Weitere Topics zum Schreiben sind nicht konfiguriert.

Keine Ahnung ob das Hilft, aber lieber ein Info mehr als zu wenig. Ich habe auch die openWB in HA über openwb2mqtt eingebunden und musste feststellen, dass durch Neustarts des Mosquitto Brokers in HA alte Werte an openWB zugeschrieben werden. In meinem Fall hat sich der Zählerstand der SimCounter ständig zurückgesetzt. Wichtig ist das deine mosquitto.conf, die für den Aufbau der Brücke verantwortlich ist, korrekt konfiguriert ist, sonst erlaubst du die Synchronisation für abonnierte Topics in beide Richtungen.