UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[maxclaudi]

@daniel-8
prüfe ich jetzt noch mal ausführlich und simuliere. ca 20min

[maxclaudi]

@daniel-8
aktualisiert, bitte testen.

[Daniel 8]

@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@daniel-8
aktualisiert, bitte testen.

Also entweder bin ich zu doof oder es ist noch nicht richtig im Script.
Folgende Meldung

error	
setForeignState: Error: The state property "ack" has the wrong type "object" (should be "boolean")!

[maxclaudi]

@daniel-8
nein, bist Du nicht. Ruhig Blut. Bitte noch einmal testen: Version 16.10.2025 11:10h.
Sind nur noch Kleinigkeiten.

[Daniel 8]

@maxclaudi

immer noch das selbe

error	
setForeignState: Error: The state property "ack" has the wrong type "object" (should be "boolean")!

[maxclaudi]

@daniel-8

Update 16.10.2025 14:47h

Beschreibung / Anleitung

[Daniel 8]

@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@daniel-8

Update 16.10.2025 14:47h

Beschreibung / Anleitung

Also was ich jetzt testen konnte hat funktioniert.

[Mabbi]

@maxclaudi
Ich konnte aktuell noch nicht das letzte Release testen, bin erst gerade mit der Arbeit fertig geworden.

Habe die letzten Tage Abends noch ein bisschen an meinen scripten rumoptimiert, Steuerpausen verlängert und mit steuerbaren Prioritäten versehen.
Grundsätzlich ist die Reihenfolge Heizen(Klimas), Haus-Akku und dann EV-laden, nun kann ich aber bei Bedarf jedes der Systeme priorisieren,
wobei der Haus-Akku dann trotzdem solange lädt wie die Startbedingungen für Heizen oder EV-Laden noch nicht erreicht sind bzw sich Überschuss auch greift.

Anbei mal heute in Diagrammen:

Morgens lud der PV-Überschuss in den Akku, gegen 10 Uhr sprang die EG-Hauptklima an, gegen 11:30 Uhr die OG-Hauptklima.
Dann hat meine älteste Tochter gegen 13:30 Uhr mit einer Heißluftfriteuse+Spülmaschine+Herd Aktion alle laufenden Klimas abgewürgt (laufen ja nur bei PV-Überschuss-Einspeisung).
Danach kam heute zum ersten mal die Sonne raus, Klimas waren noch im Cool-Down-Cycle und das EV hat beschlossen zu laden(lila) bis die Sonne wieder hinter Wolken verschwand.

Später dann kamen nach einander beide Klimaanlagen im EG dazu und mit Verzögerung beide im OG, wobei es zu dem Zeitpunkt im EG schon so mollig warm war, dass die Klimas nur noch sporadisch geheizt haben. EV hat in den kurzen Sonnenphasen noch weitere 2 mal geladen.
Grundsätzlich trotz gefühltem Schlechtwetter: Haus warm, ca. 6 KWh zus. im EV und der Haus-Akku von 10% auf 83% (aktuell 4x AB3000X)) geladen im Laufe des Tages.

Insgesamt heute bis jetzt knappe 24,5 KWh aus der PV-Anlage bekommen, davon 20,85 KWh selber genutzt und seit heute morgen die Sonne aufging 1,2 KWh Netzbezug gehabt.

Fazit: Die nun längeren Steuerzeiten am Zendure machen im Stromverbrauch kaum einen statistischen bzw. finanziellen Unterschied, ich hoffe, dass dadurch der Zendure Wechselrichter evtl. etwas länger hält.

[Mabbi]

Völlig vergessen, ich habe noch eine Frage an @maxclaudi :

Mein 2. Zendure AC2400 kommt die nächsten Tage an.
Taugt Dein Script um anhand vorhandener Datenpunkte und einer abweichenden IP 2+ Geräte zu verwalten (ich werde wahrscheinlich noch einen 3. irgendwann im Frühjahr kommendes Jahr kaufen, damit ich 7.2 KW In/Out realisieren kann, und JA, ich habe 3 einzeln abgesicherte Anschlüsse direkt an jeder Phase in meinem Schaltschrank dafür)

Hier müsste der Objektbaum evtl. um eine Ebene erweitert werden ?
Und dann mit einem 2. mqtt Client sollte das doch gehen oder ?

Falls nein wäre dies ein feature-request

[maxclaudi]

@mabbi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

Fazit: Die nun längeren Steuerzeiten am Zendure machen im Stromverbrauch kaum einen statistischen bzw. finanziellen Unterschied

ich hoffe, dass dadurch der Zendure Wechselrichter evtl. etwas länger hält.

smartMode:1

---

@mabbi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

Völlig vergessen, ich habe noch eine Frage an @maxclaudi :

Mein 2. Zendure AC2400 kommt die nächsten Tage an.
Taugt Dein Script um anhand vorhandener Datenpunkte und einer abweichenden IP 2+ Geräte zu verwalten (ich werde wahrscheinlich noch einen 3. irgendwann im Frühjahr kommendes Jahr kaufen, damit ich 7.2 KW In/Out realisieren kann, und JA, ich habe 3 einzeln abgesicherte Anschlüsse direkt an jeder Phase in meinem Schaltschrank dafür)

Hier müsste der Objektbaum evtl. um eine Ebene erweitert werden ?
Und dann mit einem 2. mqtt Client sollte das doch gehen oder ?

Falls nein wäre dies ein feature-request

done. Update 16.10.2025 19:35h

Beschreibung / Anleitung sowie die Begründung, warum pro Gerät jeweils ein eigenes Script verwendet wird.

...viel Spaß

[Mabbi]

@maxclaudi

Ich dachte ich frag mit ein paar Tagen Reserve, muss selber noch all meine scripte Multigerät-tauglich machen....
und dann ..... menno bist du schnell
Danke

Ich sag Bescheid, sobald der neue Zendure AC2400 Wechselrichter angekommen ist und ich erste Testergebnisse habe.

smartMode:1 -> Bei mir immer an, nutze ja die App nicht mehr wirklich (nur HEMS und das auch nur im Notfall, wenn ich grade mal mein script zersemmelt habe und gerne bis zur nächsten script Session einen funktionierenden Akku haben möchte)

[Mabbi]

Ich habe heute auf die letzte Version upgedated.
Beide AC2400 werden sauber erkannt und haben jeder sein eigenes java-script.

So weit ich das aktuell sagen kann, laufen beide auf Smartmode 1, HEMS ist noch an und ich lese und protokolliere die Daten per mqtt. Sieht alles soweit gut aus.

Ohne eigenes Testgerät (oder derer 2) und somit quasi blind ein funktionierendes script hinzustellen finde ich respektabel und auch beeindruckend.

Danke @maxclaudi

Nachtrag:

EV ist heute den ganzen auf prio, brauche die Tage Meter (jedes Watt hilft).
Zendure-Akkus laden und entladen fleissig je nachdem wie die Sonne rauskommt, peppeln sich langsam hoch über die Zeit, heute morgen waren beide bei MinSOC.
Leider reicht es nur für eine Klima im EG zum Heizen..... ich brauche mehr PV-Module.... :man-facepalming:

[Schimi]

keine ahnu g ob ich hier richtig bin oder im "anderen Theard" besser aufgehoben
(https://forum.iobroker.net/topic/69579/test-adapter-zendure-solarflow/1926?_=1761498948616)

Habe mal selber ein, zwei Skripte zusammengeschustert, ChatGPT was erstellen lassen, bzw. dieses für den 2400AC umgebaut:
https://forum.iobroker.net/topic/80764/script-zum-laden-entladen-von-zendure-solarflow?_=1761498948619

irgendwie bin ich aber mit der Performance nicht zufrieden...
Wenn mein 2400AC über "die Cloud" im HEMS (egal ob Zenki oder CT) regelt er viel feiner und gefühlt im Sek takt (Quelle ist ein alter Shelly 3EM (dann auch über Cloud)).
Spitzen werden schnell ausgeregelt (ohne "gegenschwingung") und es schwank +-10 Watt um den 0 (Bezug/Einspeisung)

wenn ich es "selber versuche" egal ob, das JavaScript von @maxclaudi, das offizielle MQTT oder ein per DNS umgebogenes MQTT (und damit Deaktivierung der Zendure Cloud)... entweder schwingt es "extrem hin und her, reagiert irgendwie "zäh" (und kommt damit in eine gegenschwigung) oder schaltet sehr oft den acMode zwischen 1 und 2....
Besser kann ich es nicht erklären

Ich könnte es ja einfach im HEMs laufen lassen, aber hätte doch eine gerne Möglichkeit der Steuerung um z.B. die Entladung zu verhindern wenn das Auto geladen wird oder eine Beladung zu erzwingen wenn der Strompreis günstig ist...

Hat jemand irgend einen Tipp? Oder das (für mich fluffige) "Zendure Script aus der Cloud" ?

[Mabbi]

@schimi
Ich habe bei meinen Test ähnliche Erfahrungen gemacht.

VORAB: Ob und wie schnell man mit dem Zendure regelt bitte nicht hier diskutieren bzw. kommentieren, da findet jeder seinen eigenen Weg denke ich.

Ich ermittle 2x über 30 Sekunden mein Delta der Wirkleistung (aus [Wirkleistung+] minus [Wirkleistung-]) oder Netzbezug minus Einspeisung mit einem zeitlichen Versatz von 15 Sekunden s.u.

Ich regele alle 30 Sekunden pro AC2400, mit einem zeitlichen Versatz von 15 Sekunden auf den 2. AC2400.
Damit bekomme ich eine schöne gedämpfte Regelung hin fast ohne Relaisklackern, Schaltspitzen stören die Steuerung auch relativ wenig.
Ich optimiere derzeit noch daran, pulsierende Geräte wie moderne Haartrockner und Heißluftfriteuse zu erkennen...das braucht aber noch.

Sollten wir hiermit nicht eventuell in einen eigenen thread umziehen ??

[Schimi]

@mabbi ich bin da eher im 1-2sek Bereich wenn ich mir zur Kontrolle z.B. die tibber (oder Zendure) App anschaue....
Da sind die Änderungen "sofort" sichtbar. Auch der Shelly bestätigt die schnelle Regelung des HEMS...

Entweder werde ich da irgendwie "veräppelt" oder das ding (2400AC) reagiert schneller wenn er vom HEMS gesteuert wird (bessere Logik, etc?)

Klar, könne wir einen eigene Theard erstellen, vielleicht kann die Posts ja jemand dahin verschieben...

[Mabbi]

@maxclaudi

Ohne aktive Kühlung regelt der AC2400 ab plus 65°

Sensor/hyperTmp

die Ladeleistung runter, habe hier schon Werte bis zu 15% Ladeleistungs-Reduktion gesehen. Der Kühlkörper wird dann schon ziemlich heiß und die Wärme zieht an der Aussenhaut spürbar bis in den ersten Akkublock unter dem Wechselrichter runter.
Da dies langfristig für die Elektronik Temperaturen sind, die ich als nicht lebensdauerförderlich ansehe, habe ich an den gesteuerten Lüfter-Ausgangsstecker direkt am Wechselrichter einen Lüfter angeschlossen.
Nun hält der Wechselrichter grob die 40-41° maximal ein.
Das der Sensorwert wahrscheinlich nur punktuell irgendwo im Wechselrichter gemessen wird ist mir klar, aber besser irgendwie Kühlen als stumpf Abkochen denke ich.

Frage:
Besteht die Möglichkeit

electricFanState

noch mit in die mqtt Datenpunkte (Sensor) aufzunehmen ?

Dann könnte ich anhand von dem Wert und noch zu erwartender Solarleistung (Schätzung) eventuell die Ladeleistung des Akkus reduzieren, wenn der Tag noch genug Sonne bringt.
Und eine Visualisierung wäre damit auch einfacher machbar.

[Schimi]

Der augsang ist Temp geregelt und fängt ab 40°C Spannung auszugeben... Hatte im Sommer (als es so heiss war) die Möglichkeit viel zu testen...

"Einfach" 3 alte (ich meine es sind 80ger) PC Lüfter Parallel angeschlossen (Wago)... funktioniert super

[maxclaudi]

@mabbi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@maxclaudi

Ohne aktive Kühlung regelt der AC2400 ab plus 65°

Sensor/hyperTmp

die Ladeleistung runter, habe hier schon Werte bis zu 15% Ladeleistungs-Reduktion gesehen. Der Kühlkörper wird dann schon ziemlich heiß und die Wärme zieht an der Aussenhaut spürbar bis in den ersten Akkublock unter dem Wechselrichter runter.
Da dies langfristig für die Elektronik Temperaturen sind, die ich als nicht lebensdauerförderlich ansehe, habe ich an den gesteuerten Lüfter-Ausgangsstecker direkt am Wechselrichter einen Lüfter angeschlossen.
Nun hält der Wechselrichter grob die 40-41° maximal ein.
Das der Sensorwert wahrscheinlich nur punktuell irgendwo im Wechselrichter gemessen wird ist mir klar, aber besser irgendwie Kühlen als stumpf Abkochen denke ich.

Frage:
Besteht die Möglichkeit

electricFanState

noch mit in die mqtt Datenpunkte (Sensor) aufzunehmen ?

Dann könnte ich anhand von dem Wert und noch zu erwartender Solarleistung (Schätzung) eventuell die Ladeleistung des Akkus reduzieren, wenn der Tag noch genug Sonne bringt.
Und eine Visualisierung wäre damit auch einfacher machbar.

In dem mir gesendetem Log des SF2400AC ist kein Datenpunkt
electricFanState enthalten:

LOG SF2400AC :
{
  "timestamp": 17601XXXXX,
  "messageId": 4,
  "sn": "HOXXXXXXXXXXXXX",
  "version": 2,
  "product": "solarFlow2400AC",
  "properties": {
    "heatState": 0,
    "packInputPower": 351,
    "outputPackPower": 0,
    "outputHomePower": 351,
    "remainOutTime": 490,
    "packState": 2,
    "electricLevel": 38,
    "gridInputPower": 0,
    "solarInputPower": 0,
    "solarPower1": 0,
    "solarPower2": 0,
    "solarPower3": 0,
    "solarPower4": 0,
    "solarPower5": 0,
    "solarPower6": 0,
    "pass": 0,
    "reverseState": 0,
    "socStatus": 0,
    "hyperTmp": 3131,
    "gridOffPower": 0,
    "dcStatus": 1,
    "pvStatus": 0,
    "acStatus": 1,
    "dataReady": 1,
    "gridState": 1,
    "BatVolt": 4911,
    "socLimit": 0,
    "writeRsp": 0,
    "acMode": 2,
    "inputLimit": 0,
    "outputLimit": 351,
    "socSet": 1000,
    "minSoc": 100,
    "gridStandard": 0,
    "gridReverse": 2,
    "inverseMaxPower": 2400,
    "lampSwitch": 1,
    "gridOffMode": 2,
    "IOTState": 2,
    "fanSwitch": 1,
    "fanSpeed": 0,
    "bindstate": 0,
    "VoltWakeup": 0,
    "OldMode": 0,
    "OTAState": 0,
    "LCNState": 0,
    "factoryModeState": 0,
    "ts": 1760198737,
    "tsZone": 14,
    "smartMode": 1,
    "chargeMaxLimit": 2400,
    "phaseSwitch": 1,
    "packNum": 3,
    "rssi": -49,
    "is_error": 0
  },
  "packData": [
    {
      "sn": "FO4XXXXXXXXXXXXX3",
      "packType": 5,
      "socLevel": 38,
      "state": 2,
      "power": 127,
      "maxTemp": 3051,
      "totalVol": 4910,
      "batcur": 65510,
      "maxVol": 327,
      "minVol": 327,
      "softVersion": 4103,
      "heatState": 0
    },
    {
      "sn": "FO4XXXXXXXXXXXXXX",
      "packType": 5,
      "socLevel": 38,
      "state": 2,
      "power": 157,
      "maxTemp": 2991,
      "totalVol": 4920,
      "batcur": 65504,
      "maxVol": 328,
      "minVol": 328,
      "softVersion": 4103,
      "heatState": 0
    },
    {
      "sn": "FO4XXXXXXXXXXXXXX",
      "packType": 5,
      "socLevel": 38,
      "state": 2,
      "power": 176,
      "maxTemp": 3011,
      "totalVol": 4910,
      "batcur": 65500,
      "maxVol": 327,
      "minVol": 327,
      "softVersion": 4103,
      "heatState": 0
    }
  ]
}

Das sind die relevanten Werte für den Lüfter beim SF2400AC

"fanSwitch": 1,
"fanSpeed": 0,

und müssten schon automatisch angelegt worden sein unter:
0_userdata.0.zendure.HOXXXXXXXXXXXXX.solarFlow2400AC.properties

Bei anderen Modellen wie dem SF800(Pro) heißen sie leicht anders:
Fanmode und Fanspeed.

---

Diese Werte werden – sofern vom Gerät korrekt übertragen – automatisch unter properties angelegt und regelmäßig aktualisiert.
Wenn sie sich aber nicht verändern oder falsche Werte liefern, liegt das Problem in der Firmware des Geräts oder daran, dass diese Parameter dort (noch) nicht unterstützt werden.
Das kann man über ioBroker oder das Script nicht beeinflussen.

---

Bekannte Werte:

• fanSwitch / Fanmode: vermutlich 0 = aus, 1 = an
• fanSpeed / Fanspeed: evtl. Drehzahl oder Stufe (muss man selbst beobachten)

Am einfachsten:
Datenpunkte loggen und prüfen, wann und ob sich Werte ändern.
In den meisten Fällen steht 0 für "aus".

---

Zur MQTT-Frage:
Die Daten kommen nicht über MQTT, sondern über HTTP (zenSDK).
Dein Wunsch, die Werte zusätzlich in den MQTT-Datenpunkten sichtbar zu machen, ist grundsätzlich möglich – aber nur kosmetisch sinnvoll.
Man könnte sie zwar per Script zusätzlich publishen, aber das würde die klare Trennung zwischen HTTP- und MQTT-Kommunikation verwischen.
Wenn du MQTT brauchst, lieber ein kleines Zusatzscript oder Blockly verwenden, das bei Änderungen von fanSwitch oder fanSpeed einen MQTT-Topic publisht.
Dann bleibt die Struktur sauber.
Wobei ich denke, dass die 2 states auch über mqtt published werden (?).

---

Hinweis:
Die Aktualisierung dieser Lüfter-Datenpunkte scheint ohnehin nicht zuverlässig zu funktionieren.
Siehe z. B. das offizielle Issue:
"fanSwitch":1,"fanSpeed":0 not working #21
Ob das so ist und/oder gefixt wurde, weiß ich nicht.

---

Workaround:
Wenn du unabhängig von Zendure die Temperatur-bedingte Lüfter- und Leistungssteuerung realisieren willst, bietet sich ein einfacher ESP mit Relais (z. B. Tasmota) an:

• hyperTmp per Script auswerten
• ab z. B. ≥ x °C Lüfter einschalten
• ggf. Ladeleistung reduzieren
• unter x °C Lüfter wieder ausschalten / Leistung freigeben

So bist du nicht auf Zendure-Werte angewiesen.

[Schimi]

@maxclaudi sie werden über (das offizielle) MQTT nicht ausgegeben

[maxclaudi]

@schimi
Ok.
Aber unter properties über mein script muss es vorhanden sein(?).

edit/PS: ich würde dennoch das über ein script mit Tasmota+Relais realisieren oder so wie Du über den Ausgang für den Lüfter.
Bei mir laufen die Lüfter im Sommer astronomisch mit Zeitversatz auf volle Leistung bis zum Sonnenuntergang.
Im Winter gar nicht, außer Temp ist zu hoch.
Temp kann man vom Datenpunkt nehmen und selbst eine Hysterese zum ein-/ausschalten bestimmen.
Regeln der Drehzahl ist für mich nicht wichtig. Volle Leistung. Lieber zu kühl als zu warm.