Hallo zusammen,
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.
Nachteile von Solaranzeige.de:
- 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:
1. 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...
2. 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.
Beste Grüße aus Rauenberg.
Ich bin hier einen Schritt weitergekommen.
Dazu habe ich den RS485/IP Konverter, welcher am SDM630 hängt von UDP Client auf UDP Server konfiguriert.
Nun lässt er zusätzliche Abfragen von anderen Systemen zu. Somit kann ich nun ebenfalls beliebige Register des Smartmeters über NodeRed abfragen.
Die Kommunikation zwischen WR und SDM630 wird dadurch nicht beeinträchtig.
Nun bleibt noch die serielle Schnittstelle bzw. der USB-Anschluss über einen ESP8266 zu realisieren.
Hat dies schon jemand umgesetzt?
Die Kommunikation zwischen WR und SDM630 wird dadurch nicht beeinträchtig.
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.
24kWP an 2x FSP 10kW und AxpertMAXII 8000 mit 70kWh LiFePo4
123solar, meterN und EVSE-WiFi
Kein Support per PN
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.
Szenario: 3x einphasige Wechselrichter bedienen jeweils eine Phase. Alle 3 WEs benötigen entsprechende Infos vom SmartMeter. Jeder WR stellt seine Anfrage.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).
Weiter Frage ich die aktuellen Leistungsdaten nur minütlich ab.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.
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.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.
Der Unterschied ist, dass diese Lösung nur 3€ kostet.Wie gesagt, die 20€ Lösung mit einem echten RS232/TCP Konverter ist sicher bezahlbar und m.M.n. deutlich flexibler und stabiler.
Ich hatte es auch bereits mit einem RS232/TCP Konverter getestet. Nur leider hatte ich damit keinen Erfolg.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?
24kWP an 2x FSP 10kW und AxpertMAXII 8000 mit 70kWh LiFePo4
123solar, meterN und EVSE-WiFi
Kein Support per PN
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.
Bzgl. der Steuerung des WRs über Modbus habe ich nun doch eine Dokumentation zum Protokoll gefunden ( https://www.photovoltaikforum.com/core/attachment/10695-modbus-protocol-for-p17-for-mpi-hybrid-10k-pdf/). Vielleicht mache ich mich mal daran, sobald ich mal keine anderen Projekte am Start habe 😉
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?
24kWP an 2x FSP 10kW und AxpertMAXII 8000 mit 70kWh LiFePo4
123solar, meterN und EVSE-WiFi
Kein Support per PN
Moin,
welchen TCP/RS232 Adapter hast du bestellt?
Magst du deinen Flow aus Node-Red mit mir teilen? 🙂
Viele Grüße
Stefano