Monatsrückblick Juli / August 2026 ist online!

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

[Murphy 0]

@nograx
Servus,
reicht für die 5.2.0 alpha die jdkversion 17 noch.

[nograx]

@Murphy-0 Bin jetzt leicht verwirrt, was meinst du mit jdkversion? JDK = Java Development Kit aber ich vermute du meinst was anderes. npm? js-controller? node-js?

Edit um vorab zu antworten:
Node.js: >= 22
js-controller: >= 6.0.11

[Murphy 0]

Ok Danke.