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

[cordobadb]

Hallo zusammen,
erstmal vielen Dank für die ganze Arbeit @nograx und alle, die in mit Infos versorgt haben!
Ich habe einen Hyper 2000 mit 2x AB2000 Paks. Der Hyper sendet schon an einen lokalen Broker und erste Versuche das Einspeisen/Laden über den ioBroker-Adapter zu steuern waren erfolgreich. Sowohl über den acMode 1/2 und die Leistungslimits als auch über autoModel 8 / SmartMatchingModus.

Dazu habe ich noch ein paar Fragen.

• Die acModi 1/2 benötige ich nicht, weil ich per MQTT dynamisch an den Verbrauch angepasst laden möchte, und das setzen der Limits ggf. die Schreibzyklen des EEPROMs übersteigt?

• Der Smart CT-Modus ist zu unflexibel, wenn man ihn ohne Cloud überhaupt mit einem kompatiblen Sensor "gepaired" bekommt?

• Der SmartMatchingModus nimmt eine Leistung per MQTT entgegen und regelt sie ein. Da es so auch von Zendure genutzt wird, wird davon ausgegangen, dass die Werte nur im RAM liegen. -> Der richtige Modus um eine externe Steuerung/Regelung nach Verbrauch, börsenpreisorientiertes Laden, etc. umzusetzen?

• Wie funktioniert die Logik des Bypass im Hyper 2000? Ich möchte ungern über den Akku gehen wenn die PV-Leistung gerade so dem Hausverbrauch entspricht, um den Akku zu schonen und die Verluste zu verringern. Leider lässt sich der Bypass nicht schalten, zumindest bei meinen ersten Versuchen nicht. Egal welcher Passmode geschickt wird, die Antwort ist immer success:0 und es klakt auch nichts am Wechselrichter. Der angezeigte passMode folgt dem eingestellten passMode, aber pass bleibt immer auf false. Kann es sein, dass man den Bypass beim Hyper nicht extern steuern kann, oder hat eine Logik das schalten verhindert, weil ich nachts getestet habe und da keine PV-Leistung anlag? Habt ihr damit Erfahrung?

Vielen Dank für eure Antworten!

[maxclaudi]

@cordobadb sagte in Test Adapter Zendure Solarflow:

• Die acModi 1/2 benötige ich nicht, weil ich per MQTT dynamisch an den Verbrauch angepasst laden möchte, und das setzen der Limits ggf. die Schreibzyklen des EEPROMs übersteigt?

soweit die Aussage von FireSon der Entwickler einer HA Integration für Zendure-Geräte ist und diese so von Zendure angeblich mitgeteilt bekommen hat.

• Der Smart CT-Modus ist zu unflexibel, wenn man ihn ohne Cloud überhaupt mit einem kompatiblen Sensor "gepaired" bekommt?

Funktioniert bei uns mit shelly pro, lokal und inet gesperrt.
Allerdings nicht so gut wie ein eigenes script.

• Der SmartMatchingModus nimmt eine Leistung per MQTT entgegen und regelt sie ein. Da es so auch von Zendure genutzt wird, wird davon ausgegangen, dass die Werte nur im RAM liegen.

Es wird davon ausgegangen.
Ob es so, auch umgesetzt ist, mit allen arguments etc. (wie von Zendure) ist fraglich.
Sicher ist, dass FireSon (eine mehr oder weniger) funktionierende Variante dafür geschrieben hat und sie dem Adapter als Vorlage diente.

Meine unwichtige Meinung im spoiler.

Spoiler

Sieht eher nach Reverse Engineering aus. Bzw. loggen der Kommunikation und daraus Schlüsse gezogen werden, wie es funktioniert und anpassen an die Bedürfnisse.

Der Adapter baut auf der HA Integration auf und es wurde (vieles) übernommen.
Mich persönlich stört daran, dass dies umgesetzt wurde im Vertrauen darauf, dass alles so richtig ist und einfach gemacht wird.
Man weiß zu wenig welche arguments richtig, notwendig sind oder weg gelassen werden müssen und welche arguments oder functionen es noch gibt usw.
Nur weil was funktioniert, ist es noch lange nicht richtig und vielleicht auch nicht so gut fürs System.

Beispiel: Laden und entladen.

Man kann hart umschalten von Laden auf Entladen, in dem man einfach die Schaltanweisung publised: "acMode": 2
Oder man sorgt erst dafür, dass die Werte "inputLimit":0, "outputLimit":0, "smartMode":1 sind und dann "acMode":2
Das kann man vorher abfragen, replys auswerten und dann setzen usw.

weitere (gesehene) Beispiele:
in einem code wird bei smartMachting mit negativen und positiven Werten und 0 unterschieden und zusätzlich abhängig gemacht vom momentanen "state"==x (ob System sich im Charging/Discharging oder Idle Modus befindet.)
Je nachdem wird dann unterschiedlich reagiert.
Gibt man z. B. 100 ein und das system war bei -200, dann wird nicht sofort 100 angefordert.
Es wird erst 0 gesendet und das System auf "Idle" gesetzt (zusätzlich habe ich die Variante gesehen, dass bei 0 noch das autoModel 8 verlassen wird und auf 0 (nothing) gesetzt wird) und im Anschluss wird der Wert 100 published (und je nach dem wieder ins autoModel 8 zurückgeschaltet oder/und alle weiteren arguments neu gesetzt).

Andere wiederum setzen 0 als positiven Wert und bleiben im SmartMatchingModus usw.
Wenn man nun 0 setzt, wird nicht entladen oder geladen, aber der Weg ist unterschiedlich.

Beides und noch mehr funktioniert.
Nur ob es gut für die Geräte ist oder gleichgültig etc. ?
Persönlich würde ich nie behaupten, dass mein Code das selbe macht wie Zendure.
Es sei denn, ich hätte die Bestätigung von Zendure, hätte Unterlagen bzw. ausführlich dokumentierte API/SDK.

-> Der richtige Modus um eine externe Steuerung/Regelung nach Verbrauch, börsenpreisorientiertes Laden, etc. umzusetzen?

Ansichtssache.

• Wie funktioniert die Logik des Bypass im Hyper 2000? Ich möchte ungern über den Akku gehen wenn die PV-Leistung gerade so dem Hausverbrauch entspricht, um den Akku zu schonen und die Verluste zu verringern. Leider lässt sich der Bypass nicht schalten, zumindest bei meinen ersten Versuchen nicht. Egal welcher Passmode geschickt wird, die Antwort ist immer success:0 und es klakt auch nichts am Wechselrichter. Der angezeigte passMode folgt dem eingestellten passMode, aber pass bleibt immer auf false. Kann es sein, dass man den Bypass beim Hyper nicht extern steuern kann, oder hat eine Logik das schalten verhindert, weil ich nachts getestet habe und da keine PV-Leistung anlag? Habt ihr damit Erfahrung?

Speziell zum Hyper kann ich nichts sagen.
Denke es wird sich nicht (oder nicht sehr) zum HUB2000 unterscheiden:

Bypass allgemein wird vom System selbst gesteuert.
Bedingungen für Bypass:

• PV-Leistung muss vorhanden sein
• Batterien haben Ladezustand socSet z.B. 100% erreicht
• Bypass muss eingeschaltet sein oder automatic

Dann wird in Bypass geschaltet. Sonst nicht.

Auch wenn 100% erreicht sind startet der Bypass nicht sofort.
Das System gibt den Bat Zeit um etwas abzukühlen und wartet ob die Spannung noch etwas fällt.
Lädt dann, wenn Bedarf ist, etwas mit wenig Leistung nach und wartet wieder usw.
Das kann schnell gehen oder sich auch mal etwas in die Länge ziehen je nach minVol<>maxVol Differenz.
Bypass soll sich im Automatic-Modus ausschalten, wenn über mehr als 5min eine sehr geringe PV-Leistung rein kommt.
Selbst nutze ich den Automatic-Modus.
Schalte den Bypass jedoch per script aus und später wieder auf Automatic.

Bypass "immer aus" geschaltet: ist selbsterklärend (?).

Bypass: "immer ein":
Der Schaltmodus ist bei mir sinnfrei, dann bräuchte ich kein System, das über PV DC laden kann.
Habe das nicht getestet.

[maxclaudi]

Wer den Hyper und/oder Hub2000 hat und noch in der Cloud ist:
Kann bitte jemand prüfen ob es ein Update gibt bei dem die MQTT-Verbindung eingestellt werden kann?

Wer den SF2400AC oder solarFlow 800 (pro) hat und in der App mqtt angeboten wird, der kann sich mal mit mqtt verbinden.
Im Router die Zendure-Geräte, iobroker, shelly oder was auch immer für einen Zähler usw.
alle Geräte die mit den Zendure-Geräte kommunizieren fürs inet sperren.

Denke die Kommunikation läuft weiter.
Maximal die App wird die Geräte vielleicht nicht erreichen.
Wahrscheinlich im eigenen WiFi schon.
Wenn ja, dann wäre eine Fernbedienung per App über VPN theoretisch auch möglich.

Schade, dass ich nicht testen kann.

[maxclaudi]

@bernd1967

So schnell wie die HA integration geändert wird, kommt man gar nicht hinterher.
Vor 16h schon wieder: Version 1.1.0-pre17

man beachte:

Other issues

An initial version of a new sensor is added, which counts the number of switches of the inverter between idle, charging and discharging

Fixed an issue with MQTT json load

so ein fixed fehlt dann auch im adapter.
Und ob das dann alles war und richtig gelöst wurde usw. ?
Denke es ist Neuland, noch viel zu viel unbekannt und bugy.

[The_Stig]

Sagt mal, hat jemand von euch mit der 2.0.1 das Problem, dass irgendwann keine Daten mehr reinkommen - nach einer gewissen Zeit ist dann wifi-State auf Disconnected. Musste heute wieder auf den Zendure-Server umstellen. Seitdem läuft es jetzt einige Stunden problemlos. Hyper2000.

[Bernd1967]

@maxclaudi sagte in Test Adapter Zendure Solarflow:

@bernd1967

So schnell wie die HA integration geändert wird, kommt man gar nicht hinterher.
Vor 16h schon wieder: Version 1.1.0-pre17

Jo, da hat der Fireson richtig zu tun.

Was ich mich Frage ist ob der Adapter mit der neuen Firmware noch funktioniert.

[cordobadb]

@maxclaudi : Vielen Dank für deine Ausführliche Antowrt. Die Riskien sind mir bewusst, leider gibt es aktuell auch keine andere "günstige" Wechselrichter/Speicher-Kombi die zugänglicher wäre. Da scheint mit Zendure noch am besten dokumentiert u sein. Und für einen eigenen Aufbau von Speicher, BMS, etc. fehlt mir die Zeit.

Zu deiner Frage bzgl. App/Hyper und MQTT-Option. Ich habe die aktuellste Firmware auf dem Hyper und die aktuelle Android App, da habe ich bisher aber nichts davon gesehen.

[maxclaudi]

@cordobadb sagte in Test Adapter Zendure Solarflow:

Die Riskien sind mir bewusst, leider gibt es aktuell auch keine andere "günstige" ....

warum leider? Würde mich (bis jetzt) wieder für Zendure entscheiden.
Meine zuerst angestrebte Alternative victron multiplus-II mit pylontech Batterien waren und sind mir zu teuer.

Zu deiner Frage bzgl. App/Hyper und MQTT-Option. Ich habe die aktuellste Firmware auf dem Hyper und die aktuelle Android App, da habe ich bisher aber nichts davon gesehen.

Schade. Vielleicht später oder gar nicht(?).

@Bernd1967

Jo, da hat der Fireson richtig zu tun.

vor 4 Stunden schon wieder eine neue Version: 1.1.0-pre18
schau mir den code gar nicht mehr an und warte auf das erste stable oder zumindest einige Zeit noch.

Was ich mich Frage ist ob der Adapter mit der neuen Firmware noch funktioniert.

Zumindest lokal denke ich schon.
In der Cloud würde höchstens auch das mit dem steuerbaren 2ten account evtl. abgeschafft.
Eher unwahrscheinlich, wer weiß.
Kommunikation Protokoll usw. bleibt ja.
Bevor sie noch groß was ändern, gibt es eher kein mqqt-Update für alte Geräte.
Der eingeschränkte 2t account könnte jederzeit geschaffen werden um auch Server-Traffic zu sparen.

Dass mqtt (bei Zendure, per App) sich aktivieren lässt und funktioniert, muss ja HEMS abgeschaltet sein.
Deshalb würde ich keine HEMS-Variante für Steuerbefehle bei einem lokalen Broker verwenden.
Naja mein HUB unterstützt das sowieso nicht, von daher.

Wegen SmartMode und SmartMatching würde ich gern mehr wissen.
Wenn ich an keine zusätzlichen Infos komme, dann werde ich vermutlich (leider erst in ca 1 Monat) wieder in die Cloud (phyton mqtt-Proxy am Start) und gezielt steuern.
Mal sehen was da raus kommt.

Jetzt habe ich erst mal keine Zeit und keine Möglichkeit mehr.

Infos teile ich gern, aber leider behalten die meisten ihr Wissen für sich.
Schade, es fehlt wirklich ne Austauschgruppe.

[Rene55]

@maxclaudi Ich könnte dir bei den Aussagen zu Zendure (Würde mich (bis jetzt) wieder für Zendure entscheiden.) eigentlich zustimmen. Ich habe wohl die Befürchtung, dass die viele neue Geräte auf den Markt bringen und MEIN Hub1200 bald altes Eisen ist (oder schon ist).
Aber was zum Teufel ist HEMS?? Kann das mein Hub1200 und braucht man so etwas?

[Felli]

@rene55 ich würde mich auch wieder für Zendure entscheiden. Hoffe das mein HUB1200 noch lange hält, läuft lokal ohne Bypass eigentlich sollte nix dran kommen. Die Hardware läuft im lokalen dermaßen stabil ich habe da seit Monaten keine Hand mehr dran gehabt einfach laden und entladen...

[Rene55]

@felli Danke für die Info. Ja meiner läuft ja auch ohne Cloud und auch zufriedenstellend.
Ich brauche nur noch mal eine Erfahrungswert Richtung Akknutzung bzw. Langlebigkeit. Anfänglich hatte ich erst morgens auf SOC > 90% aufgeladen und hatte dann erst in der Nacht wieder entladen. Aktuell lasse ich -je nach Netzbezug- schon Tagsüber vom Akku einspeisen. Wird wenig Bezogen wird der Akku wieder geladen. Also Quasi immer ein wenig hin und her. Ich hoffe, mein Vorgehen schadet dem Akku nicht?

[Felli]

@rene55 ich mache es so, dass ich die Akkus ab Sonnenaufgang prio lade. Sobald voll, schalte ich auf Netzausgang und 850W Output-Limit. Wenn dann erforderlich dreht die OpenDTUonBattery den Hahn auf. Wird der Akku nicht voll, schalte ich zur golden hour auf entladen um. Da Akku dann eh nicht voll ist, wird er über Nacht eh wieder leer. Die zwei bis drei Stunden die die Akkus dann voll auf entladen warten, sind denke ich vertretbar, ist bei einem professionellen Speicher ja auch nicht viel anders, wenn der Planet brennt. Ich mache mir da keinen Kopf drum ehrlich gesagt.

[Rene55]

@felli Da ist dann der kleine Unterschied: ich habe gar keine OpenDTUonBattery. Am Ausgang von Hub1200 hängen 2 MPPT von einem Deye. Hier steure ich mit 'setDeviceAutomationInOutLimit' direkt die (zusätzliche) Ausgangsleistung.
Aber: wir müllen hier gerade den Kanal zu.

[The_Stig]

@nograx - wenn du nochmal Zeit hast, wäre ich dir total dankbar für eine Rückmeldung zu meinen beiden Fragen (schon oben mal geschrieben):

• muss der AC Mode jetzt noch manuell via Blockly wie vorher geschaltet werden? Wenn nein, welcher Modus (Nothing oder AC Output?) ist der richtige in den Objects?
• Bei mir kommen am ersten Tag 3x hintereinander nach 1-2 Stunden keine Daten mehr rein (über lokale MQTT). Wifi Disconneced. Muss dann alles resetten und PV abtrennen. Über die Zendure-Cloud läuft es aktuell durch (will ich aber eigentlich nicht). Irgendeine Idee dazu?

[maxclaudi]

@rene55 sagte in Test Adapter Zendure Solarflow:

Ich habe wohl die Befürchtung, dass die viele neue Geräte auf den Markt bringen und MEIN Hub1200 bald altes Eisen ist (oder schon ist).

Solange der HUB einwandfrei funktioniert ist das doch gleichgültig.
Benötigt man immer Updates mit mehr Funktionen (die eigentlich unnötig sind)?
Die Updates haben dann Fehler und benötigen wieder Updates, die Fehler beseitigen sollen und evtl. wieder Fehler produzieren und alles verschlimmbessert wird.
Ein unnötiger Kreislauf für zuvor funktionierende Geräte.

Freu Dich an einem funktionierenden HUB und lass ihn mit einer funktionierenden Steuerung seine Arbeit machen.
Es ist egal ob altes Eisen oder nicht. Er macht was er soll und gut ist.

Aber was zum Teufel ist HEMS?? Kann das mein Hub1200 und braucht man so etwas?

Nein braucht man meiner Meinung nach nicht und kann der HUB1200 nicht.

HEMS bei Zendure steht für Home Energy Management System – also ein intelligentes System zur Steuerung und Optimierung des Heimenergieverbrauchs.
Bsierend auf der KI-gestützten Plattform ZenKI.
Wenn die KI funktioniert, soll das ach so super sein.
Meine Meinung: funktioniert (noch) nicht ausreichend, zu unflexibel, cloudabhängig, unnötig, benötigte ich nicht.

---

@Bernd1967 und @nograx
Vor 5 Stunden wieder eine neue HA Version, jetzt keine pre-Version mehr:

Version 1.1.0

Sehr interessant: Zendure hat selbst mit entwickelt.
Also lohnt sich bestimmt ein Blick in den Code um die relevanten Stellen für iobroker + adapter zu vergleichen, analysieren und zu übernehmen.

FireSon sagte:

This is the first release of the Zendure Integration . Zendure has spend a lot of time supporting this new version. Together we have added a whole new API with improved security, and an authorization token ️, which you can retrieve in the Zendure App.

Supported devices:

Ace1500
Aio2400
Hyper2000
Hub1200
Hub2000
SF800
SF800 Pro
SF2400 AC
SuperBase V6400

Wird wohl ein Update vom solarflow-Adapter geben(?).

[maxclaudi]

@the_stig sagte in Test Adapter Zendure Solarflow:

• Bei mir kommen am ersten Tag 3x hintereinander nach 1-2 Stunden keine Daten mehr rein (über lokale MQTT). Wifi Disconneced. Muss dann alles resetten und PV abtrennen. Über die Zendure-Cloud läuft es aktuell durch (will ich aber eigentlich nicht). Irgendeine Idee dazu?

Kann an Deinem WiFi liegen oder/und an der Integration.
Mein Tip: Steuer den hyper so, dass er funktioniert mit der Version, die am besten lief und warte auf das nächste Update.
Wenn es Dir zu risikoreich ist wegen der"Flash-Gefahr", dann bleib solange in der Cloud.

[Murphy 0]

@the_stig

AC Modus 0 Nothing in den Objekts funktioniert.
Auch mein Hyper hört ab und an auf Daten an den Mosquitto zu liefern. Deshalb restarte ich den Mosquitto automatisch alle 3 Stunden.
Seit dem keine Abbrüche mehr.

Ergänzt habe ich mein System jetzt durch eine Steuerung mit iQontrol für Lade- und Entladelimit.
Ebenfalls kann ich damit in Lade- und Entladezeiten ändern.

[The_Stig]

@maxclaudi Wifi schließe ich echt aus. Repeater quasi 3 Meter entfernt. Und über Monate in der alten Version des Adapters keine Probleme. Und wenn in der Cloud auch problemlos.

[The_Stig]

@murphy-0 said in Test Adapter Zendure Solarflow:

@the_stig

AC Modus 0 Nothing in den Objekts funktioniert.
Auch mein Hyper hört ab und an auf Daten an den Mosquitto zu liefern. Deshalb restarte ich den Mosquitto automatisch alle 3 Stunden.
Seit dem keine Abbrüche mehr.

Ergänzt habe ich mein System jetzt durch eine Steuerung mit iQontrol für Lade- und Entladelimit.
Ebenfalls kann ich damit in Lade- und Entladezeiten ändern.

Meinst du mit Mosquitto den MQTT Server? Wenn ja, dann sollte es ein manueller Neustart auch beheben? Das wäre ja mal einen Test wert...

[Arne Dieckmann]

@the_stig said in Test Adapter Zendure Solarflow:

• Bei mir kommen am ersten Tag 3x hintereinander nach 1-2 Stunden keine Daten mehr rein (über lokale MQTT). Wifi Disconneced. Muss dann alles resetten und PV abtrennen. Über die Zendure-Cloud läuft es aktuell durch (will ich aber eigentlich nicht). Irgendeine Idee dazu?

Ist bei mir ähnlich, allerdings mit HUB2000 und ACE1500 (der ACE spielt hier aber keine Rolle). Beide Geräte sind lokal mit dem Adapter von Nograx in Betrieb. Es läuft auch soweit alles, nur seit der Umstellung von setOutputLimit auf setDeviceAutomationInOutLimit hängt scheinbar irgendwas bei der Kommunikation. SmartMode ist auf true, AutoModel steht auf 8 und acMode auf 2.
Gefühlt alle 12 Stunden (mal mehr, mal weniger) werden keine Daten im Zendure Adapter mehr aktualisiert. Neustart Zendure Adapter hilft nicht, nur der Neustart des MQTT Servers. Ich lasse den jetzt alle drei Stunden neustarten, kann aber ja nicht die Lösung sein.