This is the full developer documentation for evcc - smart charging # Introduction evcc optimizes charging your electric vehicle with self-generated solar energy or low-cost electricity tariffs. The software works across manufacturers with hundreds of wallboxes, solar systems, and vehicles. evcc runs locally on a Raspberry Pi or NAS - no cloud required. [Install evcc now](/en/installation) *** ## Explore Features [Section titled “Explore Features”](#explore-features)   ### [Solar Surplus Charging](/en/features/solar-charging) [Charge your car with your own solar power.](/en/features/solar-charging) ### [Dynamic Tariffs](/en/features/dynamic-prices) [Charge when electricity is cheap and green.](/en/features/dynamic-prices) ### [Charge Planner](/en/features/plans) [Ready to go by departure time, at minimal cost.](/en/features/plans) ### [Home Battery](/en/features/battery) [Coordinate charging with your battery storage.](/en/features/battery) ### [Charging Sessions](/en/features/sessions) [Statistics and history of all your charging sessions.](/en/features/sessions) ### [iOS & Android App](/en/features/app) [Keep an eye on your charging from your phone.](/en/features/app) ## Supported Devices & Services [Section titled “Supported Devices & Services”](#supported-devices--services) evcc works across manufacturers with hundreds of devices: ### [Chargers](/en/chargers) [Hundreds of supported wallboxes.](/en/chargers) ### [PV, Battery, Grid, Meter](/en/meters) [Inverters, battery storage, and energy meters.](/en/meters) ### [Vehicles](/en/vehicles) [Charge level and status directly from your car.](/en/vehicles) ### [Smart Switches](/en/smartswitches) [Charge via switchable sockets.](/en/smartswitches) ### [Heating](/en/heating) [Heat pumps and water heaters.](/en/heating) ### [Tariffs & Forecasts](/en/tariffs) [Dynamic prices, solar and CO₂ forecasts.](/en/tariffs) ## Dive Deeper [Section titled “Dive Deeper”](#dive-deeper) Want more? These features and integrations go beyond the basics: * [Load Management](/en/features/loadmanagement): multiple chargers on a limited grid connection * [CO₂-Optimized Charging](/en/features/co2): charge when the grid is greenest * [Dynamic Feed-In](/en/features/dynamic-feedin): factor in variable feed-in rates * [Minimum Charge & Limits](/en/features/limits): quick base charge and charging limits * [External Limit (§ 14a EnWG & § 9 EEG)](/en/external-limit): grid operator requirements * [Notifications](/en/notifications): messages about your charging sessions * [Home Assistant](/en/smarthome/home-assistant): integrate with your smart home * [REST API](/integrations/rest-api) and [MQTT API](/en/integrations/mqtt-api): connect other systems * [MCP Server](/en/integrations/mcp): connect AI assistants * [Sunny Home Manager](/en/integrations/sma-sunny-home-manager): SMA energy management Note evcc comes without any kind of guarantee, and you use the software at your own risk. It is your responsibility to use evcc responsibly - it’s your house fire! ## Meet the Community [Section titled “Meet the Community”](#meet-the-community) * Support, configurations, questions about devices, and general discussion can be found in our [Community Support Forum](https://github.com/evcc-io/evcc/discussions). * We also have a [Slack](https://evcc.io/slack) for development discussion. Looking for more? Check out [Talks, Videos & Blogs](/en/media). # Neue Dokumentation und Blog evcc hat nun eine Dokumentation und dieses Blog und wir möchten euch diese heute etwas näher vorstellen. ## Ein paar Zahlen [Section titled “Ein paar Zahlen”](#ein-paar-zahlen) Am 6.3.2020 hatte [andig](https://github.com/andig/) **evcc** mit dem [ersten Commit](https://github.com/evcc-io/evcc/commit/3c503b333dfc9a1206dd8bcfbfda89d93746c2c6) zum Leben erweckt. Und er hätte sich nicht erträumen können was dieses Projekt bisher für einen Weg genommen hat. Über 1300 Commits später, mit inzwischen [369 Stars](https://github.com/evcc-io/evcc/stargazers), [90 Forks](https://github.com/evcc-io/evcc/network/members), [34 Contributors](https://github.com/evcc-io/evcc/graphs/contributors) und mehr als [70 Releases](https://github.com/evcc-io/evcc/releases) wächst **evcc** immer weiter. Auch die Zahl der Anwender wächst, auch wenn wir hier keine genauen Zahlen haben (und das muss auch nicht sein). Aber das [Forum](https://github.com/evcc-io/evcc/discussions) zählt auch schon fast 450 Diskussionen mit vielen Teilnehmern. Auch in unserem [Entwickler Slack Channel](https://evcc.io/slack) tummeln sich viele Interessierte. ## Neue Dokumentation [Section titled “Neue Dokumentation”](#neue-dokumentation) Um dieser Breite an Personen, vor allem auch hinsichtlich dem jeweiligen technischen Hintergrund, einen besseren Zugang zu \**evcc* zu geben, haben wir begonnen eine neue Dokumentation auf [docs.evcc.io](https://docs.evcc.io/docs/Home) auf Basis von dem Open Source Projekt [Docusaurus](https://docusaurus.io) aufzubauen. Wir haben folgende Bereiche eingerichtet: * **Erste Schritte**: Installation und Konfiguration von **evcc**. * **Anleitungen**: Verschiedene Themen und Häufige Fragen. * **Geräte**: Eine Liste der bekannten, unterstützten Geräte und derer Konfiguration. * **Referenz**: All die (auch technischen) Details und Konfigurationsmöglichkeiten, für diejenidgen die etwas mehr in die Tiefe gehen wollen. Wir würden uns freuen wenn ihr uns hierbei unterstützt. Ob es sich um Korrekturen von Rechtschreibfehlern oder neuen besseren Inhalten handelt, die Dokumentation ist ebenfalls auf Github unter [github.com/evcc-io/docs](https://github.com/evcc-io/docs) zu finden und wir freuen uns über euer Mitwirken! ## Blog [Section titled “Blog”](#blog) Zusätzlich eröffnen wir heute dieses Blog. Hier wird es in unregelmäßigen Abständen verschiedene Inhalte rund um **evcc** und Themen rund um das Laden zu Hause geben. Wir haben ein paar Ideen, lasst euch überraschen. Unser Hauptaugenmerkt bleibt jedoch auf der Entwicklung von **evcc** selbst. Aber einen Blick hinter die Kulissen, ist sicher auch immer wieder für den ein oder anderen interessant :) # Version 0.72 Es hat sich in den letzten Wochen viel getan, und darüber möchten wir heute etwas ausführlicher berichten was es alles in Version 0.72 an Neuem zu entdecken gibt.  ## Einfachere Installation [Section titled “Einfachere Installation”](#einfachere-installation) Der Zugang zu **evcc** erforderte bisher doch einige technische Kenntnisse im Umgang mit dem jeweiligen Betriebssystem. Für Linux (Debian, Ubuntu, Raspberry Pi OS) und macOS gibt es nun eine deutlich vereinfachte Installation. So unterstützt **evcc** nun die Installation über die Paketmanager `apt` unter Linux und [`homebrew`](https://brew.sh) unter macOS. Hierfür haben wir die Installationsanleitungen nochmals überarbeitet und damit die Installation weiter vereinfacht. Schaut doch mal in der [dazugehörigen Dokumentation](/en/installation) vorbei. ## Einfachere Konfiguration [Section titled “Einfachere Konfiguration”](#einfachere-konfiguration) Auch die Einrichtung von **evcc** war bisher noch sehr technisch geprägt. Seien es die Formatierungsvorgaben von [YAML](https://yaml.org), welches die Synthax der Konfigurations vorgibt, oder die Ausgestaltung und Anpassung der Konfiguration der eigenen Geräte in der Konfigurationsdatei. Für den ein oder anderen sind das doch recht hohe Hürden. Aber das Projektk ist noch jung und das Team überschaubar, vor allem wenn man bedenkt dass dies für die Entwickler “nur” ein Hobby ist. Um diese Hürden etwas zu minimieren, führen wir mit dieser neuen Version 0.72 von **evcc** eine neue Funktionalität ein: Die geführte Konfiguration mit `evcc configure`. Mit diesem Kommando lässt sich interaktiv eine funktionierende Konfigurationsdatei für die eigene Installation erstellen! Es gibt sicher hier und da noch einige Probleme und Fehler, aber wir hoffen es ist ein guter erster Schritt in die richtige Richtung. ## Download & Installation [Section titled “Download & Installation”](#download--installation) * [Debian, Ubuntu, Raspberry Pi](/en/installation/linux) * [macOS Homebrew](/en/installation/macos) * [Docker](/en/installation/docker) * [Windows](/en/installation/windows) ## Changelog [Section titled “Changelog”](#changelog) ### Version 0.72 [Section titled “Version 0.72”](#version-072) * [Detaillierte Liste der Änderungen](https://github.com/evcc-io/evcc/releases/tag/0.72) ### Version 0.71 [Section titled “Version 0.71”](#version-071) * [Detaillierte Liste der Änderungen](https://github.com/evcc-io/evcc/releases/tag/0.71) # Version 0.73 Heute gibt es ein kleines Update hauptsächlich mit einigen Fehlerkorrekturen und weiteren Verbesserungen. ## `evcc configure` [Section titled “evcc configure”](#evcc-configure) Das Kommando zur geführten Erstellung einer Konfigurationsdatei und die darunterliegenden Templates hat folgende Verbesserungen erhalten: * Bei einem Ladepunkt kann nun eingestellt werden, ob beim Abstecken des Ladekabels die Lade-Standardeinstellungen wieder hergestellt werden sollen. Mehr dazu in unserer Dokumentation unter `resetOnDisconnect` * Es können nun Fahrzeugspezifische Lade-Standardwerte eingerichtet werden. Interaktiv sind diese mit `evcc configure --advanced` verfügbar. Mehr dazu in der Dokumentation unter `onIdentify` * Geräte mit Modbus erzeugen nun korrekte Konfigurationen * Verbesserter Umgang wenn eine `evcc.yaml` Datei bereits im aktuellen Ordner existiert aber andere Zugriffsrechte hat. ## Standort-Erkennung [Section titled “Standort-Erkennung”](#standort-erkennung) Für einige Fahrzeuge kann **evcc** nun den aktuellen Standort erkennen. Dies wird momentan jedoch noch nicht aktiv verwendet. ## Download & Installation [Section titled “Download & Installation”](#download--installation) * [Debian, Ubuntu, Raspberry Pi](/en/installation/linux) * [macOS Homebrew](/en/installation/macos) * [Docker](/en/installation/docker) * [Windows](/en/installation/windows) ## Changelog [Section titled “Changelog”](#changelog) * [Detaillierte Liste der Änderungen](https://github.com/evcc-io/evcc/releases/tag/0.73) # Version 0.74 Heute gibt es ein kleines Update hauptsächlich mit einigen Fehlerkorrekturen und weiteren Verbesserungen. ## Timer in der UI [Section titled “Timer in der UI”](#timer-in-der-ui) Die Oberfläche zeigt euch nun die im Hintergrund laufenden Timer an:  * Im PV Modus: * Wann wird das Laden unterbrochen * Wann wird mit dem Laden wieder begonnen * 1p3p Phasenumschaltung: * Wann wird auf 3p hochgeschaltet * Wann wird auf 1p heruntergeschaltet Zusätzlich wird auch angezeigt mit wievielen Phasen geladen wird. ## Zielladen [Section titled “Zielladen”](#zielladen)  Die Zielladen Funktionalität ist zurück. Hiermit kann man das EV auf ein bestimmtes Datum und Uhrzeit auf den geewünschten SoC Wert laden. ## Download & Installation [Section titled “Download & Installation”](#download--installation) * [Debian, Ubuntu, Raspberry Pi](/en/installation/linux) * [macOS Homebrew](/en/installation/macos) * [Docker](/en/installation/docker) * [Windows](/en/installation/windows) ## Changelog [Section titled “Changelog”](#changelog) * [Detaillierte Liste der Änderungen](https://github.com/evcc-io/evcc/releases/tag/0.74) # Version 0.76 Heute gibt es zum Jahresende nochmals eine Aktualisierung mit einigen Neuerungen. ## Weitere Fahrzeuge und Wallbox [Section titled “Weitere Fahrzeuge und Wallbox”](#weitere-fahrzeuge-und-wallbox) Es werden nun die Dacia und Smart EQ EVs unterstützt, ebenso die Wallbox Innogy eBox. ## Fehlerkorrekturen [Section titled “Fehlerkorrekturen”](#fehlerkorrekturen) Diese Version enthält eine Reihe von Fehlerkorrekturen und vielen kleinen Verbesserungen. Schaut euch gerne über den Changelog Link unten eine detaillierte Auflistung an. ## Download & Installation [Section titled “Download & Installation”](#download--installation) * [Debian, Ubuntu, Raspberry Pi](/en/installation/linux) * [macOS Homebrew](/en/installation/macos) * [Docker](/en/installation/docker) * [Windows](/en/installation/windows) ## Changelog [Section titled “Changelog”](#changelog) ### Version 0.76 [Section titled “Version 0.76”](#version-076) * [Detaillierte Liste der Änderungen](https://github.com/evcc-io/evcc/releases/tag/0.76) ### Version 0.75 [Section titled “Version 0.75”](#version-075) * [Detaillierte Liste der Änderungen](https://github.com/evcc-io/evcc/releases/tag/0.75) # Version 0.77 Auf den letzten Metern des Jahres 2021 kommt doch nochmals eine Aktualisierung mit ein paar Fehlerkorrekturen. Das Jahr soll ja schließlich positiv enden ;) ## Fehlerkorrekturen [Section titled “Fehlerkorrekturen”](#fehlerkorrekturen) Gegenüber der Version 0.76 haben wir Korrekturen für die Verwendung einiger Geräte und der Handhabung von PV Timern in der UI eingepflegt. Schaut euch gerne über den Changelog Link unten eine detaillierte Auflistung an. ## Download & Installation [Section titled “Download & Installation”](#download--installation) * [Debian, Ubuntu, Raspberry Pi](/en/installation/linux) * [macOS Homebrew](/en/installation/macos) * [Docker](/en/installation/docker) * [Windows](/en/installation/windows) ## Changelog [Section titled “Changelog”](#changelog) * [Detaillierte Liste der Änderungen](https://github.com/evcc-io/evcc/releases/tag/0.77) # Version 0.80 Auch dieses Jahr geht es weiter mit weiteren Aktualisierungen :) Zusätzlich zu den kleineren Updates mit 0.78 und 0.79, gibt es nun auch ein paar größere Änderungen mit der Version 0.80. ## `evcc configure` Verbesserungen [Section titled “evcc configure Verbesserungen”](#evcc-configure-verbesserungen) Wenn man eine Konfiguration mit `evcc configure` erstellt, wird zuerst nach dem eigenen Know How gefragt. So können fortgeschrittene Anwender die Konfiguration in technischen Bereichen etwas genauer einstellen. Dieser Modus ist weiterhin auch über `evcc configure --advanced` direkt verfügbar. Einsteiger empfehlen wir diesen Modus jedoch nicht, da mehr Know-How erforderlich ist. Zustätzlich gibt es weitere Geräte Templates, Korrekturen an bisherigen Templates und weitere Einstellmöglichkeiten. ## Sonnenenergieanteil und Ersparnis [Section titled “Sonnenenergieanteil und Ersparnis”](#sonnenenergieanteil-und-ersparnis)  Das neue Ersparnisfeature zeigt dir an wie viel deines Ladestroms durch selbsproduzierte Sonnenenergie gedeckt werden konnte. Der Prozentwert wird unten rechts in der Ecke angezeigt. Beim Klick darauf bekommst du weitere Details in einem Dialog angezeigt. Dort siehst du neben der Energiemenge auch deinen effektiven Energiepreis und die Gesamtersparnis gegenüber reinem Netzbezug. Hier findest du mehr Informationen zur [Berechnung und Preiskonfiguration](/en/faq#savings-calculation). [Sponsoren](/en/sponsorship) finden in dem neuen Dialog unter dem Dankeschön-Konfetti-Button einen, *\*drumroll\**, Link um unsere neuen evcc Sticker zu bekommen. Ihr seid die Besten. Danke für euren Support! 💚🥳 ## Docker [Section titled “Docker”](#docker) Wer Docker verwendet, kann nun über die Tags `latest` jeweils die aktuelle Version verwenden. Mit dem Tag `nightly` gibt es dann täglich neue Builds, die aber noch nicht so gut getestet sein können. Weitere Informationen zur Docker Installation sind hier zu finden: [Docker, Synology](/en/installation/docker) ## Fehlerkorrekturen [Section titled “Fehlerkorrekturen”](#fehlerkorrekturen) Diese Version enthält natürlich wieder eine Reihe von Fehlerkorrekturen und vielen kleinen Verbesserungen. Schaut euch gerne über den Changelog Link unten eine detaillierte Auflistung an. ## Download & Installation [Section titled “Download & Installation”](#download--installation) * [Debian, Ubuntu, Raspberry Pi](/en/installation/linux) * [macOS Homebrew](/en/installation/macos) * [Docker](/en/installation/docker) * [Windows](/en/installation/windows) ## Changelog [Section titled “Changelog”](#changelog) ### Version 0.80 [Section titled “Version 0.80”](#version-080) * [Detaillierte Liste der Änderungen](https://github.com/evcc-io/evcc/releases/tag/0.80) ### Version 0.79 [Section titled “Version 0.79”](#version-079) * [Detaillierte Liste der Änderungen](https://github.com/evcc-io/evcc/releases/tag/0.79) ### Version 0.78 [Section titled “Version 0.78”](#version-078) * [Detaillierte Liste der Änderungen](https://github.com/evcc-io/evcc/releases/tag/0.78) # evcc im pv magazin Unser Core Entwickler [Andreas Linde](https://twitter.com/DerAndereAndi) und unser Anwender [Tjarko Tjaden](https://twitter.com/TjarkoTjaden) haben dem pv magazin Deutschland ein Interview zum Thema [Open-Source-Lademanager Schnittstellen zu Wallbox und Photovoltaik-Anlage meistern](https://www.pv-magazine.de/2022/01/14/mit-open-source-lademanager-schnittstellen-zu-wallbox-und-photovoltaik-anlage-meistern/) gegeben. [](https://www.pv-magazine.de/2022/01/14/mit-open-source-lademanager-schnittstellen-zu-wallbox-und-photovoltaik-anlage-meistern/) # Phase handling, Templates and Lithuanian It’s been a few months since the last blog post. So it’s time to give you a short summary and an overview of what has happened at evcc in the last eleven releases (v0.81 to v0.91). ## New supported devices [Section titled “New supported devices”](#new-supported-devices) The list of hardware supported by evcc is growing steadily. ### Charging stations 🔌 [Section titled “Charging stations 🔌”](#charging-stations-) We have added some wallbox integrations. Since evcc now also supports the very popular [Bender Controller](https://github.com/evcc-io/evcc/pull/3103) we were able to significantly expand the portfolie of supported devices. Here are the manufacturers that have been added since the beginning of the year: Alphatec, Ebee, Ensto, Garo, HardyBarth, Innogy, Juice, Mennekes, OpenWB Pro, Optec, PC Electric, SmartWB, TechniSat, Tapo Smarthome, Ubitricity Vestel, Webasto. [(All charging stations)](/en/chargers) ### Vehicles 🚗 🛵 [Section titled “Vehicles 🚗 🛵”](#vehicles--) Audi (e-tron), Cupra, Jaguar, Landrover, Mercedes, Silence S01, Smart. [(All vehicles)](/en/vehicles) ### Inverters ☀️ 🔋 [Section titled “Inverters ☀️ 🔋”](#inverters-️-) SMA (Data Manager M Lite), Shelly (1PM, 3EM), Siemens (PAC 2200), OpenEMS, TQ. [(All meters)](/en/meters) ### Grid meters 📟 [Section titled “Grid meters 📟”](#grid-meters-) SMA (Data Manager M Lite), Shelly (1PM, 3EM), Siemens (PAC 2200), OpenEMS, TQ. [(All meters)](/en/meters) ### RFID Support 🪪 [Section titled “RFID Support 🪪”](#rfid-support-) The wallboxes from Easee and Warp can now also use evcc’s [RFID function for vehicle detection](/en/features/vehicle). ## Improved phase handling (1P/3P) [Section titled “Improved phase handling (1P/3P)”](#improved-phase-handling-1p3p) The first version of phase switching for supported wallboxes has been available in evcc since mid last year. We were able to gain some experience and based on this we did [a major redesign](https://github.com/evcc-io/evcc/pull/2613) of the mechanism in February. This makes phase switching much more reliable and also behaves better in situations with unknown or implausible configuration or measurement values. ## Templates and documentation [Section titled “Templates and documentation”](#templates-and-documentation) [In December](/en/blog/2021/12/12/version-0-73#evcc-configure) we laid the foundations for a simpler initial setup with the CLI setup wizard `evcc configure`. The configuration syntax of evcc is very flexible and powerful. For example, not yet officially supported devices can often be connected purely by configuration if you know the corresponding Modbus fields and JSON structures of the interface. In the now archived `evcc-io/config` repository we had collected example configurations that you could copy and paste into your own configuration. Together with the command line wizard we introduced the concept of **templates**. Templates allow us to encapsulate boilerplate and internal device knowledge (protocols, address, data types, field names) in a clean way. The following example for setting up a Solarlog grid meter illustrates the change quite well: Before: ```yaml meters: - name: my_solarlog type: custom power: source: calc add: - source: modbus uri: 192.168.0.77:502 id: 1 register: address: 3502 type: input decode: uint32s scale: -1 - source: modbus uri: 192.168.0.77:502 id: 1 register: address: 3518 type: input decode: uint32s ``` After: ```yaml meters: - name: my_solarlog type: template template: solarlog usage: grid host: 192.168.0.77 ``` The user now only needs to know the hostname or IP address of his Solarlog instance and enter it - protocol and data structure are encapsulated in the `solarlog` template. Additionally, templates also receive a structured description of all required and optional parameters, as well as default values and localized help texts. [Since March](https://github.com/evcc-io/docs/pull/92) we have converted the [device documentation at docs.evcc.io](/en/chargers) to templates. The previous syntaxes still work of course. Since future features like the web-based setup (yes, that will come 😄) are based on `type: template` we recommend that you convert your existing configurations to the new format already now. ## New localization: Lithuanian 🇱🇹 [Section titled “New localization: Lithuanian 🇱🇹”](#new-localization-lithuanian-) With v0.91 we received a new localization. The evcc UI is now also available in Lithuanian. This is now the fourth language in addition to German, English and Italian. Many thanks [RTTTC](https://github.com/RTTTC) 💚. Since our language knowledge is relatively limited, we are always grateful for translation contributions. There is currently no documentation for this, but if you are interested, just take a look at [RTTC’s Pull Request](https://github.com/evcc-io/evcc/pull/3205). ## What’s next? [Section titled “What’s next?”](#whats-next) Some of you may have already seen it. With the next release evcc will get a completely redesigned user interface. This is already available in the current nightly builds and you can find [here](https://github.com/evcc-io/evcc/discussions/3149) and [here](https://github.com/evcc-io/evcc/pull/2889) information about the development process. But more about that in the next blog article. ## Bug fixes [Section titled “Bug fixes”](#bug-fixes) The last versions contained a number of bug fixes and many small improvements. You can find a detailed list via the changelog link below. ## Changelogs [Section titled “Changelogs”](#changelogs) Here you can find more details about the latest changes: * [Version 0.91](https://github.com/evcc-io/evcc/releases/tag/0.91) * [Version 0.90](https://github.com/evcc-io/evcc/releases/tag/0.90) * [Version 0.89](https://github.com/evcc-io/evcc/releases/tag/0.89) * [Version 0.88](https://github.com/evcc-io/evcc/releases/tag/0.88) * [Version 0.87](https://github.com/evcc-io/evcc/releases/tag/0.87) * [Version 0.86](https://github.com/evcc-io/evcc/releases/tag/0.86) * [Version 0.85](https://github.com/evcc-io/evcc/releases/tag/0.85) * [Version 0.84](https://github.com/evcc-io/evcc/releases/tag/0.84) * [Version 0.83](https://github.com/evcc-io/evcc/releases/tag/0.83) * [Version 0.82](https://github.com/evcc-io/evcc/releases/tag/0.82) * [Version 0.81](https://github.com/evcc-io/evcc/releases/tag/0.81) # Sponsoring und Umzüge Es sind schon wieder siebzehn Releases seit unserem letzten Update hier im Blog vergangen. Wie immer ist eine Menge passiert. Einige Bugfixes, aber auch viele neue Integrationen und Funktionen sind dazu gekommen. Zu unseren Highlights der letzten Monate in einem späteren Blogartikel mehr. ## 🌱 Nachhaltige Open Source Entwicklung [Section titled “🌱 Nachhaltige Open Source Entwicklung”](#-nachhaltige-open-source-entwicklung) evcc hat als kleines Hobbyprojekt angefangen, weil wir unzufrieden mit den bestehenden Lösungen für PV-Überschussladen waren und uns etwas Besseres bauen wollten. Inzwischen macht evcc aber nicht nur unser privates Sonnenladen leichter. Es gibt vermutlich mehrere tausend Installationen, die morgens das Auto wecken, sobald die Sonne auf die heimische PV-Anlage scheint. Der Gedanke macht uns sehr froh. Genaue Zahlen über unsere Nutzerbasis haben wir nicht. Wir mögen Datensparsamkeit und haben daher auch keine Ambition ein allgemeines Tracking in unsere Webseite oder die Applikation einzubauen. Dennoch können wir anhand von Zahlen aus Docker (bisher >1 Mio. Pulls) und Cloudsmith (aktuell \~4.5k Paketdownloads pro Tag) ziemlich gut erkennen, dass sich Viele im Alltag auf evcc verlassen. Damit wir das Projekt mit ausreichendem Fokus pflegen und weiterentwickeln können, ist nachhaltige Finanzierung ein wichtiges Thema. Hinter evcc steckt kein großes Unternehmen, kein Wallboxhersteller und wir haben auch keine Lust auf das Startupspiel mit Investoren. Aktuell ist evcc ein Projekt, was wir in unserer Freizeit vorantreiben. Wir sind überzeugt davon, dass es eine gute Idee ist, direkt für euch, die Nutzer zu arbeiten und unabhängig von anderen Verpflichtungen und Zwängen zu sein. Mit **GitHub’s Sponsoring** haben wir eine sehr leichtgewichtige und einfache Lösung gefunden, um finanzielle Unterstützung direkt von Nutzern entgegennehmen zu können. Zudem haben wir dadurch die Möglichkeit, **einige Funktionen exklusiv für Sponsoren** bereitzustellen. Momentan sind dies bestimmte Wallbox-Typen und die Telemetry Funktion, wir können uns aber durchaus vorstellen dieses Modell in Zukunft noch anzupassen. ## 💚 Danke an alle Sponsoren [Section titled “💚 Danke an alle Sponsoren”](#-danke-an-alle-sponsoren) Aktuell haben wir **über 1.500 Sponsoren** 🥳, die einen monatlichen Beitrag von mindestens $2 zahlen. Das ist ziemlich cool, ein großer Vertrauensbeweis und bestärkt uns darin weiter viel Zeit in das Projekt zu investieren. Zusätzlich zum Sponsortoken um Funktionen freizuschalten schicken wir allen Unterstützern auch gerne Sticker. Damit könnt ihr Laptop, Raspberry, Wallbox oder euer Ladeequipment verschönern. Den Link zum Stickerformular findet ihr in der evcc UI unten rechts beim Klick auf das Sonnensymbol. | [@evcc\_io](https://twitter.com/evcc_io/status/1489667714411114502) | [@Ein\_Klimawender](https://twitter.com/Ein_Klimawender/status/1589844295992819712) | [@frd9900](https://twitter.com/frd9900/status/1591416016848162816) | | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | [](https://twitter.com/evcc_io/status/1489667714411114502) | [](https://twitter.com/Ein_Klimawender/status/1589844295992819712) | [](https://twitter.com/frd9900/status/1591416016848162816) | | [@ABBolle](https://github.com/evcc-io/evcc/discussions/4446#discussioncomment-4069333) | [@rediculum](https://github.com/evcc-io/evcc/discussions/4446#discussion-4393578) | [@123aerox](https://github.com/evcc-io/evcc/discussions/4446#discussioncomment-4013806) | | [](https://github.com/evcc-io/evcc/discussions/4446#discussioncomment-4069333) | [](https://github.com/evcc-io/evcc/discussions/4446#discussion-4393578) | [](https://github.com/evcc-io/evcc/discussions/4446#discussioncomment-4013806) | ## 📮 Einmal-Sponsoring [Section titled “📮 Einmal-Sponsoring”](#-einmal-sponsoring) Wir haben schon mehrfach das Feedback bekommen, dass Nutzer Bauchschmerzen mit monatlichen Zahlungen haben und sich eine Möglichkeit der Einmalzahlung wünschen, um ein Sponsortoken zu erhalten. Dies ist nun möglich. Auf der [GitHub Sponsoring Seite](https://github.com/sponsors/evcc-io?frequency=one-time) gibt es jetzt neben den monatlichen auch One-time-Stufen. Folgende Preisstufen haben wir uns überlegt: * **🌱 $100 - Nachhaltige Entwicklung**\ Du trägst dazu bei, dass wir auch zukünftig viel Energie in die Weiterentwicklung von evcc investieren können. Außerdem bekommst du **ein unbefristetes Sponsortoken**, mit dem du alle evcc Funktionen nutzen kannst. * ~~**☀️ $150 - Friends & Family**\ Du bekommst **drei unbefristete Sponsortoken**. Eins für dich und zwei weitere, die du an Freunde oder Familie weitergeben kannst. Du wirst als Sponsor auf [evcc.io](https://evcc.io) erwähnt.~~ * **🚛 $1.000 - Multiplikator**\ Für Elektriker und Solarteure. Du möchtest evcc für mehrere Kunde einsetzen? Schreib uns an und wir finden eine gute Lösung. Die Ausstellung für die unbefristeten Sponsortoken funktioniert genauso wie der aktuelle Prozess über [sponsor.evcc.io](https://sponsor.evcc.io). Einziger Unterschied ist, dass das Token nicht abläuft. Update Wir haben die Sponsorstufen 2026 angepasst. Mehr dazu in unserem [aktuellen Blog-Post](/en/blog/2026/01/01/highlights-browser-config-ready#sponsoring). ## 🎟️ Contributor-Token [Section titled “🎟️ Contributor-Token”](#️-contributor-token) Community-Mitglieder, die über GitHub PRs zu substanziell zu evcc beigetragen haben, können auch ein freies Token erhalten. Wir sind immer froh über Bugfixes, brauchen aber auch dringend Unterstützung im Bereich Dokumentation und [Übersetzung](https://github.com/evcc-io/evcc/discussions/5218). Was genau eine substantielle Contribution ist, haben wir nicht klar geregelt. Einen Kommafehler rausmachen qualifiziert noch nicht, das Beheben eines fiesen Bugs reicht aber definitiv. Schreib uns einfach eine Mail an mit Verweis auf deinen GitHub Nutzernamen. ## 🚚 GitHub Sponsoring zieht um [Section titled “🚚 GitHub Sponsoring zieht um”](#-github-sponsoring-zieht-um) Aktuell läuft das GitHub Sponsoring über den Account von [@andig](https://github.com/andig), dem Gründer von evcc. Der Betrag, der nach Ausgaben (Infrastruktur, Sticker, …) im Monat übrig bleibt, wird über einen Verteilungsschlüssel an alle drei Mitglieder vom Core-Team verteilt. Um diesen Prozess transparenter zu machen, ziehen wir unser GitHub Sponsoring jetzt auf die [evcc-io Organisation](https://github.com/sponsors/evcc-io) um. Wenn ihr bereits Sponsor seid, müsst ihr nichts verändern. Euer Token läuft wie gewohnt weiter und auch der Beitrag findet den Weg an alle Teammitglieder. Wir haben aber alle Links zum Sponsoring auf die Organisation umgestellt. Einmalzahlungen gibt es auch nur dort. [](https://github.com/sponsors/evcc-io) ## 🐳 Docker Image zieht um [Section titled “🐳 Docker Image zieht um”](#-docker-image-zieht-um) Im gleichen Zug ziehen wir auch unsere Docker Images um. Bislang wurden die Pakete unter `andig/evcc` veröffentlicht. Nun findet ihr die offiziellen Versionen unter `evcc/evcc`. An dieser Stelle noch einmal Danke an das Docker Team, die evcc als [Docker-Sponsored Open-Source-Projekt](https://www.docker.com/community/open-source/application/) qualifiziert haben. Dadurch bekommen wir kostenfreien Zugang zu Team-Funktionen von Docker Hub. [](https://hub.docker.com/u/evcc) *** **Danke für eure Unterstützung!** evcc Core Team\ [@andig](https://github.com/andig), [@premultiply](https://github.com/premultiply) und [@naltatis](https://github.com/naltatis) # Version 0.111  Pünktlich am 11.1. haben wir mit dem Release 0.111 wieder einige neue Funktionen am Start die wir euch hier kurz vorstellen möchten. ## 🧞‍♂️ Neuer Ladeplaner: Erneuerbaren Netzstrom nutzen [Section titled “🧞‍♂️ Neuer Ladeplaner: Erneuerbaren Netzstrom nutzen”](#️-neuer-ladeplaner-erneuerbaren-netzstrom-nutzen) Die Zielladenfunktion gibt es in evcc schon seit einiger Zeit. Damit kannst du eine Zielzeit definieren zu der das verbundene Fahrzeug einen bestimmten Ladestand erreichen soll. Die Funktion ist bspw. praktisch um den Wagen vor längeren Fahrten pünktlich zur Abfahrt aufzuladen.  Die bisherige Ladestrategie war relativ simpel: Die Ladung wird möglichst spät gestartet, sodass der Akku pünktlich zur Abfahrt den gewünschten Stand erreicht hat. Das schont den Akku da er nicht lange auf hohen Ladeständen geparkt wird. Mit diesem Release wird der Ladeplaner intelligenter und bezieht dynamische Energiepreise und CO₂-Daten mit ein. Damit wird die Ladung auf Zeitfenster geplant in denen besonders viel erneuerbarer Strom im Netz ist. Das spart Geld, entlastet das Stromnetz und reduziert den Bedarf an fossilien Energieträgern. ### 📈 Börsenpreise mit awattar und Tibber [Section titled “📈 Börsenpreise mit awattar und Tibber”](#-börsenpreise-mit-awattar-und-tibber) Die stundenabhängigen Tarife von awattar und Tibber haben wir schon länger angebunden. Bislang hatten wir aber nur eine einfache Steuerung, die das Laden unter einem vorher zu konfigurierenden Strompreis freigibt (`cheap`). Jetzt werden die stündlichen Preise auch in der Ladeplanung verwendet und das Auto lädt dann wenn der Netzstrom besonders günstig ist. Konfiguration für awattar ```yaml tariffs: grid: type: template template: awattar region: de # or at ``` Konfiguration für Tibber ```yaml tariffs: grid: type: template template: tibber token: "476...963a4" # access token ``` ### 📊 Manuelle Zeittarife [Section titled “📊 Manuelle Zeittarife”](#-manuelle-zeittarife) Es ist nun auch möglich Zeittarife zu hinterlegen. Hier eine Beispielkonfiguration für günstige Energie zu Nachtzeiten und noch günstigere Energie am Wochenende: ```yaml tariffs: grid: type: fixed price: 0.294 # EUR/kWh zones: - days: Mo-Fr hours: 2-5 price: 0.2 # EUR/kWh - days: Sa,So price: 0.15 # EUR/kWh ``` Auch diese Preisdaten fließen in den neuen Planungsalgorithmus mit ein. ### 🌱 CO₂-Daten von GrünStromIndex und ElectricityMap [Section titled “🌱 CO₂-Daten von GrünStromIndex und ElectricityMap”](#-co-daten-von-grünstromindex-und-electricitymap) Wer keinen dynamischen Stromtarif hat kann dennoch klimaschonen Laden. Dafür binden wir jetzt CO₂-Daten ein. Aktuell haben wir zwei Quellen implementiert. Wir sind aber offen für weitere Vorschläge. [GrünStromIndex](https://gruenstromindex.de) liefert regionale Vorhersagen über die Sauberkeit des Netzstroms für Deutschland. Du musst lediglich deine Postleitzahl hinterlegen. ```yaml planner: type: template template: grünstromindex zip: 12349 ``` [Electricity Map](https://app.electricitymaps.com/map) liefert weltweite Vorhersagen. Für die Nutzung in evcc benötigt Ihr ein Token und den URL Präfix. Diese Daten bekommst du mit dem [kostenlosen Account im API portal](https://api-portal.electricitymaps.com/). ```yaml planner: type: template template: electricitymaps uri: https://api-access.electricitymaps.com/2w...1g/ token: Rp...D2 zone: DE ``` ## Ausblick [Section titled “Ausblick”](#ausblick) Für eines der nächsten Releases arbeiten wir an einer visuellen Aufbereitung des Ladeplans. Dann kannst du auch die vom Algorithmus errechneten Zeitfenster und die konkrete Kosten- oder CO₂ Ersparnis sehen. ## Weitere neue Funktionen [Section titled “Weitere neue Funktionen”](#weitere-neue-funktionen) Dieses Release enthält neben den üblichen kleinen Verbessungen und Bugfixes auch noch ein paar weitere neue Funktionen: * 🔋🪫 Bessere Unterstützung von mehreren Hausakkus [#5598](https://github.com/evcc-io/evcc/pull/5598) * 🌞 Unterstützung für FoxESS [#5721](https://github.com/evcc-io/evcc/pull/5721) * 🔌 Unterstützung für den Tesla Wall Connector 3 [#5341](https://github.com/evcc-io/evcc/pull/5341) * 🚙 Unterstützung für Volvo Fahrzeuge [#5681](https://github.com/evcc-io/evcc/pull/5681) * 🏳️‍🌈 Drei neue UI Sprachen **Danke für eure Unterstützung!**\ evcc Core Team\ [@andig](https://github.com/andig), [@premultiply](https://github.com/premultiply) und [@naltatis](https://github.com/naltatis) # evcc auf dem 19. Linux Infotag [](https://www.luga.de/static/LIT-2023/) Ende April fand, nach einer langen Coronapause, der [19. Linux Infotag](https://www.luga.de/static/LIT-2023/) statt. Der Infotag ist eine Open-Source-Community-Veranstaltung, die von der [Linux User Group Augsburg e.V. (LUGA)](https://www.luga.de/) organisiert wird. ## Video-Aufzeichnung ist jetzt verfügbar [Section titled “Video-Aufzeichnung ist jetzt verfügbar”](#video-aufzeichnung-ist-jetzt-verfügbar) Neben vielen anderen spannenden Themen hatten wir dieses Jahr die Möglichkeit unser Projekt vorzustellen. Inzwischen ist auch die Video-Aufzeichnung verfügbar. [](https://www.youtube.com/watch?v=qN8JwBWOlzw) [YouTube: Open Source Sonne tanken - Wallboxen mit evcc smarter machen](https://www.youtube.com/watch?v=qN8JwBWOlzw) Neben der allgemeinen Einführung in das Thema E-Autos mit eigenem Sonnenstrom laden ging es auch um smartes Netzladen und ich habe Einblicke in den Entwicklungsprozess und unser Finanzierungsmodell gegeben. Schau also gerne mal rein. Die Folien zum Talk findet ihr auf [Speaker Deck.](https://speakerdeck.com/naltatis/open-source-sonne-tanken-wallboxen-mit-evcc-smarter-machen) 👇 [](https://speakerdeck.com/naltatis/open-source-sonne-tanken-wallboxen-mit-evcc-smarter-machen) # Feature Highlights 10/2023 Since the last blog post, a lot has happened. We have added many new features and fixed some bugs. In this article we will highlight some of the new features. ## Charging planner visualization [Section titled “Charging planner visualization”](#charging-planner-visualization) The charging planner has been around for a while at evcc. You specify when your vehicle should have a desired state of charge and evcc finds the best time slots. Since a few releases the algorithm is no longer a black box, as we visualize the planning result. [](/_astro/chargingplan.CTuYWECo.mp4) How does the algorithm work? 5. Surplus solar energy is prioritized 6. Times with cheap grid electricity (if [dynamic electricity tariff](/en/features/dynamic-prices) exists) 7. Times with clean grid electricity (if [CO₂ interface](/en/features/co2) is configured) 8. Time windows shortly before departure **Outlook:** We are currently experimenting with PV forecast data from [Solcast](https://solcast.com/). This allows the algorithm to make even better decisions. For example, if the charging target is during the day, it may make sense not to charge the vehicle completely with cheap night-time electricity, but to leave room for surplus energy during the day. ## UI adjustable minimum charge [Section titled “UI adjustable minimum charge”](#ui-adjustable-minimum-charge) The minimum charge function has been around at evcc for ages. It is helpful if you come home with only a few percent and want to make sure you always have enough range for an unexpected event. Until now, it could only be set via the configuration file or via API. Now you can also do this via the UI under **Plan** → **Arrival** → **Min. charge %**. The settings are stored per vehicle and are retained even after a restart or update. [](/_astro/minsoc.DKb_4AD2.mp4) ## Smart grid charging [Section titled “Smart grid charging”](#smart-grid-charging) When your own PV surplus is not enough, you can also use grid electricity when it is particularly cheap or clean. If you click on the grid electricity price or CO₂ emissions in the energy flow diagram, the **Smart Grid Charging** dialog opens. There you can set a threshold for the price or CO₂ emissions. If this value is exceeded, evcc temporarily all PV mode loadpoints to fast charging. [](/_astro/dynamicprices.D9KAR9F1.mp4) Prerequisite for this function is that you have configured either a dynamic electricity price or a CO₂ integration. Another small enhancement is that with most dynamic electricity prices you now have the option to correct the price values from the API with **percentage or fixed charges** (`charges` / `tax`). Tibber and Octopus Energy (UK) already provide values including charges. With Awattar, Nordpool Estonia and Energinet you can now add these. By the way: If you have a dynamic electricity tariff that is not yet supported, but offers an API, please open a GitHub issue. ## Battery settings [Section titled “Battery settings”](#battery-settings) A huge advantage that evcc has over other surplus charging solutions is the integration with the home battery. The configuration value [`prioritySoc`](/en/features/battery) can be used to control whether surplus solar energy should be **charged into the home battery or the vehicle** first. In general, evcc tries to prevent the home battery from being unloaded into the vehicle battery in PV mode in order to avoid unnecessary conversion losses. However, with the value [`bufferSoc`](/en/features/battery) you can consciously **dedicate a portion of the home battery to support charging**. You can also set the charging process to start automatically as soon as the battery has reached a certain state of charge ([`bufferStartSoc`](/en/features/battery)). The automatic charging starts even if the sun is not shining. [](/_astro/batterysettings.Cup5vB9Y.mp4) ## Solar %, price, CO₂ per charging session [Section titled “Solar %, price, CO₂ per charging session”](#solar--price-co-per-charging-session) We also have something for the friends of data analysis. We now record the share of own solar energy (in %), the price (total and per kWh), the charging time and the average CO₂ emissions per charging session. You can switch between these values directly at the charging session. [](/_astro/sessionvalues.CBIv2fiE.mp4) ## New calculation of solar share [Section titled “New calculation of solar share”](#new-calculation-of-solar-share) If you have noticed that the share of solar energy has decreased slightly since one of the last versions, this is due to our new calculation. Until now, evcc has always distributed the ratio of grid and own energy evenly between house consumption and charging sessions. We have now switched to a new model in which the house consumption first gets the green electricity and the remaining mix goes to the charging sessions. Thanks to [@MarkusGH](https://github.com/MarkusGH) for the implementation. You can find more details about the model [in the documentation](/en/faq#savings-calculation).  ## Charging sessions overview [Section titled “Charging sessions overview”](#charging-sessions-overview) The new values have of course also found their way into the overview of the charging sessions. Depending on the configuration, prices and CO₂ emissions can now also be seen here. In addition, we have completely redesigned the display and chosen a **compact table display on a monthly basis**. It can be **filtered by charging point and vehicle**. If you need even more flexibility here, you can of course also use the CSV export or get the raw data directly via InfluxDB or MQTT. [](/_astro/chargingsessions.7sDjdbZI.mp4) ## Prioritization of charging points and vehicles [Section titled “Prioritization of charging points and vehicles”](#prioritization-of-charging-points-and-vehicles) If you have multiple charging points, you can use the [`priority`](/en/reference/configuration/loadpoints#priority) setting to specify which one should be preferred. You can also make the prioritization dependent on the detected vehicle or control it via API. There is currently no configuration via the UI. The prioritization function is also helpful if you use evcc to control other consumers, for example [a heating rod or heat pump connected via the plugin interface](https://github.com/evcc-io/evcc/pull/9393). This way you can control them so that they only run when the car is not charging (enough). ## What’s next? [Section titled “What’s next?”](#whats-next) Our [backlog](https://github.com/evcc-io/evcc/issues?q=is%3Aopen+is%3Aissue+label%3Abacklog) is well filled. These are the next big topics we want to tackle: **Config UI:** All prerequisites are now met. Currently, vehicles can already be created in 🧪 experimental mode and the jump to network, PV or battery configuration is not far away. There is still a lot to do here, but the light at the end of the tunnel is visible. **Better planning:** As mentioned above, we are working on integrating good **PV forecasts** into the planning algorithm and the UI. We also have a concept for supporting **multiple charging plans**. **Mode revision:** evcc started as an application for PV surplus charging. In the meantime, the interaction with the home battery is also playing a major role. The topic of **grid-friendly charging** based on dynamic electricity tariffs or CO₂ emissions is also gaining momentum. Therefore, we will revise our charging modes (currently PV and Min+PV) and create more flexibility here. ## Further new features [Section titled “Further new features”](#further-new-features) This was a flyover at high level and from an end user perspective. Of course, there is also a lot of work going on under the hood. * 🔌 Support for additional chargers from 22 new manufacturers * 🌞🔋📟 Support for meter, PV and battery systems from 36 new manufacturers * 🇬🇧 Website and documentation in English language. Thanks [duckfullstop](https://github.com/duckfullstop) & [carygravel](https://github.com/carygravel) 💚 If you want even more details, you are welcome to go through the [release notes](https://github.com/evcc-io/evcc/releases) of the last 49(!) releases since the beginning of the year. **Thanks for your support of evcc!**\ evcc Core Team\ [@andig](https://github.com/andig), [@premultiply](https://github.com/premultiply) and [@naltatis](https://github.com/naltatis) # v0.124 - New Tesla Integration  The days are getting longer and solar charging is starting to be fun again. A good time for a short update on the latest developments at evcc. ## New Tesla Integration [Section titled “New Tesla Integration”](#new-tesla-integration) In [October](https://www.notateslaapp.com/news/1653/tesla-creates-official-apis-for-third-party-services-to-start-charging-for-usage) Tesla introduced a new [official API](https://developer.tesla.com/docs/fleet-api). In addition, they announced that the old, [unofficial API](https://www.teslaapi.io) will be shut down at the beginning of 2024. ### What does this mean for me? [Section titled “What does this mean for me?”](#what-does-this-mean-for-me) To use the new API, you need to make two adjustments to the `evcc.yaml`: 1. **New template name:** Since the old API still works for some users today, we have decided to offer both implementations in parallel for the time being. Change the template name from `tesla` to `tesla-command` to use the new API. 2. **Generate new tokens:** With the new API it is now possible to generate the required `accessToken` and `refreshToken` directly in the browser. For this we have provided a small website at [tesla.evcc.io](https://tesla.evcc.io). The configuration should then look like this: ```yaml vehicles: - name: mytesla type: template template: tesla-command # change `tesla` to `tesla-command` accessToken: ... # generetad by tesla.evcc.io refreshToken: ... # generetad by tesla.evcc.io ... ``` The tokens generated via [tesla.evcc.io](https://tesla.evcc.io) can **only be used with the official evcc builds** (stable & nightly). The reason for this is that the tokens from Tesla’s new Developer API are always bound to a 3rd-party app. You can of course still build evcc yourself. However, you will need your own Tesla Developer Account and have to generate the tokens yourself. More details can be found in the corresponding [Pull Request](https://github.com/evcc-io/evcc/pull/10802). ### Privacy & Security [Section titled “Privacy & Security”](#privacy--security) As with the old API, the communication for data retrieval (charge level, status, …) and control (wake up) runs directly between your local evcc instance and the Tesla infrastructure. Only the token generation runs once via our website. Tokens are not stored, but only displayed to you in the browser. For an extended control of the vehicle (start and stop charging directly at the vehicle) an additional signed request to Tesla is required. Today this affects the users of a Tesla Wall Connector. Since we cannot and may not pack our private 3rd party app key into the evcc binary, we will probably provide our [own service](https://github.com/evcc-io/evcc/pull/11893) for this application, which signs these requests and forwards them to Tesla. But more on that in a later release. ### Costs [Section titled “Costs”](#costs) Tesla is currently offering the new API [free of charge](https://developer.tesla.com/docs/fleet-api#membership-tiers). However, they have already announced that they will charge fees for using the API in the future. Unfortunately, we do not yet know how open source friendly this model will be. It’s quite possible that we won’t be able to offer token generation for free in the future. We may link it to the existing evcc sponsorship model. But more on that when there is new information from Tesla. ## Active Battery Control [Section titled “Active Battery Control”](#active-battery-control) A big new feature that comes with the Christmas release is the active battery control. This function is no longer marked as experimental. In addition, some new supported battery inverters have been added in recent weeks. In the documentation you can now see [if your inverter is supported](/en/meters#features). ### Passive Control [Section titled “Passive Control”](#passive-control) Passive battery control has been available in evcc for some time now. Here evcc regulates the solar charging so that the house battery is not discharged unintentionally. Last year we introduced a [configuration dialog](/en/blog/2023/10/05/feature-highlights-10-2023#battery-settings) where you can set the priority between vehicle and house battery charging. This model works very well for solar charging. evcc knows the current state of charge of the house battery and only regulates the charging power of the vehicle. However, this mechanism does not work for fast charging. An active battery control is required for this. ### Prevent discharge during fast charging [Section titled “Prevent discharge during fast charging”](#prevent-discharge-during-fast-charging) By default, the house battery tries to cover the entire energy consumption of the house (including charging stations). Depending on the current electricity price or expected PV generation, however, it may be desirable to obtain the energy for **fast vehicle charging** directly from the grid and not from the house battery. This way the collected solar energy remains in the house battery and can be used for the house consumption at night, for example. This is our first use case for active battery control. If your inverter supports this feature, a corresponding option will appear in the battery settings dialog.  When this option is active, the house battery is put into a lock mode during fast charging. In this time it is neither discharged nor charged. This lock is also active during [scheduled charging](/en/blog/2023/10/05/feature-highlights-10-2023#charging-planner-visualization) and [smart grid charging](/en/blog/2023/10/05/feature-highlights-10-2023#smart-grid-charging). ### Next step: Charging the battery with cheap grid power [Section titled “Next step: Charging the battery with cheap grid power”](#next-step-charging-the-battery-with-cheap-grid-power) The next stage of development for active battery control is the possibility to charge the house battery with cheap grid power. This is especially interesting for users of dynamic electricity tariffs on darker days. The goal here is to fill the house battery with energy from the grid during low price phases and then use this energy in-house during high price phases. We have already implemented the necessary hardware integrations. Therefore we expect this feature to be available in one of the next releases. ## Update: Migration to browser configuration [Section titled “Update: Migration to browser configuration”](#update-migration-to-browser-configuration) evcc is a very flexible and powerful system for your own energy optimization. Our biggest challenge is still to combine this flexibility with an easy setup process. In the last months we have made great progress in the area of configuration. Our goal is to enable a pure browser-based commissioning, without `evcc.yaml`. If you have activated the option “Show experimental UI features” in the settings dialog, you can see our current development progress under ”🧪 Device Configuration”. Currently you can add and edit vehicles, grid meters, PV and battery systems there. Charging stations and tariffs will follow in the next iteration. Even though this is still a “work in progress”, we look forward to your feedback.  ## Small improvements and bug fixes [Section titled “Small improvements and bug fixes”](#small-improvements-and-bug-fixes) As always, this release also contains a number of smaller improvements and bug fixes. For more details, have a look at the [Release Notes](https://github.com/evcc-io/evcc/releases/tag/0.124.0). All the best\ your evcc core team # Community: Arne from Gifhorn A couple of weeks ago, [Detlef Heese](https://hee.se) from Osnabrück contacted us. He is a renowned photographer, electric car driver and owns a photovoltaic system. He offered to support the evcc project and provide us with professional photos. Therefore, at the end of last year, we started a [call on GitHub](https://github.com/evcc-io/evcc/discussions/10285) to find interested users who would like to present themselves and their evcc setup for a community portrait.  ## The path to electric mobility [Section titled “The path to electric mobility”](#the-path-to-electric-mobility) **Michael:** Hi Arne, thank you for taking the time for this interview. Can you tell us a bit about yourself and how you got into electric mobility? **Arne:** Hi Michael, I’m Arne and I live in the small town of Gifhorn. I live there with my wife and two children in a single-family house. Due to the German wallbox subsidy in 2021, we started to get interested in electric mobility. Back then, we had two EV chargers installed cost-effectively and with a little DIY. True to the motto: “Having is better than needing!” Even before the wallboxes were installed, we had already decided to replace one of our two combustion engine cars with an electric vehicle. Certainly the possibility of subsidies also played an important role.  Shortly afterward, we ordered an ID.3 Pure, which was delivered in the same year. And while we were waiting for the ID.3, we rounded off the package and also ordered an 11.2 kWp PV system, which was then installed at the beginning of 2022. Last year, we added a small BYD storage system to the PV system, which was mainly purchased for household consumption and is only used to a limited extent for charging the electric car. **Michael:** That sounds like a great set up. How did you come across evcc and the topic of PV surplus charging? **Arne:** Even before the PV system was installed, we knew that we wanted a way to charge with as much electricity from our own roof as possible. At first, I had the idea to use my own small script to start charging when enough surplus is available. After a bit of research, I came across the fact that there already is something like this: evcc. ## Technical insights [Section titled “Technical insights”](#technical-insights) **Michael:** Can you give us some technical details about your setup? **Arne:** Certainly, here are the most important technical details:  | Component | Details | | --------------------- | ---------------------------------------------------------------------------------------- | | **Auto** | VW ID.3 pure | | **Charger** | 2x go-eCharger HOMEfix 11 kW | | **Inverter** | Kostal Plenticore plus 10 Kostal Smart Energy Meter | | **Solar modules** | 28x Trina Vertex S 400Wp (total 11.2 kWp) nearly perfect south orientation on a 45° roof | | **Battery storage** | BYD HVS 5.1 (5.12 kWh) | | **Energy management** | evcc on a Raspberry Pi 3b | In addition, I also operate an ioBroker instance, which is not involved in the charging control.  ## What do you like about evcc? [Section titled “What do you like about evcc?”](#what-do-you-like-about-evcc) **Michael:** This looks like a well-rounded setup. Why did you decide to use evcc and what do you like about the project? **Arne:** I did not expect that we could actually increase our self-sufficiency so much with evcc. We are currently at a self-sufficiency rate of over 80% (as of early August). It just fits perfectly with our situation: we partly work from home, and have an additional car in the household, mostly used for short distances. We can leave our electric car standing at home during the day so it can solar charge. The car is simply always connected to the EV charger at home and thanks to the automatic detection, evcc starts charging as soon as enough surplus is available. As a result, the car is always charged and ready for use. In everyday life, we hardly have to worry about the charge level. Thanks to the minimum charge feature there is always enough energy during the winter months for daily trips. It couldn’t be easier and more convenient. This certainly made it easier for my wife to switch to electric mobility.  **Michael:** That sounds really great! Thank you for sharing your experiences with us. *** Also thanks to Detlef for the great photos. We look forward to sharing more stories from our community in future blog posts. If you are interested in presenting your evcc setup in a community portrait, feel free to leave your details [here in the form](https://airtable.com/appDI3xIiev1DOpMY/shrW1zGH26KElfZOK). Especially if you don’t live in or near Germany. # Highlights: § 14a EnWG, OCPP Today, [version 0.130](https://github.com/evcc-io/evcc/releases) of evcc was released. Since it’s been a while since the last release blog post, here’s an overview of the highlights from the recent releases.  ## Load Management & § 14a EnWG [Section titled “Load Management & § 14a EnWG”](#load-management---14a-enwg) A few releases ago, we introduced load management as an experimental feature. This allows you to set a power and/or current limit for the entire house. evcc controls the EV chargers so that these limits are not exceeded. For more complex installations, there is also the possibility to configure sub-circuits with their own limits and meters. You can find more information in the [documentation](/en/features/loadmanagement). ### Controlleable Consumers [Section titled “Controlleable Consumers”](#controlleable-consumers) In Germany § 14a of the Energiewirtschaftsgesetzes (EnWG) is currently a prominent topic. It allows grid operators to reduce the power consumption of large consumers, such as EV chargers, in case of high grid load. If the customer agrees to this regulation, they benefit from reduced grid fees. The technical implementation is interesting here. The grid operator does not directly access the EV charger, but communicates the signal to reduce the power via the Smart Meter Gateway (SMGW). The energy management system in the house then has to reduce the relevant consumers. With evcc you can meet this requirement (dimming) for all wallboxes today without having to switch them off, for example via a potential-free contact. The charge points can continue to operate at their minimum power (e.g. 4.1 kW) during this period. This means that any wallbox supported by evcc can be used in this scenario No need to buy a new EV charger with special support for communication with SMGW or Steuerbox. ### How it works [Section titled “How it works”](#how-it-works) In case of a grid overload, the grid operator sends a signal to the SMGW. The SMGW itself does not offer a meaningful way to communicate with the home network. This is done via a so-called Steuerbox that is connected behind the SMGW. This certified box forwards the signal to the respective devices via EEBus. evcc has implemented the EEBus interface to the Steuerbox. When a reduction signal comes in, evcc reacts and regulates the EV chargers accordingly. An alternative way to EEBus is communication via a simple switching contact of the Steuerbox. This can then be connected to evcc via a GPIO pin, for example. If the Steuerbox receives a reduction signal, the contact is closed, evcc detects this and reduces the maximum power of the wallboxes. This simpler contact solution can also be used with existing (Funk)Rundsteuerempfängern (FRSE). These are not part of § 14a EnWG, but are tolerated as a transitional solution. In practice, the use of this feature is still lacking Steuerboxen installed in the field. These will be rolled out in the coming months. If you already have such a device, feel free to contact us. ### Grid Charging of Home Battery [Section titled “Grid Charging of Home Battery”](#grid-charging-of-home-battery) This is an experimental feature and is available if your inverter supports active battery control ([see documentation](/en/meters)) and you have a dynamic electricity tariff. In this case, you can set a price limit. If this is undercut, evcc charges the home battery with grid power.  This feature can be especially useful in the winter months. If little solar power is expected during the day, the storage can be charged with cheap grid power at night. This way you can bridge periods with high electricity prices. In the current implementation, the fixed price limit is deliberately simple and only the first step into the topic. If you don’t want to regularly check and adjust the limit via the web UI, you can already build smarter solutions (e.g. time- or forecast-based) based on the introduced API. ## Elli Charger: Status Update [Section titled “Elli Charger: Status Update”](#elli-charger-status-update) A relatively popular EV charger is the Elli Charger from the VW Group. It is also sold under the names “VW ID. Charger”, “Skoda iV Charger”, “Cupra Charger” or “Audi Wallbox” and comes in different variants depending on the brand, which end with “Connect”, “plus”, “Pro”, “Connect+” or “pro” ([see overview](https://github.com/evcc-io/evcc/pull/7757#issuecomment-1529477695)). Supporting this wallbox has unfortunately not been a source of joy over the past few years. [DerAndereAndi](https://github.com/DerAndereAndi) has invested a lot of passion and time here. Thank you for that 🙌! The quality of the firmware is relatively poor and there are many bugs. This is not entirely unusual for software and new products. However, the problem is that this product has been on the market for several years and the manufacturer shows no serious efforts to fix these bugs with updates. [This post](https://github.com/evcc-io/evcc/discussions/15367) summarizes the technical problems that occur when controlling and reading the wallbox. A permanent source of errors were and are the unreliable meter data. In the current release, we have therefore removed support for the built-in meter and recommend all owners of this wallbox to use a separate meter upstream.  If you’re planning to buy a wallbox that should be controllable with evcc, we can only advise against these devices. Elli has announced a next generation product, the [ElliCharger 2](https://www.elli.eco/de/privatkunden/produkte/wallbox). From what we know so far, this is a much more mature device. However, this does not change the fact that the first generation wallboxes, which are still actively sold today, are absolutely unacceptable in terms of interface software quality. If you own such a wallbox and are affected by the problems described above, we recommend contacting Elli customer support. We have little hope that there will be software updates. However, we think their approach of replacing technically good hardware with a newer one just because the software is no longer maintained is not really sustainable. We would also appreciate direct technical contact with Elli. So far, however, all our attempts have been unsuccessful. ## Status indicators at the charge point [Section titled “Status indicators at the charge point”](#status-indicators-at-the-charge-point) A visual change that has recently been introduced to evcc is the revision of the status texts. Until now, a messages like “Surplus available. Start in 1:22 min…” or “Charging plan active. Start at 23:12.” were shown above the charge level bar.  With the growing number of functions, this display has become somewhat inflexible and parallel states, such as PV timer, charging plan, and price limit, could not be displayed simultaneously. Therefore, we have revised the area. The charger state is still displayed as a short text (“Connected”, “Charging”, …). Additional information such as PV timer, charging plan, price limit, air conditioning, or the in-vehicle limit are now displayed as an icon with an explanatory tooltip if relevant. Here is an overview of the new icons and tooltips:  ## OCPP: Stability, Features & Sponsoring [Section titled “OCPP: Stability, Features & Sponsoring”](#ocpp-stability-features--sponsoring) OCPP-suppport has been a feature of evcc for a long time. In recent months, we have focused on this topic again and [put a lot of work](https://github.com/evcc-io/evcc/pulls?q=is%3Apr+is%3Amerged+sort%3Aupdated-desc+ocpp) into the stability and functionality of our implementation. Until now, special configuration parameters were required for some wallboxes during setup. These are now, with very few exceptions, all obsolete. Functions such as meter data, query intervals, ping and heartbeat signals are now configured automatically. Since there are still wallboxes that do not fully comply with the standard, we had to implement some device-specific special handling. These are now transparent to the user. ### RFID and Authorization [Section titled “RFID and Authorization”](#rfid-and-authorization) The biggest change or innovation from the user’s point of view is the standard-compliant support of authorization. This now also enables [vehicle recognition via RFID](/en/features/vehicle#detection-via-rfid). Immediate charging without authorization is still possible. For this, the respective feature in the EV charger (“Autostart”, “Freies Laden”, “Free Vending”, or similar) must be activated. If your wallbox does not have this setting (which is rather rare), you can also restore the previous evcc behavior via the `remotestart: true` parameter. Then evcc starts the charging without approval from the device. ### Many Wallboxes Tested [Section titled “Many Wallboxes Tested”](#many-wallboxes-tested) We’ve successfully tested the implementation with a variety of devices and added them to the [documentation](/en/chargers). The list is certainly not complete. If your OCPP wallbox is not in there, but works well with evcc, we’d love to [hear from you](https://github.com/evcc-io/evcc/issues/new/choose) so we can add it to the documentation for other users. If your charger doesn’t work as expected, we’d like to know that too 😉. ### Sponsoring required [Section titled “Sponsoring required”](#sponsoring-required) With version 0.130, OCPP support becomes a feature that requires 💚 sponsoring. We are aware that this change may be unpleasant for users who have used evcc for free so far. Nevertheless, we have decided to make this change. There are mainly two reasons for this: 1. In many new, commercial wallboxes, OCPP has become the communication protocol of choice and often the only control interface. That’s why we think it’s fair, especially for users of other wallboxes, that OCPP support requires sponsoring and thus supports the entire project. 2. As described above, we have put a lot of energy and time into improving the implementation and would like to continue to do so to ensure stability and functionality. Your financial support helps us to provide the necessary resources for this. We hope you understand this change. ## Further Improvements [Section titled “Further Improvements”](#further-improvements) * **Log UI:** Logs can now be viewed, filtered, and exported directly in the web UI. * **Languages:** evcc now supports 27 languages. A big thank you to all translators. * **Config UI:** In the last few releases, many features necessary for replacing the `evcc.yaml` have been added. More on this in a later blog post. * **Bugfixes:** As always, we have fixed many bugs and improved stability. * **New devices:** We are constantly expanding the list of supported wallboxes, inverters, meters, and tariffs. For more details, you can always check the [changelogs of the releases](https://github.com/evcc-io/evcc/releases) and the pull requests and discussions linked there. ## New Sponsors [Section titled “New Sponsors”](#new-sponsors) We’d also like to thank all of you who support the project through sponsoring. Being able to work on an open-source project that is funded almost entirely by the community and users is pretty cool. As we can see, evcc is now being taken seriously in the corporate world as well. This is reflected in the fact that manufacturers sometimes contact us directly to ensure good integration of their devices. We were able to win [CUBOS](https://www.cubos.com), a company in the field of photovoltaics and commercial charging infrastructure, [lekker Energie](https://www.lekker.de), an energy supplier from Berlin, and [Victron Energy](https://www.victronenergy.com), a manufacturer of open and modular inverter, battery, and charging systems, as financial corporate sponsors. **Happy charging!**\ the evcc team\ Michael, Andi & Uli # Community: Christian from Trebbin This is the second post in our series of community portraits. Photographer [Detlef](https://hee.se) visited Christian from Trebbin this time and took some great photos.  ## Trebbin: A house, three generations [Section titled “Trebbin: A house, three generations”](#trebbin-a-house-three-generations) **Michael:** Hello Christian, thank you for taking the time. Can you tell us a bit about yourself, your family and your living situation? **Christian:** Hello Michael, I’m Christian. I live with my wife, our two children and my mother-in-law in Trebbin in a house that was originally built in 1980. We extended and energetically renovated it in 2009 to create more space and reduce energy consumption. We live here as a three-generation family and have done a lot recently towards electric mobility and our own energy production. **Michael:** Can you tell us more about your journey to electric mobility? **Christian:** Our journey into electric mobility began in 2019 when I had to commute to work by car due to a change of employer. That’s when we decided on a used Smart ED. Since everyone always wanted to drive the Smart, we replaced our combustion engine car with a Renault Zoe, which was delivered in November 2020. Since then, we’ve been completely electric. **Michael:** Funny, I’ve heard that effect before: that the electric second car becomes the family’s favorite and the combustion engine car is left standing. And how does it look today? Is the Smart still in use? **Christian:** No, the Smart has found a new owner. Earlier this year, we sold it and replaced it with a Fiat 500e Icon. So now we drive the Fiat and the Renault Zoe. Both cars are charged with electricity from our own photovoltaic systems.  ## On the road with small electric cars [Section titled “On the road with small electric cars”](#on-the-road-with-small-electric-cars) **Michael:** How do you use the electric cars in your daily life? What role does your charging infrastructure play? **Christian:** Our daily mobility is well organized. My wife commutes to Berlin by train for work, while I use one of the cars for my trips. The children’s hobbies involve a lot more driving, so we are quite a lot on the road with the cars, but mostly with solar power. With the two go-e chargers installed at the carports, we can charge at any time and ensure that the cars are ready for use. We simply plug in the cars after the trip, and when we need them, they are charged again. The chargers are powered by the PV systems, so we can use the electricity directly from the roof. The first PV system on the house roof has 19.47 kWp and the second system on the carports has 11.4 kWp. The systems are dimensioned so that we can produce the electricity for the cars and the household largely ourselves.  **Michael:** How did evcc integrate into this setup? **Christian:** With the first PV system came the desire to charge only with PV electricity in an automated way. evcc was the only project that offered the possibility of running in a Docker container. This meant that I didn’t have to buy new hardware, as there was already a NAS running for backup and data storage in the household. For us, it was particularly important to keep an eye on the power consumption and charging status of the cars. In use, the very high WAF (Woman Acceptance Factor) in the family proved to be an advantage. So my wife uses evcc very intensively, and my mother-in-law also likes to check if there is enough power available. Thanks to evcc, we manage to draw about 85% of the required electricity for the cars from our own PV system on average over the year. This has increased our energy self-sufficiency to 73%, all without the use of a home storage system.  ## High self-sufficiency without a home battery [Section titled “High self-sufficiency without a home battery”](#high-self-sufficiency-without-a-home-battery) **Michael:** 73% energy self-sufficiency without a home storage system is really impressive. That’s a value many dream of. How did you manage that? **Christian:** The large dimensioning of the PV system in combination with the east/west orientation helped us. This way, we produce the energy distributed over the day. This is particularly useful for us, as we can charge the cars during the day. evcc then takes care of the control of the charging processes, so we don’t have to worry about it. For us, it was the right decision, and we are satisfied with the result. **Michael:** Thank you for the insights into your setup.  *** Also, thanks to Detlef for the great photos. After the [first blog post](/en/blog/2024/08/09/portrait-arne-gifhorn), some more community members have already contacted us to share their stories. So there will be even more exciting insights into different installations. 🤩 # Community: Tjarko from Großefehn This is the third post in our series of community portraits. Photographer [Detlef](https://hee.se) visited Tjarko from Großefehn at the [Gröönlandhof](https://www.groeoenlandhof.de). In addition to great photos, there are also interesting insights.  ## Multi-Generational Plus Energy Farm Project [Section titled “Multi-Generational Plus Energy Farm Project”](#multi-generational-plus-energy-farm-project) **Michael:** Hello Tjarko, great that you are taking the time for a community portrait. Your farm, the Gröönlandhof, was featured in the [PV Magazine](https://www.pv-magazine.de/2021/01/15/selbst-ist-der-groeoenlandhof-wallbox-ladesteuerung-selbst-gebaut/) a few years ago, and some users might have heard the name before. Maybe you can start by telling us about yourself? **Tjarko:** Yes, gladly. Six years ago, we converted the heritage-protected, parental farm into a multi-generational plus-energy farm project, the Gröönlandhof. Since then, we’ve been living here together with other people and, among other things, we also run a Community Supported Agriculture project. On the farm, we have an electric delivery van, the Streetscooter, and two electric passenger cars. We started with a Renault Zoe, which has since been replaced by an MG ZS and an MG 4. The whole setup is powered by several PV systems.  ## 4 PV Systems, 3 Charging Points, 3 Electric Cars, and Vacation Guests [Section titled “4 PV Systems, 3 Charging Points, 3 Electric Cars, and Vacation Guests”](#4-pv-systems-3-charging-points-3-electric-cars-and-vacation-guests) **Michael:** PV systems are a good keyword. Perhaps we can delve into the technical details here. What does your setup look like? **Tjarko:** Well, as I mentioned, we have two full feed-in systems that will soon be converted to self-consumption, and a 16 kWp PV system with a south-east orientation that we already use for our own needs. We’re also planning another 16 kWp PV system with a south-west orientation. The whole setup is distributed via a Fronius Symo inverter and a large home storage system from BYD with 22 kWh. We have three charging points at various locations on the farm: two Go-e Chargers with 22 kW and one Go-e Charger with 11 kW. We’ve limited the charging points to a maximum of 22 kW in total through the integrated load management. We’ve created RFID chips for all vehicles, so you can easily track the charging processes with evcc. Since more and more guests (farm visitors, vacation guests, etc.) are coming with electric cars, there’s also an RFID chip for guest vehicles. In the past two years, we’ve managed to cover 45% of our charging power with solar energy! In terms of hardware, I initially ran evcc for testing on a Synology NAS with Docker, but now it runs on a micro PC as an add-on in Home Assistant. I find this easier and more comfortable, and it offers even more possibilities for automation through Home Assistant. Additionally, all farm residents can easily manage it through the Home Assistant app.  | Component | Details | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | **Cars** | MG 4, MG ZS, Streetscooter, vacation guests’ cars | | **Wallboxes** | go-e Charger (11 kW, 2x 22 kW) | | **Hybrid inverter** | Fronius Symo GEN24 10.0 Plus | | **Solar system** | 16 kWp South/East orientation | | **Storage** | BYD Premium HVM (22.1 kWh) | | **Control** | evcc on Mini-PC as Home Assistant Add-On | | **Dynamic tariff** | LUOX energy (formerly Lumenaza) | | **Planned** | 16 kWp South/West (new system) 27 kWp system (full feed-in to self-consumption) 25 kWp system (full feed-in to self-consumption) | We have a dynamic electricity tariff from LUOX energy (formerly Lumenaza), as they also accept small photovoltaic systems for direct marketing. The only thing left on the to-do list now is the integration of the Homematic wireless thermostats, to raise the room temperature during the heating period with evcc when there’s a solar surplus. As two more PV systems (27 kWp and 25 kWp) will be converted from full feed-in to self-consumption in the coming years, this will make for a well-rounded setup.  **Michael:** That’s really impressive, it sounds like many aspects of your daily life are integrated into a sustainable energy supply, not just charging a car. Can you tell us a bit about your background? Why did you get involved with this topic? How did you come across evcc? **Tjarko:** I myself am an engineer for Renewable Energy Systems and have been dealing with the topic of energy generation, storage, and management for a long time, both privately and professionally. As a researcher, I have published Open Data and Open Source projects myself, so I’m generally very enthusiastic about the topic. I came across evcc directly on GitHub and quickly saw its potential. Above all, the fact that evcc could take into account the charging status of vehicles long before many other solutions was a big plus for me.  ## Cloud-based solutions will never be able to do this to this extent [Section titled “Cloud-based solutions will never be able to do this to this extent”](#cloud-based-solutions-will-never-be-able-to-do-this-to-this-extent) **Michael:** Tjarko, you’ve been an evcc user from the very beginning - what fascinates you about the project? And what would you perhaps wish for in the future? **Tjarko:** evcc has always been at the forefront of integrating as much hardware as possible while keeping all functions very understandable in operation. The biggest advantage for me in the future is that it runs locally on the network and can therefore control many storage systems. In addition to the already implemented feature “discharge lock at low electricity prices”, it has recently become possible to “charge the storage from the grid”. Cloud-based solutions will never be able to do this across manufacturers to the extent that evcc can. My biggest wish is that the **configuration** is fully possible via the web interface and that there are also one and several companies that distribute evcc together with hardware, so that many more users can benefit from evcc. **Michael:** Well, let’s see how quickly this wish comes true. Thank you very much for your time and all the best! # Community: Bastian from Ahlhorn In our series of community portraits, photographer [Detlef](https://hee.se) recently visited Bastian from Ahlhorn, Großenkneten.  ## „Now is the time!“ [Section titled “„Now is the time!“”](#now-is-the-time) **Michael:** Hello Bastian, how nice to meet you. Tell us a little about yourself and how you got into electric cars and surplus charging. **Bastian:** Yes, gladly. My name is Bastian and I live with my wife and two children in the municipality of Großenkneten in the district of Oldenburger Land. The location was perfect for us because we are close to larger cities (Vechta, Oldenburg, Bremen), but the house was still affordable. The infrastructure of the place also has everything within walking distance that we need, including two grocery stores, all types of schools, and a kindergarten. After we moved into our house from 1978, I relatively quickly started dealing with the topic of PV systems. The roof surfaces in a bungalow with a pitched roof are just perfect for it. And electricity was, in my opinion, already too expensive at that time. “Now is the time” was the motto, so that you can get as much out of it as possible. So very soon we installed a large PV system on the east and west roof.  ## 28 kWp Solar + Dynamic Electricity Tariff = 💚 [Section titled “28 kWp Solar + Dynamic Electricity Tariff = 💚”](#28-kwp-solar--dynamic-electricity-tariff--) **Michael:** Using the roof for electricity generation is always a great idea. Then came the electric car? **Bastian:** Yes, exactly, last year my employer announced that they would start an electric car leasing, which was then the decisive point for us to enter the exciting field of electric mobility. Since we can make a lot of electricity through the large roof surfaces, it made sense for us to charge the car exactly with it. When searching for solutions, I quickly came across evcc on the internet. That, and the integration of Frigate, were also the reason for me to switch from ioBroker to Home Assistant. In the beginning of January we also switched to Tibber, so that we can also charge cheaply in the winter. Two years ago, we installed a heat pump which, especially in winter, uses almost all of our PV electricity. So there’s not much left, but with Tibber I’m able to charge cheaply at night.  ## Synology, Home Assistant and evcc [Section titled “Synology, Home Assistant and evcc”](#synology-home-assistant-and-evcc) **Michael:** That makes sense. Especially in winter, you can save a lot with a dynamic electricity tariff. How does your current technical setup at home look like? **Bastian:** Here’s an overview of the components that work with evcc at my home: | **Component** | **Details** | | --------------- | ------------------------------------------------------ | | **Hardware** | Synology DS923+ | | **Software** | Home Assistant with evcc Addon | | **Car** | Hyundai IONIQ 5 | | **Battery** | SENEC.Home 2.1 10kWh | | **Wallbox** | SENEC.Wallbox pro | | **Inverter** | SMA Tripower STP 25000TL-30 | | **PV** | 27,88 kWp, AXITEC X HC 340 82 Module (40 Ost, 42 West) | | **Electricity** | Tibber |  **Michael:** That’s quite a few different components at work. You had already mentioned that you use Home Assistant. Are there any more integrations into other systems? **Bastian:** I’m currently only using Home Assistant. With evcc, I mainly want to track my daily electricity costs.  **Michael:** You mentioned that you found evcc through an internet search. What was the reason for you to choose the system? **Bastian:** I came across evcc pretty quickly. I first tried the Senec components, but their system was not able to offer PV-surplus charging. So I then came across evcc. Since January, I’m using price-sensitive charging with Tibber, which enabled my to charge cheaply in the winter.  **Michael:** Which evcc feature do you like best? **Bastian:** That’s a tough question, but I think I like the automatic charging at cheap times the most. I also like that evcc is very user-friendly and comes with a very clear UI. ## Next Goal: Heat Pump [Section titled “Next Goal: Heat Pump”](#next-goal-heat-pump) **Michael:** Do you have any wishes for the future development? **Bastian:** I’m following the project on GitHub and am already looking forward to when the charging in combination with the PV forecast will arrive. Also charging with a more sophisticated planner would be great. Especially the latter will bring me better through the winter. My next goal is then to integrate my heat pump. I’m still unsure whether I should do this directly in evcc or in an EMS system and if so, which one. First, I need to be able to reach my heat pump. That’s not so easy with Buderus/Bosch…  **Michael:** Das klingt doch perfekt. Better integration for heat pumps is also on our agenda. Thank you very much for sharing this with us and all the best for the future! # Community: Andreas from Wettringen In our series of community portraits, photographer [Detlef](https://hee.se) visited Andreas in Wettringen in the Münsterland region.  ## Fascinated by IT and kept going [Section titled “Fascinated by IT and kept going”](#fascinated-by-it-and-kept-going) **Michael:** Hello Andreas, nice to meet you. Tell me a little bit about yourself and how you got into electric cars and solar charging. **Andreas:** Yes, hello Michael. I’m a pharmacist by profession. I’ve been the manager of the Sonnen-Apotheke in Wettringen for 35 years. I’m married, have two, now grown-up children and we live in a single-family house on the countryside. I’ve sold the pharmacy at the beginning of this year, but the IT in the pharmacy, 10 workstations, 5 virtual servers, Windows and Linux, I’ve always managed myself. This knowledge I could take with me. I’ve been dealing with IT since my discharge from the Bundeswehr. With the severance pay, I purchased my first computer, a Tandy TRS 80. Since then I’ve been fascinated by IT and I’ve stayed with it.  **Michael:** Wow, you have a lot of technical background knowledge and a good overview of what it takes to run a business with all that. How did you get into electric cars and solar charging? **Andreas:** Three years ago, I bought a Mini SE out of interest in the technology. The car replaced a combustion engine Mini Cooper. At the time, wallboxes were still scarce, so I took the one the installer recommended. I had no knowledge what a good solution would be. Two months later, the 10kWp PV system was installed. One half of the modules is oriented to the east (4.6 kWp), the other half to the west (5.4 kWp). Since I had no storage at that time, I wanted to use the surplus of the PV system directly to charge the Mini.  ## The Manual was no Longer a Solution [Section titled “The Manual was no Longer a Solution”](#the-manual-was-no-longer-a-solution) **Michael:** Okay, you were so early on the topic that there were not many experience values and you made your own. Did it work with the Mini and charging as you imagined? **Andreas:** Well, there was no control logic in my installation. Every morning, when the sun was up, I went to the car and plugged it in. This manual process became tedious quickly, so I started looking for automations. Since I’ve been dealing with Open Source for a long time, I looked a bit on GitHub and came across evcc. An installation on a running Linux server was quickly made. The different components like inverter, EV charger and car were quickly integrated.  ## Wallbox-Debugging, but now it’s running [Section titled “Wallbox-Debugging, but now it’s running”](#wallbox-debugging-but-now-its-running) **Michael:** That sounds like a good start. How did you proceed? **Andreas:** Everything worked, only the wallbox, an Alphatec Mini, was not controllable. After a little research in the forum, it quickly became clear that the EV charger did not work as it should. There was no proper description of the control commands either. But [Premultiply](https://github.com/premultiply) can probably say more about that. After my contact with the manufacturer, it went quickly, Premultiply received a test box and the firmware of the control board was updated. I sent the board to the manufacturer and got the new firmware installed. Now evcc can talk to the wallbox. Thanks to this solution, the problem was not only fixed for me, but also for all new Alphatec users. Open Source at its best! A step-by-step adjustment of the charging power from 6 to 16 A was finally possible. Since the box does not allow switching between single-phase and three-phase, a load switch was added to the sub-distribution. Normally I charge with one phase, since I mostly don’t have more surplus. If I need a faster charge, I manually switch to three phases. The fun with evcc could begin.  **Michael:** Ah, then you have optimized and adapted your first setup. How did it affect the usage? **Andreas:** After a year of operation of the system, I could see that I, despite the electric car, feed about 4,500 kWh into the grid. So, a second electric car would fit perfectly. The old family car, also a diesel, was replaced by an electric one. Now two cars are charged with evcc, one car is always connected to the charging station. Optimal for our situation. To be able to continue to operate at least one or other device in case of a temporary power outage, I bought an EcoFlow DELTA Pro with additional battery, a total of 7.2 kWh storage. With some scripts in Home Assistant, these are charged when there is a surplus. A part of the storage is then used during the night to reduce the power consumption, the rest as a reserve.  | **Component** | **Details** | | ---------------- | ----------------------------------- | | **Cars** | Mini SE, BMW iX3 | | **EV Charger** | Alphatec Mini | | **Inverter** | SMA Tripower 10 | | **Solar System** | 10 kWp (4.6 kWp East, 5.4 kWp West) | | **Storage** | EcoFlow DELTA Pro (7.2 kWh) | | **Control** | evcc on Ubuntu Server under Proxmox | | **Integrations** | Home Assistant | ## Home automation and media server [Section titled “Home automation and media server”](#home-automation-and-media-server) **Michael:** That sounds like an exciting journey. What does your homelab setup look like? Do you use integrations into other systems? **Andreas:** Oh yes, I’ve been fascinated by home automation for a long time. Originally I started with Homematic home automation. And more and more components came along. Since I also tried other manufacturers, I quickly wanted to manage all components together. Home Assistant was my integration. I’ve also been running a media server for two decades. My children have always managed to damage the music tapes and CDs so much that they were no longer usable. So I started early to digitalize the analog media and make it available centrally.  First with applications that ran on a NAS, later as virtual servers on a hypervisor. Currently, various homelab applications are running under Proxmox: evcc on an Ubuntu Server; Plex as a media server, eBlocker, paperlessNGX, Home Assistant. ## Meets all my needs [Section titled “Meets all my needs”](#meets-all-my-needs) **Michael:** After the initial challenges and optimizations, it sounds like you now have a solution that works well. Do you have any wishes or suggestions for the future development of evcc? **Andreas:** For me, evcc meets all my needs. I’m happy with the available feature set. It covers all the requirements I have. **Michael:** Thank you for the conversation, Andreas. It was great to hear about your setup and your experiences. I wish you all the best for the future. # Highlights: Charts & Stats The days are getting shorter. A good reason to give a small update on what has been done since the [last article in August](/en/blog/2024/08/17/highlights-14a-enwg-ocpp-loadmanagement-elli). ## Visualization of charging sessions [Section titled “Visualization of charging sessions”](#visualization-of-charging-sessions) The overview of [charging sessions](/en/features/sessions) has been available for a while. Besides the basic data like energy consumption, charging times, vehicle and odometer readings, we have been collecting information about the share of self-produced solar energy, real prices and CO₂ emissions for some time now. Previously, this data was only available as a table or CSV export for self-analysis. Now we’ve added nice visualizations of your charging energy, solar energy share, costs and CO₂ emissions.  If you have multiple charging stations or vehicles, you can group and compare the data. In the [documentation](/en/features/co2) you can find out how to set up the required [CO₂ data sources](/en/features/co2) and [dynamic prices](/en/features/dynamic-prices).  ## Battery Boost [Section titled “Battery Boost”](#battery-boost) The first version of the often requested [Battery Boost](/en/features/battery#battery-boost) has made it into the release as an experimental feature 🧪. This function supplements the classic PV surplus charging. When activated, the home battery’s stored energy is also used to charge the vehicle in addition to the available solar energy. The system automatically determines the maximum charging power that the storage system can provide.  The boost can be activated per charging station and will automatically turn off when the vehicle is disconnected. This can be particularly practical on sunny days. If you want to drive off in the afternoon with your car from home, you can activate the boost before you leave, so that the energy of the fully charged home battery is transferred to the vehicle. Your vehicle leaves with a higher charge level and your home battery has space left to store the energy of the afternoon sun, which you would otherwise have fed into the grid. Additional settings like setting charging limits and a more prominent placement in the UI (as a Boost button) are on the agenda for a future release. ## Flexible Tariffs [Section titled “Flexible Tariffs”](#flexible-tariffs) The list of [different tariffs](/en/tariffs) is growing steadily. Especially in the coming years, the topic of dynamic tariffs will gain in importance. Digital-first providers like Tibber, Awattar, Octopus or Ostrom offer APIs for the current price and price forecasts for the next day. These prices often already include grid fees and other costs. For dynamic tariffs, for which the provider does not offer an API, there is the possibility to determine the electricity price based on the day-ahead price at the electricity exchange itself. A good data source for the spot price is the [Energy Charts](https://api.energy-charts.info) interface of Fraunhofer ISE. This can be used without prior registration. Here is an example configuration for the German price zone: ```yaml tariffs: grid: type: template template: energy-charts-api bzn: DE-LU charges: 0.22 # fixed surcharge per kWh (e.g. 20ct grid fee, 2ct provider fees) tax: 0.19 # percentage surcharge (e.g. 19% VAT) ``` The formula `(price + charges) * (1 + tax)` is used to calculate the final consumer price per kWh. This formula was previously hard-coded. For more complex tariffs, e.g. with an upper cost limit, you can now also adjust this formula yourself. Here is an example for a dynamic tariff with an upper cost limit of 50ct/kWh: ```yaml tariffs: grid: type: template template: energy-charts-api bzn: DE-LU charges: 0.22 # fester Aufschlag pro kWh (bspw. 20ct Netzentgelt, 2ct Gebühren) tax: 0.19 # prozentualer Aufschlag (bspw. 19% MwSt.) formula: math.Min(0.5, (price + charges) * (1 + tax)) ``` In addition to the spot price (`price`) and the values for `charges` and `tax`, you also have the power of the [math](https://pkg.go.dev/math) library of Go at your disposal. ## Hybrid inverters with limited AC power [Section titled “Hybrid inverters with limited AC power”](#hybrid-inverters-with-limited-ac-power) Some hybrid inverters offer a higher DC power than the AC power. This means they can, for example, handle 10 kW of PV power, but only provide 8 kW of AC power for the house grid. The remaining 2 kW is stored DC-side in the battery. This has always caused problems in the surplus regulation, since evcc calculates with the full PV power. The global configuration option `maxGridSupplyWhileBatteryCharging` (yes, a clumsy name) was an attempt to counteract these unintended side effects. We have replaced this option with a more stable solution. All affected [inverter templates](/en/meters) (e.g. Fronius, Growatt, SMA, Sungrow, …) now have the extended option `maxAcPower`. This allows you to define the maximum AC power (e.g. `maxAcPower: 8000` for 8 kW) per inverter. The surplus regulation now takes this value into account accordingly. ## Sponsor cocharge: make your private charging station public [Section titled “Sponsor cocharge: make your private charging station public”](#sponsor-cocharge-make-your-private-charging-station-public) We are pleased to welcome the Bremen startup [cocharge](https://cocharge.de/evcc) as a new sponsor. [](https://cocharge.de/evcc) cocharge allows private users to make their charging station public. Your wallbox then appears in the apps of the major charging card providers, optionally with definable opening hours. For the electric car owner, charging and billing at your station works just like at any other public charging station. cocharge takes care of the technical details, claims for THG quotas, roaming agreements and the bureaucracy. **Your additional income from external charging sessions is paid out monthly.** The prerequisite for using cocharge is a **certified charger (eichrechtskonform)** that **supports OCPP**. The charging point must also be **publicly accessible**. There are no one-time or recurring costs. cocharge charges only a 15% commission for each charging session. If you have a [company car](https://cocharge.de/dienstwagen-laden) and a charging card from your employer, this solution can be particularly interesting for you. You not only save yourself the bureaucracy by automatic billing You can also earn extra money if you charge with your own solar power or at a dynamic tariff at favorable times. Using both cocharge and evcc together? Most certified chargers also have a local interface like Modbus besides OCPP. You can then make your wallbox public and locally optimize the charging power parallel with evcc. If this sounds interesting to you and you want to be one of the first users, take a look at [cocharge.de/evcc](https://cocharge.de/evcc). ## Many small improvements [Section titled “Many small improvements”](#many-small-improvements) As usual, there were also many small improvements, bug fixes and support for new wallboxes, inverters and other devices. You can find more details in the [Release Notes](https://github.com/evcc-io/evcc/releases). 💚 A big thank you goes to all who support the project through active participation and financial sponsorship. **Happy charging!**\ The evcc Team\ Michael, Andi & Uli # Community: Olaf from Bergisch-Gladbach In our series of community portraits, photographer [Detlef](https://hee.se) visited Olaf in North Rhine-Westphalia. ## We Knew There Was No Turning Back [Section titled “We Knew There Was No Turning Back”](#we-knew-there-was-no-turning-back) **Michael:** Hi Olaf, thanks for taking the time to join this format. Tell us a bit about yourself and how you got into electric cars and PV surplus charging. **Olaf:** Hi Michael, my pleasure. I’m 52, married, and have two daughters. I co-founded my first company in 1998 in the e-commerce sector, where I led the SysAdmin team. I’m still active as a co-founder and consultant in various companies. I got into electric cars about four or five years ago. Before that, I hadn’t seriously considered them and was influenced by the strange media coverage. I thought e-cars would easily catch fire and have limited range. I can’t recall exactly what prompted me to look into it again—perhaps a blog post or a friend’s suggestion about tackling climate change. By early 2020, I was watching YouTube channels about upcoming e-cars in Germany.  It quickly became clear that an Enyaq or a Model Y would suit our needs best. Unfortunately, it took a while for these cars to become available, so I had the wall boxes installed before our first e-car. After a relaxed 5,500 km summer vacation in Spain with the Enyaq, it was clear to my family and me that there was no turning back. We sold the other combustion car immediately. Once you’re into e-mobility, installing a PV system for surplus charging is the next logical step.  **Michael:** Impressive, so you got into it due to climate change and delved deeper. I’m curious: What’s your home tech setup like? **Olaf:** The PV system is 18.92 kWp, with 6 panels on a slightly flatter dormer facing north-northwest. We have two Huawei inverters and a Huawei LUNA2000 home storage with 15 kWh capacity. We use three Alfen Eve Single Pro-line 22 kW wall boxes, and evcc runs on my Synology in Docker. Our three cars regularly charge with solar power. Besides the Enyaq, we have a Model Y and a Fiat 500e.  ## That’s When It Got Me [Section titled “That’s When It Got Me”](#thats-when-it-got-me) **Michael:** How did you discover evcc and why do you use it? **Olaf:** Initially, the solar installer and I tried to get the Alfen wall boxes to charge with surplus using an Elgris Smartmeter. We managed to display the current values but couldn’t adjust the charging power. When Alfen’s support said the feature was still in beta, I looked for other PV surplus charging options and found evcc. I liked its modular approach, allowing devices from different manufacturers to work together. It’s open source and constantly developed, which intrigued me enough to try installing it. After overcoming the yaml file intricacies and seeing evcc adjust the charging power to the PV surplus, I was hooked.  **Michael:** I can see why. Watching the software regulate is fascinating, especially for optimizing self-produced electricity. What’s your favorite feature? **Olaf:** My favorite is the PV mode, which adjusts my wall boxes to the current surplus from the roof. I also appreciate other benefits, like charging the Fiat 500e only up to 80%, which it can’t do on its own. I get more up-to-date PV yield displays than in Huawei’s app, which updates every 5 minutes. I adjust the “residual power” parameter in the UI to set a buffer, ensuring no grid power is drawn when a cloud passes or a large appliance is turned on. The inverter regulates this with the home battery in seconds. Unfortunately, evcc is slowed down by Huawei’s dongle, requiring a 45-second interval. But evcc’s settings offer workarounds for almost every problem.  **Michael:** It’s great to see evcc compensating for the manufacturer’s weaknesses. Do you use integrations with other systems like Home Assistant or Grafana? **Olaf:** Not yet. It’s new territory for me, and I currently lack the time to explore it. I’m quite satisfied with evcc’s built-in functions. | Component | Description | | ---------------- | ----------------------------------------------- | | **PV System** | 18.9 kWp, partially north-northwest orientation | | **Inverter** | 2x Huawei SUN2000 | | **Home Storage** | Huawei LUNA2000 with 15 kWh | | **Chargers** | 3x Alfen Eve Single Pro-line 22 kW | | **Vehicles** | Skoda Enyaq, Tesla Model Y, Fiat 500e | | **Control** | evcc on Synology in Docker | **Michael:** Christmas is almost here. If you could wish for something for evcc’s future development, what would it be? **Olaf:** Transitioning the installation from a yaml file to a UI would be a huge step forward. It would simplify many things. Also, intelligent control of heat pumps would be great, as we’re replacing our old heating with a Lambda heat pump. It would be nice to use evcc to heat the large buffer storage with surplus electricity, avoiding expensive grid power at night. **Michael:** That’s timely. Our last release added initial heat pump integrations and an SG-ready template. Much more will happen next year. Thank you again, Olaf, for sharing your setup and personal journey into “e-mobility & efficient charging.” I wish you and your family a Merry Christmas and continued enjoyment with your setup. # v0.133 - Tesla Developer Account required Starting with evcc v0.133, a [Tesla Developer Account](https://developer.tesla.com/) is required. The usage remains free of charge, but requires an additional setup step. Update This post has been revised. **[8.2.2025](https://github.com/evcc-io/docs/pull/723/files):** More detailed instructions for the Tesla Fleet API and myteslamate.com configuration.\ **[27.3.2025](https://github.com/evcc-io/docs/pull/775/files):** Update to the new setup process of myteslamate.com. ## Paid Tesla Fleet API starting February [Section titled “Paid Tesla Fleet API starting February”](#paid-tesla-fleet-api-starting-february) Last year we integrated the [Tesla Fleet API](/en/blog/2024/02/01/v0124-new-tesla-api) into evcc. Tesla was the first manufacturer to provide an official and above all open API for communication with their vehicles. Tesla had already announced that this API would not stay free of charge. The prices are now known and will come into effect starting February 1, 2025. The billing is based on usage, with costs varying depending on the type of request. With [tesla.evcc.io](https://tesla.evcc.io) we have provided a service that allows evcc users to generate access tokens for API usage. The API communication of these tokens would be billed to us starting February 2025. The costs per user depend on the number of vehicles, charging behavior, and the specific configuration of the update interval. For most users, these costs exceed our “$2 per month” sponsoring model and would not be sustainable for us, even if we would require sponsorship for Tesla integration. ## Free API credit for private users [Section titled “Free API credit for private users”](#free-api-credit-for-private-users) Tesla offers private users a monthly API credit of $10, which should be sufficient for most evcc users. [](https://developer.tesla.com/) With the version 0.133, we have adapted the API communication to Tesla so that you can use your own Tesla Developer Account. Old tokens generated with [tesla.evcc.io](https://tesla.evcc.io) will no longer work. We have considered extending our existing token generation process so that you can use your own Tesla Developer Account. Fortunately, [myteslamate.com](https://app.myteslamate.com) has already implemented this function. There you can generate **Access- and Refresh-Tokens** with your Developer Account. So we decided not to reinvend the wheel. ## What to do? [Section titled “What to do?”](#what-to-do) []() ### For Tesla drivers [Section titled “For Tesla drivers”](#for-tesla-drivers) For the setup in evcc you need three pieces of information: * **Client ID:** from the [Tesla Developer Portal](https://developer.tesla.com/) * **Access Token:** via the script from [myteslamate.com](https://www.myteslamate.com/tesla-api-application-registration/) * **Refresh Token:** via the script from [myteslamate.com](https://www.myteslamate.com/tesla-api-application-registration/) Follow the instructions on [myteslamate.com](https://www.myteslamate.com/tesla-api-application-registration/) to generate this information. Since you’ll be working on myteslamate.com and developer.tesla.com in parallel, we recommend doing these steps in two browser windows simultaneously. At the end of the process, a script must be downloaded and executed on your computer in the terminal/console. During the login process, a permissions dialog will appear. For operation with a normal wallbox (not Tesla Wall Connector), evcc requires the following **Tesla API permissions**: * Profile information *(region, list of vehicles)* * Vehicle information *(charge level, vehicle status, etc.)* * Vehicle location *(for vehicle detection, not implemented yet)* * Vehicle commands *(for wakeup)* Once you have successfully completed the process, enter the information in the evcc configuration: Example: ```yaml vehicles: - type: template template: tesla title: Tesla Model 3 clientId: aaaaaa-11111-... # from developer.tesla.com accessToken: ey1234567890... # from myteslamate.com refreshToken: EU_1234567890... # from myteslamate.com ``` You can track your used API credit in the [Overview of the Tesla Developer Portal](https://developer.tesla.com/dashboard/). Note The evcc project is in no way connected to myteslamate.com. We are in contact with [jlestel](https://github.com/jlestel), the developer of myteslamate.com. The free use of the service for evcc users is explicitly allowed by him. Please refer to the [Terms of Service](https://www.myteslamate.com/terms-of-service) and [Privacy Policy](https://www.myteslamate.com/privacy-policy) before using the service. ### For Tesla Wall Connector users [Section titled “For Tesla Wall Connector users”](#for-tesla-wall-connector-users) If you use a Tesla Wall Connector, additional steps are required, as the charging commands require signed communication and must be handled through a publicly accessible server. myteslamate.com provides such a proxy. Billing is done on a usage basis directly through myteslamate.com. These commands do not use your Tesla API credit. We assume you’ve already completed the [steps described above](#vehicle). Log into myteslamate.com again and follow the instructions to set up the paid command proxy. Copy the **Proxy-Token** from the **Use MyTeslamate API** section. Insert this token into your evcc configuration: ```yaml vehicles: - type: template template: tesla title: Tesla Model 3 clientId: aaaaaa-11111-... # from developer.tesla.com accessToken: ey1234567890... # from myteslamate.com refreshToken: EU_1234567890... # from myteslamate.com proxyToken: aaaaa-bbbbb-... # from myteslamate.com ``` With this setup, evcc will send charging commands to the myteslamate.com proxy, which will sign it with your Tesla application and forward it to the original Tesla API. The proxy token is very powerful. It is recommended to limit the permissions at myteslamate.com to the necessary functions. For evcc, only the functions **Charge Start**, **Charge Stop** and **Set Charging Amps** are necessary. ## tesla.evcc.io will be discontinued [Section titled “tesla.evcc.io will be discontinued”](#teslaevccio-will-be-discontinued) tesla.evcc.io will be discontinued in February. All tokens generated with it will lose their validity. For further use of the Tesla API, an update to evcc version 0.133 is required. ## Other alternatives [Section titled “Other alternatives”](#other-alternatives) The Tesla API communication in evcc is not specific to myteslamate.com. You can generate the tokens with the corresponding infrastructure (public callback URL necessary) yourself and enter them into the evcc configuration mentioned above. Alternative integrations via services such as [TeslaLogger](https://docs.evcc.io/docs/vehicles#teslalogger), [TeslaMate](https://docs.evcc.io/docs/vehicles#teslamate), [TeslaBleHttpProxy](https://docs.evcc.io/docs/vehicles#tesla-ble), [TeslaMate](https://docs.evcc.io/docs/vehicles#teslamate), [Tessie](https://docs.evcc.io/docs/vehicles#tessie) or [Tronity](https://docs.evcc.io/docs/vehicles#tronity) is also possible. Tesla Wall Connector owners can also still use [TeslaBleHttpProxy](https://github.com/wimaha/TeslaBleHttpProxy) as a local “Command Proxy”. ## Conclusion [Section titled “Conclusion”](#conclusion) We have discussed several alternatives for the Tesla integration. Special services and price levels for Tesla users were also on the table. We believe that our current solution from a user’s perspective is the best. On the one hand, it does not cause additional costs for most private users. The implementation remains sponsor-free. The API communication does not require third-party services. Users with larger fleets can also use evcc, where the API usage fees directly accrue at Tesla when the monthly free allowance is exceeded. **Best regards**\ The evcc team\ Michael, Andi & Uli # Highlights: Forecasts, Config UI With the [release of v0.200](https://github.com/evcc-io/evcc/releases), we’ve taken a major step towards stability and user-friendliness. In this blog post, we’ll provide some background on the version jump. For dramatic effect, we’ll save that for the end of the article ;) We’ll also introduce some new features that have been added since the [blog post in November](/en/blog/2024/11/22/highlights-charts-stats). ## Forecasts [Section titled “Forecasts”](#forecasts) We’ve had [CO₂-optimized](/en/features/co2) and [price-optimized](/en/features/dynamic-prices) charging for a while. Now, with [Forecast.solar](https://forecast.solar) and [Solcast](https://solcast.com/free-rooftop-solar-forecasting), we’ve integrated our first two PV production forecast providers. For this, there’s a new `solar` field in the [tariff configuration](/en/tariffs). When a PV forecast source is configured, you’ll see the expected PV production for today in kWh in the energy overview. Clicking on this number or the new **Forecast** menu item takes you to a new view that visualizes the expected PV production for the next 48 hours. This visualization also shows price and CO₂ forecasts. [](/_astro/forecasts.DWNI7WCY.mp4) ~~Currently, only one PV forecast (corresponding to one roof surface) can be configured. With the next release, we’ll add the ability to combine forecasts.~~\ This is now possible, see [PV forecast](/en/tariffs#pv-forecast). PV forecast data doesn’t yet influence charging planning but forms the foundation for future features and optimizations. ## Repeating Charging Plans [Section titled “Repeating Charging Plans”](#repeating-charging-plans) When evcc knows the vehicle’s state of charge, several useful charging features become available. The ability to establish a [minimum charge level](/en/features/limits#minimum-charge) immediately after plugging in has been around for a while. Charging the vehicle efficiently and cleanly using a [charging plan](/en/features/plans) (departure time and target charge level) is also a long-standing feature. Almost as old is the desire for repeating charging plans. That is, the ability to create weekday-dependent plans that don’t require constant attention. A big thank you goes to [@Maschga](https://github.com/Maschga), who tackled this major feature. The result turned out really nice.  Plans can be deactivated when needed (e.g., during vacation). Time zones, daylight saving time, and standard time are handled correctly 🤯. Multiple repeating plans are possible, and for closely scheduled plans, the most relevant plan is selected with the planner’s decision transparently visualized. Learn more about this under [Charging Plans](/en/features/plans#repeating-plans). ## Heat Pumps & SG-ready [Section titled “Heat Pumps & SG-ready”](#heat-pumps--sg-ready) The demand for heat pump support has come up regularly in recent months. Until now, we deliberately focused on the electric vehicle use case to keep evcc focused and manageable. Integration of heat generators was possible through methods like [relays, smart plugs](/en/smartswitches#heating) and the plugin interface ([example](https://github.com/naltatis/aton-ctrl)), and was being used. Since January, we’ve offer an explicit model for heat pump control. Many heat pumps support the SG-Ready model. Using a switchable relay (e.g., Shelly), the heat pump can be instructed to increase operation during surplus or low-cost grid power. Some heat pumps also support direct communication, e.g., over the network. The list of these devices is still relatively short. If you have such a heat pump and know how to control it, please open a [GitHub Issue](https://github.com/evcc-io/evcc/issues). You can find more information about [heat pumps & electic heaters](/en/heating) in the documentation. The integration of heat generators in the UI is functional but not yet perfect. Topics like time-based metrics and better representation of the heat pump in the main overview are on our to-do list. ## Config UI: Setup via Browser [Section titled “Config UI: Setup via Browser”](#config-ui-setup-via-browser) During evcc’s development, keeping the interface as simple and clean as possible has always been important to us. We regularly receive feedback that other household members (often non-nerds) quickly find their way around the interface. This is a quality that’s not always a given, especially in “classic” open-source projects, and something we’re quite proud of. An important factor is the strong unification and the underlying data model. Once an inverter, vehicle, or wallbox is configured, the peculiarities of the devices are no longer relevant in the UI. However, the biggest pain point for many users is actually reaching this “everything is set up” state. Until now, this required using the command line and editing a YAML file. We’ve been working for a long time to enable initial setup through the UI. Over the past years and months, we’ve gradually added individual functions like creating vehicles, meters, inverters, tariffs, and more. Necessary features like a log view and authentication system are now also on board. With v0.200, we’ve added the “last big piece” towards setup via UI. **Now charging points and wallboxes, the central components of evcc, can be created and modified through the UI.** This brings us noticeably closer to a stable 1.0 release. [](/_astro/config-ui.IX3z4-QI.mp4) The configuration interface is still marked as an experimental feature 🧪. Not all fields are in the right place, carry the correct descriptions, and are thoroughly tested. We therefore very much look forward to your feedback, suggestions, and bug reports. Advanced features, like creating custom devices and better diagnostic tools, are still on the agenda. You can find more about the status and progress around this topic in the [Epic Issue](https://github.com/evcc-io/evcc/issues/6029). ### Try Config UI [Section titled “Try Config UI”](#try-config-ui) If you want to try out the pure UI setup, you can **start evcc with an empty `evcc.yaml`**. You’ll get a welcome screen and can proceed with your configuration through the UI from there. Experimental features must be activated in the UI for this. ## And Much More… [Section titled “And Much More…”](#and-much-more) As usual in the highlights blog posts, this is just a small selection of all the topics being worked on. Since the last post in November, [over 250 Pull Requests](https://github.com/evcc-io/evcc/pulls?q=is%3Apr+is%3Amerged) 🤯 have been developed, reviewed, and successfully merged. You can find the complete list of topics in the [Release Notes](https://github.com/evcc-io/evcc/releases) on GitHub. **Best regards**\ The evcc Team\ Michael, Andi & Uli # evcc App for iOS & Android We did it! The first version of the evcc app for iOS and Android is ready. It can now be downloaded from the [Apple App Store](https://apps.apple.com/de/app/evcc-io/id6478510176) and [Google Play Store](https://play.google.com/store/apps/details?id=io.evcc.android). ## What does the app do? [Section titled “What does the app do?”](#what-does-the-app-do) The evcc app is a native wrapper for the evcc user interface, providing you with an optimized user experience on your smartphone or tablet. It comes with several practical features that make using your evcc installation much more comfortable: ### Easy Onboarding [Section titled “Easy Onboarding”](#easy-onboarding) * **Automatic Detection**: The app automatically finds evcc instances in your local network via mDNS. * **Manual Setup**: You can also add your evcc instance manually via URL. * **Demo Mode**: Curious? Just try out the app with our demo instance. ### Optimized User Interface [Section titled “Optimized User Interface”](#optimized-user-interface) * **Full-Screen View**: Use the evcc UI in full-screen mode without distracting browser elements. * **Adapted Design**: The user interface respects the peculiarities of your device (notch, rounded corners, etc.). * **Improved Gesture Control**: Swipe and navigate intuitively through the app without browser zoom or overscroll effects getting in the way. ### Reliable Connection [Section titled “Reliable Connection”](#reliable-connection) * **Online/Offline Detection**: The app shows a loading screen when your evcc instance is not reachable. * **Automatic Reconnection**: As soon as your instance is available again, the app automatically reconnects. * **No Misoperations**: Avoids misleading situations where the user interface is displayed but not functional, e.g., due to network issues. ### Flexibility [Section titled “Flexibility”](#flexibility) * **Change Server**: You can change the configured URL at any time - either in offline mode or via the “Change server” menu item. * **Light and Dark Design**: The native user interface automatically adapts to your device’s system settings. The app is another step towards making evcc even easier and more intuitive to use. You can now keep an even better eye on your charging station, PV system, and energy flow in your home - directly from your smartphone. P.S.: Do you have a Mac with Apple Silicon? Then you can use the iOS app directly there as well. ## The Technology Behind It [Section titled “The Technology Behind It”](#the-technology-behind-it) We relied on proven technologies when developing the app. At its core, the app is a native wrapper around our existing web view. We chose React Native in combination with Expo, which allows us to develop the app for iOS and Android with a shared codebase. This significantly reduces development effort and ensures that new features are quickly available on both platforms. The native components are written in TypeScript and kept to a minimum. For the design system, we use UI Kitten / Eva, which helps us create a consistent and appealing user interface. Like all our projects, the app is also open source. The source code is available on [GitHub](https://github.com/evcc-io/app). Bug reports, suggestions for improvements, and pull requests are welcome! ## Where are we headed? [Section titled “Where are we headed?”](#where-are-we-headed) The first version of the app is an important milestone, but we still have some exciting ideas for the future: ### Simplifying Remote Access [Section titled “Simplifying Remote Access”](#simplifying-remote-access) Currently, the app only works on the same network as your evcc installation. For remote access, you need to establish a secure connection yourself. This is already possible today with VPN solutions like Wireguard (in combination with a FritzBox) or Tailscale (with on-demand connections and Magic DNS), but it requires additional configuration. We don’t have concrete plans for direct integration into the app yet, but it’s definitely a topic we want to address in the medium term. ### Platform-Specific Features [Section titled “Platform-Specific Features”](#platform-specific-features) The native app forms the foundation for additional platform-specific features that wouldn’t be possible with a pure web application. These include push notifications to inform you about important events, and widgets for the home screen that give you a quick overview of the current status of your charging station and PV system. 💚 A big thank you to everyone who supports this project financially or through active participation. 🌟 One last thing: Please leave a rating in the [App Store](https://apps.apple.com/de/app/evcc-io/id6478510176) or [Play Store](https://play.google.com/store/apps/details?id=io.evcc.android) if you like the app! **Best regards**\ The evcc Team\ Michael, Andi & Uli # evcc App in F-Droid The [evcc App](/en/features/app) is now also available on F-Droid. F-Droid is an alternative Android app store that only provides free software without proprietary dependencies. In addition to the Google Play Store, Android users could alternatively download the evcc App as [APK from GitHub](https://github.com/evcc-io/app/releases/latest). Now it is also available on F-Droid. You can use it independently of Google account and Google infrastructure and update it conveniently. The evcc App is Open Source and contains no tracking. With the distribution via F-Droid, the potential tracking of the traditional app store operators also disappears. To ensure that the App you install contains only what you see in the GitHub repository, F-Droid offers the possibility to **build reproducibly**. This required some adjustments to our Expo-based build process. Thank you [Maschga](https://github.com/Maschga) and [linsui](https://gitlab.com/linsui) for the help! Here is the link to the store: [evcc App in F-Droid](https://f-droid.org/en/packages/io.evcc.android/) The new version 1.0.3 contains smaller bug fixes and improvements for iOS users. All details can be found in the [Release Notes](https://github.com/evcc-io/app/releases/tag/1.0.3). **Best regards**\ The evcc Team\ Michael, Andi & Uli # Community: Ulrike & Gunther from Alzenau The days are getting warmer. A good time for a new community portrait. This time, photographer [Detlef](https://hee.se) visited Ulrike and Gunther in the beautiful town of Alzenau in Bavaria, Germany. ## Maximal insulation or maximal PV? [Section titled “Maximal insulation or maximal PV?”](#maximal-insulation-or-maximal-pv) **Michael:** Hi you two, great that you are willing to participate in a community portrait. Let’s dive right into the topic: How did your journey into electric mobility begin? **Ulrike:** Our entry point into electric mobility was in 2018 with a Nissan Leaf, followed by a Model 3. We were still living in a rented apartment at that time. It was already quite adventurous, because we didn’t have our own parking space and there was a limited number of charging points. We had experimented with solar power on our camping trips. There, of course, on a smaller scale, to charge phones, for example.  When we moved into our new house, both topics came together: electric mobility and photovoltaics. This makes our life much easier today. It’s a great feeling to start the day with a fully charged car. **Gunther:** Exactly, I especially enjoy the quiet and the comfortable driving experience. As Ulrike already said, it was clear to us from the beginning: we need cheap electricity for the car. At the beginning, we still wondered whether we should focus on maximum insulation or better on maximum solar power. In the end, it was cheaper to install more PV modules on the east-west roof, than to insulate the house extensively. Now we have a new building with a lot of solar power, which allows us to heat our home and our cars even during bad weather.  It’s a great feeling to be independent of the grid for nine months a year thanks to our own solar power. Our energy costs for two EVs, a heat pump and our house are minimal and even drop negativ thanks to the extra solar panels on the garage. ## All Electric Household! [Section titled “All Electric Household!”](#all-electric-household) **Michael:** Wow, that sounds like a very consistent implementation. What is your exact tech setup?  **Gunther:** On the house roof we have 10.5 kWp after west-north-west and 8.4 kWp after east-south-east. The north garage has about 5.1 kWp flat on the east-west roof, so we end up with 24 kWp in total. Since we drive two EVs to work, we have a large battery with 33 kWh of usable capacity (E3DC home power station). So the cars can be charged with up to 12 kW from the battery in the evening after work, which gives flexibility during bad weather. **Ulrike:** We have consistently implemented “all electric” in the consumers in and around the house, so we don’t have additional consumers with other, fossil energy forms. This means a high electricity demand, but we can cover it well with the maximum utilization of all roof areas. It also helps to not be afraid of putting solar panels on the north side. Our large battery rounds off the system.  **Gunther:** Thanks to the many modules and the battery, the system is very economical and we can easily cover bad weather periods. From the beginning of November to the middle of February we draw grid power, otherwise we are self-sufficient. In 2024 our self-sufficiency was 75 %. This year we aim for 80 %! In addition to the PV systems and the usual household consumers, we have an E3DC-charger that is controlled by the home power station, and an Easee Home charger at the second parking space. This was later added for the second EV and is a simple, uncontrolled charger. Here evcc comes into play: It gives the Easee charger the necessary intelligence to optimally charge the second EV with surplus power and optimized for the dynamic Tibber tariff.  | Component | Details | | ------------------ | ----------------------------------------------------------- | | **solar system** | 24 kWp (10,5 kWp WNW, 8,4 kWp ESE, 5,1 kWp O/W on garage) | | **battery** | 33 kWh (E3DC home power station) | | **vehicles** | Tesla Model 3, VW ID.5 | | **chargers** | E3DC charger (garage), Easee Home (parting space, via evcc) | | **heat pump** | Daikin | | **dynamic tariff** | Tibber | ## More conscious in winter, more relaxed in summer [Section titled “More conscious in winter, more relaxed in summer”](#more-conscious-in-winter-more-relaxed-in-summer) **Michael:** How did this setup affect your daily routines? **Ulrike:** In winter and the transition period we are more conscious of energy consumption and plan ahead: when should we do the laundry, when should we charge the car? Expecially for the second wallbox evcc removes the mental load. We plug in and the system takes care of the rest. Very relaxing! In summer we have so much surplus energy that we don’t need to plan much. Our electrictiy consumtion even increased compared to before. ## Energie Stammtisch: Sharing knowledge locally [Section titled “Energie Stammtisch: Sharing knowledge locally”](#energie-stammtisch-sharing-knowledge-locally) **Michael:** Gunther, you are involved in the [Energie-Stammtisch Freigericht](https://www.energie-stammtisch-freigericht.de) That sounds interesting. How did it start?  **Gunther:** We are a group of mostly tech-savvy people who are involved in renewable energy projects in the region. We support the planning of solar systems, batteries, heat pumps and charging solutions at home and share our experiences. We organize balcony solar workshops and are active for the local wind energy expansion. The work is very motivating and benefits the people in the region. I myself came to the association through the topic of EVs and am now part of the executive committee there. Our [Facebook page](https://www.facebook.com/share/1RU91S4CHT/) gives deeper insights into our work. ## evcc: Nice, Real-Time and Practical [Section titled “evcc: Nice, Real-Time and Practical”](#evcc-nice-real-time-and-practical) **Michael:** That sounds like good tips and experiences. A really good tool to advance the energy transition in your own region and to involve your neighbors. Let’s talk about the software again. Do you have a favorite feature in evcc? Do you have any suggestions for improvement? **Ulrike:** The second-by-second resolution of evcc is great. We have an old phone stuck to the wall in our living room that displays the energy balance in real time. So we can see the energy balance in real time at second resolution. And the user interface is really nice. The surplus charging also works great with evcc. **Gunther:** I see improvement potential in the setup, which I did with the help of my neighbor at the time. The new web-based setup, on which you are working, is exactly the right direction. Regarding stability, i.e. when external interfaces do not work, evcc could react better.  **Ulrike:** I especially appreciate that I don’t have to worry about anything: just plug in the car, and evcc takes care of the rest. This is a real relief in everyday life. **Gunther:** Otherwise, evcc meets our needs in automation and visualization. We are happy to have such a well-designed energy management tool. **Michael:** That’s great, thank you for the feedback. Thank you for the insights into your energy world. It’s simply inspiring! *** **How does your evcc setup look like?** If you are interested in sharing your experiences, your path and your technology in the form of a community portrait, then please sign up [here in the form](https://airtable.com/appDI3xIiev1DOpMY/shrW1zGH26KElfZOK). We are especially looking for advanced installations or from users outside of Germany. # Community: Michael from Core Team We’ve gotten to know many users from the community over the past few months. Today’s portrait is a bit different: Photographer [Detlef](https://hee.se) takes on the interviewer role and talks with Michael from the evcc Core Team. ## “The best software is useless if nobody knows about it” [Section titled ““The best software is useless if nobody knows about it””](#the-best-software-is-useless-if-nobody-knows-about-it) **Detlef:** Today we’re switching roles and it’s your turn to answer questions. I got to know you and the project through one of your talks. Are you something like the “Head of evcc”? **Michael:** No, I wouldn’t describe myself like that. I’m part of the three-person core team together with [Andi](https://github.com/andig) and [Uli](https://github.com/premultiply). Together we work on this project and share the various tasks that come with an open-source project of this size. Besides my focus on UI development, I also take care of our visibility in public. That includes things like the website, blog articles, [stickers](https://github.com/evcc-io/evcc/discussions/4446), documentation, some social media, and the occasional appearance at conferences or in YouTube videos. I do this because I think that the best software is useless if nobody knows about it. ## From Naive Idea to Core Team Member [Section titled “From Naive Idea to Core Team Member”](#from-naive-idea-to-core-team-member) **Detlef:** What was your first contact with evcc? **Michael:** My first contact with evcc was probably like that of most users. We had ordered an electric car in 2020 and I was looking for a solution to charge it with excess solar energy. Quite naively, I thought I’d just buy a smart EV charger and that would be it. The reality was sobering: manufacturer-bound isolated solutions, cloud services, proprietary solutions - none of it was what I wanted. Then I came across evcc. The software was minimalistic, modular, and had an exciting tech stack with Go and Vue.js. The project was only a few months old at the time. I made my first contributions and quickly became part of the core team. Almost five years later, the software has come incredibly far.  ## Eat Your Own Dog Food [Section titled “Eat Your Own Dog Food”](#eat-your-own-dog-food) **Detlef:** I assume you have your own evcc installation running. What does it look like? **Michael:** Our journey began in 2017 with a 9.8 kWp south-facing solar system. Back then it was important to stay under the 10 kWp limit here in Germany. In 2023 we also filled the remaining north roof and carport with solar panels. In total, it’s now 18 kWp plus a 12.8 kWh home storage system. These additions have increased our self-sufficiency level.  Of course, we use evcc to charge our electric car with solar energy. But I also try to use all the other features we’ve built into the software so far. From March to October, an [evcc-controlled 3 kW electric heating element](https://github.com/naltatis/aton-ctrl) takes over hot water heating. It only uses solar surplus or very cheap grid electricity. Even our e-bike is connected to an outlet that only delivers power when the sun is shining. This isn’t really economically driven. Our pellet heating would heat the water a bit cheaper, the e-bike consumption is negligible compared to the car. But my point is to use the new functions myself in everyday life. True to the software development motto: [Eat your own dog food.](https://en.wikipedia.org/wiki/Eating_your_own_dog_food) | Component | Details | | ---------------------- | ----------------------------------------------------------------------------------------------- | | **PV System** | 18.1 kWp total 7.7 kWp south SolarEdge 9.0 kWp north Sungrow 1.4 kWp carport Hoymiles & AhoyDTU | | **Storage** | 12.8 kWh Sungrow | | **Vehicles** | Tesla Model 3 | | **Wallboxes** | Easee Home, Go-e Gemini | | **Heating Element** | 3 kW TA Aton via PWM | | **E-Bike** | Shelly 1PM | | **Electricity Tariff** | Octopus Energy | ## Community Power Instead of Expert Knowledge [Section titled “Community Power Instead of Expert Knowledge”](#community-power-instead-of-expert-knowledge) **Detlef:** evcc now supports hundreds of devices and services. Do you know them all? **Michael:** The feature scope, yes, but the details of individual integrations definitely not. Uli and Andi are the experts for device compatibility. New device integrations almost always come from community members who own the respective device. Sometimes these users are also developers who can provide pull requests. In most cases, we work together with users to come up with a solution. The beautiful thing about our system architecture is that for feature development, device-specific characteristics don’t matter. Our unified data model ensures that working with e.g. home batteries always works the same, independent of brand and model. If a device offers additional functions like phase switching or controllability, additional options automatically appear in the user interface.  ## Open-Source vs. Commercial Solutions [Section titled “Open-Source vs. Commercial Solutions”](#open-source-vs-commercial-solutions) **Detlef:** Let’s talk about Open-Source. Does this still excite you after all these years? **Michael:** Absolutely. Open-Source is unbeatable: We create a kind of database that uniformly processes interfaces to almost all EV chargers, inverters, and other devices. This idea of *free knowledge* is fascinating and an incredibly valuable resource - also for other projects. **Detlef:** Many manufacturers offer proprietary systems, some inverters are opening up. What does this mean for your project? **Michael:** You’re right. Many manufacturers now integrate intelligent charging functions. In an ideal world, intelligent energy management should be as simple as possible. Tesla does this relatively well with their Powerwall, charger and vehicle combination. But as soon as you leave the ecosystem - different vehicle, integrate heat pump - it gets complicated. This is where solutions like evcc are needed. **Detlef:** Do you believe that evcc will find users beyond IT enthusiasts? **Michael:** I think so. Today you still need some technical background or at least some love for tinkering. But we’re working on making the initial setup as comfortable as a home router setup. This makes the software accessible to less technically-savvy users as well. Of course, cloud services are even easier to use: sign up, enter credentials, done. But then you depend on the cloud provider and have to trust in privacy and stability. A local solution in your own four walls gives you full control. Independence, stability, and data sovereignty are important criteria. ## No Magic, No Checkbox Flood [Section titled “No Magic, No Checkbox Flood”](#no-magic-no-checkbox-flood) **Detlef:** With the feature requests on GitHub, you can’t satisfy everyone. Who decides what goes into the next version? **Michael:** Various factors play a role. Our guideline is not to overload the UI with settings that need explanation, but also not to implement “magical behaviour” that could surprise users. These goals sometimes contradict each other. When in doubt, we reject feature requests - but thanks to open interfaces, many features can also be implemented externally first with custom scripts or Home Assistant. Demand naturally also plays a role. We supported heat generators only as plugins for a long time to focus on our core functions, charging electric cars. Since the beginning of the year, however, we’ve integrated heat pumps from over 20 manufacturers - simply because so many users wanted it and most of the necessary mechanisms already existed in evcc.  ## No Roadmap, No World Domination [Section titled “No Roadmap, No World Domination”](#no-roadmap-no-world-domination) **Detlef:** evcc was always a project for vendor-independent charging solutions for me - today it’s virtually a universal EMS. How do you see the future? **Michael:** Interesting question. There’s no official roadmap. The community financing model gives us freedom: no external constraints, no milestones or world domination goals with fixed deadlines. Our only motivation is to optimally adapt the software to user wishes. The community keeps the project alive and sets the direction. Whether we call ourselves “Universal EMS” and can check all product comparison checkboxes - that’s not important for us. What’s important is that we deliver solutions for users’ real needs. Regarding the future: A frequently requested feature is visualizations and statistics that go beyond charging sessions. So a kind of “dashboard” like you know from inverter manufacturer apps. We already have a lot of ideas for this. Another big topic is improvements to intelligent control. We’re planning to incorporate production and consumption forecasts into our algorithms. Good integration for external optimization systems and AI-based services are also important. We’re always looking for committed contributors here too. If you’re interested, feel free to contact us on Slack. **Detlef:** From me and on behalf of all evcc users: Thank you very much for driving the project forward like this. It delights me over and over again to charge my car with self-generated energy. **Michael:** Thanks for the questions and the opportunity to experience the interview format from the other side. *** **Community portraits wanted!** Have you already contributed code to evcc? Then feel free to get in touch [here](https://airtable.com/appDI3xIiev1DOpMY/shrW1zGH26KElfZOK). We’re currently looking for portraits of active community members. # Highlights: Config UI, Feed-in & AI Time for a new feature roundup! I’ve selected a handful of interesting topics. Before we get to the features, an important announcement for all REST API users. ## Breaking change: REST API [Section titled “Breaking change: REST API”](#breaking-change-rest-api) With release v0.207, there’s a change to the REST API. The endpoints remain unchanged, but the response format will be streamlined. Specifically, the outer `result` level is being removed. Here’s an example for the endpoint `GET /api/state`: Current JSON response: ```json { "result": { "loadpoints": [...], ... } } ``` Future JSON response: ```json { "loadpoints": [...], ... } ``` The maintainers of popular evcc integrations have been informed and have already made the necessary adjustments. Users with their own scripts or automations that directly access the REST API must adapt these themselves. More details are available in the corresponding [GitHub Issue.](https://github.com/evcc-io/evcc/pull/22299) Migration notes To ease the transition, we’ve released two versions: **v0.206 and v0.207 are feature-identical**. The API changes are **included from v0.207** onwards. If the new response format causes problems, you can downgrade to v0.206. This gives you all the new features described here and allows you to prepare your scripts and integrations for the breaking change at your own pace. ## Plans: Late charging [Section titled “Plans: Late charging”](#plans-late-charging) Charge plans have received a new feature: *Late Charging*. By default, the planning algorithm optimizes charging to occur during the cheapest or cleanest hours. However, it can also make sense to charge the vehicle late, i.e., to match the set target time. Use cases include: * **Preconditioning**: Especially in winter, it can be beneficial to warm the vehicle battery by charging at departure time. This saves energy because less active climate control is needed during the drive. * **Climate control**: If you have climate control activated in the car at departure time, this setting ensures that the required energy is drawn from the EV charger and not from the car battery. * **Battery care**: When charging to 100% before long trips, the battery shouldn’t sit fully charged for extended periods.  In addition to the checkbox for activating late charging, you can also set the duration that should be charged directly beforehand. This allows you to, for example, continue charging the majority at price-optimized times, but only fully charge the car in the last hour, as shown in the screenshot above. More details can be found in the [documentation](/en/features/plans#late-charging). []() ## Configuration via browser [Section titled “Configuration via browser”](#configuration-via-browser) A lot of progress is being made on the topic of initial setup via browser. For a few weeks now, it’s been possible to set up without `evcc.yaml`, although previously this always started in [demo mode](https://demo.evcc.io/). Now the setup starts with a selection dialog: * Classic configuration with `evcc.yaml` * Browser-based configuration *🧪 experimental* In the following video, you can see the configuration process with multiple vehicles, meters, solar/battery systems, EV chargers, and heat pumps: [](/_astro/config-ui.C4LwKdZ5.mp4) ### Demo mode [Section titled “Demo mode”](#demo-mode) To test the interface without configuration, the demo mode is still available. This can be started with the [CLI flag](https://docs.evcc.io/docs/reference/cli/evcc) `--demo`. In this mode solar, battery and EV chargers use simulated data. Additionally, the authentication system is disabled, and thus all protected functions (configuration, logs, …) are deactivated. ### User-defined Devices (Plugins) [Section titled “User-defined Devices (Plugins)”](#user-defined-devices-plugins) Through the configuration interface, vehicles, meters, PV/battery systems, EV chargers, tariffs, smart switches, and heat pumps could already be created. This is based on our large library of device templates for now over 550 products. Another strength is the [flexible plugin system](/en/reference/plugins). This allows even exotic devices and integrations to be connected using HTTP, Modbus, Script, MQTT, etc. These user-defined devices (`type: custom`) previously had to be configured via `evcc.yaml`. Now this is also possible via the UI – conveniently with syntax highlighting, validation, and test function.  ### Charging & heating [Section titled “Charging & heating”](#charging--heating) The origin of evcc is intelligent charging of electric cars. Meanwhile, the system also supports a growing list of heat pumps and heating rods. The basic optimization goals like efficient use of own energy or cost-optimized charging from the grid are identical in both areas. However, the control behavior, visualization requirements, and setting options differ in detail. In the configuration interface, the *Charging Points* section has therefore been renamed to *Charging & Heating*. The setup flow has also been revised to show the settings relevant to the respective use case. In the [video above](#config-ui) (from 2:10) you can see the different workflows for charging and heating. Here’s a screenshot of the first setup dialog:  In upcoming releases, there will be further steps to make *heating* a first-class citizen in evcc. More details can be found in this [GitHub Issue](https://github.com/evcc-io/evcc/issues/19753). ### Backup & restore [Section titled “Backup & restore”](#backup--restore) Now that more and more functions are moving to the UI, new questions arise: * How can I back up my configuration? * How do I migrate my installation to a new system? * Can I reset the configuration and start from scratch? To answer these questions, we’ve implemented a backup & restore function. This allows you to back up the evcc database on your computer, restore a saved state, or delete the configuration while, for example, keeping the charging history.  A big shoutout to [@maschga](https://github.com/maschga) for support in the implementation. ### More to come [Section titled “More to come”](#more-to-come) The number of open todos regarding setup via browser is becoming increasingly smaller. There are still some devices that cannot be created, and the topic of debug information for GitHub issues still needs improvement. And of course, there’s always room for improvement in existing functions. However, it’s now foreseeable that configuration via web interface will soon become the new standard. Version 1.0.0 is getting closer. Note: Configuration via `evcc.yaml` will continue to be possible in the future. ## Dynamic feed-in [Section titled “Dynamic feed-in”](#dynamic-feed-in) With [dynamic electricity tariffs](/en/features/dynamic-prices), you can adapt charging and heating behavior to the current price situation. This feature is now also available for feed-in. If you have a tariff with [dynamic feed-in prices](/en/features/dynamic-feedin) (e.g., direct marketing, dynamic grid fees, Netherlands, Australia, …), the [prioritize feed-in](/en/features/dynamic-feedin#feed-in-priority) function appears in the settings dialog at the charging point.  This allows you to pause charging or heating during times when it’s more lucrative to feed energy into the grid. You can set a fixed price limit for this. Automation via external scripts or systems via API is of course also possible. In upcoming releases, we will implement more features related to dynamic feed-in. We’re experimenting with pausing feed-in during times with negative prices and reducing production. More about this [here](https://github.com/evcc-io/evcc/issues/21747). ## AI Integration via MCP 🧪 [Section titled “AI Integration via MCP 🧪”](#ai-integration-via-mcp-) With the [Model Context Protocol](https://en.wikipedia.org/wiki/Model_Context_Protocol) (MCP for short), it’s possible to give LLMs like Claude, Gemini, and ChatGPT structured access to external systems, such as evcc. When experimental is activated [MCP](/en/integrations/mcp), an experimental MCP server will be enabled in evcc. You can include the new endpoint (e.g., `http://evcc.local:7070/mcp`) in your LLM’s configuration. The topic of MCP and the available tools are still very young and constantly changing. However, we see great potential and exciting new possibilities here – especially in the area of optimization and automation with local models. The following video shows an example of evcc working with Claude Code (Sonnet 4): [](/_astro/mcp-integration.D0_ADKoY.mp4) Request: *“The user wants to drive to Hamburg tomorrow at 8 AM with his Tesla.”* The LLM … * … identifies the correct charging point: “white Model 3” * … calculates the distance: Bremen (Title) -> Hamburg (Request) * … calculates the required charge level: 90% * … creates a charging plan: 90% at 8 AM for the Tesla Model 3 * … switches the charging mode from “Off” to “Solar” since plans are only active in (Min+)Solar mode Finally, it queries the charging plan calculated by evcc and returns it to the user. This relatively simple example shows quite well where the journey could go in the future. We’re excited to see how the topic of MCP develops. Feel free to try it out yourself and share your experiences in the [GitHub Discussions](https://github.com/evcc-io/evcc/discussions). More details on using MCP with e.g., Claude Code can be found in the [documentation](/en/integrations/mcp). ## Production, battery and charging points expandable [Section titled “Production, battery and charging points expandable”](#production-battery-and-charging-points-expandable) If you have multiple solar/battery systems or charging points configured, you can now expand them in the energy flow view to see more details. Devices created via the configuration interface can be given a name for this purpose. Note Naming solar, battery and other meters is not possible via `evcc.yaml` for technical reasons. ## New device support [Section titled “New device support”](#new-device-support) Since February, we’ve added several new device manufacturers: * **EV chargers:** Ampure, Autoaid, Charge Amps, Elecq, eledio, EN+, enercab, EntraTek, Free2Move, Free2move eSolutions, Huawei, Kathrein, Plugchoice, Volt Time, ZJ Beny * **Smart switches:** Home Assistant * **Heat pumps & electric heaters:** alpha innotec, Bosch, Buderus, Bösch, CTA All-In-One, Daikin, Elco, IDM, Junkers, Kermi, Lambda, my-PV, Nibe, Novelan, Roth, Stiebel Eltron, Tecalor, Vaillant, Viessmann, Wolf, Zewotherm * **Meters:** Axitec, Bosch, IAMMETER, IOmeter, ORNO, Saia-Burgess Controls (SBC), Sigenergy, Wago * **PV/Battery Systems:** Axitec, batterX, Bosch, IAMMETER, Marstek, Sigenergy * **Vehicles:** Toyota Of course, bug fixes and improvements to existing implementations were also made. ## Much More … [Section titled “Much More …”](#much-more-) This is just an excerpt. The full list of new features can be found as usual in the [GitHub Release Notes](https://github.com/evcc-io/evcc/releases). Big thanks to everyone actively participating in the development of evcc. You rock 🤘. **Best regards**\ The evcc Team\ Michael, Andi & Uli # Community: Tobias from Trebur Tobias transformed his house in Trebur in southern Hesse step by step from a gas heating household into a largely energy-independent smart home. Photographer [Detlef](https://hee.se) visited and took photos. ## Energy Independence Instead of Gas Heating [Section titled “Energy Independence Instead of Gas Heating”](#energy-independence-instead-of-gas-heating) **Michael:** Hi Tobias, it’s great that you’re taking the time to show us your home and the technical setup. Perhaps you’d like to introduce yourself briefly? **Tobias:** Hi Michael, great that we’re doing this. So, my name is Tobias and I’m 41 years old. Like some of my portrait predecessors, I have a background in computer science and am a passionate tinkerer when it comes to energy efficiency and smart home technology. My family and I inherited a detached house a few years ago and have been gradually improving everything since moving in over 10 years ago. We always looked for ways to reduce our utility costs. It was basically a step-by-step transformation from a gas heating household to a largely energy-independent smart home. **Michael:** Okay, that sounds like a lot of work, but also like you end up with customised solutions that fit your habits and living needs perfectly. Did you still have time to take care of other things? **Tobias:** Of course! One of the bigger challenges was replacing our gas heating with a heat pump. We commissioned a nationwide operating contractor for the complete system. Unfortunately, the installation was chaotic: three planned days turned into a week, they had forgotten the electrical connection, and afterwards various technical problems occurred – from incorrect buffer tank connections to an oversized circulation pump. After several corrections, our own research and the contractor’s insolvency, we had to make the final adjustments ourselves. Today the heat pump runs stably and efficiently with renewable electricity from our own roof – the journey was rocky, but it was worth it. ## From Hybrid to Fully Electric [Section titled “From Hybrid to Fully Electric”](#from-hybrid-to-fully-electric) **Michael:** That sounds like a real test of patience. But good that everything works in the end. How did you get into electric mobility? **Tobias:** A few years ago we got a plug-in hybrid, a VW Passat. The solar system followed somewhat later. The aim back then was to achieve about 10 kWp of power without having to give up the solar thermal system. Setting up the solar system was initially a bit like a puzzle because the supplier delivered two extra modules and we had to figure out how to install them as well. Well, if they’re already there, we wanted to use them too. After the solar system was up, came the first proper EV, a Tesla Model Y, and shortly afterwards the second, an Ora Funky Cat. Initially we had a KEBA P-30 charger. That didn’t work so well and we replaced it with a WARP Charger 2 Pro. With the arrival of the second EV we installed a second charger. To optimally use the solar surplus, the WARP Energy Manager was added to enable 1-phase/3-phase switching. Meanwhile, we upgraded both chargers to WARP Charger 3 with integrated phase switching to simplify the system.  ## Load Management Instead of Power Upgrade [Section titled “Load Management Instead of Power Upgrade”](#load-management-instead-of-power-upgrade) **Michael:** You’re already hinting at it, now we’re getting to where and why you use evcc…? **Tobias:** That’s right, now we’re getting into the details. Initially I used evcc as a Docker container on a Proxmox cluster. Over time, I got more and more involved with Home Assistant and now only run a Home Assistant Yellow with PoE, CM4 with 8 GB RAM and a 1 TB SSD to save power here as well. I used evcc as an add-on in Home Assistant. **Michael:** What does your set-up look like?  **Tobias:** Our system currently consists of a 10.1 kWp solar system (27x Heckert Solar NeMo), a 16 kWh Sungrow battery, 2 WARP Charger 3 Pro, a Vaillant heat pump (Arotherm plus) and a sauna (9 kW). Balancing the different consumers, storage and producers required some fine-tuning, but that’s somehow fun.  We currently have direct metering for electricity consumption in our house distribution. This means the meter can be permanently loaded with 44 A (30.4 kW). So we had to decide: either carry out a power upgrade with current transformer metering or control the whole thing via dynamic load management. For cost reasons, we initially opted for dynamic load management. We don’t actively measure the sauna’s power, so we work with two areas in evcc. The area (Main) has a current limit of 44 A and the area (Driveway) has a maximum of 32 A. Both chargers share the 32 A from the area (Driveway), so theoretically one charger could always charge at 22 kW, even though hardly any vehicle currently supports this. We assign the sauna and heat pump to the area (Main). They always have priority over the two chargers. This ensures that the main connection is never loaded with more than 44 A. If the sauna and heat pump are running at full capacity while we’re baking biscuits, evcc would temporarily reduce the charging power of our cars.  | Component | Details | | ---------------- | -------------------------------------------------------------- | | **Solar System** | 10.1 kWp (27x Heckert Solar NeMo 3.0 120M) | | **Inverter** | Sungrow SH10.0RT Hybrid | | **Battery** | Sungrow SBR 16 kWh | | **Chargers** | 2x WARP Charger 3 Pro | | **Vehicles** | Tesla Model Y, Ora Funky Cat | | **Heat Pump** | Vaillant Arotherm plus vwl 125/6 | | **Sauna** | 9 kW electric heater | | **Control** | evcc as Home Assistant add-on (Home Assistant Yellow with PoE) | ## From PV Magazine to evcc [Section titled “From PV Magazine to evcc”](#from-pv-magazine-to-evcc) **Michael:** Great, you have two chargers, a sauna and the usual household consumers covered. How did you come across evcc? **Tobias:** Through an article in PV Magazine in 2022. At that point we already knew we would install a solar system and wanted to use the surplus as efficiently as possible. Back then there were only very expensive solutions or solutions that only worked well within the manufacturer’s own ecosystem. **Michael:** Yes, that was also a reason why I think the project is so cool: surplus charging. What other features do you use, or is that actually the main use case? **Tobias:** Well, until last year we also had Tibber, which meant evcc controlled cheap charging for the cars. With the installation of the heat pump and the upcoming challenges, we switched back to a cheaper, fixed electricity tariff and needed load management. That’s where evcc could shine. So we use it to control the chargers, integrate the vehicles and for load management. I configured the heat pump control, but don’t currently use it because it doesn’t make sense with the solar thermal system.  ## Wishes for the Future [Section titled “Wishes for the Future”](#wishes-for-the-future) **Michael:** What do you wish for from evcc? Which area should we invest more energy in? **Tobias:** I’d like to see direct integration of the Vaillant heat pump via EEBUS or EBUS. I think there’s still potential there. Overall I can say that we’ve learnt a lot and achieved a lot. I’m really proud of what we’ve accomplished: the house has an efficient (and more sustainable) heating system, the solar system produces what we need during the day, and together with the buffer tank gives us a high degree of independence. **Michael:** Thanks, that’s a good point. And thank you very much for showing us how it works at your place. I’m sure this will inspire one person or another to make changes to their set-up. *** **What does your evcc set-up look like?** If you’re interested in sharing your experiences, your journey and your technology in the form of a community portrait, please register [here in the form](https://airtable.com/appDI3xIiev1DOpMY/shrW1zGH26KElfZOK). We’re particularly looking for portraits of exceptional installations or from users outside Germany. # Community: Osnabrück Rowing Club A large boathouse, showers for dozens of rowers and lots of roof space: the [Osnabrücker Ruderverein](https://www.orv.de) (ORV) has found a way to reduce energy consumption whilst becoming more independent from fossil fuels using solar power and evcc. Photographer [Detlef](https://hee.se) paid them a visit. ## From Solar Thermal to Solar PV [Section titled “From Solar Thermal to Solar PV”](#from-solar-thermal-to-solar-pv) **Michael (evcc):** Hi Michael, hi Markus, great that you’re taking the time. A large boathouse roof: that’s perfect for solar panels. How did you convince the club to invest? **Michael (ORV):** We had a solar thermal system on the roof until a few years ago, but it suffered total economic failure. As part of an energy renovation, a solar system was naturally on the agenda. The initial trigger was rising electricity prices, but also independence from gas. Since we were able to complete many tasks through volunteer work from club members, the investment was significantly lower than initially estimated. That convinced the members.  **Michael (evcc):** How much of the roof area have you been able to cover? **Markus (ORV):** Currently only about a quarter of the roof area is covered with a 30 kWp system. But we can’t install more due to regulations, and we’re already maxing out the grid connection. If that changes, we’d like to expand the system ourselves through volunteer work. ## Hot Water for Dozens of Rowers [Section titled “Hot Water for Dozens of Rowers”](#hot-water-for-dozens-of-rowers) **Michael (evcc):** How did evcc come into play? Were there alternative considerations? **Michael (ORV):** Our first chairman was already using evcc at home for his solar system, and the experiences were positive. It made sense to use it at the club too. **Michael (evcc):** And what does your technical setup look like? **Markus (ORV):** We have a Sungrow system with 29.92 kWp, a 12 kW battery, a My-PV AC-Thor 9s with one regulated 6 kW heating element and one unregulated 6 kW heating element on the relay. Each installed in a hot water storage tank. The software runs on a repurposed Dell PC that consumes a frugal 15 W. Proxmox is installed on it, Home Assistant runs in a VM and evcc in a container. We also upgraded our tech infrastructure last year for a stable and future-proof system.  **Michael (evcc):** How many people shower on a typical day with your solar heating element and has the water ever been too cold? **Michael (ORV):** It’s hard to say how many people shower per day. Since we installed water-saving heads and timers, they definitely shower for less time. That benefits our gas savings. The water can’t get too cold because we have a gas heater that warms the water as soon as it drops below 36°C.  ## 5,742 kWh of Gas Saved [Section titled “5,742 kWh of Gas Saved”](#5742-kwh-of-gas-saved) **Michael (evcc):** Can you already say how much gas has been saved through your heating elements? **Markus (ORV):** We can analyse the consumption per heating element with Home Assistant. By mid-September, we’d heated water with at least 5,742 kWh of solar electricity. That should correspond roughly to the same amount of gas. Since we’re still in the testing phase, we don’t have long-term experience yet.  **Michael (evcc):** Would you still have electricity left over for a members’ wallbox or other consumers? **Michael (ORV):** We currently feed the surplus into the grid. Since the heating elements went live, there’s not enough surplus left to make battery charging worthwhile. But we’re already planning to install EV chargers in the future.  | Component | Details | | -------------------- | ----------------------------------------------------------------------------- | | **Solar System** | 29.92 kWp (approx. 1/4 of available roof area) | | **Inverter** | Sungrow | | **Battery** | 12 kWh | | **Hot Water System** | My-PV AC-Thor 9s with 2x heating elements (6 kW regulated + 6 kW unregulated) | | **Hot Water Tanks** | 2 units | | **Control** | evcc in container on Proxmox, Home Assistant in VM | | **Hardware** | Dell PC (15 W consumption) | ## Heat Pump vs. Heating Element [Section titled “Heat Pump vs. Heating Element”](#heat-pump-vs-heating-element) **Michael (evcc):** A heat pump is significantly more efficient than a heating element. You currently use heating elements for your hot water. Why did you choose this and do you already have plans for a heat pump? **Michael (ORV):** We’ve already discussed the heat pump topic. However, our heating needs as a club differ significantly from typical installations. Classic rules of thumb don’t necessarily apply and we want to size the system according to our needs. We also want to be able to assess whether a combined heating/hot water heat pump or separate systems are better for us. Our gas heating is currently fully functional. We’re currently collecting comprehensive data on consumption, peak demand etc. with Home Assistant. Our goal is to heat completely without gas next summer. We’re very confident about that. **Markus (ORV):** Since we have to manage the projects in our spare time, we keep the number of parallel projects low so that we actually get things finished. (laughs) Plus the heating room is full, when a heat pump comes in, the gas boiler has to go out. ## From Treasurer Duties to the Water [Section titled “From Treasurer Duties to the Water”](#from-treasurer-duties-to-the-water) **Michael (evcc):** Michael and Markus, you’re the two technical souls of the Osnabrücker Ruderverein: how often do club members see you in a boat, or just in the technical room? **Markus (ORV):** Since I handed over the treasurer position in spring, I’ve resolved to get on the water more often.  **Michael (ORV):** I took over the board position for facilities three years ago and yes, the proportion of work at and for the club has become much higher. Nevertheless, I usually still manage to go rowing once at the weekend.  ## Wishes for the Future [Section titled “Wishes for the Future”](#wishes-for-the-future) **Michael (evcc):** Do you have wishes for the future and further development of evcc? **Markus (ORV):** Definitely: a function that ensures water is primarily heated during mornings and daytime, but the battery is 100% charged by nightfall would be our next wish. To preserve the battery and for grid-friendly feed-in, throttling the charging power would also be nice.  **Michael (evcc):** Thanks for the great suggestions. Since evcc started with EV charging, we still have a lot to improve when it comes to heating use-cases. But there are things to come in the future. Thanks for the insights into your energy world at the rowing club. It nicely shows how evcc can work in larger community facilities too! *** **What does your evcc setup look like?** If you’re interested in sharing your experience, journey and technology in the form of a community portrait, please sign up [here on the form](https://airtable.com/appDI3xIiev1DOpMY/shrW1zGH26KElfZOK). We’re especially looking for portraits of exceptional installations or users outside Germany. *** *Update 19 December 2025: We added the section “Heat Pump vs. Heating Element”.* # Invitation: Community Meetup We invite you to the first evcc community meetup! On **18 April 2026**, we’ll meet in Osnabrück to get to know each other, exchange ideas, and have a barbecue together. The [Osnabrück Rowing Club](https://www.orv.de) kindly provides us with their facilities. ## What to Expect [Section titled “What to Expect”](#what-to-expect) The meetup takes place in the **afternoon** and has space for **100 participants**. We’ve planned a relaxed programme: * **Getting to know each other**: Put faces to GitHub usernames * **Exchange**: Discussions about your evcc setups and experiences * **Networking**: Connect with other evcc users and developers * **Barbecue**: Wrap up the day with food and drinks  ## Registration [Section titled “Registration”](#registration) Registration is handled through the rowing club’s booking system. There’s a **contribution of €10**, which also covers the barbecue food. **[Register now →](https://widgets.yolawo.de/w/0/bookables/692e18b1db6c17d85beacfd2?t=1764767521803)** During registration, you can optionally add your city. This helps us get an idea of where people are travelling from. ## Location [Section titled “Location”](#location) [](https://maps.app.goo.gl/75RsYsPpeBuNLsWC6) **[View on Google Maps →](https://maps.app.goo.gl/75RsYsPpeBuNLsWC6)** **Osnabrücker Ruderverein e.V.**\ Glückaufstraße 16\ 49090 Osnabrück The rowing club is located directly at the Stichkanal and offers a great atmosphere for our meetup. As you can read in the [community portrait](/en/blog/2025/11/29/osnabruecker-ruderverein), the club uses evcc for its own energy management. We’re incredibly excited to finally see some faces behind the GitHub usernames! Whether you’re a user or developer, whether you’ve been around for a while or just started with evcc: come along! If you have any questions, feel free to reach out in the [GitHub Discussions thread](https://github.com/evcc-io/evcc/discussions/25787). **See you in April in Osnabrück!**\ The evcc Team\ Michael, Andi & Uli # Your Car, Your Data? Support the EU Data Act Petition! Your car constantly collects data – but you can’t access it. The EU Data Act, in effect since 12 September 2025, should change that. Reality looks different: Most car manufacturers offer no or very limited access. ## Why evcc Needs Vehicle Data [Section titled “Why evcc Needs Vehicle Data”](#why-evcc-needs-vehicle-data) evcc optimises charging your electric vehicle with solar surplus. For this, we need real-time data from your vehicle: state of charge, range, charging status. Currently, we often rely on reverse-engineered APIs. This works, but isn’t a sustainable solution. Official APIs would enable: * **Reliable surplus charging** with current battery and charging data * **Better battery management** through precise control * **Energy cost optimisation** with dynamic tariffs * **Grid stability** through intelligent load distribution ## Why This Affects You Too [Section titled “Why This Affects You Too”](#why-this-affects-you-too) “Mine works fine” – we hear that often. The reality behind it: Most vehicle integrations in evcc are based on unofficial, undocumented APIs. Developers spend their free time analysing how manufacturer apps communicate internally and build their integrations on that. This works – but only until the manufacturer changes something in their systems. Then the integration breaks without warning. This has happened repeatedly in the past and will continue to happen. The problem doesn’t just affect evcc. All open source solutions like Home Assistant face the same challenge. As long as manufacturers don’t provide official access, it remains a constant cat-and-mouse game with an uncertain outcome. With official interfaces it would be different: documented, stable, reliable. You could rely on your integration not suddenly stopping to work. ## Electric Mobility and Energy Transition [Section titled “Electric Mobility and Energy Transition”](#electric-mobility-and-energy-transition) Open data access is important for the energy transition. Vehicle-to-Grid (V2G) requires bidirectional data exchange. Smart home integration only works with real-time data. Optimised charging reduces CO₂ emissions and electricity costs. ## The Reality: Limited Access [Section titled “The Reality: Limited Access”](#the-reality-limited-access) The EU Data Act is law. Implementation by manufacturers varies greatly. **BMW** and **Tesla** offer API access. **Many others tell a different story:** Some manufacturers provide data upon request via email. Others have web forms where you receive 15-minute-old data as a ZIP file. These are not practical solutions for real-time applications like smart charging. **Data APIs already exist:** Vehicle data is already available in good quality and via API. However, only for third-party companies who pay for access. Data access is a business model for manufacturers in the B2B sector. Vehicle owners often don’t get this direct access. In our [GitHub discussion](https://github.com/evcc-io/evcc/discussions/23684) we’re collecting the current status per manufacturer. ## What Does the EU Say? [Section titled “What Does the EU Say?”](#what-does-the-eu-say) The [European Commission published clear guidelines in September 2025](https://digital-strategy.ec.europa.eu/en/library/guidance-vehicle-data-accompanying-data-act): **Users have the right to:** * Raw and pre-processed vehicle data * Easy, free access to their own data * Data in the same quality as the manufacturer uses * Sharing with third parties of their choice **Manufacturers must:** * Make data easily and directly accessible * Without additional costs for personal use * In machine-readable format * Including metadata for interpretation The legal foundation exists. Practical implementation is still lacking. ## The Petition [Section titled “The Petition”](#the-petition) Maximilian Hauser from the evcc community has started a [petition](https://www.change.org/p/eu-data-act-durchsetzen-autohersteller-m%C3%BCssen-uns-zugang-zu-unseren-fahrzeugdaten-geben) to advance implementation of the Data Act. **What’s demanded:** * German Federal Network Agency to enforce the Data Act * Clear technical standards for APIs * REST API with OAuth 2.0 * At least 12 requests per hour per vehicle * Public API documentation * 99% monthly availability ## What You Can Do Now [Section titled “What You Can Do Now”](#what-you-can-do-now) ### 1. Sign the Petition [Section titled “1. Sign the Petition”](#1-sign-the-petition) 👉 **[Sign here](https://www.change.org/p/eu-data-act-durchsetzen-autohersteller-m%C3%BCssen-uns-zugang-zu-unseren-fahrzeugdaten-geben)** 👈 ### 2. Contact Your Manufacturer [Section titled “2. Contact Your Manufacturer”](#2-contact-your-manufacturer) Ask your car manufacturer for API access according to the EU Data Act. Reference the EU guidelines. The more requests come in, the more likely things will move. ### 3. Spread the Word [Section titled “3. Spread the Word”](#3-spread-the-word) Share the petition in your network: forums, Discord servers, Facebook groups, friends and family. Reach out to your favourite YouTube channels covering e-mobility, smart home and renewable energy. *** The Data Act is here. Implementation needs pressure from users. # Highlights: Browser Config is Here! 2026 is here and with evcc [v0.300](https://github.com/evcc-io/evcc/releases/tag/0.300.2), the new year starts with probably the most important milestone: Browser-based configuration is no longer experimental. The most requested feature is finally ready for production use. New users can now set up evcc completely without command line or YAML files. In this article, we look at the highlights since [July 2025](/en/blog/2025/07/30/highlights-config-ui-feedin-ai) and provide an outlook for the coming year. ## Browser-Based Configuration [Section titled “Browser-Based Configuration”](#browser-based-configuration) Initial setup via command line and editing YAML files has long been the biggest hurdle for new users. We’ve been working for several years to simplify this process. With v0.300, the time has come: **Browser-based configuration via web UI is now officially released and the recommended way for new users.** ### What’s New? [Section titled “What’s New?”](#whats-new) Since the last highlights article, we’ve added and improved many features: * **Bug Reporting Directly in Web UI:** Diagnostic information can now be exported for GitHub issues directly through the interface. * **OCPP Setup:** The setup process for OCPP wallboxes has been significantly simplified. * **Modbus Proxy UI:** Comfortable interface for Modbus proxy configuration. * **OAuth Authentication:** UI-based authorisation flow for BMW, Mini, Viessmann, Home Assistant, Volvo and other services. * **Dynamic Suggestions:** Smart suggestion values simplify configuration. Used e.g. for sensors and switches in Home Assistant. Coming soon for Modbus settings and network devices. * Many additional bugfixes and improvements. ### What’s Still Missing? [Section titled “What’s Still Missing?”](#whats-still-missing) All functions can be configured via the UI. However, YAML syntax is still required in some places. * Tariffs and forecasts * Load management and HEMS configuration * Notifications ([work in progress](https://github.com/evcc-io/evcc/pull/25768)) We’ll be addressing these in the coming months. ### For Existing Users [Section titled “For Existing Users”](#for-existing-users) Already using evcc with an `evcc.yaml`? Then you don’t need to change anything. The `evcc.yaml` continues to be supported. If you want to switch to the web UI, you can use both configuration methods in parallel and migrate gradually. Devices from the `evcc.yaml` are visible in the UI but not editable. More details about the migration process can be found in the [FAQ](/en/faq#ui-migration). ## evcc Linux Images [Section titled “evcc Linux Images”](#evcc-linux-images) Along with the stable web UI, there’s another important new feature: Ready-to-use [Linux Images](https://github.com/evcc-io/images) for Raspberry Pi and other systems. Installation is now possible without much technical knowledge: 1. Download image 2. Flash to SD card 3. Insert into Raspberry Pi 4. Start setup directly in the browser **Completely without command line or YAML files.** Besides all Raspberry Pi versions, the NanoPi R3S is also supported. The images are based on [Armbian](https://www.armbian.com), making it easy to add new single board computer platforms. More details can be found in the [installation guide](/en/installation/linux-image) and in the [GitHub repository](https://github.com/evcc-io/images). ## More Highlights [Section titled “More Highlights”](#more-highlights) Besides the web UI, there have been many other new features in recent months: ### Tariffs: 15-Minute Price Forecasts [Section titled “Tariffs: 15-Minute Price Forecasts”](#tariffs-15-minute-price-forecasts) The EPEX exchange price for electricity has been provided in 15-minute intervals instead of hourly since October 2025. evcc now consistently uses quarter-hour slots internally. Planning algorithm and visualisation have been adapted. Many tariffs and solar forecasts have already been switched to the shorter interval. ### Planner: Continuous Charging [Section titled “Planner: Continuous Charging”](#planner-continuous-charging) The charging planner has received a new option. You can now choose between **continuous** and **cheapest**. Continuous planning selects the best contiguous charging window to avoid frequent interruptions.  ### Integration: Home Assistant [Section titled “Integration: Home Assistant”](#integration-home-assistant) We had [contact with the Home Assistant team](https://www.linkedin.com/posts/michael-geers_homeassistant-githubuniverse-opensource-activity-7391032971517992960-a9V8) and are working on better integration of both projects. First results are already visible. You can set up vehicles, chargers and metres based on Home Assistant sensors and switches. We use Home Assistant’s **autodiscovery** and **OAuth mechanism** for this. The matching **Home Assistant entities** are **suggested** to you in the edit screen.  ### Loadpoints: Sort & Hide [Section titled “Loadpoints: Sort & Hide”](#loadpoints-sort--hide) Loadpoints can now be sorted and hidden in the UI. Settings are saved per browser and enable individual views for different users.  []() ## Sponsoring: New Prices [Section titled “Sponsoring: New Prices”](#sponsoring-new-prices) We love open source and are convinced that the open knowledge accumulated in the project is a huge boost for the energy transition. Software development thrives through you - the community: wishes, ideas, testing and active code contributions drive the direction of the project. However, operation and focus require a lot of time. The project has grown so much that it’s long been more than a small side project for us. Therefore, financial support is important to continue developing and maintaining evcc sustainably in the long term. After almost 5 years, we’ve now decided to adjust sponsor prices for the first time. ### New Prices from 2026 [Section titled “New Prices from 2026”](#new-prices-from-2026) * **Monthly Sponsoring:** from $4 (previously $2) * **One-time Sponsoring:** from $150 (previously $100) ### Why This Adjustment? [Section titled “Why This Adjustment?”](#why-this-adjustment) A lot has changed in the last 5 years: **Dollar Exchange Rate and Inflation:** The dollar exchange rate (GitHub Sponsoring) has fallen and inflation has also increased our real costs. **Feature Scope:** evcc has evolved enormously. Features like the web UI, Linux images, smart charge planning, heat pump control, solar forecasts and many other functions have been added. What started in 2020 as a pure solar surplus tool is today a comprehensive energy management platform. **Sustainability:** We still have a lot planned (see 2026 outlook below). To continue developing evcc long-term and maintain quality, a solid financial foundation is needed. ### Already Sponsoring? [Section titled “Already Sponsoring?”](#already-sponsoring) Nothing changes for existing sponsors: * **One-time sponsorships** (made before 2026) naturally remain in place * **Monthly sponsorships** continue without price increase – you continue paying the previous price * Voluntary increases are of course welcome, but not required 🙌 Thanks to everyone who has supported evcc over the years – without you, the project wouldn’t be where it is today. More details can be found in the [sponsorship documentation](/en/sponsorship). ## New Device Support [Section titled “New Device Support”](#new-device-support) **44 new manufacturers** have been added since July 2025. The evcc device library now includes over **240 manufacturers** and **more than 620 products**. **Wallboxes:** Alpitronic, EV Expert, FoxESS, Neoom, Sigenergy, V2C, Veton **Heat Pumps & Heating Elements:** LG, NIBE **Metres:** Aandewiel, B+GE-TECH, Cozify HAN, DDM, EcoFlow, Home Assistant, Lovato, Senergy, Sermatec, Solakon, Strong Energy, Zendure, amsleser.no **Solar/Battery Systems:** ABB, B+GE-TECH, Bernecker Engineering, DDM, DZG, EcoFlow, Home Assistant, Lovato, ORNO, Saia-Burgess Controls (SBC), Schneider Electric, Sermatec, Solakon, Strong Energy, Wago, Weidmüller, amsleser.no, inepro **Vehicles:** Ford Connect, Home Assistant, Hyundai (US), Subaru Of course, many bugfixes and improvements have also been made to existing implementations. Details can be found in the [release notes](https://github.com/evcc-io/evcc/releases). ## 2026 Outlook [Section titled “2026 Outlook”](#2026-outlook) With the stable web UI, a major milestone has been reached. The work on it has taken a lot of time. We’re happy to now be able to focus more on new features again. The coming year will be exciting – here’s an outlook on the planned priorities: ### Optimisation Algorithm [Section titled “Optimisation Algorithm”](#optimisation-algorithm) Today, we often control individual components separately. The optimiser aims to optimise the entire system: parallel charging of multiple vehicles, home batteries and consumers – based on price signals, solar forecasts and household consumption predictions. Since mid-2025, a group of people has been working on an optimisation algorithm for evcc. It’s based on systems of equations and statistics. Product marketing would probably call it AI 😉. The optimiser can already be integrated in read-only mode today and its results can be displayed with special configuration. The next steps: * **Visualisation:** Display insights from the optimiser in the evcc interface where it makes sense * **Active Control:** Control planner, grid charging and other functions based on optimiser data More on this in the [GitHub issue](https://github.com/evcc-io/evcc/issues/23042). ### Better Display for Consumers and Heaters [Section titled “Better Display for Consumers and Heaters”](#better-display-for-consumers-and-heaters) The display and control of **regular consumers** (washing machine, dryer, …) and **heaters** should be improved. Today, these can already be added as “Heating” or “Additional Meters” and displayed in the energy flow diagram. A display as separate tiles is planned, as well as recording time-based data. The “mini loadpoints” concept has existed for some time – most of the building blocks are now in place. We’re working on this in the coming year and look forward to more clarity and specific functions for these devices. Details can be found in the [GitHub discussion](https://github.com/evcc-io/evcc/discussions/7235). ### Time-Based Statistics [Section titled “Time-Based Statistics”](#time-based-statistics) Currently, we only capture statistics based on charging sessions. Additionally, we plan to collect purely time-based data for consumption, generation, heat generation and other metrics. This long-requested feature enables overview statistics like those familiar from many manufacturer apps - but for all devices in your home. Questions like “How much solar power did the heat pump use?” or “How much energy did my solar systems produce today?” should be answerable with this. The display will complement the existing charging-optimised view. *** 💚 Big thank you to everyone who has brought the project this far – through collaboration, discussion, ideas, testing and especially financial support. We wish you a good start to 2026 and are happy that the days are getting longer again. **Best regards**\ The evcc Team\ Michael, Andi & Uli # evcc on the SmartHütte Podcast The [SmartHütte Podcast](https://podcast.smarthuette.de/) is a technical, nerdy podcast about smart home, self-hosting and other tech topics. Hosts [Andrej Friesen](https://techhub.social/@ajfriesen) and [Thomas Wiebe](https://mas.to/@behweh) regularly discuss their experiences with Home Assistant, Kubernetes, hosting and everything else that interests them. I was a guest on the latest episode and talked about the evcc project. ## What’s it about? [Section titled “What’s it about?”](#whats-it-about) In the over two-hour episode, we discuss the origins of evcc and solar surplus charging. We talk about wallboxes and how smart they really are – and what problems arise when manufacturers want to make them too smart. We talk about the challenges of vehicle integration, cloud dependencies and the EU Data Act. We discuss the sponsoring model, the journey from YAML configuration to graphical interface and how evcc and Home Assistant complement each other – from integration via MQTT to using Home Assistant entities as evcc devices and vice versa. Also: forecasts, optimizer, AI-generated pull requests and the question of when you should really control your coffee machine with solar surplus. ## Listen now [Section titled “Listen now”](#listen-now) [](https://podcast.smarthuette.de/episodes/sonne-im-tank-smartes-pv-uberschussladen-mit-michael-geers-vom-evcc-projekt) **[To the podcast episode →](https://podcast.smarthuette.de/episodes/sonne-im-tank-smartes-pv-uberschussladen-mit-michael-geers-vom-evcc-projekt)** *(in German)* Thanks to Andrej and Thomas for the invitation and the relaxed conversation! # Community: Driving Instructor Alex Alex is a driving instructor and has been using electric vehicles for driver training for years. With evcc, he controls two wallboxes for his private and company vehicles and is planning to integrate a Wolf heat pump for his 5-unit building. Photographer [Detlef](https://hee.se) paid him a visit. ## From i3 Car Sharing to IONIQ 5 [Section titled “From i3 Car Sharing to IONIQ 5”](#from-i3-car-sharing-to-ioniq-5) **Michael:** Hello Alex, great that you’re taking the time. You’re a driving instructor and use electric cars professionally. What was your first contact with electric mobility? **Alex:** Hi Michael, happy to. My first contact with e-mobility was in 2015 on short trips to Hamburg. There I got to know the BMW i3 through DriveNow car sharing. Technically exciting, distinctive with the carbon fibre body and very nippy in city traffic. That fascinated me. In mid-2021, the first own electric car came along, a VW ID.3 on lease. At that time, I also started using electric vehicles professionally for driver training - ID.3, ID.4, Hyundai Kona. For about two years now, my wife and I have been driving a Hyundai IONIQ 5. **Michael:** What was your motivation for switching? **Alex:** Several reasons. Environmental protection - fewer emissions, less noise. Then the savings potential: solar power from my own roof into the home battery and then into the car. And then the driving pleasure. The elastic acceleration and quiet driving are pleasant.  ## Electric Cars in Driving School [Section titled “Electric Cars in Driving School”](#electric-cars-in-driving-school) **Michael:** You’ve been a driving instructor in the Cologne/Bonn area for 17 years. What’s it like with e-mobility in your daily work? Has anything changed in recent years? **Alex:** Definitely. E-mobility hasn’t fully established itself in the driving school industry yet, but the advantages are increasingly being recognised. I estimate 15-20% of driving school cars are now electric - similar to private vehicles. There are also colleagues who are sceptical about the new mobility. Some are guided by the usual myths: raw material extraction, battery durability, charging times, range. But the scepticism amongst parents has noticeably decreased in recent years. **Michael:** How do the students react? **Alex:** Many parents now drive electric themselves and are open to the new type of training. The keyword is B197: 10 driving lessons of 45 minutes each for manual transmission competence, the rest of the training and the exam on automatic. The students like it because the exam is more relaxed. Typical sources of error are eliminated: no stalling, no mis-shifting, no rolling back when starting on hills. Word spreads among the students. Only very rarely are there parents who insist on pure manual transmission training.  ## Where’s the Dipstick? [Section titled “Where’s the Dipstick?”](#wheres-the-dipstick) **Michael:** Are there any funny stories from everyday driving school life with electric cars? **Alex:** (laughs) Oh yes. One student was a bit nervous during the exam and went searching for the dipstick in the engine compartment together with the examiner. You don’t forget something like that. **Michael:** What about range? Is it enough for a normal driving school day? **Alex:** Absolutely. We rely on the large battery variants with 64-77 kWh. Even in winter it works. When we switch to the manual vehicle in between for B197 training, I can recharge for 90 minutes at 11 kW in front of the driving school during that time. I’ve practically never had to use a DC charger. At home I have a separate wallbox for the company car. So I always start the day with a full battery.  ## From Tibber Smart Charging to evcc [Section titled “From Tibber Smart Charging to evcc”](#from-tibber-smart-charging-to-evcc) **Michael:** How did you come across evcc? **Alex:** I looked into HEMS systems in spring 2023. My initial goal was to combine the dynamic electricity tariff with time-optimised charging. Tibber laid the foundation for this with Smart Charging. After installing the solar system and battery storage, this control was no longer sufficient. The flexibility of evcc impressed me: messaging, tariff integration, diverse support for wallboxes and vehicles. I’m happy to support the continuous development. **Michael:** Which functions do you specifically use? **Alex:** I use automated charging plans for private and company vehicles to a specific charge level in the early morning. My goal is for the system to be operational without major external intervention. You naturally like to tinker with the final fine-tuning, but in everyday life it should just work.  ## Two Systems, Two Raspberry Pis [Section titled “Two Systems, Two Raspberry Pis”](#two-systems-two-raspberry-pis) **Michael:** Let’s talk about your technical setup. You have a somewhat unusual configuration. **Alex:** True, I actually run two separate evcc instances. The first system is for my flat. I have a 14.85 kWp solar system on the north side of the roof, combined with a 12.8 kWh BYD storage unit. Two Easee wallboxes are connected - one private, one for the company car. The dynamic electricity tariff runs via Tibber. The system runs on a Raspberry Pi 4 with Home Assistant and the evcc add-on.   | Component | Details | | ------------------------------ | ------------------------------------------- | | **Solar System** | 14.85 kWp (north orientation) | | **Inverter** | SMA Sunny Tripower SE STP10.0-3SE-40 | | **Storage** | BYD HVS 12.8 kWh LFP | | **Wallboxes** | Easee Home (11 kW), Easee ChargeUp (11 kW) | | **Vehicles** | Hyundai IONIQ 5 | | **Dynamic Electricity Tariff** | Tibber | | **Control** | Raspberry Pi 4, Home Assistant, evcc add-on |  **Michael:** And the second system? **Alex:** The second system is for the entire 5-unit building. There I have a 10 kWp solar system on the south side of the roof and a Wolf CHA 20/24 monoblock air/water heat pump with SG-Ready interface. The electricity tariff runs via Tado/Awattar. It runs on a Raspberry Pi 5, also with Home Assistant and evcc add-on. The heat pump isn’t fully integrated into evcc yet, that’s my next project.  | Component | Details | | ------------------------------ | ------------------------------------------- | | **Solar System** | 10 kWp (south orientation) | | **Inverter** | SMA Sunny Tripower STP 10000TL-20 | | **Heat Pump** | Wolf CHA 20/24 monoblock, SG-Ready | | **Dynamic Electricity Tariff** | Tado/Awattar | | **Control** | Raspberry Pi 5, Home Assistant, evcc add-on | ## Planner and Battery Boost [Section titled “Planner and Battery Boost”](#planner-and-battery-boost) **Michael:** What are your favourite features in evcc? **Alex:** Clearly the planner for specific weekdays. I can set different charging times for each vehicle. It runs completely automatically. And then the battery boost. When the home battery is full and I shoot the solar power from the home battery directly into the car during the day, preferably in summer, during a break - that’s brilliant.  **Michael:** What would you like from evcc? **Alex:** My wish list is getting smaller with the continuous development. Native integration of my heat pump would be nice. Two Wolf systems are supported, but not the CHA yet. The community on GitHub always provides good support with problems that arise. The integration of household appliances like Miele\@home or BSH Home Connect would also be a logical development, even if it’s only about a few kWh here. However, I also agree with the view not to lose focus too much and to concentrate on the core features. **Michael:** Thanks for the good suggestions. And thank you very much for giving us insights into your driving school everyday life and your evcc setup. It shows nicely how diverse e-mobility and evcc can be used! **Alex:** Happy to! And we’ll see each other in April at the [Community Meetup](/en/blog/2025/12/16/community-treffen-2026) in Osnabrück. *** **What does your evcc setup look like?** If you’re interested in sharing your experiences, your journey and your technology in the form of a community portrait, feel free to sign up [here in the form](https://airtable.com/appDI3xIiev1DOpMY/shrW1zGH26KElfZOK). We’re particularly looking for portraits of extraordinary installations or users outside Germany. # Strengthening Security with the GitHub Secure Open Source Fund Late summer last year, GitHub approached us about participating in the [Secure Open Source Fund](https://github.com/open-source/github-secure-open-source-fund). We applied, were selected by the committee, and joined 98 maintainers from 67 open source projects for an intensive security program. ## The Programme [Section titled “The Programme”](#the-programme) The in-depth phase ran across September 2025: roughly 20 sessions, all synchronous over Zoom, with evening time slots that were quite comfortable for European participants, though attendees joined from all time zones. The sessions were led by experts from the [GitHub Security Lab](https://securitylab.github.com/) and covered a wide range of topics. We had concrete tasks to complete between sessions. Homework, but the effective kind. The real value, though, was hearing these topics explained by people who deal with them daily and discussing them with the group. ## Security Is a Workout, Not a Checkbox [Section titled “Security Is a Workout, Not a Checkbox”](#security-is-a-workout-not-a-checkbox) One concept that stuck with me was *Improving Our Security Posture*. Security isn’t a checkbox you tick once. It’s more like fitness. There’s no finish line. You build habits, you keep training, you slowly get stronger. The program gave us a structured training plan. The topics ranged widely. We worked on licence clarity and compatibility, adding licence checks for our Go and NPM dependencies and publishing SBOMs. We wrote a [SECURITY.md](https://github.com/evcc-io/.github/blob/main/SECURITY.md) and an incident response plan. We learned about the CVE process. Not something I’ve had to deal with so far, but good to be prepared. We covered threat modelling, secure-by-design principles, and UX considerations for building secure software. On the tooling side, there were sessions on static analysis with CodeQL and fuzzing. GitHub Actions security was one I didn’t expect to be such a deep topic. There are many subtle ways workflows can be exploited, and we ended up doing a lot of hardening on our own actions with tools like [actions-permissions](https://github.com/GitHubSecurityLab/actions-permissions). One session that surprised me was about AI security. GitHub introduced us to the [Secure Code Game](https://github.com/skills/secure-code-game), a hands-on challenge where you find vulnerabilities in a codebase. The early levels cover classic OWASP problems like SQL injection and XSS. Familiar territory. But the latest season is about tricking software with built-in LLM functionality into doing things it shouldn’t. It was eye-opening to see that this is the new frontier people are actively training for. ## Different Projects, Different Perspectives [Section titled “Different Projects, Different Perspectives”](#different-projects-different-perspectives) What made the program special was the mix of projects in the room. There were applications like evcc, [Thunderbird for Android](https://github.com/thunderbird/thunderbird-android), [Mattermost](https://github.com/mattermost/mattermost), and [Mastodon](https://github.com/mastodon/mastodon). Libraries like [GoReleaser](https://github.com/goreleaser/goreleaser) (which we use for our releases), [Mermaid](https://github.com/mermaid-js/mermaid) (which we use in our docs), and [Node.js](https://github.com/nodejs/node). And fundamental tools like [curl](https://github.com/curl/curl) and [ImageMagick](https://github.com/ImageMagick/ImageMagick). Security means something quite different depending on what you build. An application that runs in people’s homes faces different threats than a library embedded in thousands of projects. Hearing how curl thinks about security compared to how Mastodon does was genuinely valuable. Beyond the content, the network you build with other maintainers is something that lasts. ## GitHub Universe [Section titled “GitHub Universe”](#github-universe) In October 2025, I was invited to the GitHub Universe conference in San Francisco ([read more](https://www.linkedin.com/posts/michael-geers_homeassistant-githubuniverse-opensource-activity-7391032971517992960-a9V8)). I was part of a panel about the Secure Open Source Fund at Community Day. It was great to connect with other maintainers in person after weeks of Zoom sessions. Together with [Gregg Cochran](https://www.linkedin.com/in/greggcochran/) (GitHub), [Christian Grobmeier](https://www.linkedin.com/in/grobmeier/) (Log4j), [Camila Maia](https://www.linkedin.com/in/cmaiacd/) (ScanAPI), and [Carlos Alexandro Becker](https://www.linkedin.com/in/caarlos0/) (GoReleaser) I recorded a podcast episode on open source security. You can [watch it on YouTube](https://www.youtube.com/watch?v=XmCSHr12CO0) or [listen to the audio](https://the-github-podcast.simplecast.com/episodes/live-from-github-universe-inside-the-github-secure-open-source-fund-EV0GufSU).  ## Get Involved [Section titled “Get Involved”](#get-involved) **If you maintain an open source project:** consider applying for the program. The overview you get across security topics is broad, and the network of maintainers you build is just as valuable. **If your company relies on open source** (and it almost certainly does): consider sponsoring your critical dependencies directly. Or support the [Secure Open Source Fund](https://github.com/open-source/github-secure-open-source-fund) to help the broader ecosystem. More secure open source means more secure software for everyone. # evcc-Crowdscience: Real Charging Data for Research The Solar Storage Systems research group at [HTW Berlin](https://solar.htw-berlin.de/evcc-crowdscience/) has launched [evcc-Crowdscience](https://evcc-crowdscience.de) — a platform where evcc users can anonymously share their charging data for research purposes. ## Why Real Charging Data? [Section titled “Why Real Charging Data?”](#why-real-charging-data) Real-world EV charging profiles are important for research and the energy sector. Existing models often rely on assumptions. But actual charging patterns from households with solar systems and wallboxes can differ significantly from those assumptions. evcc-Crowdscience aims to close exactly this gap. ## How Does It Work? [Section titled “How Does It Work?”](#how-does-it-work) Data is transmitted via MQTT. You generate a token on [evcc-crowdscience.de](https://evcc-crowdscience.de) and enter it in your evcc settings. From then on, your charging data is automatically and anonymously sent to the researchers. This works even if you’re already using MQTT for other integrations. No personally identifiable data is collected. If you want to stop participating, just remove the token. You can find all setup details on the [project page](https://evcc-crowdscience.de). ## What Is Being Researched? [Section titled “What Is Being Researched?”](#what-is-being-researched) Based on the collected data, the HTW Berlin team investigates: * When and how long vehicles are charged * How charging power varies in everyday use * How effective solar surplus charging is in practice * How charging behaviour differs between households The data set and results will be published as open data later on, making them available to everyone.  *Photo: HTW Berlin/Alexander Rentsch* ## Contribute Your Data [Section titled “Contribute Your Data”](#contribute-your-data) We think this project is exciting and worth supporting. The more households participate, the more meaningful the results. **[Sign up at evcc-crowdscience.de →](https://evcc-crowdscience.de)** You can find more background information on the [HTW Berlin project page](https://solar.htw-berlin.de/evcc-crowdscience/). # Community Meetup: Recap On April 18, 2026, we met for the first evcc community meetup at the [Osnabrücker Ruderverein](https://www.orv.de) rowing club. Around 40 participants joined us, coming from Germany, Belgium, and the Netherlands. Some traveled all the way from Bavaria and Baden-Württemberg. ## A barcamp-style afternoon [Section titled “A barcamp-style afternoon”](#a-barcamp-style-afternoon) The afternoon ran in barcamp style: participants bring the topics, and the rest takes shape on the spot. Three larger sessions emerged: * **Bidirectional charging**: Jan Luca and Marcel shared how CUBOS is rolling out bidirectional charging in a corporate context. * **Advanced optimization**: the interplay with [EOS](https://github.com/Akkudoktor-EOS/EOS) (a project by [Akkudoktor](https://akkudoktor.net)), [OpenEMS](https://openems.io), [Victron ESS](https://www.victronenergy.com/live/ess:start), [Home Assistant](https://www.home-assistant.io), the [evcc Optimizer](/en/features/optimizer) currently in development, and direct marketing of power. * **Load management, §14a, §9, and EEBus**: current German regulation and how evcc can implement these requirements in practice. Alongside those, many smaller rounds formed: AI use in the evcc codebase, wallbox recommendations, next steps in the UI (think “mini loadpoints”), and plenty more.  ## Professional evcc hardware [Section titled “Professional evcc hardware”](#professional-evcc-hardware) Dominik presented his [eHive](https://www.ehiv3.de) system, a DIN rail hardware specifically optimized for use with evcc. To wrap up the session, a device was raffled off among the participants: whoever guessed the weight of the hardware most accurately got to take it home.  ## Tours through the club’s energy setup [Section titled “Tours through the club’s energy setup”](#tours-through-the-clubs-energy-setup) Markus and Michael from the Osnabrücker Ruderverein gave several tours through the club’s energy tech and the boathouses. More on the club’s setup in the [community portrait](/en/blog/2025/11/29/osnabruecker-ruderverein). ## Wrap-up [Section titled “Wrap-up”](#wrap-up) We wrapped up the day with a barbecue and drinks. Good conversations and new connections within the community.  And there was even an evcc cake:  ## Photo gallery [Section titled “Photo gallery”](#photo-gallery) [Detlef](https://hee.se) documented the meetup. You can find all photos in his [photo gallery](https://hee.se/portfolio/evcc/). ## Thanks [Section titled “Thanks”](#thanks) A big thank you to the [Osnabrücker Ruderverein](https://www.orv.de) for hosting us, to Markus and Michael for the tours, and to [Detlef](https://hee.se) for the photos. And to everyone who brought topics, ideas, and energy to make this meetup happen. See you next time! # Highlights: Remote Access, iOS Widgets, Optimizer and more Half a year has passed since the [last highlights post](/en/blog/2026/01/01/highlights-browser-config-ready). A lot has happened since then with releases [0.301 to 0.311](https://github.com/evcc-io/evcc/releases): a new navigation, widgets in the iOS app, remote access, time-based statistics and much more. In this blog post, we pick out a few of our highlights and give a brief outlook on our further plans. ## Interface Overhaul [Section titled “Interface Overhaul”](#interface-overhaul) The interface has received a new navigation at the bottom of the screen. The sections **Charge**, **Home Battery**, **Forecast**, **Sessions** and **More** now get you to all functions faster. Battery and forecast have received their own pages instead of hiding in modals in the hamburger menu as before. The battery page shows the current values along with the forecasted state of charge development (experimental, more on the optimiser later). The navigation also gives you a subtle hint when a new evcc version is available. The frequently requested update button right next to the changelog is not there yet. But it’s on our list.  Along the way, more gaps in browser-based configuration have been closed: [tariffs](/en/tariffs), [notifications](/en/notifications), EEBus and [external limits](/en/external-limit) can now be set up via forms instead of YAML editing. Only load management currently still needs to be configured via a large YAML block. ## App: Widgets & Multiple Servers [Section titled “App: Widgets & Multiple Servers”](#app-widgets--multiple-servers) The [evcc app](/en/features/app) has received some new features in recent months. **iOS Widgets:** Loadpoint status, solar forecast, grid import price, grid export price and CO₂ forecast are now available as widgets right on your home screen. One tap deep links you to the matching place in the app. [](/_astro/widgets.BXJVvxJg.mp4) **Multiple Servers:** You can now manage multiple evcc instances in the app, e.g. for your home, your parents or your holiday house. Switching works via **More → Change Server**. [](/_astro/change-server.CmjWRu81.mp4) **QR Code Setup:** Setting up a new instance works by scanning a QR code straight from the web interface. You no longer have to enter the server address and credentials by hand. This is especially helpful when you prepare an installation for someone else. More about the options can be found in the [app reference](/en/reference/app). Special thanks to [Maschga](https://github.com/Maschga) for continuously improving the app. ## Remote Access [Section titled “Remote Access”](#remote-access) Many of you want to keep an eye on your system while away from home. Our recommendation so far has been to set up a VPN for this. Along the way, we have often heard the wish for a simpler solution. This topic has been on our minds for a long time. Over the past years, we have built many prototypes and discarded them again. Our requirements: high security, no data storage on our servers, transparency, ease of use and a high degree of local control. With the new, experimental [Remote Access](/en/features/remote-access), we now have a solution that fits. Your instance gets its own domain on `evcc.cloud`. The connection runs through a tunnel that your instance opens outbound itself. No port forwarding in your router is required. The nice thing about this solution is that it is technically very simple. At its core is the [hashicorp/yamux](https://github.com/hashicorp/yamux) library, which lets us route incoming internet traffic securely to the right local evcc instance, transport-encrypted via TLS. The actual authentication happens on your local instance: credentials are stored and verified exclusively there, and there are no user accounts in the cloud. The service is available to sponsors and can be enabled with two clicks under **Configuration → Remote Access**. [](/_astro/remote-access.DLnMeyIP.mp4) ## Dimming and Curtailment [Section titled “Dimming and Curtailment”](#dimming-and-curtailment) We have fundamentally reworked [external control](/en/external-limit) by the grid operator, a topic mostly relevant for Germany. The signals of an FNN control box can be read via EEBus or via switch contacts. **Dimming:** Limiting controllable consumers according to § 14a EnWG has been supported for a while. It has now become better: active limits are distributed proportionally across all controllable devices and shown in the UI. **Curtailment:** New is the reduction of production power according to § 9 EEG. Inverters from Huawei, Enphase, Sungrow and generic SunSpec devices can already be curtailed. You can find an overview of the curtailable devices in the [device list](/en/meters?f=curtail). Here we are working on broader device support. If you know another device well, we would be happy about your contribution. []() ## Heat Pumps & Heating [Section titled “Heat Pumps & Heating”](#heat-pumps--heating) More and more of you use your solar surplus not only for the car but also for a heat pump or electric heater. A lot has happened here as well. Temperatures are now displayed as a range with their own blue-to-red colour gradient, making them clearly distinguishable from loadpoints. You can configure the temperature range yourself.  With **continuous**, there is a new conceptual mode for heat pumps: instead of hard on/off switching, the device keeps running on its own, which better reflects the nature of this device category. Via EEBus, we support compressor flexibility (OHPCF), which allows heat pumps to run on surplus in a targeted way. On top of that come many [new devices](/en/heating#supported), from the Vaillant brand family to Glen Dimplex and Xtherma. We still have some open items like better mode naming, an adapted plan mode and time-based data recording (see below), plus further ideas like heat demand forecasts in the optimiser. **Sponsorship required:** When we introduced the heating category, we announced that these devices, similar to many wallboxes, will require a sponsorship. The note has been at the top of the [device list](/en/heating) since then. With one of the upcoming releases, we will enforce this in the software.  ## Battery Boost [Section titled “Battery Boost”](#battery-boost) Sometimes the car needs to be full quickly, even when the sun is not delivering. With **Battery Boost**, you can discharge the home battery into the vehicle on demand. One click on the loadpoint is enough, charging continues until an adjustable battery limit is reached. Boost works in **Solar** mode. [](/_astro/battery-boost.CqH5bKCT.mp4) By the way, Battery Boost is the first feature that made it onto its own sticker. At the [community meetup](/en/blog/2026/04/20/community-treffen-rueckblick) in April, we handed out a few sticker drafts and collected ideas. The sticker, with pixydust-green sparkle print, is now part of the default set in the letters to new sponsors.  ## OCPP Forwarding [Section titled “OCPP Forwarding”](#ocpp-forwarding) A typical case: you drive a company car and your employer reimburses the charging costs via a billing platform. Your wallbox speaks OCPP for this, but can only connect to one system. Until now, you had to choose: solar optimisation with evcc or billing via the platform. The new [OCPP forwarding](/en/integrations/ocpp-forwarding) solves this. Your evcc instance controls the wallbox and forwards the OCPP messages to the external backend at the same time. If desired, it blocks commands from outside and retains sole control over charging. Thanks to [webalexeu](https://github.com/webalexeu) for pushing this topic and building the implementation. ## New Device Support [Section titled “New Device Support”](#new-device-support) **Over 50 new manufacturers** have been added since the beginning of the year. The device library now includes more than **320 manufacturers** and over **800 products**. **Wallboxes:** ChargeLine, ChargeX, Enovates, ETEK, EVSE Master (Besen, Telestar, Morec), Hager, Lektrico, Nexblue, RAEDIAN, Shell Recharge, Stegen, Voltie **Heat Pumps & Heating Elements:** Askoma, E.G.O., Glen Dimplex, M-Tec, OVUM, Xtherma, plus the Vaillant brand family (Saunier Duval, Bulex, Glow-worm, DemirDöküm) **Metres, Solar & Battery Systems:** ADA, Afore, Atmoce, Azimut Energy, Danfoss, Eltako, Everhome, Finder, Homey, IBC Solar, IndeVolt, INTILION, IoTaWatt, Sessy, Smartstuff, Solinteg, stromleser.one, Tepto **Tariffs:** BKW, CKW, Energy-Charts, EPEX Predictor, EWS Schönau, Fingrid, OMIE, Pstryk, pvnode **Vehicles:** Alpine, Genesis, Lexus Of course, there have also been many bugfixes and improvements to existing implementations. Details can be found in the [release notes](https://github.com/evcc-io/evcc/releases). ## VW Group: Gone and Partially Back [Section titled “VW Group: Gone and Partially Back”](#vw-group-gone-and-partially-back) Every now and then, integrations also disappear again. The situation with the VW group is a bit of a rollercoaster ride. Several group brands dropped out because the group [locked out](https://www.heise.de/news/Frust-bei-E-Auto-Fahrern-Schnittstelle-fuer-Drittanbieter-weg-VW-arbeitet-dran-11320034.html) third parties like evcc, Home Assistant and others from the unofficially used API of its app. Via the detour of the new EU Data Act interface, we have made them available again, partially and with limitations. Instead of a live API, the transparency portal provides a ZIP archive with the vehicle data every 15 minutes, which your instance downloads and decodes. The group has announced a sustainable solution for smart home projects and open source. We are in contact, but have now been waiting for the manufacturer’s next step for several weeks. []() ## History: Time-Based Statistics [Section titled “History: Time-Based Statistics”](#history-time-based-statistics) We have started on a long-requested feature: energy data is now recorded in a structured way in 15-minute resolution, independent of charging sessions. The new, experimental **History** page shows grid, production, battery, charging & heating, household consumption and additional metres over time. In addition to the visual display, the data can be exported as CSV or XLSX. Also new is the concept of *consumers*: it lets you break down the recorded household consumption further, e.g. by washing machine, dishwasher or toaster. Unlike loadpoints and heating devices, consumers are only recorded and not controlled. To improve data quality, we have added support for energy metering with bidirectional metres. This records both directions: imported and exported for the grid, charged and discharged for the battery. The topic is not finished yet. Our current focus is ensuring the correctness of the data for all supported device classes. The visualisations are therefore still deliberately simple time series. But there are already lots of ideas: in this [ideas thread](https://github.com/evcc-io/evcc/discussions/31060), you can post screenshots of statistics and visualisations that you find well done and helpful and would like to see in evcc in the future. With this, we lay the foundation for statistics beyond EV charging. Questions like “How much solar power did the heat pump use last year?” are what we want to answer directly in the future.  []() ## Optimiser [Section titled “Optimiser”](#optimiser) So far, evcc controls based on the current energy situation in your home. Charging plans do look ahead at prices and forecasts, but always focused on a single loadpoint. The [optimiser](/en/features/optimizer) takes the big picture into view: it calculates the optimal behaviour of the entire system for the next two days, based on consumption and production forecasts as well as the electricity price curve. Freshly merged are weather forecasts, which will allow estimating and including the heat demand in the future. They were contributed by [daniel309](https://github.com/daniel309), thanks a lot! Also new is a selectable strategy: you decide what the plan should optimise for besides cost efficiency, e.g. filling the battery first or reducing grid peaks. The optimiser’s recommendations are displayed where they matter: on the loadpoint and on the battery page, including the forecasted state-of-charge curve. The optimiser does not control any devices yet. The next step is turning the calculated plans into actions: concretely controlling the battery and loadpoint behaviour.  ## Sponsoring via Creem [Section titled “Sponsoring via Creem”](#sponsoring-via-creem) Sponsoring is now possible without a GitHub account. At [sponsor.evcc.io](https://sponsor.evcc.io), you can complete your sponsorship directly, processed via the payment provider [Creem](https://www.creem.io), a young European company from Estonia. You can currently pay with Apple Pay, Google Pay and credit card, with more payment methods planned. Also new are [token bundles with volume discounts](https://sponsor.evcc.io/business) for electricians and installers who use evcc in their customer projects. You can find all details in the [sponsorship documentation](/en/sponsorship). ## New Documentation [Section titled “New Documentation”](#new-documentation) [docs.evcc.io](https://docs.evcc.io) has been rebuilt as well. We migrated from Docusaurus to [Astro Starlight](https://starlight.astro.build). The new foundation is more lightweight, more modern and offers more freedom for extensions. Pages load faster and work without client-side JavaScript. Search now runs locally in your browser instead of via the external service Algolia. English is the new default language. Every device has its own directly linkable detail page with a parameter table, generated from the templates and with a toggle between release and nightly state. The edit function takes you straight to the source template. The REST API reference is built from the OpenAPI specification, and there is an [llms.txt](https://docs.evcc.io/llms.txt) for LLMs. ## Agentic Development [Section titled “Agentic Development”](#agentic-development) Agentic development tools have become significantly better in recent months and have changed how we work in the project, not without friction, but mostly positive. On GitHub, an agent pre-sorts new issues, pull requests receive an automatic first review, and maintainers can trigger analyses, fixes and test builds via comment. As a trial, we also let AI answer issues substantively: understanding the problem, searching for solutions and, in suitable cases, even proposing a pull request directly. The result: better issues, better pull requests and a big boost for contributions. We have documented guidelines for AI-generated contributions in the [CONTRIBUTING.md](https://github.com/evcc-io/evcc/blob/master/CONTRIBUTING.md). One thing is clear, though: focus and quality remain our top priority. Generating new features has become easy. Good communication in issues and discussions is all the more important. Understanding use cases and the concrete needs behind them remains essential, even though the shortcut of the “quickly generated extra setting” is often very tempting. ## Outlook [Section titled “Outlook”](#outlook) What are we working on next? Some plans were already touched on above: further [improvements for heat pumps](#heating), more [statistics](#history) based on the new data recording and the [optimiser](#optimizer) on its way from recommendation to active control. Two larger topics come on top. **Mini loadpoints:** Regular consumers and heating devices are set to get their own cards with matching functions. With the time-based data and the reworked device management, the prerequisites are now in place. Details in the [GitHub discussion](https://github.com/evcc-io/evcc/discussions/7235). **Bidirectional charging:** First vehicles and wallboxes capable of feeding back are present in the community (including the core team). We are working on making them usable in evcc. We are currently in discussions with manufacturers about implementation details in the standard, certificates and other technical challenges. If you have a compatible wallbox and vehicle combination at home (or work at a manufacturer), feel free to get in touch: via [GitHub issue](https://github.com/evcc-io/evcc/issues), on [Slack](https://evcc.io/slack) or at . *** 💚 We named a few contributors above, and they stand in for many more. Big thank you to everyone who moves the project forward: through code, ideas, testing, discussions and financial support, without which the project would not be possible in this form. We wish you a sunny summer with lots of full batteries. **Best regards**\ The evcc Team\ Michael, Andi & Uli # Frequently Asked Questions ## Configuration [Section titled “Configuration”](#configuration) ### Should I configure evcc via the web interface or with the configuration file? [Section titled “Should I configure evcc via the web interface or with the configuration file?”](#should-i-configure-evcc-via-the-web-interface-or-with-the-configuration-file) We recommend using the **web interface**. After installing evcc, open it in your browser and configure your devices directly there. Settings are automatically saved in the database. The **configuration file** (`evcc.yaml`) is the traditional method and remains supported. **Important**: Some newer features are only available through the web interface. Both methods can also be used in parallel. More information can be found under [Configuration](/en/installation/configuration). []() ### I have an evcc.yaml configuration. How do I migrate to the web interface? [Section titled “I have an evcc.yaml configuration. How do I migrate to the web interface?”](#i-have-an-evccyaml-configuration-how-do-i-migrate-to-the-web-interface) You can use both configuration methods in parallel and migrate step by step. **Procedure:** 1. Configure a new device directly via the web interface under **Configuration**. 2. Remove the corresponding entry from your `evcc.yaml`. 3. Repeat this for all devices until your `evcc.yaml` is empty. **Device merging:** Charging points, grid meters, solar systems, batteries, vehicles and other meters are merged from both sources. On the configuration page, devices from `evcc.yaml` are visible but not editable. You can use devices from both `evcc.yaml` and the UI simultaneously. **UI configuration takes precedence:** For other settings (MQTT, notifications, InfluxDB, tariffs, …), values from the web interface take precedence over values from `evcc.yaml`. We recommend using only one source to avoid confusion. **Note:** In some places (HEMS, sponsor token), UI configuration is locked if already configured via `evcc.yaml`. Delete the entry from `evcc.yaml` to enable UI editing. **Conclusion:** A complete migration is not mandatory. You can continue using `evcc.yaml` for certain configurations and add new features via the web interface. There is no automatic migration. The previously available `evcc migrate` command was removed due to high complexity. Please migrate manually. ### Can I use evcc without a grid meter? [Section titled “Can I use evcc without a grid meter?”](#can-i-use-evcc-without-a-grid-meter) The grid meter is the core of evcc and should be included if possible. However, it is also possible to operate solar-guided charging exclusively on the basis of PV power. But please note that you won’t be able to charge using solar excess energy only, as the calculations required for this are only possible when grid power is known. When configured like this, evcc will charge the vehicle using the current power coming from solar generation. A typical, medium-sized house’s consumption can be specified to attempt to leave some energy for your house - you can do us this using the [`residualPower`](/en/reference/configuration/site#residualpower) config flag. **Example**: ```yaml site: residualPower: 250 # 250W house consumption ``` ### I don’t have solar panels, can I still use evcc effectively? [Section titled “I don’t have solar panels, can I still use evcc effectively?”](#i-dont-have-solar-panels-can-i-still-use-evcc-effectively) Possibly! evcc has plenty of uses beyond pure solar diversion. **Please note that all of these use cases require a Grid connection meter.** Here’s some ideas: * Automatically charge a vehicle depending on the current price of energy using a variable rate electricity tariff (such as Octopus Energy, Nachtstrom, Tibber, Awatter, etc.) - see [Dynamic Tariffs](/en/features/dynamic-prices) * Remotely start / stop your charger - especially useful on those chargers that don’t have any other remote control interface * Limit charging your vehicle to a certain state of charge - but please note that having your vehicle configured is essential. ### Can I try out evcc without all the components (PV system, charger, …)? [Section titled “Can I try out evcc without all the components (PV system, charger, …)?”](#can-i-try-out-evcc-without-all-the-components-pv-system-charger-) Sure! We have a selection of “demo” components that can help fill in gaps. [Meter](https://docs.evcc.io/en/docs/meters#demo-meter) [Charger](https://docs.evcc.io/en/docs/chargers#demo-charger) ### Can I use evcc without integrating the PV inverter? [Section titled “Can I use evcc without integrating the PV inverter?”](#can-i-use-evcc-without-integrating-the-pv-inverter) Yes! If there’s a grid meter and a controllable charger, then you can use all of evcc’s essential functionality - including solar excess charging. Please note that you will be lacking a few visualizations and statistics, including the calculation of solar charging percentage. Do consider that if you install a retrofitted meter of some kind (such as a Shelly EM) onto your inverter’s output cable, you’ll get all of the same functionality that you would if you could talk directly to the inverter. ### Can I use multiple chargers? [Section titled “Can I use multiple chargers?”](#can-i-use-multiple-chargers) Yes! Multiple chargers can be added and controlled by evcc at the same time. However, Load Management across multiple chargers is not supported right now. This is currently in development for a later release. ### My charger doesn’t support phase switching. Can I still charge single-phase? [Section titled “My charger doesn’t support phase switching. Can I still charge single-phase?”](#my-charger-doesnt-support-phase-switching-can-i-still-charge-single-phase) With small PV systems and/or during the winter, it makes sense to use a single phase to make use of any surplus power as efficiently as possible without incurring network losses. In the case of three-phase chargers that don’t support automatic mode switching, you can disconnect phases 2 & 3 on the incoming supply to your charge point using some kind of contactor (e.g Hager HAB304). If full performance is needed, simply switch these phases back on again. Danger This manual switching should only be done when the vehicle is **NOT** connected to the charger. You can also just use a single-phase charging cable in the winter. Remember to set the charger setting in the evcc UI to single-phase mode. This ways evcc knows when there’s enough surpuls to charge the vehicle. ## Debugging [Section titled “Debugging”](#debugging) ### Something’s not working. What now? [Section titled “Something’s not working. What now?”](#somethings-not-working-what-now) First check the [Community Forum](https://github.com/evcc-io/evcc/discussions) to see if your problem has already been discussed. Developers and users are standing by to help solve common issues. The easiest way to get help is using the **Report a problem** function in the evcc web interface. Click on the menu (top right) and select **Need Help?** → **Report a problem**. This shows details about your configuration, database, logs and application state. From there you can directly create a [GitHub Discussions](https://github.com/evcc-io/evcc/discussions) post or a [GitHub Issue](https://github.com/evcc-io/evcc/issues). When creating your own post, please provide detailed information: * Description of the problem with reproducible steps. * Which devices (vehicles, meters, chargers) are in use. A good problem description leads to faster and better help. ### Finding syntax errors in evcc.yaml [Section titled “Finding syntax errors in evcc.yaml”](#finding-syntax-errors-in-evccyaml) Yaml is very sensitive to syntax - and errors don’t always catch the eye straight away. Linters such as [onlineyamltools.com](https://onlineyamltools.com/validate-yaml) can be super useful, and are worth checking to find simple mistakes. ### How do I create a log file for error analysis? [Section titled “How do I create a log file for error analysis?”](#how-do-i-create-a-log-file-for-error-analysis) The easiest way is to view and download the **log in the WebUI**. Click on “Logs” in the web menu (top right). There you can also filter by different levels and areas. The log includes the last 10k lines. **Advanced log options:** If evcc is running as a Linux system service, you can access logs using the following commands: * Follow the log in real time * `sudo journalctl -fau evcc` * Show the log since the last start of the evcc service (exit with Ctrl+C) * `sudo journalctl -u evcc -q` * Save the above log to a file in the home directory * `sudo journalctl -u evcc -q > ~/evcc.log` * You can also define a Start (`-S`) and End (`-U`) timestamp: * `sudo journalctl -u evcc -S "2023-03-21 07:00:00" -U "2023-03-21 08:00:00" -q > ~/evcc.log` More useful commands here: [wiki.archlinux.org/title/Systemd/Journal](https://wiki.archlinux.org/title/Systemd/Journal#Filtering_output) If you’re using Docker, you can use `docker logs`. See the [Docker documentation](https://docs.docker.com/config/containers/logging/) for more details. ### More thoughts on device detection [Section titled “More thoughts on device detection”](#more-thoughts-on-device-detection) `evcc detect` is a special command that attempts to find compatible hardware on your network. In particular, it can sometimes help find “new” Sunspec-compatible modbus devices - however, it is more of a developer / support tool for diagnostic purposes, and can’t provide detailed results. ## Common Errors [Section titled “Common Errors”](#common-errors) ### Error: Charger out of sync: expected disabled, got enabled Charger logic error: disabled but charging [Section titled “Error: Charger out of sync: expected disabled, got enabledCharger logic error: disabled but charging”](#error-charger-out-of-sync-expected-disabled-got-enabledcharger-logic-error-disabled-but-charging) evcc expects chargers to have switched to their new state before the next check cycle (after the configured `interval`). Some devices can sometimes react a little slowly to commands - if this happens, that desynchronisation of state is flagged with these error messages. If you’re not experiencing any other issues, these can safely be ignored, or you can try increasing the [`interval`](/en/reference/configuration/interval). ### connection refused [Section titled “connection refused”](#connection-refused) This means that the device could be contacted at its given IP address or hostname, but that the device refused to talk to us. There’s a number of possible reasons for this. These ones regularly come up: * Make sure the target port is set properly in your `evcc.yaml`. * Does the target device have external access enabled? (For example, Solaredge inverters come with modbus disabled from factory) * The device may have reached the maximum number of simultaneous connections. Other connections (for example, from other home automation systems, or from other instances of evcc) might need to be stopped in order to get evcc connected. We are aware of some devices that only accept a single connection at a time. * Make sure there’s no firewall between you and the target device, and if there is, that it is configured appropriately to allow traffic ### i/o timeout [Section titled “i/o timeout”](#io-timeout) This means the target system didn’t respond quickly enough to our request. Typically this is due to: * A slow or poor quality network connection (especially when using wireless or Homeplug-style networks) * Incorrect or poor quality cabling or termination (especially with RS485) * The target device may be overloaded * Certain functions requested by evcc from the device may be unavailable (sometimes this is due to outdated firmware or improperly set configuration on the target) * evcc’s timeout or query `interval` is set too short ### /tmp/evcc: operation not permitted bind: address already in use [Section titled “/tmp/evcc: operation not permittedbind: address already in use”](#tmpevcc-operation-not-permittedbind-address-already-in-use) This error happens if evcc is already running (for example, as a service) and you attempt to launch it again. **Only one instance of evcc should be running at a time.** You can use a program such as `htop` to help you diagnose whether another instance of evcc is running in the background. If you do have a reason to use evcc at the terminal, make sure to stop the service (for example, with `systemctl stop evcc`) beforehand. ### The evcc UI isn’t accessible [Section titled “The evcc UI isn’t accessible”](#the-evcc-ui-isnt-accessible) Check the log to find the cause of the error. How to access the log is described in [Installation](/en/installation) under your respective installation method. ### MQTT plugin shows `outdated` warning [Section titled “MQTT plugin shows outdated warning”](#mqtt-plugin-shows-outdated-warning) When using the [MQTT plugin](/en/reference/plugins#mqtt), you can control how long a value received via MQTT remains valid using the `timeout` parameter. If no new value arrives within this time, the value is considered `outdated` by evcc. It is important to specify a unit here, e.g. `timeout: 30s`. ## Charging [Section titled “Charging”](#charging) ### Vehicle starts charging when plugged in, even though there’s no surplus [Section titled “Vehicle starts charging when plugged in, even though there’s no surplus”](#vehicle-starts-charging-when-plugged-in-even-though-theres-no-surplus) Some chargers start charging as soon as the car is plugged in, or when an RFID card is presented. This behaviour can’t always be influenced by evcc, but evcc does recognise this and stops the charging after a short time. ### Solar Production in Winter [Section titled “Solar Production in Winter”](#solar-production-in-winter) In the winter months, solar production is often regularly below the configured minimum. In order to get as much energy into the Vehicle as possible, you can try some of the following tips and tricks: #### Using `residualpower` [Section titled “Using residualpower”](#using-residualpower) In the configuration under the [`site`](/en/reference/configuration/site) flag, set [`residualPower`](/en/reference/configuration/site#residualpower) to a **negative** value. This determines how much power the grid can supply to nudge your solar production up enough to cover the minimum. Changes are possible via the API. **Exmaple**: ```yaml site: residualPower: -1000 # 1000W grid cover in Solar mode ``` The disadvantage of this solution is that the grid power is used even when sufficient excess is available. #### With `enable/disable` [Section titled “With enable/disable”](#with-enabledisable) In the configuration under the [`loadpoints`](/en/reference/configuration/loadpoints) flag, you can tweak the `enable` and `disable` logic to suit. Changes to the `threshold` value are possible via the API. **Example**: ```yaml loadpoints: enable: delay: 1m threshold: -200 # Charging starts when 200w of feed-in occurs for 1 minute. disable: delay: 30m threshold: 1200 # Charging stops when the grid supplies 1.2kW of energy for more than 30 minutes. ``` ### PSA (Peugeot / Citroën / Vauxhall / Opel): Charging status is only updated when I use the app [Section titled “PSA (Peugeot / Citroën / Vauxhall / Opel): Charging status is only updated when I use the app”](#psa-peugeot--citroën--vauxhall--opel-charging-status-is-only-updated-when-i-use-the-app) This is unfortunately a restriction of the manufacturer’s online service - PSA delivers outdated values until they are renewed by opening the mobile app. Sadly, ## Password [Section titled “Password”](#password) []() ### I forgot my password. How can I reset it? [Section titled “I forgot my password. How can I reset it?”](#i-forgot-my-password-how-can-i-reset-it) The password is stored encrypted, so it can’t be read. You can set a new password via the command line. Make sure to stop evcc before changing the password. ```bash service evcc stop sudo -u evcc evcc password set --database /var/lib/evcc/evcc.db service evcc start ``` Alternately, you can reset the password. You’ll be prompted to set a new password the next time you access the evcc UI. ```bash service evcc stop sudo -u evcc evcc password reset --database /var/lib/evcc/evcc.db service evcc start ``` ### How can I backup and restore my configuration? [Section titled “How can I backup and restore my configuration?”](#how-can-i-backup-and-restore-my-configuration) In the evcc web interface, go to **Configuration** → **Backup & Restore**. **Backup:** Downloads a copy of your database (evcc.db). This contains all configured devices, services, plans, charging sessions, etc. **Restore:** Restores a previously downloaded database. A local backup (`evcc.db.bak`) is automatically created before overwriting. Caution All actions are password-protected. Restoring will completely overwrite your current data. **Reset:** You can delete individual areas of your database: * **Charging sessions:** Deletes your charging session history. * **Configuration & settings:** Deletes all configured devices, services, plans, caches, etc. Caution After resetting the configuration, you’ll need to reconfigure all devices. Your `evcc.yaml` (if present) remains unchanged. Alternatively, you can delete individual caches via the command line: ```bash evcc cache get # Clear all caches evcc cache clear ``` ## PV Forecast [Section titled “PV Forecast”](#pv-forecast) You can use various [pv forecasts](/en/tariffs#pv-forecast) in evcc to see the estimated remaining production for the current day and the upcoming days. As an experimental feature, we have also built in the possibility to adapt the forecasts to your actual production. ### Forecast Adjustment [Section titled “Forecast Adjustment”](#forecast-adjustment) In addition to the forecast, evcc also logs the current solar power and accumulates this over time. This also happens for the forecast data. By comparing the two values over time, evcc can adjust the forecasts to match your actual production values. You can enable and disable this adjustment in the forecast dialog in the UI. ### Resetting the adjustment data [Section titled “Resetting the adjustment data”](#resetting-the-adjustment-data) If the adjustment values are not correct, you can reset them. Procedure: 1. Stop evcc 2. Run the following command via the CLI ```bash # Reset adjustment history. Confirm with `y`. evcc settings set solarAccForecast 0 evcc settings set solarAccYield "{}" ``` 3. Start evcc again Now evcc will start accumulating the forecasts from zero. ## Statistical Data [Section titled “Statistical Data”](#statistical-data) ### Telemetry & Community Data [Section titled “Telemetry & Community Data”](#telemetry--community-data) The [evcc Website](https://evcc.io/#live) (and the “Charge Energy Overview” dialog in the evcc UI) shows aggregated live charging data from evcc installations. We collect this data on our central *api.evcc.io* server - participation is completely voluntary. #### How do I participate? [Section titled “How do I participate?”](#how-do-i-participate) Simply turn on the toggle in the “Charge Energy Overview” dialog in the evcc UI. **A 💚 Sponsor Token is currently required to participate in Community Data**. This helps ensure that our data quality stays high, and poor / fake data stays out. #### What data is currently being collected? [Section titled “What data is currently being collected?”](#what-data-is-currently-being-collected) We currently collect the following: * current charging power * current proportion of charging power supplied by solar * total charged energy * total proportion of energy supplied by solar We may collect more data in the future, but this will **never** be personal data or private information (such as location). Your privacy is really important to us! #### What happens to the data? [Section titled “What happens to the data?”](#what-happens-to-the-data) We save the amount of energy aggregated per evcc instance. We **do not form user profiles over time**, and have no interest in doing this in the future. Our goal is to inspire more users to use evcc, learn more about how users use evcc, and above all, visualise the potential of renewable solar energy being used by evcc. The data shown can be called up by anyone using our [API](https://api.evcc.io/v1/total). If you’ve got some awesome idea for a creative visualisation, please build something and let us know about it! You can find more information on how we use data at our [Privacy Policy](https://sponsor.evcc.io/privacy) (DE). ### Savings Calculation [Section titled “Savings Calculation”](#savings-calculation) In the bottom right of the evcc interface, you’ll find the percentage of energy used to charge your vehicle(s) that has come from Solar power (for example, *85% solar energy*). If you click on it, you’ll get a dialog showing more details, including on total calculated savings versus grid. To make sure that these figures are accurate, please make sure your `evcc.yaml` includes the appropriate `tariffs` configuration. **Example**: ```yaml tariffs: currency: EUR # (default EUR) grid: type: fixed price: 0.294 # [currency]/kWh feedin: type: fixed price: 0.08 # [currency]/kWh ``` More details, including on how to use variable rate tariffs (such as those from Octopus Energy) can be found in [Configuration - Tariffs](/en/tariffs). *Please note that these statistics are rough and shouldn’t be treated as perfectly accurate.* When calculating savings, evcc uses the total amount of charged energy, and the energy sources used during charging (grid, house battery, solar). **What is Solar Energy?** Solar Energy is energy used directly from the Solar installation, and energy provided by any installed house battery. evcc assumes that the house battery is primarily used to store excess, self-produced solar power. If the house battery also discharges to satisfy other loads, or charges from grid supply, this assumption isn’t always correct. Battery losses from inversion / rectification are also not taken into account. **Calculation of savings / effective price** The algorithm distinguishes between grid supply and self-generated solar energy (solar and house battery). The cost advantage of your solar energy is calculated from the difference between your grid import rate (e.g 30ct/kWh) and your feed-in tariff (e.g 8ct/kWh). In this example, each unit of produced energy is 22ct (30ct - 8ct) cheaper than the grid import rate. If you charged a vehicle with 2 kWh of your own energy, this would then correspond to an effective saving of 44ct. If you charged 100% with your own solar energy, the displayed *effective energy price* would be the cost of not exporting to the grid, i.e the feed-in tariff (9ct/kWh). If you charge with 50% solar energy and 50% grid power, the *effective energy price* adapts accordingly (e.g 19ct/kWh). If you don’t receive a feed-in tariff for exporting power to the grid, you can set the feed-in price to 0 - the solar energy is then treated as being free of charge. **Calculation of the solar energy share** If you draw energy from several sources at the same time (e.g. 50% PV, 50% grid), your own energy is first allocated to your home. This means all consumers that are not evcc controlled. The remaining share is then divided among the charging sessions. Example: Your PV system generates 3 kW. These 3 kW are completely consumed by the house (e.g. washing machine). In parallel, you charge your car with 3 kW (e.g. mode = fast). In this case, the house is calculated with 100% solar share, the car with 0%. Flexible pricing (Octopus Energy, Awattar, Tibber, etc) is taken into account when determining the effective energy price. # iOS & Android App The Web UI is the easiest way to use evcc from any device. But there are some features that are only possible with a native app. ## About the App [Section titled “About the App”](#about-the-app) There is an official companion app for iOS and Android. It automatically finds evcc instances in your network and comes with better online/offline detection. The app adapts the Web UI even better to each device. Touch interactions are more reliable and the screen space is used more efficiently. Read more [here](https://github.com/evcc-io/app?tab=readme-ov-file#features). ## Download [Section titled “Download”](#download) The app is available on the Apple App Store, Google Play Store, and F-Droid. [](https://apps.apple.com/app/evcc-io/id6478510176)[](https://play.google.com/store/apps/details?id=io.evcc.android)[](https://f-droid.org/packages/io.evcc.android)[](https://apps.apple.com/app/evcc-io/id6478510176) You can find the source code and Android APKs in the [GitHub repository](https://github.com/evcc-io/app). [](https://github.com/evcc-io/app/releases/latest) ## Remote Access [Section titled “Remote Access”](#remote-access) Just like when accessing via browser, you need to be on the same network as your evcc instance when using the app. For internet access, we recommend using VPN services. Many routers include such functionality, but services like [Tailscale](https://tailscale.com/) or [ZeroTier](https://zerotier.com/) are also commonly used. ## URL Scheme [Section titled “URL Scheme”](#url-scheme) The app registers an `evcc://` URL scheme. Use it to prefill the server setup or jump to a page via a link or QR code. See [evcc App](/en/reference/app) for the available links. ## Perspectives [Section titled “Perspectives”](#perspectives) With the native app, we’ve created the foundation for future features that aren’t possible with the Web UI. Native push notifications or platform-specific features like widgets will follow sooner or later. # Home Battery Many photovoltaic systems are now combined with a home battery. The battery stores excess solar energy and makes it available again when needed. evcc has a number of functions to optimize the interaction between the electric car and the home battery. If the battery or hybrid inverter is configured, evcc knows the charge level of the home battery and can take this into account when regulating the charging of the electric car. ## Where does the solar energy go first? [Section titled “Where does the solar energy go first?”](#where-does-the-solar-energy-go-first) Home batteries react very quickly to available surplus and absorb this energy. In the standard case, the home battery would therefore be fully charged first before any free surplus flows into the electric car. If you have a larger storage unit, it may also make sense to start charging the electric car earlier. You can configure this behavior on the **Battery** page, which you can open from the navigation bar.  Battery page in the navigation bar Here you set the charge level up to which the home battery should be charged with priority and from when the electric car can use the surplus. With the lower limit you determine how much energy is reserved for home consumption (1) and in which area the vehicle has priority (2).  Priority Home and Car Example: You set the limit to 50%. This means that solar energy flows into the home battery first. If the battery reaches a charge level of 50%, charging points that are in Solar mode are released. The charging power is regulated so that the home battery maintains its charge level. If the surplus exceeds the maximum charging power of the battery, the vehicle will be charged before reaching the limit. If no vehicle is connected or fully charged, excess energy continues to flow into the battery. ## Battery-supported vehicle charging [Section titled “Battery-supported vehicle charging”](#battery-supported-vehicle-charging) In Solar mode, evcc tries to control the charge so that only solar energy is used directly. Discharging the home battery is avoided. With the **Battery-supported vehicle charging** function, you can explicitly release part of your home battery for charging the electric car. The upper limit determines which part (3) of the stored energy can flow into the electric car.  Battery-supported vehicle charging Example: You release the area above 75% for Battery-supported charging. Your home battery has already filled up to 100% during the day. You plug in your electric car in Solar mode. In addition to the available surplus, the released upper 25% of the home battery is now also used to charge the electric car. If there is no surplus available and the charge level of the home battery has fallen to 75%, charging is stopped. This feature is particularly useful if you have a storage unit whose capacity can cover more than your usual household consumption. It then enables you to charge the car in the evenings, for example, when there is little sun left. Efficiency and conversion losses: Generally, it is recommended to charge the car directly with solar energy if possible. Taking the detour through the home battery always results in conversion losses, which, depending on the system, can amount to [5-10%](https://solar.htw-berlin.de/studien/stromspeicher-inspektion-2024/). ### Automatic start [Section titled “Automatic start”](#automatic-start) In solar mode, the charging process only starts when there is a surplus available. If you plug in your car when there is no surplus available, the charging process will not start. Not even if there is enough released energy in the home battery. You can change this behavior with the “start automatically …” option. If you set the value here to ”… when over 90%”, for example, the charging process will start when the home battery has reached this level. As in the previous example, the charging ends when the charge level of the home battery has dropped to the set limit (here 75%).  Automatic Start ## Battery Boost [Section titled “Battery Boost”](#battery-boost) Battery boost supports **Solar** and **Min+Solar** mode with power from the home battery. In addition to the power available from the photovoltaic system the maximum available power from the home battery is used. To bring the home battery to its maximum output power, a small grid consumption is required. Activating the boost is a two-step process. First, select a **Battery Boost** limit in the settings of the charging point. This enables the feature and defines how far the home battery may be drained.  Set the battery boost limit A boost button then appears next to the charging progress indicator of the charging point. Click it to start boosting for the current charging session. The green fill of the button shows how much boost energy is left before the home battery reaches the limit. Clicking the button again stops the boost. It also ends when the car is unplugged or the mode is changed.  Active boost button at the charging point Example: This is useful if the car leaves the charging station in near future and there will be an excess of solar power in the upcoming hours. In doing so the energy in the car is maximized, while the home battery will recharge while the car is away. The above-mentioned priority settings are overridden for this charging session. ## Multiple batteries [Section titled “Multiple batteries”](#multiple-batteries) Of course, you can also configure multiple batteries in evcc. In the user interface, an average charge level is calculated from the respective charge level and the battery capacity. This value is the basis for the control functions described above. Example: You have a 5 kWh storage unit that is 50% charged. In addition, you have a 10 kWh storage unit with a charge level of 80%. This results in an average value of 70%, since 10.5 kWh (2.5 kWh + 8 kWh) of 15 kWh (5 kWh + 10 kWh) are filled. You can view the individual charge levels on the **Battery** page. ## Active battery control [Section titled “Active battery control”](#active-battery-control) The functions described above are compatible with all battery systems. evcc simply adjusts the charging control of the electric car depending on the charge level of the home battery. In some cases, however, this control is not sufficient and it is necessary to control the battery directly. Many newer battery or hybrid inverters offer an interface for this. ### Discharge Lock [Section titled “Discharge Lock”](#discharge-lock) Scenario 1: You have to go to an appointment spontaneously and want to charge your car quickly. However, you do not want the home battery to be completely discharged as a result. Scenario 2: You have a dynamic electricity tariff and want to charge your car at night because energy is particularly cheap then. However, the home battery will try to cover the charging demand as long as it has energy left. The cheap night-time electricity is only used once the home battery is empty. If your system supports active battery control, you can activate the “Prevent discharge in fast mode and planned charging” option on the **Battery** page. This puts the home battery into a locked state when a fast charging process is active. This can be triggered by fast mode, smart grid charging, charging planning or minimum charging. The blocking state applies for the period of fast charging. The home battery is not discharged during this time. []() ### Grid Charging [Section titled “Grid Charging”](#grid-charging) Scenario: You have a dynamic electricity tariff and want to charge your home battery with cheap electricity at night. For example, because the surplus generated during the day is not enough.  Grid charging section on the Battery page Similar to [CO₂-](/en/features/co2) and [price-optimized charging](/en/features/dynamic-prices) for vehicles, you can also charge the home battery with cheap electricity. If your inverter supports this function, the **Grid charging** section appears on the **Battery** page. You can set a limit here. If the current electricity price falls below this limit, the home battery will be charged from the grid and simultaneously locked to prevent discharging. German regulation § 14a EnWG During active [power reduction from an external limit](/en/external-limit), grid charging is automatically paused and battery discharge is locked (“hold” mode). Charging the battery from solar surplus is usually still possible. After the power reduction ends, grid charging automatically resumes. Load Management Home battery grid charging is not considered by [load management](/en/features/loadmanagement). For example, if the home battery draws 9 kW from the grid, this consumption is not included in load management calculations. This does not apply to § 14a power reduction signals – in that case, grid charging is automatically paused as described above. Optionally, you can set a maximum charge level up to which the battery is charged from the grid. When the battery reaches this value, grid charging is automatically stopped. The **Maximum charge** (`maxsoc`) option can be found in your battery system’s device configuration. Under [PV, Battery, Grid, Meter](/en/meters) you can see on the **Active battery control** tag whether your system supports battery control and if `maxsoc` is available. # CO₂-Optimized Charging Self-produced energy is not always enough to cover your own charging needs, and you have to fall back on mains electricity. In this case, it makes sense to start the charging process when there is as much CO₂-neutral energy as possible in the public power grid. Even if you have a green electricity tariff that advertises 0 gCO₂/kWh, optimized charging still makes sense. Although these tariffs are CO₂-neutral in terms of the national balance sheet, you will be using the local electricity mix. If there is little renewable energy available in the power grid, the additional electricity demand must be covered by fossil fuels. ## Configuring the Data Source [Section titled “Configuring the Data Source”](#configuring-the-data-source) In order to charge in a CO₂-optimised way, evcc needs forecast data about CO₂ emissions in your region. You can add the data source under **Configuration → Tariffs & Forecasts → Add forecast → Add CO₂ forecast**. Select your data source in the **Provider** field, e.g. [Grünstromindex](https://www.gruenstromindex.de/) (Germany only), and fill in the provider-specific fields such as your postcode. See [tariffs](/en/tariffs) for a list of all supported data sources. ## Clean web charging [Section titled “Clean web charging”](#clean-web-charging) Open the settings dialog at the charging point.  Settings at the charging point The CO₂ forecast data is displayed in the bar chart. Each bar represents an hour. You can select your desired CO₂ limit via the selection field or by clicking on a bar.  Screenshot of the Smart Grid Charging dialog with set CO₂ limit This limit applies in the PV mode of the current charging point. By clicking on “apply everywhere”, the limit for all charging points is applied. In addition to PV surplus charging, fast charging is now activated during the hours with low CO₂ emissions (green bars). This setting is useful to ensure a fully charged battery in the winter months, whilst still relieving the power grid. ## Load planning [Section titled “Load planning”](#load-planning) By using [charging plans](/en/features/plans), you can control CO₂-optimised charging even more precisely. All you have to do is enter your amount of energy (kWh) or your destination charge level (%) and the desired departure time. When a CO₂ data source is configured, the scheduling algorithm automatically selects the hours with the lowest CO₂ emissions.  Screenshot of the charging plan dialog with optimised CO₂ charging Tip If you have configured a [dynamic electricity tariff](/en/features/dynamic-prices), it will be preferred. The CO₂ data will continue to be collected at your charging sessions. However, the planning algorithm and the “Cheap Grid Charging” function now optimize for price instead of CO₂ # Dynamic Feed-In These features are relevant if you have a [dynamic feed-in tariff](/en/tariffs) (e.g., direct marketing, Netherlands, Australia, etc.). ## Feed-in priority [Section titled “Feed-in priority”](#feed-in-priority) By default, evcc uses solar surplus first to charge the car. Only then is the solar energy fed into the grid. During times of high feed-in rewards, it can be beneficial to prioritize the feed-in and charge the car later.  Screenshot of the feed-in prioritization feature with a set price limit With the *Feed-in priority* feature, you can set a price threshold per charging point. When the feed-in tariffs are high (shown as orange bars), charging is paused (**solar mode**) or reduced to a minimum (**min+solar mode**). # Dynamic Tariffs If your own PV power is not sufficient, the charging power requirement must be covered from time to time by grid power. If you have an electricity tariff with flexible electricity prices such as [Tibber](https://tibber.com/de/) or [Awattar](https://www.awattar.de/), you can optimize your grid charging with evcc. ## Configure data source [Section titled “Configure data source”](#configure-data-source) Your electricity price is configured under **Configuration → Tariffs & Forecasts → Add tariff → Add grid import tariff**. The currency can be changed under **Configuration → General → Currency**. ### Fixed electricity tariff [Section titled “Fixed electricity tariff”](#fixed-electricity-tariff) For a fixed electricity tariff, choose **Fixed Price** in the **Provider** field and enter your price per kWh. This information is used to calculate the actual charging costs. ### Time-dependent electricity tariff [Section titled “Time-dependent electricity tariff”](#time-dependent-electricity-tariff) If different prices apply at certain times, choose **Time-based Tariff** in the **Provider** field. Enter your regular price in the **Default price** field. With **Add zone** you can define as many periods as you like in which a different price applies, e.g. on weekdays from 2 to 6 am or at the weekend. Each zone has its own price and can be limited to specific days and hours. ### Dynamic electricity tariff via API [Section titled “Dynamic electricity tariff via API”](#dynamic-electricity-tariff-via-api) If you have an electricity tariff that follows electricity exchange prices, for example, you can also obtain the prices via an API. Choose your provider in the **Provider** field, e.g. [Tibber](https://tibber.com/de/), and enter the provider-specific access data such as the API token. You can find a list of all supported tariffs under [tariffs](/en/tariffs). If your provider has an interface but is not yet supported by evcc, please submit a [Feature Request](https://github.com/evcc-io/evcc/issues/new/choose). ### Time-based grid fees [Section titled “Time-based grid fees”](#time-based-grid-fees) If your grid operator bills time-dependent grid fees (e.g. time-variable network charges according to § 14a EnWG in Germany), you can add them on top of any tariff using `chargesZones`. See [time-based grid fees](/en/reference/configuration/tariffs#charges-zones) for details. ## Smart feed-in [Section titled “Smart feed-in”](#smart-feed-in) During certain periods of the day and in specific regions, there might be an abundance of solar power. At the same time, there may be almost no load on the grid. During these periods your energy provider might apply a cost for injecting your PV-power to the grid as supply is high but demand is low and the grid is overloaded. evcc supports smart feed-in and allows you to define a set point at which it will throttle PV inverters to prevent feed-in. ## Cheap grid charging [Section titled “Cheap grid charging”](#cheap-grid-charging) If you have configured a time-dependent or dynamic electricity tariff, the “Cheap grid charging” section will appear in the settings dialog at the charging point.  Settings at the charging point Here you can see the energy prices for the coming hours and set a price limit.  Screenshot of the Smart Grid Charging dialog with set price limit This limit applies in **solar mode** of the current charging point. If you click on “apply everywhere”, the limit is applied to all charging points. In addition to [Solar Surplus Charging](/en/features/solar-charging), fast charging is now activated in the hours with low electricity prices (green bars). ## Charging plan [Section titled “Charging plan”](#charging-plan) By using [charging plans](/en/features/plans) you can regulate your energy costs even more precisely. All you have to do is enter your energy quantity (kWh) or your target charge level (%) and the desired departure time. If a time-dependent or dynamic electricity tariff is configured, the planning algorithm automatically selects the cheapest hours for charging.  Screenshot of the charging plan dialog with price-optimised charging # Minimum Charge & Limits Most vehicle batteries don’t like being left with a very high or low charge level for long periods of time. Therefore, it makes sense to keep the battery charge level within a certain range. The minimum charge and charge limit help with this. ## Minimum charge [Section titled “Minimum charge”](#minimum-charge) With the minimum charge, you can define a value for each vehicle to which the vehicle should be charged as quickly as possible after plugging it in. This ensures that the vehicle does not remain at a low charge level for longer than necessary. You also have the convenience of always having a certain range available for spontaneous trips. An example: You arrive home with a charge level of 5%. If you have defined a minimum charge of 20%, the vehicle is immediately charged to 20%. If necessary, also with energy from your home battery or from the power grid. The vehicle then charges as usual with [Solar surplus charging](/en/features/solar-charging). ### Setting [Section titled “Setting”](#setting) You can find the **Minimum charge** setting in the **Vehicle Settings** dialog, which you open via **More → Vehicles** in the navigation bar.  Screenshot of the minimum charge setting in the vehicle settings dialog The prerequisite is that a vehicle with a known charge level (online API) is selected at the charging point. The setting is not available for guest vehicles or configured vehicles without an online API (offline vehicle).  Screenshot of a charging point with active minimum charge An active minimum charge is indicated in the UI by a red area in the progress bar. Note If evcc cannot determine the charge level of your vehicle when plugging it in, the system assumes that your vehicle is empty. This means that evcc charges the calculated amount of energy into the battery up to the minimum charge (e.g. 0-20%). The basis here is the battery capacity stored on the [vehicle](/en/features/vehicle). If this occurs regularly, e.g. because the reception at the charging point is poor, you should deactivate the minimum charge. ### Heating devices [Section titled “Heating devices”](#heating-devices) For charging points with a heating device, you can define a minimum temperature instead. If the measured temperature is below this value, battery and grid power are also used in solar mode to maintain this temperature. You can find the **Min. temperature** setting in the settings dialog of the charging point under **Heating**. ## Charging limit [Section titled “Charging limit”](#charging-limit) The charging limit sets the upper charging limit. This ensures, for example, that the vehicle is only charged up to 80%. Depending on the vehicle, there are two different variants: energy-based and charge level-based. ### Energy quantity (kWh) [Section titled “Energy quantity (kWh)”](#energy-quantity-kwh) For guest vehicles or configurations without an online API (offline vehicle), you can define the charging limit in kWh. If, for example, you select a limit of 30 kWh, charging stops as soon as this amount is reached in the current charging process.  Screenshot of a charging point Energy limit of 15 kWh By default, you can select a value in 5 kWh increments up to 100 kWh. If you have stored the battery capacity of your vehicle in the [vehicle parameters](/en/reference/configuration/vehicles#capacity), the increments will be adjusted accordingly. You will also see how many percent of the battery the selected amount of energy corresponds to. The set energy limit only applies to the current charging process and is removed again when unplugged. ### Charge level (%) [Section titled “Charge level (%)”](#charge-level-) If evcc knows your charge level (online API), you can define the charging limit in percent. For example, if you select a limit of 80%, charging stops as soon as this charge level is reached. The set limit is shown in the progress bar by a green slider. You can also use this to adjust the limit directly in 5% increments.  Screenshot of a charging point charging limit at 90% The set charging limit only applies to the current charging process and is reset to 100% when unplugged. You can, however, set a **Default limit** per vehicle in the **Vehicle Settings** dialog (**More → Vehicles**). The value defined here is used as the charging limit when the vehicle is plugged in.  Screenshot of the default limit setting in the vehicle settings dialog Example: You have defined a standard charging limit of 80%. For a trip, you increase the charging limit to 90% using the slider. This 90% only applies to the current charging process. The next time you plug in the vehicle, your charging limit will be 80% again. ### Vehicle-specific limit [Section titled “Vehicle-specific limit”](#vehicle-specific-limit) With many electric cars, you can set a charging limit directly in the vehicle. If possible, we will show you the vehicle limit in the progress bar as information. It is shown as a small interruption. You can use a tooltip to display the specific value. The vehicle limit is not changed by evcc. Important for everyday use: The limit set in the vehicle is a hard limit that evcc cannot exceed. Some users therefore set the vehicle limit to 100% and use evcc to limit the charging. Others prefer to use the vehicle limit directly. What makes the most sense for you depends on your usage and your vehicle (e.g. quality of the vehicle app). ### Interaction of charging planning [Section titled “Interaction of charging planning”](#interaction-of-charging-planning) Using [Charge Planner](/en/features/plans) you can define by when a certain amount of energy or charge level should be reached. Charging plans have a higher priority than the charging limit. If, for example, a charging plan is active for “8 a.m. tomorrow at 100%”, this would temporarily override a limit set at the charging point of, for example, 80%. # Load Management Experimental The Load Management feature is still experimental. It may not perform as expected in combination with some other features. The load management/load balancing feature can be used to limit the power used by chargers to prevent overloading the circuits and tripping breakers. By limiting the power, it could also be useful if you want to avoid accidental high peak usage. To accomplish this, a charging point can be assigned to a `circuit`. A `circuit` can have a maximum current value (`maxCurrent`) and/or a maximum power value (`maxPower`). The system works hierarchically, i.e., an electrical circuit can be part of a higher-level electrical circuit. Configuration via UI This page describes the configuration via the `evcc.yaml` file. Configuration is also possible via the UI. Circuits can be defined under **Configuration → Load Management**. The input uses YAML format and corresponds to the content below `circuits:` in the examples that follow. We are working on replacing this with a form-based approach. Each charging point can then (restart required) be assigned to a circuit under **Configuration → Charging points & Heaters → \[name]**. ## Configuration [Section titled “Configuration”](#configuration) The section `circuits` defines the circuits. Each charging point can then be assigned to an electrical circuit. ### Example: Main Circuit [Section titled “Example: Main Circuit”](#example-main-circuit) ```yaml circuits: - name: main # if there is only one circuit defined the name needs to be 'main' title: "main circuit" # name for the UI (not implemented in UI yet) maxCurrent: 63 # 63A (optional) maxPower: 30000 # 30kW (optional) meter: grid # optional loadpoints: - title: Garage circuit: main ``` This configuration only configures a main circuit. The circuit has a maximum current of 63A. If there are other consumers like an oven/heat pump (this requires a meter) using a total of 50A, the charger will only be allowed to use 13A. The circuit has a limit of 30kW. Since the grid meter is assigned to this circuit, the power of the charging points will be throttled so that the limits ​​are not exceeded at the grid connection. Without the grid meter assigned, the limits apply directly to the sum of all charging points. ### Example: Nested Circuits [Section titled “Example: Nested Circuits”](#example-nested-circuits) ```yaml circuits: - name: main title: "main circuit" maxCurrent: 48 - name: garage title: Garage maxCurrent: 32 parent: main - name: carport title: Carport maxCurrent: 32 parent: main loadpoints: - title: Garage A circuit: garage - title: Garage B circuit: garage - title: Garage C circuit: garage - title: Carport A circuit: carport - title: Carport B circuit: carport - title: Heat Pump circuit: main ``` Here we have two circuits, `garage` and `carport`, both of which are children/downstream of the main circuit (`parent: main`). The `main` circuit has a maximum current of 48A. The circuits `garage` and `carport` each have a maximum current of 32A. The charging points Garage A, Garage B, and Garage C are assigned to the `garage` circuit (`circuit: garage`). The charging points Carport A and Carport B are assigned to the `carport` circuit (`circuit: carport`). The circuits `garage`, `carport`, and the heat pump are connected directly to the root circuit (`main`). The regulation ensures that the limits of the respective circuits are not exceeded at any time. **Important:** There must always be exactly one root circuit (a circuit without `parent` property). External Limit (§ 14a, § 9) When an [external limit](/en/external-limit) is active, it caps the power of the root circuit. This is indicated by a “Consumption limited” hint on the Load Management card. ## Measuring [Section titled “Measuring”](#measuring) By default, the control system calculates the current power and current from the sum of the respective charging points. By configuring a `meter` on a `circuit`, the real load can also be taken into account. This is particularly useful if other consumers are also connected to the fuse. ```yaml site: meters: ext: - carport_meter meters: - name: carport_meter type: template template: shelly-3em circuits: - name: carport meter: carport_meter maxCurrent: 32 ``` Note: If a meter is used that is not yet used for another purpose (e.g. `grid`), it must be linked as an external meter under `site.meters.ext`. ## Limits [Section titled “Limits”](#limits) Both a maximum current per phase (`maxCurrent`) and a maximum power (`maxPower`) can be configured on each circuit. These values, if configured, are monitored independently of each other. ### External limits [Section titled “External limits”](#external-limits) If necessary, external limits can also be defined using `GetMaxCurrent` and `GetMaxPower`. In the event of an error, the predefined limits apply. Example: ```yaml circuits: - name: main title: "main circuit" maxCurrent: 48 GetMaxCurrent: source: mqtt topic: ext/maxcurrent maxPower: 33000 GetMaxPower: source: mqtt topic: ext/maxpower ``` Note An external limit can be used to implement control requests from the grid operator. For more information, see [External Limit](/en/external-limit). ## Phase Switching [Section titled “Phase Switching”](#phase-switching) For chargers with automatic phase switching (1P/3P), load management can use the switching capability to charge within the configured limits. When available power is insufficient for 3-phase charging, evcc automatically switches to 1-phase charging. This applies to fast charging and plan-based charging as well. For example, if load management limits available power to 3.5 kW, evcc switches to 1-phase charging (from 1.4 kW) instead of pausing the charge. **Requirement:** The charger must support phase switching. ## Charger Configuration [Section titled “Charger Configuration”](#charger-configuration) Some chargers come with their own load management features. It is strongly recommended to disable these or use chargers without built-in intelligence. evcc expects devices to follow its commands directly. Other configurations may cause unexpected behaviour and must be tested thoroughly on your own. ## Restrictions [Section titled “Restrictions”](#restrictions) Note A separate license will be required later for commercial use of load management. Private use with smaller installations will remain free of charge. * Current values and limits of individual circuits are displayed on the configuration page in the UI. Visualization at the charging point is planned. * `priority` settings at the charging point are not yet taken into account. * New sessions receive only the remaining circuit headroom. Rebalancing across active sessions is not yet supported. * Home battery [grid charging](/en/features/battery#gridcharge) is not considered. When the home battery actively charges from the grid, this consumption is not included in load management calculations. However, during active [§ 14a power reduction](/en/external-limit) signals, grid charging is automatically paused. # Optimizer 🧪 Experimental The optimizer is in an early stage of development. The displayed data is currently informational only. Control actions will follow in future versions. The optimizer analyses forecasts, consumption data, and the current state of your energy system to make cost-optimal decisions. It complements evcc’s rule-based control with predictive optimisation. ## Why an Optimizer? [Section titled “Why an Optimizer?”](#why-an-optimizer) evcc works rule-based and deterministically. This works great for many setups. E.g. a solar system, battery, and one vehicle. More complex scenarios push this approach to its limits: * **Multiple vehicles:** Which one should be charged first? * **Battery or vehicle:** Where should the available energy go? * **Dynamic tariffs:** Is it worth charging from the grid tonight, or will there be enough solar energy tomorrow? The optimizer can answer these questions. Currently, you set values like price limits or battery priorities yourself. In the future, you can let the optimizer handle these decisions. It will then automatically find the optimal values. We’re working on this step by step. ## What Does the Optimizer Do? [Section titled “What Does the Optimizer Do?”](#what-does-the-optimizer-do) The optimizer collects various data: * **Forecast data:** Solar yield, electricity prices, feed-in tariffs * **Historical data:** Your household’s typical consumption profile * **Current state:** Battery state of charge, connected vehicles, heating demand Based on this data, an optimisation algorithm calculates the expected behaviour of your energy system. It identifies cost-optimal actions: efficient [charging plans](/en/features/plans), battery control (hold, grid charging). It also predicts when the home battery will be full or empty. Goal: **Minimise energy costs.** ## Using the Optimizer [Section titled “Using the Optimizer”](#using-the-optimizer) Enable via the user interface: 1. **Configuration → Experimental** → enable 2. **Configuration → Optimizer 🧪** → enable The optimizer requires an active [sponsorship](/en/sponsorship). For new installations, it can take up to 24 hours to collect enough data to show first results. * **Main view → Energy flow (expand):** Shows when the home battery is expected to be full or empty. * **Menu → Optimizer:** Graphs showing how your home battery and charging points should behave over the coming hours and what the expected energy cost over the optimization horizon will be (see screenshot below).  Optimizer debug view with forecasts and optimisation results. ## Current State & Next Steps [Section titled “Current State & Next Steps”](#current-state--next-steps) The optimizer is currently informational only. It shows forecasts and potential savings but does not yet actively control anything. Next steps: * Integrate actions: actively control the home battery * Let the optimizer optimise [charging plans](/en/features/plans) * Enable users to hand over specific settings to the optimizer ## Technical Background [Section titled “Technical Background”](#technical-background) The optimizer is Python-based and leverages the strong ecosystem for mathematical optimisation and statistics. It is not part of evcc itself but a standalone service. When enabled, the cloud service `optimizer.evcc.io` is called. The service is **stateless**. No data is stored. For privacy details, see our [privacy policy](https://evcc.io/en/datenschutz/). Like evcc itself, the optimizer is open source: [github.com/evcc-io/optimizer](https://github.com/evcc-io/optimizer). You can also install the Docker image [evcc/optimizer](https://hub.docker.com/r/evcc/optimizer) locally. Use the `OPTIMIZER_URI` environment variable to point evcc to your own endpoint. # Charge Planner If you enter **a departure time and a charging goal**, the planning algorithm will automatically find the best loading times. The planner is only active in Solar and Min+Solar mode. Self-produced solar energy continues to be preferred. If your own energy is not enough, the rest is charged from the power grid. Depending on whether you have one [dynamic electricity tariff](/en/features/dynamic-prices) or a data source for [CO₂-predictions](/en/features/co2) currently have **three charging strategies**: 1. **Cheap charging** (dynamic electricity tariff available): Vehicle charges in the cheapest hours before departure. 2. **Green charging** (CO₂ forecast available): Vehicle charges in the hours with the lowest CO₂ emissions. 3. **Standard**: The planner charges the required energy in the hours shortly before departure. This means that the vehicle’s battery is still warm when you leave and less active heating energy is required. The loading strategies cannot be selected manually, but are selected automatically based on the stored data source. ## Create charging plan [Section titled “Create charging plan”](#create-charging-plan) To set a plan, click on **Plan** at the charging point. If evcc knows the charge level of your vehicle (online API) and the battery capacity, you can enter the **desired charge level in %** in addition to the departure time in the dialog. You will be shown a preview of the charging times. Use the “Active” switch to activate your plan.  Screenshot of a charging plan using the charging status ## Charging strategy [Section titled “Charging strategy”](#charging-strategy) Behind the settings button next to the plan preview you can adjust the charging strategy. The **Optimization** setting determines how the charging slots are picked: *cheapest* selects the cheapest hours, which may result in multiple starts and stops, while *continuous* charges in one uninterrupted block just in time for departure. ## Late charging [Section titled “Late charging”](#late-charging) With the **Late Charging** option, you can specify that a part of the planned charging is moved to shortly before departure. This is useful for different scenarios: * **Preconditioning**: In winter, you start your trip with a vehicle that has already been warmed up through the charging process. Reduces active heating energy demand. * **Climate control**: Ensures that a parallel active climate control of the vehicle is covered by EV charger. * **Battery care**: For planned long trips, the vehicle does not stand unnecessarily long at a high charge level. Less battery aging.  Screenshot of a charging plan with late charging This option partially overrides the purely cost- or CO₂-based charging strategy. The late portion can be set individually, from 15 minutes up to 2 hours, or to *everything*. ## Repeating plans [Section titled “Repeating plans”](#repeating-plans) You can also create repeating plans. Define on which **weekdays** the plan should be active. When multiple plans are active, the next matching time will be used and the plan prognosis will be shown in the diagram.  Screenshot of a recurring charging plan Note These state-of-charge based plans are stored per vehicle. This means you can charge [multiple vehicles](/en/features/vehicle#multiple-vehicles) at the same charging point. The planning of the currently connected vehicle will always be used. ## Energy amount plan [Section titled “Energy amount plan”](#energy-amount-plan) If the charge level and capacity are not known, planning is done by specifying an **energy amount in kWh**.  Screenshot of a charging plan using energy amount This plan only applies to the current charging session. Repeating plans are not available in this mode. # Remote Access 🧪 Experimental Remote Access is in development. Both behaviour and configuration may still change. Remote Access lets you reach your local evcc instance from anywhere. Each instance gets its own domain on `evcc.cloud`. You don’t need dynamic DNS or a port forward in your router. ``` flowchart LR subgraph internet [Internet] app["evcc app"] browser["browser"] proxy["Remote Proxy
___.evcc.cloud"] end app <-- HTTPS --> proxy browser <-- HTTPS --> proxy proxy <-->|"secure websocket
permanent"| evcc["evcc instance
evcc.local"] ``` ## How It Works [Section titled “How It Works”](#how-it-works) Your app or browser connects to your personal domain on `evcc.cloud`. The Remote Proxy forwards the requests through a WebSocket tunnel to your local evcc instance. Your local instance opens that tunnel outbound itself, so no open port in your network is required. ## Setup [Section titled “Setup”](#setup) Remote Access requires an active [sponsorship](/en/sponsorship). 1. Enable the feature in the user interface: * **Configuration → Experimental** → enable * **Configuration → Remote Access 🧪** → enable  2. Your evcc instance registers with the Remote Proxy and receives its own domain, e.g. `swift-dark-crow.evcc.cloud`.  3. Create a separate client for every device that should have access. You receive a username, a password, and a QR code containing both. * **App:** Scan the QR code with your phone’s camera. The [evcc app](/en/features/app) opens and is connected straight away. * **Browser:** Open your personal domain and sign in with the username and password (basic auth over HTTPS). * **API clients:** Access the API programmatically with username and password. curl example ```bash curl --user Macbook:7IIGKZGP-MV0PJKSE "https://swift-dark-crow.evcc.cloud/api/state?jq=.pvPower" ```  4. The same view shows which clients were active most recently and lets you revoke individual devices at any time. Access can optionally be limited to a fixed period. ## Security [Section titled “Security”](#security) **Transport.** Requests to your domain go over HTTPS using the wildcard certificate for `*.evcc.cloud`. The link between the Remote Proxy and your local instance runs through a WebSocket tunnel. **What the Remote Proxy sees.** The Remote Proxy only forwards requests. Request content is neither stored nor inspected. Per registration, only the domain, a hash of the connection token, the linked sponsor, and timestamps are persisted, so the tunnel can be reassigned when reconnecting. **Local authorization.** You create separate credentials for each device. These are stored and checked exclusively on your evcc instance. No credentials are stored on the Remote Proxy. The password is shown only once, when the client is created. Removing a device revokes only that device’s access. All others stay connected. Repeated failed login attempts are throttled automatically. **Scope of access.** Remote access credentials sit alongside evcc’s own security mechanisms. They only grant network access to your instance, comparable to reaching it from your local network. Changes to the configuration, backups, logs, or a restart still require the administrator password. **Sponsor token binding.** Registration is verified against `sponsor.evcc.io`. Each sponsor receives exactly one domain, permanently bound to that sponsor and never reassigned. ## Technical Background [Section titled “Technical Background”](#technical-background) On first activation, the local evcc instance registers with the Remote Proxy. In exchange for the sponsor token, it receives a connection token and a randomly assigned domain. Both are stored locally and reused on the next start to re-establish the tunnel without going through registration again. On subsequent starts, the local evcc instance opens a persistent, TLS-encrypted WebSocket connection (WSS) to the Remote Proxy. This connection serves as the tunnel for all subsequent traffic and is established outbound, so no port forward is required. On top of this connection, [hashicorp/yamux](https://github.com/hashicorp/yamux) acts as the multiplexer. Each incoming HTTP request at the Remote Proxy becomes its own yamux stream on top of the existing WebSocket connection. Multiple parallel requests share one connection without a new TCP or TLS handshake per request. WebSocket upgrades over the tunnel work as well. This matters because the evcc UI itself receives live data over WebSocket. If the tunnel drops, the local instance reconnects automatically. While the connection is up, your domain is reachable; otherwise the Remote Proxy returns an error. The Remote Proxy host defaults to `api.evcc.cloud`. For development or a self-hosted proxy, it can be overridden with the `EVCC_REMOTE_ACCESS` environment variable. The source code of the Remote Proxy will be published at a later date. For privacy details, see our [privacy policy](https://evcc.io/en/datenschutz/). # Charging Sessions evcc’s core task is the intelligent charging of vehicles based on photovoltaics, battery storage and electricity tariffs. This control takes place automatically and in the background. So that you can see the effect of these optimizations, we record some measurements during the charging session. ## Current charging session [Section titled “Current charging session”](#current-charging-session) In the main view you can see information about the current charging session.  Measurements during charging 1. **Power:** Shows the current charging power in kW. The green lightning symbolizes that a charge is active. Below the power, the number of active phases and their utilization are shown as small green bars. 2. **Charged:** Shows the amount of energy already charged. If your wallbox has a meter installed, the values ​​are taken from there. For wallboxes without a meter, evcc calculates the amount of energy based on the charging power. 3. **Other values:** Depending on your installation, other measured values ​​are available. You can select these by clicking on the name. Alternatively, clicking on the numerical value switches to the next display. * **Remaining time:** Shows the time remaining until the charging target is reached. If your vehicle supports this, the remaining time is determined from the vehicle data. Alternatively, the remaining time is calculated based on the current charging power and the charging target. * **Finish time:** Shows the time when the charging target is reached based on the remaining time. As with the remaining time, the prerequisite is that the vehicle can determine the remaining time from the vehicle data. * **Charging duration:** Shows the effective duration of the charging session. If the charging session is paused (e.g. due to PV surplus), the time is stopped. * **Solar:** The percentage value shows which proportion of the charged energy comes from the PV system. Energy from the home storage is counted as solar energy. * **⌀ Price:** Shows the average price per kWh. The basis is the current electricity price, the proportion of self-consumption and any lost feed-in tariff. Only available if an [dynamic electricity tariff](/en/features/dynamic-prices) is configured. * **Σ Price:** Total price of the current charging session. The basis is the current electricity price, the share of self-consumption and any lost feed-in tariff. Only available if an [dynamic electricity tariff](/en/features/dynamic-prices) is configured. * **⌀ CO₂:** Shows the average CO₂ emissions per kWh. The basis is the share of self-consumption in combination with the CO₂ emissions of the electricity mix. Your own solar power (direct PV use and storage) is considered CO₂-free. Only available if a [CO₂ source](/en/features/co2) is configured. ## List of charging sessions [Section titled “List of charging sessions”](#list-of-charging-sessions) A charging session in evcc is the period between plugging in the charging cable and unplugging it. It is quite possible that charging was paused and restarted several times during this period. charging sessions in which no energy was used are not recorded. In the menu under “Charging sessions” you will find a list of all previous charging sessions grouped by month. The data is presented in tabular form and can be exported as a CSV or Excel file. You can filter by charging point and vehicle and view totals and average values.  List of monthly charging sessions Note: On smaller screens, a more compact view with fewer columns is shown. By clicking on the column headings, you can choose which information should be displayed. ## Charging session in detail [Section titled “Charging session in detail”](#charging-session-in-detail) Clicking on an entry in the list opens the detailed view of the charging session. There you can see all available values ​​including the mileage of your vehicle, if available. If a vehicle was not recognized correctly, you can also correct the vehicle assignment or delete the charging session in this view.  Detailed view of a charging session ## Switchable sockets and heating [Section titled “Switchable sockets and heating”](#switchable-sockets-and-heating) In contrast to wall boxes, there is no way to detect the charging session with switchable sockets (e.g. Schuko charger, e-bike, …) or heating systems (e.g. heat pump, heating element, …). ### Heating systems [Section titled “Heating systems”](#heating-systems) For heating systems (heat pumps, heating elements, etc.), charging sessions are automatically reset daily at midnight. This means measurements are captured for each day separately and the list of charging sessions remains clear. ### Switchable sockets [Section titled “Switchable sockets”](#switchable-sockets) For switchable sockets, charging sessions with long periods of time are logged. If evcc is restarted, a new charging session is logged. This can also be done manually by actively stopping and starting at the charging point (mode: off). # Solar Surplus Charging Use excess solar energy to charge the electric car. This is the core function of evcc. ## Solar mode [Section titled “Solar mode”](#solar-mode) The function can be activated at the charging point via **Solar mode**.  Screenshot of a charging point. Cursor clicks on the Solar mode. In this mode, charging starts automatically as soon as the PV system delivers **enough power**. The charging power is continuously adjusted so that **no power is drawn from the grid** if possible. If the PV system no longer delivers enough power or if household consumption increases, charging is paused and continued later. ### When does charging start? [Section titled “When does charging start?”](#when-does-charging-start) All electric cars have a **minimum charging power**. This is determined by the minimum current of 6 A specified in the charging standard [IEC 61851](https://en.wikipedia.org/wiki/IEC_61851). The minimum charging power depends on the number of phases that the car and wallbox use for charging. | Phases | Minimum charging power (6 A) | Maximum charging power (16 A / 32 A) | | :-------- | :----------------------------- | :-------------------------------------------------------- | | 1-phase | **1,4 kW** (1 x 6 A x 230 V) | **3,7 kW** (1 x 16 A x 230 V) | | 2-phase | **2,8 kW** (2 x 6 A x 230 V) | **7,4 kW** (2 x 16 A x 230 V) | | 3-phase   | **4,1 kW** (3 x 6 A x 230 V)   | **11 kW** (3 x 16 A x 230 V) **22 kW** (3 x 32 A x 230 V) | Most wallboxes today are connected three-phase (11 kW or 22 kW). This means that the minimum charging power is 4.1 kW. For [wallboxes with automatic phase switching](/en/chargers#features) (1P/3P), evcc can switch between single-phase and three-phase as required and start charging at just 1.4 kW. The feed-in power is shown in the **energy flow diagram**. If the surplus is above the minimum charging power for a certain period of time, charging starts.  Energy flow diagram shows 3.4 kW feed-in. Note: The value on the grid meter is the decisive factor. **Solar mode** does not work for systems with regulated grid feed-in (“zero feed-in”). ### Not enough surplus? [Section titled “Not enough surplus?”](#not-enough-surplus) By default, the system tries to avoid drawing any power from the grid. You can adjust this behaviour under **Configuration → Charging points & Heaters → \[My Charging Point]**. In the **Behaviour** section, switch the **Solar** setting from **maximum solar** to **custom**. You can then set your own thresholds and delays. **Enable grid power** defines how much surplus must be available before charging starts. The value is negative because it refers to power exported to the grid, e.g. -2,000 W means 2,000 W of surplus. With the default value of 0 W, charging starts as soon as the minimum charging power is available as surplus. The **Enable delay** defines how long this surplus must be available continuously before charging starts, e.g. 1 minute. **Disable grid power** defines how much power may be drawn from the grid while charging before it stops. With 2,000 W, for example, charging continues as long as no more than 2,000 W is imported from the grid. With the default value of 0 W, charging stops as soon as the minimum charging power is no longer covered by surplus. The **Disable delay** defines how long this limit must be exceeded before charging stops, e.g. 30 minutes. This can be particularly useful for small solar systems or in the winter months, in order to at least partially cover your own charging needs with solar energy. The thresholds and delays should be selected so that charging is not switched on and off too often. Some vehicles refuse to charge if it is interrupted too often and must be made to charge again, for example by unlocking or plugging/unplugging the charging cable. ### Interaction with the home battery [Section titled “Interaction with the home battery”](#interaction-with-the-home-battery) Battery systems have their own, fast regulation. In the standard case, the home battery has priority. The **Solar mode** only starts charging the vehicle when it can no longer absorb any power. You can find out how to adjust this behavior under [Home battery](/en/features/battery). ## Min+Solar mode [Section titled “Min+Solar mode”](#minsolar-mode) The **Min+Solar mode** is a variation of the **Solar mode**.  Screenshot of a charging point. Cursor clicks on the Min+Solar mode. Here, charging begins immediately with minimal charging power - even if there is no or insufficient surplus. If surplus is available, the charging power is increased accordingly. In contrast to **Solar mode**, charging is not interrupted. This is primarily useful for vehicles that do not like regular starting and stopping of charging. Even in very changeable weather conditions, **Min+Solar mode** can be a good alternative to **Solar mode**. # Vehicles If you configure your vehicle or vehicles in evcc, additional functions are available to you. You can configure [Minimum Charge & Limits](/en/features/limits), use [Charge Planner](/en/features/plans) and get a detailed evaluation by vehicle in the [Charging Sessions](/en/features/sessions), including information such as mileage. Storing vehicles is optional. Since evcc controls the charging process via the wallbox in most cases, PV and price-dependent charging also works without vehicle configuration. ## Vehicle types [Section titled “Vehicle types”](#vehicle-types) The available functions depend on the vehicle type. The following types are distinguished: ### Guest vehicle [Section titled “Guest vehicle”](#guest-vehicle) If you have not configured a vehicle, the guest vehicle will be displayed at the charging point. This is a standard vehicle that does not support any special functions. Even if you have configured your own vehicle, you can switch to the guest vehicle at any time. This is useful, for example, if an unconfigured vehicle (e.g. a spontaneous visitor) charges at your wallbox. evcc then uses the standard values ​​for power and phases configured at the charging point. Under [Charging Sessions](/en/features/sessions), this charge is assigned to the guest vehicle. ### Vehicles without API (offline) [Section titled “Vehicles without API (offline)”](#vehicles-without-api-offline) If your vehicle does not have an online interface or no internet connection at the charging point, you can configure it as an offline vehicle. Go to **Configuration → Vehicles → Add vehicle** and choose **Generic vehicle (without API)** in the **Manufacturer** field. Give the vehicle a **Title** (e.g. “Green Honda e”) and enter the **Capacity** of its battery. Now that the battery capacity is known, the charging progress and the charging limit can also be shown in percent (e.g. +25%). Note: You can also use this function for third-party vehicles (friends, family, rental or company cars) to which you do not have API access. ### Vehicles with API (online) [Section titled “Vehicles with API (online)”](#vehicles-with-api-online) If your vehicle has an online interface, it makes sense to configure this in evcc as well. You can find a list of all supported manufacturers under [Vehicles](/en/vehicles). Go to **Configuration → Vehicles → Add vehicle** and choose your **Manufacturer**, e.g. Audi. Depending on the manufacturer, you then enter the access data of your vehicle account, such as user and password. evcc now has access to the current state of charge (SoC). Depending on the manufacturer, other information such as charging status, vehicle limits, mileage, climate control and estimated range are also available. Note To protect the vehicle battery, evcc only updates the charge level when a vehicle is connected to the charging point. Depending on the manufacturer, API access can wake up the vehicle and significantly increase standby consumption. You can change this behavior using the [`poll` parameter](/en/reference/configuration/loadpoints#poll) at the charging point. ## Multiple vehicles [Section titled “Multiple vehicles”](#multiple-vehicles) You can configure multiple vehicles and multiple charging points in evcc. There are various options for assigning vehicles to charging points: ### Standard vehicle [Section titled “Standard vehicle”](#standard-vehicle) If each vehicle has its own charging point, you can configure the vehicle as the standard vehicle at the charging point. This is the simplest and recommended configuration. Go to **Configuration → Charging points & Heaters → \[My Charging Point]**. In the **Vehicles** section, select your vehicle as **Default vehicle**. When a new charging process starts, evcc assumes that it is the standard vehicle. If this is not the case (e.g. guest vehicle), you can switch the vehicle in the UI. ### Assignment via the UI [Section titled “Assignment via the UI”](#assignment-via-the-ui) The currently assigned vehicle is displayed in the UI at the respective charging point. You can change the assignment by clicking on the vehicle name. This selection then applies to the current charging process.  Changing a vehicle at the charging point ### Automatic detection [Section titled “Automatic detection”](#automatic-detection) If several vehicles are charging at one charging point, automatic detection is used when plugging in. The charging status of all configured vehicles is checked and the most plausible vehicle is selected. If the detection has selected the wrong vehicle (e.g. because it is charging at a different charging point), you can correct the assignment manually. ### Detection via RFID [Section titled “Detection via RFID”](#detection-via-rfid) If your wallbox has an RFID card reader, you can also use this for the assignment. This involves assigning one (or more) RFID cards to a specific vehicle. Every time the vehicle is connected to the wallbox again, the charging process must first be activated with the corresponding RFID card on the wallbox. evcc receives a unique identification code from the wallbox. Depending on the manufacturer, this is either the RFID code or a derived internal code such as a user name from the wallbox configuration. After activating with the card, the current identifier is shown on the charging point card under **Configuration → Charging points & Heaters**. Enter this value in the **RFID identification** field of the desired vehicle under **Configuration → Vehicles**. You can store multiple identifiers per vehicle. ### Detection via Plug & Charge [Section titled “Detection via Plug & Charge”](#detection-via-plug--charge) If your wallbox supports the ISO 15118 standard, detection can also be carried out directly via the charging cable. However, there are currently very few wallboxes available on the market with this function. Note The “PLC connection to the vehicle” feature must be activated in the wallbox. The setup is similar to RFID detection. The vehicle must be connected to the wallbox. The identifier (e.g. `01:23:45:67:89:00`) is then shown on the charging point card under **Configuration → Charging points & Heaters**. Enter this value in the **RFID identification** field of the vehicle. Note If the vehicle and the wallbox do not support Plug & Charge, the vehicles return a unique hardware address (MAC address). However, some manufacturers such as VW and Audi change this to a different random value every day. In this case, you can use a wildcard and only specify the part that does not change, e.g. `01:23:45:*`. Of course, this only works if this does not occur in several existing vehicles and the specified initial part of the value is different in each case. ## Air conditioning [Section titled “Air conditioning”](#air-conditioning) For some vehicles, evcc can also detect via the online connection whether the vehicle is currently performing pre-air conditioning. In this case, the lowest possible power is released on the wallbox so that the vehicle can air condition using the power from the wallbox. It can happen that the air conditioning in the vehicle requires less than the released power. The vehicle then uses the remaining available power to continue charging the battery, even if a specified limit on the state of charge has already been reached. As soon as the air conditioning is recognized as finished, the wallbox is locked again so that the vehicle cannot draw any more power from the wallbox unless it is already charging. Note This only applies to the combination of vehicles and wallboxes that communicate via the IEC 61851 standard. This is the rule today. For vehicles and wallboxes that communicate via the ISO 15118 standard, the vehicle receives exactly the amount of energy that it requests directly from the wallbox. # Getting Started In this section you will find installation guides for evcc on various platforms. If you want to learn more about how wallboxes and EV charging work, first check out the [preliminary considerations](/en/installation/considerations). ### [Raspberry Pi & Co.](/en/installation/linux-image) [Easiest installation. Ready-made SD card image.](/en/installation/linux-image) ### [Docker](/en/installation/docker) [Synology, QNAP, Unraid and other NAS systems](/en/installation/docker) ### [Home Assistant](/en/installation/home-assistant) [As add-on via HACS.](/en/installation/home-assistant) ### [Proxmox](/en/installation/proxmox) [LXC container via helper script.](/en/installation/proxmox) ### [Linux](/en/installation/linux) [Debian/Ubuntu and other distributions.](/en/installation/linux) ### [macOS](/en/installation/macos) [Via Homebrew.](/en/installation/macos) ### [FreeBSD](/en/installation/freebsd) [Via pkg.](/en/installation/freebsd) ### [Windows](/en/installation/windows) [Manual installation. Not recommended but works.](/en/installation/windows) After installation: [Configure evcc](/en/installation/configuration) # Configuration After installing evcc, you can configure your devices and settings. The recommended way is configuration through the web interface. File-based configuration is also available for advanced users. ## via Web Interface [Section titled “via Web Interface”](#via-web-interface) Recommended The web interface is the easiest and fastest way to set up evcc. ### Getting Started [Section titled “Getting Started”](#getting-started) 1. **Start evcc**: After [installation](/en/installation), start evcc according to the instructions for your system 2. **Open browser**: Go to `http://:7070` (e.g., `http://evcc.local:7070` or `http://192.168.1.50:7070`) 3. **Set administrator password**: On first start, you’ll be prompted to set a password 4. **Setup**: Follow the instructions on the welcome page ### Adding Devices [Section titled “Adding Devices”](#adding-devices) In the configuration area, you can set up the following components: * **Charging points & Heaters** (recommended): Wallboxes and heat pumps * **Grid** (recommended): Grid connection meter and electricity tariffs – important for proper energy management * **Solar & Battery** (optional): Solar systems and battery storage * **Vehicles** (optional): Vehicle integrations for battery capacity and state of charge, enables smarter charging At least one meter or charging point must be configured for the system to run. ### Integrations [Section titled “Integrations”](#integrations) Additionally, you can integrate various services and protocols: * **MQTT**: Data exchange with other systems on the network * **[Notifications](/en/notifications)**: Push notifications and email alerts * **InfluxDB**: Data export for long-term analysis * **EEBus**: Communication with other EEBus devices * **OCPP Server**: Connection with OCPP-capable wallboxes * **Circuits**: Circuit monitoring and control * **Modbus Proxy**: Multiple access to Modbus devices * **Sunny Home Manager**: Integration via SEMP protocol * **External Limit**: Power limitation by grid operators (§ 14a EnWG, § 9 EEG) or higher-level energy management systems []() ### Backup & Restore [Section titled “Backup & Restore”](#backup--restore) The web interface offers integrated data backup functions: * **Backup**: Download database for data backup * **Restore**: Restore data from a backup file * **Reset**: Delete configuration or charging history ## via Configuration File [Section titled “via Configuration File”](#via-configuration-file) Traditional Method This method uses an `evcc.yaml` file and requires knowledge of command line and YAML files. Some new features are only configurable via the web interface. ### From Scratch [Section titled “From Scratch”](#from-scratch) You can also create the `evcc.yaml` file manually. Here you’ll find a minimal template that you can use as a starting point. #### Creation [Section titled “Creation”](#creation) Copy the content into a new `evcc.yaml` file. evcc.yaml ```yaml ## minimal configuration example site: title: Home # display name for UI meters: grid: my_grid pv: - my_pv battery: - my_battery # see https://docs.evcc.io/en/docs/reference/configuration/loadpoints loadpoints: - title: Garage # display name for UI charger: my_charger # charger vehicle: my_car # default vehicle # meter definitions # name can be freely chosen and is used as reference when assigning meters to site and loadpoints # for documentation see https://docs.evcc.io/docs/meters meters: # replace with your real grid meter - name: my_grid type: template template: demo-meter usage: grid power: -1000 # 1 kW feed-in # replace with your real solar system - name: my_pv type: template template: demo-meter usage: pv power: 4000 # 4 kW production # replace with your real battery - name: my_battery type: template template: demo-battery usage: battery power: -1000 # 1 kW battery charging soc: 50 # 50 % state of charge # replace with your real charger # see https://docs.evcc.io/docs/chargers chargers: - name: my_charger type: template template: demo-charger status: C # charging power: 2000 # 2 kW charging power enabled: true # optional # replace with your real vehicle (optional) # see https://docs.evcc.io/docs/vehicles vehicles: - name: my_car type: template template: offline title: blue e-Golf capacity: 50 # in kWh # enter your real grid tariff and feed-in price # see https://docs.evcc.io/docs/tariffs tariffs: currency: EUR grid: type: fixed price: 0.29 # EUR/kWh feedin: type: fixed price: 0.10 # EUR/kWh ``` You can start evcc with this file. Use the respective instructions for your system. #### Testing [Section titled “Testing”](#testing) Restart evcc and open your browser at `http://:7070`. Check if the values are plausible. If you receive an error message, check your entries. Often these are indentation or typing errors. The file is written in [YAML format](https://wikipedia.org/wiki/YAML). You can use the online tool [YAML Lint](https://www.yamllint.com/) to check if your file follows the correct format. #### Customizing [Section titled “Customizing”](#customizing) The file only contains demo devices (`demo-charger`, `demo-meter`, `demo-battery`, `offline`). These have fixed values. Go through the file step by step and adjust the values to your setup: * Replace the demo devices with your own [meters](/en/meters), [wallboxes](/en/chargers), and [vehicles](/en/vehicles). * If you don’t have a battery, you can remove that section completely. * If you have multiple solar systems, you can duplicate the corresponding sections. * If you have multiple wallboxes, copy the loadpoint and charger sections and adjust the names. Note that the individual entries reference each other. In the `site` entry (`meters`), the meters (`grid`, `pv`, `battery`) are assigned to their roles. The `name` field is always used for this. Names must therefore be unique. Make these changes step by step if possible. Restart evcc after each change and check the output in the browser. This way you’ll quickly notice if you’ve made a mistake. #### Further Information [Section titled “Further Information”](#further-information) The [evcc.dist.yaml](https://github.com/evcc-io/evcc/blob/master/evcc.dist.yaml) in the main project contains a complete list of all possible configuration options. More detailed explanations of the options can be found under [Reference → evcc.yaml](/en/reference/configuration). If you want to see a dynamic demo, you can also look at the contents of the [demo.yaml](https://github.com/evcc-io/evcc/blob/master/cmd/demo.yaml) file. This file contains JavaScript-based demo devices that simulate limited functionality. It is also used for [demo.evcc.io](https://demo.evcc.io). To run your own installation in demo mode, just start evcc with the parameter `--demo`. See [CLI Reference](/en/reference/cli/evcc) for more information. ## Testing [Section titled “Testing”](#testing-1) Test if the configuration works: ```sh evcc -c evcc.yaml ``` Open a browser and enter the URL: `http://:7070` (e.g., `http://evcc.local:7070`). The evcc interface should now show your own devices. If everything works, you can move your `evcc.yaml` to the location required for your installation. ## Troubleshooting [Section titled “Troubleshooting”](#troubleshooting) If errors occur, you can get additional information using the following commands. * Syntax check ```sh evcc -c evcc.yaml checkconfig ``` * Meters (Grid, Solar, Battery) ```sh evcc -c evcc.yaml -l debug meter ``` * Vehicles ```sh evcc -c evcc.yaml -l debug vehicle ``` * Wallboxes ```sh evcc -c evcc.yaml -l debug charger ``` Check the output of each command for plausibility. # Preliminary Considerations Are you technically proficient and know which hardware to install evcc on and which EV charger, solar system, and possibly battery to integrate? Then skip this page and go directly to the installation. If charging with solar power is new to you, you’ll find some information below on how to get started with evcc. ## Initial Situation [Section titled “Initial Situation”](#initial-situation) Is evcc the right solution for surplus charging for me? I have a solar system and an electric car and want to try it out. Where do I start? A solar system is particularly economical when I also consume the self-generated electricity. For this, the electricity must be consumed exactly when it is produced, i.e., when the sun is shining. The simplest solution: I always connect the car for charging when the sun is shining and there are no clouds in sight. Unfortunately, we have clouds or we’re currently using the solar system’s electricity for the washing machine. We therefore need to automate the charging control - and that’s exactly what evcc does. For automation, we need to know the current electricity surplus, i.e., how much electricity we don’t consume ourselves and therefore feed into the power grid. We get this information from the electricity meter. This can be the electricity meter of the metering point operator (e.g., your energy provider) or an additional meter that was installed with the solar system. The latter is usually the case when the solar system is equipped with a storage battery. The meter must be electronically readable. Just check under [Devices > PV, Battery, Grid, Meters](/en/meters) to see if you can find your devices. If not, you can also integrate them yourself as [user-defined devices](/en/user-defined-devices). Another prerequisite for automating surplus charging is a controllable charger. The supported devices are listed under [Devices > Chargers](/en/chargers). If I don’t (yet) have a charger, a switchable socket with consumption measurement is recommended for testing, e.g., a TP-Link Tapo P110, which is available for under 20 EUR. It can later be used to switch the charger for e-scooters or e-bikes. For the electric car, this is not a permanent solution since, on the one hand, the charging power cannot be regulated, i.e., adjusted to the current electricity yield of the solar system and self-consumption. On the other hand, there is no communication with the electric car, so switching occurs under full load, which means the switchable socket will not survive in the long term. With chargers, they communicate with the car, so that before the EV charger switches off, the car has already stopped charging. ## Hardware for evcc Installation [Section titled “Hardware for evcc Installation”](#hardware-for-evcc-installation) evcc is open-source software developed by volunteers. So there is no guarantee of functionality. But you also don’t pay a purchase price. That open-source software can work excellently can be seen, for example, with Linux, which has been developed according to this model for many years. However, this requires an active community. For example, it answers [beginners’ questions](https://github.com/evcc-io/evcc/discussions/categories/erste-hilfe) or develops the software further. If you can’t contribute to this, you can support the project through [Sponsorship](/en/sponsorship). Sponsorship is necessary for some commercial chargers. If I just want to try evcc first, I don’t need to buy a Raspberry Pi, but can start with an old, discarded PC or laptop. All devices from the last 10 years with an Intel-compatible 64-bit CPU and a network card (or WLAN) should work here. In the long term, the higher power consumption and the larger space requirements speak against a PC or laptop. Furthermore, there can be problems with laptops due to the power-saving mode. Alternatives to installation on a Raspberry Pi would be devices already present in the home network. This could be, for example, a network storage (NAS) or an existing system like Home Assistant. The installation is more demanding here, as evcc then has to run on a virtual machine or as a container. To ensure high stability, we recommend connecting both evcc and the devices used (charger, solar system, battery, etc.) with a network cable wherever possible. Before starting the installation of evcc under Debian or Ubuntu according to the [instructions](/en/installation/linux), all required IP addresses of meters, solar systems, storage systems, and chargers should be available. The IP addresses of all devices are usually listed in the web interface of the DSL or cable routers (e.g., Fritz!Box). It is helpful to assign these addresses permanently so that they do not change over a long period of time. ## EV Chargers [Section titled “EV Chargers”](#ev-chargers) Chargers come in different variants. The following describes the typical properties and functions of chargers. This should make the decision for or against a charger somewhat easier. ### Charging Power [Section titled “Charging Power”](#charging-power) A first decision concerns the maximum charging power of the charger. Common are mainly the 11 kW and 22 kW chargers. The 11 kW variant should be the most frequently chosen variant. This has two main reasons: on the one hand, many vehicles can charge at a maximum of 11 kW AC, and on the other hand, 11 kW chargers can be put into operation with a simple registration (notification) to the grid operator. The 22 kW chargers require approval from the provider. This may only be granted under certain conditions. For example, the provider may require that the charging can be switched off by a control signal in the event of an energy shortage. This can drive up the installation costs. If the house connection with a 22 kW charger exceeds a connection power of 30 kW, the provider can charge a grid expansion contribution for the connection power exceeding 30 kW. The maximum charging power or the maximum current can be configured in the chargers via switches. The installer must set this correctly according to the approved maximum power (distribution network operator) the installation (circuit breaker, residual current protection, cable cross-section, cable length, etc.). Errors here can quickly lead to failures or fires. In the event of damage, the insurance company will ask for the installation protocol or the invoice for the installer approved by the provider. ### Communication Interface [Section titled “Communication Interface”](#communication-interface) evcc requires a way to communicate with the charger. Almost all modern chargers have something like this. Under [Devices > Chargers](/en/chargers) you will find a list of currently supported chargers. Ethernet, WLAN, LTE, or serial via RS485 bus (e.g., Modbus RTU interface) are possible as physical interfaces. Often several interfaces are present simultaneously. A suitable protocol between the charger and evcc is required to control the charging process. An open standard that has now become established worldwide is [OCPP (Open Charge Point Protocol)](https://en.wikipedia.org/wiki/OCPP). In addition to the communication between the charger and evcc, the communication of the charger with the vehicle is relevant. In the simplest case, the charger can only signal the charging current between 6A and 32A. Depending on whether the charger was connected to the power grid with one or three phases, the vehicle then charges with at least 1.38 kW or 4.14 kW. Under [Features > Solar Surplus Charging](/en/features/solar-charging) you will find more information. To be able to charge both low solar power surpluses and larger surpluses, automatic 1p/3p switching is recommended. Chargers that support this function are noted accordingly in the [listing](/en/chargers). If the charger does not support automatic switching, in the winter months, with a pre-connected load disconnector (e.g., Hager HAB304), phases 2 and 3 could possibly be switched off manually. With the above minimal communication between the charger and the vehicle, it is not possible for the charger to identify the connected vehicle or to query the current state of charge (SoC). To get this information, evcc takes the route via interfaces (APIs) of the vehicle manufacturer. The scope of the information provided there is different and can include, for example, the air conditioning or the position of the vehicle. The use of these APIs is sometimes subject to a fee from the manufacturer. Some chargers already implement the relatively new [ISO 15118](https://en.wikipedia.org/wiki/ISO_15118) protocol (hardware and software extensions necessary), which is used for “Plug & Charge” and “Autocharge” at public fast charging stations. With this, it is possible, for example, to determine the identity of the connected vehicle and the SoC and to specify the charging power for each phase individually. The prerequisite is that the vehicle also correctly supports the respective function. It is not to be expected that older vehicles will still be retrofitted with support for ISO 15118. The same applies to chargers. If the hardware for communication according to ISO 15118 is not installed, there is no hope. ### Company Cars & Commercial Use [Section titled “Company Cars & Commercial Use”](#company-cars--commercial-use) Especially for company car drivers and private individuals who want to provide proof of travel costs to the tax office, a calibrated meter is interesting. Some manufacturers therefore also offer their charger in a variant with a calibrated electricity meter. This allows the amount of energy charged to be documented for each charging process. The meter is also of interest apart from the tax office, as it can be used to determine the charging losses exactly. Chargers often work most efficiently at maximum charging power. With low charging currents, on the other hand, increased charging losses often occur. While this plays only a subordinate role in pure surplus charging, it is a relevant cost factor when charging with grid power. # Docker evcc can be installed as a Docker image. Currently, we provide Docker images for AMD64, armv6 and arm64. Common use cases include NAS systems like Synology, QNAP, Unraid and TrueNAS. Caution This guide assumes basic experience with Docker. If you haven’t worked with Docker before, we recommend a direct installation as described in the [Linux](/en/installation/linux) or [macOS](/en/installation/macos) guide. If your devices are not accessible via network (e.g. RS485 adapters) you should also choose the direct installation. There are technical solutions to implement this with Docker. However, these are not covered here. ## Preparation [Section titled “Preparation”](#preparation) ### Configuration [Section titled “Configuration”](#configuration) evcc can be configured in two ways: 1. **Web interface** (recommended): Start the container without `evcc.yaml`. After starting, configure evcc directly in the browser. The configuration is automatically saved in the database. 2. **Configuration file** (traditional method): Create an `evcc.yaml` file with your settings. Instructions can be found under [Configuration](/en/installation/configuration). ### Volumes [Section titled “Volumes”](#volumes) The evcc Docker container needs at least one volume: * `/root/.evcc/` directory for the internal SQLite database (required). The database is automatically stored in this directory. * `/etc/evcc.yaml` for the configuration file (optional - only for file-based configuration) Create the database directory on your host system. In this guide we use the path `/home/user/.evcc/` as an example. If you’re using file-based configuration, also use `/home/user/evcc.yaml` ## Installation [Section titled “Installation”](#installation) This section describes three ways to install evcc using Docker: Via Docker UI, Docker CLI, and Docker Compose. ### via a Docker UI [Section titled “via a Docker UI”](#via-a-docker-ui) If you have a system with a Docker UI (e.g. Synology, QNAP, Portainer, Unraid, …), you can also perform the installation through this interface. Here are the relevant details you need to enter: #### Available Docker Images [Section titled “Available Docker Images”](#available-docker-images) * `evcc/evcc:latest` (recommended) * `evcc/evcc:nightly` (development build) #### Volume Mounts [Section titled “Volume Mounts”](#volume-mounts) | Host Path | Container Path | Description | Required | | ---------------------- | ---------------- | ------------------------------------------------------ | -------- | | `/home/user/evcc.yaml` | `/etc/evcc.yaml` | Configuration file (only for file-based configuration) | no | | `/home/user/.evcc/` | `/root/.evcc` | Directory for internal database | yes | #### Ports [Section titled “Ports”](#ports) | Host Port | Container Port | Description | Required | | --------- | -------------- | ---------------------- | -------- | | 7070 | 7070/tcp | Web UI, API | Yes | | 8887 | 8887/tcp | OCPP Server | No | | 9522 | 9522/udp | SMA Sunny Home Manager | No | | 7090 | 7090/udp | KEBA Chargers | No | | 5353 | 5353/udp | mDNS | No | | 4712 | 4712/tcp | EEBus | No | | 8899 | 8899/udp | Modbus UDP | No | Open your system’s Docker UI and create a new container with the above settings and start it. The exact field labels vary from system to system. However, you’ll find the concepts of ports and volumes in all systems. Skip to the [Testing](#test) section to verify the installation. #### Updates [Section titled “Updates”](#updates) The update process depends on your specific Docker UI. Please refer to your system’s documentation for this. Note If after an update your charging sessions are no longer displayed, the `/root/.evcc` directory is not mounted correctly. ### via Docker CLI [Section titled “via Docker CLI”](#via-docker-cli) Install and start the Docker container using one of the following commands. Whether you need `sudo` depends on your system. * Standard ```sh sudo docker run -d --name evcc \ -v /home/user/evcc.yaml:/etc/evcc.yaml \ # optional -v /home/user/.evcc:/root/.evcc \ -p 7070:7070 \ -p 8887:8887 \ evcc/evcc:latest ``` * SMA Devices and EEBus ```sh sudo docker run -d --name evcc \ -v /home/user/evcc.yaml:/etc/evcc.yaml \ -v /home/user/.evcc:/root/.evcc \ -p 7070:7070 \ -p 8887:8887 \ -p 9522:9522/udp \ -p 5353:5353/udp \ -p 4712:4712 \ --network host \ -v /etc/machine-id:/etc/machine-id \ # highlight-end evcc/evcc:latest ``` Set the network mode to `host`. The SMA Sunny Home Manager requires a unique device ID. On Linux, you can mount `machine-id` into the container. Alternatively, you can specify an ID in the `plant` parameter in `evcc.yaml`. *** NOTE The above example only uses basic ports. Please refer to the [Ports](#ports) section and add additional ports as needed. ### via Docker Compose [Section titled “via Docker Compose”](#via-docker-compose) [docker-compose](https://docs.docker.com/compose) has several advantages over direct command line execution. All parameters are stored in a file. Additionally, you can configure and start other programs like Traefik in conjunction with evcc. Simply create a configuration file named `compose.yml` in your active directory. Copy one of the following configurations matching your component setup into `compose.yml` and save it: * Standard ```yaml services: evcc: command: - evcc container_name: evcc image: evcc/evcc:latest ports: - 7070:7070/tcp - 8887:8887/tcp volumes: - /home/user/.evcc:/root/.evcc - /home/user/evcc.yaml:/etc/evcc.yaml # optional restart: unless-stopped # optional: #user: : ``` * SMA Devices and EEBus ```yaml services: evcc: command: - evcc container_name: evcc image: evcc/evcc:latest ports: - 7070:7070/tcp - 8887:8887/tcp - 9522:9522/udp - 5353:5353/udp - 4712:4712/tcp volumes: - /home/user/evcc.yaml:/etc/evcc.yaml - /home/user/.evcc:/root/.evcc - /etc/machine-id:/etc/machine-id - /var/lib/dbus/machine-id:/var/lib/dbus/machine-id network_mode: host restart: unless-stopped # optional: #user: : ``` NOTE The above example only uses basic ports. Please refer to the [Ports](#ports) section and add additional ports as needed. Start the container with: ```sh sudo docker compose up -d ``` #### Updates [Section titled “Updates”](#updates-1) Navigate to the directory containing the evcc `compose.yml` file. Update to the latest evcc image: ```sh sudo docker compose pull ``` If a new image is available, the following command will restart the container - otherwise, the existing one will continue running: ```sh sudo docker compose up -d ``` []() ## Testing [Section titled “Testing”](#testing) After successfully creating and starting your container, you can access the evcc Web UI at `http://:7070`. `` is the IP address or hostname of the computer running the container. **On first use:** * You will be prompted to set an administration password * You can then configure your devices via the web interface (for UI configuration) * Or see your configured devices directly (for file-based configuration) If you cannot establish a connection, check your container logs. If you see the interface but an error message is displayed, check: * For file-based configuration: the settings in your `evcc.yaml` file * For UI configuration: the device settings on the configuration page You can find more details in [Configuration](/en/installation/configuration) or in the [GitHub Discussions](https://github.com/evcc-io/evcc/discussions). ## Community Guides [Section titled “Community Guides”](#community-guides) Here you’ll find user-created guides for specific systems. We cannot guarantee their accuracy or currentness. Contributions welcome Updates or guides for additional systems are always welcome. Whether as PDF, personal blog article, or YouTube video. Feel free to create a pull request in the [Documentation Repository](https://github.com/evcc-io/docs/pulls). ### Synology NAS [Section titled “Synology NAS”](#synology-nas) You can install evcc via Docker on Synology NAS systems using its graphical interface, without using the command line. You’ll be given the choice of two network modes: bridge, or host. Whether the Bridge mode can be used depends on what components you’re using, and how they communicate with your equipment. In case of doubt, use host mode. Further information can be found in this instruction: [Anleitung: Synology Docker (PDF / DE)](https://github.com/evcc-io/docs/files/10365841/Anleitung.EVCC.Synology.Docker.Elli.Charger.Connect-Pro.pdf) More information on Bridge Mode can be found here: [Anleitung: Synology Docker 2 (PDF / DE)](https://github.com/evcc-io/docs/files/10365845/EVCC_Synology_Docker-2.pdf) by [at4hawo1](https://github.com/at4hawo1) ### QNAP NAS [Section titled “QNAP NAS”](#qnap-nas) Installing evcc on QNAP systems via Docker is very similar to the above Synology instructions. Further QNAP specific instructions can be found here: [Anleitung: QNAP (PDF / DE)](https://github.com/evcc-io/docs/files/11241693/EVCC_auf_QNAP_Container_Station.pdf) # FreeBSD This guide describes the installation on FreeBSD using the official [package from the FreeBSD Ports tree](https://cgit.freebsd.org/ports/tree/www/evcc). ## Installation [Section titled “Installation”](#installation) 1. ### Install [Section titled “Install”](#install) Open a terminal as root and install evcc: ```sh pkg install evcc ``` 2. ### Start [Section titled “Start”](#start) Enable the service at boot and start it: ```sh sysrc evcc_enable="YES" service evcc start ``` 3. ### Set Up [Section titled “Set Up”](#set-up) Open the evcc interface in your browser: . Set an administrator password and configure your devices directly via the web interface. ## Configuration [Section titled “Configuration”](#configuration) Recommended Configure evcc directly in your browser. After the first start, you can configure your evcc instance at . Settings are automatically saved in the database. Alternatively, you can use an `evcc.yaml` configuration file at `/usr/local/etc/evcc.yaml`. Details can be found in [Configuration](/en/installation/configuration). ## Upgrades [Section titled “Upgrades”](#upgrades) To upgrade to a new version, perform the following steps: * Check the [releases](https://github.com/evcc-io/evcc/releases) for breaking changes (BC) affecting your installation * Open a terminal as root * Upgrade evcc: ```sh pkg upgrade evcc ``` * Restart the service: ```sh service evcc restart ``` ## Additional Commands [Section titled “Additional Commands”](#additional-commands) * Check the status of the evcc server: ```sh service evcc status ``` * View logs: ```sh tail -f /var/log/evcc.log ``` ## nginx as Reverse Proxy [Section titled “nginx as Reverse Proxy”](#nginx-as-reverse-proxy) If you already have nginx running, add a new virtualhost with the following configuration: ```nginx server { ... server_name evcc. ... location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $http_host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_redirect off; proxy_read_timeout 240s; proxy_http_version 1.1; proxy_pass http://127.0.0.1:7070; } } ``` The evcc interface will then be available at `http://evcc./`. # Home Assistant Note The evcc Home Assistant addon is a community integration and is not officially supported by the evcc maintainers. The reason for this is that important data cannot simply be made available in the event of an error (missing `evcc cli`). Datamigration Please note that since February 16, 2025, with version 0.200.1, we have changed the paths in the addon to be consistent with the [guidelines](https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/) of Home Assistant. From now on, the following paths are mapped in the addon: * `/homeassistant/` -> points to `/homeassistant/` or `/config/` in Home Assistant. * `/config/` -> points to `/addon_configs/49686a9f_evcc/` in Home Assistant. If you are updating from an older version, your configuration file will be automatically copied to the new directory. We will only copy the database if it was also located in `/config/`. If you had it in `/data/`, it will remain there. We will append `.migrated` to the old files. These can then be manually deleted by you. This guide describes the installation of evcc as a Home Assistant addon. Unlike the [Linux installation](/en/installation/linux) or [Docker installation](/en/installation/docker), you don’t need command line knowledge here. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) You need a Home Assistant installation with the Addon Store enabled. Depending on your installation type, this feature might not be available. See [Home Assistant Documentation](https://www.home-assistant.io/installation/#advanced-installation-methods) for more information. ## Installation [Section titled “Installation”](#installation) * Release The current stable version. 1. Automatically add repository: Click on the following button and then on **Open link**, then on **Add**. [](https://my.home-assistant.io/redirect/supervisor_add_addon_repository/?repository_url=https%3A%2F%2Fgithub.com%2Fevcc-io%2Fhassio-addon) 2. Manually add repository: 1. Click on **Settings** → **Addons** → **Add-on Store** 2. Click on the **three dots** → **Repositories** 3. Add the repository URL and click **Add** ```plaintext https://github.com/evcc-io/hassio-addon ``` 3. Reload the webpage 4. Find the **evcc** addon and click on it 5. Click on the **INSTALL** button * Nightly The current developer version. Updated daily. May be unstable. Although it can be installed alongside the release version, only one version can run at a time. If you use the nightly version, the paths and Docker container names mentioned in this guide will change, i.e., instead of `evcc`, you must use `evcc-nightly`. 1. Automatically add repository: Click on the following button and then on **Open link**, then on **Add**. [](https://my.home-assistant.io/redirect/supervisor_add_addon_repository/?repository_url=https%3A%2F%2Fgithub.com%2Fevcc-io%2Fhassio-addon) 2. Manually add repository: 1. Click on **Settings** → **Addons** → **Add-on Store** 2. Click on the **three dots** → **Repositories** 3. Add the repository URL and click **Add** ```plaintext https://github.com/evcc-io/hassio-addon ``` 3. Reload the webpage 4. Find the **evcc (nightly)** addon and click on it 5. Click on the **INSTALL** button ## Configuration [Section titled “Configuration”](#configuration) evcc can be configured in two ways: ### Web Interface (recommended) [Section titled “Web Interface (recommended)”](#web-interface-recommended) Go to the **Information** tab in the **evcc** addon and activate **Show in sidebar** (evcc UI ) Go to the **Configuration** tab and select your working directory (example):  ```sh - sqlite_file: /data/evcc.db ``` Leave the Network section unchanged. Start the addon. Then open the evcc interface via the sidebar: * You’ll be prompted to set an administrator password * You can then configure your devices directly via the web interface * Settings are automatically saved in the database ### Configuration File (traditional) [Section titled “Configuration File (traditional)”](#configuration-file-traditional) Alternatively, you can use an `evcc.yaml` configuration file. Go to the **Configuration** tab and add the configuration file to your working directory: ```sh - config_file: /config/evcc.yaml - sqlite_file: /data/evcc.db ``` Create an evcc configuration file `evcc.yaml` in your addon root configuration folder (`/addon_configs/49686a9f_evcc`). If this folder does not exist, create it manually. To create or edit the configuration file, you have several options: * [Visual Studio Code](https://github.com/hassio-addons/addon-vscode): Select the hamburger menu in the top left and choose “File”, “Open Folder…”, select `/addon_configs/49686a9f_evcc` * [File Editor](https://github.com/home-assistant/addons/tree/master/configurator): Make sure you have disabled the “Enforce Basepath” option in the addon configuration, restart the addon and navigate to `/addon_configs/49686a9f_evcc` * [Advanced SSH & Web Terminal](https://github.com/hassio-addons/addon-ssh): Navigate to `/addon_configs/49686a9f_evcc` and use e.g. nano See [Configuration](/en/installation/configuration) for details on creating the configuration file. If you want to see the system running in demo mode, just start evcc with the parameter `--demo`. See [CLI Reference](/en/reference/cli/evcc) for more information. ## Updates [Section titled “Updates”](#updates) The update to the latest version of evcc is integrated into the Home Assistant update process. ## Advanced Tips [Section titled “Advanced Tips”](#advanced-tips) To perform the following functions, you need SSH access to Home Assistant. You can get this, for example, with the above-mentioned SSH Addon. * Install [Advanced SSH & Web Terminal](https://github.com/hassio-addons/addon-ssh) * Disable the “secure mode” in the Addon configuration * Restart the Addon * Open the Addon user interface ### How do I access the evcc database? [Section titled “How do I access the evcc database?”](#how-do-i-access-the-evcc-database) Show the files in `/data`: ```sh docker exec addon_49686a9f_evcc ls -la /data ``` Copy the `evcc.db` to `/addon_configs/49686a9f_evcc`: ```sh docker cp addon_49686a9f_evcc:/data/evcc.db /addon_configs/49686a9f_evcc/ ``` ### How can I use the evcc CLI? [Section titled “How can I use the evcc CLI?”](#how-can-i-use-the-evcc-cli) Open a shell to the evcc Docker container: ```sh docker exec -it addon_49686a9f_evcc /bin/sh ``` Run evcc CLI commands (here as an example `checkconfig`): ```sh evcc -c /config/evcc.yaml checkconfig ``` Close the shell in the evcc Docker container if you are done: ```sh exit ``` ### How can I use my external adapter / HAT in the Home Assistant evcc addon (Home Assistant OS, Raspberry Pi)? [Section titled “How can I use my external adapter / HAT in the Home Assistant evcc addon (Home Assistant OS, Raspberry Pi)?”](#how-can-i-use-my-external-adapter--hat-in-the-home-assistant-evcc-addon-home-assistant-os-raspberry-pi) If your Home Assistant device is close to your meter (solar, battery, grid, …) you can also retrieve the data directly via Modbus (e.g. USB). To do this, you need to enable external devices for Home Assistant, which also includes the evcc addon. To do this, uncomment the line `uart = 1` in the `config.txt` file on the Home Assistant OS boot partition. /config.txt ```ini uart = 1 ``` After a restart, your device should be available to the evcc addon (probably as `/dev/ttyS0` or `/dev/ttyUSB`) ## Next Step: Integration [Section titled “Next Step: Integration”](#next-step-integration) Once your system is running, you can set up the integration between evcc and Home Assistant. Under [Integrations → Home Assistant](/en/smarthome/home-assistant) you’ll find more information. You can visualize evcc data in Home Assistant or create automations based on evcc. # Linux This guide describes installation for apt-based Linux distributions like Debian and Ubuntu. Raspberry Pi For Raspberry Pi, we recommend the easier installation with [evcc Linux Image](/en/installation/linux-image). Note For other Linux distributions, see the [Docker](/en/installation/docker) guide or [Manual Installation](#manual) section. ## First Installation [Section titled “First Installation”](#first-installation) 1. ### Install [Section titled “Install”](#install) Open a terminal and install the required dependencies: ```sh sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl ``` Add the evcc APT repository: * Release Current stable release ```sh curl -1sLf 'https://dl.evcc.io/public/evcc/stable/setup.deb.sh' | sudo -E bash ``` * Nightly Development release. Updated daily. May be unstable. ```sh curl -1sLf 'https://dl.evcc.io/public/evcc/unstable/setup.deb.sh' | sudo -E bash ``` Update the package list and install evcc: ```sh sudo apt update sudo apt install -y evcc ``` Note During installation, a user `evcc` is created, so ensure the logged-in user does not have the name `evcc`. Note If a serial interface is used, you may need to run `sudo usermod -a -G plugdev evcc`. This adds the user `evcc` to the `plugdev` group, granting access to plug-in devices (USB, serial interface, etc.) without root privileges. 2. ### Start [Section titled “Start”](#start) ```sh sudo systemctl start evcc ``` 3. ### Set up [Section titled “Set up”](#set-up) Open the evcc web interface in your browser: . Set an administrator password and configure your devices directly via the web interface. [](https://cloudsmith.com) Thanks to [Cloudsmith](https://cloudsmith.com) for hosting the repository! ## Configuration [Section titled “Configuration”](#configuration) evcc can be configured via the web interface or a configuration file. Recommended Configuration via the web interface is the easiest way to set up evcc. ### Web Interface (recommended) [Section titled “Web Interface (recommended)”](#web-interface-recommended) After first start, you can configure evcc directly in the browser at . The settings are automatically saved in the database. ### Configuration File (traditional) [Section titled “Configuration File (traditional)”](#configuration-file-traditional) Alternatively, you can use an `evcc.yaml` configuration file. See [Configuration](/en/installation/configuration) for details on creating the configuration file. Caution The configuration file must be placed at `/etc/evcc.yaml`. * Create the configuration file according to the [guide](/en/installation/configuration) and save it at `/etc/evcc.yaml` * Restart the evcc server: ```sh sudo systemctl restart evcc ``` * Access the evcc interface at ## Upgrades [Section titled “Upgrades”](#upgrades) To update to the latest version of evcc, follow this guide: * Check the [releases](https://github.com/evcc-io/evcc/releases) for breaking changes (BC) for your installation * Open a terminal * Update the package list: ```sh sudo apt update ``` * Upgrade evcc: ```sh sudo apt --only-upgrade install -y evcc ``` Note If the unstable repository (nightly versions) has been added, updates will always install the latest available nightly version. If this is no longer desired, the unstable repository can be removed using `sudo rm /etc/apt/sources.list.d/evcc-unstable.list`. ## Downgrade [Section titled “Downgrade”](#downgrade) If you need to go backwards for any reason, you can do so with this command: ```sh sudo apt install evcc=x.xxx.x # Version Number ``` []() ## System Service [Section titled “System Service”](#system-service) evcc runs as a background system service. Here’s some useful commands to control it: ```sh sudo systemctl status evcc # shows status sudo systemctl start evcc # start the service, if it isn't already running sudo systemctl stop evcc # stops the service sudo systemctl restart evcc # restart the service sudo systemctl enable evcc # sets the service to run at boot sudo systemctl disable evcc # stops the service running at boot ``` ## Testing [Section titled “Testing”](#testing) Check the installation * Show the running evcc service: ```sh sudo systemctl status evcc ``` * Check the latest log entries of the evcc service: ```sh sudo journalctl -u evcc --since "yesterday" ``` * Validate the meter configuration: ```sh sudo evcc -l debug meter ``` * Validate the charger configuration: ```sh sudo evcc -l debug charger ``` * Validate the vehicle configuration: ```sh sudo evcc -l debug vehicle ``` Open a browser and enter the following URL: `http://127.0.0.1:7070`. Note Replace `127.0.0.1` with the IP address or hostname of the computer if the browser is not opened on the same computer. ## Backup and Restore [Section titled “Backup and Restore”](#backup-and-restore) ### Via Web Interface (recommended) [Section titled “Via Web Interface (recommended)”](#via-web-interface-recommended) The easiest method is to backup via the web interface. See [Configuration → Backup & Restore](/en/installation/configuration#backup) for details. ### Manual Backup [Section titled “Manual Backup”](#manual-backup) To restore the “original state” after a reinstallation, it is sufficient to back up the configuration file `evcc.yaml` (if used) and the database file `evcc.db`. The storage location is specified in the log file at program start. Typically, the configuration is located under `/etc/evcc.yaml` and the database under `/var/lib/evcc/evcc.db`. Both files can be copied using the Linux command `cp`. Example (copying from the usual storage location to the home directory): Copy yaml: `sudo cp /etc/evcc.yaml /home/pi/evcc.yaml.bak` Copy db: `sudo cp /var/lib/evcc/evcc.db /home/pi/evcc.db.bak` ## Environment Variables & CLI Options [Section titled “Environment Variables & CLI Options”](#environment-variables--cli-options) When installed via APT, evcc runs as a systemd service. You can customize the behavior using an override file: ```sh sudo systemctl edit evcc ``` Caution Don’t edit `/lib/systemd/system/evcc.service` directly. That file is overwritten by `apt` on every package update and your changes will be lost. Always use a systemd drop-in via `systemctl edit evcc` instead. ### Example [Section titled “Example”](#example) /etc/systemd/system/evcc.service.d/override.conf ```ini [Service] Environment="EVCC_LOG=debug,tariff:trace" Environment="EVCC_DATABASE_DSN=/usb/evcc/evcc.db" Environment="EVCC_NETWORK_HOST=my-evcc.local" Environment="EVCC_NETWORK_PORT=80" ExecStart= ExecStart=/usr/bin/evcc --custom-css /path/to/my.css ``` Note The first empty `ExecStart=` line is important to override the default command. Tip All parameters from `evcc.yaml` can be set as environment variables: `EVCC_` + parameter name in uppercase. For a complete list of all CLI options, see the [CLI documentation](/en/reference/cli/evcc). []() ## Manual Installation [Section titled “Manual Installation”](#manual-installation) In addition to the Debian/Ubuntu APT package, we also provide other binaries for Linux. ### Installation [Section titled “Installation”](#installation) * Download the appropriate file for your system: * 64-bit Intel CPU: [evcc\_X.XX\_linux\_amd64.tar.gz](https://github.com/evcc-io/evcc/releases/latest) * 64-bit ARM CPU: [evcc\_X.XX\_linux\_arm64.tar.gz](https://github.com/evcc-io/evcc/releases/latest) * 32-bit ARM CPU (e.g. Raspberry Pi 32-bit OS): [evcc\_X.XX\_linux\_armv6.tar.gz](https://github.com/evcc-io/evcc/releases/latest) * Extract the downloaded file (e.g., by double-clicking). * The extracted folder contains an `evcc` program. * Open a terminal and navigate to the new folder. * Check if evcc works with this command: ```plaintext ./evcc -v ``` * You should see the current version of evcc (e.g., `evcc version 0.xxx.y`). ### Configuration [Section titled “Configuration”](#configuration-1) You can configure evcc via the web interface or a configuration file. See [Configuration](/en/installation/configuration) for details. Start evcc with: ```sh ./evcc ``` Then open your browser at and follow the instructions. ### Upgrade/Downgrade [Section titled “Upgrade/Downgrade”](#upgradedowngrade) Follow the steps above and replace the evcc program file with the new or previous version. The configuration does not need to be redone. ### Setting up the Service [Section titled “Setting up the Service”](#setting-up-the-service) For production use, you’ll want to set up evcc as a system service. This ensures evcc starts when the computer boots and automatically restarts in case of errors. Note This documentation assumes Linux supports `systemd`. * Run the following command to create and open an editor with a new file for the service: ```sh sudo nano /etc/systemd/system/evcc.service ``` * Copy the following content into the file: ```plaintext [Unit] Description=evcc Requires=network-online.target After=syslog.target network.target network-online.target Wants=network-online.target StartLimitIntervalSec=10 StartLimitBurst=10 [Service] ExecStart=/usr/local/bin/evcc Restart=always RestartSec=5 [Install] WantedBy=multi-user.target ``` Adjust the path of the `evcc` file in `ExecStart` if the file is located in a different directory. This also assumes that the configuration file `evcc.yaml` can be found at `/etc/evcc.yaml`. If this is not the case, add the text `-c /yourpath/evcc.yaml` at the end of `ExecStart`. Replace `yourpath` with the appropriate directory. * Test the service: ```sh sudo systemctl daemon-reload sudo systemctl start evcc sudo systemctl status evcc ``` On success, the output should contain: `Active: active (running)`. * Configure the service to start automatically at system boot: ```sh sudo systemctl enable evcc.service ``` For more information, see the [System Service](#systemd) section above. # Raspberry Pi & Co. The easiest way to install evcc on a Raspberry Pi or similar single-board computers. Pre-configured and ready to set up via the web UI! ## Quick Start [Section titled “Quick Start”](#quick-start) 1. ### Download File [Section titled “Download File”](#download-file) Go to the **[evcc Linux Images](https://github.com/evcc-io/images/releases)** and download the latest version for Raspberry Pi (`evcc_{version}_rpi.img.zip`). 2. ### Flash SD Card [Section titled “Flash SD Card”](#flash-sd-card) If not already available: **[Download balenaEtcher](https://etcher.balena.io/)** * Insert SD card into computer * Open balenaEtcher * **Flash from file** → select downloaded file * **Select target** → select your SD card * **Flash!** → wait until finished Alternative Instead of “Download File & Flash SD Card,” you can also prepare the SD card by using the **[Raspberry Pi Imager](https://www.raspberrypi.com/software/)**. The evcc image can be found under **choose OS → other specific-purpose OS → home assistance and home automation → evcc**. 3. ### Start Raspberry Pi [Section titled “Start Raspberry Pi”](#start-raspberry-pi) * Insert SD card into Raspberry Pi * Connect network cable (recommended) - alternatively [set up WiFi](#wifi) * Connect power adapter * Wait until started 4. ### evcc Web UI [Section titled “evcc Web UI”](#evcc-web-ui)  * Open browser * Enter **** * Certificate warning must be accepted (normal, connection is encrypted) * Alternatively via IP address, e.g., `https://192.168.1.123/` (determine IP in router) * Set administrator password (on first start) * Set up devices (wallbox, solar system, home battery, vehicles) * Note: At least one loadpoint must be created for evcc to run. More details on setup can be found in the [configuration guide](/en/installation/configuration).  **Done!** 🎉 System configuration and updates work via [Cockpit](#cockpit). Log in there once to change the default Linux password. []() ## Set up WiFi [Section titled “Set up WiFi”](#set-up-wifi) If no network cable is available, the Raspberry Pi creates a WiFi hotspot for initial setup. * Search for WiFi **“evcc-setup”** on your smartphone * Connect (no password required) * Select your home WiFi network from the list * Enter your home WiFi password * Raspberry Pi ends the hotspot and connects to your home WiFi * Continue with [evcc Web UI](#evcc-web-ui) WiFi configuration can also be done later via [Cockpit](#cockpit). []() ## System Management via Cockpit [Section titled “System Management via Cockpit”](#system-management-via-cockpit) Cockpit is a graphical system management interface for Linux. Here you can configure your system, install updates, and change network settings. * URL: * User: `admin` * Password: `admin` (initial) On first login, you’ll be prompted to change the default password. Choose a secure password for system management. If you forget it, you’ll need to flash the SD card again. There is no “forgot password” function.  **Important Functions:** * **System:** Overview of CPU, memory, and disk * **Logs:** View system logs * **Networking:** Configure network and WiFi * **Navigator:** File editor for configuration files * **Terminal:** Access to command line * **Software Updates:** Update system Caution **The Cockpit password is only for system management (incl. SSH).** You set a separate administrator password for the evcc Web UI. ## Hardware Recommendations [Section titled “Hardware Recommendations”](#hardware-recommendations) evcc runs on various single-board computers and needs only few resources. Even 1 GB RAM is completely sufficient. **Supported Devices:** * Raspberry Pi 3, 4, and 5 - all models work equally well * Raspberry Pi Zero 2 W - works well * NanoPi R3S - compact, affordable, and comes with case and integrated eMMC storage **Storage:** At least 16 GB SD card or eMMC. For longer lifespan, we recommend eMMC instead of SD card (e.g., with NanoPi). SD cards can wear out from frequent write operations. See also [Armbian recommendations](https://docs.armbian.com/User-Guide_Getting-Started/#what-do-i-need). **Power Supply:** Use original power supply from respective manufacturer. **Network:** Wired connection is strongly recommended. WiFi is possible but often less stable. ## About the evcc Linux Image [Section titled “About the evcc Linux Image”](#about-the-evcc-linux-image) The evcc Linux image is based on [Armbian](https://www.armbian.com/) and offers some practical features: ### Available Services [Section titled “Available Services”](#available-services) | Service | URL | Note | | ----------- | ------------------------------------------------------ | ------------------------------ | | evcc Web UI | `https://evcc.local/` | self-signed cert **(default)** | | | `http://evcc.local:7070/` | unencrypted | | OCPP Server | `ws://evcc.local:8887/` | unencrypted **(default)** | | | `wss://evcc.local:8888/` | self-signed cert | | Cockpit | `https://evcc.local:9090/` (initial password: `admin`) | self-signed cert | | SSH | `ssh admin@evcc.local` (initial password: `admin`) | | The image offers an encrypted version for all services. We recommend using encrypted connections even in local networks. For OCPP, some wallboxes don’t support self-signed certificates. Use unencrypted WS as a fallback. ### Updates [Section titled “Updates”](#updates) * Operating system: Security updates are automatically installed * evcc: Updates can be performed manually via [Cockpit](#cockpit) ### SSH Access [Section titled “SSH Access”](#ssh-access) You can connect via SSH with the `admin` user (same credentials as [Cockpit](#cockpit)). More technical details can be found in the [GitHub Repository](https://github.com/evcc-io/images). ## Next Steps [Section titled “Next Steps”](#next-steps) In the [Features](/en/features/solar-charging) section, you can learn about all possibilities of evcc. Also download the [iOS/Android app](/en/features/app). # macOS This guide describes the installation for macOS (10.12 and higher) using the [Homebrew](https://brew.sh) package manager. Note If you want to install evcc without a package manager or test a nightly version, check out the [Manual Installation](#manual) section. ## Installation [Section titled “Installation”](#installation) 1. ### Install [Section titled “Install”](#install) Open a terminal window and install [Homebrew](https://brew.sh), if it’s not already installed. ```sh brew tap evcc-io/tap brew trust --formula evcc-io/tap brew update brew install evcc ``` 2. ### Start [Section titled “Start”](#start) ```sh brew services start evcc ``` 3. ### Set up [Section titled “Set up”](#set-up) Open the evcc interface in your browser: . Set an administrator password and configure your devices directly via the web interface. ## Configuration [Section titled “Configuration”](#configuration) Recommended Configure evcc directly in your browser. After the first start, you can configure evcc at . Settings are automatically saved in the database. Alternatively, you can use an `evcc.yaml` configuration file at `/etc/evcc.yaml`. Details can be found in [Configuration](/en/installation/configuration). ## Upgrades [Section titled “Upgrades”](#upgrades) To upgrade to a new version of evcc, perform the following steps: * Open a terminal window * Update package lists: ```sh brew update ``` * Upgrade evcc: ```sh brew upgrade evcc ``` OCPP and the Application Firewall Each upgrade installs a new binary, which the macOS Application Firewall treats as a new application. If the firewall is enabled, incoming connections are blocked until the new version is approved. OCPP chargers can no longer connect, while everything else keeps working. On a headless Mac the approval dialog is never seen. Approve the binary from the command line after each upgrade: ```sh sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add "$(brew --prefix)/opt/evcc/bin/evcc" brew services restart evcc ``` ## Additional Commands [Section titled “Additional Commands”](#additional-commands) * Check the status of the evcc server: ```sh brew services info evcc ``` * View logs: ```sh tail -f /opt/homebrew/var/log/evcc.log ``` []() ## Manual Installation [Section titled “Manual Installation”](#manual-installation) Here you’ll find instructions for manually installing evcc on macOS. ### Installation [Section titled “Installation”](#installation-1) * Download the appropriate file to your system: * 64-bit ARM or Intel CPU: [evcc\_X.XX\_macOS\_all.tar.gz](https://github.com/evcc-io/evcc/releases/latest) * Extract the downloaded file (e.g., by double-clicking the file) * There will now be a new folder with the `evcc` program * Open a terminal and navigate to the folder containing the `evcc` program * Start evcc with the following command: ```sh ./evcc -v ``` * You should see the current version of evcc (e.g., `evcc version 0.xxx.y`). ### Configuration [Section titled “Configuration”](#configuration-1) After the first start, open in your browser and configure evcc via the web interface. Alternatively, you can create an `evcc.yaml` configuration file (see [Configuration](/en/installation/configuration)) and start evcc with it: ```sh ./evcc -c evcc.yaml ``` ### Updates/Downgrades [Section titled “Updates/Downgrades”](#updatesdowngrades) Follow the steps above and replace the evcc program file with the new or previous version. The configuration does not need to be redone. # Proxmox Caution This is a community guide for advanced users. We cannot provide support for Proxmox-specific questions and bug reports. Proxmox is a virtualisation platform which enables very simple evcc hosting. If you plan to run evcc on a Linux Home server, Proxmox can be a flexible alternative, which makes it possible to install other systems in addition to evcc. An evcc installation on [Proxmox](https://www.proxmox.com/en/) then behaves exactly the same way as an installation on a dedicated Linux server. The following installation has been tested with Ubuntu 24.4. ## Manual Installation [Section titled “Manual Installation”](#manual-installation) 1. If not already present on your system, load a current Ubuntu template onto your server. 2. Create a Debian based LX container that is configured with minimal resources. (8G of disk and 512MB of RAM are plenty of resources) See screenshot:  3. Install evcc as described in the instructions for Debian-based Linux systems [Debian, Ubuntu Installation](/en/installation/linux). 4. Update evcc via the Debian package management. ## Using Helper Script [Section titled “Using Helper Script”](#using-helper-script) If you prefer to use a script for the installation, copy the bash script under the following link [Proxmox VE Helper-Scripts](https://community-scripts.github.io/ProxmoxVE/scripts?id=evcc) into the Proxmox console. This way creates a container with 1 GB RAM and since evcc is already installed, you can start directly with the configuration wizard. There are also other useful scripts on this page, e.g. for backups to external systems. # Windows Here you’ll find instructions for manually installing evcc on Windows. Caution This manual installation requires advanced PC knowledge, especially when working with the Command Prompt or PowerShell. Running evcc on Windows is possible. However, evcc is typically used in a Linux environment (e.g., Raspberry Pi). ## Installation [Section titled “Installation”](#installation) 1. ### Install [Section titled “Install”](#install) Download the appropriate file for your system and extract it (e.g., by double-clicking): * 64-Bit Intel CPU: [evcc\_X.XX\_windows\_amd64.zip](https://github.com/evcc-io/evcc/releases/latest) Open Command Prompt and navigate to the extracted folder. Verify the install: ```sh evcc -v ``` You should see the current version of evcc (e.g., `evcc version 0.xxx.y`). 2. ### Start [Section titled “Start”](#start) ```sh ./evcc ``` 3. ### Set up [Section titled “Set up”](#set-up) Open the evcc interface in your browser: . Set an administrator password and configure your devices directly via the web interface. ## Configuration file (alternative) [Section titled “Configuration file (alternative)”](#configuration-file-alternative) Alternatively to the web interface, you can use an `evcc.yaml` configuration file. See [Configuration](/en/installation/configuration) for details. Start evcc with: ```sh ./evcc -c evcc.yaml ``` ## Update/Downgrade [Section titled “Update/Downgrade”](#updatedowngrade) Follow the steps above and replace the evcc program file with the new or previous version. The configuration does not need to be redone. ## Background Service [Section titled “Background Service”](#background-service) ### Task Scheduler [Section titled “Task Scheduler”](#task-scheduler) Note This documentation assumes that evcc is located in `c:\evcc`. These instructions were created using Windows 10. * Open the start menu and search for “Task Scheduler”, then right-click it and choose “Run as administrator”:  * Once you’ve started Task Scheduler, choose whether to create the new service in its own folder or in the general Task Scheduler Library. In this example, we create a dedicated `evcc` folder. Select “Task Scheduler Library”, then right-click to open the context menu and choose “New Folder…”:  * Now select the new `evcc` folder and open the context menu again. Choose “Create Task”:  * Give the task a name (e.g. “evcc”) and a short description. Since we need to run as a system service, open user management via “Change User or Group” and enter `SYSTEM` in the box. Click “Check Names” — the word “SYSTEM” should be underscored. Click OK to close the dialog:   * In the “Triggers” tab, click “New…”. Set the trigger to “At Startup” and check that the “Enabled” checkbox is ticked:  * In the “Actions” tab, click “New”. Make sure “Start a Program” is selected, then find your `evcc.exe` executable using the Browse option. It is recommended to also set the path in the “Start in” box so that the configuration file is found automatically:  * In the “Conditions” tab, the default settings can be left as-is. Note SMA Home Manager can sometimes have issues when used with Wi-Fi — try enabling the “Network” condition and selecting the appropriate connection interface in the dropdown.  * In the “Settings” tab, make sure to select “Run task as soon as possible after a scheduled start is missed”. Also make sure “Stop the task if it runs longer than:” is **not** selected — otherwise evcc will randomly stop running.  The task can now be started manually or tested with a reboot. To check it’s working, navigate to `http://localhost:7070` in your browser. ### NSSM [Section titled “NSSM”](#nssm) Note This documentation assumes that evcc is located in `c:\Tools\evcc`. These instructions were created using Windows 11. As an alternative to Task Scheduler, you can run evcc as a Windows service. A service runs without user login and offers better control over restart behaviour and error handling. Since evcc does not natively support the Windows service interface, [*nssm*](https://nssm.cc/download) (*Non-Sucking Service Manager*) can be used as a service wrapper. * Download *nssm* from [nssm.cc](https://nssm.cc/download) and extract the ZIP file to `C:\Tools\nssm\`. * Open a command prompt (`cmd.exe`) and change to the `win64` folder: ```sh cd /D C:\Tools\nssm\nssm-2.24\win64 ``` * Install the service: ```sh nssm install evcc ``` * Go through the tabs of the dialog. The following settings are recommendations. * **Application**:  * *Path*: Path to `evcc.exe`. * *Start directory*: Working directory for evcc. * *Arguments*: Parameters for evcc, e.g. `-c evcc.yaml`. Optional: `--database evcc.db` to explicitly set the database path. Without this option, the database is stored in the executing account’s user profile. Under the *System* account, that would be `%SystemRoot%\system32\config\systemprofile\.evcc\evcc.db` — a different location than when starting interactively. With `--database` you ensure the same database is always used. This is relevant when [resetting the password](/en/faq#password-reset). * **Details**:  * *Display Name*: Name of the service in Windows Services (ideally the same as *Service Name*). * *Startup type*: *Automatic* for auto-start on boot. * **Log on**:  Default: service runs under the *System* account. Details: [nssm documentation](https://nssm.cc/usage). The account chosen here determines where evcc stores its database `evcc.db` (see *Arguments* above). * **Dependencies**:  Adding `NlaSvc` as a dependency ensures the network is ready before evcc starts. * **Process**:  Keep defaults. * **Shutdown**:  Keep defaults. nssm first tries `Ctrl`+`C`, then `WM_CLOSE`/`WM_QUIT`, and forcefully terminates the process after timeout. * **Exit actions**:  Recommendation: *Restart application* with 10 second delay, so evcc automatically restarts after a crash or restart via the web UI. * **I/O**:  Optional: redirect `stdout` and `stderr` to log files. Keep evcc’s log level low to avoid the files growing too quickly. * **File rotation**:  Optional: enable log rotation to limit log file sizes. * **Environment**:  Keep defaults. Click *Install Service* to set up the service. The service can then be started and stopped via the Windows Services management console. To verify, navigate to `http://localhost:7070` in your browser. # MCP-Server Experimental The MCP server is experimental and may change at any time. With the [Model Context Protocol](https://en.wikipedia.org/wiki/Model_Context_Protocol) (MCP for short), it is possible to give LLMs like Claude, Gemini, and ChatGPT structured access to external systems, such as evcc. MCP server is enabled on boot if experimental is activated. ## Usage with Claude Code [Section titled “Usage with Claude Code”](#usage-with-claude-code) This example shows how you can use evcc with Claude Code via CLI. MCPs via HTTP are currently only available with the [paid version](https://www.anthropic.com/pricing). Of course, you can also use other LLMs like Gemini or ChatGPT. 1. Install Claude Code according to the [official guide](https://docs.anthropic.com/en/docs/claude-code/overview). 2. Create an empty folder for your test and navigate to this folder: ```bash mkdir evcc-mcp-test cd evcc-mcp-test ``` 3. Add evcc as an MCP server to your workspace: ```bash claude mcp add --transport http evcc http://localhost:7070/mcp ``` 4. Make sure your evcc instance is running with the MCP server by checking MCP card in the UI configuration. 5. Start Claude Code and enter a query. ```bash claude ╭──────────────────────────────────────────────────────────────────────────────────────────╮ │ > Will I be able to fill my car with solar energy today? │ ╰──────────────────────────────────────────────────────────────────────────────────────────╯ ``` 6. By default, you will be asked before the system makes a request to evcc. You must confirm these requests. Now you can watch Claude Code work and should ultimately receive a proper answer to your question. However, the above query will only work if you have configured a [PV forecast](/en/tariffs#pv-forecast). ## Example: Creating a Charging Plan [Section titled “Example: Creating a Charging Plan”](#example-creating-a-charging-plan) Here you can see an example query where Claude creates a charging plan for the white Model 3. The Sonnet 4 model is used. [](/_astro/mcp-integration.D0_ADKoY.mp4) ## Demo Server [Section titled “Demo Server”](#demo-server) MCP is enabled on the demo server at [demo.evcc.io](https://demo.evcc.io). So you can also test directly with it: ```bash claude mcp add --transport http evcc-demo https://demo.evcc.io/mcp ``` Since this instance is used by many people, the results may be unreliable. # MQTT API The [API State](/en/reference/state) is also published via MQTT. Every field becomes its own topic, nested objects and lists are converted into individual sub-topics (index starts at `1`). ## Read-Only Topics [Section titled “Read-Only Topics”](#read-only-topics) ### Site [Section titled “Site”](#site) * `evcc/site/siteTitle`: site title * `evcc/site/currency`: configured currency * `evcc/site/homePower`: current home consumption (W) * `evcc/site/pvPower`: current solar production (W) * `evcc/site/grid/power`: current grid power (W, positive = import) * `evcc/site/battery/power`: battery power (W, positive = discharge) * `evcc/site/battery/soc`: battery state of charge (%) * `evcc/site/greenShareHome`: self-produced energy share of home consumption (0–1) * `evcc/site/greenShareLoadpoints`: self-produced energy share of loadpoint consumption (0–1) * `evcc/site/tariffGrid`: current grid tariff * `evcc/site/tariffFeedIn`: current feed-in tariff * `evcc/site/tariffCo2`: current CO₂ intensity * `evcc/site/batteryGridChargeActive`: battery grid charging active (true/false) ### Loadpoints [Section titled “Loadpoints”](#loadpoints) All loadpoint IDs begin at `1`. * `evcc/loadpoints`: number of available loadpoints * `evcc/loadpoints//title`: loadpoint title * `evcc/loadpoints//connected`: vehicle connected (true/false) * `evcc/loadpoints//charging`: currently charging (true/false) * `evcc/loadpoints//enabled`: charger enabled (true/false) * `evcc/loadpoints//chargePower`: current charge power (W) * `evcc/loadpoints//chargedEnergy`: energy charged in session (Wh) * `evcc/loadpoints//chargeDuration`: charge duration (ns) * `evcc/loadpoints//chargeRemainingDuration`: remaining charge duration (ns) * `evcc/loadpoints//chargeRemainingEnergy`: remaining energy (Wh) * `evcc/loadpoints//chargeTotalImport`: charge meter total (Wh) * `evcc/loadpoints//vehicleName`: vehicle identifier * `evcc/loadpoints//vehicleTitle`: vehicle display name * `evcc/loadpoints//vehicleSoc`: vehicle SoC (%) * `evcc/loadpoints//vehicleRange`: vehicle range (km) * `evcc/loadpoints//phasesActive`: active phases * `evcc/loadpoints//planActive`: plan currently active (true/false) * `evcc/loadpoints//sessionEnergy`: session energy (Wh) * `evcc/loadpoints//sessionSolarPercentage`: self-produced energy share of session (%) * `evcc/loadpoints//smartCostActive`: smart cost currently active (true/false) * `evcc/loadpoints//effectivePriority`: effective priority More Topics This list is incomplete. For all available topics, use [MQTT Explorer](https://mqtt-explorer.com/). ## Writable Topics [Section titled “Writable Topics”](#writable-topics) To change writable topics, append `/set` to the topic and send the new value. ```bash mosquitto_pub -t "evcc/loadpoints/1/phasesConfigured/set" -m "3" ``` Times are in UTC using the format `yyyy-mm-ddThh:mm:ssZ`, e.g. `2023-03-05T07:00:00Z` (= 5 March 2023, 8:00 CET). The following strings are recognised as empty values: `nil`, `null`, `none`, `-`. Use these to reset previously set thresholds: ```bash mosquitto_pub -t "evcc/site/batteryGridChargeLimit/set" -m "none" ``` ### Site [Section titled “Site”](#site-1) * `evcc/site/prioritySoc`: battery priority SoC * `evcc/site/bufferSoc`: battery buffer SoC * `evcc/site/bufferStartSoc`: battery buffer start SoC * `evcc/site/residualPower`: grid residual power * `evcc/site/batteryGridChargeLimit`: smart charging cost limit * `evcc/site/batteryDischargeControl`: enable/disable battery discharge control (true/false) * `evcc/site/batteryMode`: external battery mode (`normal`, `hold`, `charge`) — directly controls all controllable batteries, overrules other evcc modes, resets after 60 s * `evcc/site/smartCostLimit`: smart cost limit for all loadpoints * `evcc/site/smartFeedInPriorityLimit`: feed-in priority limit for all loadpoints ### Loadpoints [Section titled “Loadpoints”](#loadpoints-1) * `evcc/loadpoints//mode`: charge mode * `evcc/loadpoints//minSoc`: minimum SoC * `evcc/loadpoints//limitSoc`: limit SoC in % — only applicable for online vehicles * `evcc/loadpoints//limitEnergy`: limit energy in kWh — only applicable for offline vehicles * `evcc/loadpoints//planEnergy`: plan energy (JSON payload: `{"value": 50, "time": "2023-03-05T07:00:00Z"}`) * `evcc/loadpoints//phasesConfigured`: configured phases * `evcc/loadpoints//minCurrent`: minimum current value * `evcc/loadpoints//maxCurrent`: maximum current value * `evcc/loadpoints//enableThreshold`: threshold value * `evcc/loadpoints//enableDelay`: delay value (s) * `evcc/loadpoints//disableThreshold`: threshold value * `evcc/loadpoints//disableDelay`: delay value (s) * `evcc/loadpoints//batteryboost`: battery boost enabled (1/0) * `evcc/loadpoints//batteryBoostLimit`: battery boost SoC limit * `evcc/loadpoints//priority`: priority value * `evcc/loadpoints//smartCostLimit`: smart cost limit * `evcc/loadpoints//smartFeedInPriorityLimit`: feed-in priority limit * `evcc/loadpoints//planStrategy`: plan strategy (JSON) * `evcc/loadpoints//vehicle`: set vehicle by name ### Vehicles [Section titled “Vehicles”](#vehicles) For vehicle names see `evcc/vehicles`. * `evcc/vehicles//minSoc`: minimum SoC in % * `evcc/vehicles//limitSoc`: limit SoC in % * `evcc/vehicles//planSoc`: plan SoC (JSON payload: `{"value": 50, "time": "2023-03-05T07:00:00Z"}`) * `evcc/vehicles//planStrategy`: plan strategy (JSON) # OCPP Forward Sometimes charging sessions need to reach an external OCPP backend, e.g. a billing platform for employer reimbursement or a charge point operator. A charger can normally talk to only one OCPP server. With forwarding, the charger stays connected to your evcc instance, which passes its messages on to the external server as well. evcc keeps managing the charging. The external server receives charging sessions and meter values live and can, if allowed, also control the charger. ## Setup [Section titled “Setup”](#setup) Forwarding is available for chargers that are integrated via OCPP, i.e. chargers that use evcc as their OCPP server. Set up the charger first, then you can configure forwarding for it. 1. Open **Configuration → OCPP Server**. 2. The **Station IDs** list shows your connected OCPP chargers. Click the cloud button next to the charger to open the **OCPP Forward** dialog. 3. Enter the **Upstream server URL**, the address of the server to forward to, e.g. `wss://billing.example.com/ocpp`. 4. If the external server requires authentication, enter **Username** and **Password** (HTTP Basic Auth). If it expects a different charger identifier, set the **Station ID**. 5. Click **Save**. Forwarding starts immediately, no restart needed. The cloud icon next to the charger shows whether forwarding is working. Connection problems are shown in the dialog. To stop forwarding, open the dialog again and click **Remove**. ## Upstream Commands [Section titled “Upstream Commands”](#upstream-commands) By default, the external server can send commands to the charger. To avoid conflicts with charging control, enable **Block commands from the upstream server** in the advanced settings. The server still receives every charger message, but evcc retains exclusive control. ## Certificates [Section titled “Certificates”](#certificates) The advanced settings also cover TLS. Enable **Allow self-signed certificates** for test setups without a valid certificate. Provide a **Server certificate (CA)** if the external server uses a certificate from a private certificate authority. # Sunny Home Manager evcc supports integration with the [SMA Sunny Home Manager 2.0 (SHM)](https://www.sma.de/produkte/energiemanagement/sunny-home-manager). This integration makes charge points visible in the Sunny Portal and optionally allows control by the SHM. ## How It Works [Section titled “How It Works”](#how-it-works) The integration is permanently active. Once evcc is running, it automatically provides a SEMP endpoint (Smart Energy Management Protocol) and announces it via mDNS on the local network. This allows the SHM to automatically detect and integrate the charge points. Through the integration, all evcc charge points appear as consumers in the Sunny Portal with detailed consumption data. Additionally, the SHM can influence charging power if explicitly allowed. The SEMP endpoint is accessible at `http://[evcc-IP]:7070/semp/` and displays an XML overview of registered devices. ## Setup in Sunny Home Manager [Section titled “Setup in Sunny Home Manager”](#setup-in-sunny-home-manager) After configuring evcc, the charge points are automatically suggested as new devices in the Sunny Portal under **Configuration > Device overview**. There you can activate them and follow the configuration wizard. See the [SMA manual](https://manuals.sma.de/HM-20/en-US/10426801547.html) for setup details. ## Device IDs [Section titled “Device IDs”](#device-ids) No configuration is required on the evcc side. evcc automatically generates the necessary device IDs. Each charge point receives a unique ID in the format: ```plaintext F-AAAAAAAA-BBBBBBBBBBBB-00 ``` Where: * **AAAAAAAA**: The Vendor ID (8 characters, hexadecimal) * **BBBBBBBBBBBB**: The Device ID (12 characters, hexadecimal) If you want to override this automatism (e.g. when moving to different evcc hardware), you can copy the existing IDs from the `/semp/` endpoint of the old system and adjust them under **Settings > Sunny Home Manager**. This ensures the SHM continues to recognise the devices. # Talks, Videos & Blogs Beyond the official documentation there are lots of good, hands-on introduction and tutorial videos. If you are looking for some background on the project, check out the talks and podcasts. ## Videos [Section titled “Videos”](#videos) * May 2026 · Schatten PV\ [Nie wieder Netzstrom fürs E-Auto? Meine Victron + evcc Strategie!](https://www.youtube.com/watch?v=3GWsU53kGmo) * April 2026 · Carsten’s world\ [So lade ich mein E-Auto endlich clever mit PV-Überschuss](https://www.youtube.com/watch?v=C9lo3M-FhOY) * March 2026 · smarterkram | Olli\ [evcc in Home Assistant: Endlich die perfekte Dashboard-Karte](https://www.youtube.com/watch?v=o-EA3kuslmQ) * March 2026 · Smart-Live\ [evcc in Home Assistant installieren & einrichten + eine neue Dashboard-Karte, die du kennen musst!](https://www.youtube.com/watch?v=nQyiFg1RPy8) * November 2025 · Smarthome? Aber sicher!\ [E-Auto laden ohne Cloud: So funktioniert evcc!](https://www.youtube.com/watch?v=X2vzei6kftA) * November 2025 · smarterkram | Olli\ [Überschussladen mit Home Assistant und evcc](https://www.youtube.com/watch?v=Gdh5tbt8ROc) * November 2025 · CTech\&Media\ [evcc Tutorial: Oberfläche, Features & Smart-Home Integration](https://www.youtube.com/watch?v=J2JAv2rvf1Y) * September 2025 · smart home & more\ [evcc Schnellstart: Neues Raspberry‑Pi‑Image & Home‑Assistant‑Integration Schritt für Schritt](https://www.youtube.com/watch?v=_Me0OD0t_jw) * July 2025 · smart home & more\ [Energie clever steuern – auch ohne E-Auto! So hilft dir evcc + Home Assistant](https://www.youtube.com/watch?v=47uIM1mk1SA) * July 2025 · meintechblog.de\ ✨ [Live PV-Quartett – evcc-Special](https://www.youtube.com/watch?v=Zkds8yD2Y1g) * March 2025 · smart home & more\ [Tesla & evcc: So nutzt du die Fleet API & myteslamate mit evcc 2025](https://www.youtube.com/watch?v=8vAmDLrsI50) * February 2025 · smart home & more\ ✨ [evcc 2025 & Home Assistant – Basisinstallation & Migration – Ein echter Gamechanger?](https://www.youtube.com/watch?v=KSUfEhRCW3Y) * December 2024 · smart home & more\ [evcc spricht Home Assistant: So einfach geht’s jetzt mit HACS Integration](https://www.youtube.com/watch?v=8v2Z8ynACPE) * August 2024 · heise & c’t\ [E-Auto laden mit PV-Überschuss: evcc auf dem Raspi](https://www.youtube.com/watch?v=MoBpEXHMNjI) * May 2024 · smart home & more\ [Home Assistant: evcc-Daten zu dynamischen Strompreisen auslesen, visualisieren und damit rechnen](https://www.youtube.com/watch?v=KPkUUqJ5JTI) * April 2024 · smart home & more\ [evcc-Daten nutzen: Effizientes Energiedashboard für Home Assistant](https://youtu.be/V3p5-16U_oU) * March 2024 · smart home & more\ [Home Assistant: Schritt für Schritt - MQTT-Sensor mit Hilfe des MQTT-Explorer einrichten](https://youtu.be/0QQ3y8fgRVA) * March 2024 · smart home & more\ [Home Assistant: evcc Basisinstallation und Konfiguration](https://youtu.be/aPq8k2MronY) * February 2023 · haus-automatisierung.com\ [PV-Überschuss ins E-Auto laden - evcc.io](https://youtu.be/93C47QUjomQ) * February 2023 · verdrahtet\ [PV Überschussladen von A bis Z // evcc, ioBroker und Homematic Integration](https://youtu.be/6JxktkEaZ2o) *✨ featuring the evcc core team* ## Talks [Section titled “Talks”](#talks) * March 2025 · FOSS Backstage, Berlin\ ✨ [More Hearts than Stars: Smart Charging & Community Funding](https://www.youtube.com/watch?v=k7mGNL8dDwY) ([slides](https://speakerdeck.com/naltatis/more-hearts-than-stars-smart-charging-and-community-funding)) * September 2024 · Kieler Open Source und Linux Tage\ ✨ [evcc: Sonne, Autos und dynamische Strompreise](https://youtu.be/PejujWgAAlw) ([slides](https://speakerdeck.com/naltatis/evcc-sonne-autos-and-dynamische-stromtarife)) * 2023 · Night of open Knowledge, Lübeck\ ✨ [Open Source Sonne tanken - Dumme Wallboxen smart machen](https://www.youtube.com/live/K6wmHqnJVnM?t=35m34s) ([slides](https://speakerdeck.com/naltatis/evcc-open-source-sonne-tanken)) * May 2023 · Augsburger Linux-Infotag\ ✨ [Open Source Sonne tanken - Wallboxen mit evcc smarter machen](https://www.youtube.com/watch?v=qN8JwBWOlzw) ([slides](https://speakerdeck.com/naltatis/open-source-sonne-tanken-wallboxen-mit-evcc-smarter-machen)) *✨ featuring the evcc core team* ## Podcasts [Section titled “Podcasts”](#podcasts) * January 2026 · SmartHütte Podcast\ ✨ [Sonne im Tank - Smartes PV-Überschussladen mit Michael Geers vom evcc Projekt](https://podcast.smarthuette.de/episodes/sonne-im-tank-smartes-pv-uberschussladen-mit-michael-geers-vom-evcc-projekt) * October 2025 · The GitHub Podcast\ ✨ [Live from GitHub Universe: Inside the GitHub Secure Open Source Fund](https://the-github-podcast.simplecast.com/episodes/live-from-github-universe-inside-the-github-secure-open-source-fund-EV0GufSU) *✨ featuring the evcc core team* ## Blogposts [Section titled “Blogposts”](#blogposts) News and announcements from the core team are on the [official evcc blog](/en/blog). Here is a list of articles from the community: * November 2023 · the-ninth.com\ [A closer look at the inner workings of evcc](https://www.the-ninth.com/blog/a-closer-look-at-the-inner-workings-of-evcc) * November 2023 · the-ninth.com\ [Running evcc in our second home with Fronius](https://www.the-ninth.com/blog/running-evcc-in-our-second-home-with-fronius) * November 2023 · the-ninth.com\ [Running evcc on Synology with Huawei, go-e and VW](https://www.the-ninth.com/blog/running-evcc-synology-huawei-go-e-vw) * November 2023 · the-ninth.com\ [Comparing evcc and the go-e Controller for solar charging](https://www.the-ninth.com/blog/comparing-evcc-go-e-controller) * June 2023 · elefacts.de\ [evcc Anleitung für intelligentes PV Überschussladen mit vielen Wallboxen](https://www.elefacts.de/test-206-evcc_anleitung_fuer_intelligentes_pv_ueberschussladen_mit_vielen_wallboxen) * May 2023 · elefacts.de\ [Von evcc erfasste Daten langfristig speichern und aufbereiten](https://www.elefacts.de/test-208-von_evcc_erfasste_daten_langfristig_speichern_und_aufbereiten) * March 2023 · hobbyblogging.de\ [evcc installieren - So einfach geht’s!](https://hobbyblogging.de/evcc-installieren) * March 2023 · hobbyblogging.de\ [evcc - Was soll das sein?](https://hobbyblogging.de/evcc-was-soll-das-sein) Missing an entry? Found a good talk, video, or article that’s missing from this list? Click the **Edit page** button below and suggest it. # References Below is technical documentation on various aspects of evcc. ### Configuration [Section titled “Configuration”](#configuration) [An explanation of the settings and configuration files.](/en/reference/configuration) ### Modbus [Section titled “Modbus”](#modbus) [Documentation for Modbus, which is used in turn by various of the devices supported.](/en/reference/modbus) # evcc App The [companion app](/en/features/app) registers an `evcc://` URL scheme on your device. Open such a link to prefill the server setup or jump to a page. ## Add a Server [Section titled “Add a Server”](#server) Opens the server entry with prefilled values. All parameters are optional. Handy for onboarding: share a link or QR code that fills in the server URL and login, so nobody has to type a long address by hand. ```plaintext evcc://server?url=...&title=...&username=...&password=... ``` | Parameter | Description | | ---------- | -------------- | | `url` | Server URL | | `title` | Display name | | `username` | Login user | | `password` | Login password | Make sure the values are URL-encoded. ```plaintext evcc://server?url=https://demo.evcc.io&title=Demo%20Server&username=admin&password=secret ```  ## Open the Forecast [Section titled “Open the Forecast”](#forecast) Navigates to the forecast page. ```plaintext evcc://forecast?server= ``` `server` is the zero-based index of a saved server. If omitted, the active server is used. ## Open a Loadpoint [Section titled “Open a Loadpoint”](#loadpoint) Navigates to the loadpoints page. ```plaintext evcc://loadpoint?lp=&server= ``` `lp` focuses the loadpoint with that one-based number. If omitted, the current loadpoint is used. `server` works the same as above. # evcc evcc - open source solar charging ```plaintext evcc [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --custom-css string Additional user-defined CSS file for custom styling. No compatibility guarantees. --database string Database location (default "~/.evcc/evcc.db") --demo Enter demo mode. Disables auth, config ui and restart --disable-auth Disable authentication (dangerous) -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers --metrics Expose metrics --profile Expose pprof profiles --template string Add custom template file (debug only) --template-type string Custom template type (charger, meter, tariff, vehicle) (debug only) ``` ## See also [Section titled “See also”](#see-also) * [evcc cache](/en/reference/cli/evcc_cache) - Manage cache entries * [evcc charger](/en/reference/cli/evcc_charger) - Query configured chargers * [evcc checkconfig](/en/reference/cli/evcc_checkconfig) - Check config file for errors * [evcc completion](/en/reference/cli/evcc_completion) - Generate the autocompletion script for the specified shell * [evcc config](/en/reference/cli/evcc_config) - Dump database configuration * [evcc detect](/en/reference/cli/evcc_detect) - Auto-detect compatible hardware * [evcc device](/en/reference/cli/evcc_device) - Query database-configured devices (debug only) * [evcc discuss](/en/reference/cli/evcc_discuss) - Request support at Github Discussions () * [evcc dump](/en/reference/cli/evcc_dump) - Dump configuration * [evcc easee-ocpp](/en/reference/cli/evcc_easee-ocpp) - Manage Easee local OCPP configuration * [evcc meter](/en/reference/cli/evcc_meter) - Query configured meters * [evcc metrics](/en/reference/cli/evcc_metrics) - Inspect stored energy metrics * [evcc migrate](/en/reference/cli/evcc_migrate) - Migrate yaml to database (deprecated), reset only * [evcc password](/en/reference/cli/evcc_password) - Password administration * [evcc settings](/en/reference/cli/evcc_settings) - Manage configuration settings * [evcc sponsor](/en/reference/cli/evcc_sponsor) - Validate sponsor token * [evcc sunspec](/en/reference/cli/evcc_sunspec) - Dump SunSpec model information * [evcc tariff](/en/reference/cli/evcc_tariff) - Query configured tariff * [evcc token](/en/reference/cli/evcc_token) - Generate token credentials * [evcc vehicle](/en/reference/cli/evcc_vehicle) - Query configured vehicles # evcc cache Manage cache entries ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging * [evcc cache clear](/en/reference/cli/evcc_cache_clear) - Clear all cache entries * [evcc cache get](/en/reference/cli/evcc_cache_get) - Get cache entries # evcc cache clear Clear all cache entries ```plaintext evcc cache clear [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext -f, --force Force (no confirmation) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc cache](/en/reference/cli/evcc_cache) - Manage cache entries # evcc cache get Get cache entries ```plaintext evcc cache get [flags] ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc cache](/en/reference/cli/evcc_cache) - Manage cache entries # evcc charger Query configured chargers ```plaintext evcc charger [name] [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext -i, --current float Set maximum current -u, --curtail int Curtail feed-in to percent (0-100, only available if supported by device) (default -1) --diagnose Diagnose -m, --dim int Dim (0/1 to switch, only available if supported by device) (default -1) -d, --disable Disable -e, --enable Enable --heartbeat After command, continue running device heartbeats (if any) until interrupted -p, --phases int Set usable phases (1 or 3) --template string Add custom template file (debug only) --template-type string Custom template type (charger, meter, tariff, vehicle) (debug only) --timeout duration Timeout (default 1s) -w, --wakeup Wake up ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging * [evcc charger ramp](/en/reference/cli/evcc_charger_ramp) - Ramp current from 6..16A in configurable steps # evcc charger ramp Ramp current from 6..16A in configurable steps ```plaintext evcc charger ramp [name] [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --delay string ramp delay (default "1s") --digits string fractional digits (0..2) (default "0") --template string Add custom template file (debug only) --template-type string Custom template type (charger, meter, tariff, vehicle) (debug only) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc charger](/en/reference/cli/evcc_charger) - Query configured chargers # evcc checkconfig Check config file for errors ## Synopsis [Section titled “Synopsis”](#synopsis) Check the (specified or default) config file for errors. Note that checkconfig only checks the config file for parsing errors and does not check that individual device configurations are valid. ```plaintext evcc checkconfig [flags] ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging # evcc completion Generate the autocompletion script for the specified shell ## Synopsis [Section titled “Synopsis”](#synopsis) Generate the autocompletion script for evcc for the specified shell. See each sub-command’s help for details on how to use the generated script. ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging * [evcc completion bash](/en/reference/cli/evcc_completion_bash) - Generate the autocompletion script for bash * [evcc completion fish](/en/reference/cli/evcc_completion_fish) - Generate the autocompletion script for fish * [evcc completion powershell](/en/reference/cli/evcc_completion_powershell) - Generate the autocompletion script for powershell * [evcc completion zsh](/en/reference/cli/evcc_completion_zsh) - Generate the autocompletion script for zsh # evcc completion bash Generate the autocompletion script for bash ## Synopsis [Section titled “Synopsis”](#synopsis) Generate the autocompletion script for the bash shell. This script depends on the ‘bash-completion’ package. If it is not installed already, you can install it via your OS’s package manager. To load completions in your current shell session: ```plaintext source <(evcc completion bash) ``` To load completions for every new session, execute once: ### Linux: [Section titled “Linux:”](#linux) ```plaintext evcc completion bash > /etc/bash_completion.d/evcc ``` ### macOS: [Section titled “macOS:”](#macos) ```plaintext evcc completion bash > $(brew --prefix)/etc/bash_completion.d/evcc ``` You will need to start a new shell for this setup to take effect. ```plaintext evcc completion bash ``` ## Options [Section titled “Options”](#options) ```plaintext --no-descriptions disable completion descriptions ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc completion](/en/reference/cli/evcc_completion) - Generate the autocompletion script for the specified shell # evcc completion fish Generate the autocompletion script for fish ## Synopsis [Section titled “Synopsis”](#synopsis) Generate the autocompletion script for the fish shell. To load completions in your current shell session: ```plaintext evcc completion fish | source ``` To load completions for every new session, execute once: ```plaintext evcc completion fish > ~/.config/fish/completions/evcc.fish ``` You will need to start a new shell for this setup to take effect. ```plaintext evcc completion fish [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --no-descriptions disable completion descriptions ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc completion](/en/reference/cli/evcc_completion) - Generate the autocompletion script for the specified shell # evcc completion powershell Generate the autocompletion script for powershell ## Synopsis [Section titled “Synopsis”](#synopsis) Generate the autocompletion script for powershell. To load completions in your current shell session: ```plaintext evcc completion powershell | Out-String | Invoke-Expression ``` To load completions for every new session, add the output of the above command to your powershell profile. ```plaintext evcc completion powershell [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --no-descriptions disable completion descriptions ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc completion](/en/reference/cli/evcc_completion) - Generate the autocompletion script for the specified shell # evcc completion zsh Generate the autocompletion script for zsh ## Synopsis [Section titled “Synopsis”](#synopsis) Generate the autocompletion script for the zsh shell. If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once: ```plaintext echo "autoload -U compinit; compinit" >> ~/.zshrc ``` To load completions in your current shell session: ```plaintext source <(evcc completion zsh) ``` To load completions for every new session, execute once: ### Linux: [Section titled “Linux:”](#linux) ```plaintext evcc completion zsh > "${fpath[1]}/_evcc" ``` ### macOS: [Section titled “macOS:”](#macos) ```plaintext evcc completion zsh > $(brew --prefix)/share/zsh/site-functions/_evcc ``` You will need to start a new shell for this setup to take effect. ```plaintext evcc completion zsh [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --no-descriptions disable completion descriptions ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc completion](/en/reference/cli/evcc_completion) - Generate the autocompletion script for the specified shell # evcc config Dump database configuration ```plaintext evcc config [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --class string Device class (charger|meter|vehicle|tariff|loadpoint|circuit|messenger|hems) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging * [evcc config delete](/en/reference/cli/evcc_config_delete) - Delete device # evcc config delete Delete device ```plaintext evcc config delete [flags] ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc config](/en/reference/cli/evcc_config) - Dump database configuration # evcc detect Auto-detect compatible hardware ## Synopsis [Section titled “Synopsis”](#synopsis) Automatic discovery using detect scans the local network for available devices. Scanning focuses on devices that are commonly used that are detectable with reasonable efforts. On successful detection, suggestions for EVCC configuration can be made. The suggestions should simplify configuring EVCC but are probably not sufficient for fully automatic configuration. ```plaintext evcc detect [host ...] [subnet ...] [flags] ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging # evcc device Query database-configured devices (debug only) ```plaintext evcc device [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --template string Add custom template file (debug only) --template-type string Custom template type (charger, meter, tariff, vehicle) (debug only) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging # evcc discuss Request support at Github Discussions () ```plaintext evcc discuss [flags] ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging # evcc dump Dump configuration ```plaintext evcc dump [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --cfg Dump config file --timeout duration Timeout (default 1s) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging # evcc easee-ocpp Manage Easee local OCPP configuration ## Options [Section titled “Options”](#options) ```plaintext --charger string Easee charger serial number --password string Easee account password --user string Easee account email ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging * [evcc easee-ocpp disable](/en/reference/cli/evcc_easee-ocpp_disable) - Disable local OCPP on Easee charger * [evcc easee-ocpp enable](/en/reference/cli/evcc_easee-ocpp_enable) - Enable local OCPP on Easee charger * [evcc easee-ocpp status](/en/reference/cli/evcc_easee-ocpp_status) - Show Easee local OCPP configuration # evcc easee-ocpp disable Disable local OCPP on Easee charger ```plaintext evcc easee-ocpp disable [flags] ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext --charger string Easee charger serial number -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers --password string Easee account password --user string Easee account email ``` ## See also [Section titled “See also”](#see-also) * [evcc easee-ocpp](/en/reference/cli/evcc_easee-ocpp) - Manage Easee local OCPP configuration # evcc easee-ocpp enable Enable local OCPP on Easee charger ```plaintext evcc easee-ocpp enable [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --url string OCPP Central System URL (e.g. ws://192.168.1.100:8887/) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext --charger string Easee charger serial number -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers --password string Easee account password --user string Easee account email ``` ## See also [Section titled “See also”](#see-also) * [evcc easee-ocpp](/en/reference/cli/evcc_easee-ocpp) - Manage Easee local OCPP configuration # evcc easee-ocpp status Show Easee local OCPP configuration ```plaintext evcc easee-ocpp status [flags] ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext --charger string Easee charger serial number -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers --password string Easee account password --user string Easee account email ``` ## See also [Section titled “See also”](#see-also) * [evcc easee-ocpp](/en/reference/cli/evcc_easee-ocpp) - Manage Easee local OCPP configuration # evcc meter Query configured meters ```plaintext evcc meter [name] [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext -b, --battery-mode string Set battery mode (normal, hold, charge, holdcharge) -w, --battery-mode-wait duration Wait given duration during which potential watchdogs are active -u, --curtail int Curtail feed-in to percent (0-100, only available if supported by device) (default -1) --diagnose Diagnose -m, --dim int Dim (0/1 to switch, only available if supported by device) (default -1) --heartbeat After command, continue running device heartbeats (if any) until interrupted -r, --repeat Repeat until interrupted --repeat-interval duration Interval between repetitions --template string Add custom template file (debug only) --template-type string Custom template type (charger, meter, tariff, vehicle) (debug only) --timeout duration Timeout (default 1s) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging # evcc metrics Inspect stored energy metrics ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging * [evcc metrics battery](/en/reference/cli/evcc_metrics_battery) - Compare battery charge and discharge energy * [evcc metrics data](/en/reference/cli/evcc_metrics_data) - Export energy data as a table * [evcc metrics entities](/en/reference/cli/evcc_metrics_entities) - List metric entities * [evcc metrics forecast](/en/reference/cli/evcc_metrics_forecast) - Compare solar forecast against actual PV production # evcc metrics battery Compare battery charge and discharge energy ## Synopsis [Section titled “Synopsis”](#synopsis) Compare charge and discharge energy per battery. Without arguments all batteries are compared for the current day. Batteries can be selected by name or title. ```plaintext evcc metrics battery [name ...] [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --from string Start date as YYYY-MM-DD (default today) --range string Quick timeframe: day, month or year --to string End date as YYYY-MM-DD, inclusive (default today) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc metrics](/en/reference/cli/evcc_metrics) - Inspect stored energy metrics # evcc metrics data Export energy data as a table ## Synopsis [Section titled “Synopsis”](#synopsis) Export aggregated energy data as a table. Without arguments all entities are exported for the current day. Entities can be selected by name or title; run the entities subcommand to list them. ```plaintext evcc metrics data [entity ...] [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --aggregate string Aggregation interval: 15m, hour, day or month (default "hour") --csv Output CSV instead of a table --from string Start date as YYYY-MM-DD (default today) --group string Limit output to an entity group --range string Quick timeframe: day, month or year --to string End date as YYYY-MM-DD, inclusive (default today) --xlsx Output XLSX instead of a table ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc metrics](/en/reference/cli/evcc_metrics) - Inspect stored energy metrics # evcc metrics entities List metric entities ```plaintext evcc metrics entities [flags] ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc metrics](/en/reference/cli/evcc_metrics) - Inspect stored energy metrics # evcc metrics forecast Compare solar forecast against actual PV production ```plaintext evcc metrics forecast [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --from string Start date as YYYY-MM-DD (default today) --range string Quick timeframe: day, month or year --to string End date as YYYY-MM-DD, inclusive (default today) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc metrics](/en/reference/cli/evcc_metrics) - Inspect stored energy metrics # evcc migrate Migrate yaml to database (deprecated), reset only ```plaintext evcc migrate [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext -r, --reset Reset migrated settings ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging # evcc password Password administration ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging * [evcc password reset](/en/reference/cli/evcc_password_reset) - Reset password * [evcc password set](/en/reference/cli/evcc_password_set) - Set password # evcc password reset Reset password ```plaintext evcc password reset [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext -f, --force Force (no confirmation) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc password](/en/reference/cli/evcc_password) - Password administration # evcc password set Set password ```plaintext evcc password set [flags] ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc password](/en/reference/cli/evcc_password) - Password administration # evcc settings Manage configuration settings ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging * [evcc settings get](/en/reference/cli/evcc_settings_get) - Get configuration settings * [evcc settings set](/en/reference/cli/evcc_settings_set) - Set configuration setting # evcc settings get Get configuration settings ```plaintext evcc settings get [flags] ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc settings](/en/reference/cli/evcc_settings) - Manage configuration settings # evcc settings set Set configuration setting ```plaintext evcc settings set [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext -f, --force Force (no confirmation) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc settings](/en/reference/cli/evcc_settings) - Manage configuration settings # evcc sponsor Validate sponsor token ```plaintext evcc sponsor [name] [flags] ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging # evcc sunspec Dump SunSpec model information ```plaintext evcc sunspec [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext -i, --id int Slave id (default 1) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging # evcc tariff Query configured tariff ```plaintext evcc tariff [name] [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --template string Add custom template file (debug only) --template-type string Custom template type (charger, meter, tariff, vehicle) (debug only) ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging # evcc token Generate token credentials ```plaintext evcc token [vehicle name] [flags] ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging # evcc vehicle Query configured vehicles ```plaintext evcc vehicle [name] [flags] ``` ## Options [Section titled “Options”](#options) ```plaintext --cloud Use cloud service (requires sponsor token) -i, --current int Set maximum current --diagnose Diagnose -a, --start Start charging -o, --stop Stop charging --template string Add custom template file (debug only) --template-type string Custom template type (charger, meter, tariff, vehicle) (debug only) --timeout duration Timeout (default 1s) -w, --wakeup Wake up ``` ## Options inherited from parent commands [Section titled “Options inherited from parent commands”](#options-inherited-from-parent-commands) ```plaintext -c, --config string Config file (default "~/evcc.yaml" or "/etc/evcc.yaml") --database string Database location (default "~/.evcc/evcc.db") -h, --help Help --ignore-db Run command ignoring service database -l, --log string Log level (fatal, error, warn, info, debug, trace) (default "info") --log-headers Log headers ``` ## See also [Section titled “See also”](#see-also) * [evcc](/en/reference/cli/evcc) - evcc - open source solar charging # Configuration evcc can be configured in two ways: **1. UI Configuration (recommended)** Configuration is done via the web interface under **Configuration**. Settings are saved automatically in the database. For more information, see [Configuration](/en/installation/configuration). **2. File-based Configuration** Configuration via the `evcc.yaml` file remains supported. This section documents the YAML-based configuration. Parallel Usage Both configuration methods can be used in parallel. Devices (loadpoints, meters, PV systems, batteries, vehicles) are merged from both sources. For other settings, UI configuration takes priority. Details can be found in the [FAQ](/en/faq#ui-migration). ## File-based Configuration (evcc.yaml) [Section titled “File-based Configuration (evcc.yaml)”](#file-based-configuration-evccyaml) The configuration file is written in YAML format and is called `evcc.yaml` by default. It is located either in the same directory as evcc itself, or on POSIX (e.g. Linux) systems in `/etc/evcc.yaml`. Non-standard paths can be specified at startup: `evcc -c /path/to/evcc.yaml` ### Structure [Section titled “Structure”](#structure) The configuration file contains multiple sections. To reference between sections, devices have a `name` parameter for identification. An example file with many parameters can be found here: Here is an overview of the relationship between the most important parts of the configuration: ``` graph TD; site("site (Zuhause)") subgraph loadpoints loadpointA("Carport (charger: KEBA)") loadpointB("Garage (charger: Wallbe)") end subgraph meters meterGrid("Discovergy") meterPV("SMA Tripower") meterBattery("LG RESU") end subgraph vehicles vehicleA("VW ID.4") vehicleB("Renault Zoe") vehicleC("Tesla Model Y") end loadpointA -- loadpoint.1 --> site loadpointB -- loadpoint.2 --> site vehicleA --> loadpointA vehicleB --> loadpointA vehicleB --> loadpointB vehicleC --> loadpointB meterGrid -- meters.grid --> site meterPV -- meters.pvs --> site meterBattery -- meters.batterys --> site ``` ### How does evcc work? (A look into the innards) [Section titled “How does evcc work? (A look into the innards)”](#how-does-evcc-work-a-look-into-the-innards) In order for the system to function, an electricity meter is important. This allows us to calculate at any point in time the surplus power. Measuring the generated power is interesting, but has no effect on the function, with [this exception](/en/faq#configuration) The surplus power is compared with the minimum power required to charge. If this is sufficient, the charging process is started. The minimum power required to charge is calculated from the values `minCurrent` and `phases`, defined per `loadpoint` (a group of colocated chargers) See [`loadpoints`](/en/reference/configuration/loadpoints) for more information. For example: `phases: 1` und `minCurrent: 8` 1 (phases) x 8A (minCurrent) x 230V (mains voltage) = 1840W (minimum power required to charge) #### Manipulation Options [Section titled “Manipulation Options”](#manipulation-options) Normally, the surplus power corresponds to the available charging power. However, the available charging power can be individually adjusted using several parameters. These are: * Site: `residualpower` * Site: `prioritySoc` * Site: `bufferSoc` * Site: `aux` * Loadpoint: `enable: threshold` * Loadpoint: `disable: threshold` Please refer to the description of each respective parameter for the available settings. * [Site Configuration Parameters](/en/reference/configuration/site) * [Loadpoint Configuration Parameters](/en/reference/configuration/loadpoints) ### Site [Section titled “Site”](#site) A [Site](/en/reference/configuration/site) describes the location with the existing and required devices of the home installation and is responsible for regulating the available power. ### Loadpoint [Section titled “Loadpoint”](#loadpoint) A [Loadpoint](/en/reference/configuration/loadpoints) describes the charging infrastructure and combines existing *Chargers*, *Vehicles*, and anything else a charging point needs. ### Chargers [Section titled “Chargers”](#chargers) [Chargers](/en/reference/configuration/chargers) include a list of chargers and their properties, such as how they are addressed. ### Meters [Section titled “Meters”](#meters) [Meters](/en/reference/configuration/meters) are a list of devices that measure various power flows. These include: * Imported, Exported power * PV-generated power * Charging current of EV (if the charger does not support this directly) * Power flow of house battery(ies) ### Vehicles [Section titled “Vehicles”](#vehicles) To limit the state of charge (SoC) of EVs to a specific level, you can specify the existing [vehicles](/en/reference/configuration/vehicles) and online access data here. ### HEMS [Section titled “HEMS”](#hems) evcc can forward the charging points and their charging currents to another [Home Energy Management System (HEMS)](/en/reference/configuration/hems) so that it can use this information, for example, to control the house battery. ### Messaging [Section titled “Messaging”](#messaging) In this section, you can define events for which you want to be informed. A variety of different systems are supported for message delivery. [More information](/en/reference/configuration/messaging) # chargers To control the charging process, evcc must be able to communicate with a charger. A charger must have at least the following configuration: ```yaml chargers: - name: charger1 # reference name type: ... ... ``` Below, the possible parameters are explained. *** ## Required Parameters [Section titled “Required Parameters”](#required-parameters) ### `name` [Section titled “name”](#name) A short designation of the charger defined here. The value is used when referencing the charger in the configuration of the [charger](/en/reference/configuration/loadpoints#charger). **For example**: ```yaml name: charger1 ``` *** ### `type` [Section titled “type”](#type) This is the evcc-specific charger type that allows communication with the charger. Known chargers can be integrated using the `template` type. The appropriate (template) type can be found under [devices - chargers](/en/chargers). For unknown chargers (or for other individual reasons), define a [user-defined charger](/en/user-defined-devices#charger). **For example**: ```yaml type: custom ``` *** ## Optional Parameters [Section titled “Optional Parameters”](#optional-parameters) ### `integrateddevice` [Section titled “integrateddevice”](#integrateddevice) This parameter causes chargers that operate without a “vehicle” (e.g. heat pump, eBike) to not display a vehicle, thus omitting vehicle detection. In connection with this parameter, an icon can also be assigned (see [`vehicle.icon`](/en/reference/configuration/vehicles#icon)), which will then be displayed at the charger. **For example**: ```yaml features: - integrateddevice icon: bike ``` *** ### `heating` [Section titled “heating”](#heating) This parameter causes the state of charge for chargers in the “switchable sockets (switchsockets)” group to be displayed in degrees instead of percent. **Example**: ```yaml features: - heating ``` *** ### `continuous` [Section titled “continuous”](#continuous) Marks a device that keeps running in its own normal operation when “disabled”. The UI shows “Normal operation” instead of “Standby”. A request to increase power (e.g. on PV surplus or cheap grid power) is labelled “Boost”. Set this feature when your device keeps running in its regular mode without active control. The typical use case is a heat pump; preconfigured heat pump types and matching templates already set the feature. **Example**: ```yaml features: - continuous ``` *** ### `switchdevice` [Section titled “switchdevice”](#switchdevice) Marks a device that can only be switched on/off and does not support continuous current control (e.g. on/off heat pumps, switch sockets). The UI hides the min/max current settings and the `Min+PV` mode for this loadpoint. Matching templates and preconfigured types already set this feature. For custom configurations via `type: custom` without continuous current control, set this feature. **Example**: ```yaml features: - switchdevice ``` *** # eebus Recommendation Configure EEBus in the UI under **Configuration → EEBus**. Certificate and identifiers are generated automatically on first start. **For example**: ```yaml eebus: shipid: EVCC-1234567890abcdef interfaces: - eth0 certificate: public: | -----BEGIN CERTIFICATE----- 1234567890abcdef== -----END CERTIFICATE----- private: | -----BEGIN EC PRIVATE KEY----- 1234567890abcdef -----END EC PRIVATE KEY----- ``` Migration from YAML to UI Remove the `eebus:` block from your `evcc.yaml` and restart. A new certificate is generated automatically and all EEBus devices must be paired again. To keep your existing certificate, enter it in the EEBus dialog under **Show advanced settings**. This is useful if the SKI (part of the public certificate) is already registered with your grid operator for [external control](/en/external-limit). *** ## Required Parameters [Section titled “Required Parameters”](#required-parameters) ### `certificate` [Section titled “certificate”](#certificate) Defines the certificate and its private key to be used for the required HTTPS connection. When configuring in the UI, the certificate is generated automatically. **For example**: ```yaml certificate: public: | -----BEGIN CERTIFICATE----- 1234567890abcdef== -----END CERTIFICATE----- private: | -----BEGIN EC PRIVATE KEY----- 1234567890abcdef -----END EC PRIVATE KEY----- ``` *** ### `certificate.public` [Section titled “certificate.public”](#certificatepublic) The public certificate. **For example**: ```yaml public: | -----BEGIN CERTIFICATE----- 1234567890abcdef== -----END CERTIFICATE----- ``` *** ### `certificate.private` [Section titled “certificate.private”](#certificateprivate) The private key of the certificate. **For example**: ```yaml private: | -----BEGIN EC PRIVATE KEY----- 1234567890abcdef -----END EC PRIVATE KEY----- ``` *** ## Optional Parameters [Section titled “Optional Parameters”](#optional-parameters) ### `interfaces` [Section titled “interfaces”](#interfaces) Defines a list of network interfaces through which EEBus should communicate. By default, all interfaces are used, but this might lead to communication issues. **For example**: ```yaml interfaces: - eth0 ``` ### `shipid` [Section titled “shipid”](#shipid) Defines the SHIP-ID to be used. This should only be necessary for development purposes. Normally evcc generates the SHIP-ID automatically from the `machine-id` (on real hardware) or a randomly generated plant ID (in container environments like Docker), which is stored in the database. You can set an explicit plant ID via `plant` in `evcc.yaml` or the `EVCC_PLANT` environment variable – recommended for better portability. The SHIP-ID is tied to the certificate – if either changes, pairing with devices must be redone. Warning Don’t change this value manually unless you know exactly what you’re doing. **For example**: ```yaml shipid: EVCC-1234567890abcdef ``` # hems The `hems` section configures external control of consumption and feed-in power. This is used e.g. for implementing German § 14a EnWG or § 9 EEG regulations. For background and setup details, see [External Limit](/en/external-limit). Note Curtailment and dimming of controllable consumers act directly on the device, no circuit configuration is required. To apply the consumption limit to charging points, circuits must be set up in [Load Management](/en/features/loadmanagement). An active limit then caps the top-level circuit. SMA Sunny Home Manager & SEMP Protocol The SMA Sunny Home Manager (SHM) integration is active by default and no longer needs to be configured under `hems:`. For details and configuration options, see **Configuration > Sunny Home Manager**. *** ## Required Parameters [Section titled “Required Parameters”](#required-parameters) ### `type` [Section titled “type”](#type) Defines the type of external control. **Possible values**: * `relay`: Connection via switch contact * `fnn`: Connection via FNN control box with multiple switch contacts * `eebus`: Connection via the EEBus protocol *** ## `type: relay` [Section titled “type: relay”](#type-relay) Connection via a switch contact (e.g. control box). The contact signals whether a power limitation is active. ```yaml hems: type: relay maxPower: 8400 # Total power limit when signal is active (in watts) limit: source: gpio function: read pin: 17 ``` ### Parameters [Section titled “Parameters”](#parameters) #### `maxPower` [Section titled “maxPower”](#maxpower) Total power limit in watts that is applied when the signal is active. #### `limit` [Section titled “limit”](#limit) [Plugin](/en/reference/plugins) configuration for reading the switch contact. Expected return value: `true`/`1` = limited, `false`/`0` = normal. #### `passthrough` [Section titled “passthrough”](#passthrough) Optional [plugin](/en/reference/plugins) configuration for passing the limitation signal through to an external system. #### `interval` [Section titled “interval”](#interval) Polling interval for the switch contact. Default: `10s`. For more examples of different connections (GPIO, MQTT, HTTP), see [user-defined integrations](/en/user-defined-devices#external-limit). *** ## `type: fnn` [Section titled “type: fnn”](#type-fnn) Connection via an FNN control box with separate switch contacts. Dimming of consumption (W4) and curtailment of feed-in (W3, S2, S1) are signaled via individual contacts. ```yaml hems: type: fnn maxDimPower: 4200 # Consumption limit while dimmed (in watts) maxCurtailPower: 10000 # Installed PV power, base for curtailment steps (in watts) w4: source: gpio function: read pin: 17 # Read GPIO pin 17 # Return value: false = normal, true = active w3: source: gpio function: read pin: 27 s2: source: gpio function: read pin: 22 s1: source: gpio function: read pin: 23 ``` ### Parameters [Section titled “Parameters”](#parameters-1) At least one of the signals `w4` or `w3` must be configured. #### `maxDimPower` [Section titled “maxDimPower”](#maxdimpower) Consumption limit in watts that is applied while the dim signal (W4) is active. Required when `w4` is configured. #### `maxCurtailPower` [Section titled “maxCurtailPower”](#maxcurtailpower) Installed PV power in watts. Base value for the curtailment steps (W3, S2, S1). #### `w4` [Section titled “w4”](#w4) [Plugin](/en/reference/plugins) configuration for reading the dim signal. When active, consumption is limited to `maxDimPower`. #### `w3` [Section titled “w3”](#w3) [Plugin](/en/reference/plugins) configuration for reading the curtailment signal “0%”. When active, feed-in is limited to 0% of `maxCurtailPower`. #### `s2` [Section titled “s2”](#s2) [Plugin](/en/reference/plugins) configuration for reading the curtailment signal “30%”. When active, feed-in is limited to 30% of `maxCurtailPower`. #### `s1` [Section titled “s1”](#s1) [Plugin](/en/reference/plugins) configuration for reading the curtailment signal “60%”. When active, feed-in is limited to 60% of `maxCurtailPower`. #### `interval` [Section titled “interval”](#interval-1) Polling interval for the switch contacts. Default: `10s`. For setup details, see [External Limit](/en/external-limit). *** ## `type: eebus` [Section titled “type: eebus”](#type-eebus) Connection via the EEBus protocol. The control box automatically transmits the power limit. ```yaml hems: type: eebus ski: "1234-5678-90AB-CDEF" # SKI of the control box ``` ### Parameters [Section titled “Parameters”](#parameters-2) #### `ski` [Section titled “ski”](#ski) SKI (Subject Key Identifier) of the control box. Required for pairing. #### Advanced Limits [Section titled “Advanced Limits”](#advanced-limits) The following optional parameters can be set for EEBus communication: * `contractualConsumptionNominalMax`: Contractual maximum consumption power (in watts) * `failsafeConsumptionActivePowerLimit`: Failsafe limit for consumption power (in watts) * `productionNominalMax`: Installed generator power (Wp, in watts) * `failsafeProductionActivePowerLimit`: Failsafe limit for feed-in power (in watts) * `failsafeDurationMinimum`: Minimum failsafe duration (e.g. `2h`) #### `passthrough` [Section titled “passthrough”](#passthrough-1) Optional [plugin](/en/reference/plugins) configuration for passing the limitation signal through to an external system. #### `interval` [Section titled “interval”](#interval-2) Polling interval. Default: `10s`. For setup and pairing details, see [External Limit](/en/external-limit#eebus-pairing). # influx Defines the configuration required to write data to Influx. *** ## InfluxDB v1.8.x [Section titled “InfluxDB v1.8.x”](#influxdb-v18x) Requires at least InfluxDB 1.8.3 **Example for Influx v1**: ```yaml influx: url: http://localhost:8086 database: evcc # user: # password: ``` *** ## InfluxDB v2.x [Section titled “InfluxDB v2.x”](#influxdb-v2x) **Example for Influx v2**: ```yaml influx: url: http://localhost:8086 database: evcc # InfluxDB v2.x uses the term `bucket`, but for compatibility, it's still named `database` here token: 1234567890abcdef org: home ``` *** ## HTTPS with Self-Signed Certificate [Section titled “HTTPS with Self-Signed Certificate”](#https-with-self-signed-certificate) When using HTTPS (`https://`), the TLS certificate is verified by default. If you’re using a self-signed certificate, certificate verification can be disabled: **For example**: ```yaml influx: url: https://influxdb.example.com:8086 database: evcc token: 1234567890abcdef org: home insecure: true ``` ## VictoriaMetrics [Section titled “VictoriaMetrics”](#victoriametrics) [VictoriaMetrics](https://github.com/VictoriaMetrics/VictoriaMetrics) is a time series database with InfluxDB compatible REST API. HTTP basic authentication can be done via the URL. **Example for VictoriaMetrics**: ```yaml influx: url: http://[username:password@]victoria-metrics:8428 ``` # interval Defines the time interval at which new values are read from all measurement devices and the charging currents of the chargers are re-regulated. **Possible values**: A numerical value followed by the time unit **For example**: ```yaml interval: 30s # every 30 seconds ``` Caution Too short an interval ( < 30s ) can lead to undesired behaviour (oscillations in regulation) if the components involved do not have enough reaction time before the next control cycle begins. Experience shows that an interval of 10s to 15s is possible if all components react quickly enough. This should be tested individually. # loadpoints `loadpoints` (charging points) is a list of charging points that combines a charger, vehicles, and, if necessary, a meter with additional optional parameters for each charging point. A minimal configuration requires a charger. **For example**: ```yaml loadpoints: - title: Garage # display name for UI charger: charger # charger reference vehicle: audi # reference to standard vehicle mode: pv # charge mode (off, now, minpv, pv) ``` References always correspond to the values of the `name` parameter (e.g., `charger`) in the respective device configuration. Now, let’s explain all possible parameters. *** ## Required Parameters [Section titled “Required Parameters”](#required-parameters) ### `title` [Section titled “title”](#title) A description of the charging point, displayed in the user interface (UI). **For example**: ```yaml title: Garage ``` *** ### `charger` [Section titled “charger”](#charger) Reference to a `charger` configuration. **For example**: ```yaml charger: charger ``` Where the value `charger` corresponds to the value of the `name` parameter in the [charger definition](/en/reference/configuration/chargers#name). *** ## Optional Parameters [Section titled “Optional Parameters”](#optional-parameters) ### `meter` [Section titled “meter”](#meter) Reference to a `meter` (current meter) configuration. This entry is only needed if the used charger doesn’t perform its own current measurement or if the measurement values cannot be read from the charger by evcc. However, even in this case, this entry is optional, because evcc assumes that the set maximum current will also be used for charging. **For example**: ```yaml meter: charge ``` Where the value `charge` corresponds to the value of the `name` parameter in the [current meter definition](/en/reference/configuration/meters#name). *** ### `vehicle` [Section titled “vehicle”](#vehicle) `vehicle`: Reference to a `vehicle` configuration that is assigned as the default vehicle to the charging point. When a vehicle is plugged into the charger, it is assumed that this vehicle is connected. Automatic vehicle detection is bypassed. If a different vehicle is connected (e.g., guest vehicle), this can be manually assigned later. **For example**: ```yaml vehicle: renault ``` Where the value `renault` corresponds to the value of the `name` parameter in the [vehicle definition](/en/reference/configuration/vehicles#name). *** ### `mode` [Section titled “mode”](#mode) evcc rememerbers the last used charging mode. With the `mode` parameter, you can specify the charging mode that should be used after the vehicle is disconnected. **Possible values**: * `off`: Charging is stopped, even if a vehicle is connected to the charger. * `now`: Start charging immediately at the maximum possible power. * `minpv`: Start charging immediately at the minimum possible power. If sufficient PV surplus is available, charge faster. * `pv`: Charge only using PV surplus and pause if there isn’t enough power available. **Default value:** `pv` Note In general, an EV requires a minimum of 1.4 kW power per phase for charging. With chargers and vehicles that communicate via the ISO15118 standard, a total of at least 1.4 kW power is needed regardless of the number of phases used for charging. **For example**: ```yaml mode: pv ``` *** ### `soc` [Section titled “soc”](#soc) Defins the default settings for handling the State of Charge (SoC) of a connected vehicle. **For example**: ```yaml soc: poll: mode: charging interval: 60m estimate: true ``` #### `poll` [Section titled “poll”](#poll) Defines how vehicle APIs are used to retrieve real-time information about the vehicle. Caution Changing the default settings is **NOT** recommended, as it could lead to the vehicle’s battery draining or the vehicle manufacturer actively preventing charging control via evcc. **Use at your own risk**. #### `poll.mode` [Section titled “poll.mode”](#pollmode) Defines under what conditions the vehicle data is retrieved. **Possible values**: * `charging`: Update data **ONLY** during a charging session (recommended default). * `connected`: Update data when the vehicle is connected to the charger (not just when charging); the `interval` parameter defines the frequency. * `always`: Update data always, even when the vehicle is not connected to the charger; the [`interval`](#pollinterval) parameter defines the frequency (only supported for one vehicle per charging point). **Default value:** `charging` **For example**: ```yaml mode: charging ``` #### `poll.interval` [Section titled “poll.interval”](#pollinterval) Defines how often the vehicle is queried for data when it is **NOT** charging. **Default value:** `60m` **For example**: ```yaml interval: 60m ``` #### `estimate` [Section titled “estimate”](#estimate) Calculate (interpolate) the current SoC between vehicle data queries. **Possible values**: * `true`: evcc interpolates the SoC values between vehicle data queries (recommended). * `false`: evcc only uses the SoC values returned by the vehicle. **Default value:** `true` **For example**: ```yaml estimate: false # No interpolation ``` *** ### `enable` [Section titled “enable”](#enable) Defines the behaviour of starting charging in PV mode. Additionally, it defines the behaviour during automatic phase switching from 1p to 3p. **For example**: ```yaml enable: threshold: 0 delay: 1m ``` #### `threshold` [Section titled “threshold”](#threshold) Defines the power threshold at the grid connection point in watts (W). **Possible values**: A positive value for grid consumption, a negative value for grid export. When set to `0`, export must reach the minimum charging power. **Default value:** `0` **For example**: ```yaml threshold: 0 ``` Note If a residual power offset for the desired operating point of the surplus regulation is defined for the evcc site using the `residualPower` parameter, this value must be considered when setting the `threshold` value. For example, if `residualPower` is set to 200 (the evcc control sets the desired operating point to 200W feed-in), then setting an `enable` `threshold` value of 100 doesn’t mean that charging will start at 100W grid consumption. Instead, the remaining feed-in power will be reduced by 100W, starting the charging at 100W feed-in. To start charging at 100W grid consumption in this case, the `threshold` value should be set to 300. #### `delay` [Section titled “delay”](#delay) Defines how long the `threshold` must be met. **Default value:** `1m` **For example**: ```yaml delay: 1m ``` *** ### `disable` [Section titled “disable”](#disable) Defines the behaviour of stopping charging in PV mode. Additionally, it defines the behaviour during automatic phase switching from 3p to 1p. **For example**: ```yaml disable: threshold: 200 # maximum import power (W) delay: 10m ``` #### `threshold` [Section titled “threshold”](#threshold-1) Defines the power threshold at the grid connection point in watts (W). **Possible values**: A positive value for grid consumption. When set to `0`, charging stops once surplus no longer covers the minimum charging power. **Default value:** `0` **For example**: ```yaml threshold: 200 # Maximum grid consumption of 200W is allowed ``` Note If a residual power offset for the desired operating point of the surplus regulation is defined for the evcc site using the `residualPower` parameter, this value must be considered when setting the `threshold` value. Refer to the example in the [`enable`](#enable) `threshold` info. Caution Negative values have no effect: while surplus is available evcc keeps charging and never checks the threshold. #### `delay` [Section titled “delay”](#delay-1) Defines how long the `threshold` must be met. **Default value:** `3m` **For example**: ```yaml delay: 10m ``` *** ### `phases` [Section titled “phases”](#phases) deprecated in yaml This value can now be set in the charging point settings dialog. **charger without automatic phase switching**: Defines the number of phases with which the charger is connected. This parameter does not change the physical connection of the charger but is used to determine the minimum starting power for charging in PV mode (in combination with `minCurrent`). Recently, the incoming voltages are evaluated if the charger’s meter provides them. Based on the voltages, the `phases` value is automatically changed via API. In cases where the charger is set to 1p or 3p using a switch, manual changes to the `phases` value are no longer necessary. In cases where 1p/3p charging is realised using the corresponding charging cable rather than a switch, this “automatic” behaviour causes problems. In this case, the `phases` value must be adjusted in the `vehicle` accordingly. Since this value cannot be changed via API, the following workaround can be used: Configure the vehicle twice: once with `phases: 1` and once with `phases: 3`. Depending on the desired charging mode, select the appropriate vehicle in the UI. If a known vehicle is connected, the lower value between `vehicle: phases` and `loadpoint: phases` is used for calculation. For unknown vehicles, only `loadpoint: phases` is considered. While the vehicle is charging and the charger or charging meter provide phase currents, the actual number of phases is detected, and (as long as the vehicle remains connected) this is used for further calculations. This only works for three-phase charging points. **Default value:** `3` **Possible values:** `1|3` **For example**: ```yaml phases: 1 ``` **charger with automatic phase switching**: The value controls whether the automatic phase switching is enabled or disabled. `phases: 0` = Automatic switching enabled `phases: 1 or 3` = Automatic switching disabled, and the set value is fixed **Default value:** `3` **Possible values:** `0|1|3` **For example**: ```yaml phases: 0 ``` Note If the charging point is not assigned a charger but one of the supported controllable sockets (AVM FritzDECT, Shelly, Tasmota, TP-Link, etc.), `phases` must be set to **1** to ensure proper charging control. *** ### `priority` [Section titled “priority”](#priority) During charging, this parameter prioritises loadpoints with each other. The prioritised loadpoint is given the charging power of other non-prioritised loadpoints or those with lower priority. When a prioritised loadpoint accesses this power, it might lead to short-term grid consumption until the regulation stabilises. Higher values indicate higher priority. Loadpoints without an entry have `priority: 0`. When multiple loadpoints are present, this parameter doesn’t influence the order in which the charging sessions are started. However, if a lower-priority loadpoint is charging, a higher-priority one might be switched on if it is given access to the unused charging power. This prioritisation works in `pv` and `minpv` modes. In `minpv` mode, charging is not interrupted, only reduced to the minimum. Note If a vehicle has a priority defined, it overrides the priority of the loadpoint it is connected to. **Default value:** `0` **For example**: ```yaml priority: 2 ``` *** # log, levels ## `log` [Section titled “log”](#log) Defines the level of detail for logging information to the console. **Possible values**: * `fatal`: Only messages of the `fatal` category will be displayed. These are errors that prevent the system from functioning. * `error`: Only messages of the `error` category will be displayed. There are very few of this type of message. * `warn`: Includes `error`, additionally shows messages of the `warn` category. * `info`: Includes `warn`, additionally shows messages of the `info` category. * `debug`: Includes `info`, additionally shows messages of the `debug` category. This is necessary for error analysis. * `trace`: Includes `debug`, additionally shows messages of the `trace` category. This is the most detailed category and can result in very large log data. In general, this is not usually needed! When running evcc in the console, the `log` messages are simply directed to the standard output.\ If evcc is run as a Linux systemd service, messages can be tracked using `sudo journalctl -fau evcc`, see [Logfile zur Fehleranalyse](/en/faq#debugging).\ In the case of a Docker installation, you can view the messages using `docker logs`, see [Docker Documentation](https://docs.docker.com/config/containers/logging/). **For example**: ```yaml log: error ``` *** ## `levels` [Section titled “levels”](#levels) Allows configuring different logging levels for various components of evcc. Defines the level of detail for logging for different evcc components. **Possible components**: * `site`: The central evcc component (control, calculations, …) * `lp-X`: The respective charging point, where `X` is numbered according to the order of [`loadpoints`](/en/reference/configuration/loadpoints) configuration (charging points), starting at `1` * `sma`: The SMA HEMS component if SMA Sunny Home Manager 2.0 is integrated using [`hems`](/en/reference/configuration/hems) * *`vehicle`*: Each [`vehicle`](/en/reference/configuration/vehicles) (vehicle), where you must specify the corresponding value of the [`type`](/en/reference/configuration/vehicles#type) parameter (or template). * Additionally, depending on the use case, additional components can be specified (e.g. `cache`, `db`, `influx`, `mqtt`, …) **Possible values for each component**: Identical to the values of [`log`](#log) **For example**: ```yaml levels: site: debug lp-1: debug lp-2: debug tesla: trace ``` # messaging The `messaging` section configures [notifications](/en/notifications) about charging sessions via services like Telegram, Pushover, ntfy, or email. `events` defines for which events messages are sent, `services` defines where they are sent to. **For example**: ```yaml messaging: events: ... services: ... ``` ## `events` [Section titled “events”](#events) `events` defines the message content for various predefined events. The available events are: * `start`: Charging has started * `stop`: Charging has stopped * `connect`: Vehicle connected * `disconnect`: Vehicle disconnected * `soc`: Vehicle battery state of charge changed * `guest`: Unknown vehicle detected * `asleep`: Vehicle not charging despite charge release * `planoverrun`: Charging plan projected to miss its target **For example**: ```yaml start: # charge start event title: Charge started msg: Started charging in "${mode}" mode ``` ### `title` [Section titled “title”](#title) `title` defines the text for the message title. ### `msg` [Section titled “msg”](#msg) `msg` defines the text for the message content. Titles and messages support placeholders, either in the simple `${variableName}` form or as Go templates (`{{.variableName}}`). The available variables are listed under [message format](/en/notifications#message-format). **Example** (simple syntax): ```yaml messaging: events: start: title: Charging started msg: >- ${title} charging ${vehicleTitle} in ${mode} mode stop: title: Charging finished msg: >- ${title}: ${vehicleTitle} charged ${chargedEnergy:%.1fk}kWh in ${chargeDuration}. Solar share: ${sessionSolarPercentage:%.0f}% connect: title: Vehicle connected msg: >- ${vehicleTitle} connected to ${title} at ${pvPower:%.1fk}kW solar disconnect: title: Vehicle disconnected msg: >- ${vehicleTitle} disconnected from ${title} after ${connectedDuration} ``` **Example** (Go template syntax with calculations and conditions): ```yaml messaging: events: start: title: "{{.vehicleTitle}}: Charging started" msg: | {{.title}} charging {{.vehicleTitle}} in {{ toString .mode | upper }} mode. Solar: {{round (divf .pvPower 1000) 1 }} kW Grid: {{round (divf .grid.Power 1000) 1 }} kW {{if .battery}}Battery: {{round (divf .battery.Power 1000) 1 }} kW ({{.battery.Soc }} %){{end}} stop: title: "{{.vehicleTitle}}: Charging finished" msg: | {{.title}}: {{round (divf .chargedEnergy 1000) 1 }} kWh in {{.chargeDuration}}. Solar share: {{round .sessionSolarPercentage 0 }}% {{- if .sessionPrice}} Cost: {{round .sessionPrice 2 }} {{.currency}} ({{round .sessionPricePerKWh 2 }} {{.currency}}/kWh) {{- end}} connect: title: "{{.vehicleTitle}} connected" msg: | {{.vehicleTitle}} connected to {{.title}}. SoC: {{.vehicleSoc }}% ({{.vehicleRange }} km) Solar: {{round (divf .pvPower 1000) 1 }} kW disconnect: title: "{{.vehicleTitle}} disconnected" msg: | {{.vehicleTitle}} disconnected from {{.title}} after {{.connectedDuration}}. ``` ## `services` [Section titled “services”](#services) `services` defines a list of message services to be used. **For example**: ```yaml services: - type: template template: pushover app: 12345 recipients: - 234567 ``` The available services and their parameters are listed on the [notifications](/en/notifications#services) page. Each service page shows a ready-to-use `evcc.yaml` example. In addition, `type: custom` allows the use of any [plugin](/en/reference/plugins) with write access. See [user-defined notification service](/en/user-defined-devices#notification-service). # meters *Meters* (current measurement devices) is a list of devices in the house that can measure power and energy consumption, PV generation, or house battery usage. A `meter` defines a point of energy measurement and can be a physical device (e.g., a meter at the grid connection point), a PV inverter (AC or DC in the case of hybrid inverters), or a battery inverter. Chargers may have an integrated meter or it can be externally connected. If a charger has an internal current measurement device, no entry for it needs to be created in `meters`. If the charger doesn’t have such a meter, evcc will use the meter configured here and assigned to the charger under [`meters`](/en/reference/configuration/loadpoints#meter) in the charging point configuration, or assume that the charging power set is actually being used. evcc uses a consistent sign convention for power and current values (`power`, `powers`, `currents`): * **Positive (+)** for incoming energy: grid consumption, PV generation, house battery discharge * **Negative (-)** for outgoing energy: grid feed-in, PV inverter standby consumption, house battery charging * **Consumers** (charger, aux meters) are always **positive (+)** If the device returns values with the opposite sign, this can be corrected in the [plugin configuration](/en/reference/plugins) using `scale: -1`. The `meters` configuration is a list of different available devices. **For example**: ```yaml meters: - name: grid type: ... - name: pv type: ... - name: battery type: ... - name: charge type: ... - name: aux type: ... ``` Configurations for known devices can be found under [Devices - House Installation](/en/meters). Below, the various parameters are explained. *** ## Required Parameters [Section titled “Required Parameters”](#required-parameters) ### `name` [Section titled “name”](#name) A short designation of the meter. The value is used when referencing the device in the configuration of the [site](/en/reference/configuration/site) or the [charger](/en/reference/configuration/loadpoints#meter). **For example**: ```yaml name: charger1 ``` *** ### `type` [Section titled “type”](#type) This is the evcc-specific meter type that allows communication with the device. The appropriate type for known devices can be found under [Devices - House Installation](/en/meters). **For example**: ```yaml type: modbus ``` The various possible types and their additional parameters are documented below: *** Note The additional meter fields `title` and `icon` are not supported in the `evcc.yaml` file due to technical reasons. Titles and icons (use case dependent) can only be defined for meters created via the configuration interface. ## Supported Types [Section titled “Supported Types”](#supported-types) ### `movingaverage` [Section titled “movingaverage”](#movingaverage) This meter type can smooth fluctuating meter values. It can be used in all meter applications (`usage`). The `decay` parameter indicates the percentage of the new value to be included in the calculation. **For example** ```yaml meters: - name: grid type: movingaverage decay: 0.1 meter: type: template template: solarlog usage: grid host: 192.0.2.2 ... ``` In this example, 10% of the new value is included. After 10 cycles, the oldest value is removed from the calculation. The duration of this process depends on the `interval`. *** ### `modbus` [Section titled “modbus”](#modbus) Devices connected via the ModBus interface and supported by the [MBMD (ModBus Measurement Daemon)](https://github.com/volkszaehler/mbmd#supported-devices) project. **For example**: ```yaml type: modbus power: Power energy: Sum soc: ChargeState ... ``` #### Required Parameters [Section titled “Required Parameters”](#required-parameters-1) In addition to the parameters defined here, additional parameters are necessary. These are listed in the [Modbus](/en/reference/modbus) documentation. ##### `power` [Section titled “power”](#power) Defines the MBMD measurement value that returns the power, typically `Power`. **For example**: ```yaml power: Power ``` *** ##### `energy` [Section titled “energy”](#energy) Defines the method of measurement that MBMD returns for energy, typically `Sum`. **For example**: ```yaml energy: Sum ``` *** #### Optional Parameters [Section titled “Optional Parameters”](#optional-parameters) ##### `soc` [Section titled “soc”](#soc) Defines the method of measurement that MBMD returns for battery state of charge (SoC), typically `ChargeState`. **For example**: ```yaml soc: ChargeState ``` *** ### `lgess` [Section titled “lgess”](#lgess) LG ESS Home 8/10 devices. **For example**: ```yaml type: lgess usage: grid uri: https://192.0.2.2/ password: "DE200..." ``` Note The `uri` and `password` parameters are only required for a `meter` device if multiple devices are configured. #### Required Parameters [Section titled “Required Parameters”](#required-parameters-2) ##### `usage` [Section titled “usage”](#usage) Defines which measurements are needed here. **Possible Values**: * **`grid`**: For measurements at the grid connection point * **`pv`**: For measurements of PV generation * **`battery`**: For measurements of the house battery *** ##### `uri` [Section titled “uri”](#uri) Defines the URL within the home network of the LG ESS device. **For example**: ```yaml uri: https://192.0.2.2/ ``` *** ##### `password` [Section titled “password”](#password) The registration number of the LG ESS HOME inverter must be entered here. **For example**: ```yaml password: "DE200..." ``` *** ### `openwb` [Section titled “openwb”](#openwb) Using measurements from an OpenWB charger **For example**: ```yaml type: openwb usage: grid broker: 192.0.2.2 ``` Note The `uri` and `password` parameters are only required for a `meter` device if multiple devices are configured. #### Required Parameters [Section titled “Required Parameters”](#required-parameters-3) ##### `usage` [Section titled “usage”](#usage-1) Defines which measurements are needed here. **Possible Values**: * **`grid`**: For measurements at the grid connection point * **`pv`**: For measurements of PV generation * **`battery`**: For measurements of the house battery *** ##### `broker` [Section titled “broker”](#broker) Defines the hostname or IP address and port address within the home network of the OpenWB. **For example**: ```yaml broker: 192.0.2.2:1883 ``` *** ### `sma` [Section titled “sma”](#sma) For using the SMA Home Manager 2.0, SMA Energy Meter, or an SMA inverter. Devices must support the Speedwire protocol. **For example**: ```yaml type: sma uri: 192.0.2.2 serial: 12345678 interface: eth0 ``` *** #### Required Parameters [Section titled “Required Parameters”](#required-parameters-4) Note It is sufficient to define either `uri` or `serial`. ##### `uri` [Section titled “uri”](#uri-1) Defines the hostname or IP address within the home network of the device. **For example**: ```yaml uri: 192.0.2.2 ``` ##### `serial` [Section titled “serial”](#serial) Defines the serial number of the device from which measurements should be received. **For example**: ```yaml serial: 12345678 ``` #### Optional Parameters [Section titled “Optional Parameters”](#optional-parameters-1) ##### `interface` [Section titled “interface”](#interface) Multicast messages can only be received on a specific network interface. Usually, this is the first interface on the system. If it is not the interface connected to the meter, the interface needs to be explicitly specified. **For example**: ```yaml interface: eth0 ``` *** ### `tesla` [Section titled “tesla”](#tesla) *`tesla`*: For using measurements from a Tesla Powerwall. **For example**: ```yaml type: tesla usage: grid uri: https://192.0.2.2/ password: "***" ``` *** #### Required Parameters [Section titled “Required Parameters”](#required-parameters-5) ##### `usage` [Section titled “usage”](#usage-2) Defines which measurements are needed here. **Possible Values**: * **`grid`**: For measurements at the grid connection point * **`pv`**: For measurements of PV generation * **`battery`**: For measurements of the house battery *** ##### `uri` [Section titled “uri”](#uri-2) Defines the hostname or IP address within the home network of the device. **For example**: ```yaml uri: 192.0.2.2 ``` *** ##### `password` [Section titled “password”](#password-1) The password for the *customer* user must be entered here. **For example**: ```yaml password: "ThePassword" ``` *** ### `custom` [Section titled “custom”](#custom) Standard implementation, in which individual values are defined via [plugins](/en/user-defined-devices#meter). **For example**: ```yaml type: custom power: # Power (W) source: # Plugin Type ... energy: # Energy (kWh) source: # Plugin Type ... returnenergy: # Energy in reverse direction (kWh) source: # Plugin Type ... soc: # Battery SOC (%) source: # Plugin Type ... capacity: # Optional Battery Capacity (kWh) currents: # Current (A) per phase - source: # Phase 1 Plugin Type ... - source: # Phase 2 Plugin Type ... - source: # Phase 3 Plugin Type ... powers: # Power (W) per phase - source: # Phase 1 Plugin Type ... - source: # Phase 2 Plugin Type ... - source: # Phase 3 Plugin Type ... voltages: # Voltage (V) per phase - source: # Phase 1 Plugin Type ... - source: # Phase 2 Plugin Type ... - source: # Phase 3 Plugin Type ... ... ``` *** #### Required Parameters [Section titled “Required Parameters”](#required-parameters-6) ##### `power` [Section titled “power”](#power-1) Plugin definition to return power in watts (W). **For example**: ```yaml power: ... # Power (W) source: # Plugin Type ... ``` *** #### Optional Parameters [Section titled “Optional Parameters”](#optional-parameters-2) ##### `energy` [Section titled “energy”](#energy-1) Plugin definition to return consumed energy in kilowatt-hours (kWh). **For example**: ```yaml energy: ... # Energy (kWh) source: # Plugin Type ... ``` *** ##### `returnenergy` [Section titled “returnenergy”](#returnenergy) Plugin definition to return energy in reverse direction in kilowatt-hours (kWh), e.g. grid feed-in. **For example**: ```yaml returnenergy: ... # Energy in reverse direction (kWh) source: # Plugin Type ... ``` *** #### `soc` [Section titled “soc”](#soc-1) Plugin definition to return battery state of charge (SoC) in percentage (%). **For example**: ```yaml soc: ... # Battery SOC (%) source: # Plugin Type ... ``` *** #### `capacity` [Section titled “capacity”](#capacity) Indication of battery capacity. Only useful when multiple batteries are present. Used to determine the overall SoC. *** #### `currents` [Section titled “currents”](#currents) A list of plugin definitions to return current in amperes (A) per phase. **For example**: ```yaml currents: # Current (A) per phase - source: # Phase 1 Plugin Type ... - source: # Phase 2 Plugin Type ... - source: # Phase 3 Plugin Type ... ... ``` *** #### `powers` [Section titled “powers”](#powers) A list of plugin definitions to return power in watts (W) per phase. **For example**: ```yaml powers: # Power (W) per phase - source: # Phase 1 Plugin Type ... - source: # Phase 2 Plugin Type ... - source: # Phase 3 Plugin Type ... ... ``` *** #### `voltages` [Section titled “voltages”](#voltages) A list of plugin definitions to return voltage in volts (V) per phase. **For example**: ```yaml voltages: # Voltage (V) per phase - source: # Phase 1 Plugin Type ... - source: # Phase 2 Plugin Type ... - source: # Phase 3 Plugin Type ... ... ``` # modbusproxy The `modbusproxy` setting is a list of devices that are exposed for third-party systems via Modbus TCP on the network. Some devices allow only a very limited number of Modbus TCP clients. In the worst case, only a single connection is allowed, as is the case with SolarEdge components. Additionally, in serial Modbus RTU RS485 bus systems, only one master is allowed. With the help of `modbusproxy`, it’s possible to set up evcc as a Modbus proxy that can share existing Modbus connections with other systems. This allows evcc to communicate directly with the device, while other systems communicate with evcc, which bundles the communication connections and forwards them to the target device. The `modbusproxy` configuration is a list of different proxy configurations. **For example**: ```yaml modbusproxy: - port: 5021 uri: 192.0.2.2:502 - port: 5022 device: /dev/ttyUSB0 baudrate: 9600 comset: "8N1" - port: 5023 uri: 192.0.2.3:502 rtu: true ``` Note *Incoming* (from third-party systems such as home automation, loggers), the proxy function exclusively supports Modbus TCP. *Outgoing* towards the target device to be queried (e.g., inverter, energy meter), the protocol may be translated according to the target device’s configuration. Sponsortoken required For more information about evcc sponsorship, please visit [the sponsorship page](/en/sponsorship). *** ## Required Parameters [Section titled “Required Parameters”](#required-parameters) ### `port` [Section titled “port”](#port) The local TCP/IP port under which a connection is provided as a proxy server, and from which incoming Modbus TCP connections from third-party systems are accepted. **For example**: ```yaml port: 5021 ``` ## Optional Parameters [Section titled “Optional Parameters”](#optional-parameters) ### `uri` [Section titled “uri”](#uri) The IP address and the port of the target device in common URI Scheme. Every provided port must be unique and not already in use by another application on the same host, however, it must not be different from the port of the target device. Therefore it is valid to define a configuration for port 502, which refers to port 502 on the target device. **For example**: ```yaml - port: 502 uri: 192.0.2.2:502 ``` ### `rtu` [Section titled “rtu”](#rtu) Modbus TCP is typically used for communication with network targets. If needed, you can switch to Modbus RTU over TCP by specifying `rtu: true`. A typical use case is for simple transparent RS485-TCP converters (without protocol translation). This must match the device’s configuration. It’s ignored for serial target systems. **For example**: ```yaml rtu: true ``` ### `readonly` [Section titled “readonly”](#readonly) By setting this parameter, you can prevent Modbus write accesses by third-party systems. **Possible values**: * `true`: Write access is blocked without response * `deny`: Write access is blocked with a modbus error as response * `false`: Write access is forwarded **For example**: ```yaml readonly: true ``` # mqtt Establishes connectivity with an MQTT broker. When the connection is active, evcc automatically pushes all internal values to the specified topic via the MQTT broker and also receives changes there. For more information, refer to the [`MQTT API`](/en/integrations/mqtt-api) documentation. *** ## MQTT without Encryption [Section titled “MQTT without Encryption”](#mqtt-without-encryption) **For example**: ```yaml mqtt: broker: localhost:1883 topic: evcc # root topic for publishing, set empty to disable publishing # clientid: foo # user: # password: ``` *** ## MQTT with TLS Encryption [Section titled “MQTT with TLS Encryption”](#mqtt-with-tls-encryption) **For example**: ```yaml # mqtt message broker mqtt: broker: tls://localhost:8883 topic: evcc # root topic for publishing, set empty to disable publishing # clientid: foo # user: # password: ``` When using TLS encryption (`tls://`), the broker’s TLS certificate is verified by default. If you’re using a self-signed certificate, there are two options: 1. Install the certificate system-wide (e.g. on Linux in `/etc/ssl/certs`) so that evcc uses it automatically 2. Disable certificate verification with `insecure: true` (see below) *** ## Required Parameters [Section titled “Required Parameters”](#required-parameters) ### `broker` [Section titled “broker”](#broker) Connection details (hostname/IP and port) of the MQTT broker to which evcc should connect as a client. ### `topic` [Section titled “topic”](#topic) Specifies the root topic that evcc uses. If not specified here, no MQTT communication can take place! *** ## Optional Parameters [Section titled “Optional Parameters”](#optional-parameters) ### `user` [Section titled “user”](#user) The username for authentication to the MQTT broker. ### `password` [Section titled “password”](#password) The authentication password for the MQTT broker. ### `clientid` [Section titled “clientid”](#clientid) Specifies a fixed MQTT client ID. By default, it will be assigned dynamically. ### `insecure` [Section titled “insecure”](#insecure) Disables TLS certificate verification when using `tls://`. **For example**: ```yaml mqtt: broker: tls://broker.example.com:8883 topic: evcc insecure: true ``` ### `caCert` [Section titled “caCert”](#cacert) CA certificate for broker certificate verification (certificate content). **For example**: ```yaml mqtt: broker: tls://broker.example.com:8883 topic: evcc caCert: | -----BEGIN CERTIFICATE----- MIIDXTCCAkWgAwIBAgIJAKZm... ... -----END CERTIFICATE----- ``` ### `clientCert` [Section titled “clientCert”](#clientcert) Client certificate for mutual TLS authentication (certificate content). Must be used together with `clientKey`. **For example**: ```yaml mqtt: broker: tls://broker.example.com:8883 topic: evcc clientCert: | -----BEGIN CERTIFICATE----- MIIDXTCCAkWgAwIBAgIJAKZm... ... -----END CERTIFICATE----- clientKey: | -----BEGIN PRIVATE KEY----- MIIEvQIBADANBgkqhkiG9w0B... ... -----END PRIVATE KEY----- ``` ### `clientKey` [Section titled “clientKey”](#clientkey) Private key of the client certificate (key content). Must be used together with `clientCert`. # site Describes the location with the existing and required devices of the home installation and is responsible for regulating the available power. To regulate charging with PV surplus, a readable meter directly behind the grid connection point is necessary. In addition, devices for PV power and house battery(ies) can also be specified. Several devices are automatically added in terms of power or, in the case of battery storage, the average state of charge is calculated. **For example**: ```yaml site: title: Home # display name for UI meters: grid: mygridmeter # grid meter reference pv: - mypv1 # first pv meter reference - mypv9 # second pv meter reference battery: - mybat5 # battery meter reference aux: - myaux1 # self-regulating consumer consumer: - myconsumer1 # regular consumer, recorded for consumption statistics ext: - myext1 # for data logging, load management, etc. residualPower: 100 ``` *** ## Required Parameters [Section titled “Required Parameters”](#required-parameters) ### `title` [Section titled “title”](#title) The description of the charging point is also displayed in the UI. **For example**: ```yaml title: Home ``` *** ### `meters` [Section titled “meters”](#meters) Defines which configured meter (current measurement devices) are to be used as what type of measurement point. This logically links the device definition with its intended use. A initially universal meter is thus assigned a purpose based on its location within the home installation. Note At least the configuration of one `grid` or at least one `pv` element is necessary! evcc cannot be used without at least one of these entries! **For example**: ```yaml site: meters: grid: mygridmeter # grid meter reference pv: mypv1 # pv meter reference battery: mybat2 # battery meter reference aux: myaux1 ``` *** ## Optional Parameters [Section titled “Optional Parameters”](#optional-parameters) ### `meters.grid` [Section titled “meters.grid”](#metersgrid) Defines the [`meter`](/en/reference/configuration/meters) (current measurement device) that provides the measurements of the grid connection point. **Possible values**: Value of a `name` parameter in the [`meters`](#meters) configuration. **For example**: ```yaml grid: mygridmeter # grid meter reference ``` *** ### `meters.pv` [Section titled “meters.pv”](#meterspv) Defines [`meter`](/en/reference/configuration/meters) (current measurement devices), from which evcc fetches PV generation measurements. Multiple devices can be specified. Power data is automatically added. **Possible values**: A single value or a list of values of a name parameter in the [`meters`](#meters) configuration. The list version can also be used with single values. **For example**: ```yaml pv: myonlypv # single pv meter reference ``` or ```yaml pv: # (pvs = deprecated) - myoldpv # first pv meter reference - mynewestpv # second pv meter reference ``` *** ### `meters.battery` [Section titled “meters.battery”](#metersbattery) Defines the [`meter`](/en/reference/configuration/meters) (current measurement devices) that provide measurement data from the battery(ies). Multiple devices can be specified. Power data is automatically added, and an average is calculated from the battery state of charge. **Possible values**: A single value or a list of values of a `name` parameter in the [`meters`](#meters) configuration. The list version can also be used with single values. **For example**: ```yaml battery: myonlybat # single battery meter reference ``` or ```yaml battery: # (batteries = deprecated) - mysmallbat # first battery meter reference - myhugebat # second battery meter reference ``` ### `meters.aux` [Section titled “meters.aux”](#metersaux) Meters for external devices that run their own surplus control but aren’t directly controlled by evcc, e.g. a self-regulating immersion heater. Their power counts toward the available surplus for vehicle charging, on the assumption that the device reduces its consumption when evcc allocates that power to charging. Multiple meters are added up. **Possible values**: A single value or a list of values of a `name` parameter in the [`meters`](#meters) configuration. The list version can also be used with single values. **Example**: ```yaml aux: myaux # single aux meter reference ``` or ```yaml aux: - myaux1 # first aux meter reference - myaux2 # second aux meter reference ``` ### `meters.consumer` [Section titled “meters.consumer”](#metersconsumer) Meters for regular consumers such as a washing machine or dishwasher, recorded for consumption statistics only. Unlike `aux`, this power isn’t factored into the available surplus for vehicle charging. **Possible values**: A single value or a list of values of a `name` parameter in the [`meters`](#meters) configuration. The list version can also be used with single values. **Example**: ```yaml consumer: myconsumer # single consumer meter reference ``` or ```yaml consumer: - myconsumer1 # first consumer meter reference - myconsumer2 # second consumer meter reference ``` ### `meters.ext` [Section titled “meters.ext”](#metersext) Meters that aren’t used for regulation or shown in the UI, e.g. sub-distributions or alternative grid or solar meters. Their data is only logged and exported, not factored into surplus or consumption statistics. **Possible values**: A single value or a list of values of a `name` parameter in the [`meters`](#meters) configuration. The list version can also be used with single values. **Example**: ```yaml ext: myext # single ext meter reference ``` or ```yaml ext: - myext1 # first ext meter reference - myext2 # second ext meter reference ``` ### `residualPower` [Section titled “residualPower”](#residualpower) Sets the target operating point of the surplus regulation at the grid connection (grid meter). The default value is 0 W. Positive values shift the target value towards grid feed-in, while negative values shift it towards grid consumption. Ultimately, this value sets the “idle state” of the control loop that needs to be adjusted by the controller. Especially in combination with other independent surplus regulation systems like a battery storage, this value must be adjusted to achieve a defined system behaviour with clear priorities. If a certain proportion of grid consumption should remain or be allowed in PV mode, a negative value corresponding to the maximum proportion of grid consumption can be configured. #### `grid` `meter` present [Section titled “grid meter present”](#grid-meter-present) * Positive value: Remaining grid feed-in power * Negative value: Remaining grid consumption power #### Only `pv` `meter` present [Section titled “Only pv meter present”](#only-pv-meter-present) * Positive value: Typical household consumption, used to estimate PV surplus. * Negative value: The specified power is added to PV power and increases available charging power (Attention: grid consumption) Note When a battery storage is present, it is strongly recommended to enter a small value, e.g. between 100 to 300 W here, allowing battery charging according to configured priorities (see `prioritySoc`). Otherwise, the independent regulation of the storage will not see usable surplus. Likewise, this prevents temporary grid consumption even without a battery during rapid generation and load changes. **Example “Battery Storage”**: ```yaml residualPower: 100 ``` **For example “Grid Consumption Proportion”**: Charging should start in PV mode with at least 6A (single-phase) even with only 50% PV surplus (rest from grid). Minimum charging power: 1 phase \_ 6A \_ 230V = 1380 W, 50% of it: 690 W See also the [alternative using enable/disable to allow proportional PV and grid consumption](/en/features/solar-charging). ```yaml residualPower: -690 ``` # sponsortoken `sponsortoken` defines a token that is provided on . Tip We recommend entering the sponsor token via the web interface under **Configuration**. **For example**: ```yaml sponsortoken: eyJhbGci[...]RX5s # your token from sponsor.evcc.io ``` # tariffs You can specify your energy tariff and, if applicable, your feed-in tariff. evcc uses these values for a rough [savings calculation](/en/faq#statistical-data) that is displayed in the web UI. This data is also used by the [planner](/en/features/plans) for price and CO₂-optimized charging. **Structure** ```yaml tariffs: grid: type: ... feedin: type: ... co2: type: ... ``` **For example: Constant Energy Price** ```yaml tariffs: currency: EUR # (default EUR) grid: # static grid price type: fixed price: 0.294 # [currency]/kWh feedin: # rate for feeding excess (pv) energy to the grid type: fixed price: 0.08 # [currency]/kWh ``` More examples and a list of available providers can be found in the section [Tariffs](/en/tariffs). ## Time-Based Grid Fees [Section titled “Time-Based Grid Fees”](#charges-zones) Use `charges` to add a fixed fee per kWh to every price value. If your grid operator bills time-dependent grid fees (e.g. time-variable network charges according to § 14a EnWG in Germany), use `chargesZones` to override the default `charges` for specific periods. This works with any grid tariff, no matter if it uses a provider template, a `fixed` price or a `custom` source. Each zone has the following fields: | Field | Required | Description | | --------- | -------- | --------------------------------------------------------- | | `charges` | yes | Fee per kWh in this zone. Replaces the default `charges`. | | `months` | no | e.g. `Nov-Mar` or `Jun`. Empty means all year. | | `days` | no | e.g. `Mon-Fri` or `Sat,Sun`. Empty means every day. | | `hours` | no | e.g. `17-20` or `15:30-21`. Empty means all day. | **Example**: ```yaml tariffs: grid: type: template template: tibber token: "..." charges: 0.0941 # default grid fee per kWh chargesZones: - months: Nov-Mar days: Mon-Fri hours: 17-20 charges: 0.1838 # peak - hours: 0-6 charges: 0.0299 # low ``` If no zone matches, the default `charges` applies. If zones overlap, the last matching zone wins. When a `formula` is configured, the `charges` variable contains the zone value of the respective time slot. A `fixed` tariff with `chargesZones` is treated like a dynamic tariff: the planner prefers cheap periods and the price chart is shown. ## Feature Flags [Section titled “Feature Flags”](#feature-flags) For custom tariffs (`type: custom`) you can influence behaviour via `features`: | Feature | Description | | --------- | ---------------------------------------------------------------------------------------------- | | average | Smooths fine-grained price slots (e.g. 15-minute values) into hourly averages. | | cacheable | Persists fetched values. Used as fallback after a restart or provider outage (up to 24 hours). | **Example**: ```yaml tariffs: grid: type: custom features: - cacheable # ... additional attributes ``` # telemetry Since version 0.103 [Sponsor token required](/en/sponsorship) The `telemetry` option enables the regular transmission of charging data (power, energy, solar share) to evcc.io. No personal data or configuration details are transmitted. You can learn more about this in the [Privacy Policy](https://sponsor.evcc.io/privacy). The aggregated data is displayed on platforms like [evcc.io](https://evcc.io). You can access the raw data through . **For example**: ```yaml telemetry: true # default: false ``` # network Defines the IP address or hostname and port on which the web interface should be accessed. **Example**: ```yaml network: # schema is the HTTP schema # setting to `https` does not enable https, it only changes the way URLs are generated schema: http # host is the hostname or IP address # if the host name contains a `.local` suffix, the name will be announced on MDNS # docker: MDNS announcements don't work. host must be set to the docker host's name. host: evcc.local # port is the listening port for UI and api # evcc will listen on all available interfaces port: 7070 # externalUrl is the URL you use to access evcc in your browser # used for autodiscovery by the evcc app and by services/devices connecting to evcc # if you're running evcc behind a reverse proxy, use that URL, e.g. "https://evcc.example.com" (requires authentication at the proxy) externalUrl: https://evcc.local ``` # vehicles A vehicle represents a specific electric vehicle (EV) with its battery. When a vehicle is configured and assigned to a [charger](/en/reference/configuration/loadpoints#vehicle), the user interface can display the charging status, state of charge (SoC), remaining charging time, and other data automatically retrieved and processed from the vehicle. It is also possible to limit the charge to a specific state of charge (SoC, UI only). Since most chargers cannot be aware of this (it is only transmitted in very specific charger combinations), evcc can communicate directly with the vehicle through the online interface (API) of the vehicle manufacturer using this configuration. The `vehicles` configuration is a list of different vehicles. **For example**: ```yaml vehicles: - name: Zoe type: ... ... ``` Configurations for known vehicles can be found under [Devices - Vehicles](/en/vehicles). Below, the various parameters are explained. *** ## Required Parameters [Section titled “Required Parameters”](#required-parameters) ### `name` [Section titled “name”](#name) A short designation of the configured vehicle. The value is used when referencing the vehicle in the configuration of the [charger](/en/reference/configuration/loadpoints#vehicle). **For example**: ```yaml name: zoe ``` *** ### `title` [Section titled “title”](#title) A description of the vehicle that will be displayed in the user interface. **For example**: ```yaml title: Zoe ``` *** ### `type` [Section titled “type”](#type) This is the evcc interface type that allows communication with the vehicle. Known vehicles can be integrated using the `template` type. The appropriate (template) type for known vehicles and instructions for manual configuration `custom` can be found under [Devices - Vehicles](/en/vehicles). *** ## Optional Parameters [Section titled “Optional Parameters”](#optional-parameters) ### `capacity` [Section titled “capacity”](#capacity) The usable capacity of the vehicle’s battery in kilowatt-hours (kWh). Used to calculate the energy requirement for charging planning. **For example**: ```yaml capacity: 50 # kWh ``` *** ### `phases` [Section titled “phases”](#phases) The *maximum* number of phases this vehicle can use (possibly including the charging cable). The default internal value is 3. Possible values are 1, 2, or 3. Some vehicles, especially plug-in hybrids, do not use the maximum possible 3 phases for charging. While `evcc` can determine the actually used phases at the start of a charging process, if a charge meter is installed, this information is not available before charging starts. By configuring the `phases` parameter on the vehicle, `evcc` can start the charging process with a lower available power in PV mode. **For example**: ```yaml phases: 2 ``` *** ### `cache` [Section titled “cache”](#cache) The retention time and suppression duration of external requests to the vehicle data interface (API). Note The value must be specified with the attached time unit (see example). `m` stands for minutes. Caution It is **NOT** recommended to change the default settings, as this could lead to the vehicle manufacturer actively preventing charging control via evcc. **AT YOUR OWN RISK.** To determine current status data from the vehicle (e.g., state of charge SoC of the traction battery), the manufacturer’s interface is regularly queried online. However, to avoid overwhelming the vehicle manufacturer’s servers with constant requests (which could result in account suspension), a cache is implemented that intercepts these requests and responds with the recently retrieved data up to the maximum age indicated here. Since most vehicles update the data only during a running charging process at very large intervals (10 to 30 minutes are common), more frequent requests don’t provide added value. **Default Value:** `15m` **For example**: ```yaml cache: 5m ``` *** ### `identifiers` [Section titled “identifiers”](#identifiers) A list of one or more identifiers to identify the vehicle. If the vehicle needs to be identified at different chargers, multiple identifiers might be necessary. Identification can be achieved using the following mechanisms: #### RFID [Section titled “RFID”](#rfid) If the charger has an RFID interface, an RFID card can be assigned to a vehicle for identification. In this case, the `RFID Token ID` is required. **For example**: ```yaml identifiers: - 12345ABC # RFID token ID ``` Note: in case the identifier might be interpreted as a number, quoting is mandatory **For example**: ```yaml identifiers: - "012345" - "12345e2" - "0x1234" ``` #### Vehicle Identifier [Section titled “Vehicle Identifier”](#vehicle-identifier) If the charger supports it, it receives a vehicle identifier from the vehicle. This can be either the MAC address of the onboard charger or an identifier of a permanently installed Plug & Charge certificate (a different certificate than for DC charging!). **For example**: ```yaml identifiers: - 01:23:45:67:89:0A # MAC address ``` Some vehicles generate a new MAC address every day. In this case, wildcards can be used if the existing vehicles differ in the non-changing part of the MAC address. ```yaml identifiers: - 01:23:45:* ``` *** ### `features: ["coarsecurrent"]` [Section titled “features: \["coarsecurrent"\]”](#features-coarsecurrent) Indicates that a vehicle cannot be regulated with continuous current limitation. This setting should be used for the following combination: * Vehicle can only regulate in whole ampere steps * charger can process finer-grained charging current specifications (e.g., 1 mA) In this combination, it can happen that changes of a few mA in current result in an unexpected change of the phase current by 1A for regulation. The regulation may then start to oscillate. This feature also limits the regulation to coarse 1A steps. It CANNOT be used in conjunction with a vehicle template. To use it, the vehicle must be configured as a native type. **For example**: ```yaml features: ["coarsecurrent"] ``` *** ### `icon` [Section titled “icon”](#icon) Vehicles can be displayed with different icons in the UI. The available options are: * car * bike * scooter * moped * motorcycle * van * bus * tractor * generic * heater * cooler * waterheater **For example**: ```yaml icon: heater ``` *** # Modbus Some devices, such as meters ([`meters`](/en/reference/configuration/meters#modbus)) or chargers ([`chargers`](/en/reference/configuration/chargers)), are connected and addressed using the Modbus protocol. The `meter` configuration includes the type of physical connection (interface), optional technical interface parameters, the Modbus protocol used, the unique Modbus ID of the device on the bus, and the number and type of the register to be read or written. It is important to note that there are three different Modbus protocols: Modbus RTU, Modbus ASCII, and Modbus TCP. These can technically be transmitted over different types of interfaces. The classic version is Modbus RTU over a serial RS485 bus interface, commonly used with most meters or some chargers. Devices with a native network interface (Ethernet/WiFi), on the other hand, are typically addressed using the Modbus TCP protocol. If a serial Modbus device needs to be connected through an interface converter via a network (Ethernet/WiFi/PowerLAN), Modbus RTU protocol over a TCP/IP connection is established. The Modbus RTU protocol is directly transmitted over the network (i.e., “tunnelled”). Even though the transport method (TCP/IP) is the same, the protocol is NOT the same as Modbus TCP. It’s essential to distinguish between the protocol and the transport method. “Modbus (RTU) over TCP” is different from Modbus TCP! Caution Caution: There are more complex interface converters that can optionally translate the Modbus protocol itself between Modbus RTU and Modbus TCP! If this feature is active, evcc must communicate with the converter using Modbus TCP, while the converter communicates with the serial device via Modbus RTU and bidirectionally translates the two protocols. In this case, careful attention must be paid to the device specification and configuration; otherwise, communication might not work! In the case of a configuration with an interface converter, the serial bus configuration is determined only on the converter. The evcc configuration then concerns only the section up to the converter. ## Physical Connection [Section titled “Physical Connection”](#physical-connection) ### Serial Connection (RS485) [Section titled “Serial Connection (RS485)”](#serial-connection-rs485) If the device is directly connected via an RS485 adapter (Modbus RTU), `device` and the serial communication parameters `baudrate` and `comset` must be specified according to the device configuration. Please refer to the respective user manual, data sheets, or system settings. Note Multiple devices with identical communication parameters can be operated on a serial RS485 bus if each device is assigned a unique Modbus ID. If not all devices on a bus can be configured with uniform communication settings (but with different IDs), splitting into multiple independent bus systems is necessary. Caution Mixing devices with different serial communication parameters on a bus is not possible and leads to unpredictable communication errors. **For example**: ```yaml source: modbus id: 1 device: /dev/ttyUSB0 baudrate: 38400 comset: "8E1" ``` ### Direct Network Connection [Section titled “Direct Network Connection”](#direct-network-connection) If the device is directly connected via a native network connection (Modbus TCP), a `uri` consisting of HOSTNAME:PORT or IP:PORT must be provided: **For example**: ```yaml source: modbus id: 1 uri: 192.168.0.11:502 ``` ### Serial Device via Network Connection (with Interface Converter) [Section titled “Serial Device via Network Connection (with Interface Converter)”](#serial-device-via-network-connection-with-interface-converter) If a serial device is connected via an intermediate transparent RS485-IP interface converter (without protocol translation), the protocol must also be switched to Modbus RTU over the TCP/IP connection using `rtu: true`. **For example**: ```yaml source: modbus id: 1 uri: 192.168.0.10:502 rtu: true # Modbus RTU over TCP ``` ## Predefined Devices [Section titled “Predefined Devices”](#predefined-devices) The integrated predefined device models `model` are identical to [MBMD](https://github.com/volkszaehler/mbmd/blob/master/docs/mbmd_run.md#options): ```plaintext ABB ABB A/B-Series meters DDM DDM18SD DZG DZG Metering GmbH DVH4013 meters IEM3000 Schneider Electric iEM3000 series INEPRO Inepro Metering Pro 380 JANITZA Janitza meters MPM Bernecker Engineering MPM3PM meters ORNO1P ORNO WE-514 & WE-515 ORNO1P504 ORNO WE-504 ORNO3P ORNO WE-516 & WE-517 SBC Saia Burgess Controls ALE3 meters SDM Eastron SDM630/120/72DMv2 SDM220 Eastron SDM220 SDM230 Eastron SDM230 SDM72 Eastron SDM72 SEMTR SolarEdge SE-MTR-3Y ``` Any `model` that deviates from these is treated as a *SunSpec* device type. Use `value` to define the value to be read from the device. All supported values are predefined in [MBMD](https://github.com/volkszaehler/mbmd/blob/master/meters/measurements.go#L28). In the case of a *SunSpec*-compatible inverter or meter, the values to be read are specified in the format `model:[block:]point` according to the *SunSpec* definition. For example, querying the DC power on the second string of a three-phase PV inverter (corresponding to SunSpec Model 103) is done as follows: `value: 103:2:W`. The device `model` and the slave ID `id` are always required: **For example**: ```yaml source: modbus --- model: sdm value: Power scale: -1 # floating point factor applied to result, e.g. for kW to W conversion ``` ## Value Negation [Section titled “Value Negation”](#value-negation) For MBMD meters, measurement values can be inverted by prefixing the alias name with a `-` (minus sign). This is useful when meters are used in different configurations or mounting orientations and the sign of measurement values needs to be adjusted. ### Supported Measurements [Section titled “Supported Measurements”](#supported-measurements) Negation works for the following MBMD measurements: * `power` - Total power * `currents` - Currents per phase (array) * `powers` - Powers per phase (array) ### Syntax [Section titled “Syntax”](#syntax) ```yaml meters: - name: my-meter type: modbus model: sdm power: -Power # inverts the power value ``` ### Examples [Section titled “Examples”](#examples) #### Inverted Total Power [Section titled “Inverted Total Power”](#inverted-total-power) ```yaml meters: - name: pv-meter type: modbus model: sdm power: -Power # Power will be inverted (e.g. +1000 W becomes -1000 W) ``` #### Inverted Phase Powers [Section titled “Inverted Phase Powers”](#inverted-phase-powers) ```yaml meters: - name: grid-meter type: modbus model: sdm power: Power powers: - -PowerL1 # Phase 1 inverted - -PowerL2 # Phase 2 inverted - -PowerL3 # Phase 3 inverted ``` #### Inverted Currents (Individual Phases) [Section titled “Inverted Currents (Individual Phases)”](#inverted-currents-individual-phases) ```yaml meters: - name: grid-meter type: modbus model: sdm power: Power currents: - -CurrentL1 # Current Phase 1 inverted - CurrentL2 # Current Phase 2 normal - -CurrentL3 # Current Phase 3 inverted ``` ### Use Cases [Section titled “Use Cases”](#use-cases) **Incorrectly Mounted Meters**: If a current sensor/meter is physically installed in the wrong direction, you can correct the values in software. **Grid Feed-in vs. Consumption**: For solar meters where the sign convention needs to be reversed. **Different CT Orientations**: For multi-phase installations with differently oriented current transformers. ## Manual Configuration [Section titled “Manual Configuration”](#manual-configuration) If the Modbus device is not directly supported or if values deviating from the predefined models are to be read or written, the Modbus registers can also be configured manually. For this purpose, in addition to the general ‘modbus’ settings (see above), a `register` must be defined instead of a `value`, as with predefined devices. It is not allowed to specify both `value` and `register`. The definition of a register requires the following parameters: * `address`: the register address * `type`: The register type, allowed read types are `coil`, `input`, `holding`, write types are `writeholding`, `writeholdings`, `writecoil` * `decode`: The type of encoding of the data. Allowed are: `int16|32|64, uint16|32|64, float32|64 and u|int32s + float32s`. For type `coil` the encoding is ignored, but must still be specified. For type `writecoil`, `bool8` must be specified. * `bitmask`: An optional specification. The specified value is ANDed with the read value to extract individual bits. Other allowed parameters of a manual configuration are: * `scale`: Floating point number that can be used to convert read values (e.g. W to kW or vice versa). This value is multiplied with the read and decoded raw value. * `timeout`: modbus timeout. Without unit the value is in ns, otherwise specify unit, e.g. 10s for 10 seconds. **For example**: ```yaml source: modbus --- register: address: 40070 type: holding # coil, holding or input decode: int32 # int16|32|64, uint16|32|64, float32|64 and u|int32s + float32s bitmask: 2 # Optional: a bitmask that is applied to the read value. Here the mask is 0000000000000010b, ignored if value is 0 scale: -1.0 # floating point factor applied to result, e.g. for kW to W conversion timeout: 2s # timeout, without unit in ns ``` For the `int32s/uint32s` decodings, the byte order is swapped, which is useful for E3/DC devices. ### Writing Registers [Section titled “Writing Registers”](#writing-registers) Both holding registers and coils can be written. For this, either `type: writeholding` for holding registers or `type: writecoil` for coils must be specified. For writing multiple registers (function code 16) the type `writeholdings` is available. `type: writeholding` always writes a 16-bit register (int or bool16). Therefore, for `decode`, `uint16` must always be specified. `type: writecoil` writes a coil. For `decode`, `bool8` must be specified. **For example**: ```yaml source: modbus --- register: address: 40070 type: writeholding # writeholding, writeholdings or writecoil ``` ### Complete Example [Section titled “Complete Example”](#complete-example) A complete example for a custom charger with modbus interface (here a Phoenix EM-CP-PP-ETH with the IP address 192.168.1.10) could look like this: **For example**: ```yaml chargers: - type: custom name: CustomCharger status: # Read the status of the charger # Either A,B,C or F source: modbus id: 180 uri: 192.168.1.10:502 timeout: 3s register: address: 100 type: input # Read an input register decode: int16 enabled: # Is the charger enabled (1) or not (0) source: modbus id: 180 uri: 192.168.1.10:502 register: address: 400 type: coil # Read a coil decode: bool16 # Doesn't matter but required enable: # Enable the charger source: modbus id: 180 uri: 192.168.1.10:502 register: address: 400 type: writecoil # Write a coil decode: bool8 maxcurrent: # Set the maximum current source: modbus id: 180 uri: 192.168.1.10:502 register: address: 300 type: writeholding # Write a holding register decode: uint16 ``` # Plugins Plugins read and write individual values on a device, e.g. a single power reading, a target current, an enable command. They power the bundled device templates and are referenced directly when you build a [user-defined device](/en/user-defined-devices) of `type: custom`. Plugins can be used for the following categories: * `meter`: [PV, battery, grid, meters](/en/meters) * `charger`: [Wallboxes](/en/chargers), [Smart switches](/en/smartswitches), [Heat pumps, electric heaters](/en/heating) * `vehicle`: [Vehicles](/en/vehicles) * `tariff`: [Tariffs, forecasts](/en/tariffs) * `circuit`: [Load management](/en/features/loadmanagement) Plugins are also used by [notifications](/en/notifications) to send lifecycle events. ### Plugin list [Section titled “Plugin list”](#plugin-list) * [GPIO Plugin](#gpio) - Plugin for direct access to GPIO pins (Linux only). * [Go Plugin](#go) - Plugin that provides or receives values via a Go script. * [HTTP Plugin](#http) - Plugin that communicates with end devices via HTTP API. * [JavaScript Plugin](#javascript) - Plugin that provides or receives values via a JavaScript script. * [Modbus Plugin](#modbus) - Plugin for reading from a Modbus-capable device. * [MQTT Plugin](#mqtt) - Plugin for indirectly communicating with MQTT-capable devices via MQTT. * [Prometheus Plugin](#prometheus) - Plugin for reading metrics from Prometheus using PromQL. * [Shell Plugin](#shell) - Plugin that can execute a shell script to extract data or receive data for writing. * [SMA/Speedwire Plugin](#speedwire) - Plugin specifically for SMA devices that can communicate with the Speedwire protocol. * [Websocket Plugin](#websocket) - Plugin for receiving device data via its own web server. Can only be used for reading data. ### Helper list [Section titled “Helper list”](#helper-list) * [Calc Plugin](#calc) - Meta-plugin for arithmetically linking outputs from other plugins. * [Combined Plugin](#combined) - Meta-plugin specifically for `charger` to combine the boolean status values for the connected (*plugged*) and charging (*charging*) state into a single charging status. * [Const Plugin](#const) - Special plugin that simply returns a constant value. * [Error Plugin](#error) - Special plugin that returns a known error value. * [Convert Plugin](#convert) - Meta-plugin for data type conversion when writing (e.g., float to int). * [Delta Plugin](#delta) - Meta-plugin for converting absolute values to delta/increment values when writing. * [Ignore Plugin](#ignore) - Meta-plugin for suppressing specific error messages. * [IfElse Plugin](#ifelse) - Meta-plugin for conditional write operations with two branches (if/else). * [Map Plugin](#map) - Meta-plugin for translating integer values (e.g., device-specific modes to evcc modes). * [Meter Plugin](#meter-plugin) - Plugin to use another meter as a data source. * [Sequence Plugin](#sequence) - Meta-plugin for sequential execution of multiple write operations. * [Sleep Plugin](#sleep) - Helper plugin for delaying actions (usually used with Sequence). * [Switch Plugin](#switch) - Meta-plugin for conditional write operations based on input values (like switch/case). * [Valid Plugin](#valid) - Meta-plugin for providing plugin values based on boolean validation. * [Watchdog Plugin](#watchdog) - Meta-plugin for automatically repeating write operations at regular intervals. ## Syntax [Section titled “Syntax”](#syntax) A plugin attaches to an attribute of a device. The attribute name (e.g. `power`, `enable`, `soc`) determines the role; the `source` selects the plugin type; the remaining keys are plugin-specific parameters. ```yaml : source: : ... : ... ``` Each plugin is used in either a **reading** or a **writing** context. Some parameters only make sense in one of the two. For the full attribute lists of meters, chargers, vehicles and tariffs, see [user-defined devices](/en/user-defined-devices). []() ### Reading [Section titled “Reading”](#reading) When reading data using a plugin, so-called *pipelines* can be used. These allow data to be extracted in a fine-grained manner from the plugin’s output. This makes it possible to process complex data structures such as JSON or XML and filter out the required information. Possible parameters for data extraction are: * `regex`: A regular expression to extract values from the received text. * `jq`: A [jq](https://jqlang.github.io/jq/)-expression to extract values from JSON structures. The full syntax and possibilities can be found in the jq documentation. * `quote`: Boolean value that wraps the input data in quotes before passing it to jq. This allows jq to process unquoted strings (e.g. from MQTT). For an MQTT value like `Charging`, you can use `quote: true` and `jq: '. == "Charging"'`. * `unpack`: Converts values from other number representations, e.g. `hex`. * `decode`: Decodes binary formats like `uint32`, `float32` etc. []() #### Known error values [Section titled “Known error values”](#known-error-values) [HTTP](#http), [MQTT](#mqtt), and [Websocket](#websocket) plugins can return special error strings. evcc recognises these and converts them into internal error codes instead of treating them as data. This is useful e.g. for custom vehicle integrations where the data source knows the vehicle’s state. * `ErrAsleep`: Vehicle is asleep. evcc may choose to wake up the vehicle and retry. * `ErrMustRetry`: Operation should be retried (e.g. due to rate limiting). * `ErrNotAvailable`: Value is not available. evcc treats this as a permanent error until the next restart. If a plugin returns the string `ErrAsleep` as its response, evcc generates the corresponding internal error. The [Error Plugin](#error) uses the same mechanism to return a fixed error value as a constant. []() ### Writing [Section titled “Writing”](#writing) When writing, parameters in the configuration can be replaced by placeholders. The data is provided in the form `${var[:format]}`. If format is not specified, the data is provided in the standard %v Go format. The variables are replaced with the corresponding value before the plugin is executed. Additionally, all functions of the Go Template Library can be used to perform more complex data transformations. ## Plugins [Section titled “Plugins”](#plugins) []() ### GPIO read write [Section titled “GPIO ”](#gpio--) The `gpio` plugin enables direct access to GPIO pins (General Purpose Input/Output) on Linux systems. It is particularly suitable for Raspberry Pi and similar single-board computers. **Parameters**: | Parameter | Type | Required | Description | | --------- | ------ | -------- | ---------------------------------------- | | function | string | yes | Mode: `read` (input) or `write` (output) | | pin | int | yes | Pin number (BCM numbering, e.g. GPIO 17) | **How it works**: * **Reading** (`function: read`): Reads the state of a GPIO pin as a boolean value (`true` = HIGH, `false` = LOW) * **Writing** (`function: write`): Sets a GPIO pin to HIGH (`true`) or LOW (`false`) Pin numbering follows the BCM scheme (Broadcom numbers, not the physical pin position). For a Raspberry Pi pinout, see e.g. [pinout.xyz](https://pinout.xyz/). **Reading Example**: ```yaml source: gpio function: read pin: 17 # BCM pin number ``` **Writing Example**: ```yaml source: gpio function: write pin: 27 # BCM pin number ``` Note This plugin only works on Linux systems with access to `/dev/gpiomem`. []() ### Go read write [Section titled “Go ”](#go--) The `go` plugin uses the [Yaegi](https://github.com/traefik/yaegi) interpreter to execute Go code at runtime. It’s particularly useful for type-safe calculations and complex data processing logic. #### Available Go Standard Libraries [Section titled “Available Go Standard Libraries”](#available-go-standard-libraries) The following Go packages are automatically available and don’t need to be imported: * `fmt` - Formatted I/O * `math` - Mathematical functions * `strings` - String manipulation * `time` - Time and date functions **Reading Example**: ```yaml source: go script: | res := 500.0 res * 2 // returns 1000.0 ``` **Example with Time Functions**: ```yaml source: go script: | hour := time.Now().Hour() price := 50.0 // Night tariff if hour >= 9 && hour < 17 { price = 100.0 // Tariff price during business hours } price ``` **Example with String Processing**: ```yaml source: go script: | text := "hello world" strings.ToUpper(text) // returns "HELLO WORLD" ``` When the `go` plugin is used for writing, the value to be written is passed to the script as a variable: **Writing Example**: ```yaml maxcurrent: source: go script: | fmt.Printf("Setting charge current: %d A\n", maxcurrent) // maxcurrent variable is automatically available ``` []() #### Input and Output Transformations [Section titled “Input and Output Transformations”](#input-and-output-transformations) The `go` and `js` plugins support `in` and `out` parameters to use values from other sources as variables in the script or to forward the script result to other plugins. ##### Input Transformations (`in`) [Section titled “Input Transformations (in)”](#input-transformations-in) The `in` parameter allows you to use values from other sources as variables in your script. Each entry requires `name` (variable name in the script), `type` (`bool`, `int`, `float`, `string`) and `config` (plugin configuration). This example shows conditional logic that cannot be achieved with simple Calc operations: ```yaml power: source: go script: | // Power based on SoC and standby power := 5000.0 // normal if standby { power = 0.0 // no load in standby } else if soc < 20.0 { power = 1000.0 // low } power in: - name: soc type: float config: source: const value: 85.0 - name: standby type: bool config: source: const value: false ``` ##### Output Transformations (`out`) [Section titled “Output Transformations (out)”](#output-transformations-out) The `out` parameter forwards the script result to other plugins. This is particularly useful in a writing context, e.g. when the script result should be further processed via MQTT or HTTP. Each entry requires `name`, `type` and `config`, analogous to `in`. ```yaml maxcurrent: source: go script: | watts := maxcurrent * 230 watts out: - name: watts type: float config: source: mqtt topic: heater/target_power ``` []() ### HTTP read write [Section titled “HTTP ”](#http--) The `http` plugin performs HTTP calls to read or update data. It also includes the ability to read or perform simple transformations on JSON data structures via jq queries (e.g. for REST APIs). The full functionality can be found in the [official jq documentation](https://jqlang.github.io/jq/manual/). Authentication methods are `basic`, `bearer` and `digest`. The names of the respective parameters can be found [here](https://github.com/evcc-io/evcc/blob/master/plugin/http_auth.go#L23). #### Authentication [Section titled “Authentication”](#authentication) Various authentication methods are available for HTTP requests: **Basic Authentication**: ```yaml auth: type: basic user: password: ``` **Bearer Token** (e.g. for JWT): ```yaml auth: type: bearer token: ``` **Digest Authentication**: ```yaml auth: type: digest user: password: ``` **Custom Authentication**: For more complex authentication scenarios, custom authentication plugins can be developed. These are integrated via the `source` parameter: ```yaml auth: source: user: password: # additional plugin-specific parameters ``` This allows integration of devices with special authentication requirements without having to modify the entire HTTP plugin code. Important XML documents are automatically converted to JSON format internally, which can then be filtered with jq like a native JSON response. Attributes get the prefix `attr`. Tip For testing jq queries, online tools like [jqplay.org](https://jqplay.org/) are useful. For regex tests, [regex101.com](https://regex101.com/) is a good option. **Reading Example**: ```yaml source: http uri: https://volkszaehler/api/data/.json?from=now method: GET # default HTTP method headers: - content-type: application/json auth: # basic authentication type: basic user: foo password: bar insecure: false # set to true to trust self-signed certificates jq: .data.tuples[0][1] # parse response json scale: 0.001 # factor applied to result, e.g. for kW to W conversion cache: 60s # response cache duration timeout: 10s # timeout in golang duration format, see https://golang.org/pkg/time/#ParseDuration ``` ```yaml source: http uri: http://charger/status jq: .total_power > 10 # Converts a json integer to a boolean value ``` **Writing Example**: ```yaml body: %v # only applicable for PUT or POST requests ``` ```yaml enable: source: http uri: "http://charger/relay/0?turn={{if .enable}}on{{else}}off{{end}}" ``` []() ### JavaScript read write [Section titled “JavaScript ”](#javascript--) evcc integrates a JavaScript interpreter with the [Underscore.js](https://underscorejs.org) library, which is directly accessible via `_.`, e.g. `_.random(0,5)`. The `js` plugin can execute JavaScript code via the `script` parameter. Very helpful for rapid prototyping: **Reading Example**: ```yaml source: js script: | var res = 500; 2 * res; // returns 1000 ``` When the `js` plugin is used for writing, the value to be written is passed to the script as a variable: **Writing Example**: ```yaml maxcurrent: source: js script: | console.log(maxcurrent); ``` The `js` plugin supports the same [input and output transformations](#transformations) (`in`/`out`) as the `go` plugin. []() ### Modbus read write [Section titled “Modbus ”](#modbus--) The `modbus` plugin can read data from any Modbus-capable device or SunSpec-compatible inverter. Many power meters are already pre-configured (see [MBMD Supported Devices](https://github.com/volkszaehler/mbmd#supported-devices)). It’s also possible to write Modbus registers to integrate additional wallboxes. **Example**: ```yaml source: modbus id: 1 uri: 192.168.1.10:502 register: address: 300 type: holding decode: uint16 ``` See the [Modbus Documentation](/en/reference/modbus) for more details. []() ### MQTT read write [Section titled “MQTT ”](#mqtt--) The `mqtt` plugin enables reading values via MQTT topics. This is particularly useful for power meters, e.g. when they already provide their data via MQTT. See the [MBMD Documentation](https://github.com/volkszaehler/mbmd) for an example of how to get Modbus measurement data into MQTT. **Parameters (Reading)**: | Parameter | Type | Required | Description | | --------- | -------- | -------- | --------------------------------------------------------------- | | topic | string | yes | MQTT topic to read from | | timeout | duration | no | Maximum age of received values | | scale | float | no | Scaling factor for result (e.g. 0.001 for Wh to kWh conversion) | The plugin returns an error if no new value has been received within the `timeout` duration. If `timeout` is not set, values of any age are accepted once the first message has been received. It is recommended to set a timeout to detect when the source is no longer providing current data. For data extraction, the pipeline parameters described under [Reading](#reading) are available (`regex`, `jq`, `quote`, etc.). **Reading Example**: ```yaml source: mqtt topic: mbmd/sdm1-1/Power timeout: 30s # don't accept values older than timeout scale: 0.001 # factor applied to result, e.g. for Wh to kWh conversion ``` **Parameters (Writing)**: | Parameter | Type | Required | Description | | --------- | ------ | -------- | ---------------------------------------------------------- | | topic | string | yes | MQTT topic to write to | | payload | string | no | Payload template (uses value in default format if not set) | For write access, the data is provided with the `payload` attribute. If this parameter is missing from the configuration, the value is written in the default format. **Writing Example**: ```yaml source: mqtt topic: mbmd/charger/maxcurrent payload: ${var:%d} ``` []() ### Prometheus read [Section titled “Prometheus ”](#prometheus-) The `prometheus` plugin reads metrics from a Prometheus instance using PromQL queries. This is useful when monitoring data is already available in Prometheus and should be used in evcc. **Parameters**: | Parameter | Type | Required | Description | | --------- | -------- | -------- | ---------------------------- | | uri | string | yes | Prometheus server URL | | query | string | yes | PromQL query | | timeout | duration | no | Timeout (default: 2 minutes) | **Supported query results**: * **Scalar**: A single numerical value * **Vector**: A vector with exactly one metric entry **Example**: ```yaml power: source: prometheus uri: http://prometheus.local:9090 query: "sum(household_power_watts)" timeout: 30s ``` **Example with time range**: ```yaml energy: source: prometheus uri: http://prometheus.local:9090 query: "increase(energy_total_kwh[1h])" ``` The query must return a single numerical value. For vector results, exactly one metric must be included. []() ### Shell Script read write [Section titled “Shell Script ”](#shell-script--) The `script` plugin executes external scripts to read or update data. The plugin is useful for integrating any kind of external functionality. **Reading Example**: ```yaml source: script cmd: /bin/bash -c "cat /dev/urandom" timeout: 5s ``` **Writing Example**: ```yaml source: script cmd: /home/user/my-script.sh ${enable:%b} # format boolean enable as 0/1 timeout: 5s ``` []() ### SMA/Speedwire read [Section titled “SMA/Speedwire ”](#smaspeedwire-) The `sma` plugin provides an interface to SMA devices that support the Speedwire protocol. **Reading Example**: ```yaml source: sma uri: 192.168.4.51 # alternative to serial serial: 123456 # alternative to uri value: ActivePowerPlus # ID of value to read password: "0000" # optional (default: 0000) interface: eth0 # optional scale: 1 # optional scale factor for value ``` Supported values for `value` can be found in the diagnostic output using the `evcc meter` command (with configured SMA `meter` devices). All possible values can be found as constants [here](https://gitlab.com/bboehmke/sunny/-/blob/master/values.go#L24) (use the constant name for `value`). []() ### Websocket read [Section titled “Websocket ”](#websocket-) The `websocket` plugin provides a WebSocket listener. It also includes the ability to read or parse JSON data structures via jq-like queries. This can be used, for example, to receive data from Volkszähler’s push server. For data extraction, the pipeline parameters described in [Reading](#reading) are available (`regex`, `jq`, `quote`, etc.). **Reading Example**: ```yaml source: http uri: ws:///socket jq: .data | select(.uuid=="") .tuples[0][1] # parse message json scale: 0.001 # factor applied to result, e.g. for Wh to kWh conversion timeout: 30s # error if no update received in 30 seconds ``` ## Helpers [Section titled “Helpers”](#helpers) []() ### Calc read [Section titled “Calc ”](#calc-) The `calc` plugin allows mathematical processing of multiple individual values: **Reading Example**: ```yaml source: calc add: - source: ... ... - source: ... ... ``` ```yaml source: calc mul: - source: calc sign: source: ... (power) ... - source: ... (current) ... ``` The basic arithmetic operations addition (add), multiplication (mul), division (div), sign inversion (sign), absolute value (abs), minimum value (min) and maximum value (max) are supported as operands. With `scale: -1` on one of the values, simple subtraction can be performed, with `scale: 0.001` division, e.g. for converting kWh to Wh. With `sign:` (every positive number becomes +1, every negative number becomes -1, 0 remains 0), signs can be transferred to other values (in conjunction with `mul`). E.g. to transfer the “direction” of power (feed-in or consumption) to the measured currents for meters. With `abs:`, the absolute value of a number is calculated. With `min:` and `max:` the minimum value respectively the maximum value will be calculated. The `calc` plugin is helpful for e.g. * Summing power values from individual PV strings (addition) * Calculating apparent power from voltage and current (multiplication) * Combining separate power values for import and export into a signed single value (subtraction). * Calculating percentage fill levels (division) * Determining the correct direction of current flow (sign) * Eliminating known offsets (addition with `const` plugin) Tip Constant auxiliary values (e.g. for offsets) can be generated as operands using the `const` plugin. []() ### Combined read [Section titled “Combined ”](#combined-) The `combined` status plugin is used to convert mixed boolean status values of `Plugged` (connected) / `Charging` (charging) into an evcc-compatible charging status of A..F. It’s used, for example, with an OpenWB MQTT integration. **Reading Example**: ```yaml source: combined plugged: source: mqtt topic: openWB/lp/1/boolPlugStat charging: source: mqtt topic: openWB/lp/1/boolChargeStat ``` []() ### Const read [Section titled “Const ”](#const-) The `const` plugin returns a constant value. It’s suitable, for example, to apply fixed correction values (offset) to a variable value in conjunction with the `calc` plugin or to simulate measurement and status values for testing purposes. **Reading Example**: ```yaml source: const value: -16247 ``` []() ### Error read [Section titled “Error ”](#error-) The `error` plugin always returns a [known error value](#known-errors). It is useful to explicitly mark an unimplemented attribute as not available. **Parameters**: | Parameter | Type | Required | Description | | --------- | ------ | -------- | -------------------------------------------------------------- | | error | string | yes | Error value (`ErrAsleep`, `ErrMustRetry` or `ErrNotAvailable`) | **Example**: ```yaml soc: source: error error: ErrNotAvailable ``` []() ### Convert write [Section titled “Convert ”](#convert-) The `convert` plugin converts data types when writing. It is used when a plugin expects a different data type than evcc provides. **Parameters**: | Parameter | Type | Required | Description | | --------- | ------ | -------- | ----------------------------------- | | convert | string | yes | Conversion type | | set | config | yes | Plugin for writing after conversion | **Supported conversions**: | Conversion | Description | | ---------- | ---------------------------------------------- | | float2int | Float64 → Int64 (decimal places are truncated) | | int2float | Int64 → Float64 | | int2bytes | Int64 → Byte array (Big Endian, 8 bytes) | | bool2int | Bool → Int64 (true=1, false=0) | **Example** (evcc provides float, device expects int): ```yaml limitsoc: source: convert convert: float2int set: source: modbus uri: 192.168.1.10:502 id: 1 register: address: 41009 type: writesingle encoding: uint16 ``` In this example, evcc converts a float value like `85.5` to `85` before writing it to the modbus register. []() ### Delta write [Section titled “Delta ”](#delta-) The `delta` plugin converts absolute values to delta/increment values. It’s used for devices that add written values to an internal sum instead of setting them directly. **Parameters**: | Parameter | Type | Required | Description | | --------- | ------ | -------- | ------------------------------------------------ | | get | config | no | Plugin for reading the current total from device | | set | config | yes | Plugin for writing the calculated delta | **How it works**: 1. Input value is received (e.g., `1000`) 2. If `get` is configured, the current total is read from the device 3. Delta is calculated: `delta = new_value - current_total` 4. Delta is written via the `set` plugin 5. Internal state is updated Without the `get` parameter, the plugin tracks the total internally (starts at 0). When evcc restarts, synchronisation with the device is lost. Therefore, it’s recommended to configure `get` if the device provides a readable total register. **Supported data types**: `int64`, `float64` **Use case**: Some heat pumps (e.g., Ochsner) have registers that expect delta values instead of absolute values. When writing `500`, the device adds 500 W to the internal value instead of setting it to 500 W. To increase from 1000 W to 1500 W, you must write `+500`. To decrease, negative values are written (e.g., `-300`). **Writing Example**: ```yaml setmaxpower: source: delta get: # Read current total from device source: modbus uri: 192.168.1.50:502 id: 50 register: address: 2012 # Device's internal sum register type: input decode: uint16 set: # Write calculated delta source: modbus uri: 192.168.1.50:502 id: 50 register: address: 2201 # Delta register type: writeholding decode: uint16 ``` **Example with Watchdog**: The delta plugin is often combined with the [watchdog plugin](#watchdog) when the device requires periodic updates: ```yaml setmaxpower: source: watchdog timeout: 60s # Resend every 30 seconds set: source: delta # Convert absolute values to deltas get: # Read current total source: modbus uri: 192.168.1.50:502 id: 50 register: address: 2012 # Total register type: input decode: uint16 set: # Write delta source: modbus uri: 192.168.1.50:502 id: 50 register: address: 2201 # Delta register type: writeholding decode: uint16 ``` []() ### Ignore write [Section titled “Ignore ”](#ignore-) The `ignore` plugin suppresses specific error messages when writing. It is used when a device returns harmless errors that can be ignored. **Parameters**: | Parameter | Type | Required | Description | | --------- | ------ | -------- | --------------------------- | | error | string | yes | Error text prefix to ignore | | set | config | yes | Plugin for writing | **How it works**: 1. The nested `set` plugin is executed 2. If an error occurs, it checks whether the error message starts with the `error` string 3. If yes, the error is ignored and success is returned 4. If no, the error is passed through normally **Supported data types**: `int64`, `float64`, `bool`, `[]byte` **Example**: ```yaml batterymode: source: switch switch: - case: 1 # normal set: source: const value: 2 set: source: ignore error: "modbus: response data size '18' does not match count '4'" set: source: modbus uri: 192.168.1.10:502 id: 1 register: address: 0x1110 type: writemultiple encoding: int16 ``` In this example, the device returns a harmless modbus error that is ignored. []() ### IfElse write [Section titled “IfElse ”](#ifelse-) The `ifelse` plugin performs conditional write operations with two branches. Depending on the input value, either the `if` or the `else` plugin is executed. **Parameters**: | Parameter | Type | Required | Description | | --------- | ------ | -------- | --------------------------------------------- | | if | config | yes | Plugin executed when the condition is met | | else | config | yes | Plugin executed when the condition is not met | **How it works**: * For `bool` values: `true` runs `if`, `false` runs `else` * For `int64` values: `> 0` runs `if`, otherwise runs `else` **Supported data types**: `int64`, `bool` **Example** (different endpoints for enabling and disabling): ```yaml enable: source: ifelse if: source: http uri: http://device.local/api/on method: POST else: source: http uri: http://device.local/api/off method: POST ``` []() ### Map read write [Section titled “Map ”](#map--) The `map` plugin translates integer values to other integer values using a lookup table. It is often used to convert device-specific values to evcc standard values and vice versa. **Parameters**: | Parameter | Type | Required | Description | | --------- | ---------------- | -------- | ----------------------------------------------- | | values | map\[int64]int64 | yes | Lookup table with input → output mapping | | get | config | no | Plugin for reading (only required when reading) | | set | config | no | Plugin for writing (only required when writing) | **How it works**: **When reading**: 1. `get` plugin returns a value (e.g., `0`) 2. Value is looked up in the `values` table 3. The mapped value is returned (e.g., `0` → `2`) **When writing**: 1. Input value is received (e.g., `3`) 2. Value is looked up in the `values` table 3. The mapped value is passed to the `set` plugin (e.g., `3` → `6`) If no matching value is found in the table, an error occurs. **Supported data types**: `int64` (integer values only) **Reading example** (device value → evcc): ```yaml getmode: source: map values: 0: 2 # Device "Free" → evcc "normal" 1: 1 # Device "Forced off" → evcc "reduced" 2: 3 # Device "Recommended on" → evcc "boost" 3: 3 # Device "Forced on" → evcc "boost" get: source: modbus uri: 192.168.1.10:502 id: 1 register: address: 55 type: holding encoding: int16 ``` **Writing example** (evcc → device value): ```yaml setmode: source: map values: 1: 1 # evcc "reduced" → Device "Forced off" 2: 0 # evcc "normal" → Device "Free" 3: 3 # evcc "boost" → Device "Forced on" set: source: modbus uri: 192.168.1.10:502 id: 1 register: address: 55 type: writeholding encoding: int16 ``` []() ### Meter read [Section titled “Meter ”](#meter-) The `meter` plugin allows using another meter as a data source. This is useful when you want to use an existing device for multiple measurements or when you need different methods of a device for different attributes. The `config` section contains the complete template configuration of the meter to be embedded. The `method` parameter selects which value to read: `power`, `energy`, `returnenergy` or `soc`. **Reading Example**: ```yaml meters: - name: battery type: custom power: source: meter config: type: template template: shelly-1pm host: 192.168.178.21 channel: 0 method: power scale: -1 energy: source: meter config: type: template template: shelly-1pm host: 192.168.178.21 channel: 0 method: energy soc: source: mqtt topic: Haus/Batterie jq: .soc timeout: 60s ``` In this example, a Shelly 1PM device is used as a data source for power and energy of a battery, while the state of charge (SoC) is retrieved via MQTT. []() ### Sequence write [Section titled “Sequence ”](#sequence-) The `sequence` plugin executes multiple write operations sequentially. All nested plugins receive the same input value and are executed in the defined order. Execution stops immediately on error. **Parameters**: | Parameter | Type | Required | Description | | --------- | --------- | -------- | ------------------------------------- | | set | \[config] | yes | Array of nested plugin configurations | **How it works**: 1. Input value is received 2. Each plugin in the `set` list is called sequentially with this value 3. On error, the sequence is aborted and the error is returned 4. Successful execution means all plugins executed successfully **Supported data types**: `int64`, `float64`, `bool` **Use cases**: * Execute multiple HTTP calls sequentially * Combine with `sleep` plugin for time-delayed actions * Write multiple modbus registers simultaneously * Propagate values to multiple targets **Example 1: Multiple HTTP calls** ```yaml setmode: source: sequence set: - source: http uri: http://device.local/api/pin1 method: POST body: '{"value": "on"}' - source: http uri: http://device.local/api/pin4 method: POST body: '{"value": "off"}' ``` **Example 2: Combination with switch** ```yaml batterymode: source: sequence set: - source: switch switch: - case: 1 # normal set: source: http uri: http://battery.local/api/mode body: "automatic" - case: 3 # charge set: source: sequence set: - source: sleep duration: 1s - source: http uri: http://battery.local/api/charge body: "5000" # 5 kW - source: mqtt topic: home/battery/status payload: "mode_${batterymode}" ``` **Flow for `batterymode: 1` (normal)**: 1. Outer `sequence` receives value `1` 2. First step: `switch` checks value `1` * Case `1` matches → HTTP call to `/api/mode` with body `automatic` 3. Second step: `mqtt` sends message to `home/battery/status` with payload `mode_1` 4. Done **Flow for `batterymode: 3` (charge)**: 1. Outer `sequence` receives value `3` 2. First step: `switch` checks value `3` * Case `3` matches → Inner `sequence` is executed: * Wait 1 second (`sleep`) * HTTP call to `/api/charge` with body `5000` 3. Second step: `mqtt` sends message to `home/battery/status` with payload `mode_3` 4. Done The value flows through all plugins, with `switch` executing different actions based on the value and `mqtt` always notifying at the end. []() ### Sleep write [Section titled “Sleep ”](#sleep-) The `sleep` plugin adds a delay. Typically used within a `sequence` plugin to create time intervals between actions. **Parameters**: | Parameter | Type | Required | Description | | --------- | -------- | -------- | -------------------------------------------------- | | duration | duration | yes | Wait time (e.g., `1s`, `500ms`, `0s` for no delay) | **Example**: ```yaml setmode: source: sequence set: - source: http uri: http://device.local/api/prepare method: POST - source: sleep duration: 500ms - source: http uri: http://device.local/api/activate method: POST ``` []() ### Switch write [Section titled “Switch ”](#switch-) The `switch` plugin performs conditional write operations, similar to a switch/case statement in programming languages. Based on the input value, the corresponding action is executed. **Parameters**: | Parameter | Type | Required | Description | | --------- | ------- | -------- | -------------------------------------------------- | | switch | \[case] | yes | Array of cases with `case` and `set` configuration | | default | config | no | Fallback plugin if no case matches | **How it works**: 1. Input value is compared with the `case` values 2. On match, the corresponding `set` plugin is executed 3. If no case matches and `default` is defined, it is executed 4. If no case matches and no `default` is defined, an error occurs **Supported data types**: `int64` (integer values only) **Example**: ```yaml setmode: source: switch switch: - case: 1 # reduced set: source: http uri: http://device.local/api/mode body: "eco" - case: 2 # normal set: source: http uri: http://device.local/api/mode body: "normal" - case: 3 # boost set: source: http uri: http://device.local/api/mode body: "boost" ``` []() ### Valid read [Section titled “Valid ”](#valid-) The `valid` plugin allows providing plugin values based on boolean validation. It separates the validity of a value from its actual content. If the validation returns `false`, the value is considered unavailable. This is particularly useful for integrations like ioBroker that provide validity and value separately. **Reading Example**: ```yaml source: valid valid: source: mqtt topic: iobroker/wallbox/power/valid value: source: mqtt topic: iobroker/wallbox/power/value ``` In this example, the value is only used when the `valid` topic returns `true`. If it returns `false`, the value is marked as unavailable. []() ### Watchdog write [Section titled “Watchdog ”](#watchdog-) The `watchdog` plugin is a wrapper plugin that automatically repeats write operations at regular intervals. Some devices (e.g. battery storage systems, inverters) expect control commands to be repeated regularly to stay active. The watchdog plugin monitors write operations and automatically repeats them at half the configured timeout interval. **Parameters**: | Parameter | Type | Required | Description | | --------- | ------------------- | -------- | --------------------------------------------------------------------- | | timeout | duration | yes | Time interval for repetitions (value is rewritten every timeout/2) | | reset | string \| \[string] | no | Value(s) at which repetitions are stopped | | initial | string | no | Value that is written once at startup | | defer | bool | no | Defers updates instead of executing them immediately (default: false) | | set | config | yes | Nested plugin for the actual write operation | **How it works**: 1. **Start**: If `initial` is configured, this value is written once at startup 2. **Write**: When a value is written, the plugin checks whether it is in the `reset` list 3. **Watchdog active**: If the value is **not** in `reset`, the watchdog starts and automatically rewrites the value every `timeout/2` seconds 4. **Watchdog stops**: If the value is in `reset`, no repetitions are performed **reset parameter**: * Defines values at which the watchdog is stopped * Can be a single value (`reset: 0`) or multiple values (`reset: [0, 1]`) * Typically used for “safe” or “default” states that don’t need continuous repetition **initial parameter**: * Optional value that is written once when the plugin starts * Useful for setting a defined initial state * Executed before all other write operations **defer parameter**: * Ensures that timeouts between updates are respected * The watchdog is stopped during the delay and restarted with the new value after expiry * Useful when devices require a minimum wait time between mode changes * The delay is calculated based on the time since the last update * Reset values are always written immediately (without delay) **Supported data types**: `int64`, `float64`, `bool` **Example Write**: ```yaml source: watchdog timeout: 60s reset: 0 set: source: modbus uri: 192.168.1.10:502 id: 1 register: address: 100 type: writemultiple encoding: uint16 ``` In this example, values are automatically repeated every 30 s, except when the value `0` is written. **Flow example** with `timeout: 60s`, `reset: 0`: * Plugin starts * Write value `100` → Watchdog **runs**, value is repeated every 30 s * After 2 minutes: Value `100` has been written 4x (0s, 30s, 60s, 90s, 120s) * Write value `200` → Watchdog **continues** running, now with new value `200` every 30 s * Write value `0` → Watchdog **stops** (since `0` is defined in `reset`) * No further repetitions until a new value != `0` is written **Example with battery control** (`batterymode` uses values 1=normal, 2=hold, 3=charge): ```yaml batterymode: source: watchdog timeout: 60s reset: 1 # Stop repetitions in normal operation set: source: switch switch: - case: 1 # normal set: source: modbus # ... Modbus configuration for normal operation - case: 2 # hold set: source: modbus # ... Modbus configuration for hold mode - case: 3 # charge set: source: modbus # ... Modbus configuration for charge mode ``` # Web UI The web UI runs on port `7070` and uses hash routing. The URL can set both the page and the display settings. ## Available Pages [Section titled “Available Pages”](#links) Each page has its own hash route. Link to it directly or bookmark it. | Page | Route | Login | Parameters | | ----------------- | ------------ | ----- | ------------------------------------------------- | | Home / loadpoints | `#/` | no | `lp` | | Home Battery | `#/battery` | no | — | | Forecast | `#/forecast` | no | — | | Charging Sessions | `#/sessions` | no | `month`, `year`, `loadpoint`, `vehicle`, `period` | | Configuration | `#/config` | yes | — | | Logs | `#/log` | yes | `areas`, `level` | | History 🧪 | `#/history` | no | `day`, `month`, `year`, `period` | | Optimize 🧪 | `#/optimize` | no | — | | Report a problem | `#/issue` | yes | — | 🧪 marks experimental pages. | Parameter | Description | | ----------- | --------------------------------------------- | | `lp` | Loadpoint number, starting at `1` | | `year` | Year to show, e.g. `2026` | | `month` | Month, `1`–`12` | | `day` | Day of month, `1`–`31` | | `period` | Time range: `day`, `month`, `year` or `total` | | `loadpoint` | Loadpoint title | | `vehicle` | Vehicle title | | `areas` | Log areas to show, comma-separated | | `level` | Minimum log level | ### Examples [Section titled “Examples”](#examples) Pre-select a loadpoint on the home screen: ```plaintext http://evcc.local:7070/#/?lp=1 ``` The simplest way to get the right link is to select the loadpoint in the UI and copy the address from your browser. Filter **Charging Sessions** or **History** by time range or device: ```plaintext http://evcc.local:7070/#/sessions?year=2026&month=3 ``` ## Applying Settings [Section titled “Applying Settings”](#settings) The options under **More → User Interface** can also be set through the URL. This forces the UI’s appearance regardless of any stored browser preference, useful for kiosk screens, dashboards and iframe embeds: | Name | Parameter | Values | | ----------- | --------- | ----------------------- | | Design | `theme` | `auto`, `light`, `dark` | | Language | `lang` | `auto`, `de`, … | | Units | `unit` | `km`, `mi` | | Time format | `format` | `12`, `24` | ### Example [Section titled “Example”](#example) ```plaintext http://evcc.local:7070/?theme=dark&lang=de&unit=mi&format=24 ``` The values are applied once on load, stored as a browser preference and then removed from the address bar. `lang` accepts any language code with a translation in the [`i18n` folder](https://github.com/evcc-io/evcc/tree/master/i18n) (e.g. `de`, `fr`, `zh-Hans`) or `auto` to follow the browser language. Settings and a page can be combined in one URL. Settings go before the `#`, the page after it: ```plaintext http://evcc.local:7070/?theme=dark&lang=de#/sessions ``` # More Awesome Projects The evcc community is a creative bunch. Whether it’s a dashboard, an LED ring, or a menu bar app: here you’ll find awesome projects that make evcc even better. All of them are developed independently by their authors and are not part of evcc. * [ha-puzzles/evcc-grafana-dashboards](https://github.com/ha-puzzles/evcc-grafana-dashboards): Grafana dashboards for visualising charging sessions and energy data * [mkshb/hass-evcc-card](https://github.com/mkshb/hass-evcc-card): Lovelace card that shows the evcc overview in Home Assistant dashboards * [ohAnd/EOS\_connect](https://github.com/ohAnd/EOS_connect): connects the EOS energy optimiser with evcc and shows the results on its own web page * [powelllens/evcc\_eink\_monitor](https://github.com/powelllens/evcc_eink_monitor): E-Ink display that shows the current evcc status * [maschiach/evcc\_power\_ring](https://github.com/maschiach/evcc_power_ring): LED ring that visualises the current evcc status * [fabiofdsantos/EVCCStatusBar](https://github.com/fabiofdsantos/EVCCStatusBar): macOS menu bar app with live energy overview and charging status Missing a project? [Edit this page](https://github.com/evcc-io/docs/edit/main/src/content/docs/en/smarthome/awesome.md) to add it. # Garmin The [evccg](https://github.com/METIQ-Solutions/evcc-garmin) app by [TheNinth7](https://github.com/TheNinth7) shows live data from your evcc instance on [Garmin](https://www.garmin.com) smartwatches. It is a community project and not part of evcc. ## Features [Section titled “Features”](#features) The app offers two views: * **Glance**: a quick overview of your home battery and connected vehicles with their state of charge and charging status * **Widget**: detailed views with current power flows, loadpoint details, solar forecast, grid prices, and solar energy statistics Multiple evcc instances (sites) are supported. ## Setup [Section titled “Setup”](#setup) 1. Install the app from the [Garmin Connect IQ Store](https://apps.garmin.com/apps/2bc2ba9d-b117-4cdf-8fa7-078c1ac90ab0). 2. Enter the URL of your evcc instance in the app settings via the Garmin Connect app on your phone. If your watch is paired with an iPhone, the app can access your evcc instance directly via HTTP on the local network. With an Android phone, the connection requires HTTPS with a valid certificate. The [user manual](https://evccg.metiq.com) describes the options in detail and covers setup, supported devices, and troubleshooting. # Home Assistant [Home Assistant](https://www.home-assistant.io) collects and visualises data from your smart home and offers extensive automation capabilities. evcc specialises in smart charging and heating. Both systems complement each other and can be connected in different ways. Note evcc can also be installed as a Home Assistant Addon. You can find the instructions [here](/en/installation/home-assistant). ## Visualise & Automate [Section titled “Visualise & Automate”](#visualise--automate) evcc comes with many controls for smart charging and heating but can’t cover every use case. Integrating with Home Assistant gives you more flexibility. Here are some examples: * Visualise measurements in dashboards * Create charging plans based on calendar events * Switch charging modes based on presence * … ### Home Assistant evcc Integration (Recommended) [Section titled “Home Assistant evcc Integration (Recommended)”](#home-assistant-evcc-integration-recommended) The [ha-evcc](https://github.com/marq24/ha-evcc) integration by [marq24](https://github.com/marq24) brings evcc data and functions directly into Home Assistant. This works regardless of whether you run evcc as a Home Assistant addon or not. The only requirement is that Home Assistant and evcc are reachable on the same network. The integration provides all relevant evcc entities: measurements, settings, charging points, and vehicles. After installation, you get a comprehensive list of entities that you can use in dashboards and automations. **Installation via HACS:** 1. Open [HACS](https://hacs.xyz/) in Home Assistant and search for “evcc”. 2. Install the entry **evcc☀️🚘- Solar Charging** by marq24. 3. Restart Home Assistant. 4. Go to **Settings → Devices & Services → Add Integration**, search for “evcc”, and enter the URL of your evcc instance. For additional installation options and details, see the [GitHub repository](https://github.com/marq24/ha-evcc). For dashboards, the [hass-evcc-card](https://github.com/mkshb/hass-evcc-card) provides a Lovelace card that shows the evcc overview in Home Assistant. ### Manual Integration [Section titled “Manual Integration”](#manual-integration) Alternatively, you can manually integrate evcc data into Home Assistant via the REST API or MQTT. #### REST API [Section titled “REST API”](#rest-api) evcc offers a [REST API](/integrations/rest-api). [This guide](https://github.com/marq24/ha-evcc/blob/main/HA_AS_EVCC_SOURCE.md) by [marq24](https://github.com/marq24) describes the integration with Home Assistant in detail. #### MQTT [Section titled “MQTT”](#mqtt) You need an MQTT broker (e.g. [Mosquitto](https://mosquitto.org/), also available as a Home Assistant addon). Configure the broker connection in evcc under **Configuration → MQTT**. The same broker and topic must be configured in Home Assistant so that both systems can exchange data. You can use a tool like [MQTT Explorer](http://mqtt-explorer.com) to verify that topics are arriving correctly. A guide on setting up MQTT sensors in Home Assistant is available in the [blog by Alkly (German)](https://alkly.de/mqtt-mit-home-assistant-fuer-anfaenger). The available topics are documented in the [MQTT API](/en/integrations/mqtt-api). ## Using Home Assistant Entities [Section titled “Using Home Assistant Entities”](#using-home-assistant-entities) evcc can connect directly to Home Assistant and use its entities (sensors, switches, numbers) as data sources. This allows you to integrate devices into evcc that are not natively supported, e.g. Zigbee smart plugs, sensors from other integrations, or DIY solutions. As long as the data is available as a Home Assistant entity, evcc can work with it. ### Setup [Section titled “Setup”](#setup) 1. Add a new device in the evcc UI (e.g. **Configuration → Add additional meter**) 2. Select “Home Assistant” as the manufacturer 3. evcc will automatically discover your Home Assistant instance on the network 4. Authorise evcc in Home Assistant (new tab) 5. Assign Home Assistant entities to the presented fields (e.g. “Power”) * You’ll get suggestions and autocomplete (e.g. `sensor.inverter_power`) * Entities must return pure numeric values (`1234`, not `1234 W`) * To invert the sign, prepend `-` to the entity name (`-sensor.inverter_power`) ### Supported Device Types [Section titled “Supported Device Types”](#supported-device-types) * **[Meters](/en/meters#home-assistant)** (grid, solar, battery, …) with power, energy, currents, voltages, SoC * **[Chargers](/en/chargers#home-assistant-charger)** with status, enable/disable, and maximum charging current * **[Smart switches](/en/smartswitches#home-assistant-switch)** with simple on/off control (for smart plugs, relays) * **[Vehicles](/en/vehicles#home-assistant)** with SoC, range, status, odometer; optionally scripts for start/stop * **[Notifications](/en/notifications)** under **Configuration → Notifications** you can send evcc messages via Home Assistant ## Further Resources (Videos) [Section titled “Further Resources (Videos)”](#further-resources-videos) Videos are in German. * [smart home & more: evcc Basic Installation and Configuration](https://youtu.be/aPq8k2MronY) * [smart home & more: Step by Step - Setting up MQTT Sensor using MQTT Explorer](https://youtu.be/0QQ3y8fgRVA) * [smart home & more: Efficient Energy Dashboard for Home Assistant](https://youtu.be/V3p5-16U_oU) # Homey [Homey](https://homey.app) is a smart home hub that connects devices from many manufacturers and automates them via flows. The [evcc app for Homey](https://homey.app/en-us/app/com.evcc.io/) connects Homey to your local evcc instance. It is a community project by [rdvnit](https://github.com/rdvnit) and not part of evcc. ## Features [Section titled “Features”](#features) The app provides three device types: * **Charging point** with charge mode, charge limit, charging power, session energy, vehicle battery level and range, and connection and charging status * **Site** with solar production, grid power, and home consumption * **Home battery** with battery power, battery level, and battery control settings Flow cards let you set the charge mode, charge limit, and minimum and maximum charging current. Flow conditions react to charge mode, charging state, and connection state. The app polls your evcc instance on the local network and does not depend on any cloud service. ## Setup [Section titled “Setup”](#setup) 1. Install the **evcc** app from the [Homey App Store](https://homey.app/en-us/app/com.evcc.io/). 2. Add a device and choose **Charging point**, **evcc site**, or **Home battery**. 3. Enter the URL of your evcc instance (e.g. `http://192.168.1.50:7070`) and the password, if configured. Details and support are available in the [GitHub repository](https://github.com/rdvnit/com.evcc.io). # ioBroker [ioBroker](https://www.iobroker.net) is an open-source smart home platform that integrates devices and services via adapters. The [ioBroker.evcc](https://github.com/Newan/ioBroker.evcc) adapter connects ioBroker to your evcc instance. It is a community project and not part of evcc. ## evcc Adapter [Section titled “evcc Adapter”](#evcc-adapter) The adapter communicates with your evcc instance via the [REST API](/integrations/rest-api). It provides states for loadpoints, vehicles, and site data, and lets you control charge modes and limits from ioBroker scripts and visualisations. ### Setup [Section titled “Setup”](#setup) 1. Install the **evcc** adapter from the ioBroker admin interface. 2. Enter the address and port of your evcc instance in the adapter configuration. Details and support are available in the [GitHub repository](https://github.com/Newan/ioBroker.evcc) and the [ioBroker forum thread](https://forum.iobroker.net/topic/49165/neuer-adapter-iobroker-evcc). ## MQTT [Section titled “MQTT”](#mqtt) Alternatively, you can exchange data with ioBroker via MQTT. Configure the broker connection in evcc under **Configuration → MQTT** and use ioBroker’s MQTT adapter on the same broker. The available topics are documented in the [MQTT API](/en/integrations/mqtt-api). # openHAB [openHAB](https://www.openhab.org) is an open-source smart home platform that connects devices and services from many manufacturers. The official [evcc binding](https://www.openhab.org/addons/bindings/evcc/) brings data and controls from your evcc instance into openHAB. ## evcc Binding [Section titled “evcc Binding”](#evcc-binding) The binding connects to your evcc instance over the local network and polls its API at a configurable interval. It requires evcc version 0.209.8 or newer. Once the connection is set up, your configured devices are discovered automatically. The binding provides Things for: * Loadpoints with charging power, charge mode, current limits, and session data * Vehicles with state of charge and charging plans * Site data such as grid power, solar production, and home battery * Heating devices You can monitor charging in openHAB dashboards and control charge modes, limits, and charging plans from rules and automations. ### Setup [Section titled “Setup”](#setup) 1. Install the **evcc** binding from the openHAB add-on store. 2. Add the evcc bridge Thing and enter the address and port of your evcc instance. 3. Accept the automatically discovered Things from the inbox. Configuration details and the full list of channels are documented in the [binding documentation](https://www.openhab.org/addons/bindings/evcc/). ## MQTT [Section titled “MQTT”](#mqtt) Alternatively, you can exchange data with openHAB via MQTT. Configure the broker connection in evcc under **Configuration → MQTT** and use openHAB’s MQTT binding on the same broker. The available topics are documented in the [MQTT API](/en/integrations/mqtt-api). # Sponsorship We at evcc believe in open source software. Our goal is to enable local, cloud-free, privacy-friendly and manufacturer-independent charging of electric vehicles. The list of supported devices is growing steadily. We value an enjoyable user experience while also offering a high degree of flexibility for advanced users. To ensure the ongoing development, we need your support - financially or through active contribution. ## Community Funding 🤘💚 [Section titled “Community Funding 🤘💚”](#community-funding-) The code of evcc is open source and available on GitHub. However, for many commercial EV chargers, we require a sponsor token. Open-hardware chargers, products with a good community karma and manufacturers who actively support evcc development are supported without a token. The same applies to simple switch-sockets and plugins. We want the project to be funded by the community. This ensures that the project develops according to the needs of its users and is not influenced by large companies or investors. ## Sponsor Tokens [Section titled “Sponsor Tokens”](#sponsor-tokens) There are two ways to get a sponsor token. Direct payment comes with a proper EU invoice, downloadable afterwards. 🩷 GitHub Sponsors The full amount lands with the project, without payment or processing fees. * **[Monthly $4](https://github.com/sponsors/evcc-io?frequency=recurring)**: A small monthly contribution. Gives us planning security, and you can change or stop it any time. * **[One-time $150](https://github.com/sponsors/evcc-io?frequency=one-time)**: A lifetime sponsor token with unlimited validity. Your token can be viewed at [sponsor.evcc.io](https://sponsor.evcc.io). 💚 Direct via Creem.io No account needed, pay by credit card, Apple Pay or Google Pay, with more payment options on the way. * **[One-time €150](https://sponsor.evcc.io)**: The same lifetime sponsor token. * **[Volume discounts](https://sponsor.evcc.io/business)**: Token bundles for electricians and installers. Your token is delivered by email. As a small thank you, you’ll receive **digital supporter confetti 🎉** inside evcc and can order a cool set of **evcc stickers ☀️** which we’ll ship to you. ## Contributor Tokens [Section titled “Contributor Tokens”](#contributor-tokens) You want to contribute to the development? We’d love that! Look at the [list of open issues](https://github.com/evcc-io/evcc/issues) or [contact us](mailto:info@evcc.io) with concrete ideas on how you’d like to contribute. Significant contributions to the [documentation](https://github.com/evcc-io/docs) or [translations](https://github.com/evcc-io/evcc/blob/master/CONTRIBUTING.md#adding-or-modifying-translations) also qualify for a contributor token. [Here](https://github.com/evcc-io/evcc/blob/master/CONTRIBUTING.md) you’ll find more information on how to get started. As a contributor, we’ll issue you an unlimited contributor token. [Send us a short email](mailto:info@evcc.io) with your GitHub username. ## Trial Token [Section titled “Trial Token”](#trial-token) You want to test evcc and check if all your devices are supported? For that, you can use our test token. It has a limited validity, but will be regularly renewed. trial token, valid until 2026-08-16 ```text eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJldmNjLmlvIiwic3ViIjoidHJpYWwiLCJleHAiOjE3ODY4NjAwMDAsImlhdCI6MTc4NTk5NjAwMCwic3BlIjp0cnVlLCJzcmMiOiJtYSJ9.PepsUH_pnuq1HpSPCPrRWyquglcO58xOLZ5KP_chtN0 ``` If everything works, you can later exchange it for a real sponsor token. ## Frequently Asked Questions [Section titled “Frequently Asked Questions”](#frequently-asked-questions) #### I am now a GitHub Sponsor, how do I get my token? [Section titled “I am now a GitHub Sponsor, how do I get my token?”](#i-am-now-a-github-sponsor-how-do-i-get-my-token) At [sponsor.evcc.io](https://sponsor.evcc.io) you can view your token(s). It may take a while (sometimes hours) until we receive the sponsor information from GitHub. So please be patient and check back later. In the meantime, you can also work with the test token. If your token does not appear after a while, [contact us](mailto:info@evcc.io). Also make sure that you have selected one of the predefined levels when sponsoring. If you’ve entered a lower custom amount (e.g. $4 one-time), no token will be created. #### I have a business and want to use evcc commercially. Can I do that? [Section titled “I have a business and want to use evcc commercially. Can I do that?”](#i-have-a-business-and-want-to-use-evcc-commercially-can-i-do-that) Yes, that’s no problem. You can buy sponsor token bundles directly at [sponsor.evcc.io/business](https://sponsor.evcc.io/business), with volume discounts for electricians and installers. The tokens are meant for use at your end customers and may not be traded individually. For custom requirements, [write us an email](mailto:info@evcc.io) and we’ll get back to you. #### Where do I enter my token? [Section titled “Where do I enter my token?”](#where-do-i-enter-my-token) Enter the sponsor token via the web interface under **Configuration** → **Sponsorship**. After entering the token, a restart of evcc is required. **Note:** If a token is already present in `evcc.yaml`, the UI input is locked. Remove the entry from `evcc.yaml` to manage the token via the web interface. #### Can I use my token on multiple installations? [Section titled “Can I use my token on multiple installations?”](#can-i-use-my-token-on-multiple-installations) Yes, as long as it’s your personal evcc instances, multiple usage is no problem. We trust you to be honest about that. #### I lost my token. How do I get a new one? [Section titled “I lost my token. How do I get a new one?”](#i-lost-my-token-how-do-i-get-a-new-one) You can view your token(s) at [sponsor.evcc.io](https://sponsor.evcc.io). #### Can I sell my token or buy a “used” one? [Section titled “Can I sell my token or buy a “used” one?”](#can-i-sell-my-token-or-buy-a-used-one) The tokens are personalized and contain your GitHub username. Please do not sell them to third parties. Please do not buy used tokens from third parties via online platforms. If you want to support the project, please do so directly. #### I need a longer test time. [Section titled “I need a longer test time.”](#i-need-a-longer-test-time) If your test token expires and you’re not sure if evcc works as expected for you, you can enter a new test token. We update the test token regularly. #### My token is not working. What’s wrong? [Section titled “My token is not working. What’s wrong?”](#my-token-is-not-working-whats-wrong) There could be several reasons: * **Monthly sponsoring expired:** Check your sponsor status at GitHub and [sponsor.evcc.io](https://sponsor.evcc.io). * **Formatting error:** Check if you have correctly entered the token in `evcc.yaml`. * **Duplicate configuration:** If you entered the token both in the web interface and in `evcc.yaml`, only the token from `evcc.yaml` is used. Remove the entry from the file if you want to manage the token via the web interface. * **Token expired:** The token itself has an expiration date. If this has passed, you can issue a new one at [sponsor.evcc.io](https://sponsor.evcc.io) and replace the current one. You will receive a warning in the web interface in good time when this is necessary. Note: We will automate this process in the future. If the above does not help, [contact us](mailto:info@evcc.io) and we’ll check it out. #### My sponsor badge on GitHub is no longer displayed. [Section titled “My sponsor badge on GitHub is no longer displayed.”](#my-sponsor-badge-on-github-is-no-longer-displayed) We cannot influence the display of the sponsor badge on your GitHub profile. GitHub currently only displays the badge for the first month of sponsoring, even for larger one-time sponsorings. However, this has no influence on your sponsor status for evcc. # User-defined Devices When creating a charger, heater, grid meter, battery, solar system, other consumer, vehicle, tariff or notification service, you can pick the **User-defined device** option from the device type list and describe your own logic based on the [plugin system](/en/reference/plugins). That way you can integrate devices that aren’t covered by a built-in template, e.g. read the current power from an HTTP endpoint, or write a target current via Modbus. ## How to define a device [Section titled “How to define a device”](#how-to-define-a-device) In the UI, every device type lists a **User-defined device** entry in the template selector. Picking it opens the editor for your own configuration. A device with `type: custom` is created by default. The type can be overridden with another value when needed (e.g. `type: heatpump`). ```yaml power: source: mqtt topic: home/current/imsys/chn2/raw ``` Alternatively, write the full configuration directly in `evcc.yaml` with `name`, `type: custom` and the attribute block underneath: ```yaml meters: - name: imsys type: custom power: source: mqtt topic: home/current/imsys/chn2/raw ``` All other examples on this page use the flat attribute-block form you enter in the UI. For the list of available plugin sources (`http`, `mqtt`, `modbus`, …) and helpers (`calc`, `map`, `watchdog`, …) see the [plugins reference](/en/reference/plugins). ## Attributes and features [Section titled “Attributes and features”](#attributes-and-features) Every user-defined device is described by three kinds of fields: * **Read attributes** — plugins evcc polls to obtain a value (e.g. `power`, `soc`, `status`). * **Write attributes** — plugins evcc invokes to set a value or trigger an action (e.g. `enable`, `maxcurrent`, `wakeup`). The value to be written is available in the plugin. * **Features** — `features` list toggling non-default behaviour. Available flags depend on the device type. Generic shape: ```yaml # read attributes power: source: http uri: http://meter.local/power soc: source: mqtt topic: battery/soc # write attributes enable: source: http uri: "http://charger/relay?turn={{if .enable}}on{{else}}off{{end}}" maxcurrent: source: mqtt topic: charger/maxcurrent payload: ${maxcurrent:%d} # features features: - heating - integrateddevice ``` The available attribute names and feature flags differ per device type and are listed in the sections below. []() ## Meter [Section titled “Meter”](#meter) Power meters are configured in the [`meters`](/en/reference/configuration/meters) section. Meters defined under `meters:` can be referenced from `site`: * `grid`: Grid meter * `pv`: PV meter * `battery`: Home battery meter * `charge`: Meter for the charging power of the wallbox * `aux`: Consumption meter for intelligent consumers * `consumer`: Meter for a regular consumer, recorded for consumption statistics * `ext`: Additional meter not used for regulation or shown in the UI, only logged and exported `power` is the only required attribute. Not all meter roles support all attributes: * `limitsoc` and `batterymode` are used exclusively for battery meters (referenced from `site.battery`). * `currents`, `voltages` and `powers` are phase attributes that must be configured with exactly three plugin entries each (as a YAML array) and apply to grid meters (`grid`) and wallboxes (`charge`). Return the correct data type from each plugin. To convert, use the [reading pipelines](/en/reference/plugins#reading). ### Read attributes [Section titled “Read attributes”](#read-attributes) | Attribute | Type | Required | Context | Description | | -------------- | --------------------- | -------- | ------------- | ----------------------------------------------------------- | | `power` | `float` | yes | all | Current power in W | | `energy` | `float` | no | all | Meter reading in kWh | | `returnenergy` | `float` | no | all | Meter reading in reverse direction in kWh (see below) | | `maxpower` | `int` | no | `pv` (hybrid) | Maximum AC power in W | | `soc` | `int` | no | `battery` | State of charge in % | | `capacity` | `float` | no | `battery` | Capacity in kWh | | `powers` | `[float,float,float]` | no | all | Phase powers in W. For sign detection of unsigned currents. | | `currents` | `[float,float,float]` | no | all | Phase currents in A. For detecting active phases. | | `voltages` | `[float,float,float]` | no | all | Phase voltages in V. For connection detection (1p/3p). | []() ### Signs and Directions [Section titled “Signs and Directions”](#signs-and-directions) What a positive `power` value and the two energy directions mean depends on the meter role: | Role | `power` positive | `energy` | `returnenergy` | | ------------------------ | -------------------------------- | ---------- | ------------------ | | `grid` | Grid import | Imported | Exported (feed-in) | | `pv` | Production | Produced | Consumed (rare) | | `battery` | Discharging (negative: charging) | Discharged | Charged | | `charge` | Charging | Charged | Discharged (V2X) | | `aux`, `ext`, `consumer` | Consumption | Consumed | Produced (rare) | `energy` and `returnenergy` are increasing meter readings in kWh, ideally lifetime totals like the import and export registers of a grid meter. The differences between readings are calculated automatically, so the plugin must return a meter reading and not consumption values per interval. A counter that resets periodically (e.g. daily) also works, as the reset is detected automatically. A reading of `0` is treated as not available. Both attributes are optional. Without them, the energy history is derived from `power` over time. Real meter readings give more accurate long-term statistics. ### Write attributes [Section titled “Write attributes”](#write-attributes) | Attribute | Type | Required | Context | Description | | ------------- | ----- | -------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `limitsoc` | `int` | no | `battery` | Set charging target for battery in %. The charging target is calculated from the configured `MinSoc`, `MaxSoc` and the current state of charge (attribute `soc`). | | `batterymode` | `int` | no | `battery` | Set charging mode directly (1: normal, 2: hold, 3: charge) | ### Example [Section titled “Example”](#example) Read the current grid power from an HTTP endpoint. ```yaml power: source: http uri: http://zaehler.network.local:8080/api/data.json?from=now jq: .data.tuples[0][1] ``` []() ## Charger [Section titled “Charger”](#charger) The default `type: custom` covers wallboxes with continuous current control. For other devices, specialised charger types are described under [Switchsocket](#charger-switchsocket) and [Heat pumps](#charger-heating). ### Read attributes [Section titled “Read attributes”](#read-attributes-1) | Attribute | Type | Required | Description | | -------------- | --------------------- | -------- | ------------------------------------------------------------------------------------------- | | `status` | `string` | yes | Status (A..F) | | `enabled` | `bool` | yes | Is charging enabled? | | `power` | `float` | no | Charging power in W | | `energy` | `float` | no | Meter reading in kWh | | `returnenergy` | `float` | no | Meter reading in reverse direction in kWh (discharged energy, V2X) | | `identify` | `string` | no | Current RFID identifier | | `soc` | `int` | no | State of charge in % | | `limitsoc` | `int` | no | Charge limit in % | | `temp` | `float` | no | Current temperature in °C (heating, alias for `soc`) | | `limittemp` | `int` | no | Temperature limit in °C (heating, alias for `limitsoc`) | | `finishtime` | `string` | no | Estimated charging finish time (RFC3339, Go duration, Unix timestamp, or remaining seconds) | | `phases` | `int` | no | Number of physical phases (1..3) | | `powers` | `[float,float,float]` | no | Phase powers in W. For sign detection of unsigned currents. | | `currents` | `[float,float,float]` | no | Phase currents in A. For detecting active phases. | | `voltages` | `[float,float,float]` | no | Phase voltages in V. For connection detection (1p/3p). | ### Write attributes [Section titled “Write attributes”](#write-attributes-1) | Attribute | Type | Required | Description | | ------------------ | ------- | -------- | ------------------------------------------------- | | `enable` | `bool` | yes | Enable / disable charging | | `maxcurrent` | `int` | yes | Set maximum charging current in A | | `maxcurrentmillis` | `float` | no | Set maximum charging current in A (with decimals) | | `phases1p3p` | `int` | no | Perform phase switching (requires `tos: true`) | | `wakeup` | `bool` | no | Wake up vehicle | []() ### Features [Section titled “Features”](#features) | Feature | Description | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `integrateddevice` | No vehicle selection. Device runs without a connected vehicle and without charging sessions (e.g. heat pump, heating rod, permanently installed consumer). | | `heating` | Treat device as heating: SOC and limits are displayed in °C instead of %. | | `continuous` | Device keeps running in its own normal operation when “disabled”. The UI shows “Normal operation” instead of “Standby”. A request to increase power (e.g. on PV surplus or cheap grid power) is labelled “Boost”. | | `switchdevice` | Device can only be switched on/off (no continuous current control). Max current and the `Min+PV` mode are not shown. Min current and phases set the PV enable power. | Common feature combinations seen in built-in templates: **Electric heater**: ```yaml features: - integrateddevice - heating ``` **Socket**: ```yaml features: - switchdevice - integrateddevice # optional, when the socket drives a fixed load - heating # optional, when it controls a heating device ``` **Heat pump**: ```yaml features: - integrateddevice - heating - continuous - switchdevice # optional, when no current control is available (SG Ready) ``` ### Examples [Section titled “Examples”](#examples) Query the charging status of a charger via Modbus. ```yaml features: - integrateddevice enabled: source: modbus id: 4711 uri: modbus.local:502 rtu: false register: address: 100 type: holding decode: uint16 ``` Switch a Tasmota socket via an MQTT message. ```yaml enable: source: mqtt broker: mosquitto.local:883 topic: cmd/unu-switch/Power payload: ON ``` []() ### Switchsocket [Section titled “Switchsocket”](#switchsocket) **`type: switchsocket`** For smart sockets and similar relay devices that can only be switched on/off without continuous current control. The charging status is derived from the current power (above `standbypower` means charging). Full setup details are under [Smart switches](/en/smartswitches). | Attribute | Type | Required | Description | | -------------- | ------- | -------- | ---------------------------------------------------------------------------------------- | | `enabled` | `bool` | yes | Read socket state (on/off) | | `power` | `float` | yes | Current power in W | | `energy` | `float` | no | Meter reading in kWh | | `soc` | `float` | no | State of charge in % | | `enable` | `bool` | yes | Switch socket on/off | | `standbypower` | `float` | no | Power threshold in W. Above it: charging; below: standby. Negative: static (no metering) | []() ### Heat pumps [Section titled “Heat pumps”](#heat-pumps) Heat pumps and similar heating devices use dedicated charger types, each with its own attributes. The full setup is described under [Heat pumps, electric heaters](/en/heating). * Heat pump **`type: heatpump`** For inverter-controlled heat pumps that accept a continuous power setpoint over Modbus, HTTP or similar. The target heating power is written directly via `setmaxpower`. | Attribute | Type | Required | Description | | ------------- | ------- | -------- | --------------------------------------- | | `power` | `float` | no | Current power in W | | `energy` | `float` | no | Meter reading in kWh | | `temp` | `float` | no | Current temperature in °C | | `limittemp` | `int` | no | Device-internal temperature limit in °C | | `setmaxpower` | `int` | yes | Set maximum heating power in W | | `getmaxpower` | `float` | no | Current maximum heating power in W | * SG-Ready **`type: sgready`** For heat pumps that expose the standard SG-Ready interface as a single mode value. Three modes are supported: `1` reduced, `2` normal, `3` boost. | Attribute | Type | Required | Description | | ------------- | ------- | -------- | ------------------------------------------------------ | | `power` | `float` | no | Current power in W | | `energy` | `float` | no | Meter reading in kWh | | `temp` | `float` | no | Current temperature in °C | | `limittemp` | `int` | no | Device-internal temperature limit in °C | | `setmode` | `int` | yes | Change SG-Ready mode (1: reduced, 2: normal, 3: boost) | | `getmode` | `int` | no | Current SG-Ready mode (1, 2, 3) | | `setmaxpower` | `int` | no | Set maximum heating power in W | * SG-Ready via relays **`type: sgready-relay`** For heat pumps whose SG-Ready input is wired as two dry relay contacts (boost + dim). Each contact is driven by a separate sub-charger referenced by type, not via plugins. | Attribute | Type | Required | Description | | ----------- | --------------- | -------- | --------------------------------------- | | `power` | `float` | no | Current power in W | | `energy` | `float` | no | Meter reading in kWh | | `temp` | `float` | no | Current temperature in °C | | `limittemp` | `int` | no | Device-internal temperature limit in °C | | `boost` | `charger-typed` | yes | Relay for the SG-Ready boost contact | | `dim` | `charger-typed` | no | Relay for the SG-Ready dim contact | []() ## Vehicle [Section titled “Vehicle”](#vehicle) Vehicle parameters can also be read via plugins. ### Read attributes [Section titled “Read attributes”](#read-attributes-2) | Attribute | Type | Required | Description | | --------------- | -------- | -------- | ------------------------------------------------------------------------------------------- | | `soc` | `int` | yes | State of charge in % | | `limitsoc` | `int` | no | Charge limit in % | | `status` | `string` | no | Status (A..F) | | `range` | `int` | no | Range in km | | `odometer` | `int` | no | Odometer reading in km | | `climater` | `bool` | no | Climate control active? | | `getmaxcurrent` | `float` | no | Maximum charging current in A | | `finishtime` | `string` | no | Estimated charging finish time (RFC3339, Go duration, Unix timestamp, or remaining seconds) | ### Write attributes [Section titled “Write attributes”](#write-attributes-2) | Attribute | Type | Required | Description | | -------------- | ------ | -------- | --------------------------------- | | `wakeup` | `bool` | no | Wake up vehicle | | `chargeenable` | `bool` | no | Start/stop charging process | | `maxcurrent` | `int` | no | Set maximum charging current in A | ### Configuration [Section titled “Configuration”](#configuration) | Attribute | Type | Required | Description | | ---------- | -------- | -------- | -------------------------------- | | `title` | `string` | no | Display name of the vehicle | | `capacity` | `float` | no | Battery capacity in kWh | | `icon` | `string` | no | Icon shown in the user interface | []() ### Features [Section titled “Features”](#features-1) | Feature | Description | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `coarsecurrent` | Vehicle accepts charging current only in whole 1 A steps. The control logic is constrained to coarse 1 A steps even when the charger could regulate more finely. | | `streaming` | Vehicle pushes data instead of being polled (e.g. BMW Cardata). SOC updates outside active charging are treated as reliable. | | `welcomecharge` | Vehicle expects the wallbox to be active on connect to register the link as working. Otherwise it reports an error. | ### Examples [Section titled “Examples”](#examples-1) Read the current range from MQTT messages. ```yaml title: Green Mazda # display name (optional) capacity: 50 # battery capacity in kWh (optional) features: - coarsecurrent range: source: mqtt topic: mazda2mqtt/c53/chargeInfo/drivingRangeKm ``` Wake a car via an HTTP ping before sending further queries. ```yaml wakeup: source: http uri: http://teslalogger.local:5000/command/08154711/wake_up ``` []() `onIdentify` sets the charge mode automatically when the vehicle is detected. ```yaml soc: source: mqtt topic: car/soc onIdentify: mode: pv ``` Available modes: `off`, `now`, `minpv`, `pv`. []() ## Tariff and forecast [Section titled “Tariff and forecast”](#tariff-and-forecast) A user-defined tariff connects evcc to a custom value source via the plugin mechanism. The `tariff` attribute selects what the source represents and which unit the values use. ### Read attributes [Section titled “Read attributes”](#read-attributes-3) Exactly one of `price` or `forecast` must be configured. | Attribute | Type | Description | | ---------- | -------- | ------------------------------------------------------------------------------------------------- | | `price` | `float` | Current value. Float returned by the plugin. | | `forecast` | `string` | Forecast as JSON string with a list of time periods and values (see schema below). Polled hourly. | ### Configuration [Section titled “Configuration”](#configuration-1) | Attribute | Type | Required | Description | | -------------- | ---------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `tariff` | `string` | no | `price` (default), `co2` or `solar`. Sets the unit of the returned values: price in configured currency per kWh, CO₂ intensity in g/kWh, solar forecast in W. | | `charges` | `float` | no | Fixed additional charge per kWh added to every value. Default `0`. | | `chargesZones` | `list` | no | Time-based charges (e.g. grid fees) that override `charges` for specific periods. See [time-based grid fees](/en/reference/configuration/tariffs#charges-zones). | | `tax` | `float` | no | Percentage tax applied to the result, e.g. `0.2` for 20%. Default `0`. | | `formula` | `string` | no | Go expression for a custom calculation, with `price`, `charges` and `tax` in scope. See [examples](#formula-examples). | | `interval` | `duration` | no | Polling interval for `forecast`. Default `1h`. | | `cache` | `duration` | no | Cache duration for `price`. Default `15m`. | []() ### Features [Section titled “Features”](#features-2) | Feature | Description | | ----------- | ---------------------------------------------------------------------------------------------- | | `average` | Smooths fine-grained price slots (e.g. 15-minute values) into hourly averages. | | `cacheable` | Persists fetched values. Used as fallback after a restart or provider outage (up to 24 hours). | ### Examples [Section titled “Examples”](#examples-2) **Current price via HTTP**: ```yaml price: source: http uri: https://example.com/api/price ``` **Forecast via HTTP**: ```yaml forecast: source: http uri: https://api.allinpower.nl/troodon/api/p/spot_market/prices/?product_type=ELK jq: '[.timestamps, .prices] | transpose | map({ "start": (.[0] | strptime("%Y-%m-%dT%H:%M:%S.%f%z") | strftime("%Y-%m-%dT%H:%M:%SZ")), "end": (.[0] | strptime("%Y-%m-%dT%H:%M:%S.%f%z") | mktime + 3600 | strftime("%Y-%m-%dT%H:%M:%SZ")), "value": .[1] }) | tostring' ``` The plugin must return a JSON structure containing a list of time periods and prices. Date fields must be in the form `YYYY-MM-DDTHH:MM:SSZ` and the price in the correct currency unit (e.g. EUR). evcc works internally with 15-minute intervals; plugins may return hourly data, which is converted automatically. ```json [ { "start": "2025-01-01T00:00:00Z", "end": "2025-01-01T00:15:00Z", "value": 25.0 }, { "start": "2025-01-01T00:15:00Z", "end": "2025-01-01T00:30:00Z", "value": 26.5 }, { "start": "2025-01-01T00:30:00Z", "end": "2025-01-01T00:45:00Z", "value": 24.8 }, { "start": "2025-01-01T00:45:00Z", "end": "2025-01-01T01:00:00Z", "value": 27.2 } ] ``` []() The `formula` field accepts a Go expression with `price`, `charges`, `tax` and the slot timestamp `ts` in scope. The [`math` library](https://pkg.go.dev/math) and [`time.Time`](https://pkg.go.dev/time#Time) methods on `ts` are available. The formula runs for the current price and each forecast slot. **Price cap**: ```yaml charges: 0.22 tax: 0.19 formula: math.Min(0.5, (price + charges) * (1 + tax)) ``` Caps the result at 50 ct/kWh. **No feed-in tariff on negative day-ahead prices** (German PV systems commissioned after February 25, 2025): ```yaml formula: factor := 1.0; if price < 0 { factor = 0.0 }; factor * 0.07 ``` Pays a fixed feed-in tariff of 7 ct/kWh, except when the day-ahead market price is negative. []() ## External Limit [Section titled “External Limit”](#external-limit) A user-defined integration for the [External Limit](/en/external-limit) feature connects a control box or energy management system that isn’t covered by a built-in integration. In the UI, pick **User-defined integration** under **Configuration → External Limit**. One of four types describes how the limit signal is received: `relay` (single switch contact), `fnn` (FNN control box with multiple switch contacts), `eebus` (EEBus protocol) or `custom` (dynamic limit values via plugins). Each signal is read via a [plugin](/en/reference/plugins) configuration (GPIO, MQTT, HTTP, Modbus). See also the [`hems` configuration reference](/en/reference/configuration/hems). ### Relay [Section titled “Relay”](#relay) The connection via a single switch contact is the simplest solution. The control box activates a contact which is evaluated by your evcc instance. | Attribute | Type | Required | Description | | ------------- | ---------- | -------- | ------------------------------------------------------------------------------------------------ | | `maxPower` | `int` (W) | yes | Total power limit applied while the signal is active. | | `limit` | plugin | yes | Plugin configuration for reading the switch contact. `true`/`1` = limited, `false`/`0` = normal. | | `passthrough` | plugin | no | Passes the limitation signal through to an external system. | | `interval` | `duration` | no | Polling interval for the switch contact. Default `10s`. | The power limit is communicated to you by the grid operator. For multiple controllable consumption devices (SteuVE), the simultaneity factor is taken into account. You can also calculate the limit yourself using the formula: **Total limit = Number of SteuVE × 4.2 kW × Simultaneity factor**. Details on the calculation can be found [here](https://www.inexogy.com/blog/14a-enwg/). * Raspberry Pi GPIO When using a Raspberry Pi, the GPIO pin can be read directly: ```yaml type: relay maxPower: 8400 # Example for 2 SteuVE limit: source: gpio function: read pin: 17 # Read GPIO pin 17 # Return value: false = not limited, true = limited ``` For more details on the GPIO plugin, see the [plugin documentation](/en/reference/plugins#gpio). * MQTT If the control box or gateway sends MQTT messages: ```yaml type: relay maxPower: 11340 # Example for 3 SteuVE with simultaneity factor 0.9 limit: source: mqtt topic: hems/limit/status # Expected values: 0/false = normal, 1/true = limited ``` * HTTP API For control boxes with REST API: ```yaml type: relay maxPower: 13440 # Example for 4 SteuVE with simultaneity factor 0.8 limit: source: http uri: http://steuerbox.local/api/limit jq: .limited # JSON path to boolean value ``` * Modbus If the control box or a gateway provides the power limit via Modbus: ```yaml type: relay maxPower: 4200 # Example for 1 SteuVE limit: source: modbus uri: 192.168.179.200:4703 # Example: relay on the 2nd S0 meter of a cFos Power Brain solar wallbox id: 3 # Modbus slave ID timeout: 5s register: type: holding decode: uint16 address: 8056 # Return value: 0 = not limited, 1 = limited ``` []() ### FNN Control Box [Section titled “FNN Control Box”](#fnn-control-box) Control boxes following the FNN standard signal dimming and curtailment via separate switch contacts. Consumption dimming (W4) and feed-in curtailment (W3, S2, S1) operate independently. At least one of the signals `w4` or `w3` must be configured. | Attribute | Type | Required | Description | | ----------------- | ---------- | -------- | ------------------------------------------------------------------------- | | `maxDimPower` | `int` (W) | yes¹ | Consumption limit while the dim signal (W4) is active. | | `maxCurtailPower` | `int` (W) | yes² | Installed solar power, base value for the curtailment steps. | | `w4` | plugin | no | Reads the dim signal. Limits consumption to `maxDimPower`. | | `w3` | plugin | no | Reads the curtailment signal. Limits feed-in to 0% of `maxCurtailPower`. | | `s2` | plugin | no | Reads the curtailment signal. Limits feed-in to 30% of `maxCurtailPower`. | | `s1` | plugin | no | Reads the curtailment signal. Limits feed-in to 60% of `maxCurtailPower`. | | `interval` | `duration` | no | Polling interval for the switch contacts. Default `10s`. | ¹ required when `w4` is configured, ² required when `w3` is configured. ```yaml type: fnn maxDimPower: 4200 # Consumption limit while dimmed (in watts) maxCurtailPower: 10000 # Installed solar power, base for curtailment steps (in watts) w4: source: gpio function: read pin: 17 # Read GPIO pin 17 # Return value: false = normal, true = active w3: source: gpio function: read pin: 27 s2: source: gpio function: read pin: 22 s1: source: gpio function: read pin: 23 ``` []() ### EEBus [Section titled “EEBus”](#eebus) The digital connection via the EEBus protocol. The control box communicates directly with your evcc instance and automatically transmits the power limit. Control box and evcc need to be [paired](/en/external-limit#eebus-pairing) once. | Attribute | Type | Required | Description | | ------------------------------------- | ---------- | -------- | ----------------------------------------------------------- | | `ski` | `string` | yes | SKI (Subject Key Identifier) of the control box. | | `contractualConsumptionNominalMax` | `int` (W) | no | Contractual maximum consumption power. | | `failsafeConsumptionActivePowerLimit` | `int` (W) | no | Failsafe limit for consumption power. | | `productionNominalMax` | `int` (W) | no | Installed generator power (Wp). | | `failsafeProductionActivePowerLimit` | `int` (W) | no | Failsafe limit for feed-in power. | | `failsafeDurationMinimum` | `duration` | no | Minimum failsafe duration, e.g. `2h`. | | `passthrough` | plugin | no | Passes the limitation signal through to an external system. | ```yaml type: eebus ski: "1234-5678-90AB-CDEF" # SKI of the control box ``` []() ### Custom [Section titled “Custom”](#custom) The generic integration for control systems that provide dynamic limit values instead of switch contacts. Consumption limit and feed-in curtailment are read via plugins and work independently of each other. At least one of `maxConsumptionPower` or `curtailedPercent` must be configured. | Attribute | Type | Required | Description | | ---------------------- | ---------- | -------- | ----------------------------------------------------------------------------------------------------- | | `maxConsumptionPower` | plugin | no¹ | Reads the total power limit in watts. `0` = no limit. | | `curtailedPercent` | plugin | no¹ | Reads the allowed feed-in as percentage of `productionNominalMax` (0 to 100). `100` = no curtailment. | | `productionNominalMax` | `int` (W) | no² | Installed generator power (Wp). | | `interval` | `duration` | no | Polling interval for the plugins. Default `10s`. | ¹ at least one of the two is required, ² required when `curtailedPercent` is configured. ```yaml type: custom maxConsumptionPower: source: http uri: http://steuerbox.local/api/limit jq: .maxPower # Power limit in watts, 0 = no limit curtailedPercent: source: mqtt topic: hems/curtail/percent # Allowed feed-in in percent, 100 = no curtailment productionNominalMax: 10000 # Installed generator power (Wp) ``` []() ## Notification Service [Section titled “Notification Service”](#notification-service) A user-defined notification service processes [notification](/en/notifications) messages via any [plugin](/en/reference/plugins) with write access, e.g. a shell script, HTTP request, or MQTT message. In the UI, pick **User-defined service** under **Configuration → Notifications → Services**. The message is provided to the plugin in the `${send}` parameter (or as a template parameter `{{.send}}`). ### Configuration [Section titled “Configuration”](#configuration-2) | Attribute | Type | Required | Description | | ---------- | -------- | -------- | ----------------------------------------------------------- | | `send` | plugin | yes | Plugin invoked for each message. Must support write access. | | `encoding` | `string` | no | Format of the value provided in `${send}`. See below. | The possible `encoding` values are: | Encoding | Content of `${send}` | | -------- | ------------------------------------------------------------------------------------------------------- | | `json` | JSON object `{ "msg": msg, "title": title }`. The `title` field is only added if defined for the event. | | `csv` | `title` and `msg` as a comma-separated list | | `tsv` | Like `csv`, but tab-separated | | `title` | Only the title | | (none) | Only the message (`msg`) | ### Example [Section titled “Example”](#example-1) ```yaml messaging: events: connect: title: "${vehicleTitle} connected" msg: "${vehicleTitle} was connected (charging mode: ${mode})." services: - type: custom encoding: json send: # plugin type source: script # plugin-specific configuration; # {{.send}} contains the JSON message cmd: /usr/local/bin/evcc_message "{{.send}}" ``` In this example, a shell script (`cmd`) is invoked with the argument `{"title": "...", "msg": "..."}`.