Test Adapter Zendure Solarflow

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.

nograx

Mein Ansatz dazu sieht etwas anders aus.

Wenn Solarleistung > 50 greift folgende Logik:

Wenn SOC unter 20% dann outputLimit auf 200 Watt + aktuelle Solarleistung.
Wenn SOC unter 10% dann outputLimit auf 100 Watt + aktuelle Solarleistung.
Wenn SOC >= 6% (Entladelimit) dann nur die aktuelle Solarleistung.

Final gibt der Wechselrichter dann die Leistung ab die im Haus benötigt wird (Hoymiles per AhoyDTU).

Das hat so den Vorteil das die Solarleistung schon mal direkt ins Haus geht und nicht mit Verlusten in die Akkus. Ein Ping Pong habe ich so auch nicht.

diet99

@nograx Oh - das ist noch etwas feiner gestaffelt. Gute Idee! Dann lädt man nicht erstmal grundsätzlich auf einen fixen Prozentwert auf. Lade/Entladeverluste vermeiden ist immer gut.
Kannst Du Dein Script bitte mal posten?

Ich mache halt über meinen Shelly (Lesekopf ginge genauso) und OpenDTU-OnBattery eine echte Nulleinspeisung. Seit November letzten Jahres habe ich glaube ich eine einzige kWh ins Netz verschenkt.

romestylez

Das Script wäre wirklich cool @nograx ich weiß aber nicht ob das bei mir funktioniert da der Shelly dauerhaft den Verbrauch übermittelt und darüber das outputLimit gesetzt wird.

@diet99 ja ich habe die Nulleinspeisung per Shelly 3PM Pro gelöst. Da geht immer mal wieder 40-100 Watt ins Netz wenn der Verbrauch große Schwankungen hat aber eigentlich läuft das wirklich sehr gut.

diet99

@romestylez said in Test Adapter Zendure Solarflow:

Das Script wäre wirklich cool @nograx

@diet99 ja ich habe die Nulleinspeisung per Shelly 3PM Pro gelöst. Da geht immer mal wieder 40-100 Watt ins Netz wenn der Verbrauch große Schwankungen hat aber eigentlich läuft das wirklich sehr gut.

Daher hab ich bei mir einen gewissen Netzbezug eingestellt. Ich glaube 25W. Leer wird der Akku sowieso, also macht das wenig aus. Besser, als zuviel ins Netz zu schubsen.

romestylez

@diet99 hast du auch einen Shelly 3PM Pro oder wie hast du das eingestellt ?

diet99

@romestylez said in Test Adapter Zendure Solarflow:

@diet99 hast du auch einen Shelly 3PM Pro oder wie hast du das eingestellt ?

Ganz genau:

NEWS

Test Adapter Zendure Solarflow

Support us

1.5k
Online

30.4k
Users

76.6k
Topics

1.2m
Posts

NEWS

Test Adapter Zendure Solarflow

Support us

1.5kOnline

30.4kUsers

76.6kTopics

1.2mPosts

1.5k
Online

30.4k
Users

76.6k
Topics

1.2m
Posts