NEWS
Test Adapter Zendure Solarflow
Test Adapter Zendure Solarflow
-
@nograx sagte in Test Adapter Zendure Solarflow:
Ich gehe aktuell davon aus das es von der HA Integration noch deutlich mehr Installationen vorhanden sind als vom ioBroker Adapter. Hier müsste es doch also ne Menge Leute geben die Probleme haben. Auch hier gibt es Stand jetzt nur @lesiflo und ggf. dich?
Wenn hier so viele Hyper regelmäßig aussteigen würden, wäre das in den Github Issues deutlich sichtbar...Einige Nutzer haben über MQTT-Probleme berichtet, die möglicherweise von dieser Funktion stammen.
Auf die Schnelle fallen mir hier @Bernd1967 und @Murphy-0 ein (letzterer setzt nur sehr wenige Schreibvorgänge, 90–150).Es wird sicherlich viele User geben, die gar nicht wissen, woher die Probleme kommen, und etwas anderes vermuten – z. B. Router, Broker etc. – liest man doch häufiger.
Auffällig ist nur, dass die Probleme in Verbindung mit der neuen Funktion auftreten.
Einige Nutzer sind vermutlich auch nicht so technisch versiert.
Zum aktuellen HA Code Zendure-HA-1.1.4-pre2:
-
in allen Geräteklassen (hyper2000.py, hub2000.py, aio2400.py, …) wird "function": "deviceAutomation" gesendet – das ist der lokale Befehl.
-
In device.py taucht topic_function auf:
self.topic_function = f"iot/{self.prodkey}/{self.deviceId}/function/invoke" self.mqttPublish(self.topic_function, command)Das ist der MQTT-Topic für Befehle.
Dort gibt es auch mqttProperties, die eingehende Cloud-/Gerätenachrichten verarbeiten.Das bedeutet:
- Lokal gesetzte deviceAutomation -> MQTT-Publish geht raus.
- Cloud aktiv -> über dasselbe Topic kommt ebenfalls ein Befehl (function/invoke).
- Das Gerät empfängt also lokal und Cloud-Befehle über denselben Kanal.
Konfliktmechanismus (Cloud vs. Lokal):
- setDeviceAutomationInOutLimit schickt fixe Werte.
- Die Cloud schickt ebenfalls deviceAutomation (ihre Automatik-Parameter).
- Beide nutzen dasselbe Topic -> das Gerät führt den letzten Befehl aus.
Fazit:
- Ob mit oder ohne Freeze, der Ablauf ist logisch, weil man im SmartMatchingMode ist.
- Sobald Cloud verbunden und Mode 8 aktiv -> Cloud sendet kontinuierlich neue Automatik-Parameter.
- der lokale Code „hackt“ sich zwar rein, verliert aber gegen die Cloud-Syncs.
Wer die Situation selbst nachvollziehen möchte, kann bei aktiver Cloud-Verbindung lokal einen Proxy dazwischenschalten und den MQTT-Verkehr mitloggen. So lässt sich das Zusammenspiel von lokalen Befehlen und Cloud-Sync beobachten.
@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 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.
@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. -
@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.@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?
-
@nograx Bisher keine Ausfälle seit der Umstellung auf 2.0.3 und setDeviceAutomationInOutLimit mit Cloud
-
@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?
@nograx
Für mich ist das Thema an dieser Stelle abgeschlossen. Ob und wann die Cloud Befehle sendet oder eingreift, lässt sich ausschließlich durch gezielte Messungen (z. B. Proxy oder MQTT-Debug) sicher nachweisen. Spekulationen dazu führen nicht weiter. -
@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?
-
Moin @nograx
zu erst einmal vielen Dank für deine Entwicklung des Adapters. Ich nutze den Adapter nun schon sehr lange und es läuft sehr zufriedenstellend. Bei mir laufen die Zendure Geräte Hub2000+Ace im Offlinebetrieb.Ich bin über die neue Funktion setDeviceAutomationInOutLimit gestolpert. Durch die ganze Sache mit dem Flash hat das mein Interesse geweckt.
Ich verstehe nur nicht ganz den Zusammenhang zwischen der Funktion und den beiden Objekten autoModel und smartMode.Wenn ich die Limits per setDeviceAutomationInOutLimit setzten möchte, muss ich den smartMode auf true setzten richtig?
Der autoModel muss dann auf 0 (nothing) oder auf smart Matching Mode stehen? Ich vermute mal mit diesem Objekt lässt sich der Modus des Hubs einstellen. -
Neues zum Thema Flash/RAM.
Hier die Antwort von Zendure zum Thema Schreiben von Werten:
Die theoretische Lebensdauer des Flash-Speichers beträgt 100.000 Schreibzyklen. Bitte setzen Sie beim Ändern der Stromversorgung den Smartmode auf 1, um Schreibvorgänge im Flash-Speicher zu verhindern.
- Für den Smartmode ist ZenSDK erforderlich.
- Bitte beachten Sie den GitHub-Link und die beigefügten Screenshots: https://github.com/Zendure/zenSDK/blob/main/docs/en_properties.md
Problem bei meinem 2400 ac: Über MQTT bekomme ich kein Objekt "Smartmode". Mit dem vom Support angesprochenen ZenSDK kann ich nix anfangen.
-
Neues zum Thema Flash/RAM.
Hier die Antwort von Zendure zum Thema Schreiben von Werten:
Die theoretische Lebensdauer des Flash-Speichers beträgt 100.000 Schreibzyklen. Bitte setzen Sie beim Ändern der Stromversorgung den Smartmode auf 1, um Schreibvorgänge im Flash-Speicher zu verhindern.
- Für den Smartmode ist ZenSDK erforderlich.
- Bitte beachten Sie den GitHub-Link und die beigefügten Screenshots: https://github.com/Zendure/zenSDK/blob/main/docs/en_properties.md
Problem bei meinem 2400 ac: Über MQTT bekomme ich kein Objekt "Smartmode". Mit dem vom Support angesprochenen ZenSDK kann ich nix anfangen.
@michi-0 sagte in Test Adapter Zendure Solarflow:
Neues zum Thema Flash/RAM.
Hier die Antwort von Zendure zum Thema Schreiben von Werten:
Die theoretische Lebensdauer des Flash-Speichers beträgt 100.000 Schreibzyklen. Bitte setzen Sie beim Ändern der Stromversorgung den Smartmode auf 1, um Schreibvorgänge im Flash-Speicher zu verhindern.
- Für den Smartmode ist ZenSDK erforderlich.
- Bitte beachten Sie den GitHub-Link und die beigefügten Screenshots: https://github.com/Zendure/zenSDK/blob/main/docs/en_properties.md
Problem bei meinem 2400 ac: Über MQTT bekomme ich kein Objekt "Smartmode". Mit dem vom Support angesprochenen ZenSDK kann ich nix anfangen.
Herzlichen Dank, das bestätigt meine Tests und Analysen.
edit:
Hier eine kleine Hilfe. -
Neues zum Thema Flash/RAM.
Hier die Antwort von Zendure zum Thema Schreiben von Werten:
Die theoretische Lebensdauer des Flash-Speichers beträgt 100.000 Schreibzyklen. Bitte setzen Sie beim Ändern der Stromversorgung den Smartmode auf 1, um Schreibvorgänge im Flash-Speicher zu verhindern.
- Für den Smartmode ist ZenSDK erforderlich.
- Bitte beachten Sie den GitHub-Link und die beigefügten Screenshots: https://github.com/Zendure/zenSDK/blob/main/docs/en_properties.md
Problem bei meinem 2400 ac: Über MQTT bekomme ich kein Objekt "Smartmode". Mit dem vom Support angesprochenen ZenSDK kann ich nix anfangen.
@michi-0 sagte in Test Adapter Zendure Solarflow:
Neues zum Thema Flash/RAM.
Hier die Antwort von Zendure zum Thema Schreiben von Werten:
Die theoretische Lebensdauer des Flash-Speichers beträgt 100.000 Schreibzyklen. Bitte setzen Sie beim Ändern der Stromversorgung den Smartmode auf 1, um Schreibvorgänge im Flash-Speicher zu verhindern.
- Für den Smartmode ist ZenSDK erforderlich.
- Bitte beachten Sie den GitHub-Link und die beigefügten Screenshots: https://github.com/Zendure/zenSDK/blob/main/docs/en_properties.md
Problem bei meinem 2400 ac: Über MQTT bekomme ich kein Objekt "Smartmode". Mit dem vom Support angesprochenen ZenSDK kann ich nix anfangen.
Das ist ja interessant, ich habe fast die selbe Antwort vom Support. Nur hält bei mir der Speicher nur 10.000 Schreibzyklen. Ich bekomme auch kein Objekt Smartmode. Und mit ZenSDK kann ich auch nichts anfagen.
-
Neues zum Thema Flash/RAM.
Hier die Antwort von Zendure zum Thema Schreiben von Werten:
Die theoretische Lebensdauer des Flash-Speichers beträgt 100.000 Schreibzyklen. Bitte setzen Sie beim Ändern der Stromversorgung den Smartmode auf 1, um Schreibvorgänge im Flash-Speicher zu verhindern.
- Für den Smartmode ist ZenSDK erforderlich.
- Bitte beachten Sie den GitHub-Link und die beigefügten Screenshots: https://github.com/Zendure/zenSDK/blob/main/docs/en_properties.md
Problem bei meinem 2400 ac: Über MQTT bekomme ich kein Objekt "Smartmode". Mit dem vom Support angesprochenen ZenSDK kann ich nix anfangen.
@michi-0 sagte in Test Adapter Zendure Solarflow:
Bitte setzen Sie beim Ändern der Stromversorgung den Smartmode auf 1
Was bedeutet das? Gilt das nur für AC2400?
Kann man den Support einfach so anschreiben, auch wenn man keinen Defek (am Gerät) sondern nur eine oder zwei Fragen hat? -
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...
-
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".
-
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".
@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...
Kann ich dir irgendwelche Daten zur Verfügung stellen für eine Implementierung?
Was ich nicht verstehe, dass Zendure selbst die Ausgabe über MQTT anbietet und dann nicht alle Daten (SmartMode) zur Verfügung stellt bzw. übermittelt. Aktuell hoffe ich, dass das bei dem 2400ac ggf. gar nicht mehr notwendig ist, da ohnehin alles in den RAM geschrieben wird... Die Hoffnung stirbt zuletzt. Zumindest nach meinem Flash-Speicher. Bei mehr als 1.000 Schreibvorgängen pro Tag muss ich mir bald was neues einfallen lassen. Aktuell ist der Support dran und bat mich um Screenshots der in ioBroker ausgegeben Daten.
Bei mir hat der Support immer relativ zeitnah reagiert. Ich denke die sind auch bei Fragen ohne Defekten zur Stelle.
-
Kann ich dir irgendwelche Daten zur Verfügung stellen für eine Implementierung?
Was ich nicht verstehe, dass Zendure selbst die Ausgabe über MQTT anbietet und dann nicht alle Daten (SmartMode) zur Verfügung stellt bzw. übermittelt. Aktuell hoffe ich, dass das bei dem 2400ac ggf. gar nicht mehr notwendig ist, da ohnehin alles in den RAM geschrieben wird... Die Hoffnung stirbt zuletzt. Zumindest nach meinem Flash-Speicher. Bei mehr als 1.000 Schreibvorgängen pro Tag muss ich mir bald was neues einfallen lassen. Aktuell ist der Support dran und bat mich um Screenshots der in ioBroker ausgegeben Daten.
Bei mir hat der Support immer relativ zeitnah reagiert. Ich denke die sind auch bei Fragen ohne Defekten zur Stelle.
@michi-0 Hab den Support deswegen auch mal angetriggert.
Komme bei mir auch auf sehr viele Schreibzyklen, weil die Zendure Batterie noch in Abhängigkeit meiner SolarEdge Batterie agieren muss.IOB mekert auch ich hätte zu viele Subsciptions

VG
-
Kann ich dir irgendwelche Daten zur Verfügung stellen für eine Implementierung?
Was ich nicht verstehe, dass Zendure selbst die Ausgabe über MQTT anbietet und dann nicht alle Daten (SmartMode) zur Verfügung stellt bzw. übermittelt. Aktuell hoffe ich, dass das bei dem 2400ac ggf. gar nicht mehr notwendig ist, da ohnehin alles in den RAM geschrieben wird... Die Hoffnung stirbt zuletzt. Zumindest nach meinem Flash-Speicher. Bei mehr als 1.000 Schreibvorgängen pro Tag muss ich mir bald was neues einfallen lassen. Aktuell ist der Support dran und bat mich um Screenshots der in ioBroker ausgegeben Daten.
Bei mir hat der Support immer relativ zeitnah reagiert. Ich denke die sind auch bei Fragen ohne Defekten zur Stelle.
@michi-0 sagte in Test Adapter Zendure Solarflow:
Kann ich dir irgendwelche Daten zur Verfügung stellen für eine Implementierung?
Was ich nicht verstehe, dass Zendure selbst die Ausgabe über MQTT anbietet und dann nicht alle Daten (SmartMode) zur Verfügung stellt bzw. übermittelt. Aktuell hoffe ich, dass das bei dem 2400ac ggf. gar nicht mehr notwendig ist, da ohnehin alles in den RAM geschrieben wird... Die Hoffnung stirbt zuletzt. Zumindest nach meinem Flash-Speicher. Bei mehr als 1.000 Schreibvorgängen pro Tag muss ich mir bald was neues einfallen lassen. Aktuell ist der Support dran und bat mich um Screenshots der in ioBroker ausgegeben Daten.
Bei mir hat der Support immer relativ zeitnah reagiert. Ich denke die sind auch bei Fragen ohne Defekten zur Stelle.
Das selbe wollte der Support von mir auch. Weil auch bei mir der Smartmode fehlt