Wir wechseln das Forum am 14.11.24 auf die Forensoftware Discourse. Zwischen Montag Abend und Dienstag Nachmittag wird das Forum deaktiviert. Danach sind wir hoffentlich mit neuem Forum inkl. der vorhandenen Beiträge wieder am Start! Hier zum Forenbeitrag!
Hallo Leute,
ich will mir ein ESS mit einem Multiplus2 bauen. meine PV ist eine 10kWp mit Sunny Tripower, SMA-EM10 und HM1. Der Multiplus soll in einen anderen Gebäudeteil kommen. Somit fällt eine CAN Verbindung zu einem zusätzlichen Meter in der Verteilung aus. Es bleibt LAN und Wifi. Der Tripower bekommt die Daten vom SMA-EM über das proparitäre SMA Protokoll. Über ModBus Register 30865 und 30867 stellt der Tripower den saldierten Bezug und die Einspeisung als positive Werte im Sekundentakt zur Verfügung.
Gibt es eine Möglichkeit, dass der Multiplus diese Werte zur Steuerung verwendet?
der Multiplus ist bestellt, aber noch nicht geliefert. Bin recht unwissend in der ganzen Multiplus Sache.
Was soll der Multiplus den mit den Werten aus dem Wechselrichter steuern?
Der Multiplus braucht die Netzeinspeisung um die Ladeleistung des Akkus zu steuern als in Summe PV Einspeisung - Eigenverbrauch = Überschuss
Wird ein Überschuss erzeugt speichert der MP den Strom in den Akku, wir mehr gebrauch holt der MP den Strom aus dem Akku.
Es gibt auf Github einen Integration für den SMA HM für Venus OS.
Die Integration ist leider für den HM2, ich habe noch den HM1 und ein SMA-EM10 (Anlage ist von 2014). Wie ich schrieb, liegen die Werte aus dem Energymeter im Tripower vor und können über Modbus abgefragt werden. Die Werte sind der aktuelle Bezug und die aktuelle Einspeisung saldiert am Übergabepunkt. Also prinzipiell genau das, was der Multiplus braucht
Wenn du die per Modbus auslesen kannst bekommst du die auch ins Venus OS rein. Gibt einige Projekte auf Github die ein Grid-Meter für Venus OS via Modbus oder MQTT anbinden. Der EM24 liest allerdings auch Spannung/Strom pro Phase. Ich denke aber das Venus das nicht unbedingt braucht. Hier gibt es auch ein Projekt zu Nulleinspeisung über den Stromzähler damit ging das natürlich auch wenn du den auslesen kannst, die Werte kommen da nur nicht so schnell.
Schau dir das hier: https://www.akkudoktor.net/forum/postid/114204/ mal an
EM24 ist leider keine Option, da 1. kein Platz mehr in der Verteilung (Das SMA EM muss bleiben, wegen der SunnyPortal Langzeit Statistik seit 2014) und 2. über 30m CAN Bus Kabel nötig wären. Der Multiplus samt Speicher kommt physisch weit entfernt von der Hauptverteilung in einen frostsicheren Raum.
Das SMA-EM bietet eine ganze Latte Werte an, nur leider im proparitären SMA Speedwire Format. Der Tripower redet darüber mit dem EM. Vermutlich bekommt er auch die Spannungslage der Außenleiter. Bin jetzt aber nicht in die Tiefen der Modbus Register des Tripower herabgestiegen, aber vielleicht bietet der die auch an. Soweit ich gesehen habe, kann man im Multiplus irgendwo einen Wechselrichter einstellen. Ich hatte die Hoffnung, dass, wenn man einen Tripower auswählt und die Register aktiv sind, diese eventuell automatisch gelesen werden.
Ich habe mal meine eingerosteten Python Skills aufpoliert und einen Treiber für SMA-EM10, SMA-EM20 und SHM2.0 geschrieben. Angelehnt habe ich mich an den Fronius Treiber. Allerdings wird hier der Speedwire Broadcast und das proparitäre SMA Protokoll genutzt. Abgeschaut habe ich mir das (OBIS codes) beim entsprechenden ioBroker Adapter für SMA-EM. Der Treiber ansich ist ungetestet, da ich noch keine Venus Installation habe. Das im Repo enthaltene speedwire_test.py läuft und gibt die Werte auf der Console aus. Der dbus Teil ist da nicht drin, daher läuft es auf jedem Linux.
Link entfernt
Edit: keine Ahnung warum Github links entfernt werden. Das Projekt findet Ihr auf Github unter venus.dbus-sma-smartmeter
@profantus vielleicht kannst Du mir nochmal helfen. Ich habe mir Venus mal auf einem alten Raspi installiert. Meinen SMAEM Dienst ebenfalls. Der läuft prima und dbus-spy zeigt mir fröhlich Werte an. Nur wie/wo kann ich das jetzt ins UI einbinden. Das Einzige was gefunden wurde ist mein Sunny Tripower Wechselrichter. Im Grunde Ist mein Dienst ähnlich dem Fronius Smartmeter Dienst, nur das ich die Daten halt anders beschaffe
@waldmaus Wenn du den Dienst korrekt im D-Bus registriert hast taucht der automatisch im UI auf.
Analog zum Multiplus II oder SUN2000-3.68KTL-L1.
Der SUN2000 ist auch ein Gerät das Venus von sich aus nicht unterstützt. Den hab ich über einen MQTT Treiber und ESPHome angebunden. Artikel dazu hab ich oben schon verlinkt.
@profantus Kann es sein, dass mein "Trockentest" nicht funktioniert, weil kein Multiplus dranhängt und entsprechend kein ESS Assistent geladen ist? Grid taucht ja im UI gar nicht auf. Ich weiß auch nicht, wie ich den ESS simulieren soll. Vermutlich muss ich die Lieferung meines Multiplus abwarten
Nee, die Geräte tauchen schon im Venus auf auch wenn kein MP II dran hängt. Hast du die korrekt am DBus angemeldet?
Schau mal hier: https://github.com/victronenergy/venus/wiki/howto-add-a-driver-to-Venus
und hier: https://github.com/victronenergy/velib_python/blob/master/dbusdummyservice.py
@profantus Habs hinbekommen! Es war prinzipiell alles richtig, nur der blockende Socket hat den Dienst abstürzen lassen. Den habe ich jetzt in einen eigenen Thread gepackt und schon läuft es 🤩
Keine Ahnung ob der Github Link wieder entfernt wird:
Victron hat dazu ja ein Beispiel wie du das machen sollst und auch wie du mit Fehlern umgehen sollst. Ist in den Links oben erklärt.
@profantus Ich habe mir einen Wolf gesucht, nach einem Beispiel, was TCP sockets nutzt. Habe nichts derartiges gefunden. Alles andere, z.B. diverse MQTT Dienste arbeiten eventbasiert oder per eigenem Intervall (Fronius REST call). Bin auch nicht so der Python Crack und mit UDP sockets habe ich erst recht nix am Hut. Man bindet halt den Socket und loopt endlos in einer while Schleife, bis ein Datenpaket kommt. Scheinbar kollidiert das mit der mainloop, die denkt, das die Applikation komplett hängt. Aber wie gesagt, wenn man den Socket in einen separaten Thread packt rennt es. Wenn da jetzt keine Daten- oder Berechnungsfehler im Code sind, würde ich das soweit als fertig betrachten.
Ja, der bleibt wohl beim receive auf dem Socket stehen und dann läuft die main-loop vom service nicht mehr sauber.