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

[nograx]

@Karacho Wie @murphy-0 schon geschrieben hat könnte es daran liegen das die neuen Geräte einmal dem HEMS hinzugefügt und dann wieder entfernt werden müssen damit sich das zenSDK aktiviert und eine lokale IP-Adresse im Profil hinterlegt wird. Das wurde tatsächlich in einer der neueren Firmware implemtiert.

[Karacho]

@nograx
Habe ich gemacht. Die lokale IP wird nicht "gezogen"

[Bernd1967]

Seit Adapter Version V5 habe ich beim Aufruf der Adapter Einstellungsseite hohe CPU Last und die Speicher Anzeige flackert.
Hat das noch jemand ?

Nachtrag:
Fehler gefunden, Issues angelegt. Link Github

[nograx]

@Karacho In der Version 5.0.4 habe ich einen mDNS helper eingebaut der lokal nach zenSDK Geräten sucht. Falls er einen findet und in der Cloud keine IP hat versucht er darüber zu connecten. Du könntest mal im Log nach "[mdnsHelper]" und "[connectViaMdns]" Ausschau halten ob das fehlende Gerät gefunden wird (sich also selbst anbietet).

[nograx]

@Bernd1967 In Version 5 wurden etliche Dependencies aktualisiert. Dadurch kam das wohl zustande. In 5.0.4 tritt das jetzt nicht mehr auf.

[Karacho]

@nograx
Hallo,
habe jetzt auf aktuelleste Version über GitHub update gefahren.
Lokale IP wird jetzt "gezogen"
Danke
Gruss
KAracho

[nograx]

@Karacho Über den mDNS Helper? Cool, das war nur Theorie obs klappt da ich kein passendes Beispiel zum Testen hatte Freut mich!

Ich empfehle das Update in Zukunft eher über npm zu machen. Bei Github kann durchaus auch mal unvollständiger/ungetester Code geladen werden. Das am besten bei allen Adaptern vermeiden es sei du wirst direkt augefordert das zu tun!

[XBiT]

@nograx

[mdnsHelper] Found Zendure device via mDNS: Zendure-solarFlow4000MixPro-EOE3XXXXXXXXXXX (host: Zendure-solarFlow4000MixPro-EOE3XXXXXXXXXXX.local, addresses: 192.168.1.212)

Datenpunkte / Objekte gibt es aber nicht / werden nicht angelegt -> sorry bin nicht ganz auf den laufenden was der Adapter aktuell alles an Geräten unterstützt.

[nograx]

Mix Serie ist in der Tat ein Problem. Die haben aktuell alle das selbe Problem wie der SF 800 Pro v2 anfangs, die werden von Zendure nicht in der deviceList gepublished. Dazu habe ich Zendure schon informiert aber noch keine Rückmeldung.

Noch dazu kenne ich die ProductKeys nicht (müssen von mir im Adapter eingepflegt werden).

[lesiflo]

@nograx
Hi,
ich weiß nicht ob das Problem schon bekannt ist. Bei der Berechnung der Energiewerte kommt es zu einen unschönen Verhalten. Der letzte Wert von Vortag wird um kurz nach 0 Uhr des nächsten Tages nochmal kurz ausgegeben. Das führt bei der Berechnung von Tages, Monats oder Jahreswerten zu falschen Werten.

z.B.:

[maxclaudi]

@nograx sagte:

smartMode wird bei setDeviceAutomationInOutLimit = 0 auch auf 0 gesetzt damit der Wechselrichter sich abschaltet (wenn er nichts tun soll) und somit der Standby Verbrauch sinkt. Wenn du in der App "Export überschüssiger Energie erlauben" aktivierst sollte eigentlich automatisch alles in den Bypass gehen wenn die Akkus voll sind.

Hallo zusammen,

ich möchte hier absolut keinen Streit vom Zaun brechen oder die großartige Arbeit am ioBroker.zendure-solarflow Adapter schlechtreden – im Gegenteil, Viele profitieren enorm von diesem Projekt - auch wenn ich den Adaper nicht nutze.
Allerdings treibt mich nach tiefen Code-Analysen und Tests einiges um, bei der es um den langfristigen Schutz unserer teuren Hardware geht.

Ich rate nach meinen Analysen dringend davon ab, setDeviceAutomationInOutLimit in der jetzigen Form für eine hochfrequente, sekündliche Regelung (z.B. dynamischer Nulldurchgang) zu verwenden. Das betrifft alle bisherigen Adapter-Versionen.

In der Readme des Adapters wird dieser Parameter empfohlen, da er das Gerät angeblich steuert, ohne in den Flash-Speicher zu schreiben.
Schaut man sich jedoch den Code und das reale Verhalten der Hardware an, basiert diese Annahme leider auf unbestätigten Vermutungen, die vermutlich blind aus anderen Projekten übernommen wurden.

1. Die technischen Fakten im Code

• Bei SmartMode-Geräten (ZenSdkIobDevice.js):
  Wie oben im Zitat von nograx bestätigt, erzwingt der Adapter nach einem Timeout von 4 Sekunden über smartMode: 0 das Verlassen des geschützten RAM-Modus, sobald das Limit auf 0 fällt.
  Wichtig: Das 4-Sekunden-Timeout ist wirkungslos gegen den Verschleiß. Da im Code kein clearTimeout implementiert ist, läuft der Timer bei einer dynamischen Regelung im Hintergrund unweigerlich ab.
  Er verzögert den Schreibvorgang leider nur um 4 Sekunden, verhindert ihn aber nicht.
  Sobald das Gerät den SmartMode verlässt, wird die aktuelle Konfiguration fest in den Flash-Speicher geschrieben.
  Bei einer dynamischen Regelung führt das zu permanenten, wiederholten Schreibvorgängen (1x der Wert 0 und kurz darauf die Konfiguration).
  Der Workaround, um im Standby ein paar Watt zu sparen, hebelt hier leider den eigentlichen Hardware-Schutz für die aktive Regelung aus. smartMode: 1 ist für die aktive RAM-Regelung da – ihn bei jedem Nulldurchgang per Timeout wegzukicken, ist technisch der völlig falsche Ansatz.

• Beim Hyper2000 (Hyper2000.js):
  Da der Hyper bekanntlich keinen SmartMode hat, nutzt der Code einen anderen Weg:
  Er sendet bei jeder Änderung einen kompletten Energieplan bzw. eine Automation via MQTT (autoModel: 8).
  In der Zendure-App sieht das für den User perfekt aus, da ein aktiver Automatikmodus angezeigt wird. Man wiegt sich in Sicherheit.
  Die Annahme, dass Zendure diese per MQTT reingereichten Energiepläne nur im flüchtigen RAM verarbeitet, ist jedoch riskant.
  Ich habe es mit einem Hyper-Testgerät ausführlich geprüft: Werte per Adapter geändert, das Gerät danach für >60 Sekunden komplett von JEDER Stromquelle getrennt (PV, Netzstecker und Batterie ab), damit alle Kondensatoren restlos leer sind.
  Nach dem Neustart waren die Werte weiterhin vorhanden.
  Das zeigt:
  Der Hyper speichert diese simulierten Energiepläne jedes Mal dauerhaft im Flash-Speicher ab (vermutlich per Wear-Leveling).
  Das ist auch absolut nachvollziehbar, warum Zendure das so gelöst hat: Energiepläne müssen per Definition bei einem Stromausfall etc. erhalten bleiben. Und das bedeutet zwingend: FLASH.

---

2. Warum wir Drittanbieter-Integrationen nicht blind vertrauen sollten

Viele Nutzer glauben, dass die Integrationen absolut fehlerfrei sind und direkt auf offiziellen Hersteller-Datenblättern etc. basieren, weil die Entwickler teilweise sogar als Maintainer im offiziellen Zendure-GitHub (z. B. bei der Home Assistant Integration Zendure-HA) gelistet sind.

Dass dort aber auch nur mit Wasser gekocht wird, gravierende Logikfehler unbemerkt bleiben und nicht Alles von Zendure abgesegnet wird, zeigt ein direkter Blick in das offizielle Home Assistant Repository von Zendure unter custom_components/zendure_ha/entity.py

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

---

Fazit und Empfehlung

Dieser Auszug beweist, dass selbst den gängigen Open-Source-Integrationen keine verifizierten Dokumentationen oder Spezifikationen von Zendure vorliegen. Es wird viel analysiert, probiert und am Ende gutgläubig voneinander abgeschrieben.

Nograx hat diese Logiken vermutlich einfach in JavaScript/TypeScript übersetzt und für sein persönliches Setup optimiert, ohne die fatalen Auswirkungen auf den Flash-Speicher bei anderen Nutzungsszenarien zu ahnen.
Im Moment laufen vermutlich hunderte dynamische Setups im Sekundentakt, bei denen die User denken, sie schonen ihre Hardware, während sie - im Gegenteil - den Flash-Speicher extrem belasten.

Mein dringender Rat an alle:
Nutzt setDeviceAutomationInOutLimit bitte nicht für hochfrequente Regelungen. Vergrößert eure Regelintervalle, um eure Hardware vor schleichendem Verschleiß zu schützen, bis es vom Hersteller offiziell bestätigte Fakten zu RAM-sicheren Registern gibt.

Wie ihr es stattdessen besser löst:
Verwendet stattdessen inputLimit und outputLimit mit smartMode: 1. Bei längeren Standbyphasen schaltet ihr einfach per Script oder manuell smartMode: 0, wenn es gerade nichts zu regeln gibt und euch die paar Mehr-Watt im smartMode: 1 stören (denn dieser ist ausschließlich zum aktiven Regeln im RAM gedacht).

Ich würde setDeviceAutomationInOutLimit in der jetzigen Form - von allen Adapter-Versionen bis heute - nicht nutzen.

[lesiflo]

@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

[nograx]

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

[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