Test Adapter Zendure Solarflow
-
@maxclaudi Alles Gut. Ich hab mich nicht angegriffen gefühlt. Mach ruhig weiter so, und musst auch nicht jedes Wort auf die Goldwaage legen. Bin ja schon recht froh, dass hier so einiges Diskutiert und offen gelegt wird.
UND: Verstehen tue ich dich gut
-
@rene55 sagte in Test Adapter Zendure Solarflow:
sogar nachts bei knapp 320-380W.
Das könnte man doch gut abfangen.
z. B.: man weiß, dass ab einer bestimmten Uhrzeit (meistens) nicht mehr gekocht wird, keine Großverbraucher wie Waschmaschine etc. laufen und man schläft oder nur TV sieht, höchstens kaltes Essen mit Gästen etc.Ab x Uhr bis 5 Uhr fix outputLimit: 400W solange Bat > minSoc.
Bin jetzt mal auf 5 Minuten Mess/Regel-Interval.
Evtl. besser als nur das Intervall wären mehr Bedingungen für Entscheidungen (ob und welcher Wert und bis zu welchem Umfang gültig) outputLimit gesetzt werden soll.
-
Nur noch mal für mein Verständnis: das Problem mit dem zu häufigen Schreiben in den Flash ist beim Hyper mit der neuer Steuerung von @nograx nicht mehr vorhanden, oder?
-
@maxclaudi Ja, das wäre die einfache Version, die ich bis vor einigen Wochen in Betrieb hatte. Outputlimit etwas unter dem ermittelten Verbrauch nachts, einschalten gegen 20:00 Uhr und dann einspeisen lassen bis socMin erreicht ist. Ich hatte angenommen, wenn ich die Regelung über Tag mache könnte ich noch ein quäntchen mehr sparen, weil dann -in der bezugsarmen Zeit - der Akku wieder nachgeladen wird. Mal sehen, vllt. gibt es einen Mittelweg. Aktuell ist der SOC noch bei 31%, so dass mein Script noch gar nicht geschaltet hat.
-
@the_stig sagte in Test Adapter Zendure Solarflow:
Nur noch mal für mein Verständnis: das Problem mit dem zu häufigen Schreiben in den Flash ist beim Hyper mit der neuer Steuerung von @nograx nicht mehr vorhanden, oder?
Das Problem ist weiterhin vorhanden.
Ungewiss in welchem Ausmaß. Vermutlich komplett.Wenn Du unsicher bist, teste und schreib support an und hoffe auf eine Antwort.
Dazu müsstest aber behaupten, dass Du HA benutzt und Glück haben, dass Zendure die Integration i. V. mit einem Hyper und der Funktion invoke überhaupt als Bestandteil von Zendure anerkennt.Bisher denke ich aufgrund Tests, logging und Geräteverhalten (siehe meine vorherigen Beiträge), dass immer in den Flash geschrieben wird.
Auch bei den neuen Geräten.Gleichgültig welches autoModel benutzt wird, welche Strategie und mapping verwendet wird und ob es Zendure auch so macht.
Es wird in den Flash geschrieben.
Bei automatic modes (Energiepläne) sorgt die Firmware z. T. eigenständig durch Entscheidungen wie oft z. T. geschrieben wird und ob in einem gewissen Rahmen neue Werte häufiger oder seltener geschrieben werden.
Letzten Endes wird aber in Consumer-Geräte meistens in den Flash geschrieben.Wenn man SmartMatchingMode entfremdet und gibt selbständig oft neue Werte (der Wert muss gar nicht unbedingt als absolut angesehen werden, sondern könnte ein Rahmenwert für eigene Entscheidungen durch die Firmware sein, die sie aber nicht mehr umsetzen könnte, weil weitere, ständige Parameter zur Auswertung nun fehlen(?)), dann kommt nicht nur einiges durcheinander, dann stimmt die ganze "vorhergesehene/bestimmte/erwartete" Ablaufsteuerung, nicht mehr.
Am Ende landet die eigentliche Anforderung im Flash.
Ob nun über outputLimit gesetzt oder über funktion invoke.Die Code-Analyse von HA bringt auch nichts weiter außer, dass in einem anderen autoModel über die Funktion invoke geschrieben wird.
Der adapter-Code hat als Basis den HA-Code und ist noch reduzierter.Bis jetzt habe ich dazu nur nebulöse und schwammige Antworten erhalten, wie:
"macht Zendure genau so" (meine Interpretation: richtig, ins Flash speichern. Consumer-Gerät)
"kann ich mir nicht vorstellen" usw.Bei harten Tests, die durchgeführt wurden, blieben die Einstellungen erhalten.
Auch beim hyper -> Flash.Das deckt sich auch mit der Antwort von Zendure für neue Geräte, dass Werte in den Flash gespeichert werden.
Selbst wenn Zendure eine eigene Entwicklungsabteilung hat/hätte und die nicht outsourced ist, dann ist es unwahrscheinlich, dass das geändert wird.
Kostet Geld und außerdem ist wear-leveling ins Flash bei Consumer-Geräten anscheinend üblich.Würde mich freuen, wenn man meine Aussagen/Tests/Reverse Engineering/logs mit Beweisen widerlegen würde.
Behauptungen und Diskussionen führen nicht weiter, wenn sie nicht durch Aussagen von Zendure oder durch reproduzierbare Tests (gilt auch für Zendure) untermauert werden.
-
@rene55 sagte in Test Adapter Zendure Solarflow:
Den ByPass-Mode nutze ich gar nicht mehr (Relais).
Ist ein Argument.
Jeder wie er möchte.Für mich selbst sehe ich das bei meinem HUB2000 nicht kritisch.
Wenn keine Last vorhanden, kann ein Relais bedenklos geschaltet werden.
Kritisch bei mir wäre das Bypass Einschalten.Folgendes betrifft Bypass Modus: automatic (passMode: 0) bei meinem HUB2000
Wer den Ablauf von Zendure analysiert hat, der wird schnell erkennen, dass vor dem Einschalten in den Bypass (wenn Batterien voll sind) die PV-Leistung der Eingänge reduziert werden bis auf: ~0.
Dann erfolgt immer wieder eine Ruhepause für die Batterien (bis sie etwas abgekühlt sind etc.) und dann wird wieder mit ein paar wenigen Watt nachgeladen.Die PV-Eingangsleistung bleibt zwischen 0 und stark reduziert.
Das wiederholt sich je nach Batteriezustand ein paar mal.
Dann wird umgeschaltet und die PV-Eingänge werden hoch gefahren.
Nicht mit einem simplen Umschalten.
Das suggerieren nicht nur die Werte (Datenpunkte/mqtt) sondern auch real die Leistung vom Wechselrichter und die Daten des Zählers.
Bedeutet für mich: ein hartes Umschlten nur durch Relais unter Last wird nicht durchgeführt.
Erst wird am Eingang der Strom gedrosselt.Wie das außerhalb des automatic-Bereich aussieht und der Strom dort auch gedrosselt wird, kann ich nicht beurteilen.
Kann gut sein, dass bei manuellem Umschalten auf passMode:1 oder passMode:2 sofort geschaltet wird.
Habe das außer Acht gelassen, weil für mich nicht wichtig.Bei mir steht Bypass normal auf automatic.
Der Bypass wird per script ausgeschaltet, wenn PV-Eingangsleistung <20W über 3min und frühestens 4 Stunden vor Sonnenuntergang.
<20W ist eigentlich keine Leistung für ein Relais und müsste es leicht aushalten.Wann schaltet der automatic-Modus (passMode:0) um?
automatic Modus schaltet allein um, wenn ca 20W über eine Zeit von >= 5min ist und zusätzlich ein weiterer Parameter (den ich bisher nicht sicher ausfindig machen konnte) wirkt. Vermutlich auch die Zeit.Das funktionierte für mich mal gut, mal weniger gut.
Deshalb schaltet mein script den automatic-Modus bei sehr geringer Eingangsleistung und abhängig vom Sonnenuntergang um.
Den Bypass auf automatic schalte ich in der Nacht wieder ein.
Keine PV-Leistung vorhanden = keine Last am Relais.Sollte das Relais irgendwann wirklich defekt sein, dann wäre das mein kleinstes Problem.
Sollte Zendure nicht austauschen, dann würde ich es selbst vornehmen. -
@maxclaudi Danke für die perfekte Erklärung. Ich denke, das wird auch der richtige Ansatz für meine 'neue' Steuerung.
-
@rene55
wie geschrieben, beziehen sich die Angaben auf meinen HUB2000.
Vermutlich wird das auch beim HUB1200 so sein.
Um sicher zu gehen, könntest Du heute bei Dunkelheit auf automatic schalten.
Beobachte dann Morgen selbst die relevanten Daten vor und beim Umschalten.
Auch Wechselrichter und Zähler. -
@maxclaudi Hab ich gerade schon auf automatik umgestellt - bei SolarInput <60W wohl kein Problem. Dann bau ich meine Steuerung mit dem hier erlangten Wissen nochmal Stück für Stück auf. Auf ein langes HUB-Leben !
-
@rene55 sagte in Test Adapter Zendure Solarflow:
Auf ein langes HUB-Leben !
möge die Sonne mit uns sein
-
Hi zusammen,
ich bekomme es leider nicht hin, meinen Hyper 2000 in den Offline-Modus zu versetzen. Vielleicht kann mir jemand von euch einen Tipp geben, welchen Fehler ich mache.
Ich nutze das Windows-Tool zendure-cloud-disconnector. Darin finde ich den Hyper, trage die neue MQTT-IP-Adresse ein (natürlich mit WLAN). In meinem Fall läuft der MQTT-Broker auf dem ioBroker mit der Endung .25.
Die Adapter-Einstellungen habe ich unverändert gelassen, bis auf die Option „Serverbetrieb“.
Sobald ich den Hyper auf die lokalen MQTT-Einstellungen umschalte, verbindet er sich aber nicht mit dem Broker.
Eventuell mache ich auch beim Neustart etwas falsch:Ich halte ca. 6 Sekunden die IoT-Taste gedrückt (manchmal höre ich ein kurzes Relais-Klicken).
Dann ziehe ich das Schuko-Stromkabel für ein paar Sekunden ab.
Anschließend starte ich wieder über die IoT-Taste.
Im WLAN ist der Hyper danach erreichbar, aber am Broker meldet er sich nicht an.
Danke schon mal im Voraus für eure Hilfe
-
-
@iboriz sagte in Test Adapter Zendure Solarflow:
Ich nutze das Windows-Tool zendure-cloud-disconnector. Darin finde ich den Hyper, trage die neue MQTT-IP-Adresse ein (natürlich mit WLAN). In meinem Fall läuft der MQTT-Broker auf dem ioBroker mit der Endung .25.
Nach:
Disconnector wurde gestartet, dann
- Hast Du auf den Button "Discover Zendure Devices" geklickt.
- Dein hyper wurde angezeigt?
- Dann evtl. hyper markiert?
- auf den Button "Get Telemetry" geklickt?
- Dann wurde die DeviceID und ein paar Daten angezeigt?
- dann hast Du alle Daten "fehlerfrei" eingetragen?
- zum Schluss auf den Button "Connect to local MQTT" geklickt?
- Nun hast Du die BT-Verbindung komplett ausgeschaltet?
- Die Zendure App hat keine Verbindung und ist sicherheitshalber auch komplett beendet (BT am Smartphone aus)?
- Du hast den Hyper unbedingt einmal neu gestartet, damit die Änderungen wirksam werden?
- Du hast einen MQTT-Broker (Server) mit der identischen IP (wie im Disconnector angegeben) MIT Port: 1883 und OHNE Zugangsdaten?
bekommst Du keine Verbindung zwischen Hyper und dem Broker?
Wenn du einen Broker mit Zugangsdaten verwenden möchtest, dann ist user: <deviceID> und das Passwort dazu kannst Du HIER ermitteln.
-
@homoran Ich sehe eben das sich kein Client mit dem Broker verbunden hat.
Aber auch unter den Objeten:
Wenn ich natürlich den Zendure Adapter auf den Lokalen MQTT einstelle dann sehe ich zumindest das der Adapter mit verbunden ist.
Daher habe ich dann auch keine neuen Werte im Zendure Adapter das diese über MQTT erst gar nicht ankommen.Ja, Schritte 1-7 habe ich genauso ausgeführt, wie gesagt kann ich danach den Hyper ja auch wieder mit der Zendure Cloud verbinden das funktioniert.
Aber Punkt 8-9 habe ich noch nicht gemacht.
Das bedeutet ich deaktiviere die BT Verbindung am PC und Handy und lösche den Hyper aus der Zendure APP? Oder wie ist das gemeint die Zendure App hat keine Verbindung?Wie gesagt nutze den MQTT Broker/Client Adapter, Port ist auf Standart und kein Benutzer/Kennwort wurde gesetzt.
-
@iboriz
solange eine BT-Verbindung zum hyper aktiv ist, wird nichts über mqtt übertragen.
Die App muss nicht gelöscht sein. Aber sicherheitshalber komplett beendet.
Nicht, dass eine BT-Verbindung in Reichweite hergestellt wird oder aktiv ist.
Das gleiche gilt natürlich auch für das Notebook oder was auch immer, auf dem Disconnector ausgeführt wird/wurde. -
@maxclaudi Danke, ich hab's jetzt so nochmal versucht und das Programm geschlossen und Bluetooth am PC deaktiviert,
Auch am Handy BT deaktiviert und die Zendure APP geschlossen, zusätzlich noch den Zendure Adapter pausiert da er ja noch Daten abfragt.
(Ich habe den Hyper auf ein zweiten Account geteilt und frage darüber über die Cloud die Daten ab.)Nach dem Neustart vom Hyper meldet er sich aber am Broker nicht an.
Dann starte ich die Windows App wieder und setze es auf die Cloud zurück und nach einem Neustart ist der Hyper wieder da.
(muss ihn dann meist mehrmals neu starten da er dann im Bypass Modus hängt) -
@maxclaudi
Ich habe mich jetzt auch mal um das Thema Hyper2000 Leben bemüht.
Meine Ausgangslage war, dass im Schnitt beim Hyper alle 15 Sec. ein Wert an setDeviceAutomationInOutLimit gesendet wurde.Habe jetzt eine Hysterese eingebaut die bei Veränderungen +40 bis -40 nicht reagiert. ALS Eingangsleistung nehme ich 40.
Meine Steuerung für die Hysterese sieht so aus:
Soweit funktioniert es und reduziert die Schreibvorgänge.
Ist das eine sinnvolle Einstellung oder was würdest du ändern.
Sollte man das noch zusätzlich durch eine Zeitsteuerung ergänzen, z.B. auf 1x pro X Minute reduzieren. Oder lieber die Hysterese vergrößern?
-
@murphy-0 ich hab mir sowas ähnliches gebaut. Allerdings hilft das nur dann, wenn man relativ gleichmäßige Verbraucher hat. Bei mir sind der Trocker und die Siebträger-Kaffeemaschine echt die Hölle für die Nullregelung. Kurze, hohe Impulse. Da hilft die Hystere auch nicht. Das Problem ist halt, wenn man da noch eine 60-Sekunden-Regel einbaut, dann schaltet es halt extrem träge.
-
@iboriz
irgend was ist nicht richtig oder zu ungeduldig etc.müsste mit Geduld klappen:
-
MQTT-Broker mit ip + Port:1883 + OHNE Zugangsdaten einrichten und starten.
-
solarflow-Adapter in Instanz unter Server auf "lokaler Matt Server" umstellen,
"lokale MQTT Server URL/IP: <IP Broker> speichern, neu-starten. -
Kontrollieren ob Adapter sich mit Broker verbindet.
-
Zendure-App beenden. Muss komplett beendet sein. Nicht im Hintergrund aktiv oder Smartphone während der Zeit ausschalten.
Bei lokalem Broker kann App sowieso nicht mehr verwendet werden (außer später über BT). -
Internetverbindung für die IP von den Zendure-Geräten über den Router sperren.
-
Rechner mit BT und einsatzbereiten Disconnector starten
-
Button "Discover Zendure Devices" klick
-
Zendure Gerät wird angezeigt?
-
Gerät markieren.
-
Button "Get Telemetry" klick
-
DeviceID und ein paar Daten werden angezeigt?
-
Alle geforderten Daten fehlerfrei eintragen. Nur IP ohne port und ohne prefix z.B. 192.168.2.50
Wifi-Password am besten nur mit alphanumerischen Zeichen. -
zum Schluss auf den Button "Connect to local MQTT" klick
-
Bei erfolgreicher Ausführung vom Disconnector:
Disconnector beenden und sicherstellen, dass der Disconnector beendet ist und BT am Rechner ausschalten. -
Nochmals sicherstellen, dass wirklich keine BT-Verbindung aktiv ist und am besten Smartphone ausgeschaltet ist, wenn
man nicht sicher ist, dass die App beendet ist. -
Zendure Gerät(e) unbedingt neu starten, damit die Änderungen wirksam werden.
-
Zendure-Geräte sollten sich nun mit dem Broker verbinden.
Auch wenn nicht sofort Daten empfangen werden.
Aber zumindest nur die Verbidnung zum laufenden Broker sollte hergestellt werden.
Optional:
18. über einen MQTT-Client oder mit z. B. MQTT-Explorer getAll (Datenabfrage) publishen.
MQTT-Explorer:
Name: beliebig
Validate certificate: deaktiviert
Encrypton (tls): deaktiviert
Protokoll: mqtt://
Host: <IP> z.B.: 192.168.2.50
Port: 1883
User: leer
Password: leer
unter "advanced" zusätzlich eintragen:
<productId>/deviceId/#
Beispiel Hyper: gDa3tb/AyBcde2h/#TOPIC: iot/<productId>/<deviceId>/properties/read
json: {"properties": ["getAll"]}Solange eine BT-Verbindung zum Zendure-Gerät aktiv ist, wird nichts über mqtt übertragen.
Notfalls am Ende, wenn Zendure-Gerät neu gestartet wurde, nach ~1min den Broker mal neu starten.
Wenn der mqtt-Adapter von iob verwendet wird, bitte neueste Version v6.1.2 verwenden.
iob sollte auch einwandfrei funktionieren mit updates etc. -
-
@murphy-0 sagte in Test Adapter Zendure Solarflow:
@maxclaudi
Ich habe mich jetzt auch mal um das Thema Hyper2000 Leben bemüht.
Meine Ausgangslage war, dass im Schnitt beim Hyper alle 15 Sec. ein Wert an setDeviceAutomationInOutLimit gesendet wurde.Habe jetzt eine Hysterese eingebaut die bei Veränderungen +40 bis -40 nicht reagiert. ALS Eingangsleistung nehme ich 40.
Meine Steuerung für die Hysterese sieht so aus:
Soweit funktioniert es und reduziert die Schreibvorgänge.
Ist das eine sinnvolle Einstellung oder was würdest du ändern.
Sollte man das noch zusätzlich durch eine Zeitsteuerung ergänzen, z.B. auf 1x pro X Minute reduzieren. Oder lieber die Hysterese vergrößern?
Würde komplett anders ansetzen und kenne Deine Anforderungen nicht.
Bitte seid mir nicht böse aber beschäftige mich z. Z. selbst intensiv mit Zendure.
Gerne teile ich viel, aber support für scripts , dafür fehlt mir die Muße und Zeit.Vielleicht ein paar Anhaltspunkte zum berücksichtigen:
-
Zählererfassung über variable, wie oft überhaupt trigger berücksichtigt werden soll
-
delta als variable einbauen, die dann leicht verändert werden kann. evtl. auch im laufenden script (-> +/- x W werden nicht berücksichtigt)
-
Anlayse von schwierigen Verbrauchern und Sonderbedingungen von Ausreißern, wie die abgefangen werden sollen.
Das beinhaltet bei PV dann automatisch auch wechselhaftes Wetter/Jahreszeit.
Dafür benötigt man eine umfangreiche Strategie oder fängt alles zusätzlich grob ab.
Beispiel: für grob:
wenn Verbrauch > 1000W und das x mal innerhalb von x sek(min) dann output 1000W bis Zählererfassung < 500, mindestens aber 3 min (oder mindestens 20x Zählererfassung) usw. oder wenn Differenz zu vorherigem output > x W (300-400W) und das x mal innerhalb von x sec/min dann output: erfasster Wert für mind. x sec/min oder so ähnlich. -
Berücksichtigen, dass zwischen publishen einer Anforderung und dem erfolgreichen Umsetzen des neuen Wert (je nach System) mindestens zwischen 15-30sek. vergehen können.
Innerhalb dieses Zeitfenster dazwischen zu regeln ist sinnfrei und fordert viele Schreibvorgänge.
Zudem wirkt nach diesem Zeitfenster erst einmal der neue Wert und soll für eine Zeit ausgeführt werden und nicht sofort wieder geändert werden. -
bedenken, dass selbst wenn 1kWh ->1 Euro kosten würde, dann müsste man erst einmal 1 Stunde lang 1000W verbrauchen. Also lohnt es sich wirklich oft zu schreiben, wenn es sowieso - hardwarebedingtes Zeitfenster - nicht möglich ist?
-
Bevor zu oft geschrieben wird, lieber ein etwas großzügiger Rahmen.
Ob bei dem Rahmen dann mehr eingespeist wird (oder weniger) ist fast gleichgültig.
-
