Neuer Installer und neuer Fixer: übersichtliche Oberfläche und `iob docker`

[maxclaudi]

@MP_Trixi
Es reicht auch nur control.socCompSwitch zu löschen.

[MP_Trixi]

@maxclaudi
danke für deinen Input - habe ich gemacht (altes Script gestoppt, control.socComSwitch gelöscht, neues Script gestartet). Ich werde testen

[maxclaudi]

@MP_Trixi
Kann es sein, dass im Moment keine oder zu wenig Leistung kommt?
Ist bei mir so.
Es gibt eigenlich unter properties nur:

properties.outputPackPower
properties.packInputPower

Zur Kontrolle kannst Du das Script zur Nulleinspeisung stoppen.
Setze dann mal im dp:

control.auto_outputLimitMode

100 oder -100

gib dem Befehl 10 sek Zeit.
Danach ändert sich auch der Wert in
properties.packInputPower
oder
properties.outputPackPower

Wenn das funktioniert ist zu wenig PV-Leistung vorhanden. Müsstest Du auch in properties.solarInputPower feststellen.

Für die PV-Leistung oder Sonne kann ich nichts ;-)

PS: Durch das Edit von Dir sieht mein Post nun super aus :-)

[maxclaudi]

maxclaudi sagte:

Die SolarFlow 800er-Pro-Serie hat die Steuerelektronik, die 4 MPPT-Regler und den Wechselrichter komplett in einem Gehäuse integriert.
Dieses Gesamtsystem (inklusive ESP32-Chip, WLAN, Bluetooth und Batterie-Management-System) hat einen permanenten, spürbaren Eigenverbrauch für den reinen Betrieb.

Wenn dir die App am Morgen anzeigt, dass mit "10 W" geladen wird, bedeutet das rein physikalisch folgendes:
Deine PV-Module müssen zu diesem Zeitpunkt bereits den kompletten internen Grundverbrauch des Geräts (für CPU, WLAN, BMS-Aktivierung etc.) gedeckt haben. Erst die Leistung, die darüber hinausgeht, bleibt netto übrig und wandert als die von dir gesehenen 10 W in die Batterie.

Man darf hier die reine Startspannung der MPPT-Tracker (die beim Pro 2 erfreulicherweise schon ab 14 V liegt) nicht mit der notwendigen Mindestleistung für den Systembetrieb verwechseln.
Ohne dass die PV-Leistung die interne Grundlast des Speichers vorab komplett kompensiert, kann das Gerät weder einspeisen noch laden.
Die Solarmodule müssen real also schon deutlich mehr als 10 W liefern, damit das System überhaupt aus dem Standby erwacht.

Heute ist bei mir so ein Tag - Regen - trüb.
2400ACpro werden PV-Leistung: 0 angezeigt obwohl 3 Module (420W, 200W, 200W) per DC MC4 angeschlossen sind.
Im Gegensatz Hoymiles:
Jedes einzelne Modul an einem Hoymiles speist mit 9 bis 23W ein.

[maxclaudi]

Update: Das zenSDK-Skript ist aktuell.
Wichtigste Änderung bleibt das auto_in_out_Limit (Danke @danitz!).
Da anscheinend noch ein paar ältere Versionen genutzt werden, obwohl es im letzten Skript schon drin war: Bitte updaten!

maxclaudi sagte:

update 16.10.26 21:00h
batCalTime zusätzliche Type-Prüfung; fallback 01:00h / control.socCompSwitch ohne Funktion, entfernt

Wer bisher das Script bereits nutzt: Bitte vor Ausführung des Scripts den Datenpunkt:

control.socCompSwitch

löschen.

Alternativ gesamtes Verzeichnis mit allen Datenpunkten (inkl. dp properties etc.) löschen, für zusätzliche Beschreibungen.

Zum aktuellen Skript: HIER KLICKEN

[maxclaudi]

20.10.2026; 15:18h Fortsetzung von:

15.10.2026; 16:00 Uhr: Weiterer Bericht zum Betrieb über MQTT-Port 1883 und zenSDK POST #628

Da es dazu weltweit quasi null Infos gibt, dachte ich, ich teile meine bisherigen Erkenntnisse mal auszugsweise als kleinen Bericht mit euch.

Die Fortsetzung ist vermutlich gleichzeitig der Abschluss.

Wer möchte, kann den Bericht im Spoiler lesen;
für alle anderen ist der Beitrag dann kürzer und kann ignoriert werden. :-)

Spoiler

Ich habe meine Analysen abgeschlossen und teile ein paar Ergebnisse mit euch.

TLS Verbindung Port: 8883
Das wichtigste Ergebnis vorab:
Der herkömmliche, vorgesehene "Normal-" Betrieb über TLS ist absolut stabil möglich.

Es gibt keine Verbindungsabbrüche und keine Reconnects mehr – und das gilt auch für den Mosquitto-Bridge-Betrieb, sofern die eigene lokale IP im Zendure-Gerät (mithilfe meines zURLtool) konfiguriert ist.
Alles läuft extrem schnell und stabil.
Für mich gibt es dadurch keinen Grund mehr, einen anderen Weg einzuschlagen - vor allem nicht mit zusätzlichen Optionen (mehr dazu folgt weiter unten).
Durch die Stabilität und Schnelligkeit bei der jetzigen, regulären Betriebsart (TLS-Port 8883) kann ich keinen Mehrwert mehr über eine alternative Verbindung feststellen.
Zuvor war der ESP anscheinend auch teils durch die ständige Verarbeitung der Disconnects und Reconnects überlastet.
Jetzt ist alles super.

Die ständigen Disconnects/Reconnects der 8883-TLS-Verbindungen - seltsamerweise vom Client zum mosquitto-Broker und vermehrt im Bridge-Betrieb - waren für mich ein Kernproblem.
Laut Log passierte das ja quasi ununterbrochen im Minutentakt, teilweise sogar mehrfach pro Minute, obwohl man es subjektiv nicht richtig bemerkte.
Dachte immer, dass der ESP32-C überlastet wäre - jedoch explizit durch was?
Nur weil TLS verwendet wird und mit 1883 gab es keine Probleme.
Konnte doch nicht sein...
Nach tagelanger Analyse habe ich des Rätsels Lösung gefunden.
Im Nachhinein betrachtet fast trivial – aber mein Reverse Engineering hat sich hier definitiv gelohnt.
Die zuvor beobachteten ständigen Disconnects/Reconnects und OpenSSL-Fehler, die den ESP unbemerkt auslasteten, sind damit behoben.

Bisher dachte ich, die kursierenden Informationen der Open-Source-Community zu Bluetooth, MQTT & Co. seien korrekt oder nur minimal fehlerbehaftet, weil sie sich an vielen Stellen fast eins zu eins gleichen.
Dem ist aber nicht so.
Scheinbar wurde hier oft nur voneinander abgeschrieben.

---

Wenn man weiß, wie es geht, eröffnen sich ein paar sehr interessante Optionen:

• HTTP-Server komplett abschalten (localAPIenable true/false):
  Damit lässt sich der HTTP-Port bzw. der interne Webserver gezielt ein- oder ausschalten.
  Wenn er deaktiviert ist, kann das zenSDK natürlich leider nicht genutzt werden.
  Den reglementierten, „offiziellen lokalen HA-MQTT“ möchte man aber sowieso eher nicht nutzen.
  Der Vorteil:
  Ist der Server aus, wird der ESP32-C zusätzlich entlastet.

• Freie SoC-Grenzen:
  Es ist möglich, minSoc (5–98 %) und socSet (6–100 %) völlig frei einzustellen.
  Theoretisch beide von 0–100 %, jedoch muss socSet immer größer sein als minSoc!
  Damit lassen sich beispielsweise der Bypass (pass:0 / pass:2) und die Wirkung von socLimit indirekt steuern.
  Wenn der Webserver eingeschaltet bleibt, funktioniert das auch für zenSDK.
  Außer es wird in einer künftigen Firmware wieder geändert.
  Ich hoffe sehr, dass der Hersteller nichts ändert!
  Die Probleme mit den Verschlimmbesserungen beim SoC-Thema sollte endlich ein Ende finden.
  Hier gibt es bisher überhaupt kein Problem.
  Hoffentlich hört das Reglementieren auf..
  Aktuell getestet mit einigen Geräten <= V2.0.2 und V2.0.4 beim SF2400ACpro.

---

Cloud- & Bridge-Modus:

Bisher läuft alles tadellos über den Mosquitto-Broker im Bridgemodus zur Cloud.
Das Ganze ist absolut flexibel:

• Bei Bedarf muss man nur eine einzige Zeile auskommentieren und ist innerhalb von Sekunden entweder komplett lokal oder wieder mit der Cloud verbunden.

• Das Gleiche gilt für den Bridge-Mode: Man kann sich mit der Cloud verbinden – wahlweise mit oder ohne Schreibrechte für die Cloud.

• Bei deaktiviertem HEMS hat die Cloud von sich aus (bis jetzt) ausschließlich die Uhrzeit aktualisiert. Gut so.

---

HEMS- & NVS-Verschleiß (Flash):

Ich nutze HEMS selbst zwar nicht, habe es aber nun genauer auf dem Schirm.
So wie es „für mich aktuell“ aussieht, werden bei der Nutzung von hemsEp sehr wohl manche Parameter direkt in den NVS geschrieben.
Zwar nicht permanent kontinuierlich, aber bestimmte Keys landen dort.
Das betrifft nicht nur den Hyper, sondern auch mindestens 1600ACplus und SF2400ACpro, vermutlich alle Geräte.
Wer glaubt, dass alles ausschließlich im RAM landet, soll das gerne glauben.

Wie geht es weiter?
Für meinen Teil muss ich nun noch die Dokumentationen vervollständigen und ordnen.
Werde noch einmal die Geräte – pro forma erneut, frisch – aufsetzen und im reinen, produktiven Testbetrieb beobachten und loggen.
Evtl. widme ich mich nun noch etwas dem Thema hemsEp NVS/RAM – hat aber keine Priorität für mich, weil ich es nicht nutzen möchte.
Weil wir gerade beim Thema NVS sind: smartMode: 1 lässt sich für mich schwerer nachverfolgen als hemsEp.
Manches kann ich bis jetzt nicht eindeutig nachvollziehen, deshalb äußere ich mich auch nicht dazu.

Das war es dann.

Wer sich bedanken möchte, weiß ja, wo der Voting-Button ist. Ein extra Post dafür muss nicht sein. ;-)

Wie bei einem langweiligen Film: Endlich Ende! :-)

edit 21.10.26; 10:35h
Keine Tester mehr gesucht.
Tester und Nuzer denen ich mit mosquitto broker half, bitte per PM oder email melden. Danke.

Testers and users whom I have assisted while they were working with the Mosquitto broker: please get in touch with me via pm or email. Thanks.

[Daniel 8]

@maxclaudi sagte:

TLS Verbindung Port: 8883
Das wichtigste Ergebnis vorab:
Der herkömmliche, vorgesehene "Normal-" Betrieb über TLS ist absolut stabil möglich.

Kann man den Port über die app Option einfach so einstellen?

Das heißt mit dem läuft alles schneller und über mqtt. Dann bräuchte man Zensdk gar Nicht mehr.

Irgendwie übersteigt das ganze hier jetzt mein können.

[maxclaudi]

@Daniel-8 sagte:

@maxclaudi sagte:

TLS Verbindung Port: 8883
Das wichtigste Ergebnis vorab:
Der herkömmliche, vorgesehene "Normal-" Betrieb über TLS ist absolut stabil möglich.

Kann man den Port über die app Option einfach so einstellen?

Um es verständlicher zu erklären: Es geht hier um zwei unterschiedliche MQTT-Verbindungen.

Port 1883 ohne TLS:
Man kann den Port 1883 ohne TLS am Gerät und in der App (gewusst wie) freischalten und aktivieren.
Ab dann ist das Gerät über Port 1883 mit einer DNS-Adresse verbunden.
Diese DNS-Adresse muss per AdGuard, Pi-hole oder über einen eigenen DNS-Server auf den lokalen Broker umgebogen werden, wenn man lokal über die Datenpunkte steuern möchte.
Aber bei dieser Verbindung sind zu viele - ich nenne es mal - Möglichkeiten vorhanden und sollte m. M. n. nur kurzzeitig verwendet werden, näher gehe ich darauf nicht ein.

---

Port 8883 mit TLS:
Das ist der Standard.
So verbindet sich jedes Gerät.
Das Gerät ist über Port 8883 mit einer DNS-Adresse verbunden.
Diese DNS-Adresse kann ebenfalls per AdGuard, Pi-hole oder DNS-Server auf die IP des lokalen Brokers umgebogen werden, wenn man lokal über die Datenpunkte steuern möchte.

Alternativ:
Man konfiguriert die Variable für DNS/IP auf dem Gerät mit dem zURLtool um auf den lokalen Broker.
Auf dem lokalen Broker (z.B. Mosquitto) kann zusätzlich eine Bridge eingerichtet werden, damit das Gerät mit der Cloud verbunden bleibt.
Es ist in wenigen Sekunden erledigt, diese Bridge wahlweise abzuschalten oder der Cloud nur Lesezugriffe oder vollen Zugriff zu erlauben.

Mit einem lokalen Broker über MQTT ist die Steuerung zuverlässig, stabil und schneller als über die Cloud oder die lokale API (also auch zenSDK).

zenSDK macht nach meinen Analysen und Tests nur einen kleinen Unterschied, solange kein erhöhter HTTP(S)-Traffic im jeweiligen IP-Bereich bzw. Netzwerk vorliegt.
Wenn diese Voraussetzung gegeben ist und ein Abfrageintervall (Get) von etwa 4000 ms stabil möglich ist, kann auch das zenSDK genutzt werden.
Es ist dann nur unwesentlich langsamer als MQTT.

Der Grund dafür ist hardwarebedingt.
Auch wenn MQTT durch den schnelleren, automatischen Bericht-Versand (Report Publish) vom Gerät und das schnellere Publizieren neuer Werte klar im Vorteil ist, benötigt das Gerät hardwarebedingt Zeit.
Eine Limit-Umschaltung von inputLimit oder outputLimit braucht beispielsweise Zeit, um den Zielwert vollständig umzusetzen.

Einfacher Vergleich:
Du kannst bei einem Auto mit Automatikgetriebe und Turbolader zwar das Gaspedal oder die Bremse voll durchtreten, aber es dauert dennoch eine gewisse Zeit, bis die Höchstgeschwindigkeit oder der Stillstand erreicht sind.

Alle Klarheiten beseitigt? ;-)

---

Das heißt mit dem läuft alles schneller und über mqtt. Dann bräuchte man Zensdk gar Nicht mehr.

Richtig.
zenSDK ist, wie erklärt, unter den passenden Voraussetzungen langsamer als der lokale Broker über MQTT.
Eigentlich ist MQTT vorzuziehen, da hier nicht auf neue Werte gepollt werden muss, sondern diese sofort automatisch publiziert werden.
Zudem kann die lokale API abgeschaltet werden (gewusst wie) und der ESP32-C wird dadurch weiter entlastet.

22.10.2026:
ESP32-C, das ist übrigens die Standard-CPU, die verwendet wird und noch nirgendwo offiziell weltweit dokumentiert wurde.

Irgendwie übersteigt das ganze hier jetzt mein können.

Jetzt nicht mehr ;-)

Hinweis:
Ich überlege gerade ein MQTT-Steurungs-Script anzupassen, damit es als Ersatz für das zenSDK-Steuerungs-Script verwendet werden kann.
Damit bleiben alle Datenpunkte identisch, wenn man es gleich konfiguriert wie das zenSDK-Steuerungs-Script.
Bei identischer Benennung und Konfiguration, muss man darauf achten dass nur 1 Steuerungs-Script aktiv ist.

Bei unterschiedlicher Benennung kann zenSDK und MQTT gleichzeitig, simultan genutzt werden oder auch nur eins von beiden als vorrangiges Steuerungsscripts.

MQTT liefer natürlich einiges mehr an Infos.

[Daniel 8]

Vielen Dank für die ausführlichen Antworten.

Dann belasse ich es mal bei der Steuerung über zenSDK.

Ich Kämpfe seit 3 Tagen mit einem Problem wo ich nicht weiß woher das kommt.
Immer um 6.57 Uhr bringt das Script die Meldung Das ich meine IP Adresse überprüfen soll.

Und heute hat irgendwie mein Steuerungsscript komplett verrückt gespielt und mal alles ins Netz eingespeist. Das lief bis jetzt ohne Probleme schon eine Weile. Wobei ich heute auch das Firmware Update auf 2
0.5 gemacht habe.

War leider arbeiten und konnte nicht schauen warum dies heute so passiert ist.

[maxclaudi]

@Daniel-8 sagte:
Immer um 6.57 Uhr bringt das Script die Meldung Das ich meine IP Adresse überprüfen soll.

Wenn das täglich zur gleichen Uhrzeit vorkommt:
Prüfe mal deinen WLAN-Router oder WLAN-AP, ob dort ein täglicher Neustart konfiguriert ist.

[Daniel 8]

@maxclaudi sagte:

@Daniel-8 sagte:
Immer um 6.57 Uhr bringt das Script die Meldung Das ich meine IP Adresse überprüfen soll.

Wenn das täglich zur gleichen Uhrzeit vorkommt:
Prüfe mal deinen WLAN-Router oder WLAN-AP, ob dort ein täglicher Neustart konfiguriert ist.

Ist nicht immer ganz genau zur gleichen Zeit. So ca. Plus minus 6 Minuten.

Nein habe nichts programmiert. Ich werde mal beobachten. Jetzt ist ja zumindest der Speicher mal neu gestartet mit der neuen Firmware.
Und so werde ich schritt für schritt testen. Habe ja auch nichts verändert. Deswegen verstehe ich es nicht warum es jetzt so ist.

[maxclaudi]

@Daniel-8 sagte:
Ist nicht immer ganz genau zur gleichen Zeit. So ca. Plus minus 6 Minuten.

Nein habe nichts programmiert. Ich werde mal beobachten. Jetzt ist ja zumindest der Speicher mal neu gestartet mit der neuen Firmware.
Und so werde ich schritt für schritt testen. Habe ja auch nichts verändert. Deswegen verstehe ich es nicht warum es jetzt so ist.

Ich würde es dennoch nicht ausschließen und überprüfen.
Das gilt vor allem auch für sogenannte Repeater, falls einer im Einsatz ist.

Repeater sind für solche Verbindungen nicht optimal.
Besser ist es, einen Access Point (AP) zu verwenden oder den WLAN-Router so nah wie möglich an den Geräten zu platzieren.

Ich hatte mal bei einem Bekannten exakt den gleichen Fehler ausfindig gemacht:
Im AP war ab Werk bzw. als Standard ein täglicher Neustart hinterlegt, ohne dass er das selbst aktiviert hatte.
Der AP war nach einem Firmware-Update automatisch auf diesen täglichen Neustart konfiguriert worden.

[Daniel 8]

Ich habe alles geprüft kein Neustart. Bin noch auf der Suche. Informationen folgen wenn ich näheres weiß.
Der zendure meldet sich auf jedenfall im wlan ab und erst wieder an so sah es zumindest aus, wenn er durch die Sonnenstrahlen geweckt wird.
Als wie er nach einer bestimmten Zeit in einen Tiefschlaf gehen würde. Werde dies beobachten.

[maxclaudi]

@Daniel-8
Könnte Firmwarebedingt sein oder mit dem empfindlichen WLAN des esp zu tun haben.

Meine WLAN Verbindung ist eigentlich gut genug:

Dennoch habe ich auch 1x am Tag ein reconnect vom Zendure-Gerät.

LOG:
Der 2400ACpro hat vermutlich in dieser Sekunde kurzzeitig die Verbindung zum Netzwerk verloren.
Beim sofortigen Wiederverbindungsversuch lief die alte Sitzung im Mosquitto-Broker noch, weshalb der Broker die alte Verbindung gekappt hat, um die neue Anmeldung des Geräts zuzulassen.

Ich könnte nun auch versuchen herauszufinden, ob zu dieser Uhrzeit (01:35 Uhr) eventuell ein geplanter Neustart des Geräts stattgefunden hat.

Aber weil es so kurz ist und sonst alles tadellos funktioniert, werde ich erst mal nur das LOG im Auge behalten.

[petman]

@maxclaudi sagte:

Ich überlege gerade ein MQTT-Steurungs-Script anzupassen, damit es als Ersatz für das zenSDK-Steuerungs-Script verwendet werden kann.

ja Bitte, und da gleich noch die Berechnung Energie- Tages-, Wochen-, Monats- Jahres-ertrag mit rein.

Ich weis, der Sourceanalytix kann das, ist aber immer noch BETA.

Peter

[maxclaudi]

@petman sagte:

@maxclaudi sagte:

Ich überlege gerade ein MQTT-Steurungs-Script anzupassen, damit es als Ersatz für das zenSDK-Steuerungs-Script verwendet werden kann.

ja Bitte,

Soweit fertig.
Das MQTT-JS-Steuerungsskript (mqttSteuerung_zenSDK_Angleich.js) ist fertig und liefert einige Datenpunkte (Möglichkeiten) mehr. Struktur und Datenpunkte sind ansonsten exakt identisch mit dem zenSDK-JS-Steuerungsskript.

und da gleich noch die Berechnung Energie- Tages-, Wochen-, Monats- Jahres-ertrag mit rein.

Dazu habe ich ein separates JS-Skript (zendure_energy.js) geschrieben, damit es wahlweise genutzt werden kann. Die Datenpunkte liefern die Werte direkt in ioBroker. Zusätzlich kann man aktivieren, dass die Werte in CSV-Dateien geschrieben und gesichert werden – aufgeteilt nach Tag, Monat und Jahr.
Das Skript funktioniert, sollte jedoch dauerhaft aktiv sein, da die Werte sonst unvollständig sind. Das CSV-Format bietet sich ideal für den Import in Excel, Grafana oder andere Systeme an.

Bitte melde dich mal bei mir.

[maxclaudi]

zURLtool_V20 (c) maxclaudi 2026 - Version 2.0 cdh

Neu in zURLtool V 2.0 dch
• Sprachauswahl: Deutsch und Englisch sind auswählbar und während der Laufzeit umschaltbar.

• Reset-Funktion: Geräte können zurückgesetzt werden (Hinweis: Zum vollständigen Abmelden - z.B. bei Verkauf - Gerät auch in der App entfernen!).

• WLAN-Handling: Das manuelle Setzen des WiFi-Mode entfällt. Ein automatischer Scan zeigt alle vom Zendure-Gerät erreichbaren Netze an. Bei zur config.ini abweichendem, manuell ausgewählten WLAN muss auch das Passwort in der GUI angepasst werden.

• Offline-Modus: Die Option OFFLINE = 1 in der config.ini überspringt den WLAN-Scan, ideal für Vorbereitungen oder Konfigurationen ohne aktiven Router.

• Token & User-ID: Gerätespezifischer Token wird in mqtt_creds.txt gesichert. Für die korrekte userId (bzw. consumerId) empfiehlt sich der Einsatz des Zusatztools zAppEmulationDeviceInfo

• Ein Backup mit den verwendeten Daten in der config.ini wird zusätzlich gespeichert. Beispiel: bak_config_26.10.26_14.51.35.ini

• Hinweis zu TLS / Port 8883: Das Tool ist ein reiner Konfigurator per Bluetooth und generiert keine TLS-Zertifikate oder Keys.

Beschreibung im Spoiler.

---

Spoiler

zURLtool V 2.0 dch – Lokaler MQTT-Broker für Zendure 2026

Hallo zusammen, das Update zURLtool V 2.0 dch de/gb ist nun fertig!

---

Das Programm ist in seiner Art einzigartig, neu und durch monatelanges Reverse-Engineering, Analysen und intensives Testen entstanden.
Es handelt sich um ein reines Windows-GUI-Programm, das ganz einfach per Doppelklick gestartet wird.

Es verwendet keinen Code von anderen bekannten Projekten, die teils fehlerhaften und unvollständigen Code verwenden, mit dem Konfigurationen neuer Geräte nicht möglich sind.

Technische Voraussetzungen & Basis:

Vielen Dank an Henrik Blidh für die hervorragende BT-Bibliothek.

Das Programm nutzt zur Kommunikation ausschließlich die offiziellen Windows-BT-Treiber ab Windows 10/11 und die integrierte Bluetooth-Bibliothek bleak:

==================================================

LICENSE NOTICE FOR THE UTILIZED BLUETOOTH LIBRARY
This program uses "bleak" for Bluetooth functionality.
https://github.com/hbldh/bleak
Copyright (c) 2020, Henrik Blidh
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND.

==================================================

Die Bibliothek wurde fest in das Programm eingebunden.

Weitere Bibliotheken oder Frameworks müssen auf eurem PC nicht installiert werden.

• Betriebssystem: Windows (10) 11 (64-Bit)
• Hardware: Interner Bluetooth-Chip oder ein standardmäßiger USB-Bluetooth-Stick am Rechner.
• Kompatibilität: Getestet mit Zendure-Geräten bis zur 2400er-Serie (sowohl ältere als auch neueste Generationen / Firmware-Stände).

Inhalt des Programmpakets (zURLtoolV20.zip):
Das ZIP-Archiv enthält genau drei Dateien, die zwingend im selben Ordner liegen bleiben müssen:
• zURLtool_V20.exe (Größe: ca. 15.5 MB / 15555 KB)
• config.ini (Konfigurationsdatei für eure Zugangsdaten)
• ReadMe_zURLtoolV20.txt (Ausführliche Anleitung in Deutsch & Englisch)

Was genau macht das zURLtool?
Das Tool schreibt im Zendure-Gerät die Konfiguration der Broker-URL um.

• Es wird NICHT in die Firmware eingegriffen und es wird nichts modifiziert. Die originale Firmware von Zendure bleibt zu 100 % unangetastet.

• Es werden lediglich die standardmäßigen Bluetooth-Befehle verwendet, die die Firmware von Haus aus für die App bereitstellt.

• Das Skript verhält sich für das Gerät exakt wie die originale App, greift auf die Konfigurationsvariablen im Speicher zu und überschreibt dort die Wi-Fi-Daten und den Eintrag für die Cloud-URL mit der IP eures eigenen lokalen Brokers.

Es funktioniert quasi wie eine zusätzliche Länderauswahl, bei der man sich einfach mit einem anderen Server verbindet.
Das bietet die Firmware von Haus aus an, da die Geräte sonst permanent fest an ganz bestimmte AWS-Server gebunden wären.
Zurück zur Cloud ist auch möglich. Beispiele sind in der config.ini enthalten.

Die Geräte verbinden sich und können beschrieben werden ohne hartes Reset und ohne hartes Trennen von allen Stromquellen.

Freigabe vereinfacht.
Wer schon eine Seriennummer und Freischalt-Code für zURLtool V1.0 dch hat, kann diese verwenden.
Seriennummer und Freischalt-Code bleiben gültig, eine erneute Anfrage für zURLtool V2.0 ist nicht erforderlich.

Der Freischalt-Ablauf:
Damit das Programm funktioniert und um anonyme Massen-Weiterreichungen zu unterbinden, benötigt das Programm eine Seriennummer und einen Freigabe-Code.

1. Sende mir deinen (Foren-) Namen per privater Nachricht (PN) im Forum oder per E-Mail an: ztool.maxclaudi AT gmail . com
2. Du erhältst von mir eine persönliche "Seriennummer" und den dazu passenden "Freigabe-Code"
3. Sichere dir die Seriennummer und den Freigabe-Code unbedingt in einer Textdatei als Backup! Falls du die Datei mal verlierst, hast du deine Seriennummer und deinen Freigabe-Code als Backup griffbereit.
4. Starte die 'zURLtool_GUI.exe'.

Trage beide Werte exakt so, wie du sie erhalten hast, in die dafür vorgesehenen Felder im Startfenster ein und klicke auf "Akzeptieren & Starten".
Nach einmaliger Eingabe startet zURLtool zukünftig vollautomatisch in die Hauptoberfläche.

Als Notfall hast du zusätzlich Seriennummer und Freigabecode als Backup.
Vor dem ersten Start muss bzw. kann die config.ini in einem einfachen Text-Editor mit euren echten Daten befüllt werden.
Auswählbare Beispiele und Erklärungen zu den WLAN-Modi sind direkt darin enthalten.

Wenn keine config.ini vorhanden ist oder nicht benutzt wird, müssen die Daten in die GUI eingegeben werden.

Warum ist das Programm Closed Source?
Zu oft wurden meine Skripte, Codes oder Teile daraus in der Vergangenheit verwendet und/oder modifiziert – ohne Nennung meines Namens, ohne Danksagung / Anerkennung und unter Entfernung meiner originalen Hinweise.
Entweder wurde (leicht abgeändert) einfach "übernommen" oder u. a. als eigener Erfolg ausgegeben oder kommentiert mit "ich habe einen Weg gefunden".
Das ist ungerecht.

Monatelange harte Arbeit sollte zumindest anerkannt werden.

Sollte das Programm oder der Code in irgendeiner Form gehackt zur Verfügung gestellt oder verwendet werden, dann war dies mein letzter offizieller Beitrag in Form von Code für die Community.
Das gilt auch wenn das Programm inkl. Seriennummer und Freigabe-Code mehrfach geteilt wird.

Viel Spaß mit dem zURLtool V2.0 dch!

---

---

Bitte ReadMe_zURLtoolV20.txt beachten, enthält die deutsche und englische Beschreibung.

HINWEIS FÜR BESTEHENDE NUTZER:
Wer bereits für die Version 1.0 eine Seriennummer und einen Freischalt-Code erhalten hat, kann diese Daten direkt weiterverwenden!
Sie sind auch für die Version 2.0 gültig.
Bitte in diesem Fall keine erneute Anfrage.

RECHTLICHER HINWEIS ZUR FREIGABE:
Eine Weitergabe von Seriennummer und Freigabe-Code
sowie deren Mehrfachnutzung durch verschiedene Personen ist ausdrücklich UNZULÄSSIG.

---

Please note ReadMe_zURLtoolV20.txt: contains the German and English description.

NOTE FOR EXISTING USERS:
If you have already received a serial number and activation code for version 1.0, you can reuse them directly!
They are valid for version 2.0 as well. Please do not submit a new request in this case.

LEGAL NOTICE ON ACTIVATION:
Sharing the serial number and activation code, as well as their multiple use by different individuals, is strictly PROHIBITED.

[maxclaudi]

Download zURLtoolV20.zip in 4 Teilen.
Teil 1v4:

zURLtoolV20.zip

Achtung: Falls die Datei nach dem Download einen anderen Namen als zURLtoolV20.zip hat, benenne sie bitte entsprechend um.
Es kann und soll gerne ein Virenscan erfolgen!

HINWEIS ZUM ENTPACKEN (MEHRTEILIGES ARCHIV):
Das Programmpaket ist auf 4 Teile aufgeteilt. Bitte verwende zum Entpacken
ein vollwertiges Packprogramm wie 7-Zip, WinRAR oder Bandizip. Das integrierte Windows-eigene ZIP-Programm kann mehrteilige Archive NICHT korrekt zusammensetzen und führt zu Fehlfunktionen oder Fehlermeldungen beim Entpacken!

[maxclaudi]

Download zURLtoolV20.zip in 4 Teilen.
Teil 2v4:

zURLtoolV20.z01

Achtung: Falls die Datei nach dem Download einen anderen Namen als zURLtoolV20.z01 hat, benenne sie bitte entsprechend um.
Es kann und soll gerne ein Virenscan erfolgen!

HINWEIS ZUM ENTPACKEN (MEHRTEILIGES ARCHIV):
Das Programmpaket ist auf 4 Teile aufgeteilt. Bitte verwende zum Entpacken
ein vollwertiges Packprogramm wie 7-Zip, WinRAR oder Bandizip. Das integrierte Windows-eigene ZIP-Programm kann mehrteilige Archive NICHT korrekt zusammensetzen und führt zu Fehlfunktionen oder Fehlermeldungen beim Entpacken!

[maxclaudi]

Download zURLtoolV20.zip in 4 Teilen.
Teil 3v4:

zURLtoolV20.z02

Achtung: Falls die Datei nach dem Download einen anderen Namen als zURLtoolV20.z02 hat, benenne sie bitte entsprechend um.
Es kann und soll gerne ein Virenscan erfolgen!

HINWEIS ZUM ENTPACKEN (MEHRTEILIGES ARCHIV):
Das Programmpaket ist auf 4 Teile aufgeteilt. Bitte verwende zum Entpacken
ein vollwertiges Packprogramm wie 7-Zip, WinRAR oder Bandizip. Das integrierte Windows-eigene ZIP-Programm kann mehrteilige Archive NICHT korrekt zusammensetzen und führt zu Fehlfunktionen oder Fehlermeldungen beim Entpacken!