Test Adapter Zendure Solarflow

maxclaudi

Verbinde Dich mal mit der Cloud und nutze die App.
Schalte in der App HEMS für den AC2400 aus.
Danach von der App abmelden. (Zugangsdaten hast ja weiterhin und bestimmt bereits notiert, gespeichert)
Kann sein, dass der AC2400 dann erst mal in BT Modus ist.
DNS Umleitung mit Broker wieder aktvieren und iobroker zendures-solarflow-adapter Verbindung über lokalen Server starten.
AC2400 neu starten.
Testen...
Bitte Rückmeldung.

maxclaudi

@daniel-8 sagte in Test Adapter Zendure Solarflow:

ZU der 2.ten Frage bezüglich Schreibvorgänge auf dem Speicher kannst du dazu eine Aussage machen?

@nograx sagte in Test Adapter Zendure Solarflow:

Zum Thema Schreibzugriff auf Speicher habe ich keine Infos. Mich würde es aber schockieren..

@nograx
gebe es mal (übersetzt) weiter.
Die Mitteilung stammt von einem developer der Kontakt zu Zendure hat:

Zitat:
developer:

Da der Hyper2000 Kommunikationsprobleme hat, fragte ich, ob der AC-Modus eine alternative Lösung sein könnte. Zendure antwortete daraufhin:

zendure:

Von den Kollegen aus der Geräteentwicklung habe ich erfahren, dass sich die Steuerung über den AC-Modus von der über das AutoModeProgram unterscheidet. Im AC-Modus wird die Stromversorgung in den Flash geschrieben. Werden alle 2 Sekunden Befehle ausgegeben, ist der Flash schnell voll, was zu Gerätestörungen führt.

developer:

Ich hielt es für wichtig, dies mitzuteilen, um zukünftige Enttäuschungen zu vermeiden. Jeder kann selbst entscheiden, ob er etwas damit anfangen möchte, mich stört das überhaupt nicht.

Auf Nachfrage war die Folgeantwort:

zendure:

Bei jedem Wechsel des Ausgabemodus wird der Speicher in den Flash-Speicher geschrieben. Warum? Dadurch soll sichergestellt werden, dass das Gerät nach einem Stromausfall den letzten Zustand beibehält. Die neuen 2025-Produkte verfügen über die Eigenschaft „smartMode“. Sobald der Wert 1 ist, wird die AC-Modus-Einstellung nicht mehr in den Flash-Speicher geschrieben, wodurch die Lebensdauer des Flash-Speichers deutlich verlängert wird.

Daher ist bei der Verknüpfung im CT-Modus der Smartmode auf 1 eingestellt, und der AC-Mode kann wiederholt gesetzt werden, um einen Ausgleich zwischen der gesamten Energieaufnahme und -abgabe des Haushalts zu erreichen.

Den Wahrheitsgehalt der Mitteilung kann ich nicht überprüfen.

Es gibt ein Zendure Lokales Steuerungssystem das den SolarFlow 800 in der Firmwareversion 1.1.7 unterstützt.
SDK für developer zum lokalen Betrieb.
(Anscheinend konnte das für Hyper auch genutzt werden, ohne Gewähr.)

Zum Flash-/RAM Speicher:
Bei mir gleich kontrolliert.
Key und value von smartMode werden per json übertragen.

War natürlich auf 0 (Flash speichern).

per mqtt auf 1 gesetzt
(smartMode ist im Adapter nicht als Datenpunkt)

mqtt.x.iot.XXXXXX.yyyyyyyy.properties.write

{"properties":{"smartMode":1}}

Seit 3 Stunden läuft Steuerung wie zuvor.

Beobachte, ob der SmartMode bestehen bleibt oder öfter (bei jedem?) Schalten des acMode mit gesetzt werden soll/muss.

state wird mal per script überwacht.

Wenn das stimmt, sollte der Adapter den smartMode auch berücksichtigen oder den Datenpunkt zur Verfügung stellen(?).

danerix

@maxclaudi
@nograx
Ich denke ich habe das Problem gefunden.
Ich habe den Datenpunkt mal kopiert und das device von Groß- in Kleinschreibung kopiert.
Dann wurde das Debug-Log des Adapters getriggert; vorher kam ausser dem Startup nie was bei Aktualisierung der Datenpunkte.

Aber die Adapterwerte sind immer noch NULL.
Seltsamerweise steht dann im DebugLog nicht das kopierte Device mit der Kleinschreibung, sondern dann taucht im Pfad der mit der Großschreibung auf.

State "zendure-solarflow.0.BC8B7F.xxxxx.wifiState" has no existing object, this might lead to an error in future versions

Kannst du im Adapter statt der bc8b7f die BC8B7F eintragen?
Eventuell ist das schon alles...

nograx

@danerix sagte in Test Adapter Zendure Solarflow:

Kannst du im Adapter statt der bc8b7f die BC8B7F eintragen?

Ich habe die mal die Version v1.15.3-alpha.0 per npm bereit gestellt. Da ist für den local mode der angepasste product key drin. Musst du mal in den Einstellungen neu einbauen. Tatsächlich ist es so das ein mqtt topic case sensitive ist. Könntest also Recht haben...

maxclaudi

@danerix sagte in Test Adapter Zendure Solarflow:

@maxclaudi
@nograx
Ich denke ich habe das Problem gefunden.
Ich habe den Datenpunkt mal kopiert und das device von Groß- in Kleinschreibung kopiert.
Dann wurde das Debug-Log des Adapters getriggert;

verstehe ich nicht.

Kannst du im Adapter statt der bc8b7f die BC8B7F eintragen?
Eventuell ist das schon alles...

ist auch nicht regelkonform

maxclaudi

@nograx sagte in Test Adapter Zendure Solarflow:

@danerix sagte in Test Adapter Zendure Solarflow:

Kannst du im Adapter statt der bc8b7f die BC8B7F eintragen?

würde ich auch nicht.

Ich habe die mal die Version v1.15.3-alpha.0 per npm bereit gestellt. Da ist für den local mode der angepasste product key drin. Musst du mal in den Einstellungen neu einbauen. Tatsächlich ist es so das ein mqtt topic case sensitive ist. Könntest also Recht haben...

Warum nicht gleich richtig?
JSON ist case-sensitive (groß- und kleinschreibungsempfindlich), auch bei der Zendure API (z. B. beim lokalen HTTP‑Interface oder dem MQTT/REST-API) ist JSON case-sensitive, also groß- und kleinschreibungsempfindlich

nograx

@maxclaudi sagte in Test Adapter Zendure Solarflow:

Warum nicht gleich richtig?

Was meinst du mir "richtig"? Ich möchte das @danerix das mal testet bevor ich das allgemein zur Verfügung stelle. Risiko ist das es bei anderen Leuten aktuell mit dem kleingeschriebenen Key funktioniert - bei denen würde es dann kaputt sein...

maxclaudi

@nograx sagte in Test Adapter Zendure Solarflow:

Was meinst du mir "richtig"?....

Antwort steht mit in dem post :

@maxclaudi sagte in Test Adapter Zendure Solarflow:

JSON ist case-sensitive (groß- und kleinschreibungsempfindlich), auch bei der Zendure API (z. B. beim lokalen HTTP‑Interface oder dem MQTT/REST-API) ist JSON case-sensitive, also groß- und kleinschreibungsempfindlich

sorry, wenn sich das mit "richtig?" harsch lesen sollte, ist nicht so gemeint.
Nur als unverständliche Frage.

@nograx sagte in Test Adapter Zendure Solarflow:

Risiko ist das es bei anderen Leuten aktuell mit dem kleingeschriebenen Key funktioniert - bei denen würde es dann kaputt sein...

Davon ging ich nicht aus, weil JSON immer case-sensitive ist.
Wenn es anders auch mal funktioniert, ok. Konform ist es nicht :man-shrugging:

maxclaudi

@nograx sagte in Test Adapter Zendure Solarflow:

Was meinst du mir "richtig"? I

product key richtig setzen. Weiß nicht, welche Zeichen vom product key: bc8b7f
Groß- oder klein sind. Kenne den key nicht, aber @danerix könnte ihn mitteilen.
Wird im mqtt-Client-Adapter angelegt oder per MQTT Explorer.
Ist ja kein top secret key.

maxclaudi

@nograx

kenne Deinen Code nicht, jedoch bei settings.tsx 1.15.3-alpha

const productKeys: { value; title }[] = [
  { value: "73bkTV", title: "HUB 1200 (73bkTV)" },
  { value: "A8yh63", title: "HUB 2000 (A8yh63)" },
  { value: "yWF7hV", title: "AIO 2400 (yWF7hV)" },
  { value: "ja72U0ha", title: "Hyper 2000 (ja72U0ha)" },
  { value: "gDa3tb", title: "Hyper 2000 (gDa3tb)" },
  { value: "8bM93H", title: "Ace 1500 (8bM93H)" },
  { value: "BC8B7F", title: "SolarFlow 2400 AC (BC8B7F)" },
  { value: "b1nhmc", title: "SolarFlow 800 (b1nhmc)" },
];

sieht es doch gut aus, bis auf:
SolarFlow 2400AC hat hier nur Großschreibung
Solarflow 800 nur Kleinschreibung.

Am Ende müsste nur sicher sein, dass dies auch die richtigen productId (Groß-Kleinbuchstaben) für die 2 Geräte sind.
Bei den anderen kann dann doch nichts kaputt gehen, weil die productKeys doch case-sensitive hier stimmen?
Oder kommt das noch öfter im Code vor?

@danerix
schreib hier mal bitte die productId case-sensitive oder direkt an @nograx.

nograx

@maxclaudi sagte in Test Adapter Zendure Solarflow:

@nograx

kenne Deinen Code nicht, jedoch bei settings.tsx 1.15.3-alpha
const productKeys: { value; title }[] = [
  { value: "73bkTV", title: "HUB 1200 (73bkTV)" },
  { value: "A8yh63", title: "HUB 2000 (A8yh63)" },
  { value: "yWF7hV", title: "AIO 2400 (yWF7hV)" },
  { value: "ja72U0ha", title: "Hyper 2000 (ja72U0ha)" },
  { value: "gDa3tb", title: "Hyper 2000 (gDa3tb)" },
  { value: "8bM93H", title: "Ace 1500 (8bM93H)" },
  { value: "BC8B7F", title: "SolarFlow 2400 AC (BC8B7F)" },
  { value: "b1nhmc", title: "SolarFlow 800 (b1nhmc)" },
];
sieht es doch gut aus, bis auf:
SolarFlow 2400AC hat hier nur Großschreibung
Solarflow 800 nur Kleinschreibung.

Am Ende müsste nur sicher sein, dass dies auch die richtigen productId (Groß-Kleinbuchstaben) für die 2 Geräte sind.
Bei den anderen kann dann doch nichts kaputt gehen, weil die productKeys doch case-sensitive hier stimmen?
Oder kommt das noch öfter im Code vor?

@danerix
schreib hier mal bitte die productId case-sensitive oder direkt an @nograx.

Ich habe das heute morgen für die prerelease Version in Großschreibung geändert, da der Key wohl tatsächlich komplett groß geschrieben wird. Vorher war alles klein geschrieben.

@danerix bitte einmal die Prelease Version per npm installieren und Feedback geben.

Daniel 8

@maxclaudi sagte in Test Adapter Zendure Solarflow:

@daniel-8 sagte in Test Adapter Zendure Solarflow:

ZU der 2.ten Frage bezüglich Schreibvorgänge auf dem Speicher kannst du dazu eine Aussage machen?

@nograx sagte in Test Adapter Zendure Solarflow:

Zum Thema Schreibzugriff auf Speicher habe ich keine Infos. Mich würde es aber schockieren..

@nograx
gebe es mal (übersetzt) weiter.
Die Mitteilung stammt von einem developer der Kontakt zu Zendure hat:

Zitat:
developer:

Da der Hyper2000 Kommunikationsprobleme hat, fragte ich, ob der AC-Modus eine alternative Lösung sein könnte. Zendure antwortete daraufhin:

zendure:

Von den Kollegen aus der Geräteentwicklung habe ich erfahren, dass sich die Steuerung über den AC-Modus von der über das AutoModeProgram unterscheidet. Im AC-Modus wird die Stromversorgung in den Flash geschrieben. Werden alle 2 Sekunden Befehle ausgegeben, ist der Flash schnell voll, was zu Gerätestörungen führt.

developer:

Ich hielt es für wichtig, dies mitzuteilen, um zukünftige Enttäuschungen zu vermeiden. Jeder kann selbst entscheiden, ob er etwas damit anfangen möchte, mich stört das überhaupt nicht.

Auf Nachfrage war die Folgeantwort:

zendure:

Bei jedem Wechsel des Ausgabemodus wird der Speicher in den Flash-Speicher geschrieben. Warum? Dadurch soll sichergestellt werden, dass das Gerät nach einem Stromausfall den letzten Zustand beibehält. Die neuen 2025-Produkte verfügen über die Eigenschaft „smartMode“. Sobald der Wert 1 ist, wird die AC-Modus-Einstellung nicht mehr in den Flash-Speicher geschrieben, wodurch die Lebensdauer des Flash-Speichers deutlich verlängert wird.

Daher ist bei der Verknüpfung im CT-Modus der Smartmode auf 1 eingestellt, und der AC-Mode kann wiederholt gesetzt werden, um einen Ausgleich zwischen der gesamten Energieaufnahme und -abgabe des Haushalts zu erreichen.

Den Wahrheitsgehalt der Mitteilung kann ich nicht überprüfen.

Es gibt ein Zendure Lokales Steuerungssystem das den SolarFlow 800 in der Firmwareversion 1.1.7 unterstützt.
SDK für developer zum lokalen Betrieb.
(Anscheinend konnte das für Hyper auch genutzt werden, ohne Gewähr.)

Zum Flash-/RAM Speicher:
Bei mir gleich kontrolliert.
Key und value von smartMode werden per json übertragen.

War natürlich auf 0 (Flash speichern).

per mqtt auf 1 gesetzt
(smartMode ist im Adapter nicht als Datenpunkt)

mqtt.x.iot.XXXXXX.yyyyyyyy.properties.write
{"properties":{"smartMode":1}}
Seit 3 Stunden läuft Steuerung wie zuvor.

Beobachte, ob der SmartMode bestehen bleibt oder öfter (bei jedem?) Schalten des acMode mit gesetzt werden soll/muss.

state wird mal per script überwacht.

Wenn das stimmt, sollte der Adapter den smartMode auch berücksichtigen oder den Datenpunkt zur Verfügung stellen(?).

Also sehe ich das richtig, wenn wir den SetOutputLimit setzen, das es jedes mal in den Flash Speicher schreibt, was ja nicht so toll wäre, da man dann darauf warten kann bis er ausfällt.

nograx

@daniel-8 sagte in Test Adapter Zendure Solarflow:

Also sehe ich das richtig, wenn wir den SetOutputLimit setzen, das es jedes mal in den Flash Speicher schreibt, was ja nicht so toll wäre, da man dann darauf warten kann bis er ausfällt.

Also dazu mal folgendes:

Würde ich Aussagen von irgendwelchen Mitarbeitern immer mir Vorsicht genießen. Die Frage ist ja woher diese Aussage kommt.
Ist hier klar davon die Rede von 'Bei jedem Wechsel des Ausgabemodus wird der Speicher in den Flash-Speicher geschrieben.', was bedeutet das das nur passiert wenn der AC Modus von Laden auf Entladen umgestellt wird, bzw. von Entladen auf Laden. Somit betrifft das nur den Hyper, SF 800 und 2400 AC und dann auch nur wenn per AC geladen wird. Bedeutet also nach der Aussage das es NICHT passiert wenn das outputLimit geändert wird. Der AC Modus wird ja auch nicht permanent hin und her geschaltet.
Wenn im "offiziellen" CT Modus gefahren wird, wird ja auch sekündlich das outputLimit angepasst.
Smart Mode baue ich gerne mit ein. Ich tue mich damit schwer, da mir nicht klar ist was da im Hintergrund passiert. Habe es bei mir heute auch mal getestet und keinerlei Änderung im Verhalten des Gerätes feststellen können.

Daniel 8

@nograx sagte in Test Adapter Zendure Solarflow:

@daniel-8 sagte in Test Adapter Zendure Solarflow:

Also sehe ich das richtig, wenn wir den SetOutputLimit setzen, das es jedes mal in den Flash Speicher schreibt, was ja nicht so toll wäre, da man dann darauf warten kann bis er ausfällt.

Also dazu mal folgendes:

Würde ich Aussagen von irgendwelchen Mitarbeitern immer mir Vorsicht genießen. Die Frage ist ja woher diese Aussage kommt.

Ist hier klar davon die Rede von 'Bei jedem Wechsel des Ausgabemodus wird der Speicher in den Flash-Speicher geschrieben.', was bedeutet das das nur passiert wenn der AC Modus von Laden auf Entladen umgestellt wird, bzw. von Entladen auf Laden. Somit betrifft das nur den Hyper, SF 800 und 2400 AC und dann auch nur wenn per AC geladen wird. Bedeutet also nach der Aussage das es NICHT passiert wenn das outputLimit geändert wird. Der AC Modus wird ja auch nicht permanent hin und her geschaltet.

Wenn im "offiziellen" CT Modus gefahren wird, wird ja auch sekündlich das outputLimit angepasst.

Smart Mode baue ich gerne mit ein. Ich tue mich damit schwer, da mir nicht klar ist was da im Hintergrund passiert. Habe es bei mir heute auch mal getestet und keinerlei Änderung im Verhalten des Gerätes feststellen können.

zu 2) auch der SF 800 Pro der kann ja auch AC laden

zu 3) ja das stimmt und da sieht man ja im Adapter das jedes mal das Output Limit angepasst wird.

Was zeigt denn der Smart Mode bei dir an bzw. welches Gerät hast du denn? Es war doch irgendwie die Rede davon das es nur bei Geräten ab 2025 so ist.
Dann müsste ja wenn man mit dem Adapter den Smartmode ausliest auch auf 1 stehen wenn man im CT Modus ist oder?

maxclaudi

@daniel-8 sagte in Test Adapter Zendure Solarflow:

Also sehe ich das richtig, wenn wir den SetOutputLimit setzen, das es jedes mal in den Flash Speicher schreibt, was ja nicht so toll wäre, da man dann darauf warten kann bis er ausfällt.

Das weiß ich bei "setOutputLimit" nicht.
Bei der Konversation ging es um einen Hyper der nicht mehr richtig funktionierte.
Es waren Kommunikationsprobleme vorhanden.
Erst im Verlauf (Fehlersuche, mögliche alternative Steuerung usw) mit zendure kam die Info eher zufällig.

Es betrifft (bis jetzt) auf jeden Fall den acMode.
Das Umschalten zwischen den acModi (Laden/Entladen).

Ob und welche Modi und evtl. Keys sonst noch betroffen sind, ist mir nicht bekannt.

Nicht zu viel Angst haben.

Wenn "SetOutputLimit" auch betroffen ist, dann wird das auch von Zendure (über die Cloud) in den Flash geschrieben, außer beim gewählten CT-Modus.

Beim CT-Modus wird smartMode: 1 gesetzt und Werte ins RAM geschrieben.

Die Aussage, dass bei smartMode:1 ins RAM statt ins Eeprom geschrieben wird, ist von zendure vorhanden.

Was alles ins RAM statt ins Eeprom geschrieben wird -> mir unbekannt.

RAM ist auf jeden Fall besser als Eeprom.

Bin cloudeless auf lokalem Broker und steuere alles mit scripts.
autoModel (Energieplan): 0
Seit >16 Stunden smartMode: 1
Alles funktioniert, wie bisher - ohne feststellbare Einschränkungen, fehlerfrei.

Das habe ich gemacht, weil ich RAM vorziehe, RAM schneller ist und nicht weil ich Angst habe dass meine Zendure-Geräte frühzeitig ausfallen.
Obwohl ein zu häufiges Beschreiben eines Eeprom dazu führen könnte.

In meinen Scripts wird schon mal öfters am Tag der acMode gewechselt mit ACE1500 Netz laden.

@nograx sagte in Test Adapter Zendure Solarflow:

@daniel-8 sagte in Test Adapter Zendure Solarflow:

Also sehe ich das richtig, wenn wir den SetOutputLimit setzen, das es jedes mal in den Flash Speicher schreibt, was ja nicht so toll wäre, da man dann darauf warten kann bis er ausfällt.

Also dazu mal folgendes:

Würde ich Aussagen von irgendwelchen Mitarbeitern immer mir Vorsicht genießen. Die Frage ist ja woher diese Aussage kommt.

Ist hier klar davon die Rede von 'Bei jedem Wechsel des Ausgabemodus wird der Speicher in den Flash-Speicher geschrieben.', was bedeutet das das nur passiert wenn der AC Modus von Laden auf Entladen umgestellt wird, bzw. von Entladen auf Laden. Somit betrifft das nur den Hyper, SF 800 und 2400 AC und dann auch nur wenn per AC geladen wird. Bedeutet also nach der Aussage das es NICHT passiert wenn das outputLimit geändert wird. Der AC Modus wird ja auch nicht permanent hin und her geschaltet.

Wenn im "offiziellen" CT Modus gefahren wird, wird ja auch sekündlich das outputLimit angepasst.

Smart Mode baue ich gerne mit ein. Ich tue mich damit schwer, da mir nicht klar ist was da im Hintergrund passiert. Habe es bei mir heute auch mal getestet und keinerlei Änderung im Verhalten des Gerätes feststellen können.

zu 1)
sehe ich auch so.
Die Info ist zumindest mal da.

zu 2) möchte ich hinzufügen, dass ich einen ACE1500 habe und der schaltet in meinem script schon mal, mehrmals am Tag, den acMode um. Je nach PV-Leistung und electricLevel etc. wird vom Netz geladen.
Es sind also nicht nur Hyper und Co. betroffen.

zu 3)
im CT-Modus wird smatMode:1 gesetzt und ins RAM geschrieben.
Müsste leicht am key feststellbar sein.
Was alles ins RAM statt Eeprom geschrieben wird -> mir unbekannt. (siehe oben).

Daniel 8

@maxclaudi Was meinst du unter 3 mit Key feststellbar sein? wie kann ich das feststellen. Das hier ist für mich auch alles neuland.

maxclaudi

@daniel-8 sagte in Test Adapter Zendure Solarflow:

@maxclaudi Was meinst du unter 3 mit Key feststellbar sein? wie kann ich das feststellen. Das hier ist für mich auch alles neuland.

wenn Du in der Cloud bist, kein mqtt-Client hast und @nograx im Adapter den Datenpunkt: smartMode nicht anbietet, kannst Du ihn auch nicht sehen.
Das feststellbar war für @nograx und Alle die cloudless sind.

Daniel 8

@maxclaudi Danke für die Infos. Ja noch läuft alles über Cloud. Aber vielleicht finde ich eher im Winter mal die Zeit dazu das ganze auf komplett Lokal mit mqtt umzustellen. In der Sommerzeit hat man da immer nicht soviel Zeit. Ist aufjedenfall ein sehr interessantes Thema hier.
Ich muss mir dann auch noch überlegen wie ich die ganze Steuerung mache

maxclaudi

@nograx sagte in Test Adapter Zendure Solarflow:

Smart Mode baue ich gerne mit ein. Ich tue mich damit schwer, da mir nicht klar ist was da im Hintergrund passiert. Habe es bei mir heute auch mal getestet und keinerlei Änderung im Verhalten des Gerätes feststellen können.

Das ist eine gute Frage, was im Hintergund passieren würde.

sehr wahrscheinlich:
Lokal: ohne Energieplan passiert da nichts.

Cloud: da wird dann der smartMode automatisch, wie bisher umgeschaltet.
Zumindest beim Wechsel der Einstellung des Energieplans wird der smartMode bei CT-Mode-Auswahl auf 1 gesetzt und bei den anderen Einstellungen auf 0.

Wenn der dann manuell als Datenpunkt umschaltbar/setzbar wäre, dann gibt es m. M. nicht viele Szenarien:

Entweder der Wert bleibt beim neu gesetzten Wert bis wieder ein Wechel automatisch durch manuelle Auswahl eines anderen Energieplans erfolgt.
Der manuell neu gesetzte Wert im Datenpunkt wird (nach einer Weile oder sofort) wieder automatisch zurückgesetzt
der Wert lässt sich nicht setzen (und/oder ändert sich sofort wieder, wie bei @Daniel-8 als er versuchte das outputLimit im Bypass zu setzen, oder weil nicht richtiger Energieplan etc.)

edit/ps:
Wenn der Datenpunkt smartMode nur änderbar und dauerhaft bei autoModel (Energieplan) 0 (nothing) wäre, dann könnte man die Datenpunktänderung auch nur zulassen bzw. abhängig von:
lokal: immer
cloud: nur bei autoModel:0

Alles Spekulation, das könnte doch nach und nach getestet werden, falls eine "nicht" offiziell freigegebene alpha-Test-Version bereit stellen möchtest.

Sind nun mal Test-Versionen und nicht für garantierten, funktionierenden, sofortigen Einsatz.
Kann das für mich nicht testen, außer cloudless.
Aber bei mir läufts ja schon über mqqt gesetzt und überwacht.

@daniel-8 sagte in Test Adapter Zendure Solarflow:

In der Sommerzeit hat man da immer nicht soviel Zeit.

Die sollte man sich nehmen
Gerade Frühjahr/Sommer/Herbst bietet sich es an zum testen, auch wenn man nicht die Zeit dafür hat.
Bei den Temperaturen sind die Batterien sicher, die Sonne ist gut und lange vorhanden und man kann nahezu gefahrlos testen.

romestylez

@nograx folgende Frage:

Ich nutze teilweise den ByPass Modus welcher aber nicht immer zuverlässig funktioniert. Nun gibt es ja in der App beim Hub2000 den "Intelligenter Abgleichmodus". Den kann ich per ioBroker ja auch steuern unter "control". Gibt es eine Möglichkeit die Grundlast ebenfalls dynamisch zu steuern in dem man diese Option ebenfalls unter "control" hinzufügt ?

Ich würde nämlich die Grundlast gerne auf den Wert setzen den die beiden Paneele welche ohne Hub laufen gerade liefern. So könnte ich das lästige Abschalten vom ByPass umgehen.

NEWS

Test Adapter Zendure Solarflow

Support us

509

32.4k

81.4k

1.3m