Hi dein Post ist schon ne ganze Weile her. Hab ähnlich Probleme wie du, den Deye aber auch die ABL eMh1 via Modbus mit evcc aber auch ha verbunden zu bekommen. Bist du denn mittlerweile zu einer Lösung gekommen?
Ich habe jemanden, der mir das ganze macht aber auch da gibt es noch Probleme, scheint nicht so einfach zu sein.
Viele Grüße
André
@martinhn Leider nein. Momentan ist mein Workaround mit einem Tibber Pulse. Damit habe ich zumindest am Zähler dann eine Möglichkeit abzugreifen, ob und wieviel eingespeist bzw. entnommen wird. Damit funktioniert zumindest mal evcc rudimentär. Es funktioniert damit „Aus“, „Min+PV“ und „Schnell“. Die Einstellung „PV“ funzt nicht, weil er ja nicht weiß, was vom Dach kommt.
In einer der nächsten Woche kommt ein Bekannter vorbei und wir schauen uns nochmals an, wie wir die Daten aus dem Deye herausbekommen. Es muss ja irgendwie gehen. Wenn ich eine Lösung habe, poste ich sie hier.
So, nun habe ich es doch geschafft, zumindest zu mehr als 90 Prozent. Für mich gestaltete sich das Problem wie folgt: Wenn ich evcc konfigurierte (evcc configure in der Konsole), dann testete evcc immer die Verbindung und der Test war immer (bestimmt weitaus mehr als 10 Versuche) gescheitert. Später kam dann der Workaround mit dem Tibber Pulse und die neuer Software von evcc bietet die Möglichkeit, sich "Experimentelle UI-Funktionen" anzeigen zu lassen. Mit diesen kommt dann der zusätzliche Menue-Punkt "Device Configuration". Dort kann man dann z.B. ein weiteres Auto konfigurieren, aber auch WR und Batteriespeicher. Die Konfiguration dort ist super simpel. Und über diesen Weg hat es dann funktioniert. Es war wohl reiner Zufall, dass es bei der Abfrage ging, aber über das GUI ist es einfach leichter und auch besser ausprobierbar (verschiedene Parameter), weil man nicht alles immer wieder eingeben muss. Also war klar, dass es doch geht. Mittlerweile habe ich den Tibber Pulse eliminiert und Grid, Solar und Battery einfach direkt in die YAML-Datei aufgenommen, auch wenn dort dann wieder kam, dass der Test scheiterte. Egal, einfach alles rein und später evcc starten. Und siehe da, es geht und die Daten kommen aus dem WR raus und alles ist, wie ich es mir wünsche.
Also kurz gesagt, sich im Terminal bei der Konfiguration nicht ins Bockshorn jagen lassen, wenn evcc meckert, dass der Test des WR fehlgeschlagen ist. Einfach dennoch in die Confi aufnehmen und gut ist.
Jetzt habe ich allerdings noch die Baustelle, die auch der ursprüngliche Thread-Ersteller hat, dass es sehr häufige Fehlermeldungen gibt. Das liegt wohl daran, dass der WR nicht oft genug seine Daten herausrückt. Soweit ich es bis jetzt sehe, funktioniert PV-Überschussladen dennoch. Aber hier bleibe ich dran, ob ich hier noch eine Lösung finde. Falls jemand Rat weiß, dann nehme ich den gerne an. Danke vorab.
Mal eine allgemeine Frage. Ist es zwingend erforderlich für die Modbus Kommunikation über RS485 => USB Adapter ein Netzwerkkabel zu verlegen. Habe von der PV Anlage zur Wallbox ein 5+2 adriges Kabel liegen und habe gehofft, dass man die 2 freien bzw. für die Ansteuerung vorgesehenen Adern hierfür nutzen zu können. Vorher habe ich diese 2 Adern zum Freigeben des Schlüsselschalterkontakts meiner Heidelberg Home Eco Wallbox genutzt. Will jetzt allerdings auf eine Smart Lösung umsteigen.
Nein braucht kein Netzwerkkabel, jeder Klingeldraht tut es auch.
Also ich habe jetzt einen Raspberry Pi 5, den Waveshare Industrial USB to RS485 Converter und eine Heidelberg Energy Control Wallbox.
Leider haut es mit der Verbindung nicht hin. Kann mich da eventuell jemand unterstützen?
Wenn ich ls /dev/tty* eingebe ist der Adapter bei mir als /dev/ttyACM0 gelistet.
Nach Eingabe von lsusb, steht dort das:
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 1a86:55d3 QinHeng Electronics USB Single Serial
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Im minicom sieht die Konfiguration wie folgt aus:
Hoffe es sprengt hier jetzt nicht den Rahmen.
Im iOBroker bekomme ich den Modbusadapter hierfür nicht zum laufen.
Das Problem mit den häufigen Fehlermeldungen in evcc konnte ich jetzt lösen. Nach einem Update des Deye, welches die Modbus-Schnittstelle nutzbar machen sollte, habe ich dann probiert, das RJ45 Kabel, das zum Raspi (evcc) geht in die Modbus-Buchse zu stecken. Na ja, die gleichen Fehlermeldungen, eher sogar noch mehr als vorher.
Zweiter Versuch mit dem Meter-485 Anschluss. M.E. Weniger Fehler als beim Modbus-Anschluss, aber genau so viel wie am Dreierverteiler am BMS-Anschluss. Also wieder alles zurück auf BMS.
Dann hatte ich eine Eingebung. Womöglich stören sich die Signale vom vorhandenen EMS und evcc. Also einfach mal dem EMS den Saft abgedreht (Netzstecker gezogen). Und siehe da: ab sofort keine einzige Fehlermeldung in evcc und alle Daten korrekt wie auf dem WR.
Später dann Eingebung Nr. 2: Wieder den WR aufgeschraubt und das Kabel zum EMS in den Meter-485 Port gesteckt und den Strom zum EMS wieder eingeschaltet. Nun sind mit dem Splitter am BMS-Port der Batteriespeicher und evcc. Am Meter-485 Port hängt nun das EMS. Jetzt kann ich beides nutzen und beide arbeiten fehlerfrei.
Hurra 🎉
Vielen Dank für deinen Post. Hatte am Deye ein Problem mit dem RJ45 Anschluss. Jetzt mit der neuen Platine werde ich es erneut probieren. Deswegen war so lange Pause.
VG,
Martin
Wie sieht es mit dem Thema Timeouts aus?
Ich habe unterschiedliche Installationen mit evcc betreut.
Bei allen treten sporadisch Timeouts auf.
Das einzige was ein wenig was gebracht hat, ist die Baudrate hoch zu setzen.
Timeouts hatte ich schon lange nicht mehr. Die Baudrate habe ich auf dem Standardwert von evcc stehen.
Hallo Zusammen,
Ich bin noch neu hier, aber schon einmal vielen Dank für die vielen tollen Tipps in diesem Forum.
Hat einer von Euch schon mal das Problem gehabt, dass das Cache des RS485/USB Converters für die Übertragungsrate aus dem Wechselrichter nicht ausgereicht hat und es deswegen zu Verbindungsabbrüche kommt?
viele Grüße, Alex
Ich denke nicht dass hier ein Zusammenhang besteht.
Ich habe die Probleme bei USB Adaptern, RTU über TCPIP und bei Modbus TCP.
Jedes Mal andere technische Geräte (Waveshare, ESP32 mit Tasmota, ...).
Bei allen sporadisch Timeouts.
Timeouts hatte ich schon lange nicht mehr.
Ich bin jetzt auf etwas anderes gestoßen: Wenn man den originalen Wifi Stick abzieht, dann hat er auch keine Timeouts über Modbus mehr.
Hast du den dran?
Falls nein, dann ist wohl das der Grund für die Timeouts. Der WR ist wohl einfach zu langsam um beides zu bedienen.
Hi, kann jemand von euch das entladen der Batterie am Deye im Schnell Lade Modus unterbinden?