NEWS
Test Adapter Zendure SolarFlow 6.0.0 – mit Nulleinspeisung
-
So, v6.1.1 ist installiert und in Betrieb. Werde mal beobachten und berichten, bisher habe ich aber keine Probleme feststellen können.
-
Frage zu feedInSolarOnly: Reicht es aus ihn einmal zu aktivieren und der Adapter stellt eigenständig fest wann die PV benötigt wird oder muss man den Schalter jedes Mal einschalten wenn man PV nutzen möchte?
-
Frage zu feedInSolarOnly: Reicht es aus ihn einmal zu aktivieren und der Adapter stellt eigenständig fest wann die PV benötigt wird oder muss man den Schalter jedes Mal einschalten wenn man PV nutzen möchte?
-
@lesiflo Aktuell musst du ihn einschalten. Aber ja macht irgendwie Sinn das als eine Art Bypass zu nutzen?
-
-
@lesiflo bis was für eine Leistung macht das Sinn? Also ab wann soll er wieder aus dem Akku einspeisen?
@lesiflo bis was für eine Leistung macht das Sinn? Also ab wann soll er wieder aus dem Akku einspeisen?
Ich würde das am zendure-solarflow.0.adapterAutomation.setPoint (Sollwert Netzeinspeisung) festmachen.
Mein Script funktioniert aktuell so:
Das Skript regelt selbst keine Leistung. Es setzt nur Freigaben, und die eigentliche Regelung übernimmt der Zendure-Adapter. Dass die PV zuerst ins Haus geht, kommt also aus dem Zusammenspiel von Adapter und Hyper.
Wer was macht
- Der Adapter regelt auf 0 W am Netzanschluss und gibt jedem Hyper vor, wie viel er ins Haus liefern soll.
- Jeder Hyper deckt diese Vorgabe zuerst mit seiner eigenen PV. Nur die Differenz kommt aus seinem Akku, und überschüssige PV lädt den Akku. Das macht der Hyper selbst; im Skript steht dafür keine Zeile.
Normalbetrieb: Entladen ist frei
Das Skript schaltet bei allen drei Hypern feedInSolarOnly aus, setzt das normale Entladelimit (10 %) und lässt die Automation an. Ab da entscheidet allein der Adapter.
Entladesperre (Zeilen 344–395)
Die Sperre greift in zwei Fällen:
- Der Optimizer verbietet das Entladen (Entladen_Freigabe = false).
- Das Auto lädt mit mindestens 500 W und der Gesamt-SOC liegt nicht über bufferSoc.
Während der Sperre gilt:
- Hyper 1 und 2: feedInSolarOnly = true. Die aktuelle PV geht weiter nach Bedarf ins Haus, der Rest in den Akku, und der Akku wird nicht entladen. Fehlt dieser Datenpunkt, hebt das Skript ersatzweise das Entladelimit auf das Ladelimit an.
- Hyper 3 (ohne PV): Das Entladelimit wird auf das Ladelimit angehoben. Die Automation bleibt nur an, wenn mehr als 100 W ins Netz fließen, Hyper 3 also Überschuss aufnehmen kann.
Ist das letzte Signal des Optimizers älter als 25 Minuten, ignoriert das Skript seine Freigaben und lässt das Entladen zu.
-
Ich habe jetzt erstmal eine Version veröffentlicht die bei Solar >50W und feedInSolarOnly = true nur maximal die aktuelle Solarleistung einspeisen darf. Unter 50W darf auch der Akku hinzugezogen werden.
Das am setPoint festzumachen finde ich noch schwierig, denn wenn jmd. explizit einen negativen setPoint wählt wirds schwierig.
Ich denke da noch mal drüber nach, eventl. würde ja ein selbst konfigurierbarer Wert dafür Sinn machen.
-
Ok, probiere ich morgen mal aus
-
lesiflo sagte:
Ok, probiere ich morgen mal aus
Moin,
ich Nachgang habe ich mir überlegt, das das mit dem Einspeisen aus dem Akku bei PV <50 W bei aktiven feedInSolarOnly doch so keine gute Idee war. Stichwort Endladesperre, wenn das eAuto geladen wird sollte man eigentlich vermeiden das Strom aus dem Akkus gezogen wird, es sein denn man lässt es ausdrücklich zu.
Mit alten Version brauchte man nur feedInSolarOnly auf true setzen, dann ging nur PV ins Netz. Dazu bräuchte man jetzt einen zusätzlichen Schalter "Endladesperre".Ich bleibe daher erstmal auf der Version 6.1.1.
-
Hallo @nograx , ich hab da mal eine "doofe" Frage,
aktuell habe ich noch Adapter Version 5.3.1 installiert und bekomme 6.1.3 angeboten.
Wenn ich auf 6.x update und nichts von deinen neuen Einstellungen aktiviere, ändert sich bei mir doch auch nichts, oder ?
Ich hatte mir mit Chat GPT ein Blockly gebaut, welches für mich sehr gut funktioniert, daran würde beim update doch auch nichts geändert ?Und noch eine Frage zur AC und Master Firmware, die habe ich auch nie aktualisiert seit kauf vor ein paar Monaten.
Die sind aktuell auf (AC) 3.1.2 und (Master) auf 2.1.30.
Kann ich die eigentlich mal upgraden, oder soll ich die so lassen ?Ein update der iOS App, kann ich doch machen ?
Ok, sind dann doch mehr als eine "doofe" Frage geworden.
Weil ich mich damit so gar nicht auskenne, lieber mal nachgefragt.
Ich habe einen Hyper 2000 mit einem AB 2000 X Akku.
Das Ganze wird ausschließlich mit meinem Blockly gesteuert.
Also kein HEMS, ZenWave oder so aktiviert. -
Adapter Update kannst du problemlos machen. Die neue Automatisierung ist komplett optional und auch nicht sichtbar wenn du sie nicht explizit in den Einstellungen aktivierst.
Firmware Update hängt aktuell davon ab ob du in der Cloud unterwegs bist oder das Gerät lokal per MQTT laufen lässt.
-
-
-
-
hallo
ich verwende auch diesen adapter, aber ich kann über den adapter überhaupt nichts schalten am zendure, obwohl alle geräte gefunden werden und auch die statusse korrekt dargestellt werden im iobroker -
hallo
ich verwende auch diesen adapter, aber ich kann über den adapter überhaupt nichts schalten am zendure, obwohl alle geräte gefunden werden und auch die statusse korrekt dargestellt werden im iobroker -
ich möchte das system lokal steuern und nicht mehr über hems
denn diese automatische kalibierung am abend nervt -
ich möchte das system lokal steuern und nicht mehr über hems
denn diese automatische kalibierung am abend nervt@SpeedyBlade Dann solltest du im ersten Schritt das HEMS / Automatisierung in der offiziellen App abschalten. Sonst geht keine Steuerung. Dann kannst du wenn du z.B. deinen Shelly (oder welchem Smart Meter du auch benutzt) im ioBroker siehst auch die offizielle Automatisierung vom Adapter nutzen. Die läuft jetzt schon bei knapp 30 Personen sehr stabil.
Einrichtung grob ist die Automatisierung im Adapter einschalten, Smart Meter Datenpunkt auswählen und dann im Objektbaum die Automatisierung aktivieren. Ausführlicher wird es in der Readme beschrieben.
Wenn du uns noch mehr Infos gibst können wir dir hier auch einiges besser helfen.
-
@SpeedyBlade Dann solltest du im ersten Schritt das HEMS / Automatisierung in der offiziellen App abschalten. Sonst geht keine Steuerung. Dann kannst du wenn du z.B. deinen Shelly (oder welchem Smart Meter du auch benutzt) im ioBroker siehst auch die offizielle Automatisierung vom Adapter nutzen. Die läuft jetzt schon bei knapp 30 Personen sehr stabil.
Einrichtung grob ist die Automatisierung im Adapter einschalten, Smart Meter Datenpunkt auswählen und dann im Objektbaum die Automatisierung aktivieren. Ausführlicher wird es in der Readme beschrieben.
Wenn du uns noch mehr Infos gibst können wir dir hier auch einiges besser helfen.
@nograx
HEMS ist mittlerweile deaktiviert 👍🏼
Nutze es nur mehr lokal
Habe die Automation aus dem Adapter aktivert... Besten Dank
Läuft soweit ganz gut, allerdings habe ich noch Anliegen hierzu.
Ich habe drei solarflow 2400 mit ab3000x im Einsatz. Die erzeugende Energie erfolgt über eine separate komplette pv-anlage am Dach.
Somit sind die AC Speicher auch wirklich reine AC Speicher.
Was mir gestern aufgefallen ist, dass ein Speicher den anderen geladen hat, obwohl keine Energie vom Dach kam.
Hier wäre es gut wenn man noch folgendes in die Automation mit einfügen könnte.
Man bräuchte den Wert der pV Anlage der aktuell erzeugt wird, ist dieser kleiner Wert X, dann soll AC Ladung gesperrt werden. Ist der Wert der pv-anlage über Wert X, dann soll AC Ladung wieder aktiv werden. Beides soll jedoch mit einer Zeit hinterlegt werden können. Z.b mindestens 1,2,3,5 Minuten oder ähnliches.
Ich hoffe das war nun verständlich erklärt 😬[ { "id": "zendure_pv_trigger_in", "type": "ioBroker in", "z": "tab_zendure_automation", "name": "PV-Gesamtwert einlesen", "topic": "zendure-solarflow.0.adapterAutomation.totalSolarPower", "payloadType": "value", "onlyack": true, "func": "all", "gap": "", "x": 160, "y": 140, "wires": [ [ "zendure_logic_function" ] ] }, { "id": "zendure_logic_function", "type": "function", "z": "tab_zendure_automation", "name": "60s Timer & Hysterese", "func": "let aktuellePV = msg.payload;\n\n// Zustände aus dem Node-Speicher holen oder initialisieren\nlet statusAktuell = context.get(\"statusAktuell\") || false; // true = Laden erlaubt, false = gesperrt\nlet timerTyp = context.get(\"timerTyp\") || null; // \"ON\" oder \"OFF\"\nlet timerStart = context.get(\"timerStart\") || 0; // Zeitstempel\n\nlet jetzt = Date.now();\nlet wartezeit = 60000; // 60 Sekunden in Millisekunden\n\n// --- FALL 1: PV ist hoch genug (Einschalten prüfen) ---\nif (aktuellePV >= 150) {\n if (!statusAktuell) { // Wenn aktuell noch gesperrt ist\n if (timerTyp !== \"ON\") {\n // Start des 60s-Timers für das Einschalten\n context.set(\"timerTyp\", \"ON\");\n context.set(\"timerStart\", jetzt);\n } else if (jetzt - timerStart >= wartezeit) {\n // 60 Sekunden sind stabil abgelaufen!\n statusAktuell = true;\n context.set(\"statusAktuell\", statusAktuell);\n context.set(\"timerTyp\", null); // Timer zurücksetzen\n msg.payload = true;\n return msg;\n }\n }\n else {\n // Zustand ist bereits ON, eventuellen OFF-Timer löschen\n context.set(\"timerTyp\", null);\n }\n}\n\n// --- FALL 2: PV ist zu niedrig (Ausschalten prüfen) ---\nelse if (aktuellePV <= 50) {\n if (statusAktuell) { // Wenn aktuell noch Laden erlaubt ist\n if (timerTyp !== \"OFF\") {\n // Start des 60s-Timers für das Ausschalten\n context.set(\"timerTyp\", \"OFF\");\n context.set(\"timerStart\", jetzt);\n } else if (jetzt - timerStart >= wartezeit) {\n // 60 Sekunden sind stabil abgelaufen!\n statusAktuell = false;\n context.set(\"statusAktuell\", statusAktuell);\n context.set(\"timerTyp\", null); // Timer zurücksetzen\n msg.payload = false;\n return msg;\n }\n }\n else {\n // Zustand ist bereits OFF, eventuellen ON-Timer löschen\n context.set(\"timerTyp\", null);\n }\n}\n\n// --- FALL 3: PV liegt im Hysterese-Bereich (51 - 149W) ---\nelse {\n // Wenn der Wert dazwischen liegt, wird jeder laufende Timer abgebrochen\n context.set(\"timerTyp\", null);\n}\n\n// Wenn die Bedingung (noch) nicht erfüllt ist, blockieren wir die Nachricht\nreturn null;", "outputs": 1, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 420, "y": 140, "wires": [ [ "zendure_out_device_1", "zendure_out_device_2", "zendure_out_device_3" ] ] }, { "id": "zendure_out_device_1", "type": "ioBroker out", "z": "tab_zendure_automation", "name": "Speicher 1: acChargingAllowed", "topic": "zendure-solarflow.0.[Seriennummer_A].adapterAutomation.acChargingAllowed", "ackval": "false", "autoCreate": "false", "stateId": "", "stateName": "", "stateType": "", "stateUnit": "", "x": 710, "y": 80, "wires": [] }, { "id": "zendure_out_device_2", "type": "ioBroker out", "z": "tab_zendure_automation", "name": "Speicher 2: acChargingAllowed", "topic": "zendure-solarflow.0.[Seriennummer_B].adapterAutomation.acChargingAllowed", "ackval": "false", "autoCreate": "false", "stateId": "", "stateName": "", "stateType": "", "stateUnit": "", "x": 710, "y": 140, "wires": [] }, { "id": "zendure_out_device_3", "type": "ioBroker out", "z": "tab_zendure_automation", "name": "Speicher 3: acChargingAllowed", "topic": "zendure-solarflow.0.[Seriennummer_C].adapterAutomation.acChargingAllowed", "ackval": "false", "autoCreate": "false", "stateId": "", "stateName": "", "stateType": "", "stateUnit": "", "x": 710, "y": 200, "wires": [] } ] -
@nograx
HEMS ist mittlerweile deaktiviert 👍🏼
Nutze es nur mehr lokal
Habe die Automation aus dem Adapter aktivert... Besten Dank
Läuft soweit ganz gut, allerdings habe ich noch Anliegen hierzu.
Ich habe drei solarflow 2400 mit ab3000x im Einsatz. Die erzeugende Energie erfolgt über eine separate komplette pv-anlage am Dach.
Somit sind die AC Speicher auch wirklich reine AC Speicher.
Was mir gestern aufgefallen ist, dass ein Speicher den anderen geladen hat, obwohl keine Energie vom Dach kam.
Hier wäre es gut wenn man noch folgendes in die Automation mit einfügen könnte.
Man bräuchte den Wert der pV Anlage der aktuell erzeugt wird, ist dieser kleiner Wert X, dann soll AC Ladung gesperrt werden. Ist der Wert der pv-anlage über Wert X, dann soll AC Ladung wieder aktiv werden. Beides soll jedoch mit einer Zeit hinterlegt werden können. Z.b mindestens 1,2,3,5 Minuten oder ähnliches.
Ich hoffe das war nun verständlich erklärt 😬[ { "id": "zendure_pv_trigger_in", "type": "ioBroker in", "z": "tab_zendure_automation", "name": "PV-Gesamtwert einlesen", "topic": "zendure-solarflow.0.adapterAutomation.totalSolarPower", "payloadType": "value", "onlyack": true, "func": "all", "gap": "", "x": 160, "y": 140, "wires": [ [ "zendure_logic_function" ] ] }, { "id": "zendure_logic_function", "type": "function", "z": "tab_zendure_automation", "name": "60s Timer & Hysterese", "func": "let aktuellePV = msg.payload;\n\n// Zustände aus dem Node-Speicher holen oder initialisieren\nlet statusAktuell = context.get(\"statusAktuell\") || false; // true = Laden erlaubt, false = gesperrt\nlet timerTyp = context.get(\"timerTyp\") || null; // \"ON\" oder \"OFF\"\nlet timerStart = context.get(\"timerStart\") || 0; // Zeitstempel\n\nlet jetzt = Date.now();\nlet wartezeit = 60000; // 60 Sekunden in Millisekunden\n\n// --- FALL 1: PV ist hoch genug (Einschalten prüfen) ---\nif (aktuellePV >= 150) {\n if (!statusAktuell) { // Wenn aktuell noch gesperrt ist\n if (timerTyp !== \"ON\") {\n // Start des 60s-Timers für das Einschalten\n context.set(\"timerTyp\", \"ON\");\n context.set(\"timerStart\", jetzt);\n } else if (jetzt - timerStart >= wartezeit) {\n // 60 Sekunden sind stabil abgelaufen!\n statusAktuell = true;\n context.set(\"statusAktuell\", statusAktuell);\n context.set(\"timerTyp\", null); // Timer zurücksetzen\n msg.payload = true;\n return msg;\n }\n }\n else {\n // Zustand ist bereits ON, eventuellen OFF-Timer löschen\n context.set(\"timerTyp\", null);\n }\n}\n\n// --- FALL 2: PV ist zu niedrig (Ausschalten prüfen) ---\nelse if (aktuellePV <= 50) {\n if (statusAktuell) { // Wenn aktuell noch Laden erlaubt ist\n if (timerTyp !== \"OFF\") {\n // Start des 60s-Timers für das Ausschalten\n context.set(\"timerTyp\", \"OFF\");\n context.set(\"timerStart\", jetzt);\n } else if (jetzt - timerStart >= wartezeit) {\n // 60 Sekunden sind stabil abgelaufen!\n statusAktuell = false;\n context.set(\"statusAktuell\", statusAktuell);\n context.set(\"timerTyp\", null); // Timer zurücksetzen\n msg.payload = false;\n return msg;\n }\n }\n else {\n // Zustand ist bereits OFF, eventuellen ON-Timer löschen\n context.set(\"timerTyp\", null);\n }\n}\n\n// --- FALL 3: PV liegt im Hysterese-Bereich (51 - 149W) ---\nelse {\n // Wenn der Wert dazwischen liegt, wird jeder laufende Timer abgebrochen\n context.set(\"timerTyp\", null);\n}\n\n// Wenn die Bedingung (noch) nicht erfüllt ist, blockieren wir die Nachricht\nreturn null;", "outputs": 1, "noerr": 0, "initialize": "", "finalize": "", "libs": [], "x": 420, "y": 140, "wires": [ [ "zendure_out_device_1", "zendure_out_device_2", "zendure_out_device_3" ] ] }, { "id": "zendure_out_device_1", "type": "ioBroker out", "z": "tab_zendure_automation", "name": "Speicher 1: acChargingAllowed", "topic": "zendure-solarflow.0.[Seriennummer_A].adapterAutomation.acChargingAllowed", "ackval": "false", "autoCreate": "false", "stateId": "", "stateName": "", "stateType": "", "stateUnit": "", "x": 710, "y": 80, "wires": [] }, { "id": "zendure_out_device_2", "type": "ioBroker out", "z": "tab_zendure_automation", "name": "Speicher 2: acChargingAllowed", "topic": "zendure-solarflow.0.[Seriennummer_B].adapterAutomation.acChargingAllowed", "ackval": "false", "autoCreate": "false", "stateId": "", "stateName": "", "stateType": "", "stateUnit": "", "x": 710, "y": 140, "wires": [] }, { "id": "zendure_out_device_3", "type": "ioBroker out", "z": "tab_zendure_automation", "name": "Speicher 3: acChargingAllowed", "topic": "zendure-solarflow.0.[Seriennummer_C].adapterAutomation.acChargingAllowed", "ackval": "false", "autoCreate": "false", "stateId": "", "stateName": "", "stateType": "", "stateUnit": "", "x": 710, "y": 200, "wires": [] } ]@SpeedyBlade Exakt das was du da beschreibst dürfte eigentlich nicht passieren - lediglich wenn der Lade-Keep-Alive gehalten wird (5 Minuten) kann es temporär dazu kommen ODER wenn deine Verbindung schlecht ist und das Kommando zur Leistungsreduktion beim Gerät nicht sauber ankommt (da bitte dann mal setDeviceAutomationInOutLimit mit den aktuellen Werten vergleichen). Letzteres sollte aber auch automatisch innerhalb einer Minute korrigiert werden in dem das letzte Kommando noch einmal geschickt wird.
Es wäre super wenn du mir dazu den Adapter in den Debug Modus schaltest und dann ein Log zukommen lassen könntest sofern das noch mal passiert.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden
