Beiträge von smartuser

    Mich hat auch das Thema Degradation interessiert und dafür einerseits den Carscanner genutzt beim Vorgänger, da kamen aber regelmäßig komische Werte oder ich habe falsch abgelesen. Also habe ich, es war ein Audi, die Fahrt so gemacht, wie es mir ein werksnaher Ansprechpartner empfohlen hat. Warmes Wetter, um die 25 Grad, Auto voll auf 100% geladen per AC und dann bis auf einen einstelligen SoC Wert runtergefahren bei sehr gleichmäßigem Tempo zwischen 80 und 100km/h. Am Ende das Auto voll aufladen und dann hat man zwei Werte, Reichweite mit Verbrauchswert im Auto und die geladene Energie incl. Ladeverluste. Das habe ich einmal im Jahr gemacht und konnte so für mich sehen, nach ca. 115.000 km hatte der Akku 10% Degradation. Sehr viel DC-Ladevorgänge, über 50%, sehr viel Ladevorgänge bis 100%. Dafür finde ich die Degradation in Ordnung. Ich habe sie am Ende der Laufzeit des Fahrzeugs im Winter bemerkt, da es ein Auto mit einer WLTP-Reichweite von nur knapp über 400km war und dementsprechend im Winter deutlich unter 300 Autobahnkilometer möglich waren. Da dann noch 10% weniger und aus Langstrecken werden sehr lange Strecken :)

    Werte in dieser Größenordnung hätte ich auch erwartet. Wenn man dann noch berücksichtigt, dass mehr als 50 % DC-Ladeanteil war (das stresst den Akku mehr als AC-Laden) würde ich bei einem BEV, das überwiegend an der eigenen WEB geladen wird, eine Degradation erwarten, die noch niedriger liegt. Aber wie gesagt, schädlicher sind eigentlich lange Standzeiten mit vollem Akku bei hohen Temperaturen.

    Aus der Sorge vor Akku Degratation.

    Wenn du eine längere Statistik hast kannst du Veränderungen in Reichweite oder zugeführter Energie erkennen.

    Bei meinem früheren Ioniq nahm die Reichweite nach 1,5 Jahren signifikant ab. Gut an den Zahlen zu erkennen.

    Wir fahren jetzt seit mehreren Jahren nur noch elektrisch. Probleme mit abfallender Kapazität des Akkus hatten wir bislang nie. Hoffentlich bleibt das auch so. Denke aber, dass die Stabilität der Batterien heute so gut ist, dass die Batterie vermutlich länger lebt als das Auto. Von den seit 2013 zugelassenen BMW i3 fahren z.B. mehr als 90 % noch mit der ersten Batterie.

    Was dem Akku am meisten schadet, ist ständiges Laden auf 100 % kombiniert mit langen Stillstandszeiten nach dem Aufladen bei hohen Temperaturen. Das liegt an der Zellchemie. Aber selbst das dürfte weit weniger kritisch sein als oft beschrieben. Also nicht vollladen, wenn das Auto hinterher länger in der prallen Sonne stillsteht.


    Die geladenen kW gibt die Ford-Software leider nicht aus. Man kann mit der Integration in Home Assistant den SOC und den Kilometerstand auslesen und sich daraus selbst eine Statistik basteln, die einen Anhaltspunkt liefern kann. Da ich selbst aber zu 98% an der eigenen Wallbox lade, könnte ich mir die Statistik auch darüber ziehen. Sehe aber aktuell den Bedarf dafür nicht wirklich.

    Für statistische Zwecke würde ich den Aufwand nicht betreiben. Mein Anliegen ist effizient mit PV-Überschuss zu laden. Das mache ich mit EVCC als Add-on in Homeassistant. Wenn EVCC den aktuellen SOC bekommt , wird die Planung des Ladevorgangs besser (weil dann ja EVCC den benötigten Restbedarf berechnen kann). Momentan zeigt mir EVCC einfach die hochgerechnete Restladezeit bis zu 100 % auf der Basis des aktuellen Ladestroms an. Das ist eine sinnfreie Aussage, weil ich keinerlei Information habe, wie der aktuelle SOC ist. Da muss ich dann jedesmal in die FORD App, das ist einfach lästig.

    Passend zum Them habe ich gerade bei heise diesen Beitrag gesehen. Könne eine Lösung sein, ohne das man einen dritten benötigt.


    Daten für HomeAssistant

    Danke für die Info. Wenn ich es richtig sehe, muss ich dafür aber dem Anbieter der Torque-App meine Zugangsdaten zum Fernzugang meines Home Assistant geben (sonst funktioniert die Datenübertragung wohl nicht.. Da bin ich dann eher zurückhaltend, denn ich steuere weite Teile unseres Hauses mit Home Assistant. Und schaue schon, wer Zugriff erhält.

    So rein von Datenschutz und IT-Sicherheit her macht das ja wohl auch Sinn, dass ein beliebiger Developer keinen Zugriff auf meine VIN bekommt. Wäre natürlich cool, wenn man das dann doch irgendwie mit einer zusätzlichen "Genehmigungsebene" hinbekäme. Irgendwie sowas wie der Hauptbenutzer bei VW, der auch nur beim Händler freigeschaltet werden kann.

    Der Sicherheitsüberlegng stimme ich grundsätzlich zu. Im konkreten Fall ist das aber im Prinzip realisiert, denn wenn ich einen zweiten Account in Ford Pass für das gleiche Auto einrichte, geht das nur über ene Einladung durch den Hauptnutzer, die der Eingeladene auch annnehmen muss. Dazu erhält der neue Nutzer eine mail an das angegebene e-mail Konto. Der Hauptnutzer muss also aktiv den neuen Nutzer autorisieren. Ford blockiert hier, nach dem was man so lesen kann, primör weil der API-Server wohl von vergleichbarer Qualität wie die App ist. Oder es gibt Pläne wie vermutlich bei BMW (dort wird der API-Zugriff seit September 2025 auch blockiert), das Angebot irgendwann kostenpflichtig zu machen. So kann man zumindest eine e-mail verstehen, die ich von BMW auf meine Frage erhalten habe, warum der API-Zugang blockiert wird. Vorgeschoben wurden Sicherheitsgründe (die unser Sohn, der IT Security beruflich macht, für grotesk hält) aber dann kam der Hinweis, dass es mit Partnern von BMW über entsprechende kostenpflichtige Lösungen weiter geht...

    Das klingt logisch mit der VIN, ich hatte bisher noch keine Probleme das der Account gesperrt wird . Bzgl. evcc gibt‘s ein Cache timeout.IMG_2826.jpg

    Vielen Dank für den Hinweis. EVCC setzt wohl die Polling Rate standardmäßig auf 15 min (habe gerade einmal nachgesehen), während die Home Assistant Integration die Daten derzeit alle 60s abruft, wen ich dei Information auf Github richtig interpretiere. Der Entwickler arbeitet wohl daran, die Einstellung über die graphische Oberfläche machen zu können.. Ich nutze EVCC als Addon in Home Assistant (nicht als Standalone Anwendung). Jetzt muss ich einmal sehen, ob ich in der EVCC yaml in HA die Polling Rate auch einstellen kann. Bislang habe ich die Autos immer über das GUI eingerichtet (ist halt bequem). Sollte das gehen, wage ich dann doch einmal den Versuch mit dem Entwicklerkonto zu meinem Hauptkonto.

    Ich dachte das ist unabhängig vom Ford App Account. Ich hab mir hier mein Konto angelegt. https://developer.ford.com/developer-eu

    Das ist auch der Zugang, wo ich mir vor einiger Zeit das Developer Konto für meinen Hauptaccount eingerichtet habe. Für meinen Zweitaccount funktioniert das jetzt nicht mehr und man kann im Internet viele Berichte von Nutzern finden, die in jüngerer Zeit das gleiche Problem haben. Meine Vermutung ist, dass Ford beim Anlegen des Developerkontos die VIN prüft und dann bei versuchter Anmeldung in einem anderen Account die Einrichtung eines Developer Kontos und damit den API Zugriff blockiert. Ist ein bisschen wie Hase und Igel. Verwendest du deinen Haupt- User Account für das Entwicklerkonto? Mit der neuen Integration? Und hattest du schon einmal Probleme mit einer Kontosperrung? Die Kontosperrung wird meist durch zu häufiges Polling verursacht und man kann ja in der Integration die Polling-Rate noch nicht einstellen

    Du kannst eine Ladelimit einstellen in evcc das überstimmt aber nicht die Ladegrenze im Auto. Hier hilft nur nach dem bspw. 80% erreicht wurden den Ladevorgang in der Ford app Neuzustarten. Alternativ könnte man den Ladestand beim Fahrzeug auf 100% setzen und nur durch evcc reglementieren.

    Gut zu wissen. Wenn es mir irgendwann noch einmal gelingen sollte, für meinen Zweitaccount erfolgreich ein Entwicklerkonto einzurichten (derzeit lande ich immer in einer Redirect-Endlosschleife), kann man dann über EVCC den Zielladestand vorgeben. Das wäre ja schon einmal ein erster Schritt zur besseren Steuerung. Meine Vermutung ist mittlerweile, dass FORD den API-Zugang sperrt, wenn für das gleiche Fahrzeug zwei Entwicklerkonten Konten angelegt werden. Für den Hauptaccount habe ich ein Entwicklerkonto - das will ich aber nicht nehmen, weil man immer wieder liest, dass Ford Accounts, die zu häufig Daten abrufen, sperrt. Der Zweitaccount als einfaches Nutzerkonto funktioniert einwandfrei, nur das Entwicklerkonto geht nicht.

    Dass die Ladelimit-Einstellung in evcc die im Auto eingestellte Ladegrenze nicht überstimmt, gilt ganz generell. Deswegen habe ich das meist über 100 % im Auto und dann Einstellung des Zielladestandes in evcc gelöst. Dafür braucht es aber einen API Zugang, damit der aktuelle Ladestand und der Zielladestand übertragen werden.

    Das könnte in der tat die Ursache sein. Wir haben das ein oder zweimal bei unserem Smart erlebt; der ist aus dem Tiefschlaf auch nicht aufgewacht, wenn die Ladung wieder starten sollte. Ja nach Fahrzeugtyp dauert es offensichtlich auch unterschiedlich lange, bis das Auto in den Tiefschlaf geht. Bei uns ist es verrückterweise beim Smart nur ein- oder zweimal passiert und beim Explorer hatten wir damit bislang keine Probleme, auch wenn wir über Nacht angesteckt lassen..

    Da unsere Wallbox nicht von drei auf eine Phase umschalten kann, haben wir das entsprechende Problem vielleicht nicht. Gibt es möglicherweise einen Unterschied, wenn der Ladevorgang nur pausiert, aber nicht das Abstecken simuliert wird?

    Nun, nach diversen Software-Updates steht ja mein Workaround mit "Plug & Charge" deaktivieren nicht mehr zur Verfügung und schwupps! ist das Problem aus der Threaderöffnung wieder da.


    Habe nun mal im Auto "AC-Ladestrom reduzieren" aktiviert. Diese Möglichkeit gab es ja schon immer und soll ja explizit zur Optimierung des Überschußladens existieren (sagt die KI). Na kiekn wa ma

    Ich nutze die Ladestromreduktion häufiger. Dabei wird einfach der Ladestrom auf 50 % begrenzt. Individuell einstellen kann man da leider nichts. Wenn ich mit EVCC lade, funktioniert das Überschussladen bis jetzt problemlos - ob mit oder ohne Aktivierung der Funktion. EVCC steuert die Wallbox nach verfügbarem Überschuss und regelt rauf oder runter. Auch beim Laden mit einem einphasigen Ladekabel. Bis jetzt macht der Explorer keine Mucken. Hoffe, das bleibt so.