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

lucode · 2024-09-22T13:23:57Z

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

Add section in Home Integration over REST API

Add, Installation Home Assistant and Proxmox EN

naltatis · 2024-09-30T17:12:23Z

docs/installation/conf_templates/ha_evcc_template.yaml

@@ -0,0 +1,317 @@
+## Configuration template with demo entities (meters, chargers) ##


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.

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

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?

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.

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.

Add, Section configuration

lucode · 2024-10-05T16:04:48Z

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 · 2024-10-14T13:55:10Z

docs/installation/configuration.mdx

+    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


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

Mache einen sepraten commit daraus.

docs/installation/configuration.mdx

naltatis · 2024-10-14T14:02:25Z

docs/installation/configuration.mdx

+:::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.
+:::


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).

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.

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.

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 · 2024-10-14T14:03:29Z

docs/installation/configuration.mdx

+```sh
+- config_file Docker:  `/etc/evcc.yaml`
+- config_file Home Assistant: `/config/evcc.yaml`
+```


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

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.

docs/installation/configuration.mdx

docs/installation/proxmox.mdx

docs/integrations/home-assistant.md

.../en/docusaurus-plugin-content-docs/current/installation/conf_templates/ha_evcc_template.yaml

i18n/en/docusaurus-plugin-content-docs/current/installation/home-assistant.mdx

docs/installation/home-assistant.mdx

docs/installation/index.md

docs/installation/manual.mdx

naltatis · 2024-10-14T14:20:49Z

docs/installation/proxmox.mdx

+:::note
+Proxmox ist eine Virtualisierungs-Platform, welche ein sehr einfaches evcc Hosting ermöglicht.
+Die folgende Installation wurde mit Ubuntu 24.4 getestet!
+:::


Keine Ausrufezeichen 😄
(und Infobox)

naltatis · 2024-10-14T14:22:58Z

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 · 2024-10-14T15:22:20Z

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 · 2024-10-14T17:48:34Z

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.

typo Co-authored-by: Michael Geers <[email protected]>

lucode · 2024-10-15T12:34:46Z

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

Adding templates examples and the HA automations.

naltatis · 2024-10-21T06:41:09Z

docs/installation/configuration.mdx

+## 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


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.

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.

docs/installation/docker.mdx

docs/installation/configuration.mdx

Co-authored-by: Michael Geers <[email protected]>

Adding title to YAML content

…tion

…on wizard too, deleting and linking installation processes to the conf file

docs/installation/home-assistant.mdx

docs/installation/linux.mdx

naltatis · 2024-10-24T22:03:38Z

docs/installation/linux.mdx

+
+Es wird eine **funktionierende** evcc Konfiguration benötigt.
+
+Folge nun der [Anleitung](./configuration#konfiguration-mit-konfigurationsassistenten) zur Erstellung einer Konfiguration mit dem Konfigurationsassistenten.


Ich würde hier weiterhin den evcc configure Befehl erwähnen und auch den Linux spezfischen Flow (Datei an den richtigen Ort kopieren, Service neu starten, prüfen obs passt) hier drin der Anleitung drin lassen und dann zusätzlich auf die Konfigurationsseite (wenn man mehr wissen will, alternative Wege) verlinken. Das Thema --advanced würde ich dann bspw. nur auf der dedizierten Konfigurations-Seite sehen.

naltatis · 2024-10-24T22:04:19Z

docs/installation/linux.mdx

-  ```
-
- Gehe zurück zum Browser und lade die evcc Seite neu. Die Oberfläche sollte nun mit deinen konfigurierten Geräten zu sehen sein.
-
 ## Aktualisierung


Aktualisieren sollte nach Konfiguration bleiben.

naltatis · 2024-10-24T22:08:48Z

docs/installation/configuration.mdx

+:::
+
+
+## Konfiguration mit Konfigurationsassistenten


Suggested change

## Konfiguration mit Konfigurationsassistenten

## Konfiguration mit Konfigurationsassistenten

Das ist sehr lang das Wort "Konfiguration" taucht häufig auf (h1, 2x h2). Was hälst du von

## `evcc.yaml` mit Assistent erstellen

und

## `evcc.yaml` manuell erstellen

naltatis · 2024-10-24T22:10:14Z

docs/installation/configuration.mdx

+
+  ```sh
+  sudo systemctl start evcc
+  ```


Das ist Linux spezifisch. Ich würd das hier kürzer halten. Das Testen der Datei gehört hier mMn noch rein. Auch wo der Assistent die Datei hinlegt. Aber der rest ist dann wieder Thema der jeweiligen spezifischen Anleitung.

So hab ich das nicht gemeint. Mit dem Kommentar ging es mir darum, dass wir auf dieser generischen "Konfigurations-Seite" nur das Thema behandeln wie man eine evcc.yaml erstellen kann. Wie man die in Anwendung bringt (richtiger Speicherort, Dienst neu starten) ist abhängig von der Installationsart (Linux, Mac, Docker, Windows, ...). Das würde ich hier komplett raushalten.

naltatis · 2024-10-24T22:11:33Z

docs/installation/macos.md

-
-  ```sh
-  brew services start evcc
-  ```


Siehe Linux Anleitung. Die Grundlagen sollten inline in der Anleitung bleiben. Fortgeschrittenes dann verlinken.

naltatis · 2024-10-24T22:13:41Z

@lucode Danke, dass du hier dranbleibst! Beim nächsten PR sollten wir gucken, dass wir die Änderungen kleinteiliger (lieber mehrere kleine PRs als einen großen) angehen. Dann bekommen wir die Änderungen auch schneller durch.

Co-authored-by: Michael Geers <[email protected]>

shorter title in configuration.mdx make section "configuration-with-wizard" compatible to Linux/MacOS

naltatis · 2024-11-01T15:19:59Z

replaced by #657

lucode added 4 commits September 17, 2024 18:11

Add, Home Assistant and Proxmox Installation

db85053

Add section in Home Integration over REST API

7fb1d1f

Add, Installation Home Assistant and Proxmox EN

587b5c2

Merge branch 'evcc-io:main' into main

31ecebf

naltatis reviewed Sep 30, 2024

View reviewed changes

naltatis added documentation Improvements or additions to documentation enhancement New feature or request labels Sep 30, 2024

lucode added 3 commits October 5, 2024 17:00

Update, Installation Home Assistant

ecd8671

Add, Section configuration

Merge remote-tracking branch 'origin/main'

52d859b

Update, Installation Home Assistant

14f3943

Add, Section configuration