NEWS
Test Adapter Zendure Solarflow
-
@nograx Ich habe ein Phänomen festgestellt. Und zwar sehe ich zu Zeiten, wo der Hub1200/Akku nichts mehr abgeben sollte eine Entladeleistung des Akkus von 7 W. Hat das auch sonst jemand schon festgestellt oder hab nur ich das?
-
@rene55 sagte in Test Adapter Zendure Solarflow:
@nograx Ich habe ein Phänomen festgestellt. Und zwar sehe ich zu Zeiten, wo der Hub1200/Akku nichts mehr abgeben sollte eine Entladeleistung des Akkus von 7 W. Hat das auch sonst jemand schon festgestellt oder hab nur ich das?
Das habe ich mit eingebaut, soll im Prinzip den "Standby"-Verbrauch symbolisieren. Denn wenn das Gerät online ist und nichts über Solar rein kommt verbraucht es ja trotzdem Strom... da es zu Verwirrung führt überlege ich tatsächlich das komplett zu entfernen.
-
@nograx Danke für die Erklärung. Ja in der Tat, das hat mich (etwas) verwirrt.
-
@nograx Im Adapter 1.13.1 erwähntest du 'TEST: Set Smart CT Mode and Smart Matching Mode correctly - Feedback needed!'. Was bedeutet das, was brauchst du und kann ich dir mit dem HUB1200 dabei helfen?
-
@nograx, habe das noch einmal im Debug durchgespielt. Folgendes kommt da rein:
2025-05-21 11:02:04.476 - debug: zendure-solarflow.0 (188222) [onMessage] MQTT message: {"messageId":1226,"method":"error","deviceId":"xxx","timestamp":1747818123,"offData":1,"data":[{"code":63,"timestamp":1747818036},{"code":223,"timestamp":1747818123}]}
Ich habe aber jetzt aufgegeben. Habe nochmal alles neu verkabelt, abgesteckt, angesteckt. Das Ding geht sofort auf den Fehler, sobald ich ihn auf die Batterien setze. Ohne klappt es. Ich werde jetzt die Rücksendung einleiten und habe grad den Hub2000 wieder angeschlossen, der sofort ohne Probleme losläuft.
-
@the_stig sagte in Test Adapter Zendure Solarflow:
@nograx, habe das noch einmal im Debug durchgespielt. Folgendes kommt da rein:
2025-05-21 11:02:04.476 - debug: zendure-solarflow.0 (188222) [onMessage] MQTT message: {"messageId":1226,"method":"error","deviceId":"xxx","timestamp":1747818123,"offData":1,"data":[{"code":63,"timestamp":1747818036},{"code":223,"timestamp":1747818123}]}
Ich habe aber jetzt aufgegeben. Habe nochmal alles neu verkabelt, abgesteckt, angesteckt. Das Ding geht sofort auf den Fehler, sobald ich ihn auf die Batterien setze. Ohne klappt es. Ich werde jetzt die Rücksendung einleiten und habe grad den Hub2000 wieder angeschlossen, der sofort ohne Probleme losläuft.
Hm schade, da müsste man tatsächlich eine Liste haben welcher code zu welcher Fehlermeldung gehört.
-
@rene55 sagte in Test Adapter Zendure Solarflow:
@nograx Im Adapter 1.13.1 erwähntest du 'TEST: Set Smart CT Mode and Smart Matching Mode correctly - Feedback needed!'. Was bedeutet das, was brauchst du und kann ich dir mit dem HUB1200 dabei helfen?
Geht darum ob und wie gut das funktioniert den Smart CT Modus umzuschalten. Da werden einige weitere Parameter gesetzt und erzwungen. Mir geht es um Feedback ob es generell funktioniert bzw. was nicht.
-
@nograx Damit kann ich leider nicht dienen
Aber: ggf. wäre es ja schon hilfreich, wenn du nach Error filterst und das in einem Objekt ausgibst. In dem Falle wäre ich ja mit Error Code 223 schon weiter gekommen mit einer Google-Suche. Das habe ich jetzt halt erst gesehen, nachdem ich wieder mit der Cloud verbunden war (wobei: mit einer Bluetooth-Verbindung wäre es ja auch gegangen, habe ich nicht dran gedacht...)
-
@nograx Ich denk, da muss ich passen - bin cloudless.
-
@rene55 aber in der Theorie muss es doch auch cloudless mit dem CT gehen. Am Ende bekommt der HUB/Hyper oder was weiß ich doch auch nur per MQTT einen Wert mit dem er einspeist was der Bedarf sagt. Müsste nur einer rausfinden, würde es probieren aber ich habe weder Shelly noch EcoTracker und daher nie CT genutzt. Wäre aber interessant für die Entwicklung des Adapters. Das würde noch mehr bekehren wenn das geht
-
@felli Dann habe ich den Begriff "Smart CT Modus" falsch gedeutet. Aktuell versuche ich über "zendure-solarflow.0.73bkTV.Asd3Qz12.control.setOutputLimit" meinen Netzbezug zu minimieren.
Dazu errechne ich anhand des aktuellen Bezugs aus dem Netz einen Wert, den ich hier reinschreibe. Den Bypass lasse ich generell auf "Off" und das klappt (solange der Akku liefert) nach meinen Beobachtungen recht gut. -
@rene55 ja das geht auch gut, habe ich eine ganze Weile so gemacht nur OpenDTUonBattery war mir am Ende lieber.
-
@felli Wenn man so ein Dingens hat, ok. Ich hab ja nur einen Deye, der kennt sowas nicht.
-
@nograx
Hallo Nograx,hab eine Frage zum neuen Adapter:
Welche Kalkulationen hat du genau entfernt ?
Weil ich davon einige verwende, welche da wohl rausfallen werden.
Bzw, kommen nach dem Update des Adapter diese Daen dann über die Zendure Cloud in den IOBroker ?
Danke und Gruß Stephan
-
@stephanh sagte in Test Adapter Zendure Solarflow:
@nograx
Hallo Nograx,hab eine Frage zum neuen Adapter:
Welche Kalkulationen hat du genau entfernt ?
Weil ich davon einige verwende, welche da wohl rausfallen werden.
Bzw, kommen nach dem Update des Adapter diese Daen dann über die Zendure Cloud in den IOBroker ?
Danke und Gruß Stephan
Moin, da fallen keine States raus. Die Berechnungen macht der Adapter. Ich habe da einige Effizienz-Berechnungen mit eingebaut (Lade und Entladeverluste je nach abgerufener Leistung). Diese habe ich in dem Update entfernt, da ich bei mir festgestellt habe das die irgendwie gar nicht mehr passten. Es scheint auch so das Zendure diese jetzt in den Leistungswerten berücksichtigt, Beispiel wenn von Solar 600 Watt kommen, zeigen die Werte der Ladeleistung meist nur ca. 560 Watt. Ich nehme an das der Rest bereits die Ladeverluste inkludiert. Daher habe ich meine zusätzlichen Berechnungen entfernt.
-
Hi,
danke die für die Info.
Hab gerade den Adapter aktualisiert und es läuft alles wie gehabt.Gruß Stephan
-
@nograx sagte in Test Adapter Zendure Solarflow:
Beispiel bei den Batterien: Mein ACE 1500 sendet den SOH (State of Health) der Batterie. Der HUB 2000 der im gleichen System arbeitet z.B. nicht.
Bei mir ist es umgekehrt.
SoH kommt vom HUB2000{"messageId":"123","product":"solarFlow","deviceId":"XXXXXXXX","timestamp":1748147072,"properties":{},"packData":[{"power":10,"socLevel":68,"state":2,"maxTemp":2931,"totalVol":5000,"maxVol":333,"minVol":333,"softVersion":4113,"soh":999,"sn":"XXXXXXXXXXXXXXX"}]}
power: 10 und state: 2?
zusätzlich kommen vom Hub2000 auch noch:
{"messageId":"123","product":"solarFlow","deviceId":"XXXXXXXX","timestamp":1748078649,"properties":{"electricLevel":100,"solarInputPower":36,"outputHomePower":32,"solarPower2Cycle":35,"outputHomePowerCycle":36,"solarPower2":36}}
{"messageId":"123","product":"solarFlow","deviceId":"XXXXXXXX","timestamp":1748147108,"properties":{"electricLevel":69,"solarPower2Cycle":24,"packInputPowerCycle":17,"outputHomePowerCycle":103,"solarPower1Cycle":62}}
solarPower1Cycle: 13 ?
solarPower2Cycle: 12 ?
outputHomePowerCycle: 22 ?
packInputPowerCycle:17 ?
ACE1500
ACE1500 Akku:
packData.power: 0 ?ACE1500 properties:
acDelay: 720 ?
power: 0 ?
versuche auszuwerten.
Wenn jemand zu den Daten was weiß oder vermutet, bin über Hilfe dankbar.
Erstaunlich, wie schnell die Daten kommen.
Seit MQTT-Broker lokal, mit Authentication und Version >= 1.13.x ohne Neustart des Adapters: fehlerfrei und flüssig.@nograx
Erzwingt der Adapter die Datenabfrage zusätzlich mit{"properties":["getAll"]}
Wenn ja, in welchem Intervall?
Mich wundert es z. B., dass 4x hintereinander die identischen Temperatur-Werte von einem Akku übertragen wurden. Intervall <= 2sek.:
{"messageId":"123","product":"solarFlow","deviceId":"XxXXXxxX","timestamp":1748079345,"properties":{},"packData":[{"maxTemp":2911,"sn":"XXXXXXXXXXXXXXX"}]} {"messageId":"123","product":"solarFlow","deviceId":"XxXXXxxX","timestamp":1748079347,"properties":{},"packData":[{"maxTemp":2911,"sn":"XXXXXXXXXXXXXXX"}]} {"messageId":"123","product":"solarFlow","deviceId":"XxXXXxxX","timestamp":1748079348,"properties":{},"packData":[{"maxTemp":2911,"sn":"XXXXXXXXXXXXXXX"}]} {"messageId":"123","product":"solarFlow","deviceId":"XxXXXxxX","timestamp":1748079350,"properties":{},"packData":[{"maxTemp":2911,"sn":"XXXXXXXXXXXXXXX"}]} {"messageId":"123","product":"solarFlow","deviceId":"XxXXXxxX","timestamp":1748079352,"properties":{},"packData":[{"maxTemp":2911,"sn":"XXXXXXXXXXXXXXX"}]}