openWB Forum

Verfasst: **So Jan 14, 2024 9:07 pm**

Ich baue den soc_helper gerade ziemlich um. Wer neugierig ist kann hier einen Stand testen:

2024-01-14: Feature-Update

Größere Überarbeitungen. Ratschlag: Nehmt die mitgelieferte configuration.py und
tragt dort Eure Daten ein.
!!! Es ist jetzt zusätzlich das python-Modul "watchdog" erforderlich !!!
* Zergliederung des Codes zur besseren Lesbarkeit. die Ladeklasse aufgeräumt
  und wie die logfunktion in separate Datei ausgegliedert.
* Feature: Überwachung eingefügt, damit bei Änderung an configuration.py der
  Inhalt der Datei neu eingelesen und ein manuelles Stoppen und Starten von
  soc_helper.py überflüssig wird. Eine Änderung des Strompreises oder anderer
  Parameter erfordert damit weniger Handarbeit.
* Feature: Funktionen zur Berechnung von SOC und Kilometerstand in
  configuration.py umgezogen zur besseren Anpaßbarkeit für andere Fahrzeuge.
* Feature: Spritmonitor:  Programm funktioniert jetzt auch mit Spritmonitor,
  wenn dort noch keine Betankung gespeichert ist - in diesem Fall wird eine
  Erstbetankung angegeben.
* Feature: Spritmonitor: In configuration.py können Default-Werte für
  Reifentyp, Fahrweise und Zusatzverbraucher (Klima, Standheizung, Anhänger)
  definiert werden, die beim Hochladen angegeben werden.
* Konsolenausgabe neu formatiert.

Durch die Überwachung von configuration.py kann jetzt einfach nach
Reifenwechsel der aktuellen Reifentyp geändert werden - das Programm liest
die geänderte Konfiguration automatisch ein. Kein kill und manueller
Neustart mehr erforderlich! Das Gleiche, wenn im Frühjahr oder Herbst der
angenommene Strompreis von PV auf Netzbezug oder umgekehrt konfiguriert
wird.

Wahrscheinlich sind noch etliche bugs vorhanden, ich habe wenige Ladevorgänge zur Zeit.

Verfasst: **Sa Jan 20, 2024 2:42 pm**

Hallo zut,

das Problem mit dem Kilometerstand habe ich noch nicht gelöst (soll mit dem Schutz vor Tachozurückdrehern zu tun haben), aber die Reichweite in Kilometer habe ich rausgefunden:

wenn ich folgendes zum MeatPi sende,
{ "bus": "0", "type": "tx", "frame": [{ "id": 1812, "dlc": 8, "rtr": false, "extd": false, "data": [3, 34, 34, 224, 170, 170, 170, 170] }] };

antwortet der E-Up mit
{"bus":"0","type":"rx","ts":6698,"frame":[{"id":1918,"dlc":8,"rtr":false,"extd":false,"data":[5,98,34,224,0,93,170,170]}]}

in Data die 0 (x 256) plus die 93 sind die voraussichtliche Reichweite in Kilometer, wie im E-Up Display. In meinem Fall 93 km

(Falls es von Interesse ist...)

Grüße
c

Verfasst: **Sa Jan 20, 2024 8:37 pm**

Ich bin mir nicht sicher, ob die beim Ankommen errechnete Reichweite von Nutzen sein kann: Wenn ich an die Wallbox heranfahre, brauche ich sie nicht. Eigentlich müsste das SOC-Modul aus der Wallbox die Reichweite mitrechnen, aber das kommt wohl erst später. Gibt es eine Interessante Anwendung für die Reichweite bei Ankunft?

Den Link aus dem Readme kennst Du?: https://www.goingelectric.de/wiki/Liste-der-OBD2-Codes/

Mögliche Spielplätze, die mir einfallen:

Aus dem HV-System den vom Kunden eingestellte Max-SOC aus dem Fahrzeug auslesen und an die Wallbox übertragen - für mich nicht sinnvoll, da ich das lieber flexibel in der Wallbox nutze. Das Auto soll bei Bedarf volladen, ohne daß ich da mit der furchtbaren App drin rummache.
Das Hochvolt-Ladegerät hat eine Angabe der Effizienz. Möglicherweise könnte man das ständig im SOC-Modul der Wallbox aktualisieren - allerdings müsste dann auch der OBD-Adapter während der Ladung immer wach sein. Meiner Meinung nach legt sich die Kommunikation nach einiger Zeit hin, wenn der VW-Server nicht mit dem Auto spricht.
Interessant ist die geschätzte Kapazität der Batterie: https://www.goingelectric.de/wiki/VW-e-up-OBD2-SG17 unter 0x22 0x22 0xE4. Hier könnte man noch mitloggen, für wie gesund das Fahrzeug den Akku hält!
km-Stand gemäß https://www.goingelectric.de/wiki/VW-e-up-OBD2-SG8C, Kommando 0x22 0x02 0xBD; allerdings ist die Antwort wohl lang und es sind die Bytes bb bis dd nötig. Ich könnte mal prüfen, ob die Antwort vom WiCAN ausgegeben wird und was da zurück kommt. Meine Vermutung ist, daß der WiCAN mit der langen (extended?) Anwort noch nicht umgehen kann.

Verfasst: **So Jan 21, 2024 10:09 am**

Hallo zut,

ich habe bei Meatpi nachgefragt und einen Tipp bekommen. Bei mir läuft es jetzt kilometergenau. Zur Sicherheit muss ich nach einigen Kilometern gegenchecken.

https://github.com/meatpiHQ/wican-fw/issues/83

Grüße
c

Verfasst: **So Jan 21, 2024 10:18 am**

Das ist sehr cool! Ich habe gestern schon mal erste Änderungen für die neue Botschaft gemacht. Mit den von dir gewonnenen Information kann ich das bestimmt zum Laufen bekommen. Muss noch darüber nachdenken, wie ich das konfigurierbar mache - eventuell muss ich bei der Beschreibung der can-Botschaften eine Abstraktionsebene einfügen. Das halte ich für machbar.

Verfasst: **So Jan 21, 2024 9:13 pm**

Habe gerade zu den Protokolle CAN-TP und CAN-FD gelesen:
https://en.m.wikipedia.org/wiki/ISO_15765-2
Ist echt nicht übermäßig schwer. Jetzt liegt es natürlich nahe einen Interpreter zu schreiben, falls es den nicht schon gibt. Ich verstehe jedenfalls die Bedeutungen der Bytes für mehrteilige Botschaften...

Verfasst: **Mo Jan 22, 2024 8:41 pm**

Ich habe mal eine einfache Möglichkeit umgesetzt, mehrteilige Botschaften zu empfangen. Der Kilometerstand kommt bei mir jetzt auch in 1km-Quantisierungen

Alpha-Version im ersten Artikel.

Verfasst: **Di Jan 23, 2024 7:04 am**

Hallo zut,

das von dir erwähnte Register mit der geschätzten Kapazität, zeigt nur bei 100% SoC die Gesamt-Kapazität der Batterie an. Also wäre "momentane Kapazität" treffender. Natürlich kann man mit diesem Wert, zusammen mit dem SoC, der Reichweitenkapazität und der Temperatur eine Aussage über Batteriezustand, Umgebungseinfluss und Fahrstil treffen.

Grüße
c

Verfasst: **Mo Jan 29, 2024 3:21 pm**

Geile Sache!

Was ich mich beim Blick auf die Config frage:

Beim Ora heißt es:
" The battery SoC is calculated using Byte 4 and Byte 5, ((2*256)+69)/10"
https://github.com/meatpiHQ/wican-fw/di ... nt-7345365

und

"The milage the expression is: (B5*256)+B6"
https://github.com/meatpiHQ/wican-fw/di ... nt-7348800

Den SOC_REQUEST bekomme ich angepasst:

Code: Alles auswählen

{"bus":"0","type":"tx","ts":21767,"frame":[{"id":1931,"dlc":8,"rtr":false,"extd":false,"data":[3,34,3,8,170,170,170,170]}]}

VALID_SOC_ID ist 1995 (Vermutung auf Basis von https://github.com/meatpiHQ/wican-fw/di ... nt-7345365)

DST_REQUEST auch:

Code: Alles auswählen

{"bus":"0","type":"tx","ts":39812,"frame":[{"id":1931,"dlc":8,"rtr":false,"extd":false,"data":[3,34,208,4,170,170,170,170]}]}

VALID_DST_ID analog

Aber vorher weiß ich jetzt, was ich bei VALID_SOC_ANSWER bzw. VALID_DST_ANSWER für Bytes eintragen muss?
Vermutlich

Code: Alles auswählen

VALID_SOC_ANSWER=[98,3,8]

Wenn eine Antwort so ausschaut

Code: Alles auswählen

{"bus":"0","type":"rx","ts":21782,"frame":[{"id":1995,"dlc":8,"rtr":false,"extd":false,"data":[5,98,3,8,2,69,204,204]}]}

Und

Code: Alles auswählen

def getSoc(bytes):
    soc = round((bytes[4]*256+bytes[5])/10)
    return soc

dann die Formel?

Hab den OBDII-Adapter noch nicht, deshalb kann ich nicht ausprobieren.

(cool wäre natürlich, man könnte das irgendwie direkt als offizielles openWB-Script laufen lassen)

Verfasst: **Mo Jan 29, 2024 7:33 pm**

Kitmgue hat geschrieben: ↑Mo Jan 29, 2024 3:21 pm [...]
Beim Ora heißt es:
" The battery SoC is calculated using Byte 4 and Byte 5, ((2*256)+69)/10"
https://github.com/meatpiHQ/wican-fw/di ... nt-7345365
und
"The milage the expression is: (B5*256)+B6"
https://github.com/meatpiHQ/wican-fw/di ... nt-7348800
[...]
Aber vorher weiß ich jetzt, was ich bei VALID_SOC_ANSWER bzw. VALID_DST_ANSWER für Bytes eintragen muss?
Vermutlich
Code: Alles auswählen
VALID_SOC_ANSWER=[98,3,8]
Wenn eine Antwort so ausschaut
Code: Alles auswählen
{"bus":"0","type":"rx","ts":21782,"frame":[{"id":1995,"dlc":8,"rtr":false,"extd":false,"data":[5,98,3,8,2,69,204,204]}]}

Richtig. Nach der Anzahl der Nutzbytes der Botschaft folgt in der Antwort der Befehl, der gesendet wurde, also 34,3,8, wobei das erste Byte per Definition einen Offset von 64 bekommt. Auf das Kommando 34,3,8 folgt also 98,3,8 in der Antwort nach der 5, die die Anzahl der Nutzbytes anzeigt. Die 2 und 69 sind die restliche Nutzlast.

Kitmgue hat geschrieben: ↑Mo Jan 29, 2024 3:21 pm Und
Code: Alles auswählen
def getSoc(bytes):
    soc = round((bytes[4]*256+bytes[5])/10)
    return soc
dann die Formel?

Hab den OBDII-Adapter noch nicht, deshalb kann ich nicht ausprobieren.
(cool wäre natürlich, man könnte das irgendwie direkt als offizielles openWB-Script laufen lassen)

Auch richtig. Nach meiner vorletzten Änderung werden die Daten der Antwort in einer neue Liste zusammengebaut - in dieser steht an Index 0 die ID der Antwort, also bei Dir 1995, gefolgt von dem wie oben modifizierten Kommando und dann den Daten. In deinem Fall enthält bytes also
[1995, 98, 3, 8, 2, 69, 204, 204].

Ich habe nach diesen Angaben die configuration.py mal ergänzt und hänge sie an. Bei der nächsten Veröffentlichung ist es dabei, daher bitte ich um Prüfung, sobald Hardware verfügbar.

[Die Dateierweiterung zip wurde deaktiviert und kann nicht länger angezeigt werden.]

openWB Forum

Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)

Re: Projekt: SOC von OBD2-Buchse in die Wallbox (ohne Cloud)