Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[nograx]

@Bernd1967 wird kurzfristig gefixt

[Bernd1967]

@maxclaudi sagte:

@Bernd1967 sagte:

Allerdings kann eine Spannung auch negativ sein da dies ja vom Bezugssystem abhängt und ist damit nicht physikalisch unmöglich.Ich könnte mir z.B. vorstellen das Hersteller das machen um festzustellen ob ein Akku falsch angeschlossen wurde in einer Reihenschaltung.

Das ist Unsinn.
................

@maxclaudi
Elektronik, Elektrotechnik und Programmierung ist auch bei mir nicht nur ein Hobby.
Du hast "physikalisch Unmöglich" geschrieben und das habe ich korrigiert.
Nicht mehr und nicht weniger.

[maxclaudi]

@Bernd1967 sagte:

Du hast "physikalisch Unmöglich" geschrieben und das habe ich korrigiert.
Nicht mehr und nicht weniger.

@Bernd1967 Wer die Hardware kennt, weiß, dass man die Akkus aufgrund der mechanischen Codierung der Stecker physisch überhaupt nicht falsch herum in Reihe schalten kann.
Deine Vorstellung, das BMS würde hier eine negative Spannung messen, um einen Verpolungsfehler festzustellen, ist elektrotechnischer Unsinn.

Bei einer echten internen Zell-Umpolung (Tiefenentladung) schaltet das BMS das System zum Schutz sofort komplett ab, anstatt eine negative Spannung per MQTT zu senden.

Und gerade weil wir hier NUR von Zendure-Systemen reden und nicht von irgendeinem akademischen "Bezugssystem", ist es hier schlicht physikalisch unmöglich.
Bitte verwirre die Community nicht mit herbeigezogenen Annahmen und Wortklaubereien.
Denn hier ist das, was du dir vorstellen kannst, tatsächlich "physikalisch unmöglich".

---

@nograx sagte:

@maxclaudi sagte:
Das originale MQTT-Live-Log der Zendure-App bei aktivem HEMS (bei 40W):
Topic: iot/gDa3tb/xxxxxxx/function/invoke

{"function":"hemsEP","arguments":{"outputPower":40,"chargePower":0,"freq":0,"mode":11}}

Ich habe das mal mit meinem Hyper ausprobiert. Auf das oben genannte Paket reagiert er aber nicht. "function":"hemsEP" gilt eigentlich auch nur für die neue Generation von Geräten, beim SF2400Pro funktioniert das so. Hast du das mal lokal bei dir ausprobiert?

@nograx Ja, ich habe es an meinem Hyper 2000 getestet (productId gDa3tb mit neuer TLS-Firmware) und mein Gerät reagiert im Live-Betrieb (also nicht total isoliert) absolut fehlerfrei darauf.

Ich bin an einem Reverse Engineering mit einer völlig anderen Zielsetzung dran und versuche nicht, das Zendure-HEMS zu imitieren. Daher beschäftige ich mich auch nicht intensiv mit HEMS. Komplett lokal/isoliert kann und möchte ich das Ganze nicht weiter testen.

Was ich dir aber als unzensierten Protokoll-Fakt aus den Live-MQTT-Logs beim Ein- und Ausschalten über die App mitgeben kann: Wenn ich per originaler App das HEMS aktiviere, wird bei jedem dieser Geräte – das wurde beim Hyper 2000, 1600AC+ und 2400 AC Pro identisch aufgezeichnet – als allererstes ein Paket mit "outputPower":0,"chargePower":0 published.

Ob das zwingend nötig ist oder eine entscheidende Initialisierung darstellt, weiß ich nicht. Ich meine mich zu erinnern, dass erst danach hemsState:1 gesetzt wurde, kann mich aber auch täuschen.
Jedoch sendet das Zendure-Gerät beim Start von HEMS als direkte Reaktion mindestens zwei unterschiedliche Antworten bzw. Statusmeldungen zurück an den Broker: Einmal die direkte Funktionsbestätigung des Geräts auf invoke/reply und direkt folgend den aktualisierten Eigenschaftsbericht auf properties/report, in dem das Gerät dann hemsState:1 zusammen mit den geänderten Gerätedaten an den Broker überträgt.

Wie bereits geschrieben, verfolge ich schon sehr lange eine ganz andere Zielsetzung: Ich möchte HEMS weder verwenden noch imitieren, sondern die gesamte Zendure-MQTT-Struktur mit all ihren Topics und Parametern außerhalb von HEMS exakt interpretieren und verstehen können. Und ich denke, da bin ich inzwischen sehr weit fortgeschritten.

Zudem bin ich aktuell wieder nicht vor Ort und einfach nur dankbar, dass ich an diesem Standort wenigstens einen Hyper 2000 für den Man-in-the-Middle-Logger zur Verfügung habe, um diese realen Datenströme überhaupt sichtbar zu machen. Damit bin ich bei dem Thema nun auch wirklich raus. Einen guten Start in die Woche!

[nograx]

@maxclaudi @Bernd1967 Als erstes zu der BatVol Geschichte. Hier kann man zu 99% davon ausgehen das hier ein Copy&Paste Fehler im HA Integration Code vorliegt, der aber zu 100% unproblematisch ist und nichts mit dem ioBroker Adapter zu tun hat. Da möchte ich jetzt mal gerne einen Abschluss haben

Bzgl. der Flash-Problematik: Ich fasse mal zusammen das wir außer einem Haufen Text und Mutmaßungen hier keine weiteren belastbaren und brauchbaren Informationen haben.

Da du ja offensichtlich HEMS auf deinem Hyper jetzt gerade erst laufen hattest, wäre es hilfreich wenn du mir das vollständige MQTT Protokoll einmal zur Verfügung stellen kannst damit ich das einmal nachvollziehen kann. Ich kann mein Hyper 2000 Setup hier gerade nicht ohne viel Aufwand auf Cloud und HEMS umstellen.

[maxclaudi]

@nograx sagte:

@maxclaudi @Bernd1967 Als erstes zu der BatVol Geschichte. Hier kann man zu 99% davon ausgehen das hier ein Copy&Paste Fehler im HA Integration Code vorliegt, der aber zu 100% unproblematisch ist und nichts mit dem ioBroker Adapter zu tun hat. Da möchte ich jetzt mal gerne einen Abschluss haben

Bzgl. der Flash-Problematik: Ich fasse mal zusammen das wir außer einem Haufen Text und Mutmaßungen hier keine weiteren belastbaren und brauchbaren Informationen haben.

Da du ja offensichtlich HEMS auf deinem Hyper jetzt gerade erst laufen hattest, wäre es hilfreich wenn du mir das vollständige MQTT Protokoll einmal zur Verfügung stellen kannst damit ich das einmal nachvollziehen kann. Ich kann mein Hyper 2000 Setup hier gerade nicht ohne viel Aufwand auf Cloud und HEMS umstellen.

@nograx Meine dokumentierte Testreihe als "Haufen Text und Mutmaßungen" abzutun, aber im selben Satz nach meinen vollständigen Protokoll-Daten zu fragen, passt nicht zusammen.

Belastbar und per Hardware-Tests bewiesen sind hier drei Dinge, die jeder User bei sich zu Hause im laufenden Betrieb verifizieren kann:

1. Meine Kaltstart-Tests unter Volllast (ohne Auszuschalten) haben lückenlos belegt, dass die über deinen Adapter gesendete "deviceAutomation" (autoModel: 8) permanent im Speicher bleibt.
2. Im Code der ZenSdkIobDevice.js läuft bei jeder Null-Regelung ein unentprelltes 4-Sekunden-Timeout ab, das den smartMode: 0 und damit den Schreibvorgang unaufhaltsam erzwingt – der Timer wird bei dynamischer Regelung im Hintergrund nie gelöscht.
3. Der direkte JSON-Protokoll-Vergleich beweist schwarz auf weiß, dass der Adapter eben NICHT dieselben Befehle wie das originale HEMS nutzt.

Mit deiner Aussage bestätigst du letztlich nur, was ich im ersten Post analysiert habe: Die Behauptungen in der Readme des Adapters basieren nicht auf verifizierten Hersteller-Spezifikationen, sondern sind und waren gutgläubige Annahmen.

Da ich aktuell nicht vor Ort bin, werde ich mein unzensiertes Log-Material oder die MQTT-Struktur nicht teilen. Mein Ziel war es nie, die HEMS-Entwicklung für diesen Adapter voranzutreiben, sondern das reale Verhalten der Hardware aufzuzeigen.

Mindestens eine Bridge zur Analyse einzurichten wird für dich wohl kein Problem darstellen.

---

Edit / PS 24.08.2026 12:24h - letztes Statement

zur Praxis mit setDeviceAutomationInOutLimit:
Wer diesen Datenpunkt benutzt und wissen möchte, ob das 4-Sekunden-Szenario für das eigene Setup relevant ist, kann dies für sein spezifisches Steuerungs-Skript und seine Umgebung leicht selbst feststellen.
Ich ermuntere jeden setDeviceAutomationInOutLimit-User dazu, den Datenpunkt einfach mal für mindestens eine Woche über ein kleines Skript lückenlos in eine Textdatei (TXT) zu loggen.

Wer am Ende der Woche sieht, wie oft bei wechselndem Wetter, Wolkenfeldern oder dem Takten von Haushaltsgeräten die "0" im Log auftaucht, kann völlig selbstständig und faktenbasiert entscheiden:
Möchte ich mein Regel-Skript so anpassen, dass der Nulldurchgang abgefangen/entprellt wird, oder verzichte ich zum Schutz meiner Hardware lieber komplett auf diesen Datenpunkt?
Oder ist für mich alles gut, weil im Protokoll keine "0" auftaucht? Die Daten im eigenen Log lügen nicht.

Nachtrag zu den Kaltstart-Tests beim Hyper:
Tests mit hartem, schnellem Stromtrennen im laufenden Betrieb sind nicht geräteschonend und können eventuell Schäden an der Hardware produzieren (Nachahmung auf eigene Gefahr).
Aber ein schnelles Schreiben von Konfigurationen und ein sauberer Abschluss des Flash-Vorgangs sind in genau diesem Moment physikalisch unmöglich.

Es fanden bei mir verschiedene Testreihen statt (mit PV, Hyper und Batterie, aber auch Hyper rein im PV-Betrieb ohne Batterie).
Bei letzterem wurde unter ausreichender PV-Leistung zuerst die AC-Verbindung getrennt, dann der MQTT-Befehl gesendet und unmittelbar danach sofort die PV-Leistung gekappt.
Es bleibt im System schlicht keine Pufferenergie übrig, um in diesem Sekundenbruchteil noch einen persistenten Flash-Schreibvorgang abzuschließen.
Die Werte landen im normalen Betrieb direkt im Speicher.

---

Für mich ist das Thema hier nun endgültig beendet. Eine schöne Woche noch!

[nograx]

@maxclaudi

1. Für mich ist das kein Beweis, denn selbst bei einer harten Trennung weiß man nicht was das Gerät exakt macht. Denkbar ist immer noch sowas wie "verliere gerade jede Energiequelle" -> "schreib alles in den Flash" passiert.
2. Ja verstehe ich, passe ich gerne an. In der Praxis wird das aber vermutlich nie passieren, jedenfalls konntest du mir immer noch kein Szenario nennen wo das relevant wäre. Bei mir wird der state nur auf 0 gesetzt, wenn ich wirklich will das das Gerät nichts macht.
3. Dein Log Material zu teilen sollte doch kein Problem darstellen (eine Device ID ist schnell durch Suchen & Ersetzen ausgetauscht), geht ja nur um die Momente in denen die Befehle geschickt werden damit ich das nachvollziehen kann. Dein JSON-Protokoll-Vergleich ist unvollständig und somit auch nicht zu 100% nachzuvollziehen.

Eine Bridge einzurichten ist halt für mich doch ein Problem. Mein Shelly und auch die Hyper laufen komplett ohne Cloud. Das ist für mich aktuell zu aufwendig alles zu ändern.

Ich habe aufgrund der Thematik mich jetzt noch mal intensiv mit FireSon ausgetauscht. Von ihm kam die Aussage das bis vor ca. 6 Monaten mit einer älteren Firmware tatsächlich in den Flash geschrieben wurde, seit Firmware X (genaue Nummer wusste er gerade nicht) aber nicht mehr. Vom Zendure R&D kriege ich in Kürze noch eine Info.

[nograx]

@maxclaudi Ich habe die nötigen Infos mittlerweile von FireSon bekommen, da sie für HA ebenfalls schon versucht das haben umzusetzen. Damit ist das dann möglich die HEMS Variante der Hyper-Steuerung zu nutzen - ich werde dazu heute eine Prerelease Version des Adapters bereitstellen. Die Aussage steht aber weiterhin das die aktuelle Variante nicht in den Flash Speicher schreibt.

[Bernd1967]

Teste gerade mit Adapter v5.2.0-alpha.0 und Hyper2000
Laden funktioniert, aber entladen keine Reaktion bei mir.
Unter "mqtt.0.iot.gDa3tb.xxxxxxxx.function.invoke" wird folgendes gesendet bei Entladen mit 100W über setDeviceAutomationInOutLimit:

{"arguments":{"outputPower":100,"chargePower":0,"freq":0,"mode":9,"minSoc":100},"function":"hemsEP","messageId":56,"deviceKey":"xxxxxxxx.","timestamp":123456789}

[nograx]

@Bernd1967 Kannst du mal deinen inverterMaxLimit checken? Den hats bei mir resettet und dann ging es erst nicht mehr. Wir vermuten aktuell das zumindest der initiale Befehl einige Standard-Werte benötigt -> daher auch das minSoc 100 (was eigentlich 10% sind).

Bei mir lief es heute Nacht auf allen 4 Hypern stabil durch.

[nograx]

@bernd1967 ggf. auch mal schauen das vorher autoModel und acMode auf 0 stehen. Da bin ich mir nicht sicher ob die sich sonst in die quere kommen können.

[lesiflo]

Ich habe jetzt auch mal die v5.2.0-alpha.0 installiert. Entladen klappt, bei mir geht aber hemsState immer wieder auf 1 auch wenn ich ihn auf 0 setzte. In der App steht er auf "aus"

[nograx]

hemsState MUSS auf 1 bleiben solange du mit setDeviceAutomationInOutLimit steuern willst. In der App bleibt der Schalter tatsächlich unangetastet. hemsState wird auf 0 gesetzt sobald du das Limit auf 0 setzt.