Replies: 10 comments 42 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.
-
|
der dutycycle bezieht sich auf die funkstrecke openDTU <-> Wechselrichter. |
Beta Was this translation helpful? Give feedback.
-
|
Gibt es eigentlich etwas Neues in Bezug auf MQTT kleiner als 5 Sekunden? |
Beta Was this translation helpful? Give feedback.
-
|
Ich frage mich selber auch, wieso ich die dtu abfrage sekündlich machen kann, per mqtt aber nur 5 sekündlich den ist wert senden darf? |
Beta Was this translation helpful? Give feedback.
-
|
Auf der WEB Oberfläche unter Info/Console sieht man "Fetch inverter: 123412341234" Messages. Bei mir kommen sie alle 8 Sekunden. Das heißt, dass die Aktualisierung der Daten vom Wechselrichter nur alle 8 Sekunden erfolgt. Somit bringt MQTT Interval von 1 Sekunde nichts. Irgendwie muss man das Abfrageintervall des Wechselrichters kleiner machen |
Beta Was this translation helpful? Give feedback.
-
|
@maroviher & @mattberlinHA wie bereits weiter oben beschrieben dauert ein einfaches Paket ~ 300ms. Für einen durchschnittlichen Wechselrichter benötigt die OpenDTU alleine meist drei Pakete um die aktuellen Daten per Ihr könnt also gerne an den Einstellung rumspielen und versuchen das für Euren persönlichen Fall zu optimieren. Die Entwickler haben sich aber bei den aktuellen Defaults und min/max Werten etwas gedacht und das nicht als Schikane eingebaut, sondern um Fehlfunktionen bzw. Wechselrichter die sich bei Unterschreiten dieser Limits einfach gar nicht mehr melden zu vermeiden. Das gab nämlich in der Vergangenheit verstärkt Support-Anfragen. Der o.a. duty-cycle von @kecksk0enig beträgt in der Tat 36s pro Stunde, das sind also ca. 120 Pakete à 300ms pro Gerät und Stunde und dazu zählt m.E. die OpenDTU selber auch. Es macht bei diesen Grundvoraussetzungen auf der DTU->WR Seite also auch absolut keinen Sinn die Daten per MQTT öfter an Home Assistant oder andere Systeme zu melden, wenn gar keine neuen Daten vorliegen können. Auch ein häufigeres Steuern macht keinen Sinn, da ansonsten der WR evtl. gar nicht mehr antwortet und dann ist erstmal ganz lange nichts mit Steuern & Regeln. Wer mißt, mißt Mist. Wer viel mißt, mißt viel Mist! |
Beta Was this translation helpful? Give feedback.
-
Kann ich nicht bestätigen. |
Beta Was this translation helpful? Give feedback.
-
Dem kann ich nur zustimmen, nach dem setzen des neuen Limits vergehen 1-2 Sekunden, bis ich die Änderung am Stromzähler sehe. Getestet mit HM-1500 und HMS-800 |
Beta Was this translation helpful? Give feedback.
-
|
Das ist die Ansteuerung des neuen ActivePowerLimits durch den WR. Aber bevor der WR richtig auf ein SystemConfigPara Command antwortet müssen m.W. eine Grace Period von mindestens 15 Sekunden vergehen, sonst antwortet er nicht mehr. Das ist bereits so im OpenDTU Source Code berücksichtigt, daher meldet die OpenDTU auch schon den Wert den man gesetzt hat per MQTT. Bis er sich dann aber den gesetzten Wert vom WR per SystemConfigPara bestätigen lassen kann, vergehen mindestens 15 Sekunden. Ihr könnt Euch den Code von tbnobody gerne ansehen und die Stelle raussuchen 😉 |
Beta Was this translation helpful? Give feedback.
-
|
@stefan123t , also wie es aussieht ist der Bottleneck nicht die Performance des ESP32 sondern der Wechselrichter, der nicht schneller als ein paar Sekunden angesprochen werden kann. Dann wäre sinnvoll den Versand der MQTT Pakete nicht auf ein festes Interval zu setzen (>5s) sondern, wenn die neuen (aktualisierten) Daten von einem der Wechselrichters vorliegen. |
Beta Was this translation helpful? Give feedback.
-
|
@maroviher ja das ist in der Tat eine Überlegung, man könnte evtl. sogar das MQTT Intervall komplett weglassen, da es m.E. nur dann Sinn macht neue Daten an die Heim Automation (Home Assistant, etc.) zu senden, wenn wirklich neue Daten vorliegen. Ich nehme auch an daß es eher ein mindestens n Sekunden Intervall ist. Also außer dem z in Analyse ist daran überhaupt nichts verkehrt 😜 Ich glaube die Ahoy Entwickler haben auch schon versucht die RF-Kommunikation mit dem WR zu optimieren, und evtl. wäre es sinnvoll auf der anderen Seite die MQTT-Kommunikation wirklich rein Event Driven umzusetzen. Letztendlich ist es viel Augenwischerei hier 3-5 Sekunden Intervalle zu definieren, wenn man 10 WR abfragt und die reinen Nutzdaten |
Beta Was this translation helpful? Give feedback.
-
|
Hi, ich bin auch heute über dieses Problem gestoßen. Weiter oben im Thread wird argumentiert, man könne die Daten nicht schneller als alle 5 Sekunden von den DTUs holen, daher müsste man die MQTT Kommunikationsfrequenz auf minestens 5 Sekunden begrenzen. Gleichzeitig gibt es in den "DTU-Einstellungen" den Punkt "Abfrageintervall", welcher sich auf 1 Sekunde setzen lässt. OpenDTU erhält also in Szenarien mit wenigen oder passenden Wechselrichtern sekündlich Daten und kann diese scheinbar bereits jetzt verarbeiten und über die API zur Ansicht bereitstellen. Eventuelle Bottlenecks durch 5+ Wechselrichter wären hier für kleinere Setups oder bei Setups mit leistungsstärkeren ESP32-Variationen also bis zu einem gewissen Punkt irellevant. Entsprechende Poweruser können hier dann je nach Bedarf vertikal und horizontal Skalieren. Die bestehende Einschränkung auf MQTT Updates von je mindestens 5 Sekunden löst also keine Probleme die für die meisten Nutzer relevant wären und die Nutzer für die die begrenzte Rechenleistung der eingesetzten ESP32 relevant wäre, können die niedrigere Reporting Rate nicht in Anspruch nehmen oder über entsprechende Einblendungen und gute Dokumentation aufklären. Wenn also keine gewichtigen Gründe für das Entfernen oder Verstümmeln von vorhandener Funktionalität sprechen, handelt es sich hier wahrscheinlich eher um einen frustrierenden Bug der die Nutzererfahrung und Funktionalität des Projekts beeinträchtigt, als um etwas über dessen Sinnhaftigkeit man sich streiten muss. Leider gibt es noch kein Issue zu dem Thema, ich schaue ob ich später eins in etwas gebündelter und sachlicher erstellen kann. Zum Beheben des Issues: |
Beta Was this translation helpful? Give feedback.
-
|
Bei mir ist kein MQTT aktiv und es aktualisiert alle 3-5 Sekunden in der Live Ansicht. Ich schau mir das aber nochmal mit einer aktuellen Version an... Das 5 Sekunden Limit hat der Entwickler so eingebaut und dafür seine Gründe angegeben. Es kam bei niedrigeren Limits zu viele Support Anfragen, darum hat er es so eingebaut. M.W. wird auch nur einmal - nachdem alle WR einmal abgefragt wurden - alle Daten gemeinsam per MQTT übermittelt, nicht nach jedem WR nur ein Teil der Daten für diesen WR. Evtl müsste man dann auch die MQTT Senderoutine anpassen, dass diese auch Teildaten senden kann. Du kannst gerne einen Vorschlag machen wie das event-driven sinnvoll möglich ist. Aber bitte die anderen WR in einer DTU mit mehreren und Downstream Projekte wie OpenDTU-OnBattery berücksichtigen die evtl. noch andere Daten zum Beispiel von Batterien BMS oder Ladereglern zB Victron und Smart Metern SML/Shelly abfragen und ebenfalls per MQTT übermitteln. |
Beta Was this translation helpful? Give feedback.
-
|
Lad dir die config.json runter und änder es mit einem Texteditor dort händisch auf 1 und lad die config.json wieder hoch. Fertig. |
Beta Was this translation helpful? Give feedback.
-
|
Ist aber kontraproduktiv. Es kommt dann jede Sekunde zwar ein Wert, aber es ist ein alter Wert. |
Beta Was this translation helpful? Give feedback.
-
|
Wieso alter Wert? |
Beta Was this translation helpful? Give feedback.
-
|
Kleines Update meinerseits, da ich den MQTT Push mit der Methode des modifizierten Backup Restores mindestens seit Mai auf eine Sekunde reduziert habe: Ja, teilweise werden alte Daten erneut übermittelt. OpenDTU erhält in meiner Umgebung schätzungsweise alle 1,15 Sekunden einen vollständigen Datensatz vom Wechselrichter. Das bedeutet, dass die MQTT Meldung alle 7-8 Sekunden einen "alten" Wert erneut sendet und im Anschluss wieder sekündliche Werte übermittelt. Da die Diskussion "das wäre nicht möglich" öfter in diesem Post kam: So verhält es sich in meiner Umgebung mit einem einzigen Wechselrichter in direkter Nähe zum OpenDTU. Ich habe sogar mit einer Sekundenanzeige neben dem OpenDTU Dashboard überprüft, ob sich tatsächlich die Werte (nicht nur die "Letzte Aktualisierung" Anzeige) sekündlich ändern. Ja tun sie. Da auch das Argument verwendet wurde, die letzte Aktualisierung Anzeige im OpenDTU Dashboard wäre nicht relevant: Und der MQTT Wert? Im tatsächlichen Einsatz hat man also einen sekündlich aktuellen und reellen Wert, mit ca. einem kurzen einsekündigen Aussetzer alle 10 Sekunden. Diese Einschränkung ist in den vielen Fällen also wahrscheinlich zu vernachlässigen und damit ein deutlicher Gewinn zu dem vorherigen 5 Sekunden Limit. Aber Event Driven! Den Mindestwert auf 1 Sekunde zu setzen, um Nutzern, deren Umgebungen diese Geschwindigkeit hergeben, den Mehrwert (siehe z.B. Nulleinspeisung) zu ermöglichen, ist ein Quick Win welcher nicht das Umstrukturieren der ganzen Codebase erfordert. |
Beta Was this translation helpful? Give feedback.
-
|
@z-master42 |
Beta Was this translation helpful? Give feedback.
-
|
Schon klar. Die Intervalle sollten schon korrespondieren, sonst ist das witzlos. |
Beta Was this translation helpful? Give feedback.
-
Das ist nämlich das Problem, dass die aktuelle MQTT-Implementierung in OpenDTU nicht Event driven umgesetzt ist. An der einen Seite pollt DTU die Werte vom WR, auf der anderen Seite schickt OpenDTU zu dem festen Zeitintervall eine MQTT Nachricht und die beiden wissen voneinander nichts. |
Beta Was this translation helpful? Give feedback.
-
|
Das wäre super cool, wenn Werte lesen und via MQTT versenden aufeinander abgestimmt wäre. |
Beta Was this translation helpful? Give feedback.
-
|
Hier ist eine Antwort von der Bundesnetzagentur BNA auf Reddit zu einer Hoymiles DTU W Lite S die "dauerhaft" den Duty Cycle von <1% auf dem 868 MHz Band nicht einhält. https://www.reddit.com/r/Balkonkraftwerk/s/In6gMrFy6o Der Betrieb eines "Störsenders" kann mit bis zu 500.000€ geahndet werden. Nutzer ArugulaDull1461 bestätigt den fehlenden Duty Cycle mit einem Video:
Interessant sind in dieser Diskussion und in diesem Zusammenhang vor allem die Betrachtungen von Nutzer RacoonStealthMode: https://www.reddit.com/r/Balkonkraftwerk/comments/1mc4kmc/comment/n5rnkvs/
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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