Add, Installation, Home Assistant and Proxmox DE/EN / Integration HA update

[lucode]

[Add, Home Assistant and Proxmox Installation] (db85053)

Add section in Home Integration over REST API

Add, Installation Home Assistant and Proxmox EN

[naltatis]

Wir können auf keinen Fall eine weitere Kopie der evcc.dist.yaml hier reinpacken. Es ist jetzt schon schwer, die Doku in Sync zu halten. Was ich sehen würde wäre ein art starter yaml wo wirklich nur die Basics (1x grid, 1x pv, 1x battery, 1x charger, 1x ladepunkt, 1x fahrzeug und evtl. ein fester Tarif) drin sind. Alles andere würd ich da rausnehmen und dann auf die Referenze Docs, evcc.dist.yaml und evcc configure verweisen.

[naltatis]

Die "Starter Yaml" könnte sogar ein eigener Menüpunkt unter Installation werden. Diese Herrausforderung haben ja aktuell alle Installationswegen. Nicht nur Home Assistant.

[lucode]

Meinst du die Starter yaml auch im code repo zu hinterlegen?
Amrk. Meine demo yaml ist im Grunde keine Kopie von evcc.dist.yaml, sie enthält nur demo entities.
Ich denke auch es macht Sinn die Konfiguration in einem separaten Kapitel zu machen, nach der manuellen Installation am Schluss?

[naltatis]

Meinst du die Starter yaml auch im code repo zu hinterlegen?

In meiner Wunschvorstellung wäre die so kurz und minimal, dass wir die auch Inline anzeigen könnten.

Meine demo yaml ist im Grunde keine Kopie von evcc.dist.yaml, sie enthält nur demo entities.

Mir geht es hier primär um die ganzen anderen Optionen und Hilfstexte, die da jetzt mit drinstehen (und später aktualisiert werden müssen). Die hast du ja nicht neu geschrieben.

Ich denke auch es macht Sinn die Konfiguration in einem separaten Kapitel zu machen, nach der manuellen Installation am Schluss?

Ja, ich würde es wirklich als eigene Unterseite von "Installation" sehen. Da könnten wir dann die unterschiedlichen Wege auflisten, die man hat, um an eine Config zu kommen: 1) evcc configure, 2) selbst von Grund auf aufbauen (Starter YAML) oder 3) mit der evcc.dist.yaml anfangen.

Auf dieser Seite können wir dann auch alle relevanten Quellen verlinken, wo man dann mehr Details zu den Optionen herausfinden kann. Also "Referenz > evcc.yaml" und die evcc.dist.yaml (gh link). Auch Teile der FAQ (bspw. https://docs.evcc.io/docs/faq#fehlersuche) könnten dann mit auf diese Seite verschoben werden.

Noch ein Gedanke zur evcc.dist.yaml im Hauptrepo. Wir könnten überlegen, ob wir die so verändern, dass sie ein guter Startpunkt wird. Also die Dummy-Komponenten fix dort schon einbauen und alles Optionale wirklich erstmal auszukommentieren. Dann hätten wir nicht das Problem der Dopplung.

[lucode]

Ja ich denke auch das wäre das beste wie du es vorschlägst.

Noch ein Gedanke zur evcc.dist.yaml im Hauptrepo. Wir könnten überlegen, ob wir die so verändern, dass sie ein guter Startpunkt wird. Also die Dummy-Komponenten fix dort schon einbauen und alles Optionale wirklich erstmal auszukommentieren. Dann hätten wir nicht das Problem der Dopplung.

Hätte den Vorteil, dass man nicht überall den links darauf hinterher rennen muss. Man könnte sich dann ev. überlegen eine Art von blueprints config yaml zu machen (z.b. Kopie von bestehender evcc.dist.yaml ). Für verschiedene Anwendungs Szenarien. Aber dann müssten die dann auch wieder gepflegt werden, oder klar als unsupported zu bezeichnen.

Wann denkt ihr denn dass eine Umstellung auf UI config möglich sein könnte? Spielt hier auch mit rein zur Entscheidungsfindung. Wenn das schrittweise geschieht, müssten dann die config templates immer angepasst werden, d.h. die nicht mehr unterstützte Parameter gelöscht werden.

Ev. könnte eine Tutorial Sektion helfen diesen Transformations Prozess möglichst reibungslos zu gestalten. Nach meinen Erfahrungen mit der Inbetriebname meines neuen OCPP Chargers und des gesamten Systems habe ich festgestellt, dass man als neuer user zu sehr auf die (sehr hilfbereite) Community im Diskussions Forum angewiesen ist. Ein/zwei meiner Fragen habe ich dann nachher auch im FAQ als Antwort gefunden, doch da die FAQ nicht strukturiert sind ist es nicht sehr offensichtlich dort zu suchen. Ich finde Tutorials sind der beste Weg um neuen Usern oder solche die ihre config yaml anpassen müssen Hilfestellung zur Verfügung zu stellen. Man müsste halt dort den Hinweis vermerken, dass sicth nicht alle Tutorials sich auf den aktuellen Stand von evcc beziehen und auch die Version angeben mit der das Tutorial erstellt worden ist. Ich habe für mich schon sehr rudimentäre Tutorials erstellt eines für OCPP und eines für HA mit MQTT.

[lucode]

Ich habe nun eine Konfigurations Doku erstellt und die Home Assistant Seite angepasst. Wenn es so io, kann ich dann noch die Docker Seite und die EN Versionen anpassen.

[naltatis]

Danke für den Umbau. Mir sind das immer noch deutlich zu viele Einstellungen. Poll-Mode, Thresholds, Logging sind alles Themen, die man bei der Ersteinrichtung durchaus ignorieren kann solange man weiß, wo man für mehr suchen muss. Ich hab die Datei noch weiter ausgedünnt.

Suggested change

	## Configuration template with demo entities (meters, chargers) ##
	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
	interval: 30s # control cycle interval. Interval <30s can lead to unexpected behavior, see https://docs.evcc.io/docs/reference/configuration/interval
	# database configuration for persisting charge sessions and settings
	# database:
	# type: sqlite
	# dsn: <path-to-db-file>
	# sponsor token enables optional features (request at https://sponsor.evcc.io)
	# sponsortoken:
	# telemetry enables aggregated statistics
	#
	# Telemetry allows collecting usage data (grid and green energy, charge power).
	# It can be enabled in the configuration section of the UI.
	# log settings
	log: info
	levels:
	site: debug
	lp-1: debug
	lp-2: debug
	cache: error
	db: error
	# 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/devices/meters
	meters:
	- name: my_grid
	type: template
	template: demo-meter
	usage: grid
	power: # optional
	- name: my_pv
	type: template
	template: demo-meter
	usage: pv
	power: # optional
	- name: my_battery
	type: template
	template: demo-battery
	usage: battery
	power: # optional
	soc: # optional
	controllable: # Supports active battery control (optional)
	- name: my_charger-pw
	type: template
	template: demo-meter
	usage: charge
	power: # optional
	# charger definitions
	# name can be freely chosen and is used as reference when assigning charger to vehicle
	# for documentation see https://docs.evcc.io/docs/devices/chargers
	chargers:
	- name: my_charger
	type: template
	template: demo-charger
	status: A # optional
	power: 0 # optional
	enabled: true # optional
	# vehicle definitions
	# name can be freely chosen and is used as reference when assigning vehicle to loadpoint
	# for documentation see https://docs.evcc.io/docs/devices/vehicles
	vehicles:
	- name: my_car
	type: template
	template: offline
	title: # Will be displayed in the user interface (optional)
	capacity: 50 # Battery capacity in kWh (optional)
	# site describes the EVU connection, PV and home battery
	site:
	title: Home # display name for UI
	meters:
	grid: my_grid # grid meter
	pv:
	- my_pv # list of pv inverters/ meters
	battery:
	- my_battery # list of battery meters
	aux: # list of auxiliary meters for adjusting grid operating point
	residualPower: 0 # in W, Target operating point of the surplus regulation at the grid connection (grid meter).
	# Positive values shift the target value towards grid feed-in, while negative values shift it towards grid consumption
	maxGridSupplyWhileBatteryCharging: 0 # ignore battery charging if AC consumption is above this value
	# loadpoint describes the charger, charge meter and connected vehicle
	loadpoints:
	- title: Garage # display name for UI
	charger: my_charger # charger
	meter: my_charger-pw # charge meter
	mode: "off" # default charge mode to apply when vehicle is disconnected; use "off" to disable by default if charger is publicly available
	# remaining settings are experts-only and best left at default values
	priority: 0 # relative priority for concurrent charging in PV mode with multiple loadpoints (higher values have higher priority)
	soc:
	# polling defines usage of the vehicle APIs
	# Modifying the default settings it NOT recommended. It MAY deplete your vehicle's battery
	# or lead to vehicle manufacturer banning you from API use. USE AT YOUR OWN RISK.
	poll:
	# poll mode defines under which condition the vehicle API is called:
	# charging: update vehicle ONLY when charging (this is the recommended default)
	# connected: update vehicle when connected (not only charging), interval defines how often
	# always: always update vehicle regardless of connection state, interval defines how often (only supported for single vehicle)
	mode: charging
	# poll interval defines how often the vehicle API may be polled if NOT charging
	interval: 60m
	estimate: true # set false to disable interpolating between api updates (not recommended)
	# threshold values can be edited via API/MQTT
	enable: # pv mode enable behavior
	delay: 1m # threshold must be exceeded for this long
	threshold: 0 # site power threshold (in Watts, negative=export). If zero, export must exceed minimum charge power to enable
	disable: # pv mode disable behavior
	delay: 3m # threshold must be exceeded for this long
	threshold: 0 # maximum import power (W)
	# tariffs are the fixed or variable tariffs
	tariffs:
	currency: EUR # three letter ISO-4217 currency code (default EUR)
	grid:
	# either static grid price (or price zones)
	type: fixed
	price: 0.19 # EUR/kWh
	zones:
	- days: Mon-Sun
	hours: 7-21 # day
	price: 0.19 # EUR/kWh
	- days: Mon-Sun
	hours: 21-0 # night
	price: 0.12 # EUR/kWh
	- days: Mon-Sun # Night tariffs need to be split
	hours: 0-7 # night
	price: 0.12 # EUR/kWh
	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 pv 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/devices/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/devices/vehicles
	vehicles:
	- name: my_car
	type: template
	template: offline
	title: blue e-Golf
	capacity: 50 # in kWh
	# assign your devices to the site
	site:
	title: Home # display name for UI
	meters:
	grid: my_grid
	pv:
	- my_pv
	battery:
	- my_battery
	loadpoints:
	- title: Garage # display name for UI
	charger: my_charger # charger
	vehicle: my_car # default vehicle
	# enter your real grid tariff and feed-in price
	# see https://docs.evcc.io/docs/devices/tariffs
	tariffs:
	currency: EUR
	grid:
	type: fixed
	price: 0.29 # EUR/kWh
	feedin:
	type: fixed
	price: 0.10 # EUR/kWh

[lucode]

Mache einen sepraten commit daraus.

[naltatis]

Aktuell benutzen wir die Infobox auch an anderen Stellen in der Doku zu inflationär. Dieser Text hier kann eine ganz normale Einleitung sein. Ich würde auch Docker und Home Assistant hier gar nicht explizit erwähnen, sondern eher beschrieben, dass das hier die Seite ist, die erklärt, wie ich an eine funktionierende evcc.yaml komme.

Ich würd die auch in zwei Abschnitte/Unterüberschriften aufteilen: 1. Über Kommandozeilenassistent (evcc configure), 2. evcc.yaml manuell bearbeiten (bestehender Inhalt).

[lucode]

Sorry habe das erst nach dem untenstehenden Kommentar gesehen. Bist du sicher dass es eine gute Idee ist alle Fälle in der gleichen Doku zu präsentieren. Ich denke es ist einiges übersichtlicher es getrennt zu halten.
Auch weil ja die Docker Installationen nicht offiziell supportet werden.

[naltatis]

Die Herrausforderung, dass man händisch Änderungen an der evcc.yaml machen muss oder aus Gründen configure nicht verwenden kann gibt es ja in allen Installationsarten. Natürlich sind die nicht immer gleich "wichtig". Aber unter Installation > Configuration würde ich ja nicht erwarten, dass spezieller Content für Home Assistant kommt. Daher würde ich schon sagen, dass wir das hier allgemein halten sollten und ggf. an den relevanten Stellen Zusatzhinweise für bestimmte Umgebungsanforderungen einfügen können.

[lucode]

Daher würde ich schon sagen, dass wir das hier allgemein halten sollten und ggf. an den relevanten Stellen Zusatzhinweise für bestimmte Umgebungsanforderungen einfügen können.

Kann ich so machen, aber ist noch einmal ein ziemlicher Umbau, müssen ja auch alle links auf die Linux Install./ Konf neu gemacht werden.

[naltatis]

Auch hier zu speziell. Das gilt ja auch für Windows, Linux und andere Installationen. Würde ich einfach weglassen.

[lucode]

Bist du sicher? eigentlich richtet sich die Konfigurations Anleitung explizit an Nutzer von Docker basierten Inst.

:

::note Diese Anleitung richtet sich an Benutzer, die evcc als Home Assistant Addon oder als Docker Container verwenden und deshalb den Konfigurationsassistent nicht verwenden können Die Anleitung enthält aber eventuell nützliche Tipps, für Personen die ihre Konfiguration, nach der Verwendung des Konfigurationsassistenten noch anpassen müssen. ::

Ansonsten wird es zu kompliziert. Und ich denke der Hinweis wo die Datei zu finden ist schon hilfreich.

[naltatis]

Hi @lucode, danke für die Arbeit und entschuldige die verzögerte Antwort. Einige Dateien hast du ja bereits schon ins Englische übersetzt. Die habe ich jetzt nicht noch mal parallelkommentiert.

[lucode]

Werde mich morgen mal dran machen. Bin mir nicht sicher ob du meine commits von letzter Woche auch berücksichtigst hast? Die Änderung mit separater Konfiguration habe ich ja schon gemacht,
https://github.com/HA-projects/docs/blob/main/docs/installation/configuration.mdx

[naltatis]

Bin mir nicht sicher ob du meine commits von letzter Woche auch berücksichtigst hast?

Ich bin das aktuelle Changeset hier im Pull Request durchgegangen. Wenn du das hier hin gepusht hast sollte ich es gesehen haben.

[lucode]

Ich habe nun alle mir bewussten Änderungswünsche commited. Auch die Übersetzung ist nun gemacht.
Kann ev. sein dass ich etwas übersehen habe ;).

[naltatis]

Suggested change

	## Configuration template with demo entities (meters, chargers) ##
	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
	interval: 30s # control cycle interval. Interval <30s can lead to unexpected behavior, see https://docs.evcc.io/docs/reference/configuration/interval
	# database configuration for persisting charge sessions and settings
	# database:
	# type: sqlite
	# dsn: <path-to-db-file>
	# sponsor token enables optional features (request at https://sponsor.evcc.io)
	# sponsortoken:
	# telemetry enables aggregated statistics
	#
	# Telemetry allows collecting usage data (grid and green energy, charge power).
	# It can be enabled in the configuration section of the UI.
	# log settings
	log: info
	levels:
	site: debug
	lp-1: debug
	lp-2: debug
	cache: error
	db: error
	# modbus proxy for allowing external programs to reuse the evcc modbus connection
	# each entry will start a proxy instance at the given port speaking Modbus TCP and
	# relaying to the given modbus downstream device (either TCP or RTU, RS485 or TCP)
	modbusproxy:
	# - port: 5200
	# uri: solar-edge:502
	# # rtu: true
	# # readonly: true # use `deny` to raise modbus errors

Ich würd die Optionen bis hier hin alle rausnehmen. Das ist wieder viel kopierter Text, denn wir mühselig in-sync halten müssen. Hier gehts ja nicht um nen Referenz sondern um ne Mini-Config. Gleiches betrifft natürlich die englische Übersetzung.

[lucode]

Im Prinzip was es schon als Mini Template gedacht, um mit etwas beginnen zu können was ohne Fehlermeldung läuft. Wenn es nur eine Demo ist mit was soll ein Benutzer dann anfangen seine Konf zu erstellen? Ich würde immerhin die Network und Log settings drin lassen.