@rene55 Jo ich denke das wird zeitnah passieren.
@ritter sagte in Test Adapter Zendure Solarflow:
@nograx Funktioniert hat es ja mit 2 oder 4 Parallel geschalteten Eingängen. Erst nach Tagen nicht mehr. Nachdem stoppen des Adapter gings dann wieder was aber auch noch zufällig sein kann, muss es erst mal noch länger testen. Auf der Zendure Homepage wird doch glaub ich der Hoymiles in Kombination mit verkauft.
Ja es wird dort ein Hoymiles verkauft, allerdings kein 1800 4T. Das Thema gab es allerdings schon in der Facebook Gruppe - und dort wurde genau diese Problematik bekannt gemacht.
@nograx Guten Abend,
als erstes möchte ich mich für den tollen Adapter in ioBrocker bedanken. Der funktioniert super, auch mit der EU Cloud. Ganz vielen Dank dafür, super Arbeit!
Ich habe jetzt folgendes im Zusammenspiel HUB 2000 mit Hoymiles 1800 4T festgestellt.
Da ich sechs Module auf dem Dach habe ist das keine so richtig schöne Lösung. Was meint Ihr, wird das Problem nochmal gefixt oder ist das eher unwahrscheinlich. ? Gibt es 4 Port Wandler die besser mit den HUB 2000 funktionieren ?
Herzliche Grüße
Bernd
@bennobaer Ich habe einen HM1500 am laufen - da geht es problemlos. Der hat 2 MPPT mit jeweils 2 Anschlüssen.
@bennobaer Ich denke das Problem wird wohl nie ganz beseitigt werden, dafür müsste Zendure die Hubausgänge einzeln regeln und nicht wie jetzt die Ausgange parralel schalten. Sie werden wahrscheinlich wenn sie es hinbekommen das schwingen der Ausgangsleistung des HUB durch mehr Trägheit (grössere Reaktionszeit) herabsetzen. Perfekt für das System wäre ein Mikrowechselrichter mit nur 1 Mppt und Max 1200W eingang bei kleiner MPPT eingangspannung. Wenn mehrere Mppts vorhanden sind werden Sie sich immer gegenseitig beeinflussen, dieser Effekt ist im Bereich <100 W Ausgangsleistung am stärksten ausgeprägt ( kleine Spannungs- oder Stromstärke änderungen am Eingang auf die jeder angeschlossene Mppt anders reagiert ) , deshalb hat Zendure diese 30, 60 und 90 Watt schritte bei kleiner 100W Ausgangsleistung eingeführt um das ganze in Griff zu kriegen.
@muppibaer Vielen Dank für die Rückmeldung !
Ich teste jetzt nochmal die Module 5 und 6 an eine Anker Solix anzuschließen, so dass von dort nur eine kleine/feste von 100 Watt zum Wandler kommt. und schließe den Anker Solix an Port 3 und 4 beim Hoymiles an.
An Port 1 und 2 ist der Hub 2000 angeschlossen.
Wenn das nicht richtig klappt werde ich den Hoymiles 1800 4T für kleines Geld bei eBay verkaufen und einen kleineren mit vier Eingängen und zwei MPPT nehmen.
Wenn gewünscht werde ich berichten.
@nograx Hi nograx! First thanks for your project and time on Zendure.
Need precision please: I'm having x3 Three Solarflow HUB1200 connected (need lot of energy! :), using currently the official MQTT Zendure MQTT data through Home Assistant. I can then collect ONLY data (NO control with setOutputLimit)
Then I discovered and installed your project. Using ioBroker environment and your latest tool release, I can collect data from my three Solarflow hubs. Everything is fine. I can manually control the setOutputLimit through ioBroken it's working.
Question:
But how to control from outside from ioBroker??
How to control this "setOutputLimit" object from a remote system ? Using MQTT?
Because I've checked and MQTT inside your project is fixed to 127.0.0.1 so I can't connect from remote server using MQTT. How to edit this parameter? How to collect ZENDURE values (inside ioBroker data objects) thanks to remote system?
(I'm using Home Assistant and already MQTT for official Zendure connection but without any control available)
Any help please? How to push those MQTT data to remote system? And to force setOutputLimit outside ioBroker GUI?
Thanks for your time and explanation! Have a nice week-end!
------------------ As it's a German forum section, here is the transcription:
@nograx Hallo nograx! Zuerst danke für dein Projekt und deine Zeit mit Zendure.
Ich benötige eine Präzisierung bitte: Ich habe drei Solarflow HUB1200 verbunden (brauche viel Energie! :), und verwende derzeit die offizielle Zendure MQTT-Datenübertragung über Home Assistant. Damit kann ich NUR Daten sammeln (KEINE Steuerung mit setOutputLimit).
Dann habe ich dein Projekt entdeckt und installiert. Mit der ioBroker-Umgebung und deinem neuesten Tool-Release kann ich Daten von meinen drei Solarflow-Hubs sammeln. Alles funktioniert einwandfrei. Ich kann manuell das setOutputLimit über ioBroker steuern, es funktioniert.
Frage:
Aber wie kann ich von außerhalb von ioBroker steuern??
Wie steuere ich dieses "setOutputLimit"-Objekt von einem entfernten System aus? Über MQTT?
Weil ich überprüft habe und MQTT in deinem Projekt auf 127.0.0.1 festgelegt ist, sodass ich nicht von einem entfernten Server aus über MQTT verbinden kann. Wie ändere ich diesen Parameter? Wie sammle ich ZENDURE-Werte (in ioBroker-Datenobjekten) dank eines entfernten Systems?
(Ich benutze Home Assistant und bereits MQTT für die offizielle Zendure-Verbindung, aber ohne verfügbare Steuerung)
Kannst du mir bitte helfen? Wie kann ich diese MQTT-Daten an ein entferntes System senden? Und wie kann ich setOutputLimit außerhalb der ioBroker-Oberfläche erzwingen?
Danke für deine Zeit und Erklärung! Schönes Wochenende!
@bennobaer Das ist echt hochinteressant mit dem 1800er...Habe den 1500er und mich bisher über die 2 MPPTs geärgert, da ich zeitweise Leistung "verschenke" mit meinen ebenfalls 6 Modulen (4 an Zendure, 2 direkt an den Hoymiles). War knapp davor, zu wechseln. Deine Info spart mir Zeit und Geld. Danke!
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>
@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.
@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
@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.dischargeLimitbist 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.
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
@lesiflo said in Test Adapter Zendure Solarflow:
Moin,
ich habe seit einiger Zeit immer mal wieder diese Meldungen hier im Log:
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.
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
@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.
Same here...Fehler ohne Ende...
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 
@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.
@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 ?
@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.
