evcc
evcc copied to clipboard
evcc-io
Home Assistant MQTT discovery
As discussed in https://github.com/evcc-io/evcc/discussions/2939
docker-compose.yml used for testing:
version: '3'
services:
homeassistant:
container_name: homeassistant
image: "ghcr.io/home-assistant/home-assistant:stable"
volumes:
- ./config:/config
- /etc/localtime:/etc/localtime:ro
restart: unless-stopped
#privileged: true
network_mode: host
mosquitto:
image: eclipse-mosquitto
network_mode: host
restart: unless-stopped
volumes:
- ./mosquitto.conf:/mosquitto/config/mosquitto.conf
# mosquitto.conf
### listener 1883 0.0.0.0
### allow_anonymous true
Screenshots from HA:
Zur Vervollständigung der setter müsste ich noch die folgenden Werte hinzufügen
- residualPower (site)
- minCurrent (loadpoint)
- maxCurrent (loadpoint)
- phases (loadpoint) Da ich leider ein min und max wert angeben muss (sonst ist das bei default 0 und 100) und ich diese Felder bisher nicht verwendet habe bin ich mir nicht sicher was ich hier verwenden sollte.
Grade bei residualPower wären ja vermutlich auch recht große Werte möglich.
Ich denke, wir sollten das in dieser Form aktuell nicht machen. Ggf finden wir zu späterem Zeitpunkt nochmal eine bessere Story, wie wir evcc Properties besser und für verschiedene Plattformen publishen können.
Hallo, ich habe den PR nicht gereviewed und kann daher nicht nachvollziehen ob du ihn wegen Designproblemen oder aus anderen Gründen geschlossen hast. Ist dir der spezifische Bezug auf Home Assistant nicht recht? Wenn du mit "Story" eine user story bzgl. einer Heimautomatisierung-Integration meinst sollten wir das auf jeden Fall in #2939 diskutieren. Woran lags? :)
Der PR fügt viel Code (für den wir keinen Maintainer haben) und zusätzliche, spezifische Funktionalität hinzu. Diesen Weg weiter zu gehen generiert ein Wartungsproblem.
In https://github.com/evcc-io/evcc/pull/4070 haben wir ganz vorsichtig mit https://github.com/evcc-io/evcc/blob/master/core/const.go angefangen, publizierte Werte aus dem Code zu extrahieren. Sinnvoll wäre jetzt, hier Metainformationen hinzuzufügen für:
- Dokumentation
- Publizieren für verschiedene Plattformen (wie hier HA)
Auf der Basis liessen sich dann spezifische Publisher umsetzen ohne für jeden Einzelwert neuen Wartungsaufwand zu erzeugen.
Ja schön war die Implementierung so tatsächlich nicht.
Es wäre halt echt cool wenn eine eine zentrale Stelle geben würde die alle Parameter und Statuswerte bereitstellt (idealerweise inklusive Metainformationen). Ich hatte tatsächlich schon darüber nachgedacht das selbst umzusetzen allerdings fehlt mir hier der Überblick über den Kern der Software und aktuell auch die Zeit.
@andig Wenn die Grundlagen geschaffen sind kann ich gerne einen neuen Versuch wagen.
Das halte ich auch für sinnvoll, ist wohl aber definitiv etwas für die Core Entwickler.
In Home Assistant (immer eine gute Design Inspiration) wird ähnliches übrigens direkt über Objekte gehandhabt. Neben einem Wert hat jeder Datenpunkt einen ganzen Satz an Metainformationen (letztes Update, Einheit, ...). Wäre es sinnvoll hier ähnlich zu verfahren? https://github.com/home-assistant/core/blob/dev/homeassistant/components/number/init.py#L189
Der const.go Ansatz kann ähnliches erreichen und ist vermutlich einfacher nachzurüsten. Probleme sehe ich bei dem Disconnect von Datenstrukturen und Metadaten hinsichtlich dynamischen Elementen. Wie würde man mehere loadpoints oder konfigurierte Fahrzeuge sinnvoll via const.go beschreiben? Zwangsläufig würde der HA Publisher daher wieder Metainformationen, Daten und proprietäres Wissen lokal mischen... 🤔 Ergibt das Sinn?