Da ich erst SolarAssistant und danach irgendwann HA bekam, kann ich Dir leider nicht helfen ... sorry
Ich habe mir auch nur per YT usw. die MQTT und Raspi Sachen angeeignet und bin da leider kein Profi / Fachmann,
daher war ich froh dass es mit SA und HA so rel. problemlos ging.
PS: Ich bin sowohl von der Oberfläche, als auch wegen der Stabilität des Systems, weil es komplett ohne Cloud und Wifi / "China-Spy" absolut lokal rennt,
und auch wegen des Support`s absoluter SolarAssistant Fan 
.
2 Stück 8 K Deye mit 25 kwp und 24 kwh Pylontech, Solarassistant auf RS232 und HA auf Raspi4, Go-E WB
Hallo @Solarmik, ich kann dir leider auch nicht sagen, wie du Deye über LAN-Kabel mit HA verbinden kannst. Ich kann dir aber sagen, wie ich es gemacht habe. Ich habe den mitgelieferten Wlan Dongle verwendet, der Dongle muss nicht mit dem Internet kommunizieren, nur mit dem Heimnetzwerk verbunden werden. Dann bei HA HACS installieren, das hast du sicher schon gemacht und die Solarman Integration, also Solarman App brauchst du nicht. Es gibt genug Videos im Netz, wie man Solarman-Integration auf HA installiert, es ist wirklich nicht schwer. In der Solarman-Integration sind alle relevanten Daten vom Deye enthalten, wenn das nicht reicht, dann kann man über die yaml-Datei die gewünschten Register einfügen. Die Daten werden alle 30 Sekunden aktualisiert, ich denke das sollte für die Steuerung der Wallbox ausreichen.
An alle die Bagges Platine / YAML-File nutzen ...
Ich habe festgestellt das das BMS teilweise nur sehr langsam Werte richtung HA anpasst / sendet. Ich verstehe speziell den Teil mit den Seplos-Sensoren nicht(meine Wissenslücke), weil Bagges da Code aus zwei Quellen zusammen gefügt hat per source - Option.
Konkret hatte ich das bei einer Automatisierung mit dem SoC vom BMS bemerkt. Zum Wechselrichter scheint die Aktualisierung per CAN zu funktionieren. Aus dem WR kann ich jeden einzelnen %Schritt sehen. In HA passiert manchmal lange garnicht und dann springt der SoC plötzlich um 20%.
Aus der Errinerung habe ich mich glaube ich auch schon mal über den Ladestrom gewundert das der sich so garnicht ändert ...
Ist das bei Euch auch so? Muss ich das BMS mal neu starten?
Ansonsten funktioniert alles wie es soll - also kein Mission Critical Problem 
. und in diesem Zuge nochmal Danke an Bagges !!
Grüsse Leiner
@leiner kommt halt immer drauf an, wie schnell deine Lösung die Daten auslesen kann, per WLAN geht es langsamer, als per RS485 und auch dort bedarf es einiger Tuning Optionen, damit wichtige Werte schneller gesammelt werden in HA. Aber um 20% springen sollte es bei einem großen Akku (14kWh) auf keinen Fall. Da ist dann was foul.
@amiko Danke, das hilft mir schon mal weiter! Ich bin schon ganz wirr im Kopf, weil es dermaßen viel gibt. Ab und zu sehe ich dich ja auch in anderen Foren, du scheinst ja recht aktiv zu sein. Ich fange mal an, würde aber gern KellerZA verwenden.
@leiner kommt halt immer drauf an, wie schnell deine Lösung die Daten auslesen kann, per WLAN geht es langsamer, als per RS485 und auch dort bedarf es einiger Tuning Optionen, damit wichtige Werte schneller gesammelt werden in HA. Aber um 20% springen sollte es bei einem großen Akku (14kWh) auf keinen Fall. Da ist dann was foul.
NA ja Bagges Platine ist per WLan an meinem Netz.
Die Daten vom WR kommen soweit ich das beurteilen kann zuverlässig in HA an. Dem WR meldet das BMS auch per CAN den SoC den ich dann am Display vom Deye sehen kann und unter "sensor.sun10k_battery_capacity" gerundet zuverlässsig sehe.
Nur die RS485 vom Seplos scheint zu klemmen.
Wie zum Hohn sind die Sprünge von neulich auch heute deutlich kleiner aber immer noch da. Und dabei wäre durch die zehntel ja sogar eine glattere Kurve möglich.
Hier mal noch etwas log. Die Warnung wiederholt sich immer mal wieder:
[08:49:46][I][seplos_bms:030]: Telemetry frame (81 bytes) received
[08:49:56][I][seplos_bms:030]: Telemetry frame (81 bytes) received
[08:49:56][W][component:237]: Component seplos_modbus took a long time for an operation (51 ms).
[08:49:56][W][component:238]: Components should block for at most 30 ms.
[08:50:06][I][seplos_bms:030]: Telemetry frame (81 bytes) received
Aber wie gesagt, Funktion BMS-WR funktioniert. Der Rest ist jammern auf hohem Niveau
Grüsse Leiner
Hi @solarmik !
Warum willst Du unbedingt die Lösung von KellerZA umsetzen? Hat das irgendeinen speziellen Grund?
Ich beschäftige mich mit dem Thema "HomeAssistant & Deye-Einbindung" nun seit bald zwei Jahren und hab die Lösung von Klatremis erfolgreich im Einsatz.
Bei mir sind 2 Deye SUN-10K-SG04LP3 im Einsatz, die ich über diese Lösung sowohl 'auslesen' als auch 'steuern' kann.
Für diese Variante ist natürlich neben dem eigentlichen HomeAssistant und entsprechender Hardware (bei mir auf einem Proxmox-Server) noch weitere Hardware erforderlich.
In meinem Fall pro Deye je 1 ESP32 und 1 RS485 to TTL Adapter + entsprechender Verkabelung zwischen Deye und ESP. Details dazu sind auf der github-Seite von Klatremis ersichtlich.
Zwischenzeitlich habe ich auch schon andere System ausprobiert, die noch einfacher über den WLAN-Stick-Logger funktionieren aberr halt nur lesend'.
Hier ist neben der HomeAssistant-Hardware keine zusätzliche Hardware erforderlich.
Empfehlen kann ich hier die Lösung von StepahnJoubert. Auch hier ist die Vorgehensweise auf dessen github-Seite beschrieben.
Vor kurzem habe ich aber die Lösung von davidrapan entdeckt, welche auf der von StephanJoubert aufbaut aber meiner ersten Einschätzung nach noch besser funktioniert! Außerdem soll die Lösung nicht nur lesen sondern auch schreiben können - also quasi Einstellungen & Konfigurationem am Deye nicht nur direkt am Display sondern via HomeAssistant durchführen zu können!
Sollte David die 'Schreib-Funktion' demnächst umgesetzt haben und die wesentlichsten Parameter vorhanden sein, werde ich definitiv auf dies Lösung umsteigen.
Warum: Keine zusätzlichen ESP's + Adapter + Verkabelung notwendig (obwohl dies bis jetzt klaglos funktioniert) und bessere WLAN-Verbindung über die Stick-Logger als über die ESP's!
Zum Thema 'Visualisierung' gibt es unzählige github-Lösungen.
Ich habe ganz am Anfang auch mit einer Grafana-Lösung gespielt, da ich im Home-Assistant noch nicht so fit war.
Mittlerweile habe ich mehrer Dashboards im Einsatz unter anderem jenes von slipx06. Aber wie gesagt, da gibt es viele und das ist eindeutig Geschmacksache!
Sollte David die 'Schreib-Funktion' demnächst umgesetzt haben und die wesentlichsten Parameter vorhanden sein, werde ich definitiv auf dies Lösung umsteigen.
Ich habe auch die Lösung von David ausprobiert, die anderen Parameter (andere Register) lassen sich problemlos per yaml-Datei einfügen. Man könnte eine eigene yaml-Datei erstellen und verwenden. Ich bin auch gespannt auf die Schreibfunktion. Ich benutze immer noch Solarman App, mit der Integration von David ist SolarmanApp nicht immer online. Ich denke, wenn man die Aktualisierungszeiten in der yaml-Datei optimiert (man muss nicht alle Parameter alle 5 Sekunden auslesen), wird es auch mit der Solarman-Kommunikation besser.
Ich fange gerade mit dem Home Assistant an und habe noch kein Dashbord implementiert. Kannst du ein paar Dashbords zusätzlich zum Dashbord von slipx06 empfehlen?
Ich hab mir für meinen Deye-10K eine eigene YAML auf Basis der 'deye_sg04lp3.yaml' erstellt und diese weggesichert.
Mit SolarmanApp meinst Du die Standard-China-Lösung oder? Die hat mit der Lösung von David primär nichts zu tun und Du könntest diese auch deaktivieren in dem Du den Stick-Logger resetest und nur in Dein lokales WLAN integrierst. Das habe ich übrigens noch vor bevor och dann tatsächlich nur mehr die Lösung von David verwende.
Das Dashboard bzw. die zugehörigen 'Cards' - es ist ja im Prinzip nichts anderes als mehrere Cards die mittels einer zentralen YAML-Datei zu einem Dashboard zusammengefasst werden.
Ich verwende zB noch diese hier:
Ich versuche modbus in den Home assystant zu integrieren um die Daten aus der Wallbox auszulesen.
In die configuration.ayml habe ich modbus eintrag eingefügt
von HA Seite den Inhalt für ayml reinkopiert. Obwohl es keine Rolle spielt, ob die ayml-Datei einen Inhalt hat oder leer ist, erscheint die Fehlermeldung.
Was passt nicht? Was habe ich falsch gemacht?
modbus:
- name: modbus_hub
type: serial
port: /dev/ttyUSB0
baudrate: 9600
bytesize: 8
method: rtu
parity: E
stopbits: 1@amiko das ist doch besser raus zu lösen in eine neuen Beitrag, kommt alles durcheinander...
@summer-of-69 was David da angeht schaut echt gut aus schon mal. mal testen, dachte eigentlich das die WLAN Abfrage in der Abfrage nicht so schnell Daten liefern kann, scheint aber nicht so zu sein... die ESP32 sind zwar nett, aber haben auch ab und an ihre Zicken...
Hoffentlich bekommt er die Steuerung darüber auch bald hin, das wäre super.
- platform: modbus_controller use_write_multiple: true modbus_controller_id: ${modbus_controller_id} name: "${device_type} Control Mode" id: ${device_type}_control_mode address: 98 value_type: U_WORD optionsmap: "Lead Battery": 0 "Lithium Battery": 1
Hab da was vertauscht 🙁
Lead und Lithium ist genau anders rum...
@tsg,
ich hab mich durch etliche Forumsseiten durchgearbeitet und so langsam beginnt es im Kopf zu schmoren.
Auf Github hab ich deinen Beitrag gefunden, aber du schreibst, dass es noch nicht getestet wurde:
select:
#######################################
## Under developmnet - still testing ##
#######################################
# 98 - 1 / 111 - 0 -> Lithium (BMS)
# 98 - 0 / 111 - 0 -> Use V
# 98 - 0 / 111 - 1 -> Use %
# 98 - 0 / 111 - 2 -> No Bat- platform: modbus_controller
use_write_multiple: true
modbus_controller_id: ${modbus_controller_id}
name: "${device_type} Control Mode"
id: ${device_type}_control_mode
address: 98
value_type: U_WORD
optionsmap:
"Lead Battery": 0
"Lithium Battery": 1
Hast du mittlerweile neue Erkenntnisse? Du hast es unter "select" definiert.
Von @linuxdep hab ich diesen Code, der unter "switch" steht, aber anstelle einer erwarteten 0 oder 1 ein "ON" oder "OFF" ausliest:
switch:
- platform: modbus_controller
use_write_multiple: true
modbus_controller_id: ${modbus_controller_id}
name: ${device_type}_Battery_Typ
register_type: holding
address: 98
bitmask: 1
entity_category: config
icon: "mdi:toggle-switch"
Letzteren Code von @linuxdep hab ich im Einsatz, ohne dass ich etwas negatives sehe, außer halt dem Eintrag "OFF" für dieses Register.
@linuxdep, ich hatte auch hier noch gefragt: https://www.akkudoktor.net/forum/deye-wechselrichter/deye-hybrid-wr-standby-wirkungsgrad-womit-muss-man-rechnen-was-kan-ich-erwarten/paged/9/#post-222796
Ich bitte auch um Entschuldigung für den Doppelpost, aber die Info bzgl. des Registers 98 ist auf soviele Seiten in diesem Forum und auch bei Github verteilt, dass es schwer ist dem richtigen Faden zu folgen.
Viele Grüße
Gisbert
na ja on entspricht 1 und off 0, ein Schalter in HA hat nun mal ON/OFF als Angaben...
schaut halt so bei mir aus
ja, in der tat habe das nicht weiter verfolgt... Ist bei mir aktuell nicht in Verwendung. Bezieht sich eigentlich nur auf die Logiktabelle. Der Code ist in Ordnung. Und als Option Map oder Schalter. Ja gut bei 2 Zuständen, such es dir aus 😉
Es gibt halt die 2 Register die passen müssen.
und Register 111:
So lange du aber nur über ModBus / Homeassistent die Batterie verwendung ein/aus schalten möchtest, reicht das 111 Register. Wenn du aber mal am HMI am WR die Umschaltung vornimmst, kann sein die Register passen nicht mehr.
Um wirklich sicher zu sein könntest du auch noch abfangen, dass https://github.com/klatremis/esphome-for-deye/issues/31
Hast du vor nach SOC zu gehen oder nach Spannung? Wenn du nur zwischen "Use V" und "No Bat" schalten möchtest reicht dir die 111. Wenn du aber mit BMS und SOC arbeiten möchtest, dann musst du dich auch noch um 98 kümmern.
Klar soweit? Sonst nochmals fragen...
Hast du vor nach SOC zu gehen oder nach Spannung? Wenn du nur zwischen "Use V" und "No Bat" schalten möchtest reicht dir die 111. Wenn du aber mit BMS und SOC arbeiten möchtest, dann musst du dich auch noch um 98 kümmern.
Nicht wirklich, wenn du nur per Modbus umschaltes, dann reicht Register 111, wenn du aber mal um WR, warum auch immer, die umstellung vor nimmst, dann stellet der WR bei No battery auch von LFP auf Blei zurück (Register 98). Also ist bei mir nur zur Sicherheit um ggf. umstellen zu können wenn durch was auch immer (FW update, Handeingriff, Sonnensturm...) das Register nicht auf LFP steht.