Monatsrückblick Juli / August 2026 ist online!

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

[nograx]

@Bernd1967 Hey, konntest du jetzt noch mal prüfen ob es bei dir läuft? In der Alpha.2 habe ich noch ein paar Checks eingebaut, autoModel wird da z.B. nun 0 gesetzt falls gerade was anderes eingetragen ist.

[Bernd1967]

@nograx sagte:

@Bernd1967 Hey, konntest du jetzt noch mal prüfen ob es bei dir läuft? In der Alpha.2 habe ich noch ein paar Checks eingebaut, autoModel wird da z.B. nun 0 gesetzt falls gerade was anderes eingetragen ist.

Ja, lief Gestern auch schon mit Version Alpha.0
Ich habe einfach "inverterMaxLimit" auf 1200 gesetzt und dann fing der Hyper an einzuspeisen.
Ich wußte gar nicht das der Hyper diesen Parameter kennt :-)
Alpha.2 läuft auch.

[nograx]

Als kurze Randnotiz, Zendure wird in Kürze eine neue Firmware für den Hyper 2000 veröffentlichen die die Kommunikation von TLS (8883) wieder auf unverschlüsselt (1883) stellt.

[Amutep]

Hallo,
Ich schreib mal hier rein weil ich nicht genau weiß ob es bei github issues richtig war.

Nutze den Adapter und bekommen für für ein den 1600ac+ : [getZenSdkProperties] IP address is not defined for device 3y7p0007!
Habe die Tips von Karacho schon probiert leider keinen Erfolg

schalte ich zenSDK aus kommt die Meldung nicht.

zusätzlich bekomme ich die meldung beim starten des adapters:
Error saving device list to file: zendure-solarflow.admin is not an object of type "meta"
Cannot write file deviceList.json: zendure-solarflow.admin is not an object of type "meta"

Ich habe noch ein D0 und ein 3CT von Zendure diese Geräte tauchen nicht auf?

Danke für eure Hilfe

[nograx]

@Amutep Github Issue ist der richtige Weg, so kann es nicht verloren gehen. :-) Habe die issue schon gesehen!

Ein Log-Eintrag mit [mdnsHelper] für den SF1600 erscheint nicht?

D0 und 3CT konnte ich bisher nicht einbinden, da mir total viele Infos zum Gerät fehlen. Hast du da Log Einträge die einen Hinweis auf ProductKey/DeviceKey geben? Wüsste gerne ob die über die deviceList API "veröffentlicht" werden.

[nograx]

@Amutep Kannst du mir mal vom mDNS Helper beide Einträge für den D0 und 3CT hier posten (gerne die SN anonymisiert)

Edit: Nicht gesehen das die im Github Issue standen.

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