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

[Karacho]

Hallo,
ich habe 3x Zendure SolarFlow 2400AC im System. Einer davon ist defekt und ausgetauscht worden.
Habe ihn in der Zendure App den alten rausgeschmissen und den neuen eingebunden. Funktioniert auch ganz normal.
Nach Neustart Zendure Adapter habe ich den alten aus den Objekten rausgeschmissen und der neue wird erkannt mit SN usw.
Steht aber bei Wifi auf disconnectes.
Einbindung über Cloud API
Aber er liefert keine Daten....

[getZenSdkProperties] IP address is not defined for device pCQKRq19!

Was mache ich falsch?
Danke.
Gruss
Karacho

[Murphy 0]

@karacho
Hattest du für den Neuen in der Zendure App 1x kurz das Hems aktiviert.
Irgendwas habe ich mal gelesen dass man das machen muss.
Da ich nen Hyper habe da nicht so drauf acht gegeben.

[Karacho]

Läuft jetzt. STandardmässig war in der Instanz Eisntellungen "zenSDK verwenden" deaktivieren.
Keine Ahnugn warum neu angemeldete nicht funktionieren und "alte" funktionieren.

[Karacho]

Hallo,

ich muss das Thema doch noch mal aufmachen:

ich habe 3x Zendure SolarFlow 2400AC im System. Einer davon ist defekt und ausgetauscht worden.

Habe ihn in der Zendure App den alten rausgeschmissen und den neuen eingebunden. Funktioniert auch ganz normal.

Nach Neustart iobroker Zendure Adapter habe ich den alten aus den Objekten rausgeschmissen und der neue wird erkannt mit SN usw.

Alle drei Geräte stehen auf connection mode "Cloud MQTT".
Daten kommen auch ganz normal aus der Cloud an.

Aber:
Der neue Kopf zieht sich nicht die lokale IP 192.168.178.xx. Die anderen beiden schon.
Wenn ich dann auf ZenSDK umschalte kommt natürlich die Fehlermeldung

[getZenSdkProperties] IP address is not defined for device pCQKRq19!

Bei den zwei alte steht dann bei connection mor "zenSDK" beim neuen bleibt es bei "Cloud MQTT"

Was mache ich falsch?
Danke.
Gruss
Karacho

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