UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[maxclaudi]

@iboriz sagte in Test Adapter Zendure Solarflow:

@maxclaudi Danke für den Tipp, jetzt hat es bei mir auch endlich geklappt

freut mich, viel Spaß

[Murphy 0]

Nur mal so zur Info.
Seit ich die Schreibzugriffe auf control.setDeviceAutomationInOutLimit bei meinem Hyper begrenzt habe, hatte ich keinen einzigen Abbruch der MQTT Meldungen zum Mosquitto mehr.
Je nach Wetterlage Sonne / Wolken Wechsel und Verbrauch habe ich ca. 400 bis 600 Schreibvorgänge am Tag.
Ob das MQTT Problem beim Hyper damit zusammenhängt kann ich nicht sagen aber auffällig finde ich den Zusammenhang schon.

[maxclaudi]

HUB1200 und HUB2000

Einige verwenden den Zendure HUB mit

• Hoymiles oder kompatiblen Wechselrichter i. V. mit
• OpenDTU-OnBattery

Wenn der Hub in Bypass ist, kann der Wechselrichter über OpenDTU-OnBattery DPL gesteuert werden.

• Zwischendurch benötigt man aber Vollgas und DPL soll deaktiv sein (kritische Verbraucher mit hohen, kurzzeitigen Stromanforderungen), damit man z.B. einen Schalter hat fürs Kochen etc.

edit:
Dann ist für solarbetriebene Wechselrichter dies eine gute Möglichkeit.
Leider mit zu viel Einschränkungen und durch Pending leicht bugy.

---

05.09.2025, edit2 :
Nach einiger Arbeit ist das für mich die perfekte Lösung:
eine Blockly Vorlage zur Steuerung mit meiner modifizierten Version:
OpenDTU-OnBattery-LimitPatch

[Felli]

@maxclaudi richtig, habe ich eine Weile so gemacht und als Trigger einfach den Passmode genommen. Sobald der auf true ging den dpl geschaltet. Dazu habe ich einfach die mqtt Verbindung von der OpenDTUonBattery zu meinem mqtt Broker in IoBroker genutzt. Man hat dann ein sauberes IoBroker Objekt was man ansteuern kann. Siehe Screenshot....

Mache das aber nicht mehr, ByPass immer aus, ein langes Leben des Relais ist mir lieber. Aber jeder wie er es braucht

[maxclaudi]

@felli sagte in Test Adapter Zendure Solarflow:

@maxclaudi richtig, habe ich eine Weile so gemacht und als Trigger einfach den Passmode genommen. Sobald der auf true ging den dpl geschaltet. Dazu habe ich einfach die mqtt Verbindung von der OpenDTUonBattery zu meinem mqtt Broker in IoBroker genutzt. Man hat dann ein sauberes IoBroker Objekt was man ansteuern kann. Siehe Screenshot....

Mache das aber nicht mehr, ByPass immer aus, ein langes Leben des Relais ist mir lieber. Aber jeder wie er es braucht

meine Antwort darauf
Automatic schaltet mit nahezu ohne Last Bypass ein und mein Script mit sehr geringer Last aus. (18W DC bei 48V sind wieviel Ampere? Und welches Relais soll das nicht mitmachen?). In der Nacht ohne Last auf Automatic (Keine Sonne/PV=keineLast).
Wenn du es nicht glaubst, dann schraub den Hub auf und messe
aber ja, jeder wie er möchte

[Felli]

@maxclaudi äh das war keine Kritik lediglich meine Meinung ich muss nicht bewiesen haben... Die unzähligen HUBS im Zendureforum die ihre Arbeit wegen verbratztem Relais quittiert haben, waren aber der Grund es nicht zu tun. Habe genug Überschuss daher alles gut

[maxclaudi]

@felli

macht doch nichts. Auch wenn es Kritik wäre
Zendure ist nicht dumm und macht das nicht ohne Einschaltstrombergenzung.

Fraglich bleibt wie das bei manuellem schalten ist, wenn viel PV-Leistung vorhanden ist.

Die vorher verlinkte Antwort ist richtig und betrifft "Automatic schaltet ein" "Automatic schaltet aus", mein "Automatic ausschalten bei <= 18W" und mein "Automatic einschalten um 0 Uhr".

Ist gemessen und anhand von Daten analysiert bei meinem HUB2000.

Wenn natürlich ein User, der keinen technischen Hintergrund hat, einfach immer wild tagsüber aus und einschaltet, weil die App das kann, der muss sich nicht über Defekte wundern.

Aus dem Grund hat auch Zendure (vergeblich, angeblich) gewarnt, nicht so oft umzuschalten.
Aber wie möchte man jeden Kunden und technisch nicht so versierten davor abhalten?
Die App kann's ja

[Felli]

@maxclaudi du ich speise jenseits der 2MWh im Jahr ein, ich habe kein Problem mit zu wenig über Tag daher ist der ByPass für mich mehr oder weniger nutzlos und ich schone mein Relais. Ob mit oder ohne Last es bleibt eine mechanische Komponente die, je weniger man sie nutzt, entsprechend länger hält.

In einem anderen Usecase sicherlich anders, dann würde ich es ebenfalls so machen und habe es in der Vergangenheit auch mal in der Regelung gehabt, bzw ist noch drin aber da er auf Dauer aus ist, liegt der Subflow halt Tod in der Ecke.

Daher alles gut und wenn man weiß was man tut ist es ja auch mehr als okay Mache es z.B. bei Relais im ACE so, das ich nur zweimal am Tag schalte. Morgens auf Eingang, abends auf Ausgang und fertig.

Schaut dann so aus in NodeRed

[iBoriz]

Hi zusammen,

ich habe noch einmal eine Frage. Entschuldigt bitte, falls das schon irgendwo beantwortet wurde – ich habe gesucht, aber leider nichts gefunden.

Ich bin davon ausgegangen, dass mir mehr Daten oder zusätzliche Einstellungsmöglichkeiten zur Verfügung stehen, wenn ich den Hyper mit meinem lokalen MQTT-Broker verbinde.

Allerdings hat sich die Übersicht in den Objekten des zendure-solarflow-Plugins nicht verändert.

Im MQTT-Broker sehe ich zwar viele Einträge, kann damit aber nicht wirklich etwas anfangen.

Unter mqtt.0.iot.gDa3tb.F6BXXXX.properties.read ist auch {"properties":["getAll"]} eingetragen (das war bereits von Anfang an so). Soweit ich es verstanden habe, sollte das eigentlich dafür sorgen, dass alle Daten abgerufen werden.

Konkret fehlt mir jedoch die Einstellung, ob der Hyper ins Netz einspeisen darf oder nicht – diese Option konnte ich bisher nur in der App konfigurieren.

Vielen Dank schonmal

[lesiflo]

Hallo zusammen,
ich habe mir ein Java-Script erstellt mit den unten stehenden Funktionen. Bevor ich mir die Arbeit mache und es einstelle, ein kurze Frage ob an sowas überhaupt Interesse besteht. Es ist halt sehr an meine Umgebung angepasst. Man könnte aber die eine oder andere Idee übernehmen. Es ist auch nicht perfekt und bedarf sicher an der einen oder anderen Stelle Verbesserungsbedarf.

[Felli]

@lesiflo ich find sowas cool und Respekt das du das alles in Javascript gebaut hast. Was hälst du von der Idee, dein Konstrukt in eine NodeRed Regelung umzubauen mit der Zeit. Vorteil bei NodeRed, man kann bei richtigem Aufbau das ganze modular gestalten und Leute die z.B. keinen dynamischen Tarif nutzen, lassen den Block einfach weg.

Kurz gesagt, ich mache tatsächlich auch vieles über Javascripts aber das sind eher Helper die mir dynamisch Werte verrechnen usw. Damit gehe ich dann in NodeRed und baue dort meine Steuerung. Finde den visuellen Aufbau halt einfacher um Abhängigkeiten und Logik zu durchblicken und das macht es auch einfacher zu Nachnutzung. Würde dir auch dabei helfen, können uns da ja zusammentun, vielleicht kriegen wir ja ein schönes Package hin.

Ansonsten hau raus das Script ich schaue mir das auf jedenfall an, danke dafür

[lesiflo]

@felli NodeRed nutze und kenne ich nicht, ich kann das Script aber mal gerne einstellen. Am besten unter einem eigenen Beitrag, unabhängig von dem hier.

[Felli]

@lesiflo alles gut, die wichtigsten Teile deines Scripts, nämlich die Berrechnungen für Ausgabe und Ladeleistung z.B. sind auch in NodeRed essentiell. Der Vorteil liegt halt an allem was dazwischen ist. Wenn du magst, schau dir mal mein GitHub Projekt dazu an. Ist nicht der letzte Stand aber ich habe es versucht modular aufzubauen. Werde das irgendwann mal komplett neu bauen in einem neuen Flow. Habe damals halt wie alle ohne Plan angefangen und gemacht. Mit der Zeit lernt man dazu und versucht es umzusetzen aber ist dann immer schwierig. Teile gerne dein Script, vielleicht kann ich Teile davon nutzen. Denke aber vor Herbst wird das nichts bei mir ‍

https://github.com/Felliglanz/Zendure

Dir trotzdem vielen Dank und weiter so, finde ich echt gut

[lesiflo]

@felli Hier der neue Beitrag: Link Text

[Murphy 0]

@iboriz
Servus,
wenn du deinen Hyper2000 lokal über deinen MQTT Server betreibst kannst du Befehle und Einstellungen unter Punkt Control vornehmen.

Hier geht’s zu den Blockly Steuerungen die du zum Steuern brauchst. Natürlich geht auch JS oder NodeRed.

https://forum.iobroker.net/topic/80764/script-zum-laden-entladen-von-zendure-solarflow

Die aktuellste Version vom Zendure Adapter ist die 2.01 welche für den Hyper empfehlenswert ist. Kannst du über npm bekommen.

Viel Spaß, ist einiges zu tun bis alles lüpt!

[Rene55]

@nograx Jetzt ist ja die Version 2.0.1 im Stable. Kann/soll ich das jetzt für meinen HUB1200 nutzen? Dann wahrscheinlich mit "control.smartMode" = true und dann über "control.setOutputLimit" und eben nicht über "control.setDeviceAutomationInOutLimit".
Oder soll/muss ich bei 1.15.4 bleiben?

[nograx]

@rene55 sagte in Test Adapter Zendure Solarflow:

@nograx Jetzt ist ja die Version 2.0.1 im Stable. Kann/soll ich das jetzt für meinen HUB1200 nutzen? Dann wahrscheinlich mit "control.smartMode" = true und dann über "control.setOutputLimit" und eben nicht über "control.setDeviceAutomationInOutLimit".
Oder soll/muss ich bei 1.15.4 bleiben?

Was pricht dagegen das mit dem Hub zu nutzen? Empfehlen kann ich definitiv "setDeviceAutomationInOutLimit".

[Rene55]

@nograx Ok, dann werde ich upgraden, den smartMode auf true lassen und via setDeviceAutomationInOutLimit die Ausgangsleistung steuern. Danke.

[maxclaudi]

@nograx sagte in Test Adapter Zendure Solarflow:

@rene55 sagte in Test Adapter Zendure Solarflow:

@nograx Jetzt ist ja die Version 2.0.1 im Stable. Kann/soll ich das jetzt für meinen HUB1200 nutzen? Dann wahrscheinlich mit "control.smartMode" = true und dann über "control.setOutputLimit" und eben nicht über "control.setDeviceAutomationInOutLimit".
Oder soll/muss ich bei 1.15.4 bleiben?

Was pricht dagegen das mit dem Hub zu nutzen? Empfehlen kann ich definitiv "setDeviceAutomationInOutLimit".

Das folgende spricht dagegen:

1. Die Funktion invoke (setDeviceAutomationInOutLimit) wurde von HA übernommen und das nicht vollständig, wie HA es macht.
   z.B. der Zwischenschritt von Laden zu Entladen mit Mode:0 usw.(?)

2. Die Funktion ist nicht zur direkten Steuerung vorgesehen und verwendet original eher ein Richtwert mit mapping.
   Wurde zweckentfremdet mit ungewissen Ausmaß, ohne genauen Background.
   Dadurch kommt es zu Fehlern und Folgefehlern.

3. Das betrifft die HA-Integration und weil das die Basis für den solar-flow-Adapter ist auch diesen.
   z. B. plötzliche mqtt-Probleme, woher komme die?
   auch beim Hyper...

Lösung: wie von Zendure vorgesehen steuern.
Keine (mqtt-)Probleme, weil es Zendure für lokale Verwendung vorgesehen hat und das nun auch offiziell über mqtt/App bei neueren Geräte:
Verwendung von den dafür bestimmten Keys: acMode, inputLimit, outputLimit.

Warum?
Alles wird in Flash geschrieben. Wie bei den meisten auf dem Markt befindlichen Geräten im Consumer-Bereich.
Auch Function Invoke von Zendure macht das:
Rückkmeldung von Zendure
Auswertung

Flash schreiben ist bei Consumer-Geräte leider üblich. Tabelle

Bisherige Erkenntnis

übliche Lebensdauer von Flash im Consumbereich

Feststellungen

---

Du empfiehlst die Funktion "definitiv" für den HUB.
Ohne eine ausführliche Begründung?
Ein kurzer Satz, wie "Zendure macht das auch so" ist nicht richtig und kann nicht belegt werden.
Bei allem Respekt für Deine bisherige, großartige Arbeit.
Nur das unvollständige Übernehmen inkl. Fehlern von der HA Integration finde ich nicht zielführend.
Wir wissen doch Alle nicht, in welchem Zusammenhang und wie (mapping etc.) die originale Basis funktioniert und was sie alles erwartet.
Für reines, beliebiges und beliebig oft, Werte setzen ist sie nicht gedacht.

Die einzige sinnvollen Strategien sind: Keys verwenden, die auch freigegeben wurden.
Schreibvorgänge auf das nötigste zu begrenzen für ein langes Flash-Leben.
Das wurde von Zendure bestätigt (neue Geräte) und auch von Zendure wirklich so gemacht.

---

Hinweis:
Habe lange überlegt ob ich mich überhaupt noch dazu äußern soll.
Bin wieder an dem Punkt mich unbeliebt zu machen, nur weil ich schreibe was ist und was herausgefunden und beobachtet wurde.

Jeder wie er möchte, für mich ist das Thema "invoke" durch.

---

@felli sagte in Test Adapter Zendure Solarflow:

@maxclaudi ... Ob mit oder ohne Last es bleibt eine mechanische Komponente die, je weniger man sie nutzt, entsprechend länger hält.
....
Daher alles gut und wenn man weiß was man tut ist es ja auch mehr als okay Mache es z.B. bei Relais im ACE so, das ich nur zweimal am Tag schalte. Morgens auf Eingang, abends auf Ausgang und fertig.

Ja, das ist das auch eine mechanische Komponente.
Die genau dafür ausgewählt wurde und nicht übertrieben oft, sondern mäßig, im richtigen Zeitpunkt, genutzt werden sollte bzw. kann.

Ein Lichtschalter ist auch mechanisch und diesen schalte ich auch nicht ständig als Flip-Flop/Blinker aus und ein.
Benutzen werde ich den Schalter, weil ich nicht im dunkeln stehen möchte, damit der Schalter länger lebt.

Bypass soll Batterien schonen(?).
Das weiß ich nicht und verlasse mich auf die Aussagen des Herstellers.
Wenn das so ist, dann sind bzw. wären mir defekte Relais lieber als defekte Batterien.

Damit ist auch das Thema "Relais" für mich abgeschlossen

[nograx]

@maxclaudi sagte in Test Adapter Zendure Solarflow:

@nograx sagte in Test Adapter Zendure Solarflow:

@rene55 sagte in Test Adapter Zendure Solarflow:

@nograx Jetzt ist ja die Version 2.0.1 im Stable. Kann/soll ich das jetzt für meinen HUB1200 nutzen? Dann wahrscheinlich mit "control.smartMode" = true und dann über "control.setOutputLimit" und eben nicht über "control.setDeviceAutomationInOutLimit".
Oder soll/muss ich bei 1.15.4 bleiben?

Was pricht dagegen das mit dem Hub zu nutzen? Empfehlen kann ich definitiv "setDeviceAutomationInOutLimit".

Das folgende spricht dagegen:

1. Die Funktion invoke (setDeviceAutomationInOutLimit) wurde von HA übernommen und das nicht vollständig, wie HA es macht.
   z.B. der Zwischenschritt von Laden zu Entladen mit Mode:0 usw.(?)

2. Die Funktion ist nicht zur direkten Steuerung vorgesehen und verwendet original eher ein Richtwert mit mapping.
   Wurde zweckentfremdet mit ungewissen Ausmaß, ohne genauen Background.
   Dadurch kommt es zu Fehlern und Folgefehlern.

3. Das betrifft die HA-Integration und weil das die Basis für den solar-flow-Adapter ist auch diesen.
   z. B. plötzliche mqtt-Probleme, woher komme die?
   auch beim Hyper...

Lösung: wie von Zendure vorgesehen steuern.
Keine (mqtt-)Probleme, weil es Zendure für lokale Verwendung vorgesehen hat und das nun auch offiziell über mqtt/App bei neueren Geräte:
Verwendung von den dafür bestimmten Keys: acMode, inputLimit, outputLimit.

Warum?
Alles wird in Flash geschrieben. Wie bei den meisten auf dem Markt befindlichen Geräten im Consumer-Bereich.
Auch Function Invoke von Zendure macht das:
Rückkmeldung von Zendure
Auswertung

Flash schreiben ist bei Consumer-Geräte leider üblich. Tabelle

Bisherige Erkenntnis

übliche Lebensdauer von Flash im Consumbereich

Feststellungen

---

Du empfiehlst die Funktion "definitiv" für den HUB.
Ohne eine ausführliche Begründung?
Ein kurzer Satz, wie "Zendure macht das auch so" ist nicht richtig und kann nicht belegt werden.
Bei allem Respekt für Deine bisherige, großartige Arbeit.
Nur das unvollständige Übernehmen inkl. Fehlern von der HA Integration finde ich nicht zielführend.
Wir wissen doch Alle nicht, in welchem Zusammenhang und wie (mapping etc.) die originale Basis funktioniert und was sie alles erwartet.
Für reines, beliebiges und beliebig oft, Werte setzen ist sie nicht gedacht.

Die einzige sinnvollen Strategien sind: Keys verwenden, die auch freigegeben wurden.
Schreibvorgänge auf das nötigste zu begrenzen für ein langes Flash-Leben.
Das wurde von Zendure bestätigt (neue Geräte) und auch von Zendure wirklich so gemacht.

---

Hinweis:
Habe lange überlegt ob ich mich überhaupt noch dazu äußern soll.
Bin wieder an dem Punkt mich unbeliebt zu machen, nur weil ich schreibe was ist und was herausgefunden und beobachtet wurde.

Jeder wie er möchte, für mich ist das Thema "invoke" durch.

---

@felli sagte in Test Adapter Zendure Solarflow:

@maxclaudi ... Ob mit oder ohne Last es bleibt eine mechanische Komponente die, je weniger man sie nutzt, entsprechend länger hält.
....
Daher alles gut und wenn man weiß was man tut ist es ja auch mehr als okay Mache es z.B. bei Relais im ACE so, das ich nur zweimal am Tag schalte. Morgens auf Eingang, abends auf Ausgang und fertig.

Ja, das ist das auch eine mechanische Komponente.
Die genau dafür ausgewählt wurde und nicht übertrieben oft, sondern mäßig, im richtigen Zeitpunkt, genutzt werden sollte bzw. kann.

Ein Lichtschalter ist auch mechanisch und diesen schalte ich auch nicht ständig als Flip-Flop/Blinker aus und ein.
Benutzen werde ich den Schalter, weil ich nicht im dunkeln stehen möchte, damit der Schalter länger lebt.

Bypass soll Batterien schonen(?).
Das weiß ich nicht und verlasse mich auf die Aussagen des Herstellers.
Wenn das so ist, dann sind bzw. wären mir defekte Relais lieber als defekte Batterien.

Damit ist auch das Thema "Relais" für mich abgeschlossen

Weiß gar nicht genau wie ich darauf reagieren soll. Die setDeviceAutomationLimit Methode wurde ja auf deinen Hinweis hin implementiert, so wie die Integration von HA es macht (wo sollen hier die Unterschiede sein?). Das das nicht offiziell ist sollte jedem klar sein. Das war der Adapter nie - und jeder benutzt ihn auf eigene Gefahr. Ich selbe steuere jetzt seit dem meinen Hyper 2000 und einen AIO 2400 mit setDeviceAutomationLimit und das läuft ohne irgendwelcher Aussetzer oder Probleme.

Die "offizielle" Api von Zendure wird nur vom SF 800 und SF 2400 unterstützt. Hier ist zusätzlich zum MQTT ein Webserver aktiv der Befehle entgegen nimmt und das Gerät so dann steuert. Solange ich keinen SF 800 oder SF 2400 besitze kann und werde ich das nicht einbauen können.

Ich habe versucht Kontakt mit Zendure aufzunehmen, leider ist ioBroker offensichtlich kein Thema für Zendure. Der Ruf der HA Community war da wohl lauter.