EVNotiPi
Re: EVNotiPi
Das Auto bleibt wach und leert somit die 12V Batterie. Wenn es einschläft ist auch keine Abfrage mehr möglich, zumindest war bei meinem Versuch nach einer Stunde der BT Dongle nicht mehr erreichbar. Das Verhalten kann natürlich je nach Softwarestand unterschiedlich sein. Den raspberry jedes Mal hart abschalten ist auch keine Dauerlösung.
Das ganze ist wenig befriedigend, die Dongle Lösung leert die 12V Batterie oder ist nicht mehr erreichbar, die Node Red Lösung ist zwar top, dafür ist man wieder von Hyundai und dem Entwickler von Bluelinky abhängig.
Das ganze ist wenig befriedigend, die Dongle Lösung leert die 12V Batterie oder ist nicht mehr erreichbar, die Node Red Lösung ist zwar top, dafür ist man wieder von Hyundai und dem Entwickler von Bluelinky abhängig.
-
- Beiträge: 1553
- Registriert: Sa Nov 10, 2018 6:59 am
- Wohnort: Leverkusen
- Has thanked: 3 times
- Been thanked: 4 times
Re: EVNotiPi
Ja absolut richtigSteppl hat geschrieben: ↑Mo Apr 05, 2021 9:38 am Das Auto bleibt wach und leert somit die 12V Batterie. Wenn es einschläft ist auch keine Abfrage mehr möglich, zumindest war bei meinem Versuch nach einer Stunde der BT Dongle nicht mehr erreichbar. Das Verhalten kann natürlich je nach Softwarestand unterschiedlich sein. Den raspberry jedes Mal hart abschalten ist auch keine Dauerlösung.
Das ganze ist wenig befriedigend, die Dongle Lösung leert die 12V Batterie oder ist nicht mehr erreichbar, die Node Red Lösung ist zwar top, dafür ist man wieder von Hyundai und dem Entwickler von Bluelinky abhängig.
Hier läuft einer der ersten EVNotiPi PnP Prototypen immernoch. Und wird auch noch ne Weile.
aber mittlerweile ist für mich das ganze Thema ein Kaufkriterium (bzw. Nichtkaufkriterium) geworden für den Kona Nachfolger. Wenn Hyundai da nicht massiv nachbessert, kommt aus dem Haus definitiv nix mehr.
Aktuelles Setup:
openWB 2.x
2x openWB pro
PV:
SolarEdge SE9K mit SolarLog 380Mod am EVU Punkt (nur noch fürs SE Portal genutzt)
2x MPPT 150/35 mit jeweils 1,2kWp
Speicher:
3x Multiplus 2 5000
Cerbo GX
EM540 (am Cerbo)
28,6kWh DIY Speicher
Re: EVNotiPi
Na, da ist zumindest aktuell der neue Ioniq V für mich zu verlockend.Wenn Hyundai da nicht massiv nachbessert, kommt aus dem Haus definitiv nix mehr.
Jörg
PV 5,2 kWp, Kostal Plenticore 8.5, BYD HVS 7.7, KSEM, OpenWB Standard+ 2.1.3, Homeassistant mit zahlreichen WLAN (Tasmota-flashed), Zigbee, Bluetooth & DECT Devices, Volvo XC40 Recharge Single Extended Range MJ24
-
- Beiträge: 1553
- Registriert: Sa Nov 10, 2018 6:59 am
- Wohnort: Leverkusen
- Has thanked: 3 times
- Been thanked: 4 times
Re: EVNotiPi
Ja der gefällt mir auch, was aber Hyundai an Software abliefert ist irgendwie kacke. Dazu die gefühlten 3 Duzend Rückrufe beim Kona....
Na da muss sich noch einiges tun. Ansonsten wird das nächste eher nen Model 3 oder Y
Aktuelles Setup:
openWB 2.x
2x openWB pro
PV:
SolarEdge SE9K mit SolarLog 380Mod am EVU Punkt (nur noch fürs SE Portal genutzt)
2x MPPT 150/35 mit jeweils 1,2kWp
Speicher:
3x Multiplus 2 5000
Cerbo GX
EM540 (am Cerbo)
28,6kWh DIY Speicher
Re: EVNotiPi
Beim Kona schlafen die Steuergeräte reproduzierbar ca. 2 Minuten nach dem STOP des Ladens ein. Über OBD2 werden dann keine Daten mehr geliefert. Sobald das Laden wieder gestartet wird, wachen die Steuergeräte für BMS und CLU wieder auf. Das ständige Abfragen kann also nach meinem Verständnis die Batterie nicht leer sagen (der Dongle selbst natürlich auch nicht). Bleibt Deine These, dass die Steuergeräte sich auf dem CAN-BUS oder in Ihrer Buggy-SW verhaken. Dafür habe ich nun testweise mal für KONA alle Abfragen des CLU sowie aller überflüssigen PIDs für evSoc aus den Quellen von evnotipi auskommentiert.Jarry hat geschrieben: ↑Mo Apr 05, 2021 9:25 am Der Dongle selber wird es "NIE" schaffen die 12V Batterie zu leeren.
Das was passiert ist etwas ganz anderes. Wenn im falschen Moment ein "falsches" Signal auf dem Bus unterwegs ist, verhindert das einfach, dass Steuergeräte einschlafen. Bzw. beim ständigen abfragen schlafen die halt auch nicht ein. Da reden wir dann von Leistungen >100W. Die saugen dann die Batterie leer.
Nun hoffe ich, dass damit der Traffic auf dem CAN-Bus ausreichend minimiert wäre oder der Übeltäter der CLU-Controller wäre. Mal sehen, was passiert. Noch ist meine 24-Monate Garantie auf die 12V-Batt. nicht abgelaufen, und nach inzwischen 4 Tiefentladungen ist das gute Stück für mich erledigt. Das will ich mal ausnutzen. Vielleicht hilft die Mobilitätsgarantie ja, dass Hyundai aufwacht, falls die ECUs nicht einschlafen wollen ...
Zuletzt geändert von ragnaroek am Do Apr 08, 2021 12:24 pm, insgesamt 1-mal geändert.
Kona(2018)/Plenticore 8.5/BYD-H/KSME/KVSE-DIN/SDM630/evSoc
Re: EVNotiPi
gelöscht
Zuletzt geändert von ragnaroek am Do Apr 08, 2021 12:25 pm, insgesamt 2-mal geändert.
Kona(2018)/Plenticore 8.5/BYD-H/KSME/KVSE-DIN/SDM630/evSoc
-
- Beiträge: 693
- Registriert: Do Feb 20, 2020 1:16 pm
- Has thanked: 2 times
- Been thanked: 9 times
Re: EVNotiPi
Also es muss schon irgendeine "seltsame" Konstellation sein, die zu der Entladung der 12V Batterie führt.
Bei mir ist das vor Einsatz von evSOC noch nie passiert. Wir haben jahrelang am "Ladeverhalten" selbst nix geändert. Also Auto wurde immer angeschlossen und hing auch nach Vollladung meist noch sehr lange (in der Regel mind. über Nacht) am Ladekabel.
Dann hab ich angefangen mit evNotify zu spielen und seitdem war auch der Dongle quasi dauerhaft im Auto verbaut, auch da gab es keine Probleme.
Auch derzeit ist der Dongle dauerhaft im Fahrzeug und es gibt keine Probleme. Aber auch beim letzten Mal wieder wo ich geladen habe war danach die 12V Batterie leer.
Werde beim nächsten Mal versuchen zu laden aber dabei den RPi mit evSOC vom Strom trennen, damit der Dongle nicht abgefragt wird. Bin gespannt was dann passiert...
Die Frage ist natürlich, ob das Problem beim Ioniq (in meinem Fall vFL) und dem Kona wirklich das gleiche ist. Auch haben beim Ioniq ja ganz viele Leute dieses Problem und auch viele, die evSOC nicht nutzen. Von daher kann es definitiv nicht allein daran liegen.
Auch gab es ja schon Fälle/Vermutungen, dass die Wallbox das Fahrzeug "wach" hält. Da frage ich mich, ob sich die openWB anders verhält, wenn bei "Ladebegrenzung" statt "Keine" oder "Energiemenge" eben "EV-SOC" eingestellt ist. Denn mit den anderen beiden Lademodi hatte ich eben keine Probleme...
Bei mir ist das vor Einsatz von evSOC noch nie passiert. Wir haben jahrelang am "Ladeverhalten" selbst nix geändert. Also Auto wurde immer angeschlossen und hing auch nach Vollladung meist noch sehr lange (in der Regel mind. über Nacht) am Ladekabel.
Dann hab ich angefangen mit evNotify zu spielen und seitdem war auch der Dongle quasi dauerhaft im Auto verbaut, auch da gab es keine Probleme.
Auch derzeit ist der Dongle dauerhaft im Fahrzeug und es gibt keine Probleme. Aber auch beim letzten Mal wieder wo ich geladen habe war danach die 12V Batterie leer.
Werde beim nächsten Mal versuchen zu laden aber dabei den RPi mit evSOC vom Strom trennen, damit der Dongle nicht abgefragt wird. Bin gespannt was dann passiert...
Die Frage ist natürlich, ob das Problem beim Ioniq (in meinem Fall vFL) und dem Kona wirklich das gleiche ist. Auch haben beim Ioniq ja ganz viele Leute dieses Problem und auch viele, die evSOC nicht nutzen. Von daher kann es definitiv nicht allein daran liegen.
Auch gab es ja schon Fälle/Vermutungen, dass die Wallbox das Fahrzeug "wach" hält. Da frage ich mich, ob sich die openWB anders verhält, wenn bei "Ladebegrenzung" statt "Keine" oder "Energiemenge" eben "EV-SOC" eingestellt ist. Denn mit den anderen beiden Lademodi hatte ich eben keine Probleme...
Gruß,
Jürgen
Jürgen
Re: EVNotiPi
Die Tests mit der korrigierten Kona-Bluetooth evSoc Version waren leider negativ. Gestern Abend geladen. Nachts ohne Kabel. Heute 12V-Batterie leer.
Amperemeter an die 12V-Batt angeschlossen. Messergebnisse:
0,028A Ruhezustand Kona (alles Aus, Motorhaube zu, Ladeklappe zu, kein BT-Dongle gesteckt, bluetooth.service stopped, evSoc.service stopped)
0,050A Bluetooth-Dongle eingesteckt
1,8A Ladeklappe auf
0,5A ca. 10sek später, bleibt dauerhaft so hoch
1,8A Ladeklappe zu
0,5A ca 10sek später
0,05A ca 1min später
1,8A bluetooth.service started, evSoc.service weiter stopped! Stromaufnahme bleibt dauerhaft so hoch
0,5A ca 10sek nach bluetooth,service stopped
0,05A ca 1min später
Ergo: Zunächst erklärt die 1,8A Stromaufnahme das Entleeren der Batterie ausreichend gut. Ich sehe zunächst keinen Grund mehr, hier über schlechte Hyundai-Software zu spekulieren.
Weiter halte ich 50mA Standby Stromaufnahme bei gestecktem unbenutzten BT-Dongle für akzeptabel, um damit den Kona für "längere" Zeit abzustellen. Aber man müsste beobachten, ob der AusDerHochvoltBatterieNachladen-Algorithmus von Hyundai damit dauerhaft klarkommt.
Damit eröffnet sich prinzipiell der Weg, den bluetooth.service (oder das rfcomm bind xx:xx:xx:xx:xx) nur dann zu starten, wenn der SoC tatsächlich gewünscht wird:
Fall Laden: Ladestecker steckt UND es wird tatsächlich geladen (also Nachts bei PV-Laden lieber keinen SoC abfragen)
Fall Ankommen: Auto kommt in die Nähe der Wallbox. SoC wird übertragen. Danach wird bluetooth.service deaktiviert für z.B. 1 Stunde
Amperemeter an die 12V-Batt angeschlossen. Messergebnisse:
0,028A Ruhezustand Kona (alles Aus, Motorhaube zu, Ladeklappe zu, kein BT-Dongle gesteckt, bluetooth.service stopped, evSoc.service stopped)
0,050A Bluetooth-Dongle eingesteckt
1,8A Ladeklappe auf
0,5A ca. 10sek später, bleibt dauerhaft so hoch
1,8A Ladeklappe zu
0,5A ca 10sek später
0,05A ca 1min später
1,8A bluetooth.service started, evSoc.service weiter stopped! Stromaufnahme bleibt dauerhaft so hoch
0,5A ca 10sek nach bluetooth,service stopped
0,05A ca 1min später
Ergo: Zunächst erklärt die 1,8A Stromaufnahme das Entleeren der Batterie ausreichend gut. Ich sehe zunächst keinen Grund mehr, hier über schlechte Hyundai-Software zu spekulieren.
Weiter halte ich 50mA Standby Stromaufnahme bei gestecktem unbenutzten BT-Dongle für akzeptabel, um damit den Kona für "längere" Zeit abzustellen. Aber man müsste beobachten, ob der AusDerHochvoltBatterieNachladen-Algorithmus von Hyundai damit dauerhaft klarkommt.
Damit eröffnet sich prinzipiell der Weg, den bluetooth.service (oder das rfcomm bind xx:xx:xx:xx:xx) nur dann zu starten, wenn der SoC tatsächlich gewünscht wird:
Fall Laden: Ladestecker steckt UND es wird tatsächlich geladen (also Nachts bei PV-Laden lieber keinen SoC abfragen)
Fall Ankommen: Auto kommt in die Nähe der Wallbox. SoC wird übertragen. Danach wird bluetooth.service deaktiviert für z.B. 1 Stunde
Kona(2018)/Plenticore 8.5/BYD-H/KSME/KVSE-DIN/SDM630/evSoc
Re: EVNotiPi
Irgendwas an der Software des Kona is verbuggt. Auch die Einschlafthematik bei verzögertem Ladestart ist so eine Sache, tagelang funktioniert das einwandfrei und auf einmal nicht mehr. Schade, eigentlich ein gutes zuverlässiges Auto, aber solche Sachen nerven tierisch. Man es sich nur unter dem Aspekt schön reden das es solche Probleme auch bei anderen Herstellern gibt, siehe die Einschlafproblematik beim Model 3.
Re: EVNotiPi
Das mit der Messung finde ich eine gute Idee. Mal schauen, ob ich das auch hinbekomme.
Man sollte aber auch berücksichtigen, dass wohl ein gepairtes Handy in der Nähe das selbe Phänomen auslöst, wie EvNotiPi.
Das könnte die Probleme der anderen Leute erklären, die bei gestecktem Dongle eine leere Batterie hatten.
Man sollte aber auch berücksichtigen, dass wohl ein gepairtes Handy in der Nähe das selbe Phänomen auslöst, wie EvNotiPi.
Das könnte die Probleme der anderen Leute erklären, die bei gestecktem Dongle eine leere Batterie hatten.