Test Adapter Zendure Solarflow

[Felli]

Ich habe in meiner Kombi mit HUB1200 und ACE1500 zweimal probiert die neue Funktion mit setDeviceAutomationInOutLimit probiert aber leider ohne Erfolg. Entweder geht es in der Kombi nicht, der ACE kann ja regulär auch keinen Überschuss laden oder ich bin zu doof dafür ‍

Vielleicht kann mir ja einer weiterhelfen oder die Info hilft jemand anderem der selbes Problem hat. Nutze weiterhin die bekannten um In und Output Limit zu setzen.

[maxclaudi]

@Felli
Bei mir läuft es mit einer HUB2000 + ACE1500 Kombi.
Überschussladen mache ich ebenfalls klassisch per Script über autoModel:0, acMode, inputLimit und outputLimit, alles in Verbindung mit smartMode:1 – und mit möglichst wenigen Schreibvorgängen.

[BMGS]

@nograx said in Test Adapter Zendure Solarflow:

@bmgs sagte in Test Adapter Zendure Solarflow:

B3Dxda

Wenn B3Dxda der product key ist sollte es mit der Version 2.0.3 laufen.

Hallo, funktioniert leider bei mir noch nicht, im Fallback legt mit Zendur auch eine ander Nr. an.
zendure-solarflow.0.hC1g9Utt
Lg
Bernd

[Felli]

@maxclaudi sagte in Test Adapter Zendure Solarflow:

@Felli
Bei mir läuft es mit einer HUB2000 + ACE1500 Kombi.
Überschussladen mache ich ebenfalls klassisch per Script über autoModel:0, acMode, inputLimit und outputLimit, alles in Verbindung mit smartMode:1 – und mit möglichst wenigen Schreibvorgängen.

Genau so mache ich es auch, Schreibvorgänge sind soweit kastriert und werden nur vom Wetter beeinflusst Danke für die Rückmeldung

[maxclaudi]

Ich möchte mich an dieser Stelle zurückziehen, da ich den Adapter selbst nicht mehr nutze und stattdessen auf eine eigene Lösung umgestiegen bin.

Meine bisherigen Hinweise basierten ausschließlich auf eigener Analyse und Tests – jeder kann das bei Interesse selbst nachvollziehen.

Vielen Dank an alle hier für den Austausch und die vielen Ideen, die indirekt auch zu meiner eigenen Lösung beigetragen haben

Da ich den Adapter selbst nicht mehr einsetze, schaue ich nur noch ab und zu vorbei und beschränke mich künftig eher aufs Mitlesen.

Nochmals ein herzliches Dankeschön an alle

[Murphy 0]

@nograx
Wie bereits schon geschrieben habe ich seit der Version 2.01 offline mit weniger Schreibzugriffe seit Wochen überhaupt keine Probleme mehr. Ich benutze setDeviceAutomationInOutLimit.
Für mich kommt nur der offline modus in Frage, da ich so auch den Shelly em3 offline benutzen kann.
Ich habe jetzt auf die Version 1.03 upgedated.
Falls ich da Probleme feststelle werde ich das hier mitteilen.

[lesiflo]

@nograx Hab mal 2.0.3 installiert und setDeviceAutomationInOutLimit wieder aktiviert. Das vom @maxclaudi beschriebene Verhalten mit dem Smartmode in der App konnte ich auch sehen. Ich melde mich wenn's was neues gibt.

[Bernd1967]

@nograx sagte in Test Adapter Zendure Solarflow:

@maxclaudi Ich habe mir jetzt mal versucht in die Issues bei der HA Integration einzulesen. Dort ist beschrieben das das Problem mit dem "Freeze" behoben ist (es sei denn ich übersehe da jetzt was).

Ist wird auch angemerkt das Zendure hier wohl ein Firmware Update veröffentlicht hatte welches das Problem beheben sollte? Seid ihr da auf dem aktuellen Stand?

Hab da auch fleißig mitgelesen und zusätzlich noch in der Zendure Community
Ich hab das so verstanden das es mehrere Ursachen für die Freeze gibt.
Eine Ursache lag wohl im HA Adapter und dieser wurde wohl behoben.
Eine weitere Ursache liegt eventuell in der Firmware , da soll es noch ein Update geben, bisher ist aber noch keins veröffentlicht worden. Und was eben auch zum Freeze führen kann ist laut Zendure eine schlechte Wifi Verbindung.
Wobei ich denke, das es nur an der Firmware liegt. Es kann ja immer mal zum Ausfall der Wifi Verbindung kommen, aber dann sorge ich als Developer dafür das anschließend das Gerät auch wieder läuft. Scheinbar ist bei Zendure auch kein Logging vorgesehen, denn dann würde man sehr schnell dem Fehler auf die Schliche kommen.

[nograx]

@bmgs sagte in Test Adapter Zendure Solarflow:

@nograx said in Test Adapter Zendure Solarflow:

@bmgs sagte in Test Adapter Zendure Solarflow:

B3Dxda

Wenn B3Dxda der product key ist sollte es mit der Version 2.0.3 laufen.

Hallo, funktioniert leider bei mir noch nicht, im Fallback legt mit Zendur auch eine ander Nr. an.
zendure-solarflow.0.hC1g9Utt
Lg
Bernd

Kannst du mir davon wohl mal einen Screenshot per PN schicken?

[lesiflo]

@nograx Bisher keine Ausfälle seit der Umstellung auf 2.0.3 und setDeviceAutomationInOutLimit mit Cloud

[nograx]

@lesiflo sagte in Test Adapter Zendure Solarflow:

@nograx Bisher keine Ausfälle seit der Umstellung auf 2.0.3 und setDeviceAutomationInOutLimit mit Cloud

Da ist vll. der Testzeitraum einfach noch zu kurz. Aber danke das du es ausprobierst!

[nograx]

@maxclaudi schade das du hier jetzt einen anderen Weg gehst. Wie genau gehst du denn hier vor?

Das mit dem lokal habe ich immer noch nicht verstanden. Wenn ich über die Cloud verbunden bin, sendet ioBroker den invoke Befehl an den Cloud MQTT und das verbundene Gerät empfängt die Aktualisierung und verarbeitet diese. "Lokal" kann ich da gar nichts an das Gerät schicken weil dieses nur Befehle vom verbundenen MQTT Server entgegen nimmt.

Das einzige Problem das ich mir hier vorstellen kann, ist das Szenario das man hier unter Devices in der Zendure App noch einen Shelly oder ähnlich eingebunden hat und durch die Änderung des Mode dieser wieder aktiv geschaltet wird und somit der nachgelagerte Server bei Zendure wieder Befehle schickt. Dann versuchen natürlich 2 Steuerungen das Gerät zu steuern. Da kann es dann natürlich zu Konflikten kommen.

[maxclaudi]

@nograx sagte in Test Adapter Zendure Solarflow:

Das mit dem lokal habe ich immer noch nicht verstanden. Wenn ich über die Cloud verbunden bin, sendet ioBroker den invoke Befehl an den Cloud MQTT und das verbundene Gerät empfängt die Aktualisierung und verarbeitet diese. "Lokal" kann ich da gar nichts an das Gerät schicken weil dieses nur Befehle vom verbundenen MQTT Server entgegen nimmt.

Das einzige Problem das ich mir hier vorstellen kann, ist das Szenario das man hier unter Devices in der Zendure App noch einen Shelly oder ähnlich eingebunden hat und durch die Änderung des Mode dieser wieder aktiv geschaltet wird und somit der nachgelagerte Server bei Zendure wieder Befehle schickt. Dann versuchen natürlich 2 Steuerungen das Gerät zu steuern. Da kann es dann natürlich zu Konflikten kommen.

Lokaler MQTT-Broker (z. B. Mosquitto):
Der Broker macht nichts Eigenes. Er verteilt nur Nachrichten zwischen Clients (z. B. ioBroker, Hyper). Er ist reiner „Postverteiler“ und erfindet keine Befehle.

Cloud-MQTT bei Zendure:
Die Cloud ist nicht nur Broker, sondern zusätzlich auch aktiver Client.
Sie empfängt Nachrichten von App oder Automatikmodellen, erzeugt selbst Befehle (z. B. , SmartMatching, Preis-Automatik) und schreibt diese ins gleiche Topic.
So verteilt sie ihre Befehle ebenfalls an alle Clients (z. B. ioBroker, Hyper).

Ergebnis: Wenn ioBroker deviceAutomation publisht, landet das beim Cloud-Broker. Gleichzeitig publisht die Cloud (als Client) eigene Werte ins selbe Topic (function/invoke).
Das Zendure-Gerät empfängt also beide Quellen über denselben Kanal – und führt immer den zuletzt empfangenen Befehl aus.