SoC: MeatPi WiCAN + Manueller SoC (AutoPID)

[ChristophR]

Richtig.

Und geht er bei einem Ladevorgang (normalerweise) wenigstens einmal über 13,8V oder tut er das bei Dir nur, wenn die Zündung an ist?
Hintergrund ist, ob ich den Unterschied zwischen Klimatisierung (Meist unter 13,8V aber über 13,1V) und Laden (wenigstens kurzfristig über 13,8V) erkennen kann.
Dass er ca. alle 12 Stunden mal die NV Batterie nachlädt und dann auch über 13,8V geht, konnte ich schon beobachten, das wäre aber zu verkraften.

[zut]

So genau habe ich das nicht beobachtet - mit fiel nur auf dass die Abfragen, wenn ich sie manuell durchführte, einige Minuten (15-20) nach Ladebeginn funktionierten und irgendwann keine Antwort mehr kann.

[mattberlin]

Es scheint echt gut zu funktionieren. Und das Beste ist, dass der SoC während des Ladens (denn der DC/DC ist hierbei aktiv) alle 60000 ms aktualisiert wird.

Kannst Du mal probieren, ob er bei 13,8 Sleep Voltage auch beim Laden lange genug aktiv ist?

Kann ich gerne machen, aktuell habe ich 13,3 V eingestellt, die nach kurzer Schreit unterschritten werden, sobald nach Zündung aus kurze Zeit später HV und somit der DC/DC inaktiv geschalten werden.
Ich glaube, dass bei 13,8 V der WiCAN abschalten würde.

[mattberlin]

Also, am Anfang des Ladens beträgt die Spannung 14,x V.
Im weiteren Verlauf (ich vermute, dass die 12-V-Batterie voll war) ist die Spannung auf 13,5 V gefallen.
Daher halte ich die 13,3 V, die ich eingestellt habe, für die obere Grenze.

[ChristophR]

Ich habe nun auch Ladevorgänge beobachtet, in denen die Spannung nicht über 13,8V lag, daher kann ich damit nicht arbeiten.
@mattberlin: Du solltest Die Sleep Vorltage lieber auf 13,1V stellen, machmal habe ich beobachtet, dass die Spannung bis 13,2V Volt gefallen ist.
Damit sollte dieses Thema durch sein, danke für Eure Infos.

Es gibt nun Neuigkeiten von MeatPi:
Er hat uns eine Firmware gebaut, in der er auch die Werte, wie sie die openWB (Z.B. für Range) erwartet, direkt schreiben kann.
Normalerweise schreibt er in das Topic ein JSON Ergebnis, für manual_soc brauchen wir das auch so.
Wenn man aber z.B. den Wert Range beschreiben möchte, darf nur der Wert selbst geschrieben werden.
Wenn man das MQTT-Modul nutzen möchte wäre es auch für den SoC so, aber dann fehlt uns die automatische Berechnung, daher wäre das kontraproduktiv.
Range wird auch in den Ladeprotokollen gespeichert, daher wollte ich dies gerne nutzen.
Falls später mal der KM-Stand unterstützt werden sollte, könnten wir den auch wegschreiben.

Die neue Firmware ist hier veröffentlicht, noch nicht in den normalen Downloads:
https://github.com/meatpiHQ/wican-fw/di ... t-10880083

ACHTUNG!
Unbedingt vor dem Firmware Update MQTT deaktivieren. Nachher darf es wieder aktiviert werden. Hatte er mir extra geschrieben, ich habe nicht ausprobiert, ob es trotzdem klappt.

Wenn die Firmware drauf ist, funktioniert nun im Automate Tab auch das Feld Init, so dass ich mehrere Werte abfragen kann.
Außerdem gibt es einen neuen Type: MQTT_Wallbox. Wenn dies ausgewählt wird, wird nur der Wert (s.o.) geschrieben.

Für den Cupra Born sieht es dann so aus, odometer habe ich nur zum Test mit drin:

2024-10-08 21_23_09-WiCAN und 6 weitere Seiten - Persönlich – Microsoft​ Edge.png

(25.46 KiB) Noch nie heruntergeladen

Custom Initialisation:
ATST96;ATFCSD300000;ATFCSM1;

Name	Init	PID	Expression	Period(ms)	Type	Send_to
manual_soc	ATSP7;ATSHFC007B;ATCP17;ATCRA17FE007B;ATFCSH17FC007B;	22028C1	((B4*51)/115)-6.4	60000	MQTT_Topic	openWB/set/vehicle/2/soc_module/calculated_soc_state
range	ATSP6;ATSH710;ATCP18;ATCRA77A;ATFCSH710;	222AB62	(B5*256)+B6	60000	MQTT_WallBox	openWB/set/vehicle/2/get/range
odometer	ATSP7;ATSHFC0076;ATCP17;ATCRA17FE0076;ATFCSH17FC0076;	22295A	[B4:B6]	60000	MQTT_Topic	others/openWB/set/vehicle/2/get/odometer

[mattberlin]

Dann scheint das auf Basis der 3.46er zu sein, die man bereits auf der normalen Seite unter "Tags" beziehen kann.
Ich hoffe, dass es in die normalen Releases mit aufgenommen wird.

Unbedingt vor dem Firmware Update MQTT deaktivieren. Nachher darf es wieder aktiviert werden.

Das checke ich nicht. Das Übermitteln der Daten zur WB läuft doch via MQTT, d.h. MQTT ist zwingend erforderlich?

zur Sleep Voltage:
ok, Danke für den Hinweis, dass es beim Laden auch mal auf 13,2 V gehen kann. Wenn dann tatsächlich die Zündung aus bzw. das Laden beendet ist und somit der DC/DC aus ist, dann würde der WiCAN mit dem Setting 13,1 V etwas später schlafen legen. Aber die Batteriespannung fällt ja dann eh schnell auf unter 13,0 V ab.

[mattberlin]

Wie zu erwarten war, checke ich es wieder nicht.

Im Ladeprotokoll wird nun zwar ein Wert in Range reingeschrieben (früher stand dort "-"). Dieser Wert ist aber 0.

1.jpg

(279.96 KiB) Noch nie heruntergeladen

Das sind meine Einstellungen im MeatPi:

image_2024-10-09_191202212.png

(129.17 KiB) Noch nie heruntergeladen

Zumindest klappt aber des SoC-Schreiben noch


EDIT:
Ich hatte den Testladevorgang nicht lang genug laufen lassen. Nun stehen Anfangs- und Endwerte.

Nun bin ich gespannt, wie die openWB die geladene Reichweite in der Spalte Energie angibt:
Berechnet sie es immer noch auf Basis des Durchschnittsverbrauchs, der in der openWB für das Fahrzeug konfiguriert ist?
Oder nimmt sie die Range-Differenz aus den Spalten SoC Beginn/Ende?

[ChristophR]

Wie zu erwarten war, checke ich es wieder nicht.

Im Ladeprotokoll wird nun zwar ein Wert in Range reingeschrieben (früher stand dort "-"). Dieser Wert ist aber 0.
1.jpg

Das sind meine Einstellungen im MeatPi:
image_2024-10-09_191202212.png

Zumindest klappt aber des SoC-Schreiben noch


EDIT:
Ich hatte den Testladevorgang nicht lang genug laufen lassen. Nun stehen Anfangs- und Endwerte.

Nun bin ich gespannt, wie die openWB die geladene Reichweite in der Spalte Energie angibt:
Berechnet sie es immer noch auf Basis des Durchschnittsverbrauchs, der in der openWB für das Fahrzeug konfiguriert ist?
Oder nimmt sie die Range-Differenz aus den Spalten SoC Beginn/Ende?

Also bei Tronity war es vorher so:
Reichweite Beginn und Reichweite Ende wird aus den Infos von Tronity gefüllt.
Die Spalte Reichweite wird aus dem Durchschnittswert im Fahrzeugprofil ermittelt, ohne Berücksichtigung der Verluste.

[ChristophR]

also den MeatPI WiCAn muss ich auf jeden Fall haben.

Ich verstehe aus dem anderen Thread nicht viel. Aber verstanden habe ich wohl dass es möglöich sein soll den SOC direkt in die Open zu schicken. Das wäre mein Traumziel. Ohne Umweg über HA.

Allerdings bin ich selbst EDV Laie, kann aber auf Unterstützung durch meinen Sohn hoffen.

Muss dazu noch was programmiert werden oder kann man sich irgendwo was herunterladen?
Wie muss die Open eingestellt werden damit die das empfangen kann?

Hallo Focko,

ich antworte mal hier im Thread.

Der Hauptunterschied ist, dass der soc_helper ein Zusatzprogramm ist, welches auf einem bestehenden Gerät im Netz laufen muss. Dieses kleine Programm ruft dann die Werte ab, die Pflege macht zut in dem anderen Thread. Wenn ein neues Auto eingebunden werden muss, muss er dies in dem Programm umsetzen.
Er hat darin auch noch eine Unterstützung für Spritmonitor eingebaut. Wenn Du den auch nutzen möchtest, bist Du dort richtig.

Ich wollte das ganze gerne ohne Zusatzgerät im Netz umgesetzt haben, da ich quasi nur die openWB habe.
Der Hersteller des Dongles hat zu der Zeit eine Änderung in der Firmware umgesetzt, so dass der Dongle ohne weitere Zusatzgeräte die Daten aus dem Auto auslesen und an die openWB senden kann.
Wenn Du also nur den SoC in der openWB haben möchtest, kannst Du hier weiterlesen.

Die restlichen Werte müssen "nur" direkt im Dongle in der Konfiguration eingetragen werden. Wenn das Auto "wach" ist, sendet der Dongle dann automatisch die Daten an die openWB.
Pro Fahrzeugtyp benötigt man bestimmte Werte, damit der Dongle die Daten korrekt auslesen kann.
Das ist einmal ein Initialisierungsstring und dann die sog. PIDs, sowie die Info, wie daraus der benötigte Wert berechnet wird.
Der Hersteller des Dongles ist gerade dabei diese Daten für diverse Fahrzeuge zu sammeln, die Daten werden dort in sog. vehicle-Profilen gespeichert.
Die sind zwar hauptsächlich für HA gedacht, aber daraus kann man die benötigten Infos für "unsere" Lösung auslesen.

Für eine Fiat 500e gibt es dort noch kein Profil, aber der Hersteller hilft bei der Ermittlung der Werte für noch nicht unterstützte Fahrzeuge recht aktiv mit.
Wichtig hierbei ist, dass Dein Fahrzeug von der App Carscanner unterstützt wird, da diese ein Logfile generieren kann, aus der die wichtigsten Daten bereits ermittelt werden können.
Die größte Herausforderung dabei war für mich, dass ich einen Github Account brauchte, da dieser Support über seine Github Seite läuft.
Der Fiat 500e ist von Carscanner unterstützt (ich habe gerade mal nachgeschaut), die Voraussetzungen sind also gut.
Wenn Du dabei Hilfe brauchst, kann ich gerne unterstützen.

Zunächst brauchst Du aber erstmal den Dongle, dann könnte es "losgehen".

War das so verständlich? Sonst einfach fragen.

[zut]

Ich habe den Fiat500 für Focko schon ungetestet im soc_helper drin. Falls die direkte Lösung gefragt ist, bietet es sich an, die id3-Werte zu nehmen und die PID zu ersetzen mit denen vom Fiat500 - wie gesagt, bisher nicht getestet. Hier der Code als Augangsbasis:

Code: Alles auswählen

    SOC_REQ_ID = 0x18DA44F1
    SOC_RESP_ID = 0x18DAF144
    SOC_REQ_DATA = [3, 34, 160, 16, 170, 170, 170, 170]
    ...
    def calcSOC(self, bytes):
        print(f'Daten für SoC-Berechnung:{bytes}')
        logging.debug(f'Daten für SoC-Berechnung:{bytes}')
        displaySoc = min( round(bytes[6]*0.45-6.4), 100 ) # Fiat 500e [0x18DAF144, 98, 160, 16, xx, xx, aa, xx, xx, xx, ...]. SOC ist aa/2.55
   return(displaySoc)
    ...