Hallo zusammen,

ich habe heute die 3.0.0 für den Beta Kanal bereit gestellt. Darin ist für die Cloud User nun auch die Authentifizierung mit dem "Cloud Authorization Key" enthalten, welcher in der offiziellen App erzeugt werden kann. Ein Login per Username/Passwort ist nicht mehr möglich! Damit entfällt auch die Angabe des Server, da alle Infos bereits im Key enthalten sind. Auch ist jetzt kein 2. Account mehr nötig um das Ausloggen aus der App zu verhindern.

Hinweis: Auch wenn ihr lokal unterwegs seid, müsste ihr die Einstellungen nach dem Update noch mal aufrufen und bestätigen!
Hinweis2: Ich habe ein Menge Code umgebaut und effektiver gestaltet - es ist nicht auszuschließen das es hier und da ein paar Bugs gibt... wenn das ein Problem ist bleibt vorerst auf der 2er Version.

Und hier noch mal als kurze Zusammenfassung, Version 1.4.0 ist im Beta Kanal:

• neue weitere States verfügbar: wifiState, hubState (Standby oder Abschalten wenn Entladegrenze erreicht), pvBrand and inverseMaxPower
• In den Einstellungen funktioniert das Passwort-Eingabefeld wieder wenn man die Einstellungen neu aufruft
• In den Einstellungen habe ich ebenfalls das Feld "Benutzername" in "E-Mail" umbenannt damit es hier keine Missverständnisse gibt
• Es gibt 2 zusätzliche Berechnungen für PV1 und PV2. Hier kann man also den Tages-Ertrag für beide Kanäle getrennt auswerten

@xbit nein, alles was der Wechselrichter nicht abnimmt geht in die Akkus.

Sorry die letzten Versionen machen tatsächlich etwas Probleme mit der MQTT Verbindung. Weiß noch nicht genau wieso. Habe eine neue Version 1.6.7 bereitgestellt, die nun den Adapter alle 3 Stunden neu startet, ich hoffe damit werden die Verbindungen sauber beendet und neu aufgebaut.

Hallo zusammen,

ich habe soeben die Version 1.7.0 bereitgestellt (heute per Github installierbar - irgendwann heute Nacht auch über den Beta Kanal). Darin ist eine erste Unterstützung für den Hyper 2000 und den ACE 1500 enthalten. Es kann sein das da noch nicht alle Datenpunkte vorhanden sind, und auch Datenpunkte da sind die keinen Sinn ergeben. Außerdem kann ich nicht sagen ob die Steuerung über die Parameter möglich ist. Wollte ungern in die mir von euch bereitgestellten Systeme eingreifen.

An alle anderen der Hinweis das es eine Menge Änderungen aufgrund dieser Anpassungen gab, sofern was auffällt also bitte direkt Bescheid geben. Wem das zu viel Risiko ist bitte auf der Stable Version 1.6.7 bleiben.

Danke und viele Grüße

@diet99 sagte in Test Adapter Zendure Solarflow:

@nograx eine ganz andere Frage: anfangs gabs doch mit dem AIO Probleme, daß man die Ausgangsleistung per Adapter nicht steuern konnte, wenn ich das richtig im Hinterkopf habe. Ist das inzwischen möglich?
Danke!

Das sollte problemlos funktionieren.

@diet99 sagte in Test Adapter Zendure Solarflow:

Es ist mir nach sowie vor schleierhaft, warum man die Energiepläne nur über die App umschalten kann. Das sollte unbedingt irgendwann über den Adapter (also über MQTT?) machbar sein. Oder zumindest über eine Zeitsteuerung.
Aber vermutlich ist Zendure das eh ein Dorn im Auge, daß von außerhalb gesteuert wird. Wer weiß …

Das werde ich mir mal anschauen ob ich das mit dem Adapter machen kann.

So dann lösen wir den Spoiler mal auf. Sofern den überhaupt jemand gelesen hat.

Ich habe ein neues Tool geschrieben (https://github.com/nograx/zendure-cloud-disconnector). Damit ist es ganz einfach möglich sich per Bluetooth an ein Zendure device zu verbinden und den MQTT server zu ändern (basiert auf dem Python script von Reinhard Brandstätter). Damit könnt ihr dafür sorgen das die MQTT Daten statt an "mq.zen-iot.com" an einen MQTT Server eurer Wahl gesendet werden. Leider ist man darauf angewiesen den Standard MQTT Port 1883 zu nutzen und es ist aktuell nicht möglich eine Authentifizierung damit zu nutzen.

Die MQTT Anfragen werden dann etwas kryptisch an den MQTT Server gesendet. Mit dem ioBroker Adapter könnt ihr ab Version (1.12.1) dann in den Einstellungen unter "Server" lokal auswählen und ebenfalls euren eigenen MQTT Server auswählen. Dann noch Modell und ProduktKey eingeben (wird euch auch im Zendure Cloud Disconnector angezeigt) und schon sollte euer Gerät komplett lokal kommunizieren und gesteuert werden.

Bin gespannt aufs Feedback.

@maxclaudi sagte in Test Adapter Zendure Solarflow:

@felli
es gibt auch kein Problem und wird keins geben, wenn der ACE1500.acMode nicht (auch nicht aus Versehen oder bei Erstlieferung etc. pp) auf 3 steht.
3 gibt es und wird übertragen und der solar-flow-adapter kennt es nicht.

@nograx
danke. Wollte nur darauf hinweisen, dass es den ACE1500.acMode 3 nachweislich gibt, der Adapter den acMode 3 nicht kennt und nicht akzeptiert, weil >2 .

Solange man den (für mich nutzlosen) "ACE1500.acMode 3" nicht verwendet und dieser dauerhaft auf 2 bleibt, gibt es keine Probleme.

Moin, mit der Version 1.13.2 wird der AC Mode beim ACE 1500 nun auch korrekt gesetzt. Musste erstmal checken das Zendure hier den selben Datenpunkt bei Geräten für unterschiedliche Dinge nutzt.

@karacho sagte in Test Adapter Zendure Solarflow:

@nograx
Das ist echt schade, da es dann immer noch kein System Akku/SmartMeter gibt, mit einem "Aufsatz" smart meter, dass man parallel in den iobroker und in die Hersteller-App zur Nulleinspeisung Realisierung einbinden kann.
Daran scheitert gerade meine Akku Kauf...

Ich kenne nur Sunlit mit bitshake (keine API) und Zendure mit SmartMEter D0 (keine iobroker Einbindung)

Gibt es sonst noch Alternativen mit Aufsatz Smart Meter?

Ehrlich gesagt kann ich nicht verstehen warum man den Kauf von so einem System davon abhängig macht ob so ein Smart Meter mit dem Akku System kommunizieren kann (per Cloud!) wenn man selber ioBroker im Einsatz hat. Da wäre es mir persönlich wichtiger das ich das Gerät selber direkt steuern kann und das Smart Meter Gerät ebenfalls schnell seine Daten an ioBroker liefert. Dann habe ich viel mehr Möglichkeiten das so zu steuern wie ich es möchte und es läuft lokal im eigenen Netz und ist nicht von irgendwelchen Clouds abhängig.

Ich habe bei mir einen Shelly Pro 3EM im Einsatz, vorher den Tibber Pulse und habe die Steuerung eines Hoymiles Wechselrichters per AhoyDTU in einem ioBroker Script gesteuert. Am Wechselrichter hängt ein HUB2000.

Hallo zusammen,

ich habe heute die 3.0.0 für den Beta Kanal bereit gestellt. Darin ist für die Cloud User nun auch die Authentifizierung mit dem "Cloud Authorization Key" enthalten, welcher in der offiziellen App erzeugt werden kann. Ein Login per Username/Passwort ist nicht mehr möglich! Damit entfällt auch die Angabe des Server, da alle Infos bereits im Key enthalten sind. Auch ist jetzt kein 2. Account mehr nötig um das Ausloggen aus der App zu verhindern.

Hinweis: Auch wenn ihr lokal unterwegs seid, müsste ihr die Einstellungen nach dem Update noch mal aufrufen und bestätigen!
Hinweis2: Ich habe ein Menge Code umgebaut und effektiver gestaltet - es ist nicht auszuschließen das es hier und da ein paar Bugs gibt... wenn das ein Problem ist bleibt vorerst auf der 2er Version.

@stephanh sagte in Test Adapter Zendure Solarflow:

@nograx said in Test Adapter Zendure Solarflow:

das sich mein Hyper mit leerem Akku auch wi

Hi, danke für die Info.
Intressant ist aktuell, das mein Hyper nicht unter 24% Accu geht. Sobald ich die Entlade grenze auf 10% stelle. Springt die wieder auf 24% hoch. Muss recherschieren wo das her kommt.

Das kommt aus der "Spannung Überwachung" in den Adapter Einstellungen. Wenn die Spannung in den kritischen Bereich fällt (dann ist der Akku definitiv fast leer) setzt er die Entladegrenze auf den aktuellen SOC-% des Systems, um diesen durch die hubState Einstellung "wenn Entladelimit erreicht abschalten" ausgeschaltet wird. Beim HUB1200/2000 hat das immer prima funktioniert. Mein Hyper bleibt aber leider online.

@stephanh sagte in Test Adapter Zendure Solarflow:

Guten Morgen zusammen,

hab nun seid einer Woche den aktuellen Adapter installiert und bekommen nun aufeinmal diese Meldung:

Verwende einen Hyper 2000.

Diese Meldung hatte ich noch nie gehabt. Mit dem Adapter in der Version 1.5.x lief alles ohne Probleme.

Danke für Tipps

Dein hubState unter "control" steht vermutlich auf "0 - Stop output and standby". Dadurch wird die Meldung verursacht. Ich muss aber dazu sagen das ich es bisher nicht geschafft habe das sich mein Hyper mit leerem Akku auch wirklich abschaltet. Solange dieser noch AC seitig verbunden ist bleibt der trotz der Einstellung online.

@astuermer sagte in Test Adapter Zendure Solarflow:

@nograx sagte in Test Adapter Zendure Solarflow:

@astuermer sagte in Test Adapter Zendure Solarflow:

setDeviceAutomationInOutLimit

Hi, 'setDeviceAutomationInOutLimit' funktioniert offensichtlich nicht in der Kombi HUB/ACE. Schon mal versucht den Befehl direkt auf dem Ace auszuführen? Ich kann das nicht mehr testen da ich keinen Hub/ACE besitze.

Da passiert denke ich nichts. Habs mit ein par Kommandos probiert, aber selbst in der Zendure App ist die Steuerung des Ace komplett gesperrt und man bekommt den Hinweis, dass bei einer Kopplung alles über den Hub gesteuert werden muss.

Was wäre der Nachteil, wenn man direkt über setInputLimit und setOutputLimit steuert?
smartMode habe ich bereits auf "true" gesetzt.

Danke.

Naja ist halt blanke Theorie, aber mit smartMode auf true solltest du save sein was das schreiben in den Flash angeht.

@astuermer sagte in Test Adapter Zendure Solarflow:

setDeviceAutomationInOutLimit

Hi, 'setDeviceAutomationInOutLimit' funktioniert offensichtlich nicht in der Kombi HUB/ACE. Schon mal versucht den Befehl direkt auf dem Ace auszuführen? Ich kann das nicht mehr testen da ich keinen Hub/ACE besitze.

Ich dürft gerne wenn ihr in Kontakt mit dem Support seid anmerken das sich Zendure mal mit mir in Verbindung setzt. Bisher werde ich da ignoriert.

@kiter1988 sagte in Test Adapter Zendure Solarflow:

Hub2000 + ACE1500 , 3x AB2000

Guten Morgen,

ich versuche verzweifelt meine Akkus mit den Funktionen des Adapters zu laden.
Es läuft bei mir alles lokal über mqtt.

Problem ist, dass der Datenpunkt "Auto Model" Energieplan immer wieder auf Smart Matching Mode springt und auf keiner meiner Einstellungen bleibt.

Wie gehe ich beim Laden vor ?
Welche Datenpunkte muss ich noch ändern ?

Aktuell stell ich folgendes ein.

• AC input mode
• auto model : nothing
• setDeviceAutomationInOutLimit: im negativen Bereich.

Es funktioniert leider keine einzige Kombination, immer wieder springt der Punkt auf "Smart Matching Mode".

Welche Adapterversion nutzt du? Zur aktuellen Beta habe ich da in der Funktion setDeviceAutomationInOutLimit noch mal was geändert. Das kann ich aber auch aufgrund der fehlenden Geräte nicht testen.

Ansonsten musst du den acMode (1 = Laden, 2 = Entladen) manuell schalten und dann mit setInputLimit (Ladeleistung) und setOutputLimit (Einspeiseleistung) die gewünschte Leistung vorgeben. smartMode idealerweise noch auf "true" setzen.

ZenSDK ist eine neue Schnittstelle von Zendure - ein Webserver der direkt auf dem Gerät läuft. Leider nur verfügbar auf den neuen SF 800er und dem SF 2400 AC. Da ich diese Geräte nicht besitze kann ich dieses neue SDK leider aktuell nicht implementieren...

@lesiflo sagte in Test Adapter Zendure Solarflow:

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

Irgendwelche Auffälligkeiten bisher? Hättest du mittlerweile einen Ausfall erwartet?

@maxclaudi sagte in Test Adapter Zendure Solarflow:

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.

Grundsätzlich alles richtig. Letzteres dürfte ja aber nur passieren wenn man in der Cloud noch Shelly, Steckdosen o.ä. konfiguriert hat und hier eine vollständige Konfiguration vorliegt. Wenn dann über ioBroker die deviceAutiomation genutzt wird kann es durchaus passieren das das kollidiert und gleichzeitg aus 2 Quellen Befehle geschickt werden. Wenn ich aber die Konfiguration in der App lösche sollte alles fein sein, denn was soll die Cloud an Befehlen senden wenn die gar keinen Trigger hat?