Test Adapter Zendure Solarflow

[romestylez]

Ich nutzen den Adapter seit ~2 Wochen in der Version 1.6.4

Über ein Blockly Script will ich den Wert "minSoc" von 10 auf 50 setzen. Das funktioniert auch soweit ich das sehen kann. Öffne ich allerdings die App und prüfe dort den Wert für die Entladegrenze wird der Wert mit 10 angezeigt und auch im Datenpunkt steht wieder 10.

Ich habe bereits die Option "Bestätigt" probiert aber keine Änderung. Ich muss dazu sagen das dies mein erstes Blockly Script ist und ich eventuell auch einfach was falsch mache.

<xml xmlns="https://developers.google.com/blockly/xml">
  <block type="schedule" id="BWktR#:+NRaQ%Yxf!|{;" x="38" y="112">
    <field name="SCHEDULE">00 04 * * *</field>
    <statement name="STATEMENT">
      <block type="update" id=")k[Tms16Z5EAR8h[p)RR">
        <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="false"></mutation>
        <field name="OID">zendure-solarflow.0.A8yh63.2T8b4PkK.minSoc</field>
        <field name="WITH_DELAY">FALSE</field>
        <value name="VALUE">
          <block type="math_number" id="/Gs6iAM++fI[RbBzp15]">
            <field name="NUM">50</field>
          </block>
        </value>
      </block>
    </statement>
  </block>
</xml>

[Rene55]

@romestylez Wenn ich den Adapter richtig verstanden habe, müsstes du dazu einen Datenpunkt aus der Sektion 'control' verwenden. Ich denke, hier

zendure-solarflow.0.73bkTV.YpbX6abcd.control.dischargeLimit

bist du mit 'steuere' eher richtig.

[BennoBaer]

@nograx Guten Abend,

vielen Dank für das Update.

Ich wollte aber nochmal kurz zu meinem Status mit dem HMS 1800 4T berichten.

Nachdem ich gestern die Anker Solix 1600 für das 5te und 6te PV Modul angeschlossen habe, musste ich auch feststellen, dass auch hier das gleiche Problem mit Leistungen unter 100W gibt. Erst nachdem ich die Anker Solix auf nur einem statt auf zwei Beinen mit den Hoymiles 1800 4T verbunden habe klappt dies hier einwandfrei.

Also erster funktionale Zwischenschritt ist den PV HUB 2000 sowie die Anker Solix auf je einem Bein bei der Hoymiles 1800 4T. Wehrmutstropfen bleibt die maximale Leistung von 475W pro Eingang des Hoymiles.

Nachdem ich jetzt die Zendure Lösung und die von Anker gleichzeitig verwende (PV Modul 1-4 auf Zendure und 5-6 auf Anker) gefällt mir die Lösung von Zendure deutlich besser. Wenn gewünscht kann ich gerne mehr Infos zu den Unterschieden posten.

Was ich bei der Kombination Zendure <-> Hoymiles als unglücklich empfinde ist die Trägheit bei einer Änderung. Wenn ich die Leistung von z.B. 150W auf 450 StAnpasse dauert das zwischen ca. 45 Sekunden. Gleiches bei der Reduzierung. Weiß einer von Euch ob das am Hoymiles liegt und wenn dies der Grund ist, welcher WR ist schneller ?

Herzliche Grüße
Bernd

[romestylez]

@rene55 said in Test Adapter Zendure Solarflow:

@romestylez Wenn ich den Adapter richtig verstanden habe, müsstes du dazu einen Datenpunkt aus der Sektion 'control' verwenden. Ich denke, hier

zendure-solarflow.0.73bkTV.YpbX6abcd.control.dischargeLimit

bist du mit 'steuere' eher richtig.

Die Control Werte hatte ich gar nicht gesehen Ich habe jetzt mal den Control DP auf 50% gesetzt über mein Script. Sobald ich aber die App öffne und nachschaue springt der DP auf 10% oder welcher Wert auch immer vorher eingestellt war.

[lesiflo]

Moin,
ich habe seit einiger Zeit immer mal wieder diese Meldungen hier im Log:

zendure-solarflow.0
2024-06-17 06:53:36.380	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 06:53:36.380	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 06:53:36.379	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 06:53:36.379	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 06:53:36.261	error	Connection to MQTT failed! Error: ErrorWithReasonCode: Connection refused: Client Identifier not valid

zendure-solarflow.0
2024-06-17 03:53:36.057	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 03:53:36.057	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 03:53:36.044	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 03:53:36.043	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 03:53:36.039	error	Connection to MQTT failed! Error: ErrorWithReasonCode: Connection refused: Client Identifier not valid

zendure-solarflow.0
2024-06-17 03:53:36.038	error	Connection to MQTT failed! Error: ErrorWithReasonCode: Connection refused: Client Identifier not valid

zendure-solarflow.0
2024-06-17 02:39:50.364	error	Connection to MQTT failed! Error: Error: read ECONNRESET

zendure-solarflow.0
2024-06-17 00:53:35.734	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 00:53:35.731	error	Subscription to MQTT failed! Error: Error: Connection closed

Was kann der Grund dafür sein? Der Adapter bleibt aber grün.
Bin auf Version 1.6.4

[romestylez]

@lesiflo said in Test Adapter Zendure Solarflow:

Moin,
ich habe seit einiger Zeit immer mal wieder diese Meldungen hier im Log:

zendure-solarflow.0
2024-06-17 06:53:36.380	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 06:53:36.380	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 06:53:36.379	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 06:53:36.379	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 06:53:36.261	error	Connection to MQTT failed! Error: ErrorWithReasonCode: Connection refused: Client Identifier not valid

zendure-solarflow.0
2024-06-17 03:53:36.057	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 03:53:36.057	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 03:53:36.044	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 03:53:36.043	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 03:53:36.039	error	Connection to MQTT failed! Error: ErrorWithReasonCode: Connection refused: Client Identifier not valid

zendure-solarflow.0
2024-06-17 03:53:36.038	error	Connection to MQTT failed! Error: ErrorWithReasonCode: Connection refused: Client Identifier not valid

zendure-solarflow.0
2024-06-17 02:39:50.364	error	Connection to MQTT failed! Error: Error: read ECONNRESET

zendure-solarflow.0
2024-06-17 00:53:35.734	error	Subscription to MQTT failed! Error: Error: Connection closed

zendure-solarflow.0
2024-06-17 00:53:35.731	error	Subscription to MQTT failed! Error: Error: Connection closed

Was kann der Grund dafür sein? Der Adapter bleibt aber grün.
Bin auf Version 1.6.4

Die Fehler habe ich seit 3-4 Tagen ebenfalls relativ regelmäßig im Log. Dachte schon ist was auf meiner Seite.

[nordstern19_72]

Hallo,
ich nutze diesen Adapter seid der latest Version 1.6.2. Erstmal Danke für die klasse Arbeit!

Nachdem Wechsel auf die neuste stable 1.6.4 kamen auch die Fehlermeldungen wie bei beiden Vor-Postern.
Heute gab es allerdings noch einen Adapter-Crash obendrauf.

host.SER1010
2024-06-17 19:06:23.576	info	instance system.adapter.zendure-solarflow.0 started with pid 103823
host.SER1010
2024-06-17 19:05:53.385	info	Restart adapter system.adapter.zendure-solarflow.0 because enabled
host.SER1010
2024-06-17 19:05:53.385	info	instance system.adapter.zendure-solarflow.0 terminated with code null ()
host.SER1010
2024-06-17 19:05:53.385	warn	instance system.adapter.zendure-solarflow.0 terminated due to SIGABRT
host.SER1010
2024-06-17 19:05:53.385	error	Caught by controller[9]: 16: 0x17126f9 [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.385	error	Caught by controller[8]: 15: 0xdeef37 v8::internal::Builtin_DateConstructor(int, unsigned long*, v8::internal::Isolate*) [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.385	error	Caught by controller[7]: 14: 0x115edf5 v8::internal::JSDate::New(v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::JSReceiver>, double) [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.385	error	Caught by controller[6]: 13: 0xf18ce5 v8::internal::Handle<v8::internal::HeapNumber> v8::internal::FactoryBase<v8::internal::Factory>::NewHeapNumber<(v8::internal::AllocationType)0>() [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.385	error	Caught by controller[5]: 12: 0xf17554 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawWithImmortalMap(int, v8::internal::AllocationType, v8::internal::Map, v8::internal::AllocationAlignment) [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.385	error	Caught by controller[4]: 11: 0xf1fae0 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.385	error	Caught by controller[3]: 10: 0xf3f567 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.385	error	Caught by controller[3]: 9: 0xf3e19e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.385	error	Caught by controller[3]: 8: 0xf63848 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.385	error	Caught by controller[3]: 7: 0xf629d3 [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.384	error	Caught by controller[3]: 6: 0xf524d8 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.384	error	Caught by controller[3]: 5: 0xf515d5 [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.384	error	Caught by controller[3]: 4: 0xd74257 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.384	error	Caught by controller[2]: 3: 0xd73eb0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.384	error	Caught by controller[1]: 2: 0xaa27ee [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.384	error	Caught by controller[1]: 1: 0xb9c310 node::Abort() [io.zendure-solarflow.0]
host.SER1010
2024-06-17 19:05:53.384	error	Caught by controller[0]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
host.SER1010
2024-06-17 19:05:53.384	error	Caught by controller[0]: <--- JS stacktrace --->
host.SER1010
2024-06-17 19:05:53.384	error	Caught by controller[0]: [92878:0x6c698b0] 205613926 ms: Mark-sweep 2004.3 (2082.3) -> 1988.5 (2082.8) MB, 3604.7 / 0.0 ms (average mu = 0.121, current mu = 0.067) allocation failure; scavenge might not succeed
host.SER1010
2024-06-17 19:05:53.384	error	Caught by controller[0]: [92878:0x6c698b0] 205610063 ms: Mark-sweep 2003.8 (2081.8) -> 1988.0 (2082.3) MB, 3465.9 / 0.0 ms (average mu = 0.173, current mu = 0.086) allocation failure; scavenge might not succeed
host.SER1010
2024-06-17 19:05:53.383	error	Caught by controller[0]: <--- Last few GCs --->

zendure-solarflow.0
2024-06-17 19:02:54.246	info	[startRefreshAccessTokenTimerJob] Refreshing accessToken!

zendure-solarflow.0
2024-06-17 19:02:54.245	info	[startRefreshAccessTokenTimerJob] Refreshing accessToken!

Nach unzähligen Einträgen "Refreshing accessToken" davor, dann der Crash ab 19:05:53

Bin erstmal zurück auf die 1.6.2 und beobachte weiter.

Gruß
Nordstern

[diet99]

@nordstern19_72 Habe gerade mal bei mir geschaut, da gibt’s diese Access Token Errors in Massen:

Deine Meldungen kann ich so auf Anhieb nicht nachvollziehen.
Habe ebenfalls kürzlich auf 1.6.4 aktualisiert.

[The_Stig]

Same here...Fehler ohne Ende...

[nograx]

Ich habe in der letzten Version einen Check mit eingebaut der die Verbindung neu aufbaut wenn vom Zendure MQTT keine Daten mehr kommen. Beim Neuaufbau der Verbindung erscheinen dann diese Meldungen, vermutlich weil die "tote" Verbindung dann gekappt wird - der Adapter liefert zu dem Zeitpunkt aber wieder Daten. Zumindest ist das bei mir so.

Das ist halt leider auch etwas was ich schlecht debuggen und testen kann - ich muss ja beim testen darauf hoffen das der MQTT von Zendure wieder spinnt

[nograx]

@stormy27 The MQTT connection from the ioBroker Adapter is Client only - so you can't connect to it. I think you have to build you own solution to control things. Like setting up an mqtt host on your ioBroker instance and connect to it from your HA instance - and then use some logic to set the parameters on the adapter.

[romestylez]

@nograx kannst du hier eventuell helfen ?

Ich nutzen den Adapter seit ~2 Wochen in der Version 1.6.4

Über ein Blockly Script will ich den Wert "zendure-solarflow.0.A8yh63.2T8b4PkK.minSoc" von 10 auf 50 setzen. Das funktioniert auch soweit ich das sehen kann. Öffne ich allerdings die App und prüfe dort den Wert für die Entladegrenze wird der Wert mit 10 angezeigt und auch im Datenpunkt steht wieder 10.

Ich habe bereits die Option "Bestätigt" probiert aber keine Änderung. Ich muss dazu sagen das dies mein erstes Blockly Script ist und ich eventuell auch einfach was falsch mache.

<xml xmlns="https://developers.google.com/blockly/xml">
  <block type="schedule" id="BWktR#:+NRaQ%Yxf!|{;" x="38" y="112">
    <field name="SCHEDULE">00 04 * * *</field>
    <statement name="STATEMENT">
      <block type="update" id=")k[Tms16Z5EAR8h[p)RR">
        <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="false"></mutation>
        <field name="OID">zendure-solarflow.0.A8yh63.2T8b4PkK.minSoc</field>
        <field name="WITH_DELAY">FALSE</field>
        <value name="VALUE">
          <block type="math_number" id="/Gs6iAM++fI[RbBzp15]">
            <field name="NUM">50</field>
          </block>
        </value>
      </block>
    </statement>
  </block>
</xml>

Ich habe auch bereits den Wert in "zendure-solarflow.0.73bkTV.YpbX6abcd.control.dischargeLimit" angepasst das Problem bleibt bestehen. Sobald ich die App öffne wird der Wert überschrieben wie kann ich also über den Adapter den das Entladelimit steuern ?

[nograx]

@romestylez zuerst würde ich mal versuchen die Entladegrenze manuell im Datenpunk zu setzen, um Probleme mit dem Blockly auszuschließen.

Ich habe das jetzt bei mir mal getestet und auch festgestellt das der Wert in der App (iPhone) bestehen bleibt. Ich habe manuell im Datenpunkt unter "control" vom Adapter von 6% auf 5% geändert - in der App steht weiterhin 6%. Die Daten der Api sagen aber 5%. !! Wenn ich jetzt die App manuell schließe und neu öffne steht da der korrekte Wert 5%! Für mich sieht das so aus als wäre das ein Anzeigefehler der App...

[romestylez]

@nograx ich habe den Wert bereits manuell gesetzt z.B. von 10% auf 45% ich öffne dann meine App gehe dort auf die Entladegrenze und sehe dann dort aber wieder 10% auch im Datenpunkt sehe ich wieder 10%

[romestylez]

@nograx ich habe jetzt noch mal getestet (die App hat ja heute/gestern) ein Update bekommen. Und nun geht es ohne jegliche Probleme der Wert aktualisiert sich sogar in Echtzeit in meiner App Ich schaue dann jetzt mal das ich es im Blockly auch umgesetzt bekomme denn da wird der Wert mit dem Wert aus der App überschrieben.

Vielen Dank dir für den coolen Adapter !

[diet99]

@romestylez ja, die haben offenbar das Echtzeitverhalten der App massiv optimiert. Bisher mußt man immer auf dem Startbildschirm einen Refresh machen (runterziehen), um Aktualisierungen auf den folgenden Screens zu bekommen. Auch die Energiefluß-Anzeige ist jetzt viel schneller da und aktuell.

Auch von meiner Seite ein großes Dankeschön an @nograx für die prompten Antworten auf Anfragen. Hier läuft der Adapter ebenfalls super.

[romestylez]

@diet99 said in Test Adapter Zendure Solarflow:

@romestylez ja, die haben offenbar das Echtzeitverhalten der App massiv optimiert. Bisher mußt man immer auf dem Startbildschirm einen Refresh machen (runterziehen), um Aktualisierungen auf den folgenden Screens zu bekommen. Auch die Energiefluß-Anzeige ist jetzt viel schneller da und aktuell.

Auch von meiner Seite ein großes Dankeschön an @nograx für die prompten Antworten auf Anfragen. Hier läuft der Adapter ebenfalls super.

Ja da wurde auf jeden Fall etwas optimiert. Folgendes Blockly verwende ich nun um das Entladelimit auf 50% zu setzen. Mein Ziel ist einfach das wenn der Speicher morgens sehr leer ist er erst mal geladen wird. Ich werde das Blockly noch erweitern damit wenn der Wert der Batterie 50% erreicht hat er das Entladelimit wieder auf 10% setzt. So kann ich zumindest etwas den Akku Prioritätsmodus simulieren und trotzdem mein Shelly 3EM Pro nutzen.

<block xmlns="https://developers.google.com/blockly/xml" type="schedule" id="BWktR#:+NRaQ%Yxf!|{;" x="-662" y="-212">
  <field name="SCHEDULE">0 4 * * *</field>
  <statement name="STATEMENT">
    <block type="control" id="LX;tUWce2j,@LQz4JSJ5">
      <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="false"></mutation>
      <field name="OID">zendure-solarflow.0.A8yh63.2T8b4PkK.control.dischargeLimit</field>
      <field name="WITH_DELAY">FALSE</field>
      <value name="VALUE">
        <block type="math_number" id="/Gs6iAM++fI[RbBzp15]">
          <field name="NUM">50</field>
        </block>
      </value>
    </block>
  </statement>
</block>

[diet99]

@romestylez said in Test Adapter Zendure Solarflow:

Folgendes Blockly verwende ich nun um das Entladelimit auf 50% zu setzen. Mein Ziel ist einfach das wenn der Speicher morgens sehr leer ist er erst mal geladen wird. Ich werde das Blockly noch erweitern damit wenn der Wert der Batterie 50% erreicht hat er das Entladelimit wieder auf 10% setzt. So kann ich zumindest etwas den Akku Prioritätsmodus simulieren und trotzdem mein Shelly 3EM Pro nutzen.

Das habe ich jetzt nicht 100%ig verstanden mit dem Entladelimit hochsetzen.

Ich habe es bei mir so gelöst, daß ich grundsätzlich ein Entladelimit von 15% verwende (im Sommer könnte man auch 10% nehmen) und bei Erreichen dieses Limits die Ausgabeleistung des SolarFlow auf 0 setze. Wenn wieder Solarenergie reinkommt, warte ich im Script ab, bis der Ladezustand 30% erreicht hat und prüfe dann, ob zusätzlich mindestens 250W Solarleistung anliegen. Erst dann schalte ich den Ausgang des SolarFlow wieder ein, und zwar auf die volle Leistung (in meinem Falle 900W, damit der Wechselrichter seine 800W komplett erreichen kann). Die Nulleinspeisung regle ich über eine OpenDTU-OnBattery am Wechselrichter.

[romestylez]

@diet99 ich habe einen Shelly 3EM Pro. Entladelimit ist 10%.

Wenn ich diese 10% nun erreiche wird geladen und bei 11% wieder entladen. Das will ich verhindern in dem ich prüfe wie der Ladestand ist. Wenn dieser 10% ist setze ich das Limit auf 50% damit erst mal geladen wird. Wenn 49% erreicht sind setze ich das Entladelimit wieder auf 10%.

Ob das alles Sinn macht weiß ich noch nicht. Ich spiele aber gerne rum und probiere neue Dinge aus. Dein Ansatz klingt auch ok ich habe einen Hoymiles WR mit max. 800 Watt was aber über den Shelly gesteuert wird.

[diet99]

@romestylez Ah - also exakt das gleiche Szenario wie bei mir. Nur anders gelöst Ich wollte ebenfalls dieses Einspeise-Ping-Pong bei niedrigem Akkustand vermeiden. Funktioniert hier sehr gut.