Stromverbrauch bei Nichtbenutzung

[Pfriemler]

Er hat es wieder getan, mein Roller, und offenbar über ca 3 Tage 8% Strom verbraucht, nach der letzte Fahrt, ohne Laden. Es ist irgendwann in diesen Tagen passiert, es kann auch an einem Tag gewesen sein.
Ich habe es nur beim Check gemerkt. In den darauffolgenden Tagen blieb der SoC festgenagelt auf dem gleichen Wert.
Ich habe da aber eine Idee die ich jetzt verfolge.
Derzeit klemmt am USB-Ausgang ein Smarthomemodul, das mir hilft sekundengenau festzustellen, ob und wie lange die 12V-Versorung aktiv wird. Und zu meiner Überraschung passiert das bei mir seit Beginn der Überwachung jede Nacht, etwa 1:12-1:13 Uhr, für ca 15 Sekunden. In der letzten Nacht hatte ich zudem ein Handy am seriellen Port zum Loggen. Und siehe da:

Code: Alles auswählen

01:12:42.421 Received 75 bytes from report socket
01:12:42.421 [00-39]: $FIND,0,0,1,5,1$FIND,0,0,1,5,1$FIND,0,0,
01:12:42.434 writing 50 bytes to socket 0
01:12:42.465 S01 FIND INITIATE: act-flags 0, loc-flags 0, pre-pwr 1, duration 5s, post-pwr 1

Es wird also über Telemetrie ein Kommando empfangen, was den Roller (teilweise) einschaltet.
Die ersten beiden gleichen $FIND-Kommandos (Link zum Telemetriethread füge ich später nach) aktivieren die Batterie und lässt sie im aktiven Zustand. Das dritte schaltet sie wieder aus. Wenn das fehlschlägt, bleibt die Batterie vielleicht den ganzen Tag eingeschaltet, was den Verbrauch erklären könnte. Und warum das so sporadisch passiert und schlecht zu tracken ist.

@Gerold, hast Du ähnliches in Deinen Logs?

edit 22.2.: Diese Nacht blieb die Batterie wieder aktiv, die AUS-Meldung meiner Mimik kam nicht. Ist das so ein Freitagnachtding? Habe über die Mo-App schlicht den Ausschaltbefehl gesendet - und prompt kam die AUS-Meldung
In 6h nur 2% verloren.

[Gerold]

Das $FIND muss ja vom Silence Server kommen. Mein Astra Modul hat aber keine Verbindung mehr zum Server und empfängt von Ihm auch keine Meldungen mehr. So findet ich auch in den Reports, die das Modul sendet, keine Hinweise, dass ein $FIND empfangen worden ist. Dies würde bei mir ein Versenden eines Reports mit Reason "Scutum Event auslösen, wobei in den Reportdaten die Stromstärke mit etwa 0.3 A ausgewiesen wird.

edit 22.02: Ich würde an Deiner Stelle testweise $IPAD1 auf irgendeine Fake Adresse setzen und beobachten, ob der Spuk damit aufhört. Falls dem so ist, muss man , wenn man den Stromverlust vermeiden will, eine andere Nutzung des Moduls in Betracht ziehen. Alternativen sind ja zum Glück vorhanden.

[Pfriemler]

Mit der These "sporadischen Nichtabschaltung nach täglicher nächtlicher Aktivierung" habe ich die bei Spritmonitor notierten gelegentlich hohen Standbyverluste nochmal zusammengetragen. Wenn es sich um das gleiche Fehlerbild handelt, dann ist es beginnend mit dem 17.05.24 bis heute mutmaßlich 13x aufgetreten, 8x in ganz 2024 und 5x in diesem Jahr, im Schnitt alle 22 Tage.

... Ich würde an Deiner Stelle testweise $IPAD1 auf irgendeine Fake Adresse setzen ...

Genau das war meine Überlegung auch schon. Ich hoffe aber zunächst erst einmal, eine fehlerhafte nächtliche Sequenz loggen zu können, um zu sehen, ob der Befehl schon falsch ankommt oder nur falsch abgearbeitet wird.

[error]

Zur allgemeinen Belustigung: ich wollte gestern abend meine Silence nach 2 Monaten beheiztem Kelleraufenthalt "ausmotten". Zündung an, Tacho zeigt 39%, draufgesetzt, Ready, versuche zu rangieren, Karre aus. - Schlüsselreset, Tacho zeigt 0%, Akku leuchtet nach ein paar Versuchen rot.

Akku raus, 15% eingeladen, Spuk vorbei. Jetzt hängt sie erst mal seit gestern nacht am Netz. Hatte leider das Handy mit Gerolds App nicht dabei. Sonst hätte ich Zellspannungen liefern können. Das will ich gleich mal nachholen.

edit: zumindest hat der Akku überlebt. Die Zellen liegen bei 100% geladen aktuell zwischen 4,084V u. 4,088V. Für 15.000 km Laufleistung wohl ein guter Wert. Dann soll mir das egal sein.

[Pfriemler]

Mit so einem "abgestandenen" Akku bin ich ja auch schon mal fast gestrandet. Das hat aber mit meinem Problem nichts zu tun, sondern ist eine andere Baustelle.

Ich bin gerade noch am Sammeln weiterer Logs, aber so wie es aussieht, habe ich da in der ersten Version eine Lücke im Log. Gewundert habe ich mich nämlich über insgesamt 5x "$FIND,OK" im Log, obwohl ich nur 3 $FIND-Kommandos gesehen habe. Tatsächlich ist die auf "$FIND,0,0" endende Befehlszeile unvollständig. In den beiden folgenden Aufzeichnungen werden insgesamt 5 identische "$FIND,0,0,1,5,1"-Kommandos empfangen. Diese kamen bisher im 1x, 1x, 3x-Paket. Da neue Kommandos kommen, während die ersten noch nicht abgearbeitet sind, geht da möglicherweise ab und zu etwas durcheinander.
Den 5 FIND-Kommandos folgen dabei nur drei "FIND INITIATE"- es taucht nach dem letzten Dreifachkommando nur 1x auf. In den ersten beiden Logs folgen dem 3x "DIG-OUT 5 ON" bzw. "...OFF", also die zum Zündschloss parallel am Astramodul angeschlossene Leitung ein- und nach einer Sekunde wieder ausgeschaltet. Soweit so gut.
Im Log der letzten Nacht gibt es hingegen 5x "on-off". Und das ist nicht alles.

Auffällig finde ich, dass der Roller neben den bekannten Stati von 0(aus) bis 6(Charging) auch den Status 10 kennt, der der Reihenfolge im Log nach immer dann eingenommen wird, wenn ein Schaltbefehl an das BMS gesendet wurde. (Das findet man auch bei singulären $PBAT- oder $PWON-Kommandos.) Nach meinem Verständnis taucht diese Meldung im Log immer dann auf, wenn das Akku-BMS einen geänderten Status meldet. Regelmäßig taucht dabei auch ein "S01 attempt [x] PBAT1 Failed, bike status = 10"-Fehler auf, wobei [x] bis 4 zu sehen ist. Das Kommando "PBAT" taucht dabei hier sonst nirgends auf, möglicherweise handelt sich um eine interne Teilübersetzung des $FIND, wofür ja die Aktivierung des Akkus nötig ist.
Der 5. Versuch geht aber nicht über "Status 10" (siehe folgenden Absatz) . Und nach dem letzten "off" bleibt der Akku an!

Nachfolgend alle Treffer im letzten Log gefiltert nach "DIG-OUT", "PBAT", "$FIND" und "S01 STATUS CHANGED". Man sieht dass da eine ganze Menge durcheinanderläuft. Am Ende ist zwar die Zündungsleitung aus (DIG-OUT 5 OFF), aber der Status des Rollers wechselt - seltsam und untypisch nicht über 10, sondern direkt von 0 zu 1 - und bleibt dort, d.h. der Akku blieb wieder in Betrieb.
DIe letzte Zeile mit dem Statuswechsel kam Stunden später nach dem Senden des Ausschaltbefehls mit der App. Solange war der Akku aktiv, alle bis dahin gesendeten Protocol-X-Reports (alle 10min) wiesen den Status "1(BMS)" aus. Der Akku hat wiederum 2% SoC eingebüßt in der Zeit.

Zeile 4328: 01:14:08.133 [00-14]: $FIND,0,0,1,5,1
Zeile 4330: 01:14:08.133 S01 FIND INITIATE: act-flags 0, loc-flags 0, pre-pwr 1, duration 5s, post-pwr 1
Zeile 4337: 01:14:08.289 DIG-OUT 5 ON
Zeile 4345: 01:14:08.649 S01 STATUS CHANGED TO: 10
Zeile 4347: 01:14:08.655 S01 attempt 0 PBAT1 Failed, bike status = 10
Zeile 4375: 01:14:08.927 $FIND,OK
Zeile 4388: 01:14:08.968 S01 STATUS CHANGED TO: 1
Zeile 4396: 01:14:08.999 [00-14]: $FIND,0,0,1,5,1
Zeile 4398: 01:14:09.028 S01 FIND INITIATE: act-flags 0, loc-flags 0, pre-pwr 1, duration 5s, post-pwr 1
Zeile 4436: 01:14:09.304 DIG-OUT 5 OFF
Zeile 4448: 01:14:09.764 $FIND,OK
Zeile 4509: 01:14:10.486 S01 STATUS CHANGED TO: 10
Zeile 4528: 01:14:10.675 S01 STATUS CHANGED TO: 0
Zeile 4570: 01:14:11.089 [00-39]: $FIND,0,0,1,5,1$FIND,0,0,1,5,1$FIND,0,0, .... [40-44]1,5,1
Zeile 4573: 01:14:11.128 S01 FIND INITIATE: act-flags 0, loc-flags 0, pre-pwr 1, duration 5s, post-pwr 1
Zeile 4580: 01:14:11.338 DIG-OUT 5 ON
Zeile 4596: 01:14:11.688 S01 STATUS CHANGED TO: 10
Zeile 4597: 01:14:11.688 S01 attempt 1 PBAT1 Failed, bike status = 10
Zeile 4620: 01:14:11.940 $FIND,OK
Zeile 4621: 01:14:11.940 $FIND,OK
Zeile 4622: 01:14:11.940 $FIND,OK
Zeile 4634: 01:14:11.988 S01 STATUS CHANGED TO: 1
Zeile 4684: 01:14:12.379 DIG-OUT 5 OFF
Zeile 4762: 01:14:13.458 S01 STATUS CHANGED TO: 10
Zeile 4785: 01:14:13.661 S01 STATUS CHANGED TO: 0
Zeile 4884: 01:14:14.881 DIG-OUT 5 ON
Zeile 4892: 01:14:14.964 S01 STATUS CHANGED TO: 10
Zeile 4893: 01:14:14.969 S01 attempt 2 PBAT1 Failed, bike status = 10
Zeile 4944: 01:14:15.888 DIG-OUT 5 OFF
Zeile 5004: 01:14:16.967 S01 STATUS CHANGED TO: 0
Zeile 5104: 01:14:18.228 DIG-OUT 5 ON
Zeile 5119: 01:14:18.768 S01 STATUS CHANGED TO: 10
Zeile 5120: 01:14:18.768 S01 attempt 3 PBAT1 Failed, bike status = 10
Zeile 5161: 01:14:19.088 S01 STATUS CHANGED TO: 1
Zeile 5200: 01:14:19.433 DIG-OUT 5 OFF
Zeile 5269: 01:14:20.557 S01 STATUS CHANGED TO: 10
Zeile 5288: 01:14:20.758 S01 STATUS CHANGED TO: 0
Zeile 5387: 01:14:21.976 DIG-OUT 5 ON
Zeile 5405: 01:14:22.825 S01 STATUS CHANGED TO: 1
Zeile 5413: 01:14:22.852 S01 PBAT1 SUCCESS!
Zeile 5426: 01:14:22.978 DIG-OUT 5 OFF
.
.
.
Zeile 522310: 07:59:29.830 S01 STATUS CHANGED TO: 0

Nachtrag: Die Befehlszeile für FIND lautet übersetzt: keine Aktoren (SItz,Batterie-/Lenkerblock (S01 hat nur Sitz), keine "Locatoren" (Blinker, Standlicht, Bremslicht, Tagfahrlicht, Piepser, Hupe, Abblend-, Fernlicht), Roller einschalten, 5 Sekunden (warten), Roller ausschalten.
Anfrage an SEAT ist unterwegs, schauen wir mal ob das was bringt.

[Pfriemler]

Also das Problem wird langsam übel. Bezogen auf das erste Auftreten Ende Januar, habe ich jetzt im Schnitt alle 4 Tage ein "Hängenbleiben", so auch heute Nacht wieder (leider nicht geloggt). Ich mache mal eine Anfrage im Telemetriethread für einen Vergleich.

edit: bitte nicht untergehen lassen, ich brauche mal Vergleichsdaten
edit2: Das Astra speichert die Befehle ja ggf. im Puffer, wenn es mit der Abarbeitung nicht klar kommt. Die ankommenden 5 Befehle werden in unterschiedlichen Häppchen empfangen, hier im Bspl. des "Hängenbleibers"

Zeile 4319: 01:14:07.969 [+UUSORD: 1,15] (1x)
Zeile 4334: 01:14:08.219 [+UUSORD: 1,15] (1x, +0,25s)
Zeile 4408: 01:14:09.099 [+UUSORD: 1,45] (1x) +0,88s)

kommt das Befehlstriple mit einer Verzögerung von fast einer Sekunde nach den ersten beiden.
Auch heute nacht gab es wieder 5 Befehle und wie fast brav 5 Digitalleitungs-Ein/Ausschaltungen (jeweils für eine Sekunde) und eine saubere Abfolge, die Befehle wurden diesmal als 1x, 2x (nach 0,25s) und 2x (wiederum nach knapp 0,9s) angezeigt.

[Pfriemler]

Die Häufigkeit der Hängenbleiber bei $FIND steigert sich dramatisch, der Schnitt der letzten Woche ist "jeder 2. Tag".

Gerade nochmal ein paar Versuche mit $FIND gemacht. Zu meiner großen Überraschung ist es ziemlich egal, ob man dem Ding 1x odert 5x am Stück den Befehl schickt - die Abarbeitungssequenz ist nahezu ähnlich. Auch mit nur 1x "$FIND,0,0,1,5,1" bekomme ich im besten Fall 5x DIG-OUT 5 ON und ...OFF für jeweils eine Sekunde. Im besten Fall heißt: Der Roller ist hinterher aus. Bei 2 von 3 Versuchen blieb er an. Beim Senden von 5x $FIND... am Stück waren es diesmal nur 4x und der Roller blieb an, und das finde ich auch in älteren Logs, d.h.:
--> Immer, wenn es weniger als 5x waren, blieb der Roller hängen.

btw: DIG-OUT ON / OFF ist dabei nicht unbedingt eine "Ein-Aus"-Schaltung wie über das Zündschloss. Die bleibt bei PWON,1 nämlich genauso für nur eine Sekunde an (eine Frage, die ich mir schon immer gestellt hatte), aber der Roller geht danach nicht aus, offenbar schickt das ASTRA ein paar Befehle im Gegensatz zum Zündschloss, so dass der Roller an bleibt.
Bei $PWON,0 zuckt sich DIG-OUT nicht mehr, im Log erscheint leider nicht welcher Befehl gesendet wird.

[motoqtreiber]

Über den Winter kommen 2 Probleme zusammen: Der Akku entlädt sich ständig und die Akkuanzeige stimmt nicht.
Ich hatte öfter kontrolliert und Akkuanzeige ok. Dann war der Roller plötzlich tot, Akku komplett leer. Die Anzeige war also die ganze Zeit falsch. Tiefentladung! Was sehr schädlich ist!

Dann geladen und Akku zeigte konstant 100% an, egal wie weit man fährt.

Diese Selbstentladung gibt es sonst nur bei Tesla.
Mein ID3, ID4 und Fiat 500e verlieren genau NIX beim Rumstehen.

[conny-r]

Mein DTR Schrott Akku 20 Ah in 10 Tagen 0,2-0,3 V Ein Traumwert

Mein 35 Ah in 3 Mon nicht mal 1 Volt.

[patba]

Dann geladen und Akku zeigte konstant 100% an, egal wie weit man fährt.

Wie, verstehe ich das richtig, Du bist mit 100% losgefahren, und trotz längerer Strecke ging die Anzeige nicht zurück? Das wäre mal was neues, das hat glaube ich noch niemand gehabt. Außer bei Versuchen, den Akku mit selbst gebauten Ladegeräten übervoll zu laden, und da auch nur auf den ersten paar km.

Was aber natürlich so ist: Die SOC-Anzeige erkennt die Selbstentladung/Standby-Verbräuche nicht. D.h. die Anzeige zeigt dann zu viel an. Beim Laden zählt die Anzeige einfach per coulomb-counting hof und bleibt dann bei 100% stehen, obwohl der Akku noch nicht voll ist, und ein Strommessgerät auch nach wie vor den Ladevorgang anzeigt. Man kann nicht oft genug wiederholen, die SOC-Anzeige ist nur richtig kalibriert, wenn der Akku vorher randvoll geladen wurde, was man entweder mit einem Verbrauchs-Messgerät kontrolliert, oder indem man den Akku mind. 9-10h angesteckt lässt, auch wenn die Anzeige schon längst 100% anzeigt.
Es gibt übrigens neuere Firmware (im BMS?), die in diesem Zustand nur 99% anzeigen. Die 100% werden dann ausschließlich angezeigt, wenn der Ladevorgang wirklich abgeschlossen ist.