OVMS für den VW e-Up

[spoeh-man]

Ich glaube das ist der Bug dass das Laden nicht zuverlässig erkannt wird zeigt die App die Ladung an bevor du die Ladetaste drückst

[donaldduck8]

Das ist genau dieser Bug, auch die App zeigt die Ladung nicht an.

Meine Hoffnung ist, das mit den Metrics (xvu.e.hv.chgmode) zu umgehen.

[dexter]

Ich möchte jetzt gerne ein einfaches Ladelog erstellen

Vorab: das System schickt Dir von Haus aus beim Ladestart und -stopp Nachrichten mit Kilometer- und Ladestand sowie einigen Infos mehr. Falls die nicht bei Dir ankommen stimmt mit Deiner Konfiguration etwas nicht.

Optional kannst Du zusätzlich ein tabellarisches Ladebuch vollautomatisch generieren lassen:
https://docs.openvehicles.com/en/latest ... istory-log

Die Tabelle "*-LOG-Grid" liegt dann auf dem Server, kannst Du von dort manuell herunterladen oder Dir täglich mit dem Datenexport von meinem Server mailen lassen.

Achtung, wenn Du während des Ladens nur MQTT nutzt: MQTT-Server erhalten die Nachrichten und Datenaufzeichnungen zwar auch, haben dafür aber kein Standardhandling. D.h. ohne passende Scripte rutschen die Daten idR einfach durch.

1. event
Ladestecker wird gesteckt
Kilometerstand und Ladestand (SOC) wird per notification ans Handy geschickt.

2. event
Ladestecker wird herausgezogen
Ladestand (SOC) wird per notification ans Handy geschickt.

Jetzt gibt es die beiden events die auf diese Bedingung reagieren sollten:
vehicle.charge.start
vehicle.charge.stop

Tun sie aber nicht, erst wenn ich die Lademodustaste drücke und den Ladetimer deaktiviere geht es.
Dann bekomme ich die notification, aber dann wird immer bis 100% geladen.

Gibt es da eine andere Möglichkeit?
Bei den Metrics gibt es z.b. den Parameter
xvu.e.hv.chgmode
dieser wechselt mit gestecktem Stecker von 0 auf 1
Ist es möglich diesen an ein event zu binden?

Ladestecker rein/raus hat zunächst einmal keine direkte Entsprechung mit dem eigentlichen Ladevorgang. Den Steckerstatus lesen wir noch nicht direkt aus, dass der an "xvu.e.hv.chgmode" ablesbar ist wäre mir neu. Ich vermute das funktioniert nur, wenn der Stecker auch schon Strom hat, müsste ich aber mal selbst testen.

An die Metric auch ein Event zu koppeln kann ich unabhängig davon gern einrichten, bzw. besser an die davon abgeleitete Standard-Metric "v.c.type".

Aber die Lade-Events "vehicle.charge.start/stop" sind eigentlich schon die korrekten Events für Dich, diese werden auch für die o.g. Systemnachrichten verwendet. Die hängen an der Metric "v.c.charging", und die funktioniert auch mit Ladetimer -- ich lade fast immer per Timer nur bis 80%.

Oder genauer gesagt, im reinen OBD-Modus, funktioniert das alles. Hast Du den T26 aktiv? Eventuell gibt's da noch einen Bug. Probier dann doch mal, während der Ladung nur OBD zu verwenden.

[donaldduck8]

Bei den Metrics gibt es z.b. den Parameter
"xvu.e.hv.chgmode" dieser wechselt mit gestecktem Stecker von 0 auf 1

sorry das hatte ich missverständlich geschrieben.
Gemeint war damit:
Ich stecke den Ladestecker (AC), die Ladung beginnt, "xvu.e.hv.chgmode" springt von 0 auf 1
Ich beende den Ladevorgang und ziehe den Ladestecker (AC), die Ladung stoppt, "xvu.e.hv.chgmode" springt von 1 auf 0


Das OVMS hängt an OBD und T26 und das ist ja der Bug.
Wenn ich nur OBD an habe funktioniert ja alles was du bechrieben hast, also die Systemnachricht, das Ladelog und auch die Lade-Events "vehicle.charge.start/stop"

Das Problem hatte ich hier schonmal beschrieben:

Hallo,
leider ist dieser Beitrag völlig untergegangen.
Ich möchte deshalb nochmals nachfragen:
Ist das bei euch auch so oder nur bei mir?
1. AbfahrtzeitenTimer ist gesetzt, dann wird die AC-Ladung in der App nicht erkannt.
2. AbfahrtzeitenTimer ist gelöscht, dann wird die AC-Ladung in der App erkannt aber nach Ladeende nicht mehr zurückgesetzt.

Mit "da" meinte ich bei OBD-Nutzung. Der Fehler steckt offenbar im T26-Part oder dem Zusammenspiel der beiden. Das Logging bringt da vermutlich erst mal auch nicht mehr, das T26-Modul loggt ohne Custom-Build nur die korrekt erkannten Statuswechsel, nicht die Datengrundlage (das wäre zuviel).
Alles was Du mit dem Ladelog haben willst geht aber auch mit OBD alleine, das habe ich ja auf der Basis entwickelt und mache ich selbst auch so.

Der Fehler steckt leider immer noch im T26 Part.
Nur OBD zu nutzen damit das Ladelog funktioniert ist keine Option, da ich weiterhin die Vorklimatisierung benötige.

Hab mal die Metric "v.c.type" getestet (OBD+T26+Ladetimer an)
Nach Ladestart wechselt die Metric von "" auf "type2"
Nach Ladeende wechselt die Metric von "type2" auf ""

Wenn du die an ein event koppeln könntest würde das erstmal helfen.

Gruss Donald

[dexter]

Ach ja, Danke für den Reminder. Da sollte aber mittelfristig doch besser der Bug gefixt werden.

However, versprochen ist versprochen, das Event ist jetzt da: "vehicle.charge.type"

Dazu direkt noch ein Tipp: Du kannst das auch nutzen, um die fehlenden Statuswechsel zu faken, wodurch Du -theoretisch- die System-Ladenachrichten wieder bekommst. Das machst Du so:

Code: Alles auswählen

/* Event-Script: /store/events/vehicle.charge.type/40-fakestate.js */
(function(){

  var m = OvmsMetrics.GetValues([ "v.c.type" ]);

  if (m["v.c.type"] != "") {
    OvmsCommand.Exec("metrics set v.d.cp yes");
    OvmsCommand.Exec("metrics set v.c.state charging");
  } else {
    OvmsCommand.Exec("metrics set v.c.state done");
    OvmsCommand.Exec("metrics set v.d.cp no");
  }

})()

Der Ladeport (v.d.cp) muss offen sein, damit die Status-Nachricht die Ladedaten enthält. Zusatzhinweis: nach dem Statuswechsel wartet das System automatisch ein paar Sekunden bis die Nachrichten generiert werden, das hat den Sinn, den stabilen Ladestart abzuwarten.

Wenn Du lieber stattdessen oder zusätzlich dazu eigene Notifications senden möchtest, hier der Rumpf dafür mit Steckertyp und SOC:

Code: Alles auswählen

/* Event-Script: /store/events/vehicle.charge.type/60-mynotify.js */
(function(){

  var m = OvmsMetrics.GetValues([ "v.c.type", "v.b.soc" ]);

  if (m["v.c.type"] != "") {
    OvmsNotify.Raise("info", "usr.charge.start", "Ladung per " + m["v.c.type"].toUpperCase() + "\nbei SOC " + m["v.b.soc"] + "%\n");
  } else {
    OvmsNotify.Raise("info", "usr.charge.stop", "Ladung beendet\nbei SOC: " + m["v.b.soc"] + "%\n");
  }

})()

Weitere benötigte Metrics für die Nachricht klinkst Du einfach in das Array bei GetValues ein.

[donaldduck8]

Hallo Michael,
erstmal danke für deine Bemühungen.

Leider funktioniert das alles nicht so richtig

Was ich gemacht habe:
Update OVMS von 3.3.003-72 auf die neueste edge Version 3.3.003-114
Das neue event "vehicle.charge.type" ist ja dazugekommen.
Dazu dein "40-fakestate.js" angelegt und ein eigenes script mit einfacher Textnachricht (notify raise text info usr.anton.welcome "Ladung Change") erstellt.


Wenn die Ladung gestartet wird bekomme ich einmal die Nachricht "Ladung Change"
Bei Ladeende passiert nichts mehr, keine Nachricht auch nach stunden nicht

Der Grund dafür scheint zu sein das sich die metrik "v.c.type" nun dauerhaft auf "type2" befindet.
Wenn ich die metrik mit "metrics set v.c.type """ in den Ursprungszustand zurücksetzte funktioniert das event wieder einmal(statusänderung) und mit dem erneuten Ladestart nocheinmal , das wars dann aber.


Du schreibst "Der Ladeport (v.d.cp) muss offen sein, damit die Status-Nachricht die Ladedaten enthält"
Was meinst du denn mit Ladeport? Den Klappdeckel vom Ladestecker, der wird doch gar nicht ausgewertet.
Außerdem ändert sich diese metric überhaupt nicht, sie bleibt dauerhaft auf "no"

Hier nochmal die genauen metrics zur Analyse:

Auto verschlossen (Ursprungszustand)

xvu.e.hv.chgmode 0
v.c.type
v.d.cp no
v.c.state done


Auto aufgeschlossen
Stecker in die Ladedose Wallbox (AC)
Auto im Ladevorgang

xvu.e.hv.chgmode 1
v.c.type type2
v.d.cp no
v.c.state done


Ladevorgang beendet (Fernbedienung auf)
Stecker aus in die Ladedose gezogen

xvu.e.hv.chgmode 0
v.c.type type2 und bleibt auch stundenlang
v.d.cp no
v.c.state done


Das einzige was hier sicher funktioniert ist "xvu.e.hv.chgmode", wahrscheinlich wäre es besser gewesen das event an diesen zu binden.
Jetzt nach dem ich "v.c.type" manuell mehrfach zurückgesetzt habe, (siehe oben) reagiert er überhaupt nicht mehr auf Ladestart, also kein "type2" mehr nur "".
Hmmm...

[dexter]

Hmpf. Ja, wo ich da jetzt nochmal drüberschaue, das Löschen von "v.c.type" passiert auch erst nach erkanntem Ladestop, was ja gerade nicht funktioniert.

"xvu.e.hv.chgmode" ist eine interne Debug-Metrik, da mag ich kein Event dran hängen. Ich hatte mal über nutzerdefinierbare Events auf Metrikänderungen nachgedacht, das braucht aber noch was.

Mach's daher vorerst am besten per Ticker-Script:

Code: Alles auswählen

/* Event-Script: /store/events/ticker.10/50-fakestate.js */

// Statusspeicher im globalen Kontext anlegen:
var usrState = usrState || {};

(function(){

  var m = OvmsMetrics.GetValues([ "xvu.e.hv.chgmode" ]);

  // Statusänderung?
  if (m["xvu.e.hv.chgmode"] == (usrState["xvu.e.hv.chgmode"]||0)) return;
  usrState["xvu.e.hv.chgmode"] = m["xvu.e.hv.chgmode"];

  // Ladestart/-stop faken:
  if (m["xvu.e.hv.chgmode"] > 0) {
    OvmsCommand.Exec("metrics set v.d.cp yes");
    OvmsCommand.Exec("metrics set v.c.state charging");
  } else {
    OvmsCommand.Exec("metrics set v.c.state done");
    OvmsCommand.Exec("metrics set v.d.cp no");
  }

})()

Das Script läuft per "ticker.10" alle 10 Sekunden und prüft, ob sich der Zustand der Metrik geändert hat.

Testen kannst Du das per manuellem Setzen von "xvu.e.hv.chgmode", das geht nur wenn das Fahrzeug nicht wach ist.

Das andere Script solltest Du entsprechend wieder löschen, dieses macht alles nötige.

[donaldduck8]

Wouww riesengroßes daaaankeschööön an dexter
!!! Es läuft so wie es soll !!! (Ja ist es denn schon Weihnachten?).

Also mal kurz zusammengefasst als Überblick wofür das Ganze gut ist:
OVMS angeschlossen an OBD+T26 und Ladetimer aktiv = AC Ladung wird nicht erkannt

Nach diesem letzten Hack "50-fakestate.js" wird die AC Ladung sicher erkannt und nach Ladeende auch wieder zurückgesetzt.
In der APP kommt die Systemnachricht und es wird der Ladestatus der Batterie mit den (orange) farbigen Polkappen angezeigt.

Das Ladelog kann ich jetzt aus den "Grid history log" daten vom dexter server entnehmen, oder ich versuche die Befehle von "60-mynotify.js" in das obige script zu integrieren - alles ist jetzt möglich.

Gruss Donald

[1337]

Hallo zusammen,
ich würde OVMS primär zur Vorklimatisierung nutzen wollen. Reicht es dafür aus, nur den T26 Anschluss anzubinden? Ggf später würde ich dann den OBD noch anschließen.

[TP-eUp2017]

Guten Morgen,

ich hätte Interesse an der OVMS und dem Kabel.
Sind die Sachen noch zu verkaufen?

MFG Tobias

Moin,

wir müssen uns leider von unserem Up trennen. Daher biete ich euch hier mein OVMS an. Ist mit 2/3 G Modem, und mit meinen Adaptern. Ich hatte das OVMS unterm Beifahrersitz, die 2 offenen Leitungen gingen über ein Kabel hinter den OBD Port. Könnte man wieder genauso verbauen, oder die OBD Leitungen Isolieren / ComfortCAN-Only, oder sich einen eigenen Adapter Kaufen/Basteln. Ist auf Werkseinstellungen zurückgesetzt.

120€ inkl. Versand.