Test Adapter Zendure Solarflow

Kiter1988

Hallo,

ich benutze meinen Hub2000 seit Vorgestern mit meinem lokalen mqtt , da es vorkam dass die Verbindung zur Cloud mehrfach am Tag abrissen ist.

Heute Nacht riss aber auch die Verbindung vom Hub zu meinem mqtt broker ab und ich musste den bt-manager erneut ausführen, damit die Verbindung wieder zustande kam. Ist das Problem bekannt ?
Was kann ich tun ?

Eine andere Frage wäre noch,
wie kann ich den Akkuprioritätsmodus aktivieren ?
Ich habe es über den Datenpunkt aus dem Adapter probiert, dieser stellt sich aber nach kurzer Zeit wieder um in den "smart matching modus"

Arne Dieckmann

@kiter1988 said in Test Adapter Zendure Solarflow:

Hallo,

ich benutze meinen Hub2000 seit Vorgestern mit meinem lokalen mqtt , da es vorkam dass die Verbindung zur Cloud mehrfach am Tag abrissen ist.

Heute Nacht riss aber auch die Verbindung vom Hub zu meinem mqtt broker ab und ich musste den bt-manager erneut ausführen, damit die Verbindung wieder zustande kam. Ist das Problem bekannt ?
Was kann ich tun ?

Den Abbruch der Verbindung hatte ich auch ca. einmal pro Tag (und auch andere Nutzer hier). Ich lasse derzeit meinen MQTT Server alle zwei Stunden neu starten. Seitdem hängt da nichts mehr. Es kommen nur ein paar Warnmeldungen des Zendure Adapters. Aber da weiß man ja, warum.

Arne Dieckmann

@bernd1967 said in Test Adapter Zendure Solarflow:

@arne-dieckmann
Wenn ich nicht falsch liege läuft das so:
Wenn das Geräte ein Zeitstempel (timestamp) liefert wird dieser mit der aktuellen Zeit verglichen.
Weicht dieser um 10 Minuten ab gilt das Gerät als "Offline".

Kommt nicht hin. Habe den Zendure Adapter neu gestartet. Zeitstempel und "zuletzt geändert" sind dann erstmal fast identisch. Nach ungefähr 30 Sekunden toggeln steht alles wieder auf disconnected.

Bernd1967

@arne-dieckmann
Nicht das Du es falsch verstanden hast.
timestamp vom Gerät bedeutet timestamp im Payload z.B.:

Topic: mqtt.0.gDa3tb.+++++.function.invoke.reply

Payload:
{"messageId":700001,"deviceId":"+++++","timestamp":1755032357,"function":"deviceAutomation","output":"success","success":1}

Besser ist es vielleicht den Datenpunkt "zendure-solarflow.0.gDa3tb.++++.lastUpdate" im Adapter zu nutzen.

Nachtrag:
Wie ich gerade feststellen muß wird "lastUpdate" auch aktualisiert wenn der Adapter selbst in "mqtt.0.iot.gDa3tb.+++++.function.invoke" ein publish absetzt.
Also am besten eine eigene Routine bauen.
Ich überwache den Pfad "mqtt.0.gDa3tb.++++++.*"
Wenn hier nichts mehr ankommt nach 120 Sekunden; gilt mein Hyper als "Offline"

maxclaudi

Der Hub2000 unterstützt smartMode:1
ace1500 allein unterstützt nicht smartMode.

json immer nur an den HUB publishen.

Für den Adapter bedeutet das:

control-Datenpunkte unter dem ACE1500 schreiben in Flash.
smartMode Schalter unter ace1500.control ist vorhanden aber für die dortigen Datenpunkte vom ace1500 wirkungslos.
Zur Steuerung des ace1500 immer nur die Datenpunkte control vom HUB2000 mit smartMode:1 verwenden.

Angaben beziehen sich auf meine Geräte HUB2000 und ACE1500.
Vermutlich ist das bei allen HUB2000 und ACE1500. Garantieren kann ich nichts.

The_Stig

Kurzes Update: auf ausschließlich lokale Steuerung zurück und mit MQTT-Restart alle 2 Stunden auch keine Abbrüche mehr. Danke für den Tipp.

cbrocker

@schaafalexander sagte in Test Adapter Zendure Solarflow:

@cbrocker said in Test Adapter Zendure Solarflow:

@schimi
sprich,
man kann nach wie vor die App parallel nutzen?

Da man ja das HEMS deaktivieren muß, wie ist es mit der 0-Einspeisung?
Muß ich das dann über Blockly oder so machen oder gilt 0-Einspeisung trotzdem?

Es sieht so aus, als müsse man das dann direkt über Blockly lösen.
Konnte manuell die Werte einfach im MQTT Objekt setzen und er hat die Ausgangsleistung angepasst.
Aber es gibt kein Steuerungssignal mehr vom Shelly in der Weboberfläche auf das er sich beziehen kann, da man sich ja vom HEMS trennt.

Danke dir.
Ja, meine Befürchtung ist, wenn der ioBroker, WLAN oder Router mal rumzickt, dann wird womöglich unkontrolliert eingespeist oder evtl. sogar von AC geladen.

SchaafAlexander

@cbrocker said in Test Adapter Zendure Solarflow:

@schaafalexander sagte in Test Adapter Zendure Solarflow:

@cbrocker said in Test Adapter Zendure Solarflow:

@schimi
sprich,
man kann nach wie vor die App parallel nutzen?

Da man ja das HEMS deaktivieren muß, wie ist es mit der 0-Einspeisung?
Muß ich das dann über Blockly oder so machen oder gilt 0-Einspeisung trotzdem?

Es sieht so aus, als müsse man das dann direkt über Blockly lösen.
Konnte manuell die Werte einfach im MQTT Objekt setzen und er hat die Ausgangsleistung angepasst.
Aber es gibt kein Steuerungssignal mehr vom Shelly in der Weboberfläche auf das er sich beziehen kann, da man sich ja vom HEMS trennt.

Danke dir.
Ja, meine Befürchtung ist, wenn der ioBroker, WLAN oder Router mal rumzickt, dann wird womöglich unkontrolliert eingespeist oder evtl. sogar von AC geladen.

Das sind die einzigen beiden Kenngrößen die befüllt werden können über die App, wenn mans ausm Hems löst.
Finde das auch etwas schade, aber mal sehen wie ichs dann final umsetze.

maxclaudi

@kiter1988 sagte in Test Adapter Zendure Solarflow:

Hallo,

ich benutze meinen Hub2000 seit Vorgestern mit meinem lokalen mqtt , da es vorkam dass die Verbindung zur Cloud mehrfach am Tag abrissen ist.

Heute Nacht riss aber auch die Verbindung vom Hub zu meinem mqtt broker ab und ich musste den bt-manager erneut ausführen, damit die Verbindung wieder zustande kam. Ist das Problem bekannt ?
Was kann ich tun ?

Eine andere Frage wäre noch,
wie kann ich den Akkuprioritätsmodus aktivieren ?
Ich habe es über den Datenpunkt aus dem Adapter probiert, dieser stellt sich aber nach kurzer Zeit wieder um in den "smart matching modus"

Wenn Du

keinen (weiteren) hyper verwendest
nur den HUB2000 betreibst
den hub2000 betreibst mit einem ace1500 "gebunden" an den hub2000

dann würde ich:

bei Vewendung des Adapters, die Version v1.15.4 benutzen mit smartMode:1
(smartMode unter control immer eingeschaltet)
zusätzlich mit einem script den Datenpunkt smartMode triggern.
wenn der Datenpunkt aus irgend einem Grund auf auf false (bzw. 0) gesetzt wird, dann mit einem kleinen timeout den Datenpunkt automatisch wieder auf true (1) setzen lassen.
die Steuerung nur über den HUB2000 vornehmen unter
zendure-solarflow.0.A8yh63.<deviceID>.control

und alle Probleme sollten weg sein.

Michi 0

Rückmeldung von Zendure:

*"Der Wert des Steuergeräts wird in den Flash-Speicher geschrieben, wodurch die Betriebsfrequenz so weit wie möglich reduziert und gleichzeitig die Anzahl der Schreibvorgänge reduziert werden kann.
Ich hoffe, dass die oben genannten Informationen für Sie hilfreich sein können.

Vielen Dank für Ihre Unterstützung und Ihr Verständnis."*

Heißt das, alles was an Steuerung anfällt läuft über den Flash? Wenn man die Ladung/Entladung des Speichers tatsächlich (wie wohl von allen hier beabsichtigt und auch vom Hersteller vorgesehen) ständig anpasst, kommen da am Tag doch bestimmt ein paar hundert Befehle zusammen. Das würde ja auch bei Anbindung eines Shelly 3 EM oder des Zendure Hausinternen Strommessgerätes gelten. Wird das Thema Schreibrate hier ggf. zu hoch aufgehängt oder macht Zendure das bei der Steuerung über die extern angebundenen Smartmeter das irgendwie anders?

maxclaudi

@michi-0 sagte in Test Adapter Zendure Solarflow:

Erst mal ein großes Dankeschön für die (erwartete, traurige) Bestätigung.

Rückmeldung von Zendure:

*"Der Wert des Steuergeräts wird in den Flash-Speicher geschrieben, wodurch die Betriebsfrequenz so weit wie möglich reduziert und gleichzeitig die Anzahl der Schreibvorgänge reduziert werden kann.
Ich hoffe, dass die oben genannten Informationen für Sie hilfreich sein können.

Vielen Dank für Ihre Unterstützung und Ihr Verständnis."*

Heißt das, alles was an Steuerung anfällt läuft über den Flash? Wenn man die Ladung/Entladung des Speichers tatsächlich (wie wohl von allen hier beabsichtigt und auch vom Hersteller vorgesehen) ständig anpasst, kommen da am Tag doch bestimmt ein paar hundert Befehle zusammen.

Kurze, traurige Antwort: ja
Bitte dran bleiben und nachhaken, bis die restlichen Fragen beantwortet wurden.

Die Erklärung für Betriebsfrequenz wäre interessant, aber eigentlich unnötig.
Es wird vermutlich (wie in meinem script geprüft) ob ein identischer Wert geschrieben werden soll. Wenn schon vorhanden, dann nicht... oder ähnlich.
Das hilft leider nicht weiter.

Das würde ja auch bei Anbindung eines Shelly 3 EM oder des Zendure Hausinternen Strommessgerätes gelten. Wird das Thema Schreibrate hier ggf. zu hoch aufgehängt oder macht Zendure das bei der Steuerung über die extern angebundenen Smartmeter das irgendwie anders?

unbedingt beim Support nachhaken!
Denke aber nicht, dass es anders gemacht wird.
Hab schon einige Tests durch und bisher alles traurige durch die Tests bestätigt bekommen.

Noch einmal, auch wenn ich mich unbeliebt mache und das niemand lesen möchte:
Nur weil es den SmartMatchingModus gibt und dies Zendure dort auch "so ähnlich" macht, bedeutet das NICHT, dass nicht in den Flash geschrieben wird.
Das mapping ist etwas anders aber flash bleibt flash.

Michi, bitte bleib dran (Vorlage von meinem post hast ja noch und auch die Bitte nach einer Firmware die 3 keys (acMode/setInputLimit/setOutputLimit) bei autoModel:0 nur ins RAM speichert.

Eine solche Firmware würde mir zwar nicht helfen, wenn sie ältere Geräte nicht updaten, aber Dir und Allen mit neuen Geräten.

Es müssten mehr Leute aktiv Support-Anfragen stellen um eine Chance auf Erfolg zu haben.

Sollten die Fragen nun als beantwortet gelten und sie nicht darauf reagieren: neues Ticket bzw. Anfrage.

Rene55

@maxclaudi Also, wenn ich das richtig deute, ist mein HUB1200, den ich ja aktuell intensiv mit '.control.setDeviceAutomationInOutLimit' steuere, über kurz oder lang defekt. Und da wird sich Zendure auch bezüglich Kulanz oder so auch fein raushalten.

maxclaudi

@rene55 sagte in Test Adapter Zendure Solarflow:

@maxclaudi Also, wenn ich das richtig deute, ist mein HUB1200, den ich ja aktuell intensiv mit '.control.setDeviceAutomationInOutLimit' steuere, über kurz oder lang defekt.

Bisherige Erkenntnis (Tests + Code Analyse HA+adapter) und Einbeziehung der Antwort von Zendure (von michi bereitgestellt):

Die Gefahr ist groß.

HUB1200 und HUB2000 würde ich (vor allem bei intensiver Nutzung der Steuerung) über den solar-flow-Adapter die Version v1.15.4 verwenden.

Siehe mein post, bei zusätzlicher Verwendung von ace1500 auch unter Berücksichtgung von meinem weiteren post.

smartMode:1 ist nicht schadhaft, jedoch was alles ins RAM geschrieben wird (und was nicht) ist auch nicht 100%ig bestätigt und schwer zu testen.
Macht es aber teilweise und richtig (ohne mqtt Abbrüche, Fehler etc.) im Gegensatz zum SmartmachtingMode.

Mehr kann man im Moment nicht machen und ist m. M. für HUB1200 und HUB2000 der sicherste Weg.
Wenn denn HUB1200 auch smartMode gesetzt werden kann:
anscheinend ja.

gerade von einem Kollegen erhalten:

Du bekommst wahrscheinlich nun immer mehr schriftlich bestätigt, dass unsere Tests und deine Befürchtungen über Flash-Writes, eingeschränkte Parameter und das MQTT-Reply-Verhalten stimmen.

Das ist so ein bisschen wie bei einem Arztbesuch, wo man insgeheim hofft: „Vielleicht ist es doch nichts Schlimmes“ – und dann sagt der Arzt: „Ja, genau so schlimm wie Sie denken“.

maxclaudi

@michi-0 sagte in Test Adapter Zendure Solarflow:

Rückmeldung von Zendure:

*"Der Wert des Steuergeräts wird in den Flash-Speicher geschrieben, wodurch die Betriebsfrequenz so weit wie möglich reduziert und gleichzeitig die Anzahl der Schreibvorgänge reduziert werden kann.
Ich hoffe, dass die oben genannten Informationen für Sie hilfreich sein können.

Vielen Dank für Ihre Unterstützung und Ihr Verständnis."*

Heißt das, alles was an Steuerung anfällt läuft über den Flash? Wenn man die Ladung/Entladung des Speichers tatsächlich (wie wohl von allen hier beabsichtigt und auch vom Hersteller vorgesehen) ständig anpasst, kommen da am Tag doch bestimmt ein paar hundert Befehle zusammen.

hier mal ein Auszug von Schreibvorgänge pro Tag:

Steuerung zur angestrebten 0 Einspeisung.
Eher mehr einspeisen als Verbrauch.
PV-Überschuss wird zum zusätzlichen Laden der Batterien verwendet.
Je nach Wetter wird unterschiedlich oft angepasst
(Wolken, Sonne, Nebel, Regen, Morgen, Mittag, Abend, Jahreszeit)
Kritische Verbraucher werden mit delta und großzügiger Einspeisung behandelt um Schwingen abzufangen usw.
Versucht wird wenig Umschaltbefehle zu erzeugen.

Steuerung funktioniert einwandfrei, aber mit den Werten für ein Flash-Schreiben nicht prickelnd.
Auszug eines log:

-------------------------------
acMode wurde heute: 2 x geändert.
inputLimit wurde heute: 6 x geändert.
outputLimit wurde heute: 195 x geändert.
06.08.25, 23:59:00
-------------------------------
acMode wurde heute: 4 x geändert.
inputLimit wurde heute: 43 x geändert.
outputLimit wurde heute: 254 x geändert.
07.08.25, 23:59:00
-------------------------------
acMode wurde heute: 16 x geändert.
inputLimit wurde heute: 34 x geändert.
outputLimit wurde heute: 257 x geändert.
08.08.25, 23:59:00
-------------------------------
acMode wurde heute: 12 x geändert.
inputLimit wurde heute: 2 x geändert.
outputLimit wurde heute: 86 x geändert.
09.08.25, 23:59:00
-------------------------------
acMode wurde heute: 1 x geändert.
inputLimit wurde heute: 0 x geändert.
outputLimit wurde heute: 76 x geändert.
10.08.25, 23:59:00
-------------------------------
acMode wurde heute: 0 x geändert.
inputLimit wurde heute: 0 x geändert.
outputLimit wurde heute: 34 x geändert.
11.08.25, 23:59:00
-------------------------------
acMode wurde heute: 4 x geändert.
inputLimit wurde heute: 10 x geändert.
outputLimit wurde heute: 447 x geändert.
12.08.25, 23:59:00
-------------------------------
acMode wurde heute: 2 x geändert.
inputLimit wurde heute: 19 x geändert.
outputLimit wurde heute: 403 x geändert.
13.08.25, 23:59:00
-------------------------------
acMode wurde heute: 2 x geändert.
inputLimit wurde heute: 8 x geändert.
outputLimit wurde heute: 302 x geändert.
14.08.25, 23:59:00
-------------------------------

Theoretisch müsste mein flash schon defekt sein, wenn nicht viel ins RAM geschrieben wird.
Verwendet wird: acMode/inputLimit/outputLimit in autoModel:0

Wie auch beim offiziellen MQTT bei neuen Geräten möglich.

PS: zusätzlich beim HUB2000 immer: smartMode:1 bzw. bei Verwendung des Adapters: smartMode: true

Rene55

@maxclaudi Ich bin dann wieder auf 1.15.4 und hab den smartmode auf true. Steuern dann also über '.control.setOutputLimit'. Ich lass dann auch mal mitzählen, wie oft 'setOutputLimit' den Wert wechselt, 'smartmode' ist ja konstant auf true.

maxclaudi

@rene55

würde noch über js oder Blockly smartMode triggern.
Wenn smartMode auf false gesetzt werden sollte, dann nach einem timeout (bei mir 10 sek.) automatisch auf true setzen lassen.

Bei mir wird dazu extra noch eine email gesendet, dass ich sofort Bescheid weiß.
Seit Nutzung von smartMode geschah dies 2x bei mir, dass smartMode sich (scheinbar automatisch) zurück auf 0 (false) setzte.
Kann aber nicht ausschließen, dass dies mit anderen, zeitgleichen Tests erfolgte.
Möchte sicher gehen, dass smartMode:1 gesetzt bleibt.

Rene55

@maxclaudi jo, das krieg ich auch hin.

maxclaudi

Gut oder weniger gut??

Fall: alles wird ins Flash gespeichert.

Annahmen

Zeitraum bisher: September 2024 bis Mitte August 2025 ~11 Monate (~330 Tage)
Maximal beobachtete Änderungen pro Tag: outputLimit ~ 828 Writes pro Tag
acMode und inputLimit vernachlässigt, da deutlich seltener.

Flash-Zyklen eines „Consumer“-Geräts konservativ geschätzt: 50.000 Writes pro Zelle
(hochwertigeres Industrie-Flash kann 100k–1 Mio, Billig-Flash 10k–50k)

2️. Gesamtanzahl bisheriger Writes für outputLimit

Wir nehmen einen Mittelwert aus meinem Log: grob ~500 Writes/Tag
330 Tage × 500 Writes ≈ 165.000 Writes bisher (seit LOG-Beginn)

Hinweis: Das ist schon über der konservativen 50k-Zyklen-Annahme, aber:

Flash-Speicher ist nicht eine Zelle, sondern ein Block- und Wear-Leveling-System

Zendure verteilt Schreibvorgänge intern (Wear-Leveling): eine einzelne Zelle wird nicht jeden Write getroffen
(Wear-Leveling: sonst wäre mein HUB2000 schon defekt)

In der Praxis bedeutet das: die Flash-Lebensdauer wird deutlich verlängert

Hochrechnung der Lebensdauer

Angenommen konservativer Flash (50k Zyklus pro Zelle)

Wear-Leveling verteilt die Writes auf 10 Speicherblöcke: effektive Zyklenzahl ≈ 50k × 10 = 500k Writes

Bei 500 Writes/Tag: 500k / 500 ~ 1.000 Tage ~ 2,7 Jahre!

Realistischer: Zendure verwendet vermutlich 100k Zyklen pro Zelle, mehrere Blöcke: 5–10 Jahre sind erreichbar

10 Jahre sind für ein Consumer-Gerät wie Zendure eher optimistisch – vor allem bei intensiver Nutzung.

konservativ gerechnet:

Flash-Zellen: 50.000–100.000 Zyklen pro Zelle (Consumer)
Wear-Leveling: ca. 10 Blöcke: effektive Zyklen 500.000–1.000.000
Bei ~500 Writes pro Tag -> 1.000–2.000 Tage -> 2,7–5,5 Jahre

Selbst mit weniger Writes oder hochwertigerem Flash würde man eher 5–6 Jahre als realistische Lebensdauer erwarten, bevor die Flash-Zellen erste Abnutzungserscheinungen zeigen.

Fazit

Der HUB2000 ist noch (lange?) nicht am Ende, selbst bei intensiver Nutzung und speichern in Flash.

Verbraucher wie outputLimit verursachen die meisten Writes.

Beachten:
Garantie 10 Jahre: wahrscheinlich auf Funktionalität, nicht auf unbegrenzte Flash-Zyklen!

Also unnötige Writes vermeiden: wie bisher schon umgesetzt
Meine erwartete realistische Lebensdauer: ca. 5 Jahre.

Merke:
Bei Consumer-Geräten ist Flash „begrenztes Gut“, aber Firmware mit Wear-Leveling + seltene kritische Writes: Lebensdauer bleibt für 5–10 Jahre realistisch.

reale Lebenserwartung mit dem Flash speichern:
Bei optimistischen Bedingungen mit einer Regelung durch mein Script und schreiben ins Flash "sollten" 5 Jahre machbar sein.
Ist das jetzt für den Preis ok oder weniger ok?

andere Hersteller und deren Produkte werden es ähnlich oder identisch handhaben.
Ist nur eine Analyse und grobe Einschätzung.
Zendure ist mir nur bekannter, weil wir es selbst nutzen.
Die Steuerungs-/Regelmöglichkeiten soll erst mal ein anderes Produkt für den Preis liefern.
Nur bei bei der Nutzungszeit ist mir nicht ganz so wohl.
Anschaffungspreis<> Nutzung/Amortisation

Kann sowieso nicht geändert werden und nur das Beste daraus gemacht werden.

Rene55

@maxclaudi Oha, da muss ich meine Strategie nochmal überdenken: Ich habe seit heute Mittag ca.14 Uhr bis heute Abend ca.20.45 Uhr schon 2190 Schreibatacken auf 'setOutputLimit' ermittelt.

maxclaudi

@rene55 sagte in Test Adapter Zendure Solarflow:

@maxclaudi Oha, da muss ich meine Strategie nochmal überdenken: Ich habe seit heute Mittag ca.14 Uhr bis heute Abend ca.20.45 Uhr schon 2190 Schreibatacken auf 'setOutputLimit' ermittelt.

In 7 Stunden 2190 x outputLimit zu setzen ist m. M. zu viel und bestimmt auch nicht nötig.

Zielsetzung: Script, dass Dein Ziel (in etwa) erreicht wird, mit max. x Schreibvorgänge 24h umsetzen.

x ist von Dir (Risikobereitschaft) und Deinem Ziel (wie genau es mit weniger Schreibvorgänge/Verbrauchsverhalten etc. erreicht werden kann) abhängig.

Für mich und den beobachteten Energieplanverhalten setze ich dazu 500/24h.
Maximaler Ausreißer/Ausnahme: 900/24h.
Das ist nur für mich so und gilt nicht als Maßstab.
Nur Info und vielleicht hilft es als Vergleich.
Zusätzlich verwenden meine Steuerungen öfters den Bypass.

Eine Mitteilung, nicht von Zendure.
Wurde aus NDA und Support-Gründen so formuliert.

RAM/Flash-Nutzung: Profi- vs. Consumer-PV-Geräte

Bereich	Industrie-/Profi-Geräte (z. B. SMA, Fronius, Victron)	Consumer-Geräte (z. B. Zendure, EcoFlow, Bluetti)
RAM	Immer ausreichend vorhanden (teilweise > 64 MB SDRAM). Wird für alle temporären Zustände genutzt (z. B. Limits, Moduswechsel).	Fast immer nur im Mikrocontroller integriert (einige KB – wenige MB). Reicht aus, wird aber oft nicht konsequent genutzt.
Flash-Nutzung	Nur für statische Daten: Firmware, Netzwerkeinstellungen, Geräte-ID, Seriennummer, Logging mit niedriger Frequenz.	Auch für dynamische Steuerparameter wie `outputLimit`, `acMode`, etc. – selbst wenn diese sich ständig ändern.
Wear-Leveling	Professionell implementiert, oft über dedizierte NAND-Controller mit sehr langer Haltbarkeit (100k–1M Zyklen).	Einfachere Wear-Leveling-Algorithmen, meist intern im MCU oder in Standard-Flash-Chips (10k–100k Zyklen realistisch).
Strategie bei Parametern	Parameter liegen im RAM. Nur bei bewusster Speicherung (z. B. "Save Config") werden sie ins Flash geschrieben.	Firmware schreibt oft automatisch ins Flash bei jedem Wert, manchmal nach Plausibilitätsprüfung ("Wert neu? ja/nein").
Zielsetzung	Langlebigkeit, Servicefähigkeit, hohe Ausfallsicherheit über 10–20 Jahre.	Einfachheit, niedrige Produktionskosten, schneller „Consumer-freundlicher“ Support.
Nach Stromausfall	Gerät startet mit Default + letzter gespeicherter Konfiguration (Flash). Dynamische Limits sind danach weg (außer separat gespeichert).	Gerät startet mit den zuletzt geschriebenen Werten aus Flash – deshalb schreiben viele Consumer-Geräte so oft.
Firmware-Philosophie	„RAM first, Flash nur wenn nötig“	„Alles sofort ins Flash, dann ist’s sicher“

(Wenig) RAM ist definitiv vorhanden, sonst läuft CPU nicht.
Zendure nutzt es aber nicht (oder kaum) für dynamische MQTT-Steuerungen, sondern sichert sofort ins Flash -> Consumer-Design.
Die (autoModel Methoden) Energiepläne weichen davon nicht ab.
Daher entsteht das Risiko mit vielen Schreibvorgängen.
Ob smartMode eine generelle Ausnahme ist (RAM-only), bleibt offen, weil Zendure es nicht offiziell dokumentiert.

Wir sind nicht allein, auch andere Hersteller gehen "übliche" Wege.

NEWS

Test Adapter Zendure Solarflow

Support us

269

32.4k

81.4k

1.3m