Monatsrückblick Oktober 2026 ist online!

[maxclaudi]

@Daniel-8
Die Zahlen sind aufschlussreich und bestätigen ein altbekanntes Phänomen bei LiFePO4-Zellen:

Deine Zellspannungen liegen stabil bei 3,27V bis 3,28V, die Gesamtspannung bei 49,39V.
Bei einem 15S-Akku ist das physikalisch ein absolut gesunder, noch gut gefüllter Zustand - chemisch entspricht das eher 60% bis 70% realer Kapazität.

Dass die Firmware 49% ausgibt und das Gerät wegen deines Limits (50%) kurz darauf schlafen schickt, bedeutet:
Die softwareseitige SoC-Berechnung der Firmware läuft zu ungenau, selbst wenn deine Kalibrierung erst 5 Tage her ist.
Vermutlich wurde nicht richtig bzw. vollständig kalibriert.

Wenn das die Werte sind nach dem Aufwachen, dann schaltet das Gerät nicht ab, weil der Akku real leer ist oder die Heizung ihn leergesaugt hat, sondern weil die Firmware sich "verrechnet" hat und fälschlicherweise denkt, der Mindest-SoC sei erreicht.
Physikalisch ist die Batterie noch top.

[maxclaudi]

@Daniel-8

Du hättest zwei Optionen, um das Problem zu lösen:

• Option 1 (Neukalibrierung): Die Kalibrierung noch einmal durchführen. Akku auf 100 % laden und ruhen lassen.
  Danach noch mal sanft nachladen, bis die 100 % garantiert erreicht sind.
  Anschließend bis auf 5 % entladen und nochmals vollständig auf 100 % aufladen.
  Dann sollte die SoC-Berechnung der Firmware eher stimmen.

• Option 2 (Die Skript-Lösung):
  Die kennst Du doch inzwischen ;-)
  Den minSoc in der Firmware auf 10 bis 15 % absenken und die Abschaltung vollständig einem geprüften, sicheren Skript anvertrauen.
  Das Skript überwacht die realen Zellspannungen und schaltet den Entladevorgang sicher ab, sobald die minVol einer einzigen Zelle aller Batterien einen definierten Spannungswert erreicht.

Ich bevorzuge den zweiten Weg, unabhängig von der ungenauen Prozentberechnung der Firmware.

[Daniel 8]

Ja die 49 kommen daher das er halt über Nacht was verliert. Die Akkus werden dann in Standby geschickt. Da ist er aber noch erreichbar. Das ein bisschen mehr drinnen ist wie angezeigt habe ich auch schon festgestellt, wenn er mal auf 100 Prozent lädt und viel weniger rein geht als soll.

Aber das tiefe abschalten ist erst nach ca 13 Stunden der letzten BefehlEingabe.

Das ist für mich kein Problem und wollte es nur mitteilen. Ich bin so zufrieden wenn er bei 50% soc aufhört zum einspeisen.

Mir ist das ganze ja nur aufgefallen weil dann von deinem Script die Meldung IP prüfen kam. Dann schaute ich ob er vom wlan getrennt war. Aber sobald sonne kommt läuft ja wieder alles. Deswegen unternehme ich da auch nichts.

[maxclaudi]

@Daniel-8
Alles klar, dann passt das ja perfekt für dein Setup :-)
Es ist auf jeden Fall gut, dass das für alle Mitleser hier im Thread dokumentiert ist.

Sobald mit der Sonne morgens die MCU erwacht, läuft das Skript ja wie gewohnt weiter.

Ein zusätzliches Isolieren der Batterie(n) wäre zu empfehlen, wenn schon im Oktober nur 8°C erreicht werden.

[maxclaudi]

zURLtool goes to ESP32!

Zuerst wollte ich eine Android-App schreiben.
Außerdem war im Hinterstübchen immer noch die Idee für ein eigenständiges BT-MQTT-Gateway vorhanden.

Dann dachte ich an Nebelkerzenwerfer mit Verschwörungstheorien, was mein Windows-Programm angeblich alles auf dem PC anstellen könnte.
Open-Source ist für mich in diesem Umfeld leider nicht mehr möglich, weil ich es nicht einsehe, dass meine Erkenntnisse und mein Code ungefragt übernommen werden, ohne dass auch nur eine einzige Namensnennung oder ein Danke erfolgt.

Heute Mittag kam mir dann die Idee, eine zURLtool-Firmware für einen ESP32 mit integriertem Webserver zu schreiben.
In einer Schublade lag noch ein passendes ESP32-Board mit 4MB Flash.

Also ab ans Proggen...

Ich habe eine einfache Prototyp-Benutzeroberfläche als Website erstellt (natürlich auch Smartphone-tauglich) und den Code für den ESP32 umgesetzt.

Die .bin-Datei wurde erstellt, kompiliert, geflasht und ... NICHTS.

Es wurde kein Access Point zur Verfügung gestellt und der Chip blieb stumm.

Dann kam mir der Gedanke an diese günstigen ESP32-Entwicklungsboards und deren Empfindlichkeit gegenüber Spannungsspitzen. Fehlende oder zu kleine Blockkondensatoren (C)?

In der Tat, das war das Problem! Ich habe zwei noch vorhandene Elkos auf die Schnelle hinten auf das Board gelötet: einen 220µF-Kondensator an die 3V3-Schiene und einen 10µF-Kondensator an die 5V-Leitung.

Spoiler

Dazu noch ein gutes 5V DC 2.4A Mean Well Hutschienen-Netzteil über ein altes Kabel mit dem Micro-USB-Stecker verbunden und ...

Spoiler

läuft! :-)

Es wird also wahrscheinlich demnächst eine zURLtool-Firmware für den ESP32 geben.

Damit ist für das Umschreiben der Geräte-Konfiguration kein Notebook mit Bluetooth, keine EXE und keine Zusatzsoftware mehr nötig.

Das eigene Heimnetzwerk, ein Smartphone oder ein beliebiger Rechner reichen dann völlig aus – zusammen mit einem ESP32, zwei Kondensatoren und einem 5V-Netzteil.

endlich schlafen :-)

Allen eine erholsame und gute Nacht ;-)

[maxclaudi]

03.11.2026
(Testgeräte HUB2000 / Hyper 2000 / 1600AC+ / 2400 ACpro)

Technische Beobachtung in aktuellen Zendure-Firmware-Versionen: 

Es fällt auf, dass das Verhalten bei (Cloud-)MQTT-Publishes angepasst wurde, was das Echtzeit-Streaming von Werten betrifft. Alle Beobachtungen beziehen sich hierbei auf die properties/report-Meldungen: 

• Früher: Sobald sich Werte von PV-Modulen oder Batterien änderten, wurden diese sofort per MQTT (in Echtzeit) im Report gemeldet.

• Jetzt: Unabhängig von tatsächlichen Wertänderungen wird die properties/report-Meldung nun starr in einem festen Intervall von 5000 ms publiziert. Werte scheinen dort gesammelt übertragen zu werden.

• Aktive Abfrage / externe Befehle: Werden explizite Anfragen oder Befehle an das Gerät gerichtet, erfolgt die Antwort-Veröffentlichung und Änderung – wie bisher – sofort.

• HEMS-Ausnahme: Ist HEMS „in der App aktiviert“ und die Steuerung läuft über die Cloud, scheint es Ausnahmen von dieser Begrenzung zu geben. Zum Teil läuft es scheinbar wie zuvor, damit vermutlich schneller geregelt werden kann (Wertänderungen werden schneller gesendet als das Intervall).

edit 05.11.2026 10:15h
Ob bei deaktiviertem HEMS bei extrem drastischen Wertsprüngen zwischendurch doch ein Sofort-Publish vom Gerät getriggert wird, weiß ich (noch) nicht.
Ich kann es nur hoffen und werde das Verhalten weiter beobachten und versuchen, es in zwei Firmware-Versionen zu analysieren. 

• bei wechselhafter PV-Leistung werden die Werte schneller via MQTT veröffentlicht (Sofort-Publish). Das Gerät reagiert demnach dynamisch auf starke Leistungsschwankungen, auch ohne aktives HEMS.

• zusätzlich bisher unbekannter Schalter (enable/false) in der Firmware identifiziert. Der Status dieses Schalters lässt sich direkt über ein MQTT-Publish steuern.
  edit-Ende

Die Anpassung dient vermutlich der Reduzierung des Traffics der Geräte zur Cloud und der Entlastung des ESP32. 

Die aktuellen Firmware-Versionen von HUB2000, ace1500 und die letzte Firmware-Version vom Hyper < 2 (vor TLS) sind von dieser Änderung nach meinem Kenntnisstand und den vorhandenen Test-Geräten nicht betroffen.

[maxclaudi]

Heute hatte ich wieder einen langen Tag.

Ein Zendure-Gerät und dafür extra einen Broker aufsetzen?

Jemand wollte sein Zendure-Gerät (mit TLS) cloudfrei betreiben und direkt mit dem ioBroker-MQTT-Adapter verbinden.

Bedingungen:

• Zendure-Gerät (TLS)soll sich mit MQTT-Adapter verbinden
• MQTT und zenSDK Steurung sollen möglich sein
• Cloudfrei
• auf keinen Fall extra einen eigenen Broker wie Mosquitto aufsetzen
• Setup sollte simpel, leicht änderbar und direkt einsatzbereit sein
• nichts kompliziertes

Dachte: nicht realisierbar.
Wo fängt man da an?

Nach einigem Grübeln habe ich mir angeschaut was vorhanden ist und was genutzt werden kann und angefangen zu proggen.

Viele Stunden später....

Ergebnis: eine echte eierlegende Wollmilchsau:
TLS-Entschlüsselung und Plain-Brücke für ioBroker in einem.

Das absolut Sensationelle daran:
Der ESP32 verhält sich wie ein Mosquitto-Broker (inklusive Echos und RAM-geschütztem Retain-Speicher) und das mit nur 4MB Flash.
Konnte dafür keine 3rd Party Libs verwenden.
Alle verfügbaren Libs hatten entweder Fehler, waren aufgebläht oder die Funktionen wurden nicht unterstützt.

Also wieder ans Eingemachte....
Der Code baut nur auf den nackten Bordmitteln des ESP-IDF-Frameworks (bzw. Arduino-Core) auf.
Schlanker und effizienter geht es kaum.

Spoiler

Ich dachte selbst erst nicht, dass es klappt ohne PSRAM und mit nur 4MB Flash, aber das Ergebnis läuft stabil und sicher.

Funktionierendes Multi-User-System:

• 2x TLS-Clients (Port 8883): für bis zu zwei Zendure-Geräte.

• 3x Plain-Clients (Port 1883): ohne TLS, z. B. für den ioBroker-Adapter, MQTT-Explorer und MQTTX.

Ein separater MQTT-Broker wird damit komplett überflüssig.
Die Konfiguration (WLAN und TLS-Zugangsdaten) erfolgt einfach einmalig seriell über USB am Rechner, z.B. mit Arduino-Serial-Monitor oder PuTTY.

Man kann im laufenden Betrieb:
• "setup" eingeben und schnell Daten ändern.
• "status" eingeben und man erhält Infos (siehe Bilder)

Spoiler

Also wurde nur kurz zURLtool benutzt und nun übernimmt ein alter Standard ESP32 mit 4MB flash (noch mit Micro-USB) den Broker.
Bild im Spoiler

Spoiler

Darf ich vorstellen :-) ... ein vollwertiger TLS-Broker für Zendure Geräte:

.
Einrichtung von Zendure-Gerät und ESP32-Broker komplett in ca. 10min.

Wahnsinn.... Ziel erreicht!

Wieder so spät, hoffe Popcorn ist noch vorhanden ;-)

und wieder Allen eine erholsame und gute Nacht ;-)

[maxclaudi]

Wünsche allen ein schönes Wochenende :-)

Vielleicht ist jemandem langweilig oder möchte wissen, was ich momentan teste.
Roman zum Wochenende und vielleicht Interesse an einem Projekt?

ja? Dann spoiler lesen ;-) ...ansonsten nicht weiter beachten.

Spoiler

ESP32 WROOM 4MB FLASH als lokaler TLS-Broker läuft "bis jetzt" unauffällig, schnell, stabil und zuverlässig.
Nach TLS-Verbindung mit dem zenGerät scheint er sich beinahe zu langweilen.
Auch wenn man ihn per Skript mit unnötigen und häufigen Anfragen zu fluten versucht...
ist er nicht aus der Ruhe zu bringen und arbeitet weiter.
Mit 1 TLS-Client und 3 Clients über 1883 (iobroker-Adapter, MQTTX und MQTT-Explorer) funktioniert es gut.
Bleibt weiterhin im Test-Run.

Das hat mir keine Ruhe gelassen.
Vielleicht geht noch ein wenig mehr... los ging's.

---

Beta-Status erreicht und die eierlegende Wollmilchsau ist seit Stunden im Testbetrieb.
Bin gespannt, ob das stabil und dauerhaft läuft.

Hardware:
ESP32 WROOM D0WDQ6 Revision v1.0 4MB FLASH
altes Board aus der Schublade, siehe Bild.

Wofür? Was ist das?

Der ESP32 ist:
• TLS-Client zu einer anderen DNS/CLOUD als Bridge
• ein TLS-Broker Port: 8883 für 1 TLS-Client zenGerät
• ein Broker Port: 1883 für maximal 3 zusätzliche Clients mit jeweils User + Passwort
Z. B. für iobroker-MQTT Broker/Client-Adapter v8.1.2, MQTTX und MQTT-Explorer

---

Was wird benötigt?

• 1 Zendure-Gerät (z. B. 800 pro plus / 1600 AC+ / 2400AC pro plus)
• iobroker Adapter MQTT Broker/Client Adapter v8.1.2 als Client
• ESP32 mit 4MB FLASH
• irgendein Kunststoffgehäuse für den ESP32
• gutes Netzteil für den ESP32 mit stabilen 5V mit "reinem" geglätteten DC-Ausgang und lieber zu viel A als zu wenig.
• Schalter (Schliesser) oder Brücke.
• zURLtool oder AdGuard oder Pi-hole, um die DNS des zenGeräts auf die IP des ESP32 umzukonfigurieren.
• WLAN-Router (Fritzbox etc.) oder WLAN-AP mit DHCP

---

Wie soll das funktionieren?

Siehe Bilder.

Nachdem der ESP geflasht ist, öffnet man eine serielle Konsole (Visual Studio Code PlatformIO / PuTTY oder Arduino serieller Monitor etc.).

• Ist der Chip nicht konfiguriert, landet man automatisch im Setup.
• Ist der Chip bereits konfiguriert, hat man beim Starten 3 Sek. Zeit, um ins Setup zu kommen.
Z. B. nach RESET durch die Reset-Taste.

Dann kommen die Abfragen.
Betätigt man nur die Enter-Taste, wird nichts geändert.
Ansonsten gibt man entweder ein, was geändert werden soll, und betätigt danach die Enter-Taste,
oder man gibt nur das Minuszeichen ein und drückt die Enter-Taste, um den aktuellen Wert zu löschen.

Zur Konfiguration kann man sich zuvor alle Daten in einem Textfile vorbereiten
und dann per Copy-Paste einfach jeweils einfügen.
Es ist ein reines zenGateway (Bridge) und nur für 1 zenGerät.

Erforderliche Daten:
Es muss mindestens ProductKey und DeviceID eines Geräts eingegeben werden.

Der Reihe nach wird abgefragt:
WLAN-SSID
WLAN-Passwort
CLOUD-DNS
ProductKey
DeviceID

und danach für den Port: 1883 jeweils gewünschte User + Passwort

Am Schluss wird noch der LOG-LEVEL abgefragt.
Sollte das System absolut stabil laufen, dann 0 setzen.

Das war es, mehr ist nicht nötig :-)

Danach verbindet sich der ESP mit dem Heim-WLAN und zeigt seine bezogene, aktuelle IP an.

Die angezeigte IP im Internetrouter (z. B. Fritzbox) dauerhaft festlegen.

Dann kann man den ESP trennen, an ein besseres Netzteil anschließen und am besten in der Nähe des WLAN-Routers platzieren.

Wenn ein Schalter (Schließer) zwischen GPIO: 17 und GND angeschlossen wird, kann man umschalten.
Ist kein Schalter angeschlossen, dann ist der ESP im Bridge-Betrieb zur Cloud.
Ist ein Schalter (Schließer) an GPIO:17 und GND angeschlossen und eingeschaltet ODER eine Brücke von GPIO:17 zu GND vorhanden, dann wird die Cloud-Verbindung getrennt und das zenGerät ist rein lokal mit dem ESP32 als Broker verbunden mit lokalen Client(s).

Man kann also zwischen Cloud oder lokal physisch umschalten.

---

Aktuelle Analyse auch als Memo für mich:

Zum Status:
Unnötige Cloud-Echos werden ausgewertet und gefiltert.
Dass die ms größer werden, ist gut und hat seinen Grund.

Der errno: 104, "Connection reset by peer":
[STATUS] IP 192.168.50.153 | Clients 4 | Switch-Cloud: AKTIV | Cloud-TLS VERBUNDEN | Gerät aktiv: JA | Heap frei 129276 | Min 102428 | Max-Block 69620 | Cloud-Echo 1563
[4297115][E][WiFiClient.cpp:429] write(): fail on fd 50, errno: 104, "Connection reset by peer"
[STATUS] IP 192.168.50.153 | Clients 4 | Switch-Cloud: AKTIV | Cloud-TLS VERBUNDEN | Gerät aktiv: JA | Heap frei 128944 | Min 100704 | Max-Block 57332 | Cloud-Echo 2395
war bewusst erzwungen.

Schließen ohne DISCONNECT vom MQTT-Explorer und gleich wieder Öffnen + CONNECT.
Ein Test, wie sich der ESP mit HEAP verhält.

Alles ok, sieht nicht übel aus.
Werte, auf die es ankommt, sind stabil.

Heap frei: Er liegt über die ganze Zeit zwischen etwa 129 und 133 KB.
Er sinkt nicht, sondern pendelt.

Min: Er ist von 102 KB auf 99,7 KB gefallen, also um etwa 3 KB in mehreren Stunden.
Min kann nur sinken, und kleine Stufen kommen von einmaligen Spitzen, zum Beispiel beim Wiederaufbau einer Verbindung.
Problem wäre, wenn er mit jedem Reconnect um ein paar KB weiterfällt und am Ende unter etwa 50 KB landet.

Max-Block: Der Abfall von 69 bis 73 KB auf 57 KB passt zeitlich zum Test mit der Fehlermeldung write(): fail on fd 50, errno: 104, "Connection reset by peer".
Verbindung wurde dabei zurückgesetzt.
ESP und Gegenstelle haben danach neu aufgebaut.
Die neuen Puffer liegen an anderen Stellen im Speicher.
Das ist normale Fragmentierung.
57 KB sind aber weit mehr als 16 KB, die ein neuer TLS-Puffer braucht :-)

---

ToDo:
Vorerst nur laufen lassen und beobachten:

• Heap sollte um 130 KB frei bleiben.
• Max-Block sollte über etwa 40 KB bleiben.
• Min darf nicht bei jedem Reconnect weiter fallen.

Zum Schluss noch ein Bildausschnitt vom Notebook, auf dem ioBroker, MQTTX und MQTT Explorer gleichzeitig mit dem ESP-Broker verbunden sind, während der 1600AC+ Daten an die Cloud und an alle Clients liefert.

Falls jemand sich bedanken möchte für den Roman, bitte nur voten ;-)
Ein extra Post ist dafür nicht nötig.

Wer Fragen oder Interesse an dem Projekt hat, bitte schön :-)

Liebe Grüße maxclaudi

[maxclaudi]

...manchmal möchte man mehr, und nun ist es gelungen und gut. :-)

NEU: nur noch APP und ESP32-Board WT32-ETH01 werden benötigt.

Ein zenGerät lokal über MQTT verbinden und in Echtzeit steuern:
• ohne extra Broker
• wahlweise lokal isoliert oder innerhalb von Sekunden umgeschaltet ins Internet zur Cloud mit einfachem Befehl.
• wahlweise zenSDK oder echtes, schnelles MQTT (nicht das lokale HA-MQTT!)
• Nur ESP32 WT32-ETH01 und zenApp zur einmaligen Einrichtung werden benötigt.

                    +-----+
                    |ESP32| <- LAN -> |Verbindung aus- einschaltbar | <- PORT 8883 mit TLS -> Router (z. B. FritBox) <- Internet-> TLS-Cloud
zenGerät <- WLAN -> |WT32-| <- LAN -> PORT 1883 ohne TLS lokal  z. B. iobroker MQTT-Adapter als Client lokale Steuerung
                    |ETH01| <- LAN -> PORT 1883 ohne TLS lokal Reserve z.B. gelegentlich MQTT-Explorer
		    |W/LAN| <- LAN -> PORT 1883 ohne TLS lokal Reserve z. B. gelegentlich MQTTX
		    +-----+

Final und läuft seit heute, 07.11.2026 21:00 Uhr, im ununterbrochenen Dauertest.

Wer Interesse hat, liest den Spoiler, sonst einfach ignorieren.

edit/ps 08.11.2026 16:30h

Spoiler

Steuerung isoliert lokal oder mit Cloud.
Einfach umschaltbar in Sekunden.
Alles ohne externen Broker, ohne AdGuard, ohne Pi-Hole etc. und ohne Router-Tricks. Internetsperre nicht nötig.

Was wird benötigt?

• zenGerät
• MQTT-Client z.B. ioBroker MQTT Broker/Client v8.1.2 - Adapter
• ESP32-Board WT32-ETH01 (Empfehlung: mit >= 100µF Elko).
• Smartphone mit zenApp
• LAN in der Nähe des zenGeräts

Habe noch einige PCB von einem anderen Projekt

---

Ersteinrichtung ESP32 kinderleicht - einmalig über die serielle Konsole.

Eingegeben werden folgende Daten:

• CLOUD DNS
• productKey
• userID
• die ( maximal 3) Client - Konten PORT 1883 ohne TLS
• SSID-WLAN-AP: für ESP32 WT32-ETH01
• WLAN-Password-AP: für ESP32 WT32-ETH01
• LOG-Level (bei Normal-Betrieb: 0)

Alles Weitere wird vollautomatisch erledigt.

---

Einrichtung des zenGeräts:

• Smartphone BT einschalten
• zenAPP öffnen.
• In der App Netzwerk einrichten:
  Netzwerk auswählen: SSID-WLAN-AP vom ESP32 WT32-ETH01
  Passwort: vom WLAN-Password-AP eingeben.

verbinden und drin. "einfach drin" - kinderleicht :-)

WLAN-AP setzt automatisch: 192.168.4.1 und lässt nur 1 Gerät zu.

Durch die Platzierung direkt neben dem 1600AC+ hat das Gerät eine super Verbindung bei -35 dBm ohne paketbasierte Latenzen:

---

Highlights & Funktion

1. Dedizierter LAN- & AP-Betrieb
ESP32 bezieht seine Daten und - wenn man möchte - Internetverbindung stabil über LAN.
WLAN-Teil wird vom Heimnetz entkoppelt und arbeitet isoliert als WIFI_AP, fest limitiert auf 1 Verbindung für das zenGerät.

2. Integrierter Mini-DNS-Server
Ein integrierter DNS-S. leitet auf den ESP-AP mit IP 192.168.4.1 um.
Gerät verbindet sich mit dem lokalen TLS-Broker des ESP32, während Bridge den Namen über das Heimnetz auflöst.

3. Integrierte Whitelist für den Bridge-Tunnel
Sicherheitstechnisch ein Meilenstein:
Das Gateway besitzt eine integrierte Whitelist.
Lokale 1883 Clients (ioBroker, MQQTX, MQTT-Explorer etc.) dürfen unverschlüsselt auf Port 1883 Daten austauschen, aber der ESP32 lässt nur die echten zen-topics des Geräts in das Inet.
Fremde Daten oder lokaler Skript-Traffic werden gefiltert und blockiert, auch wenn die Bridge aktiviert ist.

4. Statischer Heap-Schutz gegen Fragmentierung
Speicherarchitektur wurde zur Vermeidung von Fragmentierung im 24/7 auf statische char-Arrays umgestellt.
Die Funktion parst MQTT-Pakete ohne jede Heap-Allokation direkt in feste Speicherbereiche.
Heap bleibt bis jetzt konstant.

5. Software-Bridge-Steuerung über MQTT
Die Cloud-Bridge wird softwareseitig über ein lokales MQTT-Topic:

/bridgeMode

gesteuert. Mit

{"bridgeSwitch":0}

wird die Cloud-Verbindung abgeschaltet und sauber getrennt, während der lokale TLS-Server für den Hub unterbrechungsfrei weiterläuft.

{"bridgeSwitch":1}

verbindet bei Bedarf wieder mit Cloud. Z. B. falls man doch die App unterwegs benötigt.

Durch den statischen Stream-Parser und die Reduzierung der Stack-Puffer ist das System für den dauerhaften Betrieb ausgelegt.

toDo
Testlauf und nur noch reine Beobachtung.

---

Wer vielleich noch einen WT32-ETH01 hat... ;-)

Falls jemand sich bedanken möchte, bitte nur voten.
Ein extra Post ist dafür nicht nötig.

Wer Fragen oder Interesse an dem Projekt hat, bitte schön :-)

---

edit/ps 08.11.2026 16:30h

Ein User bat um meine Hilfe, das Projekt umzusetzen.
Er hat zwei zenGeräte (SF2400 AC, 1x SF 800 Pro 2) und zwei ESP32-WT32-ETH01.

Knackpunkt: In der Nähe gibt es kein LAN-Anschluss und das WLAN ist dort nicht gut – meinte er.

Nach kurzer Unterhaltung und dem Eruieren, was vor Ort gegeben und vorhanden ist, war die Lösung schnell gefunden und umgesetzt.

Ein alter TP-Link-Router, den er noch herumliegen hatte, war schnell als WLAN-Brücke (Wireless Client Mode) konfiguriert.
Dieser ist nun per WLAN mit dem Heimnetz (Fritzbox) verbunden.

Das Signal ist um Welten besser als das von den zenGeräten mit ihren ESP-Chips.
Vorher lag RSSI im Schnitt bei -79 dBm.
Der Router mit seinen externen Antennen erreicht nun -58 bis -64 dBm (wird zumindest so angezeigt).
Der Router hat vier LAN-Buchsen, an die die zwei ESPs angeschlossen wurden.
Die beiden ESPs sind ca. 30 cm voneinander getrennt und werden gemeinsam über ein 5V-3A-Netzteil versorgt.
Weil es ein Noname-Netzteil ist, wurde bei beiden ESPs zwischen 5V und GND jeweils ein Elko mit 220 µF angeschlossen.
Zudem wurde zwischen dem EN-Pin und GND jeweils noch ein Elko mit 100 µF angelötet.

Ergebnis:
Es funktioniert besser als zuvor – allein schon, weil die Bridge eine deutlich bessere Verbindung zum WLAN hat als die zenGeräte.
Die zwei ESP32-WT32-ETH01 befinden sich nun weniger als einen Meter von den zenGeräten entfernt und haben damit natürlich ebenfalls eine Top-Verbindung.

Läuft! :-)

Wer noch Fragen hat, bitte schön.
Wünsche Allen einen wunderschönen Sonntag.

edit/Ende

Was für ein Meilenstein in meiner persönlichen zenHistory und weltweit.
Was für ein gelungenes Wochenende.
Wünsche Allen eine schöne, gute Nacht :-)

[maxclaudi]

Tipp
gleich noch einmal separat, weil mein Tipp einem User sehr geholfen hat:
Wenn jemand WLAN-Probleme mit dem zenGerät hat und das Handy daneben eine gute WLAN-Verbindung – wichtig: im 2,4-GHz-Netz – hat, dann könnte eine WLAN-Bridge direkt neben dem zenGerät Wunder bewirken.