Replies: 4 comments 19 replies
-
|
Hallo Dekalus, |
Beta Was this translation helpful? Give feedback.
-
|
Bezüglich Deiner Annahmen im Vergleich der RestAPI und dem MQTT Client, solltest Du Dir den Code mal ansehen. Bei OpenDTU werden die Sekunden im UI hochgezählt und bei Vorliegen neuer Daten ca. alle 5 Sekunden holt / pusht er die aktuellen Daten zum Browser. Ich weiß nicht ob das jetzt über WebSocket geht oder ob das Events in Vue sind. Die Daten kommen praktisch immer wenn sie vom Wechselrichter an die DTU in einem vollständigen Frame (mehrere Pakete) geschickt wurden und die CRC8 und CRC16 Checksummen auch passen. Dann werden Sie mit dem nächsten Event ins UI bzw. an den MQTT Server geschickt. Wenn Du wissen willst wie lange das dauert, dann schau doch mal unter Info > Console ein bißchen zu. Da werden bestimmt auch ein paar Fälle mit Retransmits dabei sein. So und jetzt steuerst Du noch aus Deinem Smart Home System den Wechselrichter auf ein béstimmtes Leistungslimit, dann kann die DTU nicht normal mit dem / den WR plaudern, sondern muß ihm auch noch PowerLimit Befehle erteilen. Und zwischenrein klickt der Anwender in der GUI bzw. schaut sich die AlarmEvents an und triggered gleich mal ~20 Pakete und mehr vom WR. Da hat noch keiner ein GridProfile aktualisiert oder mit einem zweiten bis X-ten Wechselrichter gesprochen. |
Beta Was this translation helpful? Give feedback.
-
Das ist aber sowas von be.... Bei allem was über 1 Sekunde braucht um bearbeitet zu werden, kann doch nicht mehr von einer Nulleinspeisung die Rede sein! Gibt es denn keine Möglichkeit, den Datentransfer im Zeitabschnitt von 1 Sekunde oder schneller zu gewährleisten? Weshalb mir das so wichtig ist, habe ich unten detailliert beschrieben.
Das wird nicht der Fall sein, da ich in der Materie (Programmieren) nicht bewandert bin und auch nicht vor habe, mich da rein zu arbeiten...
Danke für die Info.
Hier muss ich mich halbwegs korrigieren. Die Daten von der RestAPI des ShellyEM3 werden beim aktualisieren über den Browser mit F5 sekündlich erneuert. Wie das mit der OpenDTU ist weiß ich nicht. Allerdings werden auch hier die Daten sekündlich in der Live-Daten-Übersicht aktualisiert. Edit: Die Daten per "/api/livedata/status" werden in einem Intervall von mindestens einer Sekunde wenn nicht gar noch schneller aktualisiert.
Wie erwähnt, ich möchte nur einen Wechselrichter mit guter Netzwerkanbindung benutzen. Falls da auch nur ein Quäntchen mehr Leistung rausspringt, indem ein kleineres Aktualisierungsintervall ausgewählt werden kann, ist es das meiner Ansicht nach schon Wert. |
Beta Was this translation helpful? Give feedback.
-
|
Die Daten per "/api/livedata/status" sind die Daten die die openDTU per NRF oder CMT vom Wechselrichter abfragen muß. Wenn Du mit F5 / Reload oder einem Script die Daten häufiger von der DTU abfragst, werden die Informationen aber auch nicht schneller vom WR zur DTU übertragen. Du erzeugst einfach mehr Last auf dem kleinen ESP32 Mikrocontroller, weil der die HTTP Response (hier JSON oder eben die MQTT Message) zusammenstellen und ausliefern muß. Das stösst einfach an die System-Grenzen und es ist schön wenn Dein ESP32 einen solchen "Lasttest" aushält, ein anderer mit mehr als einem Inverter beschäftigter ESP32 kommt da einfach nicht hinterher und die REST API ist daher auch nicht dafür gedacht mit Abfragen (F5 / Reload) zu geballert zu werden. So viel zu den von Dir selbst beschriebenen Fakten. Das Selbe gilt für die MQTT Schnittstelle, hier entscheidet die openDTU selbst, wie oft sie den MQTT Server kontaktiert und das wurde von den Entwicklern auf ein sinnvolles Maß (min. alle 5 Sekunden, wenn neue Daten vorliegen) nach unten beschränkt, um die anderen Funktionen der DTU sicher zu stellen. Bei diesem Projekt / Programm dreht sich halt nicht alles nur um einen Wechselrichter sondern einige Nutzer haben davon auch 10-20 auf dem Dach / als Latten am Solarzaun. Den effektiven Nutzen dieser "Quäntchen"-Physik für einen einzelnen Inverter haben wir ja weiter unten ausführlich diskutiert 🤷 |
Beta Was this translation helpful? Give feedback.
-
|
Ich sehe schon, wir funken auf verschiedenen Wellenlängen. Aber zunächst einmal Danke für die Ausführungen. Es liegt mir fern, mit Dir einen Streit vom Zaun zu brechen. Ich möchte aber auch nicht auf herablassende Art und Weise behandelt werden. Vielleicht fällt Dir dieses Verhalten nicht auf. Mir schon.
Einen gediegeneren Umgang miteinander würde ich mir wünschen. Nur weil ich nicht so viel Ahnung von der Materie habe, heißt das nicht, dass man mit mir ungeduldig werden muss. Auch nicht, wenn ich in etwas herausfordernderer Weise Fragen in den Raum werfe. Für mich ist ein Gerät wie der ESP32 dazu gedacht, so benutzt zu werden, wie benötigt. Es spielt für mich keine Rolle, ob dieser noch viel Luft nach oben hat, oder an seine Belastungsgrenze kommt. Auch spielt es für mich keine Rolle, ob vielleicht jemand anderes 10-20 Wechselrichter im Einsatz hat. Das sollen diese Benutzer machen wie sie es wollen... Für mich spielt einzig und alleine eine Rolle, dass in meinem Falle ein Wechselrichter maximal performant funktioniert. Anhand der obigen Erklärungen ist es mir als Laien einfach nicht möglich ein Resümee zu ziehen. Deshalb nochmals die Frage. Gibt es eine Möglichkeit mit welcher Technik auch immer (ob über MQTT, RestAPI oder...), den Wechselrichter + Messeinheit (ShellyEM3) schneller anzusprechen, oder nicht? Oder ist es aus welchen Gründen auch immer nicht gewünscht? Vielleicht weil zu kompliziert zu programmieren? Jedenfalls kein Grund kann es sein, für jedes Verwendungsszenario so viel Sicherheitsspielraum zu ermöglichen, dass es nicht zu einer Überlastung der OpenDTU kommt. Dafür gibt es dann die Möglichkeit Warnhinweise gut sichtbar einzubauen. Es sollte in der Hand des Benutzers liegen, wie weit er beim Einstellen der Werte geht. Das ist meine Meinung zum Thema. Sicherlich hat da jeder eine andere Meinung.
Moment mal... Wir sind hier noch nicht fertig. Siehe unten... |
Beta Was this translation helpful? Give feedback.
-
|
Ja den effektive Wert für einen 500 Watt Verbraucher den Du zehn Mal am Tag einschaltest (oder zehn Verbraucher die Du je einmal am Tag einschaltest) beläuft sich auf 1,36€ im Jahr. Sollte das für Dich relevant sein, würde ich Dir empfehlen den Code selbst umzuprogrammieren oder jemanden zu bezahlen der es für Dich macht. Das ist eine Software für alle und fünf Sekunden sind hinreichend für einen Wechselrichter, bei mehreren dauert es entsprechend N mal 5 Sekunden. Schönen Abend noch. |
Beta Was this translation helpful? Give feedback.
-
Rein interessehalber: Wofür wäre ein Intervall von 1 Sekunde nützlich? (Ich selbst habe 10 Sekunden eingestellt.) |
Beta Was this translation helpful? Give feedback.
-
|
Auf alle Fälle ist mein HM-800 sehr schnell ansprechbar. Ich frage mich allen Ernstes, weshalb die Bauteile so gebaut worden sein sollen, dass sie mindestens ganze 5 Sekunden brauchen, um zu reagieren. 5 Sekunden sind eine halbe Ewigkeit! Unzumutbar lange... |
Beta Was this translation helpful? Give feedback.
-
Beispiel: "Es würden also 500 Watt mal 9 Sekunden (4500 Watt) optimal vom Sonnenstrom genutzt werden." 500 W mal 9 Sekunden = 4500 Ws = 1,25 Wh (Faktor 3600!) Dieser Fehler zieht sich durch die gesamte Rechnung oben...
|
Beta Was this translation helpful? Give feedback.
-
|
@Dekalus bitte bedenke doch die Einheiten in Deinen Rechenbeispielen: Es würden 500 Watt mal 9 Sekunden (4500 WattSekunden = 1,25Wh; 0,00125kWh * 0,30€ = 0,000375 €) pro Hände waschen verbraucht. Dir entgehen also sage und schreibe 10 * 0,0375 €Cent also 0,375€Cent pro Tag mal 365 Tage im Jahr = 1,36€ pro Jahr. Deine Solaranlage wird sich damit nicht wirklich schneller amortisieren. Leider werden wir damit also nicht das Weltklima retten, während andere für ihr Trinkwasser Stunden zu Fuß gehen müssen. Die Original Hoymiles DTU macht das m.W. übrigens nur alle 5 Minuten und in 30 Watt Intervallen, da würden Dir noch mehr Watt Sekunden entgehen 🤒 |
Beta Was this translation helpful? Give feedback.
-
Gut. Dankeschön für die Korrektur und die Umrechnung. Sonst stimmt alles? Also habe ich nur die Einheit falsch gewählt (anstatt Watt hätte ich Wattsekunden schreiben müssen). Sonst scheint meine Berechnung ja aufzugehen. |
Beta Was this translation helpful? Give feedback.
-
Hier wurde nur eines von vielen möglichen Szenarien, die in einem Haushalt vorkommen können aufgezählt. Wenn wir noch weitere Haushaltsgeräte wie Kühlschränke, Gefrierfächer, Haarföhn, E-Herd, Backofen, Mikrowelle, Kafeemaschiene, Wasserkocher uvm. in die jährliche Berechnung mit einbeziehen, dann summiert sich hier ganz schnell mal ein großer Batzen an zusätzlichem Einsparungspotential. Wenn dann müssen wir doch etwas realistischer an dieses Szenario herangehen. 🤒 Edit: Auf einen Punkt wurde ich noch hingewiesen. Während der Zeit, in der das Balkonkraftwerk mit Speicher nicht auf Stromverläufe reagieren kann, da das Zeitintervall so groß ist, dass es das nicht mitbekommt, wird der Akku dennoch weiter geladen, wenn dieser nicht schon voll ist und die Sonne gerade scheint. Je nachdem ob dann diese Energie später für andere Zwecke aufgebracht wird und der Akku nicht vorher voll geladen wurde, geht sie also nicht verloren. |
Beta Was this translation helpful? Give feedback.
-
|
Hallo zusammen, ich bin nun auch schon eine Weile am Feintunung der Nulleinspeisung. Fakt ist ja, dass die openDTU (vielleicht ist es auch der WR, jedenfalls bekomme ich keine Werte mehr via MQTT) sich aufhängt, wenn man alle 3 Sekunden versucht, die Leistungsbegrenzung des WRs zu verändern. Fakt ist aber definitiv, dass es hierfür mehr als sinnvoll ist, mit einem kleineren Intervall als 5 s via MQTT zu versenden. Mag sein, dass es bei mehrere WRs keinen Sinn macht. Aber es gibt nun einmal viele Anwender mit einem WR und denen würde man helfen, wenn man das MQTT-Intervall auf 1 s reduzieren kann. Daher die Frage: Besteht Aussicht darauf, dass openDTU entsprechend ertüchtigt wird? |
Beta Was this translation helpful? Give feedback.
-
|
Jetzt muss ich das Thema noch einmal aufgreifen. Was ist denn eigentlich der Grund, dass als Untergrenze 5 s implementiert sind? |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Danke für die Rückmeldung. Zu 1) Aktuell wird auf der Funkstrecke zwischen WR und OpenDTU sekündlich aktualisiert, so dass man auf dem Web-Interface entsprechend häufig Änderungen sieht. Auf welcher Grundlage dürfte man auf der WLAN-Strecke nicht schneller als fünfsekündlich Daten senden? Der springende Punkt ist, dass 5 Sekunden einfach zu lang sind für eine bestmögliche WR-Leistungsregelung. |
Beta Was this translation helpful? Give feedback.
-
Hallo.
Eigentlich habe ich nur eine ganz einfache Bitte, die (so denke ich zumindest) ganz schnell und unkompliziert umgesetzt werden kann.
Es per Menü Einstellungen-->MQTT-Einstellungen-->MQTT-Broker-Parameter-->Veröffentlichungsintervall zu ermöglichen, kleinere Werte als 5 Sekunden einzustellen. Es sollte die Möglichkeit geben mindestens zwischen 1, 2, 3, 4 und höheren Veröffentlichungsintervallen wählen zu können. Bestenfalls sogar bei jeder Änderung.
Die folgende Seite gibt Aufschluss darüber, was die OpenDTU und die AhoyDTU können:
https://blog.helmutkarger.de/balkonkraftwerk-teil-8-opendtu-und-ahoydtu-fuer-hoymiles-wechselrichter/
Zitat: "Kleinstes MQTT Veröffentlichungsintervall" bei der AhoyDTU: 1 Sekunde oder bei jeder Änderung
Bei der OpenDTU sind es hier nur 5 Sekunden. Dieser Nachteil sollte dringend beseitigt werden.
Vielen Dank.
Hello.
Actually, I only have a very simple request that (or so I think) can be implemented very quickly and easily.
Allow setting smaller values than 5 seconds via menu Settings-->MQTT Settings-->MQTT Broker Parameter-->Publish Interval. There should be the possibility to choose at least between 1, 2, 3, 4 and higher publication intervals. At best even with every change.
The following page provides information about what the OpenDTU and the AhoyDTU can do:
https://blog.helmutkarger.de/balkonkraftwerk-teil-8-opendtu-und-ahoydtu-fuer-hoymiles-wechselrichter/
Quote: "Smallest MQTT publication interval" at AhoyDTU: 1 second or with each change
With the OpenDTU it is only 5 seconds. This disadvantage should be eliminated urgently.
Thank you.
Beta Was this translation helpful? Give feedback.
All reactions