Monatsrückblick Juli / August 2026 ist online!

[GH-Kgasse]

Hallo zusammen,
ich habe ein reproduzierbares Problem mit dem Zendure-SolarFlow-Adapter 5.1.0 und einem SolarFlow 2400 AC+.

Setup:

ioBroker Zendure-SolarFlow Adapter: 5.1.0
SolarFlow 2400 AC+
SolarFlow 800 Plus als Vergleichsgerät in derselben Adapterinstanz
Log-Level: silly
Test sowohl mit aktiviertem als auch mit deaktiviertem zenSDK

Beim SolarFlow 2400 AC+ funktioniert das Lesen der Daten problemlos. Mit aktiviertem zenSDK wird das Gerät korrekt per mDNS gefunden und die Properties werden regelmäßig erfolgreich gelesen.

Problematisch sind die Control-Datenpunkte, insbesondere:

zendure-solarflow.0.5fG27j.xd5Eq922.control.setDeviceAutomationInOutLimit

Die Objektdefinition sieht korrekt aus:

{
"type": "state",
"common": {
"type": "number",
"role": "value.power",
"read": true,
"write": true,
"unit": "W",
"def": 0
}
}

Wenn ich den Datenpunkt manuell z. B. auf +444 oder -444
setze, wird der Schreibvorgang offenbar nicht vom Adapter verarbeitet.
Im Log erscheint beim 2400 AC+ insbesondere KEIN:

[onStateChange] Control state 'setDeviceAutomationInOutLimit' changed ...

und auch KEIN:

[setDeviceAutomationInOutLimit] ...
[updateProperty] ...
[writeZenSdkProperties] ...

Das Verhalten ist identisch:

zenSDK aktiviert
zenSDK deaktiviert / Cloud MQTT

Es läuft parallel auch kein Regelscript für die Solarflow 2400 AC+, welches hierauf einen Einfluss nehmen könnte.
Beim SolarFlow 800 Plus in derselben Adapterinstanz funktioniert derselbe Datenpunkt dagegen einwandfrei.

Beispiel vom 800 Plus:

[onStateChange] Control state 'setDeviceAutomationInOutLimit' changed, new value is 29, ack = false!
[setDeviceAutomationInOutLimit] Set device Automation limit to 29!
[setDeviceAutomationInOutLimit] Using zenSDK to set input/outputlimit in combination with acMode and smartMode!
[updateProperty] Updating property acMode with value 2 ...
[writeZenSdkProperties] Successfully wrote properties ... {"acMode":2} / status: 200
[updateProperty] Updating property outputLimit with value 29 ...
[writeZenSdkProperties] Successfully wrote properties ... {"outputLimit":29} / status: 200
[updateProperty] Updating property inputLimit with value 0 ...
[writeZenSdkProperties] Successfully wrote properties ... {"inputLimit":0} / status: 200

Beim 2400 AC+ fehlt diese komplette Kette.

Zusätzlich habe ich die manuelle Steuerung über die Zendure-App untersucht:

Laden mit 400 W:

acMode = 1
setInputLimit = 400
setOutputLimit = 0
autoModel = 0 / Nothing
smartMode = false

Entladen mit 111 W:

acMode = 2
setInputLimit = 0
setOutputLimit = 111
autoModel = 0 / Nothing
smartMode = false

Die App-Steuerung funktioniert also, und die Werte werden anschließend auch korrekt im ioBroker angezeigt.

Manuelle Schreibversuche auf

setInputLimit

bzw.

setOutputLimit

werden beim 2400 AC+ ebenfalls nicht wirksam bzw. kurz darauf wieder auf 0 gesetzt.

Auffällig ist dagegen:

acMode

lässt sich über ioBroker manuell setzen und der Wert bleibt erhalten.

Zusammenfassung:

SolarFlow 800 Plus:
setDeviceAutomationInOutLimit
→ onStateChange
→ Adapter verarbeitet den Wert
→ zenSDK Write
→ funktioniert

SolarFlow 2400 AC+:
setDeviceAutomationInOutLimit
→ kein onStateChange im Log
→ kein Write
→ funktioniert weder mit zenSDK noch über Cloud MQTT

Für mich sieht es deshalb danach aus, dass der Control-State beim 2400 AC+ zwar korrekt angelegt wird, aber nicht korrekt im onStateChange bzw. im Geräte-Handler verarbeitet wird.

Falls weitere Logs oder Tests benötigt werden, kann ich diese gerne liefern.

[nograx]

@GH-Kgasse
Du setzt setDeviceAutomationInOutLimit bei dem Gerät aber nicht zufällig mit "Bestätigt" bzw. ACK=true oder?

Ich habe selbst einen 2400AC+ hier am laufen, und da funktioniert das. Also kann kein allgemeines Problem sein.

[GH-Kgasse]

@nograx. Danke
wenn ich die Werte von Hand setzt, dann mit Bestätigt.
Nachtrag: das war mein Fehler, ohne Bestätigt, geht das manuelle Schreiben. Oh Mann, mein Fehler.

im Script via:

setStateDelayed('zendure-solarflow.0.5fG27j.XXXXXXXX.control.setDeviceAutomationInOutLimit', { val: NeueLeistung, ack: false, expire: 0 }, parseInt(((0) || '').toString(), 10), false);

[nograx]

@GH-Kgasse Jo das war direkt mein Verdacht. IoBroker Adapter bestätigen den Wert wenn er korrekt verarbeitet wurde. Wenn du das vorher schon bestätigst heißt das „setz den Wert aber mach sonst bitte nichts“

[nograx]

@XBiT Kannst du wohl mal die Version v5.2.0-alpha.3 ausprobieren? In den Einstellungen "Über mDNS gefundene Geräte automatisch hinzufügen" aktivieren? Rein theoretisch sollte damit dein 4000 Mix im Adapter auftauchen und auch steuerbar sein...

[The_Stig]

Hi @nograx - kurz nachgehakt: mit meinem Hyper2000, wenn ich auf die Alpha umstelle, um "hemsEP" zu nutzen - muss ich dann in meiner Automatisierung, die jetzt aktuell auf setDeviceAutomationInOutLimit steuert, etwas ändern?

[nograx]

@The_Stig nein

[The_Stig]

top- danke!

[nograx]

Die letzte alpha geht heute noch als Beta rein. ich konnte mit @Amutep einiges voran bringen und diverse Bugs beheben. Die Mix Geräte und die Smart Meter werden nun sauber erkannt und ausgelesen.

[XBiT]

@nograx

Nach dem ersten Start der V5.2.0 wird der Mix erkannt, es kommt aber gleich in der Log im 5 sec. Takt

zendure-solarflow.0
2026-08-29 19:20:20.980	warn	Operation mode (autoModel) is not set to '0', we can't set the output limit!

ein ändern auf einen anderen Wert und wieder zurück auf "0" bringt keine andere Reaktion

[nograx]

@XBiT ist bei dir die Option "Spannungs-Überwachung nutzen (deaktiviert die Einspeisung wenn die Spannung einer Batterie in kritischen Bereich fällt)" aktiviert und die Batterie quasi leer? Könnte sein das er versucht die Einspeisung zu stoppen. Ich nehme an du steuerst den über das Cloud HEMS?

Wenn das so ist solltest du die Option nicht anhaken.

[The_Stig]

Hatte jetzt testhalber mal die 5.2.0 drauf und damit aber das komische Problem, dass da immer das AutoModel auf Nothing gesetzt wird und ich damit halt keine Steuerung mehr habe. Auch ein Downgrade auf 5.1.0 oder eine 4er Version hilft leider nicht. IRgendwelche Ideen?
So sieht das dann aus

[The_Stig]

Ok, Entwarnung. Habs gefunden - da gibt es ja einiges neu an Objekten im Adapter. Unter anderem HemsState. Der war bei mir - trotz lokaler Steuerung - auf True. Sobald ich das deaktiviere, bleibt es auch wieder im SmartMatchingMode. Puuuh.

[The_Stig]

Mist nein! HemsState wird auch wieder automatisch auf On gesetzt. Was ist denn das jetzt hier?

[nograx]

@The_Stig Geht um den Hyper oder? Wenn du da setDeviceAutomationInOutLimit zur Steuerung nutzt wird/muss HemsState auf 1 gesetzt werden da es jetzt den simulierten HEMS Befehl nutzt. Wenn du hemsStage auf 0 setzt dürfte die Steuerung nicht mehr funktionieren.

[The_Stig]

Hi @nograx danke für die schnelle Rückmeldung. Ja, hyper. Ich nutze setDeviceAutomationInOutLimit. Und das mit dem HemsState wusste ich nicht. Bei mir wird dann aber immer das AutoModel auf 0 gesetzt und damit nicht mehr gesteuert. Also keine Änderung des outputHomePower

EDIT: Also etwas ausführlicher:
HemsState steht auf on
AutoModel steht auf 0
setDeviceAutomationInOutLimit z.B. auf 500
OutputHomePower bleibt auf 0

[nograx]

autoModel muss 0 sein. Schau mal bitte ob inverterMaxLimit gesetzt ist.

[The_Stig]

Finde nur OutputLimit, das ist bei 1200. Hab kein inverterMaxLimit soweit ich das sehe.

[nograx]

control.inverseMaxPower sorry ;)

[The_Stig]

Yes, das stand auf 0. Habs jetzt mal auf 1200 gesetzt und siehe da, es geht ;-) Puuuuuuuuh. Danke dir, das rettet meinen Tag.