Rückmeldungen Beta 1.9.110

[LutzB]

Die Release Notes findet Ihr dort: viewtopic.php?f=3&t=2625

[aiole]

Danke Euch für's update!!!

Das SoC-update für BMW i3 an LP1 (6min-Intervall) klemmt allerdings noch immer (LP2 mit 5min Intervall geht perfekt).
Am Intervall selbst liegt es nicht. Alleiniges Speichern der alten LP1-Einstellung reicht auch nicht. erst ein Ändern (ich lösche eine Ziffer der VIN)/ Speichern / Rückändern / Speichern + 1x Intervall abwarten schafft Abhilfe.

LP1:
2021-02-25 15:05:15: Lp2: Nothing to do yet. Incrementing timer.
2021-02-25 15:05:07: Lp1: Nothing to do yet. Incrementing timer.
2021-02-25 15:05:05: Lp2: Nothing to do yet. Incrementing timer.
2021-02-25 15:04:57: Lp1: chargingEror:
2021-02-25 15:04:57: Lp1: Charging:
2021-02-25 15:04:57: Lp1: SoC:
2021-02-25 15:04:57: Lp1: Requesting SoC
2021-02-25 15:04:54: Lp2: Nothing to do yet. Incrementing timer.

LP2:
2021-02-25 15:09:07: Lp1: Nothing to do yet. Incrementing timer.
2021-02-25 15:09:04: Lp2: Nothing to do yet. Incrementing timer.
2021-02-25 15:08:56: Lp1: Nothing to do yet. Incrementing timer.
2021-02-25 15:08:56: Lp2: chargingEror: 0
2021-02-25 15:08:56: Lp2: Charging: 0
2021-02-25 15:08:56: Lp2: SoC: 93
2021-02-25 15:08:54: Lp2: Requesting SoC
2021-02-25 15:08:47: Lp1: Nothing to do yet. Incrementing timer.

[aiole]

neuer Versuch mit 1.9.111
Gleiches Problem. Jetzt habe ich SoC-LP1 einfach auf Audi umgestellt/speichern/retour auf BMW/speichern => SoC-LP1 kommt

[truckl]

Ich kann das Problem mit dem BMW SOC ebenfalls reproduzieren.

Ursache ist, dass beim Update grundsätzlich die "auth[12].json" mit den Dummy-Defaults (demo@bmw.de, ...) überschrieben wird.

Es reicht einmal die Modulkonfig des LP zu öffnen und zu speichern (ohne irgend etwas zu ändern) um wieder die korrekten Werte zu setzen.

Ich habe mich bereits mehrfach durch den relevanten Code von "atreboot.sh", "update.sh" & Co gewühlt aber noch herausgefunden warum es passiert. Ich vermute es liegt an dem Backup-und-Restore während des Updates.

Das Problem ist, dass man das kaum Debuggen kann weil man ja ein Update anstoßen muss und dabei natürlich jeglicher Debug-Output den man evtl. einbaut sofort wieder überbügelt wird bevor aktiv wird. Ein direkter "Logikfehler" im Backup/Restore ist mir bisher leider noch nicht aufgefallen.

[derNeueDet]

Das Problem beim i3 soc am LP1 liegt in der update.sh

Beim zurück kopieren wird in Zeile 89 die auth.json auf die falsche Datei kopiert.

VG
Det

[LutzB]

Jein, das ist schon so gewollt. Es gab bei der Zusammenlegung der Module für LP1 und LP2 das Problem, dass wir die auth.json beider LPs umbenennen mussten, da sie ab da in einem Verzeichnis liegen.

Zeile 89 greift also nur beim Upgrade von einer alten Version, da nur dann die auth.json existiert. Bei einem Update einer Version nach der Umstellung greift hingegen Zeile 95.

So zumindest die Idee. Kann aber durchaus sein, dass da noch ein Denkfehler drin ist.

[derNeueDet]

Ok, sorry
Das war mir nur auf die Schnelle aufgefallen. Der Hintergrund der Umstellung hat mir da gefehlt.

VG
Det

[truckl]

Habe nun noch folgenden Test durchgeführt:

• Alle 'auth*.json' aus '/tmp' gelöscht
• '/var/www/html/openWB/modules/soc_i3s1' komplett gelöscht
• Datei 'auth.json' aus '/var/www/html/openWB/modules/soc_i3' gelöscht
• Update (train 'master') getriggert

Ergebnis:

• 'auth1.json' wird nicht mehr mit den Dummy-Daten überschrieben. Die SOC-Abfrage funktioniert auch nach dem Update.
• Verzeichnis '/var/www/html/openWB/modules/soc_i3s1' entsteht neu mit den Dateien 'auth.json' und 'main.sh'
• Datei '/var/www/html/openWB/modules/soc_i3/auth.json' entsteht neu mit den Dateien 'auth.json' und 'main.sh'
• In '/tmp' entstehen die Dateien 'auth1.json' und 'auth2.json'

Nun habe ich (ohne weiteren, manuellen Eingriff) ein erneutes Update getriggert. Ergebnis:

• 'auth1.json' wird WIEDER mit den Dummy-Daten überschrieben. Die SOC-Abfrage funktioniert NICHT mehr.
• In '/tmp' entstehen zuätzlich die Dateien 'auth.json' und 'auth.json.1' mit den Dummy-Werten

Lösungsansatz (ohne 100% sicher zu sein dass das wirklich alles ist):

• Verzeichnis '/var/www/html/openWB/modules/soc_i3s1' wird aus dem Git-Repo entfernt
• Datei '/var/www/html/openWB/modules/soc_i3/auth.json' wird aus dem Git-Repo entfernt oder evtl. muss diese auch in 'auth1.json' umbenannt werden um eine Dummy-Vorlage zu erhalten
• In 'update.sh' wird in Zeilen 89, 92, 95 und 98 anstatt 'cp' ein 'mv' gemacht damit keine "Reste" des Updates in '/tmp' verbleiben ('/tmp' ist zumindest auf meiner openWB von Herbst 2019 KEINE ramdisk sondern 100% persistent)

@LutzB Soll ich einen PR vorbereiten oder willst Du direkt? Ich sehe keine Möglichkeit das ohne ggf. auch nur "testweise" Integration in "master" final zu testen.

[LutzB]

Danke für Deine Analyse. Copy durch Move zu ersetzen ist eine gute Idee! Ich sehe mir das Montag nochmal in Ruhe an und spiele ein paar Fälle durch.

Das Verzeichnis SOC_i3s1 kann nicht entfernt werden, da es für LP2 (noch) benötigt wird.

[hominidae]

....habe gerade gesehen, dass im GUI (Standard-Theme), aber auch im MQTT (openWB/global/DailyYieldAllChargePointsKwh) die geladene Energie angezeigt wird/vorhanden ist (Wert >0kWh)....obwohl heute nicht geladen wurde.

Im Tagesgraph sieht man, dass es die geladene Energiemenge von gestern ist.
Die LPx stehen jeweils auf 0kWh.

DUO Kaufgerät, Beta 1.9.110