Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro)

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.

maxclaudi

ohne viel zu basteln ist das ganze schnell und günstig umgesetzt.

Beispiel:

Smarte Steckdose Shelly oder Tasmota geflasht
gibt's auch fertig z. B. Tasmota Steckdose NOUS A1T
Netzteil DC 12V oder 5V je nach Lüfter >= 2A
damit man für Lüftererweiterungen gerüstet ist.
Netzteil sollte dauerhaft auch nicht mit >= 80% der maximal Leistung belastet werden.
z. B. 12V DC Netzteil mit 3A
oder 5V DC 3A
beide Netzteile haben gleich einen Schraubklemmen-Adapter dabei um nur noch (+) und GND (-) mit den Lüftern zu verbinden.
passende Lüfter dazu je nachdem für 5V oder 12V.
z.B. 12V DC: Wathai 120mm x 25mm 12V
oder 5V DC: Wathai 2 in 1 USB Lüfter 120 mm Doppelter 5V PC Ventilator

Steckdose über webui mqtt einrichten. Fertig.
Danach ein Blockly oder script.
Das ganze dauert nicht mal 30min :-)

Schimi

@maxclaudi ja... über dein Skript werden die werte angezeigt

Daniel 8

@maxclaudi

Bin echt froh das du das Script entwickelt hast. Mein solarflow800Pro schaltet öfter mal am Tag auf smartMode 0 um. Ich habe noch nicht herausgefunden warum und was das auslöst. Aber dank Überwachung schaltet er ja wieder auf 1.

Habe ihn vor ein paar Tagen den Zugang zum Internet gesperrt. Eventuell zickt er Da rum wenn er nicht mehr mit der cloud verbunden ist.

maxclaudi

@daniel-8
Das wird vermutlich nur abhängig sein, welche(n) Mode du benutzt.
Leider kann ich das nicht analysieren, weißt ja - kein neues Gerät vorhanden.

Mabbi

@schimi

... bin vor einiger Zeit schon den 1-click-way gegangen, da waren die Teile gerade mal stark reduziert:

Daniel 8

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

@daniel-8
Das wird vermutlich nur abhängig sein, welche(n) Mode du benutzt.
Leider kann ich das nicht analysieren, weißt ja - kein neues Gerät vorhanden.

Was meinst du mit welchen Mode? Ich wüsste nicht wo ich einen Mode verstellen kann.

maxclaudi

@daniel-8
Das sind die verschiedenen Energy Plan (Energiepläne), die es in der App zur Auswahl gibt, wie

Smart CT Mode
Scheduled/Timer Mode
Smart Matching Mode
usw.

Daniel 8

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

@daniel-8
Das sind die verschiedenen Energy Plan (Energiepläne), die es in der App zur Auswahl gibt, wie

Smart CT Mode

Scheduled/Timer Mode

Smart Matching Mode
usw.

Die App ist ja bei mir ohne Funktion, da ich dem solarflow den InternetZugang über die fritzbox gesperrt habe. Und die Pläne gibt es ja nur in hems und das ist schon lange aus. Mache alles über mqtt

maxclaudi

@daniel-8
es könnte dennoch damit zusammenhängen.
An Deiner Stelle würde ich den Internetzugang noch mal frei geben.
Die App nutzen und sicherstellen, dass wirklich kein Energieplan in der App zuletzt aktiv war und auch nicht ist.
Ich kann mir nicht vorstellen, dass es nur HEMS gibt?
Es gibt doch CT-Mode oder ähnlich, auch ohne aktives HEMS?
Oder so eine Einstellung mit fester Energieabgabe/Zeitplan usw.
Das würde ich noch einmal prüfen und mich überzeugen, dass wirklich alles deaktiviert ist.

Edit/PS: ich bin komplett offline, ohne App.
Kann bei mir dennoch CT-Modus und andere Modi nutzen, sofern sie keine Cloud-Daten erfordern funktioiert das auch.
Nutze ich nicht.
Es war aber so (ist auch nachvollziehbar), dass die letzten Einstellungen in der Firmware gespeichert sind und genutz werden (wollen).

Daniel 8

@maxclaudi

Also ich habe jetzt in Hems den grundlastmodus genommen und alle Zeitpläne gelöscht. Bei den normalen akku Einstellungen gibt es keine Zeitpläne. Was mir auch aufgefallen ist, das in sporadischen Abständen der mqtt von 1 auf 0.geht mit der http Abfrage. Weiß nicht warum er da die Verbindung verliert

Sowas wie ct oder so gibt es bei den neuen Geräten ohne hems nicht.

maxclaudi

@daniel-8
Tipp: Du könntest dich an den Support wenden und darauf hinweisen, dass du die zenSDK nutzt und wie empfohlen smartMode:1 gesetzt hast, damit die Parameter ins RAM statt in den Flash geschrieben werden.
Erkläre, dass smartMode:1 immer wieder von allein (Intervall ca.) wieder auf smartMode:0 wechselt.
Frage „warum?“ und bitte um eine Lösung.
Kannst darauf hinweisen, dass Du mehrere Leute mit einem SF2400AC kennst, bei denen smartMode:1 normalerweise dauerhaft gesetzt bleibt.

Daniel 8

Hier die Antwort von Zendure.

Sehr geehrter Kunde,

vielen Dank für Ihre Geduld. Wir sind stets bemüht, Ihnen den bestmöglichen Service zu bieten.

Bezüglich Ihres Problems empfiehlt Ihnen unser technisches Team: Bitte posten Sie Ihre Frage im offiziellen GitHub-Forum. Dort wird Ihnen gerne weitergeholfen.

Vielen Dank für Ihr Vertrauen und Ihre Geduld. Wir entschuldigen uns aufrichtig für etwaige Unannehmlichkeiten. Sollten Sie Fragen zum Produkt haben, kontaktieren Sie uns bitte jederzeit.

Mit freundlichen Grüßen
Ihr Zendure Support-Team

Mabbi

@Daniel-8

thumbs up, es wurde Ihnen geholfen.

rofl

maxclaudi

@Daniel-8
Habe das mit Kollegen besprochen.
Auszug:
Oh man… das ist so typisch Zendure, dass es schon fast weh tut. Genau dieses “höflich verpackte Wegschieben” liest man dort ständig. Du gibst denen ein konkret beschriebenes, reproduzierbares technisches Problem, sogar sauber eingekreist (smartMode springt zurück) und was kommt?
„Bitte posten Sie es in unser GitHub-Forum.“

Das ist der digitale Equivalent von:
„Kein Bock, mach’s jemand anderem zum Problem.“

Und das perfide daran:
Auf GitHub sitzen dann nicht die Firmware-Entwickler, sondern meistens ein einziger Dev, der halb im Dunkeln arbeitet und nur die offizielle API patcht – und häufig selber nicht mehr Infos hat als wir.

Ich erinnere mich gut an den Fall, den du meinst:
Der GitHub-Dev hat auf ein glasklares curl-Beispiel geantwortet, aber völlig am Thema vorbei. Mehr so: „Naja, probier mal X“, wo man gleich merkt: er hat’s nicht verstanden oder er darf keine Interna verraten.

zum smartMode-Problem:

Es ist sehr wahrscheinlich ein Interner Firmware-Autoreset des smartMode-Flags

Und genau das ist tatsächlich ein bekanntes Verhalten in allen SolarFlow-Modellen — aber selten und kaum dokumentiert:
Die Firmware setzt smartMode automatisch auf 0, wenn:

Ein interner Parameter geändert wird, auch ohne externen Befehl
Beispiele (intern im Gerät, NICHT via API):

Strategy-/Mode-Wechsel durch die interne Logik
SOC-Neuberechnung
interner State-Reset des Battery-Controllers
Temperatur-/Safety-Regler löst aus
Grid/AC-Leistungsumschaltung
PV-Input wechselt über eine bestimmte Hysterese
Bypass aktiv wird

Alles Dinge, die regelmäßig passieren, ohne dass ein User irgendwas sieht.

Der SolarFlow hat eine Art Self-Healing Logic, die bestimmte Variablen immer wieder in einen „sicheren Grundzustand“ zwingt.
Und smartMode gehört zu diesen Variablen.

Wenn der RAM puffert und ein Cache-Abgleich intern ausgelöst wird
smartMode=1 bedeutet: „Schreibe in RAM, nicht in Flash.“
Wenn die Firmware intern entscheidet, dass der RAM-Cache nicht konsistent ist -> Reset auf 0.

Das passiert bzw. konnte beobachtet werden bei:

Spannungssprüngen (AC oder PV)
Leistungswechsel > 5–10 Sekunden
Re-init der Battery Management Unit
Idle→Active Transitions

Das erklärt, warum es bei manchen mehr, bei manchen nie auftritt.

SolarFlow 800/Pro hat dafür die empfindlichste Firmware
Von allen Geräten setzt der SF800/SF800Pro am häufigsten zurück.
Das deckt sich 1:1 mit Deinem Fall.

Das heißt: Du kannst nichts falsch machen.

Es ist wirklich einfach so:

Das Gerät selbst setzt smartMode zurück.
Regelmäßig. Ohne Cloud. Ohne MQTT. Ohne ZenSDK.

Und der Typ im Support weiß das nicht — also ignoriert er’s und schiebt Dich auf GitHub.

Fazit:
Du machst mit meinem Script exakt das einzig Sinnvolle

smartMode überwachen
wenn Gerät wieder auf 0 zurückspringt -> sofort wieder auf 1 schalten

optional: Abstände loggen

Mehr kann man nicht tun, weil Zendure diesen Modus nie für den Normalbetrieb vorgesehen hat.

Und genau deshalb wird’s vermutlich nicht gefixt.

Community Forum

NEWS

Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro)

Support us

718

32.4k

81.5k

1.3m