OVMS für den VW e-Up

[marxx]

Ja, die Innentemperatur ist überarbeitungsbedürftig. Ich hatte heute auch exorbitante Werte.

Da dürfen wir mal wieder durch die Logfiles trüffeln

Werde bald wieder loslegen. War jetzt Tage beschäftigt Maps and More unter LineageOS mit root und AFWall+ und IPv6 kastriert zum Laufen zu bringen. Geht seit heute

viewtopic.php?p=1309096#p1309096

marxx

[sharkcow]

Zum Glück hab ich kein M&M, dann bleibt mein LOS verschont

Gibt's eigentlich eine einfache Möglichkeit, den Zeitstempel der letzten erfolgreich vom CAN gelesenen Botschaft über OVMS auszulesen? Dann könnte ich das verwenden um die Aktualität der Werte in meiner App zu bewerten.

[dexter]

Das Framework hält die Aktualität nicht global, sondern pro Metric nach. Das Alter der letzten Änderung kann per Age() abgefragt werden, ob der spezifische Messwert sich selbst als veraltet ansieht per IsStale().

Die Info über die "Staleness" zeigt der Befehl "metrics list" mit der Option "-s" an. Ansonsten wird die Info bislang nur verwendet, um die alten V2-Staleness-Flags im V2-Protokoll zu generieren. Eine Script-API dafür sowie Transport per WebSocket oder MQTT ist Todo.

[Dimitrie78]

Das Script für OpenWB Soc abfrage @dexter

Code: Alles auswählen

/**
 * Module plugin: openWB soc
 *  Version 1.0
 * 
 * Installation:
 *  - Save as /store/scripts/lib/openwbsoc.js
 *  - Add to /store/scripts/ovmsmain.js: openwbsoc = require("lib/openwbsoc");
 *  - Issue "script reload"
 * 
 * Use:
 *  - http://192.168.4.1/api/execute?apikey=password&command=openwbsoc.get()&output=text&type=js
 */


// Get state of charge:
function getSoc() {
  var soc = OvmsMetrics.Value(["v.b.soc"]);
  
  if ( soc )
    print( soc );
  else print(0);
}

// API exports:
exports.get = getSoc;

Das sollte aber eigentlich nicht zu abstürzen führen.

[der kleine Nik]

@sharkcow
Leider kann ich das gerade nicht vergleichen aber je nach dem wo das ntc vom Innenraum liegt können 40c sowohl rohwert als auch berechneter sein. Beide sagen nur aus zu warm. In dem Bereich ist der Wert selber nicht relevant, nur wie sich das Fahrzeug bei dem Wert im Bereich kühlen verhält. Ich war schon in Autos die sagen dir 40c bei einer innenraumtemp von 20c. Und einer Außentemp von -20c. Muss wirklich mal meine HW Einsatz bereit bekommen.

Grüße
Nik

[sharkcow]

Das Framework hält die Aktualität nicht global, sondern pro Metric nach. Das Alter der letzten Änderung kann per Age() abgefragt werden, ob der spezifische Messwert sich selbst als veraltet ansieht per IsStale().

Die Info über die "Staleness" zeigt der Befehl "metrics list" mit der Option "-s" an. Ansonsten wird die Info bislang nur verwendet, um die alten V2-Staleness-Flags im V2-Protokoll zu generieren. Eine Script-API dafür sowie Transport per WebSocket oder MQTT ist Todo.

Verstehe ich das richtig, dass ich die Age()-Eigenschaft im Quellcode einbauen müsste? Der Tipp mit den metrics in der shell ist aber schon mal super, danke! (Und danke dass du meinen inkompetenten Post zum a2l nicht kommentiert hast: natürlich habe ich den Pfad zum .elf nicht genau genug angeschaut jetzt geht es. Falls ich dir also Infos von einem crash schicken soll sag Bescheid. Ich bekomme jetzt wieder häufiger welche, scheinen aber verschiedene Ursachen zu sein).

[dexter]

Die Age()-Eigenschaft implementieren die Metrics generell schon, bei jeder Aktualisierung der Werte wird das Alter automatisch auch aktualisiert. Falls Du meinst, dass Du das Alter für Deinen Anwendungsfall abfragen willst, dann hängt es davon ab, wo und wie oft Du das Alter brauchst. Im Modul (C++) fragst Du es einfach über den Metric-Zeiger ab. Wenn Du es im Script oder in der Web-UI brauchst, macht es Sinn, die APIs dafür zu erweitern. Wenn Du es im Server oder einer App brauchst, müssten die Übertragungsprotokolle dafür erweitert werden.

Oder Du rufst halt hilfsweise erst mal "metric list -s" auf und liest die Info aus der Ausgabe. Kommandos kannst Du über alle APIs und Protokolle ausführen.

[marxx]

***

Es gibt neue größere Fortschritte zu vermelden

Soko has joined the club Und er hat den Code super cool aufgesplittet.

https://github.com/devmarxx/Open-Vehicl ... icle_vweup

Es gibt jetzt zwei VW e-UP Konfigurationsmöglichkeiten. Einmal "VW e-Up (Komfort CAN)" und jetzt neu "VW e-Up (OBD)" im OVMS.

"VW e-Up (Komfort CAN)" ist wie gehabt über den T26A Stecker unter dem Beifahrersitz mit Anschlussmöglichkeit an der GSM und GPS Antenne vom e-Up selbst. "VW e-Up (OBD)" ist neu und geht mit eigener GSM und GPS Antenne und über den OBD Stecker vom Auto.

Vorteil von der neuen Variante ist

- wir müssen den Beifahrersitz nicht mehr ausbauen um das OVMS einzubauen
- wir können sharkcows Codes benutzen

Nachteil momentan

- es kann bisher nur den SOC auslesen (da kommt aber sehr bald mehr denke ich)
- es geht durch das VW Gateway und da können wir noch nicht schreiben, somit kein Climate Control

Ich werde mich weiterhin um die T26A Variante kümmern, weil ich mit dem Schreibzugriff auf dem Komfort CAN die Klimaanlage steuern kann. Freue mich aber riesig, dass am OBD nun auch gearbeitet wird. Und echt cool, wie der Code auseinander dividiert ist. So können wir unabhängig voneinander beide Optionen voranbringen. Big thanx to Soko

Das alles steht den Betatestern zur Verfügung (siehe drei Sternchen oben) und ist noch nicht im offiziellen OVMS Release enthalten. Unsere eigene Betaversion hat den geplitteten Code, die gefixte Ausgabe vom Scripting und Climate Control unter T26A immer noch nicht repariert.

Wenn ein Betatester die neue Version flashen will, bitte unbedingt vorher ein vorhandene "VW e-Up" vehicle configuration im OVMS auf "Nissan Leaf" umstellen und dann erst den OTA flash mit reboot machen. Nach dem Reboot dann die vehicle config auf "VW e-Up (Komfort CAN)" oder"VW e-Up (OBD)" stellen. Klingt komisch, muss aber sein, sonst crasht das OVMS beim Reboot und kann nur noch über das USB Terminal angesprochen werden! Das wird im Release für alle natürlich nicht so sein, wird dran gearbeitet ...

Bei Fragen einfach melden.

Da geht was

Greetinx

marxx

[sharkcow]

Die Ursache für meine Abstürze scheint gefunden: mein WLAN ist im Auto so schwach, dass es manchmal unter -89dBm sinkt und dann stürzt OVMS ab. Danke an dexter für den Tipp, ich würde natürlich hoffen dass sowas von den fähigen OVMS-Entwicklern nicht als normales Verhalten betrachtet wird...

Jetzt habe ich aber ein anderes Thema: die Abfrage per http get bei OVMS liefert manchmal längere Zeit veraltete Werte. Leider auch beim Laden, was das SoC-gesteuerte Laden verunmöglicht. Sobald ich mich im webinterface vom OVMS einlogge, werden die Werte wieder aktualisiert. Daher zwei Fragen:
a) ist das bei euch auch so (v.a. an E-Imo, der das SoC-gesteuerte Laden ja am Laufen hat)?
b) was genau ist die Ursache? Schläft der KCAN ein und ein Login weckt ihn auf?

Danke,

sharkcow

[der kleine Nik]

Hallo sharkow,

#1. Lädst du in dem Moment aktiv?
#2. Hast du in dem Moment ein flackern auf dem Display?

zu1. denke nicht das du das meintest aber das Auto versucht natürlich so viel Batterie wie möglich zu sparen, schläft also ein wenn du PV mäßig das system zurückfährst oder Zeitlich gesteuert. --> Glaube aber das überwachst du eh noch auf einer 2 Leitung.

zu2. Beim Flackern auf dem Display würdest du in dem Moment den CAN überlasten. Typisches Zeichen. Aber nicht immer. kann auch ohne flackern sein. Manche InK CAN sind oft überfordert, da die Komfort Elektronik im Auto immer mehr zunimmt und zum Zeit der Planung war da halt noch nicht so viel bei dem AUto.