HOME
Home Assistant Konfiguration
Den Home Assistant(fortan nur noch HA genannt -.-) ruft man im Browser mit http://homeassistant.local:8123 auf.
Man KANN versuchen sich via https zu verbinden, aber bei mir gab es da nur Fehlermeldungen aber keine Verbindung..
Nachdem man sich mit bei dem schicken Begrüßungsbildschirm(bewegliche Sternzeichen!) eingetragen hat..
Ein recht aufgeräumter HA, leider in Denglisch. Entweder Deutsch ODER Englisch, kann doch nicht so schwer sein?
Ein beherzter Klick auf den User "Hejn"..
Und die Sprache umstellen..
Schon wird noch mehr in Deutsch angezeigt.
Aber.. wo wir gerade mal hier sind.. noch einen Punkt ändern:
Aber wozu ist die orange-farbene EINS denn gut?
Wann immer neue Geräte entdeckt werden.. oder das Passwort nicht akzeptiert wurde.. landen diese Meldungen hier.
Die Sprachumstellung erfolgte NACH dem Eintrag in die Logdateien/Benachrichtigungen. Somit bleibt das noch in Englisch..
Folgt man dem Link bei der bunten Eins:
Klickt man nacheinander die einzelnen Konfigurieren Buttons an werden weitere Daten(meist Passwörter/IP-Adressen/Ports) abgefragt und die Geräte aktiviert.
Ein Fehler bei einem UPnP Dings.. verschwindet nach einem Neustart:
Um einige Kernkomponenten zu installieren sucht man via Einstellungen-Addons-Addon-Store den Addon-"Store" auf:
Terminal & SSH ist essentiell für Bastelarbeiten notwendig! (nicht vergessen: Addon zur Seitenleiste hinzufügen!)
Samba Share (habe es IMMER noch nicht genutzt ^^)
Ein paar Ärgernisse vorweg abschalten:
Der Befehl ls muss eigentlich immer als ls -ahl eingegeben werden um auch versteckte Dateien und vor allem ordentliche Listen anzuzeigen.
Der Pfad wird dämlicherweise beschnitten, so weiß man nie WO man eigentlich unterwegs ist..
nano /data/.bash_profile öffnet die Datei zum editieren..
und man fügt folgende Zeilen ein:
export PS1='${debian_chroot:+($debian_chroot)}\[\033[31m\]\u@\h\[\033[m\]:\[\033[36m\]$PWD\[\033[m\]$ '
alias ls="ls -ahl"
Dann via STRG+o zum Speichern(mit ENTER bestätigen)
Nano wird mit CTRL+x beendet.
Das Terminal einmalig mit "exit" schließen.. Beim nächsten geöffneten Terminal sind diese äusserst bescheuerten Fehler behoben..
Nichtunterstützte Geräte können durch "selbstgebastelte" Lösungen eingebunden werden, z.B. Microinverter des Herstellers Deye:
Unter github.com/StephanJoubert kann man eine Zip-Datei herunterladen.
Dazu startet man das Terminal(s.o. Terminal & SSH) und befindet sich zuerst einmal im Ordner /root
Falls er noch nicht existiert muss einmalig der Ordner /config/custom_components/ erstellt werden:
mkdir /config/custom_components/
cd /config/custom_components/ in das neue Verzeichnis wechseln.
wget https://github.com/StephanJoubert/home_assistant_solarman/archive/refs/heads/main.zip die aktuelle Datei(solarman Integration) herunterladen
unzip -d "weg" main.zip entpackt den Kram in einen neuen Unterordner namens "weg"
cd /config/custom_components/weg/home_assistant_solarman-main/custom_components/ In den neu erzeugten Unterordner wechseln..
mv solarman/ /config/custom_components/solarman Die entpackten Dateien zum korrekten Pfad kopieren..
rm -r /config/custom_components/weg Den unnötigen Entpack-Ordner löschen..
rm /config/custom_components/main.zip Und die nun überflüssige main.zip löschen
So, einmal die Konfiguration von HA neu starten lassen(oder komplett neu starten?)
Via Einstellungen-Dienste-Suche kann die neue Integration NICHT gefunden werden.
Man MUSS auf Integration hinzufügen klicken!
In der dortigen Suche kann nun "solarman" eingetragen werden!
VORHER überlegen wie man die Microinverter benennen will!
MUSS es die komplette Typenbezeichnung sein oder will man die nach Standort benennen? (Deye SUN600EU3G/Süddach)?
Diese Bezeichnungen BLEIBEN quasi das ganze Leben so.. auch wenn man die umbenennen kann..
Abgefragt wird unscheinbar der PreFix für die Einheiten. Statt Solarman sollte man dann doch zumindest den Hersteller benennen.
Also z.B. Deye-600 bzw. Deye-2000.
Die Device Serial kann abgefragt werden:
curl -u user:passwort 192.168.1.1/status.html | grep "$dat ="
(Daten anpassen: username:passwort und die IP-Adresse im Netzwerk)
Port bei 8899 und "slave/master" bei 1 belassen.
Die KORREKTE!! yaml auswählen: Microinverter deye_2mppt.yaml bzw. deye_4mppt.yaml
Für weitere Microinverter KEINESFALLS den bereits konfigurierten Dienst Solarman aufrufen und die Werte ändern!!
Stattdessen einen weiteren Dienst via Integration hinzufügen-Solarman,..
Falls die fehlerhafte deye_4mppt.yaml IMMER noch nicht gefixt wurde dies von Hand erledigen(es fehlen die Einträge für Statistik bei PV1,2,4!)
nano /config/custom_components/solarman/inverter_definitions/deye_4mppt.yaml
Die verschiedenen "Karten"
Unter "Dashboard" wird wohl die gesammelte Darstellung von Sensoren verstanden.
Das erste(bereits gefüllte) Dashboard ist die Übersicht. Solange man dieses nicht anrührt werden neu erkannte Geräte automatisch irgendwie dort angezeigt.
Es ist HÄSSLICH, aber dafür kann man in dem Gewusel an Sensoren schnell eigene Inspirationen sammeln.
Weitere "Dashboards" erstellt man über Einstellungen-Dashboards-Dashboard hinzufügen.
Zuerst fügt man ein Dashboard namens "Solar" hinzu, wählt ein ICON das irgendwas mit Solar zu tun hat und fertig.
Schon sollte im linken Menü dieses neue "Dashboard" erscheinen, zuerst ist es genauso zugemüllt wie das aus der Übersicht, aber..
Um Ordnung in das entstehende Chaos zu bringen kann man auf drei "Überkarten" zurückgreifen:
* Horizontale Stapel(nebeneinander)
* Vertikale Stapel(übereinander)
* Raster (man kann die Spaltenanzahl angeben 1..4(je mehr Spalten umso kleiner und unbrauchbarer sind die Unterkarten..)
In diese Karten kann man dann Unterkarten einfügen.
Wer die Gauge-Karte nutzt findet schnell die Besonderheiten heraus:
Zeiger darstellen? Klar!
Schwellwerte definieren? Ja! (je nach Einstellungen sind farbige Bereiche möglich von blau-grün-gelb-rot)
Karten als Quadrate darstellen? Nicht unbedingt, die rechteckigen sparen Platz!
Minimum und Maxima vorgeben.. Klar, kann ich aber nicht erklären, selber probieren ;)
Im folgenden Beispiel die "Grenzwerte" jeweils von den kleinen 600W und den mittleren 2kW Invertern:
| Entität | min. | max. | grün | gelb | rot | Minimum | Maximum |
|---|
| PV1/PV2/PV3/PV4 voltage | 20.0V | 60.0V | 20 | 55 | 60 | | 70 |
| PV1/PV2/PV3/PV4 current | 0.0A | 12.5A | 1 | 12 | 13 | | 15 |
| AC Voltage | 184.0V | 256.0V | 207 | *195 | 253 | 184 | 265 |
| AC Grid Current | 0.0A | 9.6A | 0 | 9 | 10 | 0 | 12 |
| Output Frequency | 49.8Hz | 50.2Hz | 49 | 48 | 51 | 48 | 52 |
| Total Output Power(active) | 0W | 2200W | 10 | 2000 | 2200 | 0 | 2300 |
| Radiator Temperature | -40°C | 65°C | 10 | 2000 | 2200 | -40 | 70 |
Für die kleineren Microinverter(600G3 EU) sieht das Datenblatt maximale Werte vor, die man gleich in die Gauges einbaut:
Die nominale maximale Leistung liegt bei 600W, die totale maximale Leistung endet bei 660W.
10 W Leistung sollte als unterster Wert angegeben werden, also wird grün auf 10 gesetzt.(alles darunter ist dann blau).
Ab 580W Leistung wird gelb hinterlegt und ab 640W wird rot eingestellt.
Was noch fehlt ist das Maximum, ohne Eintrag wird hier 100 angenommen was doch etwas zu gering ist also auf 700 setzen.
Auch für current(Ampere) gibt es ein Maximalwert, hier liegt er be 10.5A was man so nicht eingeben kann da keine Kommazahlen angenommen werden.
Egal:
Code-Editor
Der Code hat einen SEHR ungewohnten Syntax.. und pieselt sich schon an wenn man versehentlich TAB genutzt hat statt Leerräume mit Leerzeichen zu füllen..
Dennoch ist ein geübter Umgang damit Gold wert.. WENN man denn den Syntax erfasst hat: Eben mal ein paar Karten des Typs "Gauge" kopieren MIT deren Grenzwerten?
Kein Problem, wenn man damit umzugehen weiss..
In diesem Beispiel öffnet der obere "Code-Editor" die gesamte gerade ausgewählte Karte(nicht die übergreifende "Bedingungen" sondern deren "Karte")
Der mittlere "Code-Editor" öffnet die gerade ausgewählte Unterkarte(hier 1 von 17).
Und der untere "Code-Editor" öffnet die Gesamtansicht
Terminal
Veränderungen können auf drei Wegen erfolgen:
*1) Physisch entnimmt man die Speicherkarte(bei einem RaspberryPi-Aufbau, etc.) und beschreibt die in einem anderen Rechner und stopft die dann wieder zurück
*2) IRGENDWIE(k.A. klappte nicht -.-) via FTP im Netzwerk
*3) via emuliertem Terminal AUF dem RaspberryPi über das lokale Netzwerk von einem anderen Computer aus(Browser)
Alle drei Lösungen haben Vor- und Nachteile..
Arbeiten mit BEKANNTEN Editoren sind toll, aber dafür ständig die Karte rausnehmen, hin und her laufen?
Das SEHR gewöhnungsbedürftige Terminal zwingt zum Umdenken, da die einzigen installierten(installierbaren!!) Editoren vi und nano sind..
Eigene "Sensoren" definieren
Allen Ernstes soll man das von Hand in die configuration.yaml eintragen?!!
Ein paar Codebeispiele:
# Loads default set of integrations. Do not remove.
default_config:
# Load frontend themes from the themes folder
frontend:
themes: !include_dir_merge_named themes
# Text to speech
tts:
- platform: google_translate
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
template:
- sensor:
# Gesamtverbrauchsberechnung Shelly aus der Summe der drei Phasen
- name: phase_total
unit_of_measurement: "W"
state: "{{ (states('sensor.l1_power') | float) + (states('sensor.l2_power') | float) + (states('sensor.l3_pv_power') | float) }}"
state_class: "measurement"
icon: "mdi:solar-power-variant-outline"
Diese Definitionen sind sehr.. pingelig. Einrückungen MÜSSEN eingehalten werden. Ein Leerzeichen zu viel oder zu wenig..
Anführungszeichen weglassen KANN funktionieren. Leitet jedoch ein Anführungszeichen z.B. einen Namen ein und das "Abschluss"-Zeichen fehlt.. FEHLER.
Doppeltes oder einfaches Anführungszeichen?
Der obere Teil ist Standartvorgabe der configuration.yaml.
template: leitet die Template-Definition eingeleitet(EINMALIG zu verwenden!).
- sensor: PREFIX für die folgenden Variablen, EINRÜCKUNG und das Leerzeichen zwischen dem - und sensor: beachten!
- name: der Name der neu definierten Eintität, KEINE Leerzeichen im Namen erlaubt!
# leitet Kommentare ein die ignoriert werden
unit_of_measurement: "W" Angabe der Maßeinheit(hier eben W für Watt)
state: leitet die Berechnung ein die in der "Variablen" angegeben unter - name: gespeichert werden soll.
Die etwas WIRRE Definition dahinter berechnet sensor.l1_power + sensor.l2_power + sensor.l3_pv_power, also die Summe aller Phasen.
Der Shelly zeigt(bei korrekt gesetzten Stromzangen) bei Verbrauch NEGATIVE Werte an.
Erscheint seltsam da der Zähler im Schaltschrank ja auch "positiv" summiert.
Gutgläubige Menschen die einen Fehler bei der Installation vermuten suchen im Internet nach diesem Phänomen und glauben an einen Installationsfehler -.-
Lässt man also gegen klingende Münze diese Zangen umdrehen(von der freundlichen Elektrikkraft) sind die Werte nun positiv.
Braucht man die Werte aber UNBEDINGT negiert bleiben nur zwei Lösungswege:
1.) Stromzangen ERNEUT umdrehen lassen und vor den Elektrikern als Volldepp dastehen.
2.) Oder neue Entitäten definieren und dort die (falschen) Messwerte umkehren lassen
# Invertierungsdefinition wenn die Messzangen nicht gedreht werden können
- name: "l1_inverted_name"
unique_id: "l1_inverted_unique"
unit_of_measurement: "W"
state: "{{ -1* (states('sensor.l1_power') | float) }}"
state_class: "measurement"
icon: "mdi:solar-power-variant-outline"
Automation!
Der Homeassistant wird laufend weiter entwickelt.
Sowohl Design als auch Herangehensweise(liebevoll von mir dargestellt) gehört schnell der Vergangenheit an -.-
Meine erste Automation diente dazu den Homeassistant jeden Tag abends neu zu starten.
Grund sind die(fehlerhaften) Restdaten der DEYE-Microinverter:
Sinkt die Sonne abends übermitteln die Inverter brav die letzten Werte.. jedoch(fast nie!) den Null-Wert.
Stattdessen sieht man in der Statistik z.B. eine Leistung von 2W (die ganze NACHT durch!!)
Als kleines Extra soll diese Automation eine halbe Stunde nach Sonnenuntergang(lokal abhängig!) einmal ausgelöst werden..
Klappte wunderbar: Sobald HA neugestartet wurde waren die Werte der nun nicht mehr vorhandenen(da dunkel!) Inverter unbekannt.. und tauchten NICHT mehr auf ^^
War vielleicht der falsche Weg, funktionierte aber so wie ich das wollte.
Einspeisung in das Netz deaktivieren wenn Batteriewert zu gering ist..
Beispiel hier Anker Solix 2 E1600 Pro
Mein erster Batteriespeicher begeistert mich(2024):
+ Kapazität erweiterbar je nach Geldbeutelinhalt..
- Sobald die Kapazität der (aller?) Batterien auf 5% abgefallen ist geht das E1600 in den "Schlafmodus" und ist nicht mehr via HA erreichbar -.-
+ man kann eine Reservekapazität von 10% einstellen.. doch:
- auch dann fällt langsam aber sicher die Kapazität(auch ohne Frost/Heizung!!) ab und plötzlich sind die blöden 5% erreicht(und damit der Schlafmodus aktiv)..
"Schlau" wie ich bin habe ich mir das System erst Ende Oktober zugelegt.. mit den daraus resultierenden Problem: In Wintermonaten ist Sonnenschein echt rar -.-
Darum möchte ich eine höhere Reservekapazität vorhalten, doch wie?
Könnte man nicht mit HA eine Automatisierung basteln die z.B. bei einer Kapazität von unter 1600Wh die Ausgangsleistung reduziert(auf Null setzt)?
* Man kann das E1600 mit einem in den Sicherungskasten verbauten 3Phasen-Messgerät(original von Anker bzw. Shelly 3em/pro) koppeln..
..und damit den "Benutzermodus" zwischen Manuell(Einspeisevorgabe) und Smartmeter(automatisch) wechseln..
HA gibt mit der Integration den Benutzermodus(s.o) vor, den man in HA ändern kann!!
Ebenso ist dort eine System Einspeisevorgabe vorhanden, deren Slider man auf 0 setzt.
Es geht auch mit der Anker App: einen täglichen Plan erstellen der von 0 bis 24 Uhr eine Einspeisevorgabe von 0W (NULL) hat.
ACHTUNG!
Je nachdem welchen Anker-Account man HA zugewiesen hat.. erscheinen diese Vorgaben(oder auch nicht).
Schlimmer ist jedoch.. solange HA Zugriff auf den Haupt-Account hat.. wird man alle paar Minuten aus der Anker App geworfen..
Aber jetzt endlich zu der gewünschten Automation:
Wenn die Akkukapazität KLEINER als 1600Wh ist.. dann soll keine Einspeisung mehr erfolgen.
Die Einspeisevorgabe hat hier ja nur zwei Möglichkeiten: manuell(0W) und Smartmeter.
HomeAssistant:Einstellungen Automatisierungen & Szenen Automatisierung erstellen NEUE Automatisierung erstellen
Sobald
* Auslöser hinzufügen klicken
* Entität wählen!
* numerischer Zustand wählen
* Entität wählen(die Anker Integration benennt diese Entität unterschiedlich, am Namensende steht aber _akkuenergie)
* Das ATTRIBUT FREILASSEN(X), sonst würde der maximale Kapazitätswert übergeben 6.400Kwh z.B.
* Untergrenze auf 5600 setzen(in Wh, also die 5600Wh entsprechen 5,6kWh!)
* Speichern (vorgegebener Name) Sobald E1600pro Akkuenergie unter 5600W ist
Eine zweite Abfrage ist eine GUTE Idee, somit wird diese Automation nicht alle paar Millisekunden ausgeführt:
Und wenn(optional)
*Bedingung hinzufügen
*Gerät E1600pro wählen(oder wie das auch immer benannt wurde)
*Bedingung Aktuell ausgewählte Option von E1600pro Benutzermodus
*Option: smartmeter (also nur wenn Akkukapazität unter Wert x gefallen UND aktuelle Option smartmeter ist!!)
Jetzt zur Aktion die dann ausgelöst werden soll:
Dann
* Aktion hinzufügen
* Gerät: E1600pro
* Aktion: Ändere die Option E1600pro Benutzermodus (die Vorauswahl überschreiben)
* Option: manual
Speichern und fertig!
Mehrere Fehler(Fehlinterpretationen) die beachtet werden sollten:
Im Beispiel soll ein Ereignis ausgelöst werden, wenn die Kapazität der Akkus 1.6kWh unterschreitet..
1.) Der zu prüfende Wert muss in Wattstunden angegeben werden also 1600(und NICHT 1,6!!).
....Nicht GANZ korrekt, der letzte Wert(bei meiner Anlage) liegt bei 1664Wh, ist dieser unterschritten liegt man der "gewünschten" Restkapazität
2.) Ist die aktuelle Kapazität GLEICH dem vorgegebenen Schwellwert passiert NICHTS, weil die Logikabfrage KLEINER als lautet..
....Eine aktuelle Kapazität von 1600 ist nicht kleiner als der Schwellwert von 1600 sondern GLEICH..
3.) Erst wenn eine ÄNDERUNG des aktuellen Kapazität stattfindet wird die Prüfung durchgeführt und gegebenenfalls die Befehle der Automation ausgeführt.
Und ich verzweifelte stundenlang, hatte sogar den Schwellwert ÜBER die aktuelle Kapazität gesetzt.. einfach die nächste Kapazitätsänderung abwarten und freuen!
Man kann das beschleunigen(zu Testzwecken) indem man die System Api Nutzung manuell aus- und wieder einschaltet.
Dabei werden die Werte neu eingelesen(das gilt als Änderung?!!) und die Automatisation wird getriggert.
Nachteil: Für einen Augenblick gehen alle Werte verloren(da Anbindung unterbrochen)
Für später: Anpassung je nach Sonne/Kapazität/Last...WIP!
Die Energieverteilung KÖNNTE man jeden Tag von Hand anpassen.. doch weiß man welches Wetter und welche Bedeckung am Himmel herrscht?
SEHR enttäuscht bin ich vom DWD.. selbst die nächstgelegene Station meldet Sonnenschein.. und hier ist komplette Bedeckung!
Oder gar umgekehrt.. es werden 2 Sonnenstunden mit ca. 85% Bedeckung vorhergesagt.. und es war 4 Stunden lang sonnig(4kWh Ertrag).
Ich versuche das Problem mal zu beschreiben:
Schlechtwetter vorhergesagt:
Um die Akkus nicht sinnlos zu entladen(weiß man wann das Schlechtwetter vorbei ist?) wird die Einspeisevorgabe auf 0 gesetzt und der Akku mit dem spärlichen Lichtresten geladen.
Man behält sich 50% Restkapazität im Akku damit man die dunklen Tagen teilweise ausgleichen kann..
Und dann reißt die Wolkendecke auf, die Sonne scheint überraschend stundenlang!!
Mit Einspeisevorgabe:0 wird erst mal alles in die Akkus geladen. Nur Überschüsse(gemäß maximal vorgegebener Einspeiseleistung(350W/600W/800W)) gehen in das Hausnetz.
* maximale Einspeiseleistung(350W/600W/800W) begrenzt den eingespeisten Strom(in das Netz) auf die ausgewählte Wattzahl.
* Einspeisevorgabe gibt an wie viel Watt konstant in das Hausnetz eingespeist werden SOLLEN(aus den Akkus/Solar).
Nun kann es passieren das bei GUTEM Wetter der Akku tatsächlich mal voll geladen wird, dann passiert aber Folgendes..
.. kurz vor Erreichung der maximalen Kapazität wird die Ladeleistung zurück genommen indem die MPPTs abgeriegelt werden.
TROTZ voller Sonne haben die Solarmodule plötzlich nur noch 40-60W Leistung(pro Modul).. damit die Akkus nicht überladen werden.
ABER der Rest der eingestrahlten Sonnenleistung geht komplett verloren! Nichts wird eingespeist, der winzige Rest wandert in die Akkus..
Diese Seite wurde zuletzt am 19.11.2024 um 23:04 geändert.
(c) 2024 DHLF ☮🇺🇦