openWB Forum

Keine MQTT Daten für Ladepunkt A und auch Ladepunkt B
Noch keine Daten nach dem Start oder Ladepunkt nicht erreichbar.

Ich betreibe eine Standalone mir 2.1.8 Beta 1 als "Master" vor 2 secondary OpenWB Custom (Diese haben noch das 1.9er Image drauf)

Nach dem Update von der letzten Beta auf diese Beta erhalte ich nun in der Ladepunkt Ansicht alle 10 Sekunden die o.g. Fehlermeldung kurz eingeblendet.
Vorher lief alles ohne Probleme.

Ist das nur eine Einstellung, oder benötigt ihr einen Log?

Danke und Gruß
Bogie

Jetzt wäre der richtige Zeitpunkt, alle openWB auf software2 zu bringen.

LutzB hat geschrieben: Di Aug 19, 2025 11:31 am Jetzt wäre der richtige Zeitpunkt, alle openWB auf software2 zu bringen.

Ich dachte, die könnten immer auf 1.9 bleiben (als dumme secondaries)?
Ist der o.g. Fehler weg, wenn ich sie auf software2 bringe?
Also hängt die Fehlermeldung direkt damit zusammen?

Danke und Gruß
Bogie

Bogie hat geschrieben: Di Aug 19, 2025 11:49 am Ich dachte, die könnten immer auf 1.9 bleiben (als dumme secondaries)?
Ist der o.g. Fehler weg, wenn ich sie auf software2 bringe?
Also hängt die Fehlermeldung direkt damit zusammen?

Danke und Gruß
Bogie

Aus viewtopic.php?p=131620#p131620 :

Kommunikation mit Secondaries: Die Primary fragt die Daten von der Secondary, analog zu den anderen Ladepunkten, ab. Um die Kompatibilität sicher zu stellen, wird mit diesem Update einmalig die Secondary auf den gleichen Software-Stand wie die Primary gebracht.

Kann man jetzt die Zeit einstellen für die Phasenumschaltung? Das ist bei mir wenn Wolken da sind echt ein Problem. Bin noch auf der Release dafür würde ich aber wechseln. Steht leider nicht in den Änderungen.

Frage zur internen PNP Adresse:
Die ist momentan fest auf 192.168.193.250: Das wird bei mehreren Systemen (Produktiv, Test) zu Problemen führen.
Wann wird die Konfigurierbarkeit realisiert?

fawick hat geschrieben: Di Aug 19, 2025 6:37 am Die neuen MQTT-Topics openWB/set/mqtt/vehicle/n/get/... fuehren zu keiner Aenderung der Werte (z.B. auf der Status-Seite)

Ich kann mit mosquitto_sub sehen, dass sie nach dem Setzen von der OpenWB zwar wieder genullt werden, aber danach scheint die Verarbeitung aufzuhoeren:

Code: Alles auswählen

$ mosquitto_sub -h openwb.fritz.box -v -t 'openWB/set/mqtt/#'
openWB/set/mqtt/vehicle/2/set/soc 42
openWB/set/mqtt/vehicle/2/set/soc (null)
openWB/set/mqtt/vehicle/2/get/soc_timestamp 1755585226
openWB/set/mqtt/vehicle/2/get/soc_timestamp (null)
openWB/set/mqtt/vehicle/2/get/range 101
openWB/set/mqtt/vehicle/2/get/range (null)

PS: Installierte Version 2025-08-18 14:33:10 +0200 [c22390280]

viewtopic.php?p=131622#p131622
Bitte ein Log von main und mqtt log einstellen.

Bogie hat geschrieben: Di Aug 19, 2025 11:49 am

LutzB hat geschrieben: Di Aug 19, 2025 11:31 am Jetzt wäre der richtige Zeitpunkt, alle openWB auf software2 zu bringen.

Ich dachte, die könnten immer auf 1.9 bleiben (als dumme secondaries)?
Ist der o.g. Fehler weg, wenn ich sie auf software2 bringe?
Also hängt die Fehlermeldung direkt damit zusammen?

Danke und Gruß
Bogie

Erledigt -

ChristophR hat geschrieben: Di Aug 19, 2025 5:41 am Betreff: Rückmeldungen software2 2.1.8-Alpha 2

LenaK hat geschrieben: Mo Aug 18, 2025 9:34 am

ChristophR hat geschrieben: Sa Aug 16, 2025 1:53 pm

Die Standzeit mit dem höheren Akkustand soll minimiert werden.
Wenn das Auto das ganze Wochenende angesteckt ist, soll es nur bis 85% laden.
Erst am Tag vor der geplanten Abfahrt (bei mir Di oder ggf. einmaliger Zeitplan), soll weiter geladen werden.
Die Idee stammte hier aus dem Forum, daher könnten es noch andere so konfiguriert haben. Vor der Umstellung auf die temp-Profile hat das so geklappt.

Du könntest es so konfigurieren:
Sa-So 07:00 Uhr mit Ziel-SoC 45% und 85% mit Überschuss.
Mo, Do, 07:00 Uhr mit Ziel-SoC 45% und 95% mit Überschuss.
Di-Mi, Fr, 07:00 Uhr mit Ziel-SoC 65% und 95% Überschuss.

Könnte ja vielleicht so klappen, ist aber nicht wirklich intuitiv, klingt eher wie ein Workaround.

Nach Deiner Erklärung (Guckt nur in die Vergangenheit, wenn nicht neu angesteckt wurde) würde dann z.B. wenn ich erst Sonntags um 8:00 Uhr anstecke, direkt bis 95% geladen. Wenn ich aber Sonntag um 6:00 Uhr anstecke, erst Sonntagabend ab 19:00 Uhr.

Warum muss ein Plan denn aktiv bleiben, wenn sein Ziel erreicht wurde?

Damit noch etwas Überschuss geladen wird, falls das Auto nicht sofort zum Zielzeitpunkt gefahren wird. Dann wird das Auto gefahren, angesteckt und der nächste Zielzeitpunkt ist aktiv.
Nur weil das Auto nicht pünktlich zum Zielzeitpunkt abgesteckt wird, muss ja nicht gleich bis zum nächsten Zieltermin geladen werden.

LenaK hat geschrieben: Di Aug 19, 2025 1:33 pm

fawick hat geschrieben: Di Aug 19, 2025 6:37 am Die neuen MQTT-Topics openWB/set/mqtt/vehicle/n/get/... fuehren zu keiner Aenderung der Werte (z.B. auf der Status-Seite)

Ich kann mit mosquitto_sub sehen, dass sie nach dem Setzen von der OpenWB zwar wieder genullt werden, aber danach scheint die Verarbeitung aufzuhoeren:

Code: Alles auswählen

$ mosquitto_sub -h openwb.fritz.box -v -t 'openWB/set/mqtt/#'
openWB/set/mqtt/vehicle/2/set/soc 42
openWB/set/mqtt/vehicle/2/set/soc (null)
openWB/set/mqtt/vehicle/2/get/soc_timestamp 1755585226
openWB/set/mqtt/vehicle/2/get/soc_timestamp (null)
openWB/set/mqtt/vehicle/2/get/range 101
openWB/set/mqtt/vehicle/2/get/range (null)

PS: Installierte Version 2025-08-18 14:33:10 +0200 [c22390280]

viewtopic.php?p=131622#p131622
Bitte ein Log von main und mqtt log einstellen.

Braucht ihr das Log wirklich noch? Es scheint ja doch daran zu legen, dass das ConfigurableDevice, das in packages/modules/vehicles/mqtt/soc.py erstellt wird, in den "fetch soc"-Threads doch nur in Abhaengigkeit der konfiguierterten Intervalle abgefragt wird, obwohl der Hilfetext in der UI fuer das MQTT-SOC-Modul davon spricht, dass bei MQTT die Intervalle keine Rolle spielen.