UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[cordobadb]

@lesiflo : Vielen Dank für das Sktipt und deine Erklärung! Ich werde mich mal durchwühlen, nach der Beschreibung scheint es aber einiges umzusetzten was ich auch vorhatte.

[cordobadb]

@lesiflo : Gibt es einen physikalischen Grund für die 20s-Verzögerung?
Geht es um das potentielle E²PROM-Problem beim zu häufigen Schreiben des AC-Modus, oder siehst du noch andere Probleme in der HW, Akku, etc?

[lesiflo]

@cordobadb sagte in Script zum Laden/Entladen von Zendure Solarflow:

HW, Akku, etc

Die 20 Sekunden habe ich eingebaut um ein häufiges Schalten des Relais beim Laden/Entladen zu verhindern. Erst wenn länger als die 20 Sekunden Leistung aus den Akkus benötigt wird auf Entladen umgeschaltet. Am besten ausprobieren was bei dir passt. Zudem möchte ich verhindern, das das Auto aus dem Akku geladen wird. Wenn ich den Wert zu klein mache geht kurzfristig Leistung vom Akku ins eAuto, da die Regelung vom eAuto laden träger ist. Hierfür nutze ich noch die externe Software openWB.

[Murphy 0]

Ich verhindere auch dass der Hyper einspeist wenn das Auto geladen wird.
Da ich aber eine ältere Heidelberg Home eco WB habe steuere ich das mit iobroker über den Mercedes.me Adapter.

[Murphy 0]

@lesiflo
Welche unterste Zellspannung würdest du beim Einspeisen empfehlen.
Ich glaube etwas über 3,1 Volt als Abschaltgrenze gelesen zu haben, finde es aber nicht mehr.

3,2 bis 3,4 habe ich als Arbeitsbereich.

[Wildshunter]

Halloechen,
jetzt schaue ich seit längerem mal wieder in meine Scripte bzw. die Automatisiation (Script wie oben beschrieben lief 1a) und mir fällt leider folgendes auf, vielleicht hat jemand eine Idee:
sobald mein Akku nun voll ist, schaltet er meine Solarmodule ab und kurz danach (alle 3-4 Sekunden) wieder auf Bypass, somit wieder kurzzeitig die Module dazu. Das geht bis Abends, bis sich der Akku entleert und am nächsten Tag genau das gleiche, Akku wird geladen und sobald er voll ist, schaltet Bypass "hin und her".
Echt komisch, auch wenn ich das Script hier anhalte, bleibt es bei dem Verhalten (zyklische Bypass schalten / wieder aus).
Neustes Firmware Update von Hyper 2000 wurde noch nicht durchgeführt. Ich ueberlege jetzt ob ich jetzt den ganzen lokalen MQTT wieder auf die Zendure Cloud lege und danach das Firmware Update durchführe.... um zu sehen, ob das irgendwie am Hyper 2000 liegt oder nicht...
Gibt es sonst Ideen (Zendure Adapter nicht ganz aktuell, kann aber momentan wegen aelterer node Version nicht updaten)? Danke!
(1.13.1 - zendure Adapter)

[Murphy 0]

@wildshunter

Wenn du auf deinem lokalen Broker bist kannst du deine Hardware jederzeit durch eine Bluetooth Verbindung updaten. Soll sogar stabiler sein als über die Zendure Cloud.

Solange ich auf Fehlersuche bin setze ich nach jedem Schritt im Blockly wo ich mir im geringsten unsicher bin einen debug output.
So komme ich dann den kleinsten Fehlern auf die Schliche.

Ich bin im Moment dabei die Schreibzugriffe ins Flash zu minimieren.
Der Debuglog sieht dann so aus:

[SchaafAlexander]

@lesiflo said in Script zum Laden/Entladen von Zendure Solarflow:

@cordobadb Moin, hier mal das Script. Ist aber sehr stark an meine Bedürfnisse angepasst und auch noch nicht ganz fehlerfrei.

hems.txt

Das ioBroker-JavaScript ist eine komplexe und intelligente Steuerung für zwei Zendure Hyper-Batteriespeicher (Hyper1 und Hyper2). Es berücksichtigt:

• PV-Produktion
• Strompreis (Tibber)
• Hausverbrauch
• SOC der Akkus
• Sonnenauf- und -untergang
• Auto-Ladevorgang
• VIS-Log-Ausgabe für visuelle Rückmeldung

Zentrale Aufgaben & Ziele des Skripts

1. Optimale Ladung/Entladung der Akkus
   Priorisiert PV-Überschuss-Laden.
   Nutzt günstigen Strompreis für zusätzliches Laden.
   Verhindert Entladen bei günstigen Strompreisen oder Vorrang fürs Auto.
   Erlaubt Entladung bei teurem Strompreis.

2. Speicher-Priorisierung:
   Wenn der Speicher lädt und sein SOC unter einer definierten Schwelle ist, haben Speicher-Ladevorgänge Vorrang.

3. Strompreis-Integration (Tibber):
   Laden bei günstigem Preis (aggressiv oder konservativ je nach Einstellung).
   Entladen bei teurem Preis.

4. PV-Forecast-Nutzung:
   Verwendet pvforecast-Daten für Tages- und Restprognose.

5. Nachtbedarf-Absicherung (AmountHours):
   Nutzt SOC und Sonnenuntergangs-/aufgangszeit zur Berechnung von Tibber’s AmountHours.
   Stellt sicher, dass genug Akkuenergie für die Nacht verbleibt.

6. Leistungsaufteilung zwischen Hyper1 und Hyper2:
   Dynamisch je nach SOC-Differenz.
   Leistung ist begrenzt auf xxx W je Gerät.

7. Hysterese und Modusverzögerung:
   Verhindert zu schnelles Umschalten zwischen Lade- und Entlademodus (20s Delay).

8. VIS-kompatibles Logging:
   Ausgabe der Vorgänge (PV, SOC, Ladeleistung, Preisstatus etc.) in einem HTML-Log-Table im VIS

Hallo @lesiflo ,

vielen Dank für das Skript und die Erklärungen.
Sind die Screenshots aus Post 1 noch aktuell zu dem hier erwähnten Umfang?
Leider kann ich das txt nicht importieren und würde es gerne anhand der Screenshots in etwa nachbauen.

Habe ein ähnliche Ausgangslage.

• PV (SolarEdge mit 9.2kWh Batterie)
• Tibber
• OpenWB
• Zendure 2400 AC (1-3 je nachdem wie gut das läuft :-D )

Vielen lieben Dank und weiterhin einen schönen Tag!

[lesiflo]

@schaafalexander Das neue ist ein Java Script und hat mit dem ursprünglichen Blockly Script nichts mehr zu tun. Am besten das Blockly aus dem ersten Post nehmen. Das sollte klappen. Ansonsten das neue als Java Script importieren.

[SchaafAlexander]

@lesiflo
Danke.
Orientiere mich am Blockly und hab heute mal angefangen mich ranzutasten.

Merci :-)

[Michi 0]

Hallo Zusammen,

bin gerade dabei für meinen Solarflow 2400ac ein Skript zu basteln und wollte mich an euren "Vorarbeiten" orientieren. Leider klappt das aber nicht, da bei mir kein BKW am Solarflow hängt. Statt dessen wird er über eine 10 kWp Anlage am Dach geladen. Daher kann ich die Regelung zum laden nicht übernehmen.

Meine Regelung soll (fürs erste) nur laden bei Überschuss und entladen bei Stombezug aus dem Netz berücksichtigen. Soweit ganz einfach... dachte ich.

Die "klassische" Berechnung mit "Netzeinspeisung* (-1) + Ladewert" für Laden und "Netzbezug+ Entladewert" funktioniert nicht in allen Varianten. Beispielsweise wenn die Batterie geladen wird, und dann der Verbrauch samt Ladewert über die vorhandene PV Leistung steigt.

Ich komme einfach nicht auf die korrekten Formeln. Aktuell verwende ich folgendes Skript:

var Ladewert, Entladewert;


on({ id: 'fronius.0.site.P_Grid' /* Actual grid power */, change: 'ne' }, async (obj) => {
  let value = obj.state.val;
  let oldValue = obj.oldState.val;
  if ((obj.state ? obj.state.val : '') < 0) {
    Ladewert = (obj.state ? obj.state.val : '') * -1 + getState('mqtt.0.Zendure.number.xxxxx.inputLimit.set').val;
    setState('mqtt.0.Zendure.select.xxxxx.acMode' /* Zendure/select/xxxxx/acMode */, 'Input mode');
    setState('mqtt.0.Zendure.number.xxxxx.inputLimit.set' /* Zendure/number/xxxxx/inputLimit/set */, Ladewert);
  } else if ((obj.state ? obj.state.val : '') > 0) {
    Entladewert = (obj.state ? obj.state.val : '') + getState('mqtt.0.Zendure.number.xxxxx.outputLimit.set').val;
    setState('mqtt.0.Zendure.select.xxxxx.acMode' /* Zendure/select/xxxxx/acMode */, 'Output mode');
    setState('mqtt.0.Zendure.number.xxxxx.outputLimit.set' /* Zendure/number/xxxxx/outputLimit/set */, Entladewert);
  }
});

Der Solarflow wird direkt über den MQTT Adapter gesteuert und ausgelesen.

Stromwerte kommen vom Fronius Adapter: Einspeisung ist P-Grid mit negativen Werten. Strombezug ist P-Grid mit positiven Werten.

Kann mir mal jemand Starthilfe geben? Ich komme auch nach mehreren Tagen einfach nicht auf den Fehler bzw. die nötigen Anpassungen. :face_with_thermometer:

[lesiflo]

@michi-0 Kleiner Tip: Frag mal Chat-GPT. Damit habe ich mittlerweile meine komplette Steuerung der Hyper erstellt.
Ich würde das allerdings gleich in Java-Script machen.

Versuchs mal so in etwa:

[Michi 0]

@lesiflo Danke!!! Läuft soweit. Bin mal gespannt was heute Abend passiert. Aktuell bekomme ich den Strom vom Dach nicht weiter, sodass ich das "runterregeln" noch nicht testen kann. Zumindest ist mein "Regelungs-Ping-Pong" aber schon mal weg.

ChatGPT hatte ich probiert. Allerdings hat der Import in Blockly nicht geklappt. :thinking_face:
Und Java-Script wollte ich mangels Kenntnisse nicht probieren <- Das Skrpit wird noch erweitert um eine Hysterese bei den Messwerten und einer Ladung bei günstigen Strompreisen. Das würde ich in Java definitiv auch mit Hilfe nicht mehr hinbekommen...

[lesiflo]

@michi-0 So habe ich mal angefangen. Da ich auch das Blockly nicht in Chat-GPT laden konnte habe ich es mir im Java-Code ausgeben lassen, nach Chat-GPT kopiert und gesagt was ich haben möchte. So habe ich mich dann nach und nach an Java-Script rangetastet. Mittlerweile ist daraus ein recht großes Script mit allen was ich haben möchte entstanden. Übrigens auch mit Laden/Entladen nach Strompreis.

[Murphy 0]

Michi,

So sieht mein Blockly für die Hysterese aus.
Für inputalt und outputalt und impuls habe ich User Objekte angelegt. So bleiben die Werte nach einem Neustart erhalten

Schreibimpulse werden auch geloggt.

Meine Formel mit Geräte Automation Limit hat geänderte Vorzeichen im Vergleich zum AC Modus.

[lesiflo]

@murphy-0 inputalt und outputalt braucht man eigentlich nicht. Beim Trigger kann man auch "vorherigen Wert" auswählen. Aber geht so auch.

[Murphy 0]

@lesiflo
Bin immer dankbar für Tips 🙏

[lesiflo]

@murphy-0 So etwa könnte gehen:

Beispiel Laden

[Michi 0]

@ lesiflo Verständnisfrage:

Bezieht sich "vorheriger Wert" nicht auf den Triggerwert (hier Wert Stromanschluss)? Dieser Wert wird für Berechnung "Output" bearbeitet und taugt dann doch nicht mehr für den Abgleich...?

Und gleich nocht etwas: Ich bekomme die Meldung, dass "Set-Output" ein String anstatt Nummer haben will. Wenn ich dann in Blockly "konvertieren in String" vor die Berechnung von Output setze rechnet es mir aber ein vielfaches vom tatsächlichen Wert aus. Wo fehlts denn hier?

[lesiflo]

@michi-0

vorheriger Wert bezieht sich auch den Triggerwert hier "power".

Bsp:
Wert = 30 W
vorheriger Wert = 50 W -> keine Änderung

Wert = 30 W
vorheriger Wert = 100 W -> Änderung

output bezieht sich immer auf den aktuellen Wert.