Epic: UI-based config

[andig]

UI-based configuration is probably the single biggest game changer that we need to make evcc more approachable for non-technical users. This will be a large change and time-consuming. To keep seeing results we should develop an incremental roadmap that delivers usable results and can be shipped step by step. This issue should structure the work.

• Single, new devices for testing only (Add configuration api #6035)
  Scope: template devices only, no linked config, no modbus. This can be done standalone without touching bigger parts of the application and will already allow users with demo installation to play with things.
• Modify existing config, save config (Add support for loading and storing device configuration from/to database #6199)
• Vehicles use case (these should be pretty easy and not not need be linked to other parts of the config)
• API: use of stable IDs (vehicle, charging point, ...) instead of indices (FeatureRequest/API: liste aller loadpoints / loadpoint-id #8646)
• Meters in combination with site (Add site config api (BC) #9812)
• loadpoint settings (UI: Make loadpoints configurable #12903)
• vehicle settings (UI: Make vehicles fully configurable #12905)
• Creating loadpoints plus chargers in combination with loadpoints
• Device lifecycle (Devices: add lifecycle #11572)
• Security: add authentication (e.g. admin password) for changing device settings (Config UI: Add authentication #11732)
• Allow starting with a grid (or pv) meter being configured (Grid meter optional: improved no-solar use case, UI configuration #14341)

More stuff to break into steps:

• tariffs (Add tariff templates #9820, Add tariffs configuration #10042)
• mqtt, influxdb, modbus, modbus proxy, push messages Config UI: add missing config sections / partial yaml inputs (BC) #13319
• remaining site settings Config UI: add missing config sections / partial yaml inputs (BC) #13319

Challenges:

• integrate "online" with "offline" config to still allow using complex configs
• make things "pluggable" and implement restart behaviour for all classes of devices
  • vehicles (Experimental: neues Fahrzeug wird erst nach Neustart angezeigt #9669)
  • meters
  • chargers
  • tariffs
• add option to use configure a meter-template outside of its labled usage (e.g. a charge meter as aux meter see Add aux meter templates #11887)

Smaller Todos:

• move dirty api to web socket
• move site meters to global config, identified by type (grid, pv, battery, aux)
• show/update meter configuration when device fails during startup
• allow saving broken devices (RCT)

[naltatis]

Ja, das ist alles noch "exerimental" 😄
Geht hier erstmal darum die Funktionalität an die Oberfläche zu bekommen.

[Hofyyy]

Auf die Gefahr hin das ihr das schon kennt. Ich bin von genau so einem Dialog bei der Weboberfläche "homebridge" sehr angetan. Speichern führt eine Validierung durch und speichert nur, wenn das Schema passt. Vielleicht kann man sich dran anlehnen, oder es hilft beim abgucken.

[andig]

move site meters to global config, identified by type (grid, pv, battery, aux)

@naltatis das ist nicht so einfach, da nicht alle Zähler einen Typ haben. Usage dient nur dazu, bei integrierten Geräten die richtigen Werten abzugreifen. Sonst spezifiziert erst die Auswahl in Site, wofür der Zähler verwendet werden soll.

[naltatis]

@naltatis das ist nicht so einfach, da nicht alle Zähler einen Typ haben. Usage dient nur dazu, bei integrierten Geräten die richtigen Werten abzugreifen. Sonst spezifiziert erst die Auswahl in Site, wofür der Zähler verwendet werden soll.

Das wir dafür eine neue Eigenschaft am Zähler brauchen, hatte ich auf dem Zettel. Vielleicht ein guter Anlass das mit den Meter-Titles #6781 auch anzugehen 😄.