schon seit einer Weile bin ich auf der Suche nach der passenden Kommunikation bzw. Methode zur Steuerung meines WR.
Aktuell habe ich dies mit der Solaranzeige(.de) realisiert. Darüber erhalte ich einige Informationen (per MQTT) und kann auch die Ladefunktion für den Akku beeinflussen.
(Die Steuerung des JKBMS mache ich über einen ESP32. Voller Funktionsumfang. Protokoll ebenfalls MQTT. Node-Red übernimmt die Logik.)
Allerdings finde ich diese Lösung nicht optimal für mich.
Befehlssätze sind vorgegeben. Eine Erweiterung ist aus meiner Sicht aufwändig und erfordert gute Programmierkenntnisse. Nach einem Update ist die Erweiterung weg.
Basis bildet ein Raspi. In der aktuellen Zeit werden Raspi´s in Gold aufgewertet. Ausserdem nutze ich die Software ausschliesslich als Interface. Influx/Grafana wird bereits von meiner zentralen Haussteuerung übernommen. Daher ist der Raspi hier absolut überdimensioniert.
Das Absetzen der Befehle ist asynchron. Bestimmte Intervalle müssen abgewartet werden. Eine Steuerung in Echtzeit ist somit nicht möglich.
Weitere Nachteile meiner Lösung:
Für das Auslesen des SDM630 benötige ich zusätzliche Hardware. Bei mir ein ESP8266 mit Tasmota in Verbindung mit einer RS485 Schnittstelle
Die Verbindung zwischen der WR-Modbus-Karte und dem SDM630 erfolgt über 2x USR-TCP232-304
Für mich werden hier zu viele Komponenten um die eigentliche Funktion herum benötigt.
Aus meiner Sicht die Ideale Lösung:
die Komplette Kommunikation erfolgt über die Modbus Schnittstelle.
Also Kommunikation zwischen SDM630 und WR + Abfrage SDM630 (per Node-Red) + Steuerung WR (per Node-Red).
Hier wurde mir allerdings mitgeteilt, dass dies nicht möglich ist. Daher...
Ersetzen der Solaranzeige@Raspi durch einen ESP8266. Ich stelle mir hier ein USB-WIFI Gateway vor, welches unter Node-Red mit seriellen Befehlen gefüttert wird.
Dies, als auch die Steuerung des WR über einen RS232/TCP Gateway, habe ich bereits "erfolglos" versucht und habe es daher frustriert aufgegeben.
Ich würde mich freuen, wenn wir hier eine Sammlung an verschiedenen Lösungen starten.
Dies spart die mühselige Recherche in diversen 139 seitigen Topics in unterschiedlichen Foren in unzähligen Sprachen.
Also zeigt mal bitte eure Lösungen her
Über eine direkte Unterstützung der Umsetzung meiner Lösung bin ich natürlich auch sehr dankbar.
Das glaube ich ehrlich gesagt nicht. Wenn du die Modbus-Karte parallel zum RS485-TCP Converter betreibst, hast du zwei Master am Bus.
Da diese nichts von einander wissen, kommt es zu vielen Kollisionen am Bus.
Das mag auf den ersten Blick zwar funktionieren, verzögert die ohnehin sehr zeitkritische Smartmeter-Abfrage des WR weiter.
Prinzipiell würde das schon funktionieren, aber du müsstest die Modbus-Karte im WR auf den Server-Betrieb umstellen und die Abfrage/Steuer-Kommandos an den WR im (Modbus-)Protokoll entsprechend anpassen.
Ich arbeite gerade an einer Software-Lösung als Ersatz für den Modbus-Server - das würde bei dir wohl auch relativ gut reinpassen ?
Bzgl. ESP: Mag sein, dass die Lösung "billiger" als ein weiterer RS232-TCP Umsetzer wäre. Ich rate dir dennoch dazu, die Steuer-Programme,etc. auf deiner Linux Maschine (xPi,altes Notebook,...) zu entwickeln/laufen zu lassen. Da reicht ein billiger Orange- oder Banana-Pi älterer Generation.
Ich mach das schon x-Jahre so, kann laufend etwas Neues austesten und Programme gemütlich von irgendwo anpassen, ohne den ESP gleich neu flashen zu müssen. Und man kann sogar mal remote mit SolarPower "vorbeischaun", ohne irgend ein Kabel umstecken zu müssen ?
Einiges dazu habe ich auch auf Github veröffentlicht.
Ich habe mir dazu auch vorher Gedanken gemacht und bin zu der Überzeugung gekommen, dass dies gehen muss.
Szenario: 3x einphasige Wechselrichter bedienen jeweils eine Phase. Alle 3 WEs benötigen entsprechende Infos vom SmartMeter. Jeder WR stellt seine Anfrage.
Mein Node-Red ist in dem Fall nichts anderes als eine Art weiterer WR.
Im Falle von UDP handelt der RS485/TCP Konverter es so ab, dass er die Antworten vom SDM630 immer an die letzte IP sendet, die eine Anfrage gestellt hat.
Da die Konverter auch cachen/buffern, sollte es hier zu keinen bis wenigen zusätzlichen Kollisionen auf dem Bus selbst kommen.
Weiter Frage ich die aktuellen Leistungsdaten nur minütlich ab. Diese sind für mich nur zur Protokollierung. Ich regle damit nichts zusätzlich.
Auch wenn der WR und der SM den Bus exklusiv für sich haben, kann es zu Kollisionen kommen, da der WR jede Sekunde eine Anfrage stellt und nicht vorher abwartet, ob er überhaupt eine Antwort erhält. Dies lässt sich natürlich nicht vermeiden.
Den Konverter auf der WR Seite musste ich nicht anpassen und bleibt auf UDP-Client. Dieser initiiert die Verbindung und verbindet sich mit dem UDP-Server.
Dies sollte nach Dokumentation sogar der Standard sein.
Im Grunde soll der ESP8266 nur ein transparentes Gateway zwischen meiner NodeRed Instanz und dem WR darstellen. Also das Gleiche, was ein RS232/TCP Konverter macht. Der Unterschied ist, dass diese Lösung nur 3€ kostet.
Dahinter ist ein Raspi. Auf diesem könnte ich auch deine Skripte verarbeiten.
Ich hatte es auch bereits mit einem RS232/TCP Konverter getestet. Nur leider hatte ich damit keinen Erfolg.
[quote data-userid="1929" data-postid="91894"]Szenario: 3x einphasige Wechselrichter bedienen jeweils eine Phase. Alle 3 WEs benötigen entsprechende Infos vom SmartMeter. Jeder WR stellt seine Anfrage.[/quote] Nein, in diesem Fall muss ein Modbus-Server den Verkehr regeln. Das ist bei allen mir bekannten Wechselrichtern so, weil es auch nur so spezifizierten ist. Dieser fungiert als Master, fragt den Smartmeter ab und schickt Kommandos und Abfragen an die div. WR am Bus, welche auch als Slave's eingestellt sind (Server-Mode auf der Voltronic Karte).
[quote data-userid="1929" data-postid="91894"]Weiter Frage ich die aktuellen Leistungsdaten nur minütlich ab.[/quote]S.o., meiner Meinung nach definitiv außerhalb der Spezifikation vom RS485-Bus (Es kann nur einen geben... ? ). Aber klar, wenn du die WR<->Smartmeter Kommunikation nur 1x pro Minute störst, wird das nicht so massiv ins Gewicht fallen, wie wenn du das sekündlich machst.
[quote data-userid="1929" data-postid="91894"]Auch wenn der WR und der SM den Bus exklusiv für sich haben, kann es zu Kollisionen kommen, da der WR jede Sekunde eine Anfrage stellt und nicht vorher abwartet, ob er überhaupt eine Antwort erhält. Dies lässt sich natürlich nicht vermeiden.[/quote]Bin ich auch anderer Meinung, weil der Bus genau so funktioniert: Ein Master (keine ID am Bus) frägt 1-127 Slaves ab. Diese Antworten in einem genau spezifizierten Zeitraum. Erst nach Ablauf dieses Timers darf der Master wieder etwas fragen. Wenn's "verspätet" kommt, ist der Slave kaputt und gehört getauscht.
Hab nach Analyse von gefühlt 1000 Modus-Traces noch nie etwas anderes gesehen.
[quote data-userid="1929" data-postid="91894"]Der Unterschied ist, dass diese Lösung nur 3€ kostet.[/quote]Wie gesagt, die 20€ Lösung mit einem echten RS232/TCP Konverter ist sicher bezahlbar und m.M.n. deutlich flexibler und stabiler.
[quote data-userid="1929" data-postid="91894"]Ich hatte es auch bereits mit einem RS232/TCP Konverter getestet. Nur leider hatte ich damit keinen Erfolg.[/quote]Hab das bei mir schon seit 2015 so in Betrieb, mit den billigstern USR-TCP-401 um 10$ das Stück. Funktioniert noch immer tadellos.
Wobei hakelte es denn mit dem Converter?
Das Thema hat mir jetzt keine Ruhe gelassen und ich habe gestern noch einen RS232/TCP Konverter bestellt.
Kurz vor Mittagspause geliefert und direkt umgesetzt. Hatte die ganze Zeit nicht bemerkt, dass ich bei der Erstellung des Buffers kein <CR> hinzugefügt habe. Jetzt kommen die Antworten vom WR. Dh. die Abfrage/Steuerung des WR geht nun auch über NodeRed.
Als letzen Schritt schaue ich jetzt noch, dass ich die ^D054BMS Kommandos implementiert bekomme.
Meines Wissens nach gibt es mehrere Modbus-Karten für diese Wechselrichter. Die HW ist immer gleich, nur die Firmware auf den Karten ist unterschiedlich.
Die s.g. ModbusII-Karte ist für den Nullausgleich - haben wohl die meisten User drinnen stecken und ist auch schon 1000x Diskutiert worden.
Damit die Abfragen/Kommandos der von dir verlinkten Anleitung funktionieren, brauchst du die klassische Modbus-Karte. Kenne eig. niemanden, der sowas hat.
Wenn du ohnehin über die RS232 Schnittstelle kommunizierst, warum schickst du nicht alle Abfrage-/Steuer-Kommandos darüber, so wie alle anderen auch?
