Gibt's eigentlich noch eine Möglichkeit an eine deiner Platinen zu kommen?
Habe nun die Lösung dafür, für alle die das gleiche Problem haben :
@bagges Moin Bagges,
wo hast du die Platinen herstellen lassen?
@mr-tom25 jlcpcb
Hallo erstmal. Bin neu im Forum. Mich würde deine Platine auch interessieren. Konnte dir leider nur keine PN schicken, da ich ja neu bin.
Lg Henning
Hallo, können Sie mir helfen, die Solarassistant-MQTT-Entität mit Homeassistant zu teilen? Ich habe es mit der Sunsynk-Power-Flow-Card versucht, aber es funktioniert nicht
Hallo,
ich habe im SA den MQTT aktiviert und User mit PW definiert.
Das habe ich im HA angelegt. Ich habe das auch nur per YT gelernt / abgeschaut, bin ja auch noch absoluter newbee .
Am besten dort mal suchen, das wird da rel gut erklärt.
Bei Fragen einfach hier nochmal fragen was genau nicht geht.
@linuxdev Ist es möglich, die Zusammenfassung im ersten Beitrag zu aktualisieren? Dann muss man sich nicht durch die 21 Seiten kämpfen 
Wenn ich das richtig sehe gibt es folgende Optionen:
-
Joubert Solarman Integration (langsam, readonly, funktioniert aber ohne Zusatzhardware)
-
ESPHome (mit RS485 Adapter und ESP)
-
KellerZA Sunsynk/Deye Addon (funktioniert mit Solarman oder RS485 Adapter)
-
HA Modbus Integration (mit RS485 Adapter, erfordert manuelles Editieren der HA-Config, keine fertige Config verfügbar)
-
SolarAssistant über MQTT (mit RS485 oder RS232 Adapter, Raspberry PI, kostenpflichtige Software)
Auch wenn es in diesem Thread hauptsächlich um ESPHome geht, scheint mir das KellerZA Addon derzeit die beste Lösung zu sein. Angeblich kann das Addon über den Solarman-WIFI-Dongle auch schreiben (hab's nicht ausprobiert). Ich benutze das Addon mit RS485-Ethernet Adapter und kriege die wichtigen Werte im Sekundentakt (lässt sich einstellen).
2 „Gefällt mir“
Hallo!
Ich habe seit mittlerweile fast 2 Jahren die HA-Lösung von Klatremis im Einsatz und es läuft alles so wie ich es mir vorstelle.
Allerdings ist für mich ein Punkt immer unklar geblieben und vielleicht könnt ihr mir da weiterhelfen:
Ich habe die Lösung bei 2 baugleichen DEYE SUN10KSG04-LP3 im Einsatz (gleiche Firmware).
1x am Modebus-Port und 1x am BMS-Port (Y-Kabel).
Gerne hätte ich beide am Modbus-Port, aber obwohl ich schon alle möglichen Varianten durchgespielt habe, funktioniert bei einem der Modebus Port eben nicht.
Egal! Meine Frage geht sowieso in eine andere Richtung.
Ich möchte die Daten nun nicht über die 'LAN-Ports' abgreifen, sondern über den RS232-Anschluß an dem der 'Solarman WLAN-Dongel' hängt.
An den PINs 2 & 3 sind die TX bzw RX Verbindungen vorhanden.
Nun meine Frage:
Kann ich diese 1 zu 1 / A+ B- übernehmen oder handelt es sich hier um ein gänzlich anderes Protokoll?
Oder anders gefragt:
Liefern die PINs 2 und 3 ebenfalls die gleichen Register wie die A+ B- bei den LAN-Ports (Modebus-Port/BMS-Port)?
Ich hab schon etliche Foren und das WEB abgegrast aber dazu noch keine konkrete Aussage gefunden.
Sage schon jetzt Danke für alle Rückmeldungen!
@summer-of-69 RS485 und RS232 sind elektrisch komplett unterschiedlich - u.A. gibt es bei RS232 getrennte Leitungen zum Senden und Empfangen, bei RS485 passiert das abwechselnd auf demselben Leitungspaar. Da Du ja schon die ESP Lösung hast könntest Du versuchen, den TTL-RS485 Konverter gegen einen TTL-RS232 Konverter zu tauschen. In einem anderen Forum habe ich mal gelesen dass das Protokoll auf der RS232 Schnittstelle auch Modbus sein soll (wobei ich nicht ganz verstehe wie dann das Firmware-Update über diese Schnittstelle laufen kann...egal).
Hoffe das hilft Dir weiter
Karsten
@Karsten24 - Danke für die Rückinfo. 
Ich habe mir ja schon so etwas gedacht nur hatte ich bis jetzt keine logische Erklärung.
Werde das mal mit einem RS232 to TTL versuchen und berichten.
@Karsten24 - Danke für die Rückinfo.
Ich habe mir ja schon so etwas gedacht nur hatte ich bis jetzt keine logische Erklärung.
Werde das mal mit einem RS232 to TTL versuchen und berichten.
@karsten24 habe ich mal eingefügt, die Lösung (von hier) meist du sicher? Scheint sich ja weiterentwickelt zu haben... mal noch mal genau anschauen, eine native HA Integration wäre schon toll.
Eigentlich wurde das mal durch eine FW umgestellt, bist sicher das die aufgespielte FW auch aktiv ist auf dem WR, also C037+11xx ? Ggf. würde ich mal Werksreset machen und neu parametrieren, nur nicht zu viel verstellen, gab hier schon seltsame Phänomene.
@linuxdep Ich hab auf beiden Deye's die Version "AT-C042-1150" - die offiziell für Österreich freigegebene Version.
Auch der Hardreset bewirkt manchmal Wunder. Ich kenn das von einer Batteriespeicher-Aufrüstung von 200 auf 300 Ah.
Ich konnte die Änderung über das Display durchführen und er zeigte es mir auch korrekt an, nur im Hintergrund wurde die tatsächliche Kapazität erst nach einem Hardreset angepasst. Zuvor wurde der Batteriespeicher nie auf 100% geladen sondern blieb in der Regel stets bei 99% 'hängen'.
Schade ist bei einem Hardreset nur, dass man alle historischen Daten verliert!
Sofern ich meine nun favorisierte Lösung: RS232 -> ESP32 -> Home Assistant nicht realisieren kann, werde ich den Hardreset nochmal probieren.
@pv-soko und @bagges Gibt es dazu nun einen LINK?
Mich würde das Thema ebenfalls brennend interessieren, habe aber bei meiner Suche im WEB noch nichts konkretes gefunden.
Genau, der Code dazu ist unter GitHub - kellerza/sunsynk: Deye/Sunsynk Inverter Python library and Home Assistant OS Addon. Ich kenne die ESP Lösung nicht, daher fehlt mir der Vergleich, aber das Sunsynk Addon lässt aus meiner Sicht kaum Wünsche offen. Auch die Doku finde ich hervorragend.
Lediglich die Konfiguration der benötigten Sensoren ist ziemlich fummelig. Man muss nämlich die Namen in eine Liste eintragen - hierzu muss man aber erst mal in den Sourcen nachschlagen, welche Sensoren es überhaupt gibt. Hier wäre AutoCompletion oder eine Liste zum Anhaken besser. Immerhin sind die betreffenden Quelldateien in der Doku direkt verlinkt.
Das Plugin hat Treiber für Solarman (hierzu müssen ggf. die Abfrageraten reduziert werden), Modbus RTU (z.B. mit RS485-USB Adapter) und Modbus TCP (z.B. mit RS485-Ethernet Adapter). Man kann also ganz ohne Zusatzhardware starten. Der Upgrade-Pfad zu einer schnelleren Lösung ist relativ einfach, günstig und bastelfrei (abgesehen von der Verkabelung).
Gut gelöst finde ich die Schedules, mit denen man die Abfrageraten für einzelne Sensoren oder gruppiert nach Einheit festlegen kann. Die Leistungssensoren ("W") kommen bei mir zuverlässig im Sekundentakt an (mit RS485-Ethernet Adapter).
Die Schnittstelle des Addons zu HA läuft über MQTT, einschließlich Meta-Daten für HA AutoDiscovery - man muss also keine MQTT-Sensoren in HA manuell anlegen. Wer die Daten sowieso in MQTT braucht (z.B. für evcc) hat sich also einen Schritt gespart.
Das Sahnehäubchen ist aus meiner Sicht, dass man in einer Python Datei eigene Sensoren definieren kann - hier kann man also auch komplexe Algorithmen auf Basis der Daten programmieren, bevor diese überhaupt in HA aufschlagen. Ein Beispiel dafür ist auch dabei.
@summer-of-69 ich kann da nicht viel beisteuern. Ich kenne die Dongle nicht und alles was ich mache geht über rs485 und separater Stromversorgung.
Trotzdem Danke für die Rückinfo @bagges
Ich habe inzwischen erste Versuche via RS232-Schnittstelle -> RS232 to TTL -> ESP32 unternommen, bekomme aber im LOG-File leider folgende Fehlermeldung:
Modbus CRC Check failed! 4040!=FFFF
Kann mir da wer einen Tipp gebe?
Hallo, ich bekomme immer um 0:05 Uhr komische / falsche Werte für "Deye Day Grid Export", "Deye Day Battery Charge" und "Verbrauchte Batterieenergie" die mir meine Anischt im Energy Dashborad unansehnlich machen. Hat einer eine Idee woher die kommen? Bisher habe ich die manuel gelöscht aber auf dauer ist das keine Löung.
Ich importiere die werte via Modbus: GitHub - zivillian/esp32-modbus-gateway: ESP32 Modbus RTU/TCP Gateway
