Ich habe eine Solaredge PV, die ihre Erträge über Modbus/TCP an den GX meldet. Das funktioniert. Nun ist aber noch eine separate Balkonsolaranlage dazugekommen (Hoymiles WR). Wie kann ich deren Erträge der Venus GX bekanntmachen? Gibt es da ein API? Müsste ich den Weg über MQTT gehen? Wenn ja, wo würde dann der MQTT Server laufen?
Du musst Dir eine OpenDTU besorgen und die kann man im Venus OS visualisieren.
Google mal nach OpenDTU.
Würde die Visualisierung der openDTU über MQTT gehen? Woher weiß die GX denn dabei, welche Topics sie angucken muss?
Wenn ich mir das hier ansehe:
dann wirkt das so, als ob ich auf Betriebssystemebene bei der Venus GX etwas installieren muss. Ich hab jedoch die originale blaue box von Victron - komme ich da überhaupt an das OS heran?
Würde es damit gehen:
Du könntest auch ein Shelly 1pm in die Leitung installieren.
Und dann einen Treiber installieren.
1 Like
Für mich sieht “dbus-opendtu” so aus, als ob man damit einen Prozess installiert, der irgendeinen REST-Service abfragt und dann (per Konfiguration einstellbar) irgendwelche Attribute aus der JSON Antwort selektiert.
Das würde bedeuten, dass ich es auch ohne DTU hinbekommen würde, denn es sitzt sowieso schon ein Shelly Plug an der Balkonsolaranlage dran. Der hat auch ein REST API und dort könnte ich den aktuellen Ertrag ja abgreifen.
Ja genau. Ich hab zwar einen Shelly PLus PLUG S, aber das macht aus Sicht des JSON API sicher keinen Unterschied.
Hat jemand diese “Halmand”-Lösung im Einsatz?
Oder ein offiziell unterstützten ET112 ohne viel gebastelt.
Kommt aber natürlich darauf an, wo/wie das Balkonkraftwerk in deine Verbraucheranlage eingebunden ist.
Ja, in meinem Fall hängt das BKW im OG an der Giebelwand und das ESS System steht im Keller. Also binde ich wohl besser den Shelly ein. Der wird dann ja wohl auch als Energiezähler auf dem dbus auftauchen.
ich bin der Meinung, der Shelly PLus PLUG S kann keine negativen Werte anzeigen, somit funktioniert der nicht im Zusammenhang mit der PV
https://support.shelly.cloud/de/support/solutions/articles/103000316350-welche-shelly-ger%C3%A4te-k%C3%B6nnen-negative-leistung-f%C3%BCr-zur%C3%BCckgespeiste-energie-messen-
hallo,
das ist zwar richtig, da aber keine pv keinen strom verbraucht, kann man problemlos davon ausgehen, dass die gemessene leistung in etwa der pv-leistung entspricht, allerdings ist das ganze natuerlich auch mit verlusten behaftet und auch der shelly misst nicht so genau, ausser man nimmt einen shelly-em.
tschuess
Im Portal wird es dann falsch angezeigt und PVs verbrauchen Strom im Standby (wenn auch nicht viel)
also, das funktioniert mit allem möglichen Zeug. Wenn man so ein bastelgeraffel einsetzen will, sollte man allerdings python und linux fest sein.
bei mir laufen 4 x HM1500 über ET340 was das einzige ist, was sauber funktioniert.
OpenDTU Code ist frei verfügbar und läuft über ESP und hat aber keinen stabilen Empfang. Die richtige DTU Pro kann man via ModBus TCP auslesen, zerschiest sich dann aber u.U. die DTUPro (ist bei mir bei 2 Geräten passiert → Garantietausch, soll angeblich in der FW gefixt sein).
Shelly ist so ein Thema, habe ich aber auch am Laufen und in Victron eingebunden, restarte das Teil aber per cron stündlich, weil die sich einmal pro Woche aufhängen.
Bei den ganze 3th party python skripten aufpassen, dass man sich das Filesystem mit den Logfiles nicht zukippt, dann geht nichts mehr
hallo,
das trifft aber nur nachts zu und das ist im vergleich zur einspeisung so minimal, dass du den fehler dann ignorieren kannst.
da du den shelly nur per script einbinden kannst, muss das auch richtig konfiguriert sein, da kannst du dann auch bestimmt das vorzeichen und die phase aendern.
tschuess
Also ich habe sehr viele Shellies im Einsatz und bei mir hängt sich maximal einer im Jahr auf
Ich habe drei Shellies seit bis zu anderthalb Jahren, und hatte noch nie einen Aufhänger. Keinen einzigen.
2 Likes
hallo,
ich habe auch jede menge shellys in betrieb und bei einem bekannten einen shelly em pro und einen shelly 3em pro installiert.
der 3em pro hat laengere zeit aerger gemacht, weil er keine messwerte mehr geliefert hat, aber seit dem letzten firmware-update gab es keine probleme mehr.
einige meiner shelly starten des oefteren automatisch neu. das ist mir aber erst aufgefallen, als ich festgestellt habe, dass sie sich selbst eingeschaltet haben, was die voreinstellung nach einem neustart war. ich habe dann eine auswertung der datenbank gemacht und festgestellt, dass dabei shelly-1, 1pm und der plug s gleichermassen betroffen waren. aber bis auf die neustarts funktionieren sie noch.
ich habe ein ticket geoeffnet und ein paar shellys als ersatz bekommen.
tschuess
Normal Hoymiles kann man per OpenDTU oder AhoiDTU einbinden. Beide können per Debus-OpenDTU oder direkt MQTT eingebunden werden.
War vor den virtuellen Komponenten.
HM-Serie über Nordic-Funk NRF24, die HMS auf 900 MHz mit Cm2000 oder so.
Ich habe insgesamt 4 HMS-2000-4t , ein HMS-1000-2t und einen HM-600 per OpenDTU/dbus-dtu eingebunden. Per MQQT gehen noch Details in Home Assistant, sodass ich Daten zu jedem einzelnen Panel habe.
Es gibt seit ca einem Jahr aber auch welche mit WLAN. Die können evtl. über SolarMan eingebunden werden.
Also bitte erst prüfen, was Du hast.
Ich kann opendtu mit henne49/dbus-opendtu nur wärmstens empfehlen.
Mit opendtu (Hardware) kann man einen oder mehrere Hoymiles bis in’s Detail auslesen => das nutze ich seit 2 Jahren bei 3 Installationen. Teilweise mit 5 HMS pro opendtu. Damit kann man Auffälligkeiten an einzelnen Solarmodulen erkennen und auch die Hoymiles-Logeinsicht gibt mitunter Aufschluss über Störungsursachen.
Und diese Daten werden mit besagten henne49/dbus-opendtu perfekt dem Venus-OS bereitgestellt, indem Venus regelmäßig (z.B. minütlich) http-Anfragen an opendtu stellt.
(MQTT kommt hierbei nicht zum Einsatz.)
Für mich die viel bessere Wahl, als einen Strommesser physikalisch zu installieren, der dann in Venus-OS integriert werden würde.