evcc updaten und installieren 2026: Versionen, Sponsor-Token, Migrationen

Aktuell stabil: evcc 0.305.1 (Release 19. April 2026). Update in einer Zeile je Installationsweg: Docker: sudo docker compose pull && sudo docker compose up -d. Debian/Ubuntu: sudo apt --only-upgrade install -y evcc. Synology DSM: Container Manager öffnen, Image evcc/evcc:latest neu ziehen, Container neu erstellen. Vor jedem Update eine Kopie der evcc.yaml und der Datenbank anlegen. Breaking Changes sind in den Release-Notes mit einem Marker gekennzeichnet und betreffen in der Regel einzelne Hersteller-Vorlagen. Ein Sponsor-Token (vier US-Dollar im Monat oder einmalig 150 US-Dollar) wird für die Anbindung vieler kommerzieller Wallboxen benötigt. Details in Abschnitt evcc Sponsor-Token verstehen.

Wie evcc veröffentlicht wird: Release-Zyklus verstehen

Das Projekt veröffentlicht neue Versionen in einem für Open-Source-Projekte hohen Takt: Minor-Releases erscheinen wöchentlich bis zweiwöchentlich, Patch-Versionen folgen meist innerhalb weniger Tage, wenn Regressionen gemeldet werden. Die Versionsnummer folgt dem Schema 0.MAJOR.MINOR.PATCH. Solange der führende Nullblock steht, bleibt das Projekt formal im Vor-1.0-Status, auch wenn viele der verfügbaren Anbindungen längst produktiv im Dauerbetrieb laufen.

Die Release-Notes auf GitHub sind in vier Kategorien gegliedert: neue Funktionen, sonstige Änderungen, Fehlerbehebungen und Breaking Changes. Letztere sind mit einem sichtbaren Marker versehen und nennen in der Regel konkret, welche Hersteller-Vorlage, welche Konfigurations-Struktur oder welcher Datenpunkt sich verändert. Für die Betriebsplanung heißt das: Wer nicht jeden Release sofort einspielen will, kann bedenkenlos vier bis sechs Wochen warten und sich auf Patch-Level orientieren. Nur bei Breaking Changes, die das eigene Setup betreffen, ist eine aktive Migration notwendig. Der Hauptratgeber zu evcc liefert den Überblick über die Funktionsweise, diese Seite konzentriert sich auf die Wartung.

Wo Sie den Changelog zuverlässig lesen

Der verbindliche Changelog liegt in den Release-Notes auf GitHub: github.com/evcc-io/evcc/releases. Jede Version hat dort einen eigenen Eintrag mit allen Commits, PR-Nummern und, besonders wichtig, den Breaking-Change-Markern. Zweite Quelle ist die offizielle Dokumentation unter docs.evcc.io: Dort werden größere Umstellungen in den jeweiligen Anleitungs-Kapiteln eingebaut und erfahrungsgemäß leichter zu finden als über den reinen Release-Text.

Dritte, inoffizielle Quelle ist die #announcements-Rubrik in den GitHub Discussions. Sie eignet sich, um zu verstehen, welche Änderung gerade besonders viele Nachfragen erzeugt. Für die Entscheidung, welche Version man ansteuert, ist aber die Release-Note der Referenzpunkt.

evcc aktualisieren – je nach Installationsweg

Die drei verbreitetsten Installationswege behandeln wir in einem Block, damit Sie nicht zwischen drei Unter-Seiten springen müssen.

Docker (inklusive NAS wie Synology, QNAP, Unraid)

Wer evcc als Docker-Container betreibt, aktualisiert in zwei Schritten. Bei docker-compose-basierten Setups:

sudo docker compose pull
sudo docker compose up -d

Der Image-Name ist evcc/evcc:latest. Der Container wird dabei neu erzeugt, die beiden persistenten Volumes (die Datenbank unter /root/.evcc und die evcc.yaml unter /etc/evcc.yaml) bleiben unverändert. Wer direkt mit docker run arbeitet, muss den Container mit stop und rm entfernen und mit identischen Volume-Parametern neu starten. Das Image wird vorab mit docker pull evcc/evcc:latest gezogen.

Debian und Ubuntu (apt-Repo)

evcc pflegt ein eigenes apt-Repository. Ist es wie in der Installations-Dokumentation beschrieben eingebunden, reicht:

sudo apt --only-upgrade install -y evcc

Der systemd-Dienst evcc startet nach dem Paket-Update meist von selbst durch. Wer auf Nummer sicher gehen will: sudo systemctl restart evcc und anschließend sudo journalctl -u evcc --since "5 minutes ago" für einen kurzen Log-Check.

Synology DSM (Container Manager)

DSM-Nutzer arbeiten über den Container Manager (ältere DSM-Versionen: Docker-Paket). Der Weg ist: Image evcc/evcc:latest neu ziehen, den bestehenden Container stoppen, das Image-Update übernehmen und den Container neu erstellen. Die Port-Weiterleitungen (7070 für die Web-Oberfläche, 8887 für OCPP) und die Volume-Bindings sind dabei aus dem bestehenden Setup zu übernehmen. Wer DSM per SSH nutzt, kann auch direkt die oben genannten Docker-Kommandos absetzen. Das Ergebnis ist identisch.

Gemeinsame Vorsichtsregel

Vor jedem Update eine Kopie der evcc.yaml und ein Snapshot der Datenbank. Unter Debian liegen diese Dateien standardmäßig in /etc/evcc.yaml und /var/lib/evcc/evcc.db. Die zehn Sekunden, die ein cp dieser beiden Dateien kostet, sparen im Ernstfall eine Stunde Konfigurations-Rekonstruktion.

Backup vor dem Update: Welche Dateien wann sichern

Die Update-Kommandos tauschen nur die Binärdateien aus. Konfiguration und Betriebsdaten liegen in zwei Dateien, die beim Update unangetastet bleiben, bei einem fehlgeschlagenen Update oder einem Schema-Wechsel aber den Unterschied zwischen zehn Minuten und drei Stunden Arbeit machen.

Was sichern. Zwei Dateien sind für jeden Installationsweg identisch wichtig:

• Konfigurations-Datei evcc.yaml: enthält die komplette Geräte-, Tarif- und Loadpoint-Logik. Ohne diese Datei muss das Setup von Hand neu aufgebaut werden.
• Datenbank evcc.db: speichert Ladesessions, Sponsor-Token, Anpassungshistorie der PV-Vorhersage und Lernwerte. Ein Verlust ist kein Betriebs-Showstopper, kostet aber die Statistik der bisherigen Laufzeit.

Wo die Dateien liegen. Die Standard-Pfade je Installationsweg:

• Debian/Ubuntu (apt): /etc/evcc.yaml und /var/lib/evcc/evcc.db.
• Docker: als Volumes eingebunden, typisch ./evcc.yaml:/etc/evcc.yaml und ./data:/root/.evcc. In dem Data-Volume liegt die evcc.db.
• Synology Container Manager: die per DSM-UI eingebundenen Volume-Pfade, häufig im DSM-Bereich /volume1/docker/evcc/.

Frequenz und Methode. Als Minimum eine Kopie direkt vor jedem Update. Wer ein NAS oder einen zweiten Host im Haushalt hat, fährt besser mit einem rollierenden Snapshot: ein simples Shell-Skript per cron oder systemd.timer kopiert die beiden Dateien täglich an einen externen Ort. Rotations-Werkzeuge wie borg oder restic halten die Historie kompakt. Eine rein lokale Kopie auf derselben SD-Karte oder im selben Container-Volume zählt nicht als Backup: Bricht der Speicher, ist beides weg.

Versionskontrolle für evcc.yaml. Wer die Konfiguration regelmäßig anpasst, legt die evcc.yaml zusätzlich in ein privates Git-Repository. Jede Änderung wird so nachvollziehbar, und ein Rollback auf eine vorige Konfiguration ist ein git checkout entfernt. Die Datenbank gehört wegen Größe und Binärformat nicht in das Repository.

Breaking Changes: Muster der letzten sechs Monate

Breaking Changes im evcc-Changelog betreffen nahezu nie das Kernprinzip, sondern einzelne Integrationen. Drei Muster sind in den letzten sechs Monaten dokumentiert:

Template-Merges pro Hersteller-Serie. Wenn eine Gerätefamilie bisher auf mehrere Vorlagen verteilt war, etwa eine Low-Voltage- und eine High-Voltage-Variante, fasst das Projekt diese gelegentlich zusammen. Für die Betriebs-evcc.yaml bedeutet das meist einen geänderten Template-Namen, und der Release-Eintrag dokumentiert das ausdrücklich.

Protokoll-Umstellungen bei Wechselrichter-Anbindungen. Herstellerseitige Firmware-Wechsel (zum Beispiel bei der Goodwe-DT-Serie) führen dazu, dass evcc das Kommunikationsverfahren wechseln muss. Betroffene Setups müssen in der evcc.yaml den aktualisierten Wert beim Feld type pflegen.

Refactoring zentraler HEMS-Parameter. Seltener, aber wirksam sind Umbauten im Energiemanagement-Kern, zum Beispiel bei der Modellierung von Einspeise- und Bezugsleistungs-Grenzen. Diese Änderungen werden lange angekündigt und im Release-Text mit einem aussagekräftigen Titel versehen.

Dazu passt ein Muster aus den GitHub Discussions: Nach größeren Updates erscheint regelmäßig eine Welle von Konfigurations- und Token-Fragen. Zwei Beispiel-Threads: Thread #22961 zum Sponsor-Token-Fallback und Thread #27016 zu Fahrzeug-Token-Refresh. In jedem Fall hilft die oben genannte Vorsichtsregel: Snapshot vor Update, Release-Note vorab überfliegen, Breaking-Change-Markierung ernst nehmen.

Rollback und Snapshot: Wenn ein Update bricht

Rollback ist je nach Installationsweg unterschiedlich aufwendig, aber in allen drei Fällen möglich.

Docker: Über einen gepinnten Image-Tag. Anstelle von evcc/evcc:latest in der docker-compose.yml oder im docker run den exakten Tag der letzten als stabil bekannten Version setzen, zum Beispiel evcc/evcc:0.305.1. Rollback heißt dann: Tag ändern, compose up -d, fertig.

Debian/Ubuntu: apt install evcc=<version> mit exakter Versionsnummer aus apt-cache madison evcc. Danach empfiehlt sich apt-mark hold evcc, damit das Paket nicht beim nächsten apt upgrade automatisch wieder angehoben wird.

Synology: Image-Tag beim Container-Erstellen auf die bekannte Version setzen, analog zum Docker-Weg.

Datenbank-Sicherung als Versicherung: Ein Downgrade der Binärdatei funktioniert nur, wenn die Datenbank zur alten Version passt. Deshalb gilt: Vor einem Update, das einen Datenbank-Schema-Wechsel ankündigt (Release-Note prüfen), eine Kopie von /var/lib/evcc/evcc.db (beziehungsweise /root/.evcc/evcc.db im Container) ablegen. Ohne diese Kopie ist ein Rollback nach Schema-Migration nicht sauber möglich.

Health-Check nach dem Update: Die fünf Minuten, die einen Tag sparen

Unmittelbar nach einem Update ist eine kurze Verifikation sinnvoll, bevor das System unbeaufsichtigt in den Dauerbetrieb geht. Mit dieser Reihenfolge fallen die meisten Regressionen innerhalb von fünf Minuten auf.

Minimal-Check (unter einer Minute)

1. Weboberfläche aufrufen und im Footer die Versionsnummer prüfen. Entspricht sie der erwarteten neuen Version?
2. Dashboard lädt fehlerfrei, Kacheln für Netz, PV, Wallbox und Fahrzeug sind sichtbar und zeigen aktuelle Werte?
3. Keine roten Fehlerbanner oben oder an einzelnen Kacheln?

Standard-Check (fünf Minuten)

1. Wallbox-Anbindung: Status-Kachel zeigt „verbunden“, nicht „Verbindungsaufbau“ oder Zeitüberschreitung. Bei Fahrzeug-Anwesenheit: korrekte Erkennung.
2. Netz- und PV-Zähler: Werte plausibel im Verhältnis zur Tageszeit (bei Sonne positive PV-Leistung, bei Nacht nahe null).
3. Tarif-Provider: Wer einen dynamischen Stromtarif eingebunden hat, prüft die Preiskurve für den kommenden Tag in der Tarif-Kachel. Fehlt sie, ist der API-Token oder die Provider-Schnittstelle nach dem Update zu prüfen.
4. Fahrzeug-Anbindung: Bei eingetragenem Fahrzeug-Account ist der Ladezustand in der UI sichtbar. Nach einem Hersteller-seitigen Token-Refresh (gängig bei mehreren OEM) erscheint gelegentlich eine erneute Authentifizierungs-Aufforderung.
5. Logs: unter Debian sudo journalctl -u evcc --since "10 minutes ago", unter Docker docker logs --since 10m evcc. Keine wiederkehrenden Error-Zeilen?

Wann ein Rollback sinnvoll ist. Wenn Wallbox oder Wechselrichter nach dem Update dauerhaft nicht erreichbar sind und die Logs eine konkrete Fehlerklasse zeigen (Modbus-Timeout, OCPP-Handshake-Fehler, Template-Mismatch), ist der Rückweg auf die letzte stabile Version über die oben beschriebenen Tag-Pinning- oder apt install evcc=<version>-Wege der schnellste Weg zum funktionierenden Betrieb. Die Release-Note der gebrochenen Version ist dann der richtige Ort, um den Breaking-Change-Marker zu prüfen und die eigene evcc.yaml für den nächsten Aktualisierungs-Versuch anzupassen.

Erstinstallation in drei Sätzen

Dieser Ratgeber fokussiert auf Update und Betrieb. Für die Erstinstallation verweisen wir auf die offizielle Dokumentation unter docs.evcc.io/docs/installation, weil die dort gepflegten Schritt-für-Schritt-Anleitungen aktueller sind, als wir es hier spiegeln könnten. Unterschiede auf Patch-Level sind häufig.

Zur Entscheidungshilfe, welchen Weg Sie wählen sollten:

1. Raspberry Pi mit fertigem SD-Image – für Einsteiger ohne Linux-Vorkenntnisse der bequemste Einstieg.
2. Docker auf NAS oder Mini-PC – wenn bereits ein Container-Host im Haushalt läuft, ist das der effizienteste Weg.
3. Debian/Ubuntu via apt – wenn evcc auf einem bestehenden Linux-Server mitlaufen soll und Sie systemd gewohnt sind.
4. Home Assistant Add-on – nur, wenn der Rest des Smart-Home bereits in Home Assistant lebt. Eine eigene Ratgeber-Seite zur Home-Assistant-Integration ist in Vorbereitung.

Die Entscheidungs-Matrix Was wollen Sie als Nächstes? im Hauptratgeber führt Sie über drei Fragen zur passenden Variante.

evcc Sponsor-Token verstehen

evcc ist Open Source und steht unter der MIT-Lizenz zur Verfügung. Der komplette Quellcode liegt öffentlich auf GitHub. Für die Anbindung vieler kommerzieller Wallboxen verlangt das Projekt jedoch einen kostenpflichtigen Sponsor-Token. Das ist ein Finanzierungsmodell, kein technisches DRM: Der Code bleibt offen, aber die Entwicklerinnen und Entwickler machen einen Teil ihrer Arbeit an einer kollektiven Refinanzierung fest.

Wie der Token bezogen wird

Zwei Modelle stehen zur Wahl:

• Monatlich vier US-Dollar über GitHub Sponsors. Solange das Sponsoring aktiv ist, bleibt der Token gültig. Er kann jederzeit gekündigt werden.
• Einmalig 150 US-Dollar. Der damit ausgestellte Token hat laut offizieller Angabe unbegrenzte Gültigkeit.

Der Token wird nach der Bezahlung über sponsor.evcc.io abgerufen und in der evcc-Weboberfläche unter Konfiguration > Sponsoring eingetragen. Danach ist ein Neustart von evcc notwendig.

Welche Funktionen den Token verlangen

Die verbindliche Antwort liefert die Kompatibilitätsliste in der Dokumentation. Dort ist bei jeder Wallbox vermerkt, ob für die Anbindung ein Token erforderlich ist. Grob zusammengefasst:

• Ohne Token: Open-Hardware-Geräte (zum Beispiel offene Box-Varianten), smarte Schaltsteckdosen und die Plugin-Schnittstelle.
• Mit Token: Viele der in Deutschland verbreiteten kommerziellen Wallboxen.

Eine detaillierte, nach Herstellern sortierte Übersicht mit Token-Anforderung pro Modell finden Sie in unserem Ratgeber evcc-kompatible Wallboxen.

Ablauf und Verlängerung

Bei monatlicher Sponsorship läuft der Token, solange die Zahlung läuft. Die Weboberfläche gibt rechtzeitig vor Ablauf eine Warnung aus. Nach Ablauf verweigern die token-pflichtigen Anbindungen den Start. Die grundlegenden Funktionen (PV-Überschussladen mit Open-Hardware-Wallboxen, Visualisierung, MQTT-API) bleiben unberührt.

Neutraler Kontext

Ob das Modell zu Ihnen passt, ist eine Abwägung zwischen einem niedrigen Jahresbeitrag und der Alternative, eine kommerzielle Energiemanagement-Lösung einzusetzen oder evcc auf eine Open-Hardware-Wallbox umzustellen. Wir halten das Modell für transparent dokumentiert und für ein Open-Source-Projekt dieser Größe tragfähig. Eine redaktionelle Empfehlung oder Abwertung ist damit nicht verbunden.

Häufige Fragen zu evcc-Updates und Sponsor-Token