Ladeautomation Referenz

01 Die MQTT-Steuerbefehle

Das Wichtigste zuerst, weil es am schwersten zu finden war: Der Multi RS 6000-3P ist kein klassisches MultiPlus/Quattro-System. Er ignoriert den kompletten com.victronenergy.settings-Baum für die ESS-Steuerung — und zwar lautlos. Befehle dorthin werden scheinbar angenommen, quittiert und wirken trotzdem nicht.

Broker ist der Ekrano GX selbst unter 192.168.6.19:1883, ohne Authentifizierung. Die VRM-Portal-ID der Anlage lautet c0619ab9f305. Home Assistant hängt bereits an diesem Broker, Befehle gehen dort über mqtt.publish.

Schreiben — Präfix W/

Lesen — Präfix R/, Antwort auf N/

Der Victron sendet auf den N/-Topics nur, wenn man ihn fragt. Eine leere Nachricht an das R/-Topic desselben Pfads löst genau eine Antwort aus:

publish  R/c0619ab9f305/acsystem/0/Settings/Ess/MinimumSocLimit   (leerer Payload)
   →   N/c0619ab9f305/acsystem/0/Settings/Ess/MinimumSocLimit   {"value":20.0}
   →   N/c0619ab9f305/acsystem/0/Ess/ActiveSocLimit             {"value":20.0}

Ess/ActiveSocLimit ist dabei der aussagekräftigere Wert: das tatsächlich wirksame Limit, nicht nur die Einstellung. Ein globaler Keepalive (R/<id>/system/0/Serial) wäre ebenfalls möglich, lässt das Gerät aber alle Werte im Sekundentakt fluten — gezielte Einzelabfragen sind sparsamer.

Was nachweislich nicht funktioniert

Diese Wege sehen richtig aus, melden teilweise sogar plausibel zurück, und bewirken am Multi RS trotzdem nichts. Live gegengeprüft, während der Wert am Ekrano-Display selbst verstellt wurde:

• settings → Settings/CGwacs/AcPowerSetPoint, Hub4Mode, BatteryLife/State, BatteryLife/MinimumSocLimit
• die HA-Entität number.multi_rs_6000_3p_ess_mindest_soc — schreibt auf den obigen, wirkungslosen Pfad
• die HA-Entität select.multi_rs_6000_3p_ess_modus für Steuerzwecke

02 Wie heute gesteuert wird

Nach dem Umbau vom 07.09. gibt es statt sechzehn ineinandergreifender Preis-Automationen nur noch zwei Schalter und einen wiederverwendbaren Zeitfenster-Baustein. Der Rest ist bewusst abgeschaltet.

Beide lassen sich außerdem über den Zeitplan-Baustein vorprogrammieren: input_datetime.schnell_netz_start und ..._ende legen das Fenster fest, input_select.schnell_netz_ziel bestimmt das Ziel. Zwei Automationen (Zeitplan: Start / Ende) schalten dann selbstständig.

Die Bedienoberfläche

Das Dashboard /dashboard-energie/ ist seit dem 10.09. umgebaut. Reihenfolge: Energiefluss, Übersicht, Sofort laden, Ladeplan, Automatik, Hausakku Laden. Der frühere Reiter Auto Laden ist als Unterseite ausgeblendet und nur noch über seine URL erreichbar.

• Sofort laden — Dauer wählen, aktueller Preis und Ø-Preis des gewählten Fensters, dann Rückfrage mit Menge und Kosten, erst danach lädt es. Während einer laufenden Ladung ist alles gesperrt außer Laden jetzt stoppen.
• Ladeplan — vier Blöcke in fester Reihenfolge: Fahrzeug und Ladestände, Deadline, Ergebnis, Start. Ein Knopf trägt das Fenster ein und schaltet scharf.
• Automatik — weiterhin ein Platzhalter.

03 Auto aus dem Netz laden

Das Grundproblem: EVCCs now-Modus lädt mit voller Leistung, nimmt sich den Strom aber bevorzugt aus dem Hausakku statt aus dem Netz. Am 04.09. live nachgemessen: 11,35 kW Ladeleistung, 1,3 kW PV, Netzbezug blieb bei null — die Differenz kam aus dem Akku.

Der Trick

Statt an EVCC herumzuregeln wird dem Victron der Hausakku entzogen: Der Mindest-SoC wird proaktiv auf den aktuellen Hausakku-Stand plus ein Prozent gesetzt, gedeckelt auf 99. Damit darf der Akku nicht mehr entladen — und das System zieht die Ladeleistung automatisch aus dem Netz. Kein Netzsollwert, kein Direktzugriff auf die Wallbox nötig.

Die 11 kW sind bei allen vier Wegen sofort weg — das macht die Wallbox beziehungsweise das Auto. Unterschiedlich lange dauert nur das Aufräumen in Home Assistant: beim Abstecken und beim Stopp-Knopf ohne Wartezeit, sonst zwei Minuten. Die Wartezeit ist Absicht: „lädt nicht“ heißt nicht zwangsläufig „fertig“ — das Auto pausiert auch von selbst, und EVCC schaltet zwischen ein- und dreiphasig um.

Das reguläre Ende ist nicht diese Abschaltung, sondern der Zeitplan-Baustein zur eingestellten Endzeit. Die Abschaltung ist ein Notnetz und gehört deshalb bewusst nicht auf die Bedienoberfläche.

Preis-Rückfrage vor dem Start

Seit dem 10.09. startet der Knopf nicht mehr direkt. Er öffnet eine Rückfrage mit dem Durchschnittspreis des gewählten Fensters — nicht dem Momentpreis, der bei vier Stunden Ladedauer wenig aussagt — dazu Preisspanne, Menge und geschätzte Kosten. Erst die Bestätigung schaltet ein. Eine vergessene Rückfrage verfällt nach zwei Minuten, damit sie nicht Stunden später zu einem längst anderen Preis bestätigt wird.

Grundlage ist sensor.sofort_laden_fensterpreis: der Mittelwert der Viertelstunden-Preise über jetzt bis jetzt + Dauer. Menge und Kosten sind ausdrücklich als Obergrenze beschriftet — sie rechnen mit 11 kW über die volle Dauer.

Ohne angestecktes Auto lässt sich gar nicht erst starten. Grund: Die Ladeende-Erkennung wartet auf den Übergang „lädt“ → „lädt nicht“. Wurde nie geladen, gibt es diesen Übergang nicht, und die Session liefe bis zur eingestellten Endzeit weiter — mit gesperrtem Hausakku und ohne Nutzen.

Liegt der Ø-Preis über input_number.evcc_schnellwahl_warn_schwelle (aktuell 0,40 €/kWh), färbt sich die Rückfrage orange, und während der Ladung kommt eine Warnung aufs Handy. Sie stoppt nichts — sie informiert nur.

04 Hausakku

Der Hausakku wird im Normalbetrieb DESS überlassen. Manuelles Netzladen gibt es weiterhin als Schalter, wird aber selten gebraucht.

Der frühere Software-Ladestrom-Deckel wurde am 08.09. entfernt: Am Ekrano sind dauerhaft 157 A eingestellt (0,25 C der 628-Ah-Zellen), damit war der Software-Deckel überflüssig.

05 DESS

Victrons Dynamic ESS optimiert den Hausakku gegen den Stundenpreis. Es läuft auf auto_vrm und macht das inzwischen zuverlässig.

Am 01.09. kaufte DESS nachts bei 0,45 €/kWh Netzstrom ein. Die Ursache war nicht ein Fehler in DESS, sondern dass es mit einem Festpreis von 24,19 ct rechnete und deshalb jede Stunde für gleich teuer hielt. Seit der Umstellung auf den dynamischen Tibber-Preis kennt es den echten Stundenpreis.

Was DESS als Nächstes vorhat

Der Fahrplan liegt nicht lokal auf dem Ekrano. Ein Mitschnitt von 1965 MQTT-Topics am 10.09. fand nur die alten, wirkungslosen CGwacs/BatteryLife/Schedule-Plätze — alle leer. Der Plan lebt ausschließlich in der VRM-Cloud:

GET https://vrmapi.victronenergy.com/v2/installations/938029/stats?type=dynamic_ess&interval=hours
     Header: X-Authorization: Token <VRM-Token>

Geliefert werden unter anderem vrm_to_battery_fc, vrm_to_grid_fc, vrm_consumption_fc und solar_yield_forecast — je 34 Stundenpunkte, rund 33 davon in der Zukunft. Geplante Netzladung erkennt man daran, dass die geplante Batterieladung die PV-Prognose derselben Stunde übersteigt; der Rest muss aus dem Netz kommen.

Für „DESS lädt gerade aus dem Netz“ taugen die lokalen Messwerte besser: DC-Batterieleistung, Summe der drei Netzleistungen, dazu der ESS-Modus als Zusammenhang. Ein weiterer Kandidat, lokal gefunden, aber noch unbestätigt: acsystem/0/Ess/DisableDischarge.

Die alte Zwangsabschaltung bei hohem Preis (EVCC/DESS Preissteuerung) ist seit dem 07.09. deaktiviert und wird nicht mehr gebraucht: Ihre Preisgrenze von 0,21 € war nichts anderes als der alte Festpreis minus Lade- und Entladeverluste.

06 Rückmeldung vom Gerät

Lange war unklar, ob ein gesendeter Befehl am Victron wirklich ankommt. Seit dem 09.09. gibt es dafür echte Sensoren, gespeist aus den R/-Abfragen aus Abschnitt 1.

Abgefragt wird alle 30 Sekunden, zusätzlich sofort nach jedem Schaltvorgang und beim HA-Start. Bleiben die Antworten aus, gehen die Sensoren nach drei Minuten bewusst auf unavailable, statt einen veralteten Wert weiterzuzeigen — ein Prüfsensor darf ausfallen, aber nicht lügen.

Erst dadurch möglich: den Ruhewert wiederherstellen

Bis zum 09.09. schrieb das Ende pauschal 20 % zurück — eine Notlösung, weil keine Entität den echten Gerätewert kannte. Seit es die Rückmeldung gibt, wird der Wert von vor der Session gesichert und danach genau er wiederhergestellt.

Der Ruhewert wird außerdem laufend nachgeführt: Steht der Gerätewert zehn Minuten stabil, während nicht schnellgeladen wird, übernimmt Home Assistant ihn als neuen Ruhewert. Stellst du am Ekrano dauerhaft 30 % ein, weiß HA das kurz darauf von selbst.

Ein Wachhund prüft alle fünf Minuten: Wird nicht schnellgeladen, steht der Merker aber noch, und liegt der Gerätewert über dem Ruhewert — dann wird zurückgeholt und eine Notiz hinterlassen. Das greift auch dann, wenn HA während der Session neu startete oder ein Befehl unterwegs verlorenging.

07 Harte Grenzen

08 Fahrzeuge

Für die beiden ID.3 setzt Home Assistant bewusst kein Ladelimit mehr. Seit vehicleSoc wieder echte Werte liefert, würde EVCCs eigene SoC-basierte Planung ein von uns gesetztes limitEnergy ohnehin ignorieren — das Auto stoppt sich über sein eigenes Limit zuverlässiger.

Gast ist ein eigener Fall: Bei einem fremden Auto kennt niemand den Ladestand, deshalb wird dort nur die gewünschte Menge in kWh eingegeben. Dieselbe Zahl treibt die Preisrechnung und das EVCC-Ladelimit, sie können also nicht auseinanderlaufen. Bis zum 10.09. gab es dafür zwei getrennte Felder, und nur eines davon wirkte wirklich.

EVCCs Puffer-Schwellen werden saisonal gesetzt, jeweils am 1. April und 1. September. Die Automation liest die Werte aus zwei Helfern und setzt den Priority-SoC fünf Punkte darunter. Aktueller Stand: Sommer 45/50 %, Winter 75/80 % (Priority-SoC / Buffer-SoC).

Was die Schwellen bedeuten, ist für den Akkuschutz entscheidend: Unter dem Priority-SoC hat der Hausakku Vorrang, das Auto bekommt nichts. Über dem Buffer-SoC darf das Auto den Akku anzapfen — aber nur bis zu dieser Grenze. Im PV-Betrieb kann EVCC den Hausakku damit gar nicht unter den Buffer-SoC ziehen, auch nicht bei 7 kW Ladeleistung. Deshalb braucht PV-Laden keinen Eingriff von uns; Schnellladen dagegen ignoriert diese Grenzen.

09 Was bewusst abgeschaltet ist

Elf Automationen stehen auf off (am 10.09. nachgezählt). Sie sind nicht kaputt — sie gehören zur alten Preisautomatik, die am 07.09. komplett stillgelegt wurde, weil ihr Zusammenspiel nicht mehr überschaubar war.

Es sind genau diese: EVCC/DESS Preissteuerung, Hausakku Ladeplan ausführen, Sessionmin-Preis Tracking, Preis ist jetzt günstig, PV nachhaltig weg, PV-Rückkehr morgens, Schnellwahl Jetzt Hausakku laden, Erinnerung Anstecken vor günstigem Fenster, Auto angesteckt, Auto abgesteckt und TEST Schnell über Netz.

10 Überwachung

Ein Cron-Job auf dem apps-server prüft alle 30 Minuten und protokolliert jede Messung.

Gemeldet wird nur noch, was wirklich etwas bedeutet:

• Teurer Netzbezug — über 500 W bei über 0,30 €/kWh, zwei Messungen hintereinander, und nur wenn das Auto nicht lädt. Das ist genau das Symptom vom 01.09.
• VRM-Formel auseinandergelaufen — siehe Abschnitt 5.
• Festhängendes now-Laden bei hohem Preis.

Protokolliert werden unter anderem Netzleistung und Batterieleistung — damit lässt sich im Nachhinein belegen, ob DESS je teuer eingekauft hat, statt sich auf Momenteindrücke zu verlassen.

11 Der go-e direkt

EVCC reicht vom Ladepunkt nur charging und connected durch, chargerStatusReason steht dauerhaft auf unknown. Damit ist „das Auto ist voll“ nicht von „pausiert“ zu unterscheiden. Die Wallbox selbst weiß es — das Fahrzeug meldet es über die Pilot-Leitung.

Der go-e Charger V3 (Firmware 60.5) steht unter 192.168.6.46 und hat eine eigene, offene HTTP-Schnittstelle ohne Authentifizierung. Nur API v2 — der alte Endpunkt /status antwortet mit 404.

GET http://192.168.6.46/api/status?filter=car,err,alw,fwv
     → {"alw":false,"car":1,"err":0,"fwv":"60.5"}

Der Unterschied zwischen 3 und 4 ist genau das, was fehlte: „angesteckt, darf gerade nicht“ gegen „fertig“. In Home Assistant liegen dafür zwei REST-Sensoren, alle 30 Sekunden abgefragt: sensor.go_e_ladezustand (Klartext, Rohwerte als Attribute) und sensor.go_e_fehler.

Weil wir keine Integration nutzen, passt niemand die Auswertung an, wenn sich die Firmware ändert. Deshalb meldet sich HA in drei Fällen: Firmware gewechselt, ein car-Code den die Tabelle nicht kennt (das Template gibt dann „unerwartet (N)“ aus, statt still etwas Falsches anzunehmen), oder 30 Minuten keine Antwort.

MQTT kann der go-e ebenfalls, ist aber abgeschaltet. Der Nutzer erwartet, es später für die Steuerung durch den Netzbetreiber (§14a EnWG) ohnehin zu brauchen — dann neu bewerten.

12 EVCC kennt die Preise

Seit dem 10.09. hat EVCC einen Tibber-Tarif und die VRM-Solarprognose. Es steuert damit weiterhin nichts — das ist ein Beobachtungsschritt.

„Günstiges Netzladen“ ist kein Zielzeit-Planer. Der Untertitel in EVCC sagt es: „Aktiviert vorübergehendes Schnellladen im PV-Modus.“ Fällt der Preis unter die Grenze, lädt EVCC sofort mit voller Leistung, in beliebig vielen verstreuten Blöcken, ohne Rücksicht auf einen Zielzeitpunkt. Für „bis morgen früh voll“ wären EVCCs Ladepläne das richtige Werkzeug. Im selben Dialog gilt: Batterie Boost muss aus bleiben — er erlaubt ausdrücklich Schnellladen aus der Hausbatterie.

Der Akkuschutz gilt jetzt auch für EVCC

Bis zum 10.09. hing das Anheben des Mindest-SoC an einer Stelle: unserem eigenen Schalter. Startet EVCC von sich aus — per Preisgrenze oder weil jemand in der App auf „Schnell“ drückt — blieb der Mindest-SoC bei 20 %, und die 11 kW kämen aus dem Hausakku. Seit dem 10.09. lösen zusätzlich binary_sensor.evcc_go_e_smart_cost_active und select.evcc_go_e_mode = now den Schutz aus.

Entsprechend stellt der Wachhund nicht allein deshalb zurück, weil gerade nicht geladen wird. Seine Bedingung ist ein Oder: entweder ist kein Schnellladen mehr aktiv — oder es wird seit zwei Minuten nicht geladen und die Ladeleistung liegt unter 0,2 kW, also 200 Watt. Der zweite Zweig ist der wichtigere: Er greift auch dann, wenn das Auto voll ist, das Kabel steckt und der Modus noch auf „Schnell“ steht. Genau so lief es am 30.09.2026 — der Mindest-SoC fiel gut zwei Minuten nach dem Ladeende von selbst auf 20 zurück, alle vier Entitäten, Merker gelöscht. Die frühere Fassung dieses Absatzes („erst wenn kein Schnellladen mehr aktiv ist“) war zu eng und hätte diesen Fall nicht abgedeckt.

12b Was nach dem Ladeende passiert

Am 30.09.2026 an einer echten Ladung Schritt für Schritt nachgemessen. Drei Dinge laufen dabei nacheinander ab, und zwei davon sehen aus wie ein Fehler, sind aber keiner.

Die Stromrampe — erst gedrosselt, dann voll

Wird schnellgeladen, geht der Strom nicht sofort auf 16 A. Er startet auf 10 A und wird erst danach hochgestuft — über EVCCs eigene maxcurrent-Schnittstelle, damit EVCC den gedrosselten Wert kennt und nicht dagegenregelt. Am 30.09. lagen zwischen Schutz und Hochstufung 93 Sekunden, danach 11,39 kW. Der Sinn: Der Übergang auf Netzbezug soll abgeschlossen sein, bevor die volle Last anliegt.

Der Mindest-SoC kommt von selbst zurück

Der Wachhund prüft alle fünf Minuten den realen Zustand, nicht den Ablauf einer Sitzung. Am 30.09. stellte er gut zwei Minuten nach dem Ladeende alle vier Entitäten von 77 auf 20 zurück und löschte den Merker — obwohl der Modus noch auf „Schnell“ stand und das Kabel steckte.

DESS hält den Akku noch ein paar Minuten fest

Danach bleibt der Netzbezug trotzdem bestehen — am 30.09. rund 400 W, obwohl Modus aus, Mindest-SoC 20 und Hausakku 78 %. Die Ursache steht im Gerät selbst: Beschränkungen für dynamisches ESS meldet no_flow, Strategie probattery. Das Dynamische ESS hält den Hausakku fest, und das Haus läuft solange am Netz.

Es löst sich von allein — am 11.09. nach etwa fünf, am 30.09. nach rund sieben Minuten. Größenordnung: Hundertstel Kilowattstunden. Kein Eingriff nötig. Nach dem Smart-Meter-Einbau am 26.10.2026 lohnt ein zweiter Blick, weil Netzbezug dann wieder Geld kostet.

Die Abschalt-Rampe des Wechselrichters — die ist nicht der Nachlauf

Auch wenn das Auto hart abschaltet, geht der Netzbezug nicht sprunghaft auf null, sondern streng linear über etwa eine Minute. Das sieht dem DESS-Nachlauf zum Verwechseln ähnlich, hat aber eine andere Ursache — und anders als jener ist es kein Fehler und nicht abstellbar.

Das Auto war also sofort aus; die Flanke danach gehört allein dem Wechselrichter. Gemessen rund 80 W/s — am 07.10.2026 im Fünfsekundentakt waren es 94 W/s, verteilt auf drei Geräte also 31 W/s je Multi RS.

Warum das überhaupt uns trifft, obwohl es nur um 11 kW geht: Die Regel gilt nicht der Wallbox, sondern unserer Speicheranlage mit 3 × 6.000 VA = 18 kVA — VDE-AR-N 4105 greift ab 4,6 kVA. Und der zitierte Satz nennt beide Richtungen, supply and/or consumption. Weil die Wallbox am AC-Ausgang hinter dem Akku hängt, laufen ihre 11 kW durch den Multi RS und sind für ihn ein geregelter Sollwert. Beim Nachbarn, dessen Wallbox direkt am Zähler sitzt, passiert nichts dergleichen. Es ist eine Folge unserer Topologie, nicht der Wallbox.

Und es ist nachweislich nicht DESS — am 07.10. stand während der Rampe der Netz-Sollwert auf 0, der Zustand auf scheduled_selfconsume und der Ziel-SoC auf 0. DESS steuerte in diesem Moment gar nichts.

Die Energie ist nicht verloren: Was der Wechselrichter nicht schlagartig abwerfen darf, schiebt er in den Hausakku — am 07.10. direkt gegengemessen (Netz 6.615 W, Akku +6.227 W). Die Fläche unter der Rampe sind rund 0,06 kWh, also gut zwei Cent, und die liegen im Speicher.

Zurück auf PV — die Lücke vom 30.09. und wie sie geschlossen wurde

Es gab zwei Rückstellungen auf PV, und keine passte auf den häufigsten Fall: Auto abgesteckt braucht den gezogenen Stecker, PV-Rückkehr morgens braucht 500 W Sonne für fünf Minuten. Auto voll, Kabel steckt bis zum Morgen — dafür gab es nichts, der Modus blieb auf „Schnell“ hängen.

Schlimm war das nicht, der Mindest-SoC war ja längst zurück. Die eine Folge: Zieht der Wagen nachts noch einmal Strom — Klimatisierung, Bordakku —, käme das mit voller Leistung aus dem Netz statt aus Überschuss.

Zwei Grenzen, die man nicht verwechseln darf

Beide heißen im Gespräch schnell „die Grenze“, tun aber Verschiedenes — und sie berühren sich nicht:

Nachgeprüft am 30.09.: Acht Automationen schreiben den Victron-Mindest-SoC, keine einzige liest die Prognose. Sie speisen sich nur aus dem gesicherten Ruhewert und dem aktuellen Ladestand.

13 Noch unbewiesen

Diese Punkte sind aus Feldern und Doku sauber hergeleitet, aber nicht an der eigenen Anlage beobachtet. Sie gelten als plausibel, nicht als Fakt — und sind kein Fundament zum Weiterbauen.

• Springt car auf 4, wenn das Auto selbst beendet? Bleibt es bei 3, ist „fertig“ nicht von „pausiert“ zu trennen und die Zwei-Minuten-Regel bleibt das führende Signal.
• Kommen Ladestand und Auto-Ladelimit schon beim Anstecken oder erst beim Laden? Der Ladepunkt steht auf soc.poll: charging mit einer Stunde Abstand. Davon hängt ab, ob sich der Start-SoC beim Planen überhaupt füllen kann.
• Greift ein Stopp am go-e selbst durch, oder gibt EVCC im now-Modus wieder frei?
• Füllt EVCC die Kosten je Sitzung? sessionPrice und sessionPricePerKWh sollten sich mit der ersten Ladung nach dem Tarif füllen. Sie sind die Grundlage für eine Abrechnung gegenüber Dritten.
• Ändert sich der Mindest-SoC, ohne dass HA geschrieben hat? Das fiele auf EVCCs eigene Entladesperre zurück. Seit es die Rückmeldung gibt, wäre es sichtbar statt vermutet.

14 Wenn etwas nicht läuft

1. Lädt das Auto nicht aus dem Netz, sondern aus dem Akku? Prüfen, ob sensor.victron_ess_aktives_soc_limit wirklich auf den aktuellen Hausakku-SoC hochgezogen wurde. Steht dort noch 20, ist der Befehl nicht angekommen.
2. Sensoren auf unavailable? Dann antwortet der Victron nicht. Prüfen, ob die Automation Victron: ESS-Status abfragen läuft und ob der Ekrano unter 192.168.6.19 erreichbar ist.
3. Befehl scheint zu wirken, tut es aber nicht? Erst die Payload-Form prüfen (JSON-Hülle!), dann ob der Pfad wirklich unter acsystem/0 liegt. Nicht der HA-Entität glauben — echte Leistungsmesswerte ansehen, über mehrere Minuten.
4. Automation geändert, wirkt aber nicht? Nach jeder Änderung über die Config-API zusätzlich automation.reload aufrufen. Ohne das läuft die alte Fassung im Speicher weiter — das hat einmal einen Sicherheits-Timeout zwei Stunden lang wirkungslos gemacht.
5. Dashboard-Änderung nicht sichtbar? Lovelace liegt im Storage-Mode. Direkte Änderungen an der Datei werden erst nach einem HA-Neustart übernommen, es gibt keinen Reload-Dienst dafür.
6. Neuer Sensor liefert immer 0 oder nichts? Erst die Entity-ID prüfen. Home Assistant macht aus einem Namen mit Umlaut eine ID ohne Ersatzschreibweise: aus „Nachbar Akkukapazität“ wird sensor.nachbar_akkukapazitat, nicht ...kapazitaet. Templates zeigen dann ins Leere und liefern still den Vorgabewert. Umbenennen per WebSocket über config/entity_registry/update; der Anzeigename darf den Umlaut behalten.
7. EVCC-Einstellung geändert, wirkt aber nicht? EVCC übernimmt Konfigurationsänderungen erst nach docker restart evcc. Bis dahin liefert /api/state den alten Stand — das gilt für Fahrzeugdaten ebenso wie für einen neu angelegten Tarif.
8. Tibber-Tarif in EVCC meldet „Invalid Compact JWS“? Das Token war nicht als JWT lesbar, meist unvollständig kopiert. Das Token aus Home Assistant hilft nicht, wenn dessen Tibber-Anbindung über Nabu Casa läuft: Das ist ein OAuth-Token mit wenigen Stunden Laufzeit, den nur HA erneuern kann. EVCC braucht einen eigenen persönlichen Token von developer.tibber.com.
9. Ein Ergebnis wird schlechter, obwohl es mehr Freiheit gibt? Dann stimmen Optimierungskriterium und angezeigte Zahl nicht überein. Am 10.09. so gefunden: Die Fenstersuche minimierte den Mittelwert über aufgerundet 15 Viertelstunden, bezahlt wurde nach der echten Menge — 14 volle Slots plus Rest. Der letzte Slot zählte in der Auswahl voll, in der Rechnung zu 16 %. Folge: Mit einer späteren Deadline wurde das Laden teurer, was logisch unmöglich ist. Der Monotonie-Test — mehr Freiheit darf nie schlechter sein — findet so etwas am billigsten.
10. Ein Bedienelement schreibgeschützt gemacht? Prüfen, was über dieses Feld sonst noch ging. Am 10.09. verschwand mit dem Ziel-Feld auch die einzige Möglichkeit, einen vorgemerkten Plan abzusagen — einen laufenden konnte man stoppen, einen gebuchten nicht.
11. Zustandsauslöser feuert nicht? Sie feuern nur bei echter Änderung. Einen bereits ausgeschalteten Schalter noch einmal auszuschalten löst nichts aus — wer sich darauf verlässt, baut einen wirkungslosen Knopf.
12. Beschreibungstext einer Automation gelesen? Nicht darauf verlassen. Mehrere Beschreibungen sind älter als der Code darunter. Es zählt der actions-Block.