Rückmeldungen 2.1.2 Beta 3

[Franknav]

Hallo Zusammen,

Das Backup auf ein SAMBA-Share (FritzBox) funktioniert jetzt grundsätzlich.

Nur leider NICHT mit Hostnamen zumindest nicht "fritz.box" dem Standard-Namen der Fritzbox.
Hier funktioniert nur die ip-Adresse (Standard = 192.168.178.1)

Der Rest der notwendigen Angaben (Freigabe-Name, Pfad usw.) funktioniert!

Samba-Konfig mit IP-Adresse

Die Backups werden aktuell mit einen Zeit Stempel versehen was zur Folge hat, das man sich u das löschen der alten Backups selbst kümmern muss, vielleicht könnte man noch eine Option einbauen wo man die Anzahl der Backups festlegen kann bzw. diese rundgeschrieben werden.

Vielen Dank Frank

[LenaK]

Ich habe noch einen Nachtrag zu meiner Meldung im Beta 2 Thread https://www.openwb.de/forum/viewtopic.p ... 952#p96952.

Im SoC-Log gibt es vielleicht den richtigen Hinweis zum Problem:

Code: Alles auswählen

2023-11-18 14:14:15,512 - {modules.common.fault_state:55} - {ERROR:fetch soc_ev1} - mqtt: FaultState FaultStateLevel.ERROR, FaultStr <class 'AttributeError'> 'NoneType' object has no attribute 'soc', Traceback: 
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/common/configurable_vehicle.py", line 57, in update
    log.debug(f"Requested start soc from {source.value}: {car_state.soc}%")
AttributeError: 'NoneType' object has no attribute 'soc'

Ich konnte das Problem auch im Simulator nachstellen. Einfach einen MQTT-SoC konfigurieren und virtuell ein Auto anstecken und die Ladung starten. Wenn man nun per MQTT einen SoC übermittelt, wird der alle 5 Minuten zurückgesetzt.

Der component_updater eines MQTT-SoC (packages/modules/vehicles/mqtt/soc.py) liefert einfach keinen CarState, da auch nichts zu aktualisieren ist. Mit einer Prüfung, ob es einen CarState gibt, läuft es im Simulator bei mir (wieder). Alternative wäre vielleicht auch ein CarState, der zum MQTT-SoC passt.

VG

Ist im Master behoben.

[LenaK]

der SOC wird mit dem aktuellen Master noch nicht von der openWB Pro übernommen. Die Pro bekommt den Wert vom Auto.
Und ich seh erst jetzt, dass es eigentlich um das Gleiche wie beim vorherigen Post geht: nur ein kleiner Unterschied im log
<class 'TypeError'> unsupported operand type(s) for -: 'int' and 'NoneType', Traceback:


Das ist das Logfile vom SoC-Log:

Code: Alles auswählen

2023-11-18 21:48:35,216 - {modules.common.component_context:24} - {DEBUG:fetch soc_ev1} - Update Komponente ['Manueller SoC']
2023-11-18 21:48:35,223 - {modules.common.fault_state:55} - {ERROR:fetch soc_ev1} - Manueller SoC: FaultState FaultStateLevel.ERROR, FaultStr <class 'TypeError'> unsupported operand type(s) for -: 'int' and 'NoneType', Traceback: 
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/common/configurable_vehicle.py", line 56, in update
    car_state = self._get_carstate_by_source(vehicle_update_data, source)
  File "/var/www/html/openWB/packages/modules/common/configurable_vehicle.py", line 96, in _get_carstate_by_source
    return CarState(soc=calc_soc.calc_soc(vehicle_update_data,
  File "/var/www/html/openWB/packages/modules/vehicles/common/calc_soc/calc_soc.py", line 13, in calc_soc
    imported_since_start = vehicle_update_data.imported - imported_start
TypeError: unsupported operand type(s) for -: 'int' and 'NoneType'

2023-11-18 21:48:45,255 - {modules.common.component_context:24} - {DEBUG:fetch soc_ev1} - Update Komponente ['Manueller SoC']
2023-11-18 21:48:45,257 - {modules.common.fault_state:55} - {ERROR:fetch soc_ev1} - Manueller SoC: FaultState FaultStateLevel.ERROR, FaultStr <class 'TypeError'> unsupported operand type(s) for -: 'int' and 'NoneType', Traceback: 
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/common/configurable_vehicle.py", line 56, in update
    car_state = self._get_carstate_by_source(vehicle_update_data, source)
  File "/var/www/html/openWB/packages/modules/common/configurable_vehicle.py", line 96, in _get_carstate_by_source
    return CarState(soc=calc_soc.calc_soc(vehicle_update_data,
  File "/var/www/html/openWB/packages/modules/vehicles/common/calc_soc/calc_soc.py", line 13, in calc_soc
    imported_since_start = vehicle_update_data.imported - imported_start
TypeError: unsupported operand type(s) for -: 'int' and 'NoneType'

2023-11-18 21:52:01,276 - {modules.common.component_context:24} - {DEBUG:fetch soc_ev1} - Update Komponente ['Manueller SoC']
2023-11-18 21:52:01,277 - {modules.common.configurable_vehicle:57} - {DEBUG:fetch soc_ev1} - Requested start soc from manual: 30%
2023-11-18 21:52:01,286 - {modules.common.store._api:26} - {DEBUG:fetch soc_ev1} - Raw data CarState(soc=30, range=None, soc_timestamp=None)
2023-11-18 21:52:01,319 - {modules.common.store._api:30} - {INFO:store soc_ev1} - Saving CarState(soc=30, range=None, soc_timestamp=None)
2023-11-18 21:52:21,367 - {modules.common.component_context:24} - {DEBUG:fetch soc_ev1} - Update Komponente ['Manueller SoC']
2023-11-

Danke! jürgen

Bei Dir ist die Ursache eine andere. Hast Du die Pro auf Version 3.2.1 geupdatet?

Bitte das Debuglevel auf Details stellen und mindestens einen kompletten Durchlauf von # ***Start*** bis # ***Start*** aus dem Main-Log und SoC-Log unter System->Fehlersuche posten, wenn das Problem auftritt. Sensible Daten wie Benutzernamen und Kennwörter unkenntlich machen.
Vorher bitte auf den Master updaten, ich habe das Logging erweitert.

[Gero]

Nachdem ich ja nun feststellen durfte, dass diese Fehlermeldung hier nichts mit der influxdb-Installation zu tun hat, bin ich nun wieder auf der alten SD-Karte. Wie bekomme ich denn nun diesen Fehler hier weg? Lutz hatte mal nachgefragt, wie ich denn den bullseye installiert hätte. Einfach das aktuelle Image, welches der Raspberry Pi Imager (mac) nimmt. Und dann hinterher einfach die openWB von github.

Ich habe jetzt hier auch noch eine offizielle SD-Karte mit der 2.0 aus dem Shop herumliegen. Kann ich die einfach klonen und in einen standalone-raspi 4 stecken? (Meine Version ist die 2023-11-20 12:23:11 +0100 [3d7589aa3], aber einen alpha-Thread gibt es ja nicht mehr)

[electron]

Ich war vor ca. zwei Monaten auf die 2.0-Software auf einem Raspi gewechselt und habe meine openWB als "Nur Ladepunkt" betrieben. Am 5.11. habe dann ein Backup der 1.9 gemacht und die openWB auf die 2.0 umgestellt. Das Einspielen des Backups hat grösstenteils funktioniert - allerdings habe ich jetzt in der Monatsauswertung am 5.11. einen PV-Ertrag von 50'000 kW... die anderen Werte sind ebenfalls an diesem Tag viel zu hoch (siehe Screenshot) . Der Grund liegt in der Berechnung der Tageswerte als Differenz zwischen zwei Zählerständen - da am 4.11. die Wallbox noch von einem externen Raspberry Pi gesteuert wurde, sind die Werte alle 0, am 5.11. dann auf dem Zählerstand nach 5 Jahren Betrieb...

Hat jemand ein ähnliches Problem (gehabt) und möglicherweise eine Lösung gefunden? Lassen sich die Zählerstände, aus denen die Tages- und Monatswerte berechnet werden, irgendwo korrigieren? Wenn nur ein Monat komisch aussähe, wäre das kein so grosses Problem, aber beim Jahres-Graph für 2023 sieht es genauso aus - der November dominiert alles....

Vielen Dank,
Claus

[Andi]

Hallo Claus,

das Problem hatte ich auch, habe dann die csv Dateien im Backup der 1.9 händisch im tar file "gefixt" und erneut per Datenübernahme eingespielt. Das hatte dort funktioniert.

Jetzt hatte ich letzte Woche leider an meiner MQTT PV Ertragsschnittstelle rumgefummelt und promt kam da leider einmal ein unplausibel hoher Wert in die OpenWB und nun hab ich dasselbe Problem wieder. Aber in der 2.0 ist wohl von csv auf JSON umgestellt worden und da kann man leider nur schwer nach den unplausiblen Stellen filtern/suchen. Und irgendwie hab ich es noch nicht geschafft da ein manipuliertes JSON wieder in die 2.0 zu bekommen. Wäre da auch zu Hinweisen dankbar, da die ganze Auswertung nun echt Verbogen ist und damit unbrauchbar wird.

[electron]

Hallo Frank,
vielen Dank für den Tipp!
Claus

[etnie83]

Eine Frage: stoppt bei Dir das Zielladen zur konfigurierten Uhrzeit? Bei mir nicht, aber das könnte auch an den sporadischen 0% SoC Werten liegen...

Ich habe es hier abgebrochen, aber beim letzten Versuch mit dem ZOE hat die openWB gestoppt als sie fertig war, hat nur zwischendurch 2x angehalten und neu gestartet.

Hab auch bei der vorherigen Version dieses Ladediagramm mit Peaks. Übertrage per MQTT den SoC weil die RenaultApi rum zickte. Der lädt dann mit Vollgas und geht dann auf 0W und wieder auf die eingestellte Ampere. Dies immer wieder im paar Minutenwechsel. Manchmal hat meine Zoe dann keinen Bock mehr und startet das laden nach 0W nicht mehr.
Hab jetzt leider kein Ladelog. Muss ich mal umstellen und hochladen. Ich stell mal auf RenaultApi um und teste dann nochmal

[ChrisChros]

Hallo,

bezüglich dem Backup per Samba habe ich aktuell noch ein paar Probleme.
Ich habe hier ein TrueNAS-System am laufen. Bei diesem habe ich einen neuen Nutzer angelegt und als Home Directory den Ordner angegeben in dem die Backups gespeichert werden sollen. Nur in diesem Ordner hat der Nutzer die entsprechenden Schreibrechte.

In openBW habe ich nun die Einstellungen wie folgt vorgenommen:

Da der Nutzer direkt mit dem Verzeichnis verknüpft ist habe ich bei der Freigabe nur "/" eingetragen.
Im Main-Log finde ich dann aber nur folgenden Eintrage:

Code: Alles auswählen

2023-11-21 12:53:09,828 - {SMB.SMBConnection:104} - {INFO:cloud backup} - Authentication with remote machine "192.168.1.8" for user "openwb" will be using NTLM v2 authentication (with extended security)
2023-11-21 12:53:10,185 - {schedule:660} - {DEBUG:MainThread} - Running job Job(interval=1, unit=minutes, do=handler10Sec, args=(), kwargs={})

und es wir kein Backup im dem entsprechenden Verzeichnis abgelegt.

Hat jemand von euch eventuell eine Idee wie ich das zum laufen bekommen könnte?

Gruß Chris

[LutzB]

Jede SMB Freigabe hat auch einen Namen. Ich denke, das wird das Problem sein.