Bei uns laden ein VW ID.3 und ein BMW i5 an zwei go-eChargern. EVCC steuert die Ladevorgänge, Home Assistant setzt darüber eine zusätzliche Betriebsregel um: Es darf nur ein Auto gleichzeitig laden.
Der ID.3 ist unser regelmäßig genutztes Familienauto und soll bei gleichzeitigem Bedarf zuerst verfügbar sein. Diese Reihenfolge passt zu unserem Alltag; technisch notwendig ist sie nicht.
Ein typischer Fall: Beide Autos sind verbunden, der ID.3 liegt unter seinem sichtbaren Prioritätsziel und der BMW wartet im Modus off. Erreicht der ID.3 das Ziel, reicht das allein noch nicht zur Übergabe – solange er tatsächlich lädt, behält er Vorrang. Erst wenn er nicht mehr lädt, sein SOC das Prioritätsziel erreicht hat und der BMW gültigen Ladebedarf meldet, sperrt die Automation zuerst den ID.3. Danach stellt sie am BMW den vor der Sperre gemerkten Modus pv, minpv oder now wieder her.
In Home Assistant lässt sich die Entscheidung am Prioritätsziel und an den EVCC-Modi nachvollziehen: Im beschriebenen Fall zeigt off den wartenden Ladepunkt, der restaurierte Modus die weitere Ladeart. Das Prioritätsziel ist technisch unabhängig von den EVCC- und Fahrzeug-Ladelimits.
Drei Ebenen mit klaren Zuständigkeiten
Der ID.3 lädt mit maximal ungefähr 6,9 kW, der BMW i5 mit bis zu 11 kW. Beide haben einen eigenen go-eCharger; die Aufgaben bleiben getrennt:
- Elektrische AnlageZuleitung und unabhängige Schutzorgane bilden die technische Grundlage.
- EVCCVerwaltet Ladepunkte, Fahrzeugdaten und die Modi für PV-geführtes Laden.
- Home AssistantGibt im Betrieb genau einen Ladepunkt frei und sperrt den anderen.
Was EVCC bereits kann – und warum ich trotzdem ergänze
EVCC unterstützt mehrere Ladepunkte. Seine priority bevorzugt einen Ladepunkt, bestimmt aber nicht die Startreihenfolge und schließt einen zweiten nicht aus. Das ist nicht meine Regel „genau einer darf laden“.
Auch das experimentelle EVCC-Lastmanagement bildet gemeinsame Grenzen ab, aber nicht automatisch eine exklusive Verriegelung. Bei einer neuen Installation würde ich diese Möglichkeiten zuerst mit EVCC und dem Elektriker prüfen.
Was du dafür brauchst
Bei mir bringt die HACS-Community-Integration ha-evcc Zustände und einstellbare Modi nach Home Assistant. Die EVCC-Dokumentation empfiehlt sie, das Projekt nennt sie inoffiziell. Entscheidend sind diese Signalrollen:
| Rolle | Wofür sie gebraucht wird |
|---|---|
| Verbunden und lädt, je Ladepunkt | Erkennt Anwesenheit und einen aktiven Ladevorgang. |
go-e-Fahrzeugstatus car des ID.3 |
Erkennt fehlende Daten und den mehrdeutigen Wert complete. |
| Reale Ladeleistung, je Ladepunkt | Prüft, ob der gesperrte Anschluss bei null bleibt. |
| EVCC-Modus, je Ladepunkt | Liest und setzt off, pv, minpv oder now. |
| ID.3-SOC | Wird gegen ein sichtbares, eigenes Prioritätsziel verglichen. |
| BMW-SOC und BMW-Ziel-SOC | Müssen gültigen Ladebedarf zeigen. |
| Zielhelfer für den ID.3 | Bei mir 50 bis 100 Prozent in 5er-Schritten, aktuell 80 Prozent. |
| Zwei letzte-Modus-Helfer | Merken je Ladepunkt den letzten Modus vor einer automatischen Sperre. |
| Zwei Sperrhelfer | Merken persistent, ob off von dieser Automation gesetzt wurde. |
Technischer Zusatz: MQTT und REST können Zustände lesen und Modi setzen. Entitäten, Authentifizierung und fehlende Daten muss man dabei selbst beherrschen.
complete gehört nicht zu den Freigabebedingungen: Der Wert erschien nach einer EVCC-PV-Pause schon bei rund 61 Prozent. Maßgeblich ist der EVCC-SOC gegenüber dem Prioritätsziel. Ist der ID.3 verbunden und sind car oder SOC unknown beziehungsweise unavailable, bleibt sein Vorrang vorsorglich bestehen.
Vom Fehler zur aktuellen Zustandslogik
Die erste Fassung setzte einen erlaubten Ladepunkt pauschal auf pv und überschrieb damit minpv oder now. Außerdem las sie complete fälschlich als „wirklich voll“. Beides ist entfernt; auch ein Ziel von 100 Prozent löst kein now aus.
Heute wird bei relevanten Zustandsänderungen, nach einem Home-Assistant-Start und alle zwei Minuten neu entschieden:
| Beobachteter Zustand | Entscheidung |
|---|---|
| ID.3 lädt aktiv – auch bei erreichtem Prioritätsziel | ID.3 hat Vorrang; BMW-Modus merken und BMW sperren. |
| ID.3 ist verbunden und sein gültiger SOC liegt unter dem sichtbaren Prioritätsziel | ID.3 hat Vorrang; BMW bleibt gesperrt. |
ID.3 ist verbunden und car oder SOC ist unknown/unavailable |
Im Zweifel bleibt der BMW gesperrt. |
| ID.3 lädt nicht mehr und sein SOC liegt mindestens am Prioritätsziel; BMW ist verbunden und liegt unter seinem EVCC-Ziel | ID.3-Modus merken, ID.3 sperren, danach den gemerkten BMW-Modus restaurieren. |
| BMW-SOC oder BMW-Ziel ist nicht gültig | Keine neue BMW-Freigabe. |
| Keine der beiden Freigabebedingungen trifft zu | Die Automation erzwingt keinen pauschalen Bereitschaftsmodus. |
Vor einer Sperre speichert ein Auswahlhelfer den letzten Modus ungleich off; ein Sperrhelfer kennzeichnet den Eingriff. Restauriert wird nur bei weiterhin off und gesetztem Sperrhelfer. So blieben pv, minpv und now in den Prüfungen erhalten. Ein bewusstes off ist während aktiver Sperre nicht immer eindeutig und bleibt ein Prüffall.
Die Reihenfolge ist konservativ: Verlierermodus merken, Sperre kennzeichnen, Verlierer auf off, erst danach den zuvor automatisch gesperrten Gewinner freigeben. Im Modus restart beginnt jeder Trigger mit aktuellen Daten.
So überträgst du das Konzept in Home Assistant
Ich veröffentliche kein universelles Blueprint: Integrationen liefern unterschiedliche Zustände, eine falsche Zuordnung wäre bei zwei Wallboxen riskanter als hilfreich.
- Prüfe unter Entwicklerwerkzeuge → Zustände, welche stabilen Entitäten die Rollen aus der Tabelle liefern. Verwende Entity-IDs statt Geräte-IDs.
- Lege einen Zahlenhelfer für das Prioritätsziel, zwei Auswahlhelfer mit
off,pv,minpv,nowund zwei Umschalter als Sperrmerker an. - Nutze im Modus Neu starten Änderungen an Verbindung, Laden,
car, SOC, Zielen und Modi als Auslöser; ergänze Start, Kontrolllauf und ruhige Leistungsschwellen. - Prüfe zuerst den ID.3-Vorrang. Der BMW-Zweig folgt nur bei gültigem Bedarf: Verlierermodus merken, Sperrhelfer setzen, Verlierer auf
off, dann einen zuvor automatisch gesperrten Gewinner restaurieren. - Lass einen neutralen Sonst-Fall unverändert. Prüfe Traces und beide realen Leistungen – nicht nur Modusanzeigen.
Kleine Abnahmematrix vor dem Alltagseinsatz
| Test | Erwartetes Ergebnis |
|---|---|
| Nur ID.3 verbunden, SOC unter Ziel | BMW off; ID.3 behält seinen vorher gewählten Modus. |
| Beide verbunden und beide brauchen Energie | ID.3 erhält Vorrang; am BMW bleibt die reale Leistung null. |
| ID.3 erreicht das Prioritätsziel, lädt aber weiter | Keine Übergabe; aktives Laden hält den ID.3-Vorrang aufrecht. |
| ID.3 lädt nicht mehr, erreicht mindestens das Prioritätsziel; BMW hat gültigen Bedarf | Erst ID.3 sperren, dann BMW im gemerkten Modus wiederherstellen. Das ID.3-Fahrzeuglimit ist dafür nicht maßgeblich. |
go-e-car meldet während einer PV-Pause complete, der ID.3 liegt aber unter Ziel |
Keine Übergabe an den BMW. |
go-e-car oder ID.3-SOC wird unbekannt |
Im Zweifel bleibt der BMW gesperrt. |
| BMW-SOC oder BMW-Ziel wird unbekannt | Keine neue BMW-Freigabe. |
Manuell pv, minpv und now wählen |
Modus nach automatischer Sperre und Freigabe jeweils erhalten; now nie automatisch erzeugen. |
| Home Assistant während einer Übergabe neu starten | Nach dem Startlauf höchstens ein Ladepunkt mit realer Leistung; Sperrhelfer und Modusrestaurierung plausibel. |
Diese Fälle brauchen zur eigenen Anlage passende Schwellen, Wartezeiten und reale Wallboxleistungen.
Nachkontrolle an realen Übergaben
Nach der Änderung habe ich die tatsächliche Leistung beider Ladepunkte in konkreten Abläufen verglichen:
Grafik vergrößern
off bei 0 kW. Die unveränderten Home-Assistant-Werte sind stufig und ungeglättet, enthielten keine missing- oder unavailable-Werte und wurden über die direkte go-eCharger-Leistung mit EVCC abgeglichen.| Beobachteter Fall | Ergebnis |
|---|---|
| Übergabe vom ID.3 an den BMW | Der ID.3 stand auf off und 0 W, bevor der BMW in pv mit ungefähr 4,6 kW lud; keine sichtbare Überschneidung. |
Bewusst gewähltes now am BMW |
now blieb über SOC-Aktualisierungen und Kontrollläufe erhalten: BMW ungefähr 10,9 kW, ID.3 0 W. |
Manuell gewähltes pv am BMW |
Der Modus blieb stabil, der ID.3 gleichzeitig bei 0 W. |
Diese Beobachtungen bestätigen Übergabe und Moduserhalt in den geprüften Situationen, aber nicht jede Störung. Integrationsausfall, Neustart während einer Übergabe, stark verzögerte Daten und gleichzeitiges Anstecken sind nicht in allen Kombinationen dokumentiert.
Warum Neustart und Kontrolllauf dazugehören
Bei Neustart oder verspäteten Daten führen zwei Wege zurück zu einer definierten Entscheidung:
- HA-Starttrigger: bewertet nach jedem Start die gesamte Lage neu.
- Kontrolllauf alle zwei Minuten: zieht verpasste oder verspätete Zustände nach.
Trifft ein Neustart der Automation zwischen Sperren und Freigeben, ist der konservative Zwischenzustand eher „beide aus“ als „beide an“.
Fazit
Aus Fehlerbeobachtung wurde eine klare Betriebsregel: ID.3-Vorrang bei aktivem Laden oder unter sichtbarem Ziel, vorsorgliches Sperren bei fehlenden Daten und Moduserhalt statt pauschalem pv. Die geprüften Übergaben zeigten keine gleichzeitige Leistung. Die Automation organisiert den Alltag – elektrischen Schutz liefern Leitung, Schutzeinrichtung und fachliche Planung.
Stand und letzte redaktionelle Überarbeitung: 9. September 2026.