OVMS für den VW e-Up

[erichabg]

Wäre es nicht möglich, dass das OVMS den Ladestrom selbstständig wieder hochsetzt, wenn es erkennt, dass der Ladestecker abgesteckt wurde?

Ich schätze so wurde das von Sharkcow programmiert oder/und wenn SOC unter den max. SOC-Wert fällt.

Das denke ich nicht, denn sonst würde er nicht schreiben "Konsequenz: Wenn ihr mit OVMS die Ladung stoppt, kann sie auch nur mit OVMS wieder gestartet werden!"

Genau das sollte mein Vorschlag mit dem automatischen Rücksetzen beim Abstecken von der Ladesteckdose beheben, so würde man eben kein OVMS, Maps&Less etc. mehr benötigen um die Ladung wieder zu starten.
Bei uns ist es z.B. so, dass meine Frau zwar mit dem eUp fährt, aber weder OVMS noch Maps&Less(!) benützt.

[donaldduck8]

Finde deinen Vorschlag auch sehr gut.
Nur müsste erstmal dafür die Erkennung des Ladeports von sharkcow eingebaut werden.

[sharkcow]

Danke für die Rückmeldungen. Besonders an hengsti, schön zu sehen dass es auch bei Gen2 so funktioniert wie gedacht.

Die CAN-Fehler sind bekannt und haben nach meiner Erfahrung keinen Einfluss auf die Funktionalität.

Vielleicht hab ich das "dreckige" auch ein bisschen zu dramatisch dargestellt. Der Ladestrom wird ja sofort auf normal zurückgestellt, wenn der SoC den MaxSoC wieder unterschreitet, also kurz nach dem Losfahren. Außerdem wenn man den MaxSoC niedriger als den aktuellen SoC stellt oder eben über OVMS eine Ladung startet.

Nachdem ich jetzt geschickterweise den Steckerstatus in OBD gefunden habe, werde ich noch einbauen dass der Ladestrom zurückgestellt wird sobald man absteckt (nur bei OBD-Verbindung). Sicherheitshalber werde ich auch noch einbauen, dass der Strom bei jedem Neustart des Moduls erst mal auf den Maximalwert gestellt wird.

Wie erwähnt kann man den Strom ja auch mit M&M zurückstellen (hat halt nicht jeder). Ich hab keine Ahnung wo die VW-Apps so stehen, aber evtl. kann man da auch den Ladestrom "reparieren"?

Hab auch mal mit obdeleven geschaut, ob man den Ladestrom über OBD ändern kann, hab aber nur eine zusätzliche Begrenzung gefunden in der langen Codierung. Wenn hier jemand mehr weiß, bitte unbedingt melden! Dann könnte man in Notfällen ohne OVMS über OBD den Strom zurücksetzen.

Das Risiko ist aus meiner Sicht also fast bei Null, dass man "liegen bleibt". Außer wenn OVMS komplett abraucht genau in der (meist kurzen) Zeit, in den der Strom auf 1A steht.

Nach Rücksprache mit dexter haben wir trotzdem beschlossen, dass das Restrisiko zu groß ist um es als Standardfunktion zu betreiben. Ich werde daher noch einen Schalter im WebIF dafür einbauen, bei dem man dem damit verbundenen Risiko explizit zustimmt. Ansonsten wird nur über ID 958 an- und ausgeschaltet, was halt öfter mal nicht funktioniert bzw. sich nach kurzer Zeit wieder zurücksetzt.

sharkcow

[marxx]

Hey Sharkcow,

da geht ja ordentlich was vorwärts

Gut, dass Du den Schalter im WebIF einbaust. Auch aus meiner Sicht darf OVMS default nicht "mächtiger" sein als das Auto. Eine "mächtigere" Funktion sollte immer Opt-In sein in meiner Welt.

Ich habe mir den aktuellen T26 Code mal ein bisschen angeschaut (nur ein bisschen) und habe da ein paar Punkte:

1. Autodisable climate control ticker (30 min.)

Diese Funktion ist nun nicht mehr da. Ich habe sie damals eingebaut um sicherzustellen, dass egal was zwischen OVMS und Auto passiert, OVMS immer ein Ende der Vorklimatierung bekommt. Wenn sichergestellt ist, dass egal was kommt OVMS nicht in ein "Klima An" Status verharrt kann man es raus nehmen. Es war für mich nur so eine Art doppelten Boden. Der Gedanke war, dass das Auto die Macht hat die Vorklimatisierung selber abzuschalten (nach 15 Minuten ohne Ladekabel, nach 30 Minuten mit Ladekabel) und sollte irgendetwas schief gehen OVMS die Vorklimatierung nach 30 Minuten sowieso beendet.

2. devmode

Mein heißgeliebter "devmode" ist verschwunden Den habe ich damals eingerichtet, als ich das Auto noch nicht hatte. Es gab mir die Möglichkeit zu entwickeln, ohne dass das OVMS mit dem Auto kommuniziert. Das war damals sehr hilfreich und ich habe es drin gelassen nach dem Motto "wer weiß wofür ich es nochmal brauche". Nun ist es raus und sicherlich unverhältnismäßig viel Auifwand es wieder rein zu fricklen. "devmode" I'll miss you

3. Ist sichergestellt, dass T26 noch ohne OBD funktioniert?

Auch das ist eher historisch, aber da das Ganze mit T26 angefangen hat, ist mir wichtig, dass T26 ohne OBD (wie OBD ohne T26) eigenständig funktioniert. Auch hatten wir mal definiert, dass wenn T26 angeschlossen ist ein T26 Wert vorrang hat (zumindest für die App und für den T26 Code selbst), auch wenn der selbe Wert über OBD gezogen werden kann. Ist das noch der Fall im neuen T26 Code?

3. Kannst Du kurz beschreiben wie "profile" funktioniert?

Wirklich nur kurz. Ich weiß, dass das viel Arbeit ist ... Aber vielleicht in dem Stil, wie ich damals den Ring versucht habe zu erklären?

viewtopic.php?p=1324166#p1324166
viewtopic.php?p=1342615#p1342615

Ansonsten habe ich die Vergleichstabelle von OVMS zu "we connect" (oder wie immer das VW Dings jetzt heißt) angepasst:

Stimmt die so? Was machen wir mit den Zeitplänen und der Statistik? Lassen wir das erstmal so, oder verweisen wir darauf, dass das gescriptet werden kann?

Auf jeden Fall riesen Danke für den neuen Code

marxx

[mbfoo]

Hi!
Seit Dezember spiele ich auch im OVMS-Spiel mit meinem eUP BJ 2020 mit, ich nutze die FW von sharkcow. In diesem Sinne erstmal vielen Dank für die Entwicklung!

Ich möchte zuhause eine Ladebegrenzung von 80% haben und unterwegs soll das Auto einfach vollladen. Implementiert habe ich es bisher indem ich das OVMS per MQTT an meinen Iobroker verbunden habe und dann bei entsprechenden SoC-Levels charge stop Befehle sende. Das habe ich kombiniert mit einem Zeitplaner und automatisch startender Klimatisierung (wo ich dann wieder charge start sende).
Das klappte mit der Dezember-FW so zu 70%, bzw. der Ladevorgang wurde teilweise bei >80% gestartet und konnte nicht mit charge stop gestoppt werden. (could not start/stop charge, mit CAN-Fehlern).
Die Sicherung vom Maps & More-SG habe ich ausgesteckt.

Aus diesem Grund habe ich die neuste FW installiert (3.3.003-621-gc7b40bc4-dirty/ota_0/main (build idf v3.3.4-849-g6e214dc33 Jan 3 2024 17:00:15)).
Der xvu profile0 read Befehl will bei mir leider nicht:

Code: Alles auswählen

E (4641458) can: can3: intr=27341 rxpkt=27079 txpkt=232 errflags=0x80001080 rxerr=0 txerr=88 rxinval=0 rxovr=0 txovr=0 txdelay=91 txfail=2 wdgreset=0 errreset=0
W (4641458) mcp2515: can3 EFLG: TX_Err_Warn EWARN 
E (4641458) can: can3: intr=27342 rxpkt=27079 txpkt=232 errflags=0xa00510a0 rxerr=0 txerr=104 rxinval=0 rxovr=0 txovr=0 txdelay=91 txfail=2 wdgreset=0 errreset=0
OVMS# xvu profile0 read
E (4641458) can: can3: intr=27343 rxpkt=27079 txpkt=232 errflags=0x80051080 rxerr=0 txerr=112 rxinval=0 rxovr=0 txovr=0 txdelay=91 txfail=2 wdgreset=0 errreset=0
E (4641458) can: can3: intr=27344 rxpkt=27079 txpkt=232 errflags=0x80051080 rxerr=0 txerr=120 rxinval=0 rxovr=0 txovr=0 txdelay=91 txfail=2 wdgreset=0 errreset=0
W (4641458) mcp2515: can3 EFLG: TX_Err_Passv TX_Err_Warn EWARN 
E (4641458) can: can3: intr=27345 rxpkt=27079 txpkt=232 errflags=0xa01510a0 rxerr=0 txerr=128 rxinval=0 rxovr=0 txovr=0 txdelay=91 txfail=3 wdgreset=0 errreset=0
E (4641458) can: can3: intr=27347 rxpkt=27079 txpkt=233 errflags=0x80151080 rxerr=0 txerr=128 rxinval=0 rxovr=0 txovr=0 txdelay=91 txfail=3 wdgreset=0 errreset=0
W (4641508) mcp2515: can3 EFLG: TX_Err_Warn EWARN 

Ich möchte an einer externen Ladesäule immer vollladen und nur zuhause das 80%-Limit drin haben (um dann zu gegebenen Zeitpunk mit charge start voll zu laden).

Unter dem Aspekt, dass die Kommunikation nicht so ganz stabil läuft, teile ich die Bedenken mit der Ladestrombegrenzung zum SoC-Limit. Ich habe bedenken, dass die Begrenzung zuverlässig zurückgenommen wird.
Ist das eingestellte SoC-Limit eigentlich ein Feature vom Ladesteuergerät oder wird es im OVMS abgebildet, welches entsprechende charge start/stop Befehle zum Auto sendet? Wenn das Ladesteuergerät die Aufgabe übernimmt, sollte das Auto ja wenigstens bis zum zuletzt eingestellten SoC-Limit vollladen, oder?

Ansonsten, gibt es Ideen die Kommunikation zuverlässiger zu machen?

[sharkcow]

Hallo mbfoo!

Erst mal danke für's Testen der Firmware und willkommen im Forum

Danke auch für deinen Log. Kannst du mal vorher "log level debug v-vweup" in der Shell ausführen bevor zu das "xvu profile0 read" machst? Dann sollte man sehen, woran es hängt. Ein bekanntes Problem ist, dass das Auto manchmal nicht aufwacht (Vermutung ist, wenn der 12V-Akku unter 12V ist). Bei wiederholtem Ausführen des Befehls sollte es aber immer irgendwann klappen.

Zur Funktionsweise: das Abschalten beim eingestellten Maximal-SoC passiert im OVMS durch Senden des (neuen) Ladestop-Befehls ans Auto.
Leider akzeptiert das Auto den Ladestopp-Befehl nicht immer und stellt sich manchmal direkt danach auf den vorherigen Zustand zurück (erklärt deine Erfahrungen mit dem Dezember-build). Daher habe ich den "workaround" implementiert, der in der letzten Version der FW drin ist. Ich persönlich habe keine Bedenken den zu verwenden, da immer mehrmals versucht wird den Strom zurück zu stellen. Habe bei mir auch noch kein "Hängenbleiben" erlebt. Außerdem werde ich noch weitere Trigger implementieren (u.a. Abstecken), was es noch sicherer machen wird.

Man könnte auch die (weiteren) Ladeprofile von M&M implementieren. Dann gäbe es auch im Auto eingestellte MaxSoC. Ich konzentriere mich aber aktuell auf die Grundfunktionen.

Ich persönlich wüsste im Moment auch nicht, wie man das Ganze zuverlässiger hinbekommt. Ich vermute, dass das OVMS noch nicht wirklich als OCU vom Bus akzeptiert ist (s.a. Kommentar von marxx). Das Wichtigste wäre, dass das Auto zuverlässig aufwacht (auch bei <12V). Wenn es mal wach ist, haben meine Befehle immer beim ersten Anlauf funktioniert (und falls nicht, wird automatisch bis zu 2x wiederholt).

sharkcow

[sharkcow]

Moin marxx,

1. Autodisable climate control ticker (30 min.)

Ja, ich musste viel ändern und das beizubehalten wäre etwas mühsam gewesen. Ich habe die Kommunikation (inkl. wakeup) inzwischen recht konsequent auf einen kleinen Zustandsautomat umgestellt. Da könnte man auch solche Timer einbauen. Ich persönlich finde das zusätzliche Abschalten aber verzichtbar. Ich habe auch noch keinen Fall erlebt, in dem das Steuergerät das nicht zuverlässig gemacht hätte. An der Stelle machen wir ja (inzwischen) wirklich genau dasselbe wie die OCU, nämlich mit Multiplex-Protokoll nur das Byte für's Klimatisieren setzen und Einschalten.

2. devmode

Ja, auch der ist leider dem umfangreichen Umbau zum Opfer gefallen... nachdem jetzt deutlich anders (und mehr) kommuniziert wird, wäre ein erneutes Implementieren tatsächlich ein großer Aufwand Ich selbst habe den aber nie benutzt, mir reicht ausführliches Logging (u.a. im verbose-Modus).

3. Ist sichergestellt, dass T26 noch ohne OBD funktioniert?

Ja, die Änderungen betreffen ja fast nur T26.

3. Kannst Du kurz beschreiben wie "profile" funktioniert?

Klar, mach ich in einem separaten Post.

Ansonsten habe ich die Vergleichstabelle von OVMS zu "we connect" (oder wie immer das VW Dings jetzt heißt) angepasst:

ovms_wecon5.png

Stimmt die so? Was machen wir mit den Zeitplänen und der Statistik? Lassen wir das erstmal so, oder verweisen wir darauf, dass das gescriptet werden kann?

Ja, danke, sollte passen. Die Zeitpläne und Statistik sind ja noch nicht wirklich niederschwellig nutzbar. Vielleicht können wir aber noch ein paar neue Kategorien aufnehmen, bei denen VW ein rotes X bekommt... z.B. Reifendruck, SOH (demnächst auch den internen...!)

sharkcow

[E-lmo]

@mbfoo
Ist Deine Wallbox nicht steuerbar?
(Quick@dirty würde es auch ein Shelly in der CP-Ader erledigen.)
Das Fahrzeug lädt dann an einer ungesteuerten Wallbox bis 100% durch und die heimische Wallbox wird über iobroker bei 80% abgeschaltet.

Ich lasse das schon länger so durch OpenWb erledigen. Den SOC fragt diese direkt lokal von OVMS ab.

[sharkcow]

Funktionsweise der Klima- und Ladesteuerung

Die Hintergrundinfos zum Multiplex-Protokoll und den Ladestandorten von dexter findet ihr hier: https://goingelectric.de/forum/download ... ?id=127443

Wir arbeiten bis jetzt nur mit dem ersten Profil/Ladestandort namens "Optionen", haben das daher mal Profil0 genannt. Man kann (mit M&M) weitere Ladeprofile mit Min-/MaxSoC, Klimatisierung etc einstellen. Wenn Profil0 mal sauber läuft, könnte man also auch die Funktionalität von M&M implementieren, z.B. für Leute wie mich, die gar keines haben

Das Profil0 wird im Ladesteuergerät (ID 69C) über PID 959 angefragt und geschrieben. Hier ein Beispiel mit den Bytes, deren Bedeutung wir kennen (fleißig geklaut bei dexter's Doku):

Anfrage:

Code: Alles auswählen

69E 90 04 19 59 27 00 00 01
    ^^--------------------- Kanal (80/90/A0), wir nehmen aktuell immer 90
       ^^------------------ Länge der Anfrage in Bytes
          ^---------------- Lesen
           ^ ^^------------ PID
                ^^--------- Sequenz-ID (wir nehmen aktuell immer 27)
                   ^^------ keine Teilstrukturadressierung, also alles
                      ^^--- ab Index 0
                         ^^ Anzahl Profile (Ladestandorte)

Antwort:

Code: Alles auswählen

69C 80 22 49 59 27 02 40 00
    ^^--------------------- Kanal
       ^^------------------ Länge
          ^---------------- push-update
           ^ ^^------------ PID
                ^^--------- Sequenz-ID
                   ^^------ Anzahl Profile insgesamt
                      ^^--- Satzstruktur (40=komplett)
                         ^^ ab Index 0
    c0 01 00 01 00 10 1e ff
       ^^------------------ Anzahl Profile in Antwort
             ^^------------ Schaltbyte Flags: b0: Laden, b1: Klima, b2: Klima auf Batterie
                   ^^------ MaxCurrent
                      ^^--- MinSoC     
    c1 ff 00 ff ff ff ff 01
    c2 78 00 1e 1e 0a 00 00
       ^^------------------ Temperatur (+100 /10)
             ^^------------ veränderbar, bei verschiedenen Autos 00..ff beobachtet
                ^^ ^^------ veränderbar, bisher nur 1e 0a bebachtet
    c3 08 4f 70 74 69 6f 6e
       len:O  p  t  i  o  n
    c4 65 6e 00 00 00 00 00
            e  n

(Ein guter Teil der Bytes ist anscheinend gar nicht beschreibbar; die M&M-Profile haben aber stellenweise auch anderen Inhalt, z.B. gibt es bei Profil0 leider keinen MaXSoC.)

Implementiert ist das Ganze in OVMS jetzt als Zustandsautomat, welcher folgende Zustände durchläuft (bis zum jeweils gewünschten Ziel):

(INIT) - IDLE - WAKE - REQUEST - READ - WRITE - WRITEREAD - SWITCH

Jeder Kommunikationsschritt wird bei Mißerfolg mehrfach wiederholt nach einer gewissen Wartezeit. Aktuell sind es 3 Wiederholungen in 1s-Abständen, das hat bei mir bisher noch immer gereicht.

Das gewünschte Ziel wird gesetzt in der Variable profile_key:

P0_KEY_READ / _CLIMIT (MaxCurrent) / _CC_TEMP (Temperatur Vorklimatisierung) / _SWITCH

Bei P0_KEY_SWITCH steht in profile0_activate, was ins Schaltbyte des Steuergeräts geschrieben wird, also ob die Ladung geschaltet wird oder Klima (und ob aus dem Akku klimatisiert wird).

Wenn dann WakeupT26() ausgeführt wird, geht's los.

Der größte Bug aus meiner Sicht ist immer noch, dass das Auto manchmal nicht aufwacht. Es scheint eine Korrelation mit der Spannung der 12V-Batterie zu geben (unter 12V klappt's oft nicht). Wenn man den Wakeup allerdings gleich wiederholt, geht es. Die Wiederholungen, die im Zustandsautomat eingebaut sind, klappen aber nicht... Bin da noch an der Fehlersuche.

sharkcow

[marxx]

Servus sharkcow

wow Vielen Dank für die super Erklärung.

Das mit dem "nicht-Aufwachen" bei Spannung unter 12V von der Bordbatterie ist indertat rätselhaft. Aber wenigstens haben wir da jetzt den Grund gefunden. Was ich da sehe ist, dass beim wakeup bei Spannung kleiner 12V erst zögerlich (und manchmal auch nichtt) das Laden der 12V Batterie im Auto getriggert wird. Erst wenn die 12V Batterie dann geladen wird, kann die Klimasteuerung gestartet werden.

Im Idealfall müsste also zuerst geprüft werden "ist die Bordbatterie unter 12V". Wenn nein, starte die Klimasteuerung. Wenn ja, starte das Laden der 12V Batterie, warte etwas und starte dann erst die Klimasteuerung.

Da aber der jetztige Workaround "drei mal Starten bis es funktioniert" läuft, hat das sicher keine hohe Priorität.

Ich habe die Tabelle neu gemacht:

"Durchschnittsverbrauch" habe ich wieder ausgekreuzt. Das machen wir ja noch nicht, oder?

@dexter Gibt es noch keinen Standard dafür im OVMS? Übersehe ich da etwas?

Falls so, wäre es cool dafür eine allgemeine OVMS-Funktion, eine Darstellung im WebIf unter "Status" und ein Feld dafür in der App zu haben. Sicherlich auch interessant für andere Fahrzeuge.

Aber, wie gesagt, korrigiert mich bitte, wenn ich da was übersehe.

marxx