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. Und da wird sich Zendure auch bezüglich Kulanz oder so auch fein raushalten.
-
@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“.
-
@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:0Wie 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
-
@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.
-
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. -
@maxclaudi jo, das krieg ich auch hin.
-
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 JahreSelbst 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/AmortisationKann sowieso nicht geändert werden und nur das Beste daraus gemacht werden.
-
@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.
-
@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.
-
@maxclaudi sagte in Test Adapter Zendure Solarflow:
„Alles sofort ins Flash, dann ist’s sicher“
Mag sein, halte ich aber für Steuerungen leicht übertrieben. Bei 'modes' sehe ich das völlig genau so.
Zu meiner Strategie: ich möchte natürlich den Bezug nahe null halten, Derzeit bekomme ich vom Leskopf meines Zählers alle 10 Sekunden (!) den aktuellen Wert und regel dagegen. Das scheint mir tatsächlich etwas too much zu sein, zumal der WR ja gar nicht hinterher kommt. Ich Versuchs jetzt mal mit einem größeren Intervall und schau mir den Bezug weiter an.
Den ByPass-Mode nutze ich gar nicht mehr (Relais). -
@rene55 sagte in Test Adapter Zendure Solarflow:
Zu meiner Strategie: ich möchte natürlich den Bezug nahe null halten, Derzeit bekomme ich vom Leskopf meines Zählers alle 10 Sekunden (!) den aktuellen Wert und regel dagegen.
Bei mir zum Vergleich: Zähler liefert sehr schnell (1sek?) neue Daten.
Alle 15sec wird per script nur ausgewertet (kann angepasst werden), was aber nur erst einmal die Erfassung der Zählerdaten betrifft.
Danach wird noch von einigen anderen Parametern entschieden:
ob und was durchgeführt wird + ob sinnvoll oder nicht.zumal der WR ja gar nicht hinterher kommt.
Richtig. Macht keinen Sinn zu oft zu triggern, auszuwerten und Limits zu setzen, die der Wechselrichter nicht setzen + umsetzen kann, weil das Zeitfenster es nicht zulässt.
Dann lieber Strom verschenken und gleich großzügigeres outputLimit oder etwas mehr Verbrauch in Kauf nehmen (kleineres outputLimit für größere Hysterese verwenden) und nicht bei jedem Watt regeln. -
@maxclaudi Ums 'Strom verschenken' gehts nicht. Als SmartHomeianer habe ich tatsächlich einen recht hohen Grundverbrauch, sogar nachts bei knapp 320-380W. Möchte eben nur -wenn die Sonne scheint - möglichst wenig Bezug haben. Tagsüber war ich immer so um die 30 - 70 W, wenn nicht gerade Großverbraucher liefen. Bin jetzt mal auf 5 Minuten Mess/Regel-Interval.
-
@rene55 sagte in Test Adapter Zendure Solarflow:
@maxclaudi Ums 'Strom verschenken'
Leute nehmt doch nicht alles immer so genau und zerpflückt nicht, was ich wie schreibe
Ist nicht immer so hart oder böse gemeint.
Möchte nicht immer auf meine genaue "Wortwahl" achten müssen
Reicht wenn man versteht, was ich meine und ist nie so hart oder gar böse gemeint. -
@maxclaudi Alles Gut. Ich hab mich nicht angegriffen gefühlt. Mach ruhig weiter so, und musst auch nicht jedes Wort auf die Goldwaage legen. Bin ja schon recht froh, dass hier so einiges Diskutiert und offen gelegt wird.
UND: Verstehen tue ich dich gut -
@rene55 sagte in Test Adapter Zendure Solarflow:
sogar nachts bei knapp 320-380W.
Das könnte man doch gut abfangen.
z. B.: man weiß, dass ab einer bestimmten Uhrzeit (meistens) nicht mehr gekocht wird, keine Großverbraucher wie Waschmaschine etc. laufen und man schläft oder nur TV sieht, höchstens kaltes Essen mit Gästen etc.Ab x Uhr bis 5 Uhr fix outputLimit: 400W solange Bat > minSoc.
Bin jetzt mal auf 5 Minuten Mess/Regel-Interval.
Evtl. besser als nur das Intervall wären mehr Bedingungen für Entscheidungen (ob und welcher Wert und bis zu welchem Umfang gültig) outputLimit gesetzt werden soll.
-
Nur noch mal für mein Verständnis: das Problem mit dem zu häufigen Schreiben in den Flash ist beim Hyper mit der neuer Steuerung von @nograx nicht mehr vorhanden, oder?
-
@maxclaudi Ja, das wäre die einfache Version, die ich bis vor einigen Wochen in Betrieb hatte. Outputlimit etwas unter dem ermittelten Verbrauch nachts, einschalten gegen 20:00 Uhr und dann einspeisen lassen bis socMin erreicht ist. Ich hatte angenommen, wenn ich die Regelung über Tag mache könnte ich noch ein quäntchen mehr sparen, weil dann -in der bezugsarmen Zeit - der Akku wieder nachgeladen wird. Mal sehen, vllt. gibt es einen Mittelweg. Aktuell ist der SOC noch bei 31%, so dass mein Script noch gar nicht geschaltet hat.
-
@the_stig sagte in Test Adapter Zendure Solarflow:
Nur noch mal für mein Verständnis: das Problem mit dem zu häufigen Schreiben in den Flash ist beim Hyper mit der neuer Steuerung von @nograx nicht mehr vorhanden, oder?
Das Problem ist weiterhin vorhanden.
Ungewiss in welchem Ausmaß. Vermutlich komplett.Wenn Du unsicher bist, teste und schreib support an und hoffe auf eine Antwort.
Dazu müsstest aber behaupten, dass Du HA benutzt und Glück haben, dass Zendure die Integration i. V. mit einem Hyper und der Funktion invoke überhaupt als Bestandteil von Zendure anerkennt.Bisher denke ich aufgrund Tests, logging und Geräteverhalten (siehe meine vorherigen Beiträge), dass immer in den Flash geschrieben wird.
Auch bei den neuen Geräten.Gleichgültig welches autoModel benutzt wird, welche Strategie und mapping verwendet wird und ob es Zendure auch so macht.
Es wird in den Flash geschrieben.
Bei automatic modes (Energiepläne) sorgt die Firmware z. T. eigenständig durch Entscheidungen wie oft z. T. geschrieben wird und ob in einem gewissen Rahmen neue Werte häufiger oder seltener geschrieben werden.
Letzten Endes wird aber in Consumer-Geräte meistens in den Flash geschrieben.Wenn man SmartMatchingMode entfremdet und gibt selbständig oft neue Werte (der Wert muss gar nicht unbedingt als absolut angesehen werden, sondern könnte ein Rahmenwert für eigene Entscheidungen durch die Firmware sein, die sie aber nicht mehr umsetzen könnte, weil weitere, ständige Parameter zur Auswertung nun fehlen(?)), dann kommt nicht nur einiges durcheinander, dann stimmt die ganze "vorhergesehene/bestimmte/erwartete" Ablaufsteuerung, nicht mehr.
Am Ende landet die eigentliche Anforderung im Flash.
Ob nun über outputLimit gesetzt oder über funktion invoke.Die Code-Analyse von HA bringt auch nichts weiter außer, dass in einem anderen autoModel über die Funktion invoke geschrieben wird.
Der adapter-Code hat als Basis den HA-Code und ist noch reduzierter.Bis jetzt habe ich dazu nur nebulöse und schwammige Antworten erhalten, wie:
"macht Zendure genau so" (meine Interpretation: richtig, ins Flash speichern. Consumer-Gerät)
"kann ich mir nicht vorstellen" usw.Bei harten Tests, die durchgeführt wurden, blieben die Einstellungen erhalten.
Auch beim hyper -> Flash.Das deckt sich auch mit der Antwort von Zendure für neue Geräte, dass Werte in den Flash gespeichert werden.
Selbst wenn Zendure eine eigene Entwicklungsabteilung hat/hätte und die nicht outsourced ist, dann ist es unwahrscheinlich, dass das geändert wird.
Kostet Geld und außerdem ist wear-leveling ins Flash bei Consumer-Geräten anscheinend üblich.Würde mich freuen, wenn man meine Aussagen/Tests/Reverse Engineering/logs mit Beweisen widerlegen würde.
Behauptungen und Diskussionen führen nicht weiter, wenn sie nicht durch Aussagen von Zendure oder durch reproduzierbare Tests (gilt auch für Zendure) untermauert werden.
-
@rene55 sagte in Test Adapter Zendure Solarflow:
Den ByPass-Mode nutze ich gar nicht mehr (Relais).
Ist ein Argument.
Jeder wie er möchte.Für mich selbst sehe ich das bei meinem HUB2000 nicht kritisch.
Wenn keine Last vorhanden, kann ein Relais bedenklos geschaltet werden.
Kritisch bei mir wäre das Bypass Einschalten.Folgendes betrifft Bypass Modus: automatic (passMode: 0) bei meinem HUB2000
Wer den Ablauf von Zendure analysiert hat, der wird schnell erkennen, dass vor dem Einschalten in den Bypass (wenn Batterien voll sind) die PV-Leistung der Eingänge reduziert werden bis auf: ~0.
Dann erfolgt immer wieder eine Ruhepause für die Batterien (bis sie etwas abgekühlt sind etc.) und dann wird wieder mit ein paar wenigen Watt nachgeladen.Die PV-Eingangsleistung bleibt zwischen 0 und stark reduziert.
Das wiederholt sich je nach Batteriezustand ein paar mal.
Dann wird umgeschaltet und die PV-Eingänge werden hoch gefahren.
Nicht mit einem simplen Umschalten.
Das suggerieren nicht nur die Werte (Datenpunkte/mqtt) sondern auch real die Leistung vom Wechselrichter und die Daten des Zählers.
Bedeutet für mich: ein hartes Umschlten nur durch Relais unter Last wird nicht durchgeführt.
Erst wird am Eingang der Strom gedrosselt.Wie das außerhalb des automatic-Bereich aussieht und der Strom dort auch gedrosselt wird, kann ich nicht beurteilen.
Kann gut sein, dass bei manuellem Umschalten auf passMode:1 oder passMode:2 sofort geschaltet wird.
Habe das außer Acht gelassen, weil für mich nicht wichtig.Bei mir steht Bypass normal auf automatic.
Der Bypass wird per script ausgeschaltet, wenn PV-Eingangsleistung <20W über 3min und frühestens 4 Stunden vor Sonnenuntergang.
<20W ist eigentlich keine Leistung für ein Relais und müsste es leicht aushalten.Wann schaltet der automatic-Modus (passMode:0) um?
automatic Modus schaltet allein um, wenn ca 20W über eine Zeit von >= 5min ist und zusätzlich ein weiterer Parameter (den ich bisher nicht sicher ausfindig machen konnte) wirkt. Vermutlich auch die Zeit.Das funktionierte für mich mal gut, mal weniger gut.
Deshalb schaltet mein script den automatic-Modus bei sehr geringer Eingangsleistung und abhängig vom Sonnenuntergang um.
Den Bypass auf automatic schalte ich in der Nacht wieder ein.
Keine PV-Leistung vorhanden = keine Last am Relais.Sollte das Relais irgendwann wirklich defekt sein, dann wäre das mein kleinstes Problem.
Sollte Zendure nicht austauschen, dann würde ich es selbst vornehmen. -
@maxclaudi Danke für die perfekte Erklärung. Ich denke, das wird auch der richtige Ansatz für meine 'neue' Steuerung.
