OpenDTU-onBattery Blockly DPL Ein/Aus
-
Nicht unbedingt einen Denkfehler, aber eine Fehler im "Ablauf".
Kochplatte an - DPL auf 100% - Kochplatte geht aus - volle 1400 Watt gehen in´s Netz - DPL merkt das - reglet runten - ist auf z.B. 5% - Kochplatte wieder an - Dpl merkt das - regelt wieder rauf - jetzt kommt Wolke - Solarpanel bringt nichts mehr - Dpl merkt das und regelt - Kochplatte wieder aus - usw. usw. usw.
Wenn sich Zustände in kurzer Zeit sehr oft verändern, ist DPL vollkommen überfordert.
Sammel mal Daten und schaue dir das mit Grafana an.
Das alles bezieht sich bei in aller Regel in der Mittagszeit. Immer dann wenn große Lasten geschaltet werden.
Es gibt auch Videos auf Youtube die sich mit der Regelung beschäftigen das gerade neue Kochfelder solche Sachen vollkommen durcheinander bringen. Speziell bei Kochfeldern die getacktet sind. So kann es passieren das immer gerade dann "geschaut" wird wenn die Platte aus ist, obwohl sie real aus 70 % Leistung fährt.Hab ich 2 Tage lang gemacht.
Bisher alles tutti.
Wie gesagt, der Intervall steht bei 3sek.
Ich kontrolliere am Zweirichtungszähler den Einspeisewert .
Der hat sich seit der Durchgabe an den Netzbetreiber von vor ein paar Tagen nicht geändert.
Kann nur mutmaßen.
Ich habe die neueste Firmwaren von openDTUonBattery und in den DPL Einstellungen für beide WR alles für mich perfekt eingestellt.Mit dem technischen Verständnis in der Hinsicht, liegst Du vermutlich weit vor mir.
Die neuste FW ist vom 11.10.25.
Ich hab, wie gesagt , lange zugesehen, wie sich die Werte ändern.
Und dieses schnelle hin und herregeln konnte ich nicht beobachten. Stattdessen aber, dass die Software den WR höher geregelt hat, obwohl nicht viel Strom über die Panels generiert wurde. Das ist in der Hinsicht gut, dass es einen Puffer gibt und er nicht im Sekundentakt die Regelung vornehmen muss.Wie gesagt, meine Einstellungen funktionieren (für mich) super.
Natürlich wird man nie bei permanent 0 landen, aber bei Sonnenschein gestern war ich bei +10 und -10 in der Range. Das passt für mich.Synology DS218+ & 2 x Fujitsu Esprimo (VM/Container) + FritzBox7590 + 2 AVM 3000 Repeater & Homematic & HUE & Osram & Xiaomi, NPM 10.9.4, Nodejs 22.21.0 ,JS Controller 7.0.7 ,Admin 7.7.19
-
Hab ich 2 Tage lang gemacht.
Bisher alles tutti.
Wie gesagt, der Intervall steht bei 3sek.
Ich kontrolliere am Zweirichtungszähler den Einspeisewert .
Der hat sich seit der Durchgabe an den Netzbetreiber von vor ein paar Tagen nicht geändert.
Kann nur mutmaßen.
Ich habe die neueste Firmwaren von openDTUonBattery und in den DPL Einstellungen für beide WR alles für mich perfekt eingestellt.Mit dem technischen Verständnis in der Hinsicht, liegst Du vermutlich weit vor mir.
Die neuste FW ist vom 11.10.25.
Ich hab, wie gesagt , lange zugesehen, wie sich die Werte ändern.
Und dieses schnelle hin und herregeln konnte ich nicht beobachten. Stattdessen aber, dass die Software den WR höher geregelt hat, obwohl nicht viel Strom über die Panels generiert wurde. Das ist in der Hinsicht gut, dass es einen Puffer gibt und er nicht im Sekundentakt die Regelung vornehmen muss.Wie gesagt, meine Einstellungen funktionieren (für mich) super.
Natürlich wird man nie bei permanent 0 landen, aber bei Sonnenschein gestern war ich bei +10 und -10 in der Range. Das passt für mich.Das ist auch vollkommen ok. Ich glaube nichts ist in diesem Bereich ist so individuell wie der Aufbau und Ausrichtung der Solarpanels, dem WR, dem täglicher Ablauf oder die Elektrogeräte im Haushalt.
Wenn das bei Dir alles so läuft - einfach freuen. :blush:Ich bin froh, das ich hier die Möglichkeit habe es einfach zu deaktivieren. Und ganz wichtig, das der WAF zu 100% efüllt ist.
Die Natur braucht nicht unseren Schutz, sie braucht unsere Abwesenheit.
-
Das ist auch vollkommen ok. Ich glaube nichts ist in diesem Bereich ist so individuell wie der Aufbau und Ausrichtung der Solarpanels, dem WR, dem täglicher Ablauf oder die Elektrogeräte im Haushalt.
Wenn das bei Dir alles so läuft - einfach freuen. :blush:Ich bin froh, das ich hier die Möglichkeit habe es einfach zu deaktivieren. Und ganz wichtig, das der WAF zu 100% efüllt ist.
-
Hab ich 2 Tage lang gemacht.
Bisher alles tutti.
Wie gesagt, der Intervall steht bei 3sek.
Ich kontrolliere am Zweirichtungszähler den Einspeisewert .
Der hat sich seit der Durchgabe an den Netzbetreiber von vor ein paar Tagen nicht geändert.
Kann nur mutmaßen.
Ich habe die neueste Firmwaren von openDTUonBattery und in den DPL Einstellungen für beide WR alles für mich perfekt eingestellt.Mit dem technischen Verständnis in der Hinsicht, liegst Du vermutlich weit vor mir.
Die neuste FW ist vom 11.10.25.
Ich hab, wie gesagt , lange zugesehen, wie sich die Werte ändern.
Und dieses schnelle hin und herregeln konnte ich nicht beobachten. Stattdessen aber, dass die Software den WR höher geregelt hat, obwohl nicht viel Strom über die Panels generiert wurde. Das ist in der Hinsicht gut, dass es einen Puffer gibt und er nicht im Sekundentakt die Regelung vornehmen muss.Wie gesagt, meine Einstellungen funktionieren (für mich) super.
Natürlich wird man nie bei permanent 0 landen, aber bei Sonnenschein gestern war ich bei +10 und -10 in der Range. Das passt für mich.@haselchen sagte in OpenDTU-onBattery Blockly DPL Ein/Aus:
Die neuste FW ist vom 11.10.25.
Alle Firmwareversionen sind nun auch auf dem aktuellen Stand 11.10.25
ab hier nachfolgend.Wie gesagt, meine Einstellungen funktionieren (für mich) super.
Natürlich wird man nie bei permanent 0 landen, aber bei Sonnenschein gestern war ich bei +10 und -10 in der Range. Das passt für mich.wenn du zufrieden bist, gibt es keinen Grund was zu ändern :-)
-
Ich musste bei Dir 2mal hingucken :)
Wir haben das gleiche Setup oder?
HM600 und HM800 und demnächs ne PV Anlage und solange 0 Einspeisung, bis die kommt?@haselchen
Ich habe sechs mal 430 Watt auf dem Gartenhaus. Macht 2580 Watt. Die hängen an zwei HM800 und einem HM600. Alle drei sind auf 1000Watt "aufgebohrt". :laughing:Die Natur braucht nicht unseren Schutz, sie braucht unsere Abwesenheit.
-
@haselchen
Ich habe sechs mal 430 Watt auf dem Gartenhaus. Macht 2580 Watt. Die hängen an zwei HM800 und einem HM600. Alle drei sind auf 1000Watt "aufgebohrt". :laughing: -
@haselchen
Ich habe auch immer ein schlechtes Gewissen wenn die Sonne es am blauen Himmel so richtig gehen läßt.edit:
update 06.03.2026 10:27h
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2
final version mit Bescheibung
für verschiedene Builds: HIERIch schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
-
edit:
update 06.03.2026 10:27h
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2
final version mit Bescheibung
für verschiedene Builds: HIERedit:
update 06.03.2026 10:27h
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2
final version mit Bescheibung
für verschiedene Builds: HIERIch schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
-
edit:
update 06.03.2026 10:27h
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2
final version mit Bescheibung
für verschiedene Builds: HIERedit:
update 06.03.2026 10:27h
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2
final version mit Bescheibung
für verschiedene Builds: HIERIch schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
-
edit:
update 06.03.2026 10:27h
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2
final version mit Bescheibung
für verschiedene Builds: HIERedit:
update 06.03.2026 10:27h
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2
final version mit Bescheibung
für verschiedene Builds: HIERIch schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
-
edit:
update 06.03.2026 10:27h
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2
final version mit Bescheibung
für verschiedene Builds: HIERedit:
update 06.03.2026 10:27h
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2
final version mit Bescheibung
für verschiedene Builds: HIERIch schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
-
edit:
update 06.03.2026 10:27h
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2
final version mit Bescheibung
für verschiedene Builds: HIER -
Funktioniert. Danke :+1: :+1: :+1: :+1:
Was hat sich geändert, oder habe ich was überlesen?@beowolf
Builds wurden nur auf den aktuellen Stand 2025.10.11 von oDTUoB gebracht.
Änderungen nachzulesen bei hoylabs/OpenDTU-OnBatteryAm Patch selbst hat sich nichts geändert.
-
wenn DPL ausgeschaltet wird: sofort maximale Leistung von solarbetriebenen Wechselrichter (statt minimal).
-
zusätzliche MQTT dp
dplState zur Kontrolle
dplCmd zum DPL ein- auschalten. -
-
Huhu,
bin zufällig hier auf das Thema gestossen.
Lustigerweise habe ich mich genau vor ein paar Tagen damit beschäftigt.
Neue grosse PV kommt demnächst und solange will ich mit dem BKW eine 0 Einspeisung machen, weil ich den aktuellen Einspeisewert schon an den Netzbetreiber durchgeben musste und der sich nicht erhöhen soll (kein Bock auf Diskussionen mit dem Netzbetreiber).
Nun sehe ich hier gepatchte Firmware und Blocklys....Ich hab die openDTUon Battery auf nen ESP32 S3 gespielt und dort alles eingestellt.
(HM600 und HM800)
Die Software regelt automatisch den Verbrauch auf 0. Setzt je nach Verbrauch die % der WR. Intervall ist bei 3sek.
Das Ganze bilde ich per Widget in der VIS ab.
Reine Neugier, warum modifizierte FW und Blockly?
DPL regelt alles automatisch, warum also eingreifen?@haselchen sagte in OpenDTU-onBattery Blockly DPL Ein/Aus:
Reine Neugier, warum modifizierte FW und Blockly?
DPL regelt alles automatisch, warum also eingreifen?möchte meine Antwort um (m)einen zusätzlichen Anwendungsfall ergänzen.
Zendure-Setup:
- Zendure HUB2000
- Ladegerät Zendure ACE1500
- mehrere Zendure-Batterien
- am HM1200-Wechselrichter
Die DPL-Steuerung dieses Zendure-Gesamtsystems mit dem HM1200 läuft bei mir komplett über ein JS-Script.
Das regelt zuverlässig und meiner Meinung nach besser als OpenDTU-onBattery.Grundprinzip:
- Das Zendure-System lässt sich per Script steuern, solange es nicht im Bypass ist.
- Bypass schaltet sich automatisch ein, wenn die Batterien voll sind. Dann wird die komplette PV-Leistung direkt an den HM1200 durchgereicht.
- Im Bypass kann das Script nicht mehr regeln.
- Erkennt mein Script per Datenpunkt, dass Bypass aktiv ist, schaltet es (über den zusätzlichen MQTT-Datenpunkt: dplCmd) OpDTUoB-DPL ein. Ab diesem Moment übernimmt OpDTUoB die Leistungsregelung auf „0-Einspeisung“.
Zusätzlicher Nutzen:
- Werden starke, schnelle Lastwechsel erkannt (Zählerwert springt heftig), schaltet mein Script über den zusätzlichen MQTT-DP dplCmd die DPL von OpDTUoB ab. Sofort steht dann dauerhaft die volle Leistung des HM1200 zur Verfügung.
- Wird anschließend festgestellt, dass über eine definierte Zeitspanne zu viel eingespeist wird, schalte ich DPL mit einer weiteren Deadzone über mqtt.dplCmd wieder ein.
Sobald PV-Leistung fehlt und der Zendure-Bypass automatisch oder manuell deaktiviert wird, können die Batterien wieder einspeisen:
- Dann übernimmt wieder mein Zendure-Script die Regelung.
- OpDTUoB-DPL wird abgeschaltet, weil in diesem Zustand keine doppelte Regelung (Zendure <> OpDTUoB) stattfinden soll.
- Sofort volle Leistung des HM1200 ist dann auch wieder gewünscht.
Vielleicht ist so ein Szenario für dich später ebenfalls interessant – je nachdem, wie du deine größere PV-Anlage planst (Eigenverbrauch vs. Einspeisevergütung, Batteriekonzept usw.).
Ich schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
-
@haselchen sagte in OpenDTU-onBattery Blockly DPL Ein/Aus:
Reine Neugier, warum modifizierte FW und Blockly?
DPL regelt alles automatisch, warum also eingreifen?möchte meine Antwort um (m)einen zusätzlichen Anwendungsfall ergänzen.
Zendure-Setup:
- Zendure HUB2000
- Ladegerät Zendure ACE1500
- mehrere Zendure-Batterien
- am HM1200-Wechselrichter
Die DPL-Steuerung dieses Zendure-Gesamtsystems mit dem HM1200 läuft bei mir komplett über ein JS-Script.
Das regelt zuverlässig und meiner Meinung nach besser als OpenDTU-onBattery.Grundprinzip:
- Das Zendure-System lässt sich per Script steuern, solange es nicht im Bypass ist.
- Bypass schaltet sich automatisch ein, wenn die Batterien voll sind. Dann wird die komplette PV-Leistung direkt an den HM1200 durchgereicht.
- Im Bypass kann das Script nicht mehr regeln.
- Erkennt mein Script per Datenpunkt, dass Bypass aktiv ist, schaltet es (über den zusätzlichen MQTT-Datenpunkt: dplCmd) OpDTUoB-DPL ein. Ab diesem Moment übernimmt OpDTUoB die Leistungsregelung auf „0-Einspeisung“.
Zusätzlicher Nutzen:
- Werden starke, schnelle Lastwechsel erkannt (Zählerwert springt heftig), schaltet mein Script über den zusätzlichen MQTT-DP dplCmd die DPL von OpDTUoB ab. Sofort steht dann dauerhaft die volle Leistung des HM1200 zur Verfügung.
- Wird anschließend festgestellt, dass über eine definierte Zeitspanne zu viel eingespeist wird, schalte ich DPL mit einer weiteren Deadzone über mqtt.dplCmd wieder ein.
Sobald PV-Leistung fehlt und der Zendure-Bypass automatisch oder manuell deaktiviert wird, können die Batterien wieder einspeisen:
- Dann übernimmt wieder mein Zendure-Script die Regelung.
- OpDTUoB-DPL wird abgeschaltet, weil in diesem Zustand keine doppelte Regelung (Zendure <> OpDTUoB) stattfinden soll.
- Sofort volle Leistung des HM1200 ist dann auch wieder gewünscht.
Vielleicht ist so ein Szenario für dich später ebenfalls interessant – je nachdem, wie du deine größere PV-Anlage planst (Eigenverbrauch vs. Einspeisevergütung, Batteriekonzept usw.).
Dein Setup kannste mit meinen 2 Pipifax WR und 4 Panels nicht vergleichen :)
Deine Umsetzung grenzt ja schon an einer Diplomarbeit :joy:Ich hab ,vermutlich, die einfachste Konstellation für das 0 Einspeise-Projekt.
Die neue Anlage hat dann 14,85 kwp , einen 15KW Wechselrichter und eine 12,27kwh Batterie, Smartmeter und automatische Pipapo Regelung intern.
Da muss ich mich dann sowieso erstmal gaaaaaaaaanz in Ruhe reinfuchsen. -
Funktioniert. Danke :+1: :+1: :+1: :+1:
Was hat sich geändert, oder habe ich was überlesen?@Beowolf
update 06.03.2026 10:27h
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2MQTT-Datenpunkte
Die Steuerung erfolgt ausschließlich über MQTT.
Dabei gilt:Neu:
MQTT Topics werden automatisch erkannt und vom ioBroker MQTT Adapter als Datenpunkte erstellt.Status-Topic
mqtt.x.<baseTopic>.dpl.dplState
dplState wird regelmäßig publiziert und der Datenpunkt existiert daher immer automatisch.
Liefert nur den aktuellen Status des Dynamic Power Limiters (DPL)
Werte:
0 = aus deaktiviert
1 = DPL aktivSteuer-Topic
mqtt.x.<baseTopic>.dpl.dplCmd
wird automatisch erstellt.
Dieses Topic dient ausschließlich zur Steuerung des Dynamic Power Limiters.
Werte:
1: DPL aktivieren
0: DPL deaktivieren
Nach jedem Schaltvorgang setzt sich der Wert automatisch auf -1 zurück.Hintergrund des -1 Mechanismus
In ioBroker Blockly kann kein ack:false gesetzt werden.
Ohne Rücksetzen würde ein identischer Wert (z. B. erneut 1) nicht erneut übertragen werden.
Durch den automatischen Reset auf -1 kann derselbe Befehl jederzeit erneut gesendet werden.
Damit ist ein zuverlässiges Schalten auch mit Blockly möglich.NEU: Verhalten bei MQTT-Reconnect
Unabhängig davon, ob- OpenDTUoB neu gestartet wird
- die MQTT-Verbindung unterbrochen war
- der Broker neu gestartet wurde
sendet OpenDTUoB nach der Wiederverbindung automatisch:
dplState
dplCmd = -1Dadurch erkennt ioBroker die Topics erneut und erstellt sie bei Bedarf automatisch.
Eine Steuerung ist danach sofort wieder möglich.Funktionsweise
Status abfragen
Der aktuelle Zustand wird ausschließlich über dplState gelesen.
0 = aus
1 = aktiv
dplCmd wird nach jeder Aktion automatisch auf -1 zurückgesetzt und dient nicht als Statusanzeige.Verhalten nach Deaktivierung des DPL
Wenn der Dynamic Power Limiter deaktiviert wird:Solare Wechselrichter
- gehen automatisch auf maximale Leistung
Es ist kein zusätzliches Setzen von Leistungswerten erforderlich.
Batteriebetriebene Wechselrichter
- verhalten sich weiterhin wie im Original-Repository.
Hinweise zur Nutzung
Jeder Schaltvorgang (dplCmd) erzeugt einen Flash-Schreibzugriff.
Das System ist daher nicht für häufiges Ein/Ausschalten ausgelegt.Empfehlung:
Schaltvorgänge mit zeitlichem Abstand durchführen,
kein dauerhaftes toggeln (z. B. Sekundentakt)Eigenschaften des Patches
Der Patch ist bewusst minimalinvasiv umgesetzt:- keine Änderungen in nicht benötigten Codebereichen
- MQTT Race Conditions werden sauber abgefangen
Eine Rückkehr zur Original-Firmware ist jederzeit über das Web-Firmware-Update möglich.
⚠️ Lizenz & Haftung
Diese Firmware basiert auf OpenDTU-onBattery (GPLv2, Fork von OpenDTU).
Sie enthält eigene Anpassungen und wird nicht offiziell unterstützt.Nutzung erfolgt auf eigene Verantwortung – keine Haftung für Schäden oder Fehlfunktionen.
Firmware im zip muss vor dem flashen entpackt werden.
Bitte nur bin Datei flashen.update 06.03.2026/ FirmwareBuild: generic_esp32s3 firmware:
generic_esp32s3_MQTT-REV2_firmware.zipIch schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
-
@Beowolf
update 06.03.2026 10:27h
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2MQTT-Datenpunkte
Die Steuerung erfolgt ausschließlich über MQTT.
Dabei gilt:Neu:
MQTT Topics werden automatisch erkannt und vom ioBroker MQTT Adapter als Datenpunkte erstellt.Status-Topic
mqtt.x.<baseTopic>.dpl.dplState
dplState wird regelmäßig publiziert und der Datenpunkt existiert daher immer automatisch.
Liefert nur den aktuellen Status des Dynamic Power Limiters (DPL)
Werte:
0 = aus deaktiviert
1 = DPL aktivSteuer-Topic
mqtt.x.<baseTopic>.dpl.dplCmd
wird automatisch erstellt.
Dieses Topic dient ausschließlich zur Steuerung des Dynamic Power Limiters.
Werte:
1: DPL aktivieren
0: DPL deaktivieren
Nach jedem Schaltvorgang setzt sich der Wert automatisch auf -1 zurück.Hintergrund des -1 Mechanismus
In ioBroker Blockly kann kein ack:false gesetzt werden.
Ohne Rücksetzen würde ein identischer Wert (z. B. erneut 1) nicht erneut übertragen werden.
Durch den automatischen Reset auf -1 kann derselbe Befehl jederzeit erneut gesendet werden.
Damit ist ein zuverlässiges Schalten auch mit Blockly möglich.NEU: Verhalten bei MQTT-Reconnect
Unabhängig davon, ob- OpenDTUoB neu gestartet wird
- die MQTT-Verbindung unterbrochen war
- der Broker neu gestartet wurde
sendet OpenDTUoB nach der Wiederverbindung automatisch:
dplState
dplCmd = -1Dadurch erkennt ioBroker die Topics erneut und erstellt sie bei Bedarf automatisch.
Eine Steuerung ist danach sofort wieder möglich.Funktionsweise
Status abfragen
Der aktuelle Zustand wird ausschließlich über dplState gelesen.
0 = aus
1 = aktiv
dplCmd wird nach jeder Aktion automatisch auf -1 zurückgesetzt und dient nicht als Statusanzeige.Verhalten nach Deaktivierung des DPL
Wenn der Dynamic Power Limiter deaktiviert wird:Solare Wechselrichter
- gehen automatisch auf maximale Leistung
Es ist kein zusätzliches Setzen von Leistungswerten erforderlich.
Batteriebetriebene Wechselrichter
- verhalten sich weiterhin wie im Original-Repository.
Hinweise zur Nutzung
Jeder Schaltvorgang (dplCmd) erzeugt einen Flash-Schreibzugriff.
Das System ist daher nicht für häufiges Ein/Ausschalten ausgelegt.Empfehlung:
Schaltvorgänge mit zeitlichem Abstand durchführen,
kein dauerhaftes toggeln (z. B. Sekundentakt)Eigenschaften des Patches
Der Patch ist bewusst minimalinvasiv umgesetzt:- keine Änderungen in nicht benötigten Codebereichen
- MQTT Race Conditions werden sauber abgefangen
Eine Rückkehr zur Original-Firmware ist jederzeit über das Web-Firmware-Update möglich.
⚠️ Lizenz & Haftung
Diese Firmware basiert auf OpenDTU-onBattery (GPLv2, Fork von OpenDTU).
Sie enthält eigene Anpassungen und wird nicht offiziell unterstützt.Nutzung erfolgt auf eigene Verantwortung – keine Haftung für Schäden oder Fehlfunktionen.
Firmware im zip muss vor dem flashen entpackt werden.
Bitte nur bin Datei flashen.update 06.03.2026/ FirmwareBuild: generic_esp32s3 firmware:
generic_esp32s3_MQTT-REV2_firmware.zipupdate 06.03.2026
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2⚠️ Lizenz & Haftung
Diese Firmware basiert auf OpenDTU-onBattery (GPLv2, Fork von OpenDTU).
Sie enthält eigene Anpassungen und wird nicht offiziell unterstützt.Nutzung erfolgt auf eigene Verantwortung – keine Haftung für Schäden oder Fehlfunktionen.
Firmware im zip muss vor dem flashen entpackt werden.
Bitte nur bin Datei flashen.update 06.03.2026/ FirmwareBuild: generic_esp32s3_usb firmware:
generic_esp32s3_usb_MQTT-REV2_firmware.zipIch schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
-
update 06.03.2026
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2⚠️ Lizenz & Haftung
Diese Firmware basiert auf OpenDTU-onBattery (GPLv2, Fork von OpenDTU).
Sie enthält eigene Anpassungen und wird nicht offiziell unterstützt.Nutzung erfolgt auf eigene Verantwortung – keine Haftung für Schäden oder Fehlfunktionen.
Firmware im zip muss vor dem flashen entpackt werden.
Bitte nur bin Datei flashen.update 06.03.2026/ FirmwareBuild: generic_esp32s3_usb firmware:
generic_esp32s3_usb_MQTT-REV2_firmware.zipupdate 06.03.2026
2025.10.11-patch_DplOff-Limit_maximum-MQTT-maxclaudi-Rev_2⚠️ Lizenz & Haftung
Diese Firmware basiert auf OpenDTU-onBattery (GPLv2, Fork von OpenDTU).
Sie enthält eigene Anpassungen und wird nicht offiziell unterstützt.Nutzung erfolgt auf eigene Verantwortung – keine Haftung für Schäden oder Fehlfunktionen.
Firmware im zip muss vor dem flashen entpackt werden.
Bitte nur bin Datei flashen.update 06.03.2026/ FirmwareBuild: opendtufusionv2 firmware:
opendtufusionv2_MQTT-REV2_firmware.zipIch schreibe meistens sehr direkt – bitte nicht falsch verstehen, es ist nie böse gemeint. Das ist einfach mein Stil und niemals abwertend gemeint.
Support us
520
Online32.7k
Benutzer82.6k
Themen1.3m
Beiträge