OVMS für den VW e-Up

[dieselstinker]

Probier mal aus, das Script zweimal hintereinander zu starten, wenn es dann geht, sleep auf 3 oder 4 vergrössern.

Komisch, das Skript funktioniert bei mir nicht. Das Auto wird geweckt, man hört kurz das Summen der Pumpe, aber sonst passiert nichts. Unter Nachrichten steht nur „Vehicle has been woken“

Wenn ich das mache ist anschließend der Mindestladestand auf 30% und der Ladestrom auf 5A zurückgesetzt worden.

D’accord! Die Klimatisierung funktioniert auf Anhieb, aber die Ladesteuerung ist anschließend im A.

Vielleicht findet sich jemand, der/die sich an den Origanlcode ran wagt?

Kann ich dieselben OBD-Befehle auch als Skript laufen lassen? Würde das Debuggen erstmal vereinfachen.

[OuterRoast]

Kann ich dieselben OBD-Befehle auch als Skript laufen lassen? Würde das Debuggen erstmal vereinfachen.

Das sollte wohl gehen, siehe z.B. hier auf github:

Code: Alles auswählen

  data_s[0] = 0x29;
  data_s[1] = 0x58;
  data_s[2] = 0x00;
  data_s[3] = 0x00;
  if (vweup_enable_write && !dev_mode) {
    comfBus->WriteStandard(0x69E, length_s, data_s);
  }

Sollte einfach ersichtlich sein, dass das genau das ist, was wir im Script per "can can3 tx st 69e 29 58 00 00" senden.
Ohne irgendwas darüber zu wissen(!) würde ich sagen, dass man die anderen Befehle analog aus dem github-Code entnehmen und per "can can3 tx st ..." ebenso senden könnte.

[dexter]

Nochmal zur Erinnerung: ich habe die Konfiguration der Ladung/Klimatisierung schon recht weit dekodiert, jedenfalls weit genug für eine bessere Steuerung. Siehe meine Posts zum Multiplex-Protokoll hier aus dem Frühjahr, Abschnitte zu PID 958 und 959.

Das kann man auch per Script testen, aber es wird dann wie die jetzige Implementierung auf das Überschreiben der unbekannten Felder hinauslaufen. Mein Plan war/ist, die PIDs erst auszulesen, um die unbekannten Felder beim Schreiben unverändert zu lassen. Das geht per Script nur sehr umständlich, und der aktuelle Stand enthält noch viele weiße Flecken.

Wer da helfen möchte kann die Frames zu diesen PIDs besser zuerst einmal bei sich aufzeichnen und mir schicken oder hier posten, evtl. bekommen wir die unbekannten Bytes ja so noch entschlüsselt, oder zumindest eine Idee, welche davon fix sind.

Per "can log start mon crtd 3:69c-69e" kann man im Log die Kommunikation zwischen Lademanager (69c), Bluetooth-Controller (69d) und OCU (69e) verfolgen, per bspw. "can log start vfs crtd /sd/canlog.crtd 3:69c-69e" schickt man die Aufzeichnung in ein File. Dann bspw. mit der Bluetooth-App die Ladekonfiguration abrufen und ggf. mal testweise eine Einstellung ändern. Notizen machen, was man wann ändert.

[OuterRoast]

Kann ich - um ein bisschen bzgl. der Ladewerte bei aktivem T26A herumzutesten - die T26A-Funktionen schnell per Shell de-/aktivieren, oder muss ich dazu jedes mal das Häkchen im Webinterface bedienen?

[dexter]

Rework:

Code: Alles auswählen

vehicle module NONE
config set xvu con_t26 no
vehicle module VWUP
…
vehicle module NONE
config set xvu con_t26 yes
vehicle module VWUP

So ist's vermutlich zuverlässiger.

Wird vermutlich trotzdem nach ein paar mal hin/herschalten einen Reboot notwendig machen, der Code ist für sowas bislang eigentlich nicht ausgelegt.

[OuterRoast]

Ich hatte gerade nur ein paar Minuten mit dem ladenden Up zur Verfügung. Habe deine Shell-Zeilen in t26a_off und t26a_on Scripte gepackt und mich mal als Beispiel besonders auf "chargepower" ≙ "v.b.power" konzentriert, was mir seit Verwendung von T26A immer 0 anzeigt. Bericht:

Einige Minuten nach Ladestart, T26A und OBD default an: Ladezeitprognosen abwegig, chargepower = 0
T26A aus via Shell, kurz warten: Ladezeitprognosen plausibel, chargepower 6.5
T26A an via Shell, kurz warten: Ladezeitprognosen und chargepower bleiben plausibel und werden - wie vorher mit nur OBD gewohnt - weiterhin regelmäßig aktualisiert (Beobachtung ca. 15min)
-> währenddessen auch noch Vorklimatisierung mit dem kurzen can3 tx Script aktiviert, Werte bleiben weiter plausibel, chargepower sinkt etwas ab, aktualisiert weiter

Ich konnte es leider zeitbedingt nicht mehrfach testen, hole ich übers Wochenende noch nach.


Hier wird es komplett spekulativ da ich wirklich null Plan von C++ habe, aber ich wollte es nicht unerwähnt lassen, gerne mit zwei Worten abbügeln wenn es kompletter Quatsch ist:

In der Shell fiel mir auf, dass OBD nach dem t26a_on wohl Sekundenbruchteile früher startete als T26A und noch vor dem ersten (warum zwei mal?) Start von T26A PollSetState OFF -> CHARGING setzt (also OBD dann wohl schon vor T26A wirklich aktiv war?):

Code: Alles auswählen

I (3062161) webcommand: HttpCommandStream[0x3f8c76f4]: 3450128 bytes free, executing: . t26a_on
I (3062171) v-vweup: Stop VW e-Up vehicle module
I (3062201) v-none: Generic NONE vehicle module
I (3062591) v-none: Shutdown NONE vehicle module
I (3062591) v-vweup: Start VW e-Up vehicle module
I (3062601) v-vweup: Starting connection: OBDII
I (3062601) v-vweup: PollSetState: OFF -> CHARGING
I (3062601) v-vweup: Starting connection: T26A (Comfort CAN)
I (3062601) mcp2515: can3: SetPowerMode on
I (3062641) v-vweup: Starting connection: T26A (Comfort CAN)
I (3062641) mcp2515: can3: SetPowerMode on

OvmsVehicleVWeUp::OBDInit tut abhängig von HasT26() oder HasNoT26() Dinge, oder eben nicht. So wie ich es verstehe, wird über OBD diverses weniger getan/gelesen/abgefragt, wenn T26A anwesend ist. Könnte das durch das Eingreifen via Shell hier anders abgelaufen sein (also als wäre T26A deaktiviert) als beim normalen Boot? Wird hier evtl. zu viel OBD deaktiviert? Ich selbst bin leider wirklich überfordert zu interpretieren, was der Code dort tut.


Edit: noch etwas, was mir ins Auge gefallen ist:
Hier ist wohl kommentiert, dass T26A StdMetrics.ms_v_bat_power - das dürfte v.b.power sein? - nicht unterstützt. Wenn T26A aktiv ist, ist der Wert bei mir scheinbar immer 0. Wenn nur OBD aktiv ist, wird er regelmäßig gesetzt. Nach t26a_off und t26a_on via shell scheint er auch zu funktionieren. Wie gesagt fehlt mir das Wissen, um weiter zu ergründen, warum das so ist. Evtl. ist es eine "Spur"?

[dieselstinker]

Nochmal zur Vorklimatisierung:
Ich hatte zunächst mehrfach das Skript probiert. Hat nie funktioniert.
Dann habe ich einmal über die vorgesehene Funktion in der App vorgeheizt. Hat funktioniert, aber die Programmierung zerschossen (5A, 30%).
Jetzt habe ich noch 2x das Skript getestet und beide Male hat es funktioniert! (Und das OVMS ist nach Ende der Fahrt gecrasht...)

War das jetzt Zufall, oder ist es einfach die Regel, dass man einmalig per App vorheizen muss und danach klappt es dann per Skript?

[OuterRoast]

Einige Minuten nach Ladestart, T26A und OBD default an: Ladezeitprognosen abwegig, chargepower = 0
T26A aus via Shell, kurz warten: Ladezeitprognosen plausibel, chargepower 6.5
T26A an via Shell, kurz warten: Ladezeitprognosen und chargepower bleiben plausibel und werden - wie vorher mit nur OBD gewohnt - weiterhin regelmäßig aktualisiert (Beobachtung ca. 15min)
-> währenddessen auch noch Vorklimatisierung mit dem kurzen can3 tx Script aktiviert, Werte bleiben weiter plausibel, chargepower sinkt etwas ab, aktualisiert weiter

Man kann seine Beiträge nach einiger Zeit wohl nicht mehr bearbeiten?
Dann ergänze ich halt hier: Das Verhalten ist bei reboot reproduzierbar. Direkt nach dem Reboot erhalte ich noch ca. 1 Minute im Charging Monitor einen Wert für v.b.power (Battery -> Power), dann springen und bleiben Battery Current und Battery Power auf 0. t26a_off + t26a_on führt dazu, dass die Werte wieder korrekt werden.

Ich will noch testen wie es sich mit einem neuen Ladestart verhält, nachdem ich die Scripte angewendet habe (also Kabel aus- und wieder einstecken). Dann habe ich erst mal keine Ideen mehr.

[donaldduck8]

War das jetzt Zufall, oder ist es einfach die Regel, dass man einmalig per App vorheizen muss und danach klappt es dann per Skript?

Es wird wohl die Regel sein, das man mindestens einmal mit der App Vorklimatisieren muss.
Wahrscheinlich war bei dir die Klimatisierung deshalb noch nicht enabled.
Jetzt sollte das Vorklimatisieren mit Script aber auch dauerhaft funktionieren.

Mit der App "Vorklimatisieren" überträgst du noch jede Menge mehr an Daten.
Dabei wird vermutlich die Klimatisierung erst enabled-vorbereitet und leider auch der Mindestladestand auf 30% gesetzt.
Dann kommt zuletzt die Aktivierung mit "69e 29 58 00 01"

Im Script wird ja nur dieser kurze Aktivierungs Befehl gesendet, der Rest fehlt.


Donald

[dexter]

Einige Minuten nach Ladestart, T26A und OBD default an: Ladezeitprognosen abwegig, chargepower = 0
T26A aus via Shell, kurz warten: Ladezeitprognosen plausibel, chargepower 6.5
T26A an via Shell, kurz warten: Ladezeitprognosen und chargepower bleiben plausibel und werden - wie vorher mit nur OBD gewohnt - weiterhin regelmäßig aktualisiert (Beobachtung ca. 15min)
-> währenddessen auch noch Vorklimatisierung mit dem kurzen can3 tx Script aktiviert, Werte bleiben weiter plausibel, chargepower sinkt etwas ab, aktualisiert weiter

Man kann seine Beiträge nach einiger Zeit wohl nicht mehr bearbeiten?
Dann ergänze ich halt hier: Das Verhalten ist bei reboot reproduzierbar. Direkt nach dem Reboot erhalte ich noch ca. 1 Minute im Charging Monitor einen Wert für v.b.power (Battery -> Power), dann springen und bleiben Battery Current und Battery Power auf 0. t26a_off + t26a_on führt dazu, dass die Werte wieder korrekt werden.

Du hast ja den Logauszug vom Start gepostet. Was siehst Du im Log bevor Current & Power auf 0 gehen?

Außerdem stell bitte den Log-Level für "v-vweup" und "events" auf "Debug".

Mein aktueller Verdacht ist, dass Du den 12V-Level nicht kalibriert hast, und die Messung bei Dir daher zu niedrig ausfällt. Das könnte das T26-Modul dazu veranlassen zu glauben die Ladung sei beendet. Du müsstest dann eine Logmeldung "Car stopped itself charging the 12v battery" haben, und direkt danach "PollSetState: CHARGING -> OFF".

Falls mein Verdacht stimm, kalibrier mal den 12V-Level und probier's dann nochmal.