Test Adapter Zendure Solarflow
-
@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.
-
-
@maxclaudi
Danke dir, warum soll ich böse sein. Alles gutEine kurze Frage: welches obere und untere Limit für die Zellspannung bei Laden und Entladen empfiehlst du?
Vielleicht zwischen 3.2 und 3.4 ?
-
@murphy-0 sagte in Test Adapter Zendure Solarflow:
welches obere und untere Limit für die Zellspannung bei Laden und Entladen empfiehlst du?
Vielleicht zwischen 3.2 und 3.4 ?Empfehlen möchte ich nichts.
Zendure sind 15S LiFePO4 48V Batterien.
≥ 2.80 V/Zelle => ≥ 42.0 V Pack unter Last abschalten bzw. begrenzen.
Unter Last erholt sich die Spannung danach etwas.3.45–3.50 V/Zelle ->51.75–52.50 V Pack-Spannung.
Das erreicht >90 % SoC, vermeidet Stress und soll gängiger „long-life“-Bereich sein.Selbst nutze ich 2.9V und 3.4V.
Muss jeder für sich entscheiden. Ein Batterie-Experte bin ich nicht. -
@murphy-0 also vorneweg, ein Akkuexperte bin ich auch nicht aber mache es mittlerweile auch so, das ich als untere Grenze die minVol nehme. Ich schalte bei 3,1V ab, das ist weit genug weg von böse und oben nehme ich tatsächlich den Punkt an dem das BMS meinst das sie voll sind also die 100%. Da das BMS wohl erst ab 3,5V anfängt zu balancen, ist es auch empfehlenswert denke ich. Davon ab, sollen die Akkus ihre Kapa bringen sonst muss man es sich nicht nur schön rechnen 🫣
-
vielen Dank, damit kann ich etwas anfangen.
Ohne dieses Forum würde ich mich noch immer über die Zendure Cloud schwarz ärgern.
So läuft jetzt alles stressfrei seit Wochen.
-
@murphy-0 das kann ich bestätigen, war auch schon super als ich noch in der Cloud war dank Peters Integration, jetzt lokal alles tutti und gar keine Probleme mehr.
Bezüglich der writes, ich habe auch mal ein logging in NodeRed gebaut. Also es ist so, das ich heute an einem sehr durchwachsenen Tag, trotz rbe Filter vor dem ioBroker-Out, 171 mal das Input-Limit ändern musste. Der flow wird nur alle 60 Sekunden getriggert aber durch die Wolken ging es halt ständig auf und ab. Ehrlich gesagt, die Anlage läuft schon so seit einem Jahr, ich denke da wäre längst was kaputt. Werde mir, bevor es keine mehr gibt, noch einen HUB1200 auf Halde legen, dann ist das Thema durch. Den nächsten BKW Speicher werde ich selbst bauen, dann ist eh alles wumpe
