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

[maxclaudi]

@nograx Wenn du fertig editiert hast, setz bitte kurz ein Codewort wie „ENDE“ darunter, dann antworte ich dir auch gerne sachlich auf deine Fragen. ;-)

[maxclaudi]

@lesiflo sagte:

@maxclaudi: Was sind denn deine Empfehlungen für den Hyper? Mit setInputLimit/setOutputLimit und Umschalten acMode 0, 1, 2 ?
Aktuell verwende ich setDeviceAutomationInOutLimit mit 5 Sekunden Regelung

Hallo @lesiflo,

da der Hyper bekanntlich keinen smartMode besitzt, müssen wir die Logik etwas anders betrachten. Meine Devise lautet hier generell: Änderungen so oft wie nötig, aber so wenig wie möglich.

Hier sind meine persönlichen Erfahrungswerte und wie ich das handhabe – dies ist ausdrücklich kein unumstößlicher „heiliger Gral“, sondern eine technische Empfehlung auf Basis meiner Tests:

1. Regelung über Limits (inputLimit / outputLimit):
Ich gehe stark davon aus, dass der Hyper alles mittels Wear-Leveling direkt in den Flash speichert. Wenn man es mit den Speichervorgängen nicht übertreibt, fängt ein gutes Wear-Leveling das auch ab. Eine Regelung alle 5 bis 10 Sekunden, bei der nur das inputLimit oder nur das outputLimit angepasst wird, sehe ich daher als relativ unkritisch an.

2. Der Umgang mit dem acMode (Vorsicht bei schnellen Wechseln!):
Ein Wechsel des acMode (also das Umschalten zwischen Laden und Entladen) ist eine ganz andere Hausnummer als das reine Ändern eines Watt-Limits. Hierbei wird im Gerät die Umschaltelektronik (MOSFETs, Relais oder beides) aktiv beansprucht. Ich würde den acMode niemals im Sekundenbereich hin und her schalten, sondern hier eher in Minuten-Intervallen denken. Im Live-Betrieb nutze ich eigentlich nur acMode: 1 (AC-Laden) und acMode: 2 (AC-Entladen).

3. Warum acMode: 0 nicht nötig ist:
Den Zustand acMode: 0 brauchst du im Grunde überhaupt nicht anzufassen. Er ist weder dokumentiert, noch sendet die offizielle App oder die Cloud diesen Modus - zumindest bei mir die letzten 2 Tage - nicht.
Das System regelt sich über die Limits hervorragend im Standby: Steht acMode: 1 und das inputLimit auf 0, ist das quasi der Standby-Modus für die Batterie (es sei denn, es liegt PV-Leistung an). Steht acMode: 2 (AC-Entladen) und du setzt das outputLimit auf 0, wird schlicht nichts ins Hausnetz abgegeben.
Das Energiemanagement des Hyper arbeitet dabei autark.

Anstatt mit setDeviceAutomationInOutLimit im 5-Sekunden-Takt die Energieplan-MQTT-Runden zu drehen, würde ich dir beim Hyper empfehlen, den acMode (1 oder 2) je nach Grundbedürfnis (Laden/Entladen) stabil vorzugeben und im 5-10 Sekunden-Raster ausschließlich die Datenpunkte für inputLimit oder outputLimit anzupassen.

[nograx]

@maxclaudi ich denke immer noch das du damit genau das Gegenteil bewirkst. inputLimit / outputLimit hat den gleichen Effekt als wenn du den Regler in der App bedienst, da würde ich eher Flash Probleme erwarten. DeviceAutomationInOutLimit sendet die selben Befehle ans Gerät die auch das HEMS von Zendure verwendet. Dann hätte der Hyper die gleiche Flash Problematik wenn das HEMS von Zendure verwendet wird.

[maxclaudi]

@nograx sagte:

@maxclaudi

1. Das hat schon mal das gravierende Problem das der Hyper keinen SmartMode kennt, zumindest meine beiden Modelle nicht. Die o.g. Methode kann ich da nicht anwenden.

2. Wird bei den zenSDK Geräten smartMode auf 0 gesetzt wenn das setDeviceAutomationInOutLimit auf 0 ist. Das passiert ja nur wenn man gerade wirklich will das das Gerät nichts tut, ansonsten hat man da ja immer einen anderen Wert. Wenn bei mir setDeviceAutomationInOutLimit = 0 ist, dann ist das immer für längere Zeit (z.B. wenn Akku leer oder eine Niedrigpreisphase ist und ich nichts einspeisen will).

Wie oft steht setDeviceAutomationInOutLimit denn bei dir wirklich auf 0 und springt dann wieder auf einen anderen Wert? Kannst du mir dein Szenario genauer erläutern?

Mir jetzt zu unterstellen das ich hier einfach irgendwas vom HA Projekt in JavaScript/TypeScript übersetze finde ich ziemlich frech. Die Art und Weise deines Posts finde ich ebenfalls fragwürdig, da ich hier keine Lösung sehe. Bei der zenSDK setDeviceAutomationInOutLimit Regelung möchte ich das Szenario sehen wo das relevant ist. Dann kann ich gerne schauen ob ich eine gute Lösung finde.

Der Teil mit BatVol hat hier rein gar nichts zu suchen, denn da geht es um das HA Projekt, was mit dem ioB Adapter nichts zu tun hat und den Teil findest du auch nicht im Code vom Adapter! Wenn dich das stört mach bitte ein issue in der HA Integration auf.

Btw.: Die zenSDK Geräte ziehen mit aktivierten Wechselrichter ca. 30W. Das sind 0,7kWH pro Tag was ich gerade im Winter heftig finde.

@nograx,

es lag und liegt absolut nicht in meiner Absicht, dich persönlich anzugreifen oder deine Arbeit am ioBroker-Adapter herabzuwürdigen. Es geht mir hier rein um den technischen Austausch auf Code- und Hardware-Ebene.

Dass du meine fundierte Code-Kritik allerdings als „frech“ bezeichnest, verwundert mich doch sehr, wenn wir einen Blick auf die Chronologie und deine eigenen Aussagen hier im Thread werfen:

1. Warum das Home Assistant Projekt hier als Referenz angeführt wurde:
Du schreibst in deinem aktuellen Post, dass Home Assistant hier rein gar nichts zu suchen hat.

Blättern wir kurz zurück zu Beitrag #1813. Als wir damals die systemischen MQTT-Konflikte analysiert haben, war deine wortwörtliche Begründung für die Struktur deines Adapters:
„autoModel: 8 wird auch bei der HA Integration immer mit geschickt. Da das Zendure abgenickt hat (die Integration offiziell ist) muss ich davon ausgehen das das so OK ist.“

Zudem hast du in Beitrag #1808 offen geschrieben: „Tatsächlich habe ich hier vor einigen Tagen noch mal die Methoden der HA Integration übernommen Werde da gleich mal ne Beta raus basteln.“ oder

@nograx sagte:
Da ich mit der 2.0.3 jetzt beim Hyper 1:1 das von der HA Integration übernommen habe würde ich @lesiflo mal bitten das mit der Version noch mal auszuprobieren.

ok übernommen ist kein abschreiben?

Wenn du dich also selbst historisch exakt auf diese Drittanbieter-Integration als deine Referenz berufst und Methoden übernimmst, um deine Code-Entscheidungen zu begründen, dann ist es für mich und alle Mitleser auch völlig legitim aufzuzeigen, dass man Drittanbieter-Code bezüglich des realen Laufzeitverhaltens niemals blind vertrauen darf. Wer Code übernimmt, übernimmt eben auch unbewusst eventuelle Fehlannahmen des ursprünglichen Autors, weil das tiefere Hintergrundwissen der herstellereigenen Firmware-Architektur fehlt.

2. Warum die Logik bei JEDEM Nulldurchgang ein unentprelltes Loch hat:
Wie genau Zendure das originale HEMS auf Protokollebene taktet, habe ich nicht analysiert und werde es daher auch nicht beurteilen. Wir brauchen hier aber auch gar kein hypothetisches Haushalts-Szenario zusammenzuschustern oder über getaktete Verbraucher zu spekulieren. Die Relevanz ergibt sich einzig und allein aus der Logik des Adapter-Quellcodes bei einem Nulldurchgang.

Sobald ein ioBroker-Regelskript (egal aus welchem Grund) auch nur ein einziges Mal den völlig legitimen Wert 0 an setDeviceAutomationInOutLimit übergibt, passiert im Code Folgendes:

• Bei SmartMode-Geräten (ZenSdkIobDevice.js):
  Der 4-Sekunden-Timer für smartMode: 0 wird gestartet. Springt die Regelung im nächsten Intervall (z.B. nach 2 Sekunden) aufgrund geänderter Lasten direkt wieder auf einen aktiven Wert ungleich Null (z.B. 400W), läuft das System regulär weiter. Das Problem: Da im gesamten Adapter-Code kein clearTimeout existiert, läuft der Standby-Timer im Hintergrund unaufhaltsam weiter! Genau 4 Sekunden nach dem ersten Nulldurchgang schlägt das Timeout zu und sendet dem Gerät das smartMode: 0 hinterher – und zwar mitten in der Phase, in der das Skript schon längst wieder im aktiven Regelbetrieb ist. Das Gerät wird im laufenden Betrieb unvermittelt aus dem RAM-Modus gerissen, was jedes Mal einen Flash-Schreibvorgang erzwingt.

  Dass smartMode: 0 den Flash belastet, steht im Übrigen als offizielle Warnung von dir selbst in der Sf2400Ac.js Zeile 42: „AC mode was switched and smartMode is false - changes will be written to flash memory. In the worst case, the device may break...“ Ein unentprellter Timer führt diesen gefährlichen Zustand bei schnellen Regelungen im Hintergrund permanent aus.

• Beim Hyper2000 (Hyper2000.js):
  Hier wird bei limit == 0 zwar kein Timer gestartet, aber es wird starr bei jeder Änderung das Energieprogramm (autoModel: 8) mitsamt dem neuen Watt-Wert übermittelt. Dass diese Methode nicht in den Flash schreibt, ist durch nichts belegt. Mein Praxisbeweis dazu an der realen Hardware ist eindeutig: Ich habe Werte über diesen Datenpunkt geändert und den Hyper danach für >60 Sekunden komplett von ALLER Stromzufuhr getrennt (PV-Module ab, Batterien ab, Netzstecker raus), damit alle Kondensatoren restlos leer sind. Nach dem Neustart waren die geänderten Werte weiterhin vorhanden. Die simulierten Energieprogramme landen also ebenfalls dauerhaft im Flash-Speicher.

Das 4-Sekunden-Timeout ist in dieser Form gegen den Flash-Verschleiß schlicht wirkungslos, da es im Hintergrund nicht abgebrochen wird, sobald sich die Bedingungen im ioBroker ändern. Es verzögert den Moduswechsel lediglich starr, anstatt ihn sauber zu entprellen.

Konstruktiver Vorschlag zur Behebung:
Auch wenn ich persönlich aufgrund des Risikos von dieser Funktion im Sekundentakt abrate – du könntest das Problem für die dynamischen Regler im Adapter-Code vermutlich über eine einfache Entprellung mittels clearTimeout abfangen.

Sobald ein Wert ungleich 0 reinkommt, müsste ein eventuell laufender Standby-Timer im Code einfach abgebrochen werden, damit er nicht mitten in die darauffolgende Regelphase hineingrätscht:

// Pseudocode zur Veranschaulichung im Adapter:
if (limit !== 0) {
    if (this.standbyTimeout) {
        clearTimeout(this.standbyTimeout);
        this.standbyTimeout = null;
    }
    // Regulärer aktiver Regelbetrieb...
} else {
    if (!this.standbyTimeout) {
        this.standbyTimeout = setTimeout(async () => {
            // Erst nach X Minuten echtem, dauerhaftem Stillstand in den Standby wechseln
        }, 300000); // z.B. 5 Minuten statt 4 Sekunden
    }
}

Wenn du das Standby-Timeout von superkurzen 4 Sekunden auf beispielsweise 5 oder 10 Minuten durchgehenden Stillstand erhöhst und mit einem clearTimeout absicherst, würdest du evtl. beide Welten vereinen:

1. Die dynamischen Regler bleiben bei kurzen Nulldurchgängen absolut sicher und stabil im RAM-Betrieb.
2. Deine eigenen Geräte schalten sich bei echter Inaktivität (z.B. nachts über Stunden) nach einigen Minuten trotzdem sauber in den stromsparenden Standby.

Mir ging es hier rein um den technischen Erfahrungsaustausch auf Code-Ebene, um die Hardware der User im ioBroker-Umfeld so sicher wie möglich zu betreiben. Schönen Übergang ins Wochenende!

PS zu: "Die Art und Weise deines Posts finde ich ebenfalls fragwürdig, da ich hier keine Lösung sehe."

Das finde ich ehrlich gesagt eher fragwürdig. Ich mache mir hier die Mühe, den Quellcode tiefgehend zu analysieren, führe reale Hardwaretests durch und warne die Community vor nachvollziehbaren Risiken. Dass vom Hinweisgeber nun erwartet wird, nicht nur den Fehler lückenlos zu belegen, sondern auch direkt die fertige Software-Architektur als Lösung mitzuliefern, verdreht die Rollen ein wenig.

Anstatt sachliche Kritik als „frech“ abzutun, wäre es für uns alle im Forum viel hilfreicher, wenn du die Belege für die Behauptung in deiner Readme vorlegst. Dass diese Steuerung komplett „Flash-frei“ arbeitet, basiert bisher rein auf unbewiesenen Annahmen – und reine Vermutungen als unumstößliche Fakten zu verkaufen, entspricht nicht meiner Arbeitsweise.

[nograx]

@maxclaudi Ich streite nicht ab das man sich auch mal anschaut wie andere gewisse Sachen lösen, deine Sätze ("in JS/TS übersetzt...") haben bei mir gewisse Triggerknöpfe gedrückt die bei mir gerade Puls auslöst. Ich sage nur "KI kann das schneller und besser"... da hätte ich mich besser im Griff haben müssen. Wie viele andere Adapter Entwickler habe ich hier schon ewig viel Zeit und Arbeit reingesteckt ...

Wie bereits beschrieben gibt es für den Hyper keine Lösung, der Adapter und auch die HA Integration macht exakt das selbe was Zendure mit dem Cloud HEMS macht. Wenn das also in den Flash schreibt macht das HEMS das ebenfalls - entweder Zendure hat hier gewisse Sicherheitsmechanismen eingebaut oder hat das einfach nicht aufm Schirm. Hier einfach zu sagen man sollte inputLimit/outputLimit nutzen halte ich jedenfalls für falsch. Ich kann hier aber noch mal meinen Zendure Kontakt ansprechen.

Über den Timeout hätten wir gerne diskutieren können, vll baue ich das auch ein. Trotzdem sehe ich kein Szenario wo man sehr häufig das setDeviceAutomationInOutLimit auf 0 und dann nach kurzer Zeit wieder auf einen beliebigen anderen Wert setzt. Vll kannst du mich da ja noch aufklären.

Muss jetzt doch noch mal editieren:

Zitat: "wenn du die Belege für die Behauptung in deiner Readme vorlegst." Belege für deine Behauptungen kannst du aber auch nicht vorlegen. Vll wurde der Wert bei dir auch nur in den Flash geschrieben weil du das Gerät ausgeschaltet hast...!?

[nograx]

Noch zum Hyper 2000: Der Modus der gesetzt wird ist kein Energieplan, sondern dazu wird der "Smart-Modus" genutzt. Steht dann auch in der App ganz oben am Gerät wenn die Daten in die Cloud geliefert werden.

[Bernd1967]

@maxclaudi sagte:
...
Dort findet sich für die Auslesung der Batteriespannung (BatVolt) folgendes mathematisches Konstrukt:

"BatVolt": (
    "template",
    "{{ value / 100 if (value | int) < 32768 else (value | bitwise_xor(0x8000 | int) - 0x8000 | int) / 100 }}",
    "V",
    "voltage",
),

Diese Formel ist mathematisch und logisch leider völlig fehlerhaft:

1. Zweierkomplement-Verwechslung: Die Entwickler wollten hier offenbar einen vorzeichenbehafteten 16-Bit-Integer verarbeiten. Wenn der Wert über 32767 steigt, wird er als negativ interpretiert. Das macht bei Strömen (A) Sinn, die rein- oder rausfließen.
2. Physikalisch unmöglich: Eine Batteriespannung (BatVolt) kann niemals negativ sein. Die Abfrage if < 32768 ergibt bei einer reinen Spannungsauslesung keinen Sinn.
3. Mathematischer Fehler: Selbst wenn man ein Zweierkomplement berechnen wollte, zieht die Operation im else-Zweig durch das bitwise_xor(0x8000) und das anschließende Subtrahieren von 0x8000 den Wert quasi doppelt ab. Das Ergebnis wäre eine völlig falsche, tief negative Spannung statt der korrekten Zweierkomplement-Formel (die schlicht value - 65536 lauten müsste).

Zu 2:
Ich gebe Dir recht das Akku Spannungen immer positiv angegeben werden.
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.Vielleicht weiß Fireson von HA da mehr und hat das deswegen mit aufgenommen.Hast Du Ihn mal gefragt ?

Zu 3:
Dazu habe ich mal die KI claude befragt weil ich es auch nicht genau wußte.
Die meinte in kurzform folgendes.

Zitat:
Kurz gesagt: Die Kritik ist mathematisch nicht korrekt – der Ausdruck rechnet trotz des ungewöhnlichen Aufbaus exakt das Richtige. Der Grund liegt in der Operator-Präzedenz von Jinja2, die hier leicht zu übersehen ist.

Wie Jinja das tatsächlich parst

In Jinja binden Filter (|) stärker als arithmetische Operatoren (+, -, *, /). Das heißt, der Ausdruck

value | bitwise_xor(0x8000 | int) - 0x8000 | int

wird nicht als "wende int auf das gesamte Ergebnis der Subtraktion an" gelesen, sondern so geklammert:

( value | bitwise_xor(0x8000|int) ) - ( 0x8000 | int )

Der zweite | int-Filter hängt sich also nur an die Konstante 0x8000 (also ein reiner No-Op), nicht an das gesamte Zwischenergebnis. Es gibt also gar keine "doppelte" Anwendung von irgendetwas auf den kompletten Ausdruck.

Zitat: Ende

[Bernd1967]

@nograx
Ich hab die Adapterversion 5.1.0.
solarflow 800Pro2 ist über zenSDK verbunden.
Mir viel auf das bestimmte Werte in packData nicht aktualisiert werden z.B. batcur oder power.
Ein Fehler sind auf jeden Fall 0-Werte, durch z.B. "if (x.batcur)" werden diese gefiltert.
Kannst Du das umändern das auch 0-Werte gespeichert werden?

Code Ausschnitt "ZenSdkIobDevice.js":

if (x.batcur) {
            await ((_b = this.adapter) == null ? void 0 : _b.extendObject(`${key}.batcur`, {
              type: "state",
              common: {
                name: "batcur",
                type: "number",
                desc: "batcur",
                role: "value",
                read: true,
                write: false,
                unit: "A"

[maxclaudi]

@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.

dazu verweise ich nochmals auf meinen POST
Hatte nicht mehr daran gedacht und dieses 2te mal die Syntax fehlinterpretiert. Es bleibt dabei:

Elektrotechnik, Elektronik und Programmierung sind nicht nur ein Hobby von mir.
Lass uns das mal ganz nüchtern physikalisch und softwareseitig betrachten:

Ein Akku in diesem proprietären, verpolungssicheren Zendure-Stecksystem kann niemals eine negative Spannung erzeugen oder übertragen!
Selbst wenn man Akkus im Werk intern in Reihe schaltet – das BMS (Battery Management System) misst die Einzelspannungen der Zellen und die Gesamtspannung des Packs.
Wenn ein Pack physikalisch falsch herum auf die Platine gelötet würde, läge die Gesamtspannung bei 0V oder das System würde durch die Schutzdioden kurzschließen und/oder, rauchen und abschalten.
Es wird von der Firmware niemals eine "gesunde, aber negative Arbeitsspannung" über MQTT an die Cloud übertragen (können).

Das bedeutet glasklar:
Die von deiner KI analysierte Formel (Zweierkomplement) ist perfekt und mathematisch absolut korrekt für Ströme (Ampere) – dort macht sie Sinn, da Strom rein- oder rausfließen kann (Laden/Entladen).

Die Maintainer von Zendure-HA haben diese Formel mit sehr hoher Wahrscheinlichkeit per Copy-Paste einfach stumpf kopiert – und für (BatVolt) angeglichen.
Und weil die Spannung im Normalbetrieb (42V bis 58V) als Rohwert immer im Bereich von 4200 bis 5800 liegt (also weit unter der Grenze von 32768), wird der else-Zweig bei der Spannung in der Praxis schlicht niemals betreten.

Der Fehler fällt beim Testen einfach nicht auf, weil der Code bei Spannungen immer im if-Zweig bleibt. Es ist m. M. n. eine klassische Copy-Paste-Altlast.

[maxclaudi]

@nograx sagte:

@maxclaudi ich denke immer noch das du damit genau das Gegenteil bewirkst. inputLimit / outputLimit hat den gleichen Effekt als wenn du den Regler in der App bedienst, da würde ich eher Flash Probleme erwarten. DeviceAutomationInOutLimit sendet die selben Befehle ans Gerät die auch das HEMS von Zendure verwendet. Dann hätte der Hyper die gleiche Flash Problematik wenn das HEMS von Zendure verwendet wird.

@nograx Die Behauptung, dein Adapter mache exakt dasselbe wie das herstellereigene Zendure-HEMS, ist durch einen direkten Blick in deinen Quellcode (Hyper2000.ts) und den realen MQTT-Datenstrom der originalen Zendure-App widerlegt.

Schauen wir uns die unzensierten JSON-Protokolle an:

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}}

Dein Adapter-Code (Hyper2000.ts ab Zeile 49 bei 40W):
Topic: iot/gDa3tb/xxxxxxx/function/invoke

{"function":"deviceAutomation","arguments":[{"autoModelProgram":2,"autoModelValue":{"chargingType":0,"chargingPower":0,"freq":0,"outPower":40},"msgType":1,"autoModel":8}]}

Fakt ist: Zendure schickt hier für die Regelung ein völlig anderes Paket mit einem anderen Funktionsaufruf ("hemsEP" mit mode: 11) als dein Adapter, der starr die "deviceAutomation" (autoModel: 8) übermittelt.

Ob der Hyper nun bei der originalen HEMS-Funktion im Hintergrund ebenfalls in den Flash-Speicher schreibt oder nicht, kann keiner von uns ohne Einblick in den Firmware-Quellcode beweisen – das bleibt Spekulation.

Fakt ist aber durch meine Tests: Die über deinen Adapter gesendete "deviceAutomation" (autoModel: 8) simuliert im Gerät einen permanenten Plan, und dieser Zustand bleibt nachweislich auch nach einem kompletten, minutenlangen Netzentzug im Gerät erhalten.

Dein Adapter nutzt bei der Regelung schlicht nicht denselben Weg wie das herstellereigene HEMS. Wie oft und in welchem Intervall man diese Datenpunkte nun ansteuert und welches Risiko man seiner Hardware damit zumutet, bleibt am Ende jedem User selbst überlassen. Für mich ist das Thema damit nun auch fachlich komplett durch.

Schönen Abend noch!

edit/PS Quelle Adaper Hyper2000.ts
und deviceID entfernt.

[nograx]

@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]

@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.