Zendure SmartFlow AI einrichten - Erwartungswerte unklar, Fehlermeldung in HA (scheinbar Validierung optionaler Felder)

[RallyeB]

System: Zendure SF2400 AC
Version: Zendure SmartFlow AI 1.5.0-beta6

Hallo

Ich versuche, das battery-smartflow-ai in Betrieb zu nehmen, scheitere aber gerade daran, dass mir die erwarteten Wertebereiche der folgenden Felder unklar sind. Alle drei Felder sind eigentlich optionale Felder, werden bei mir von Home Assistant aber bei Klick auf OK mit Fehlermeldungen versehen ("Entity None is neither a valid entity ID nor a valid UUID"). Insofern wäre mein Workaround, hier entsprechende Werte zu liefern, müsste dann aber die Bedeutung kennen:

"SoC-Limit Status" (optional): Das scheint ein Feld zu sein, in dem die Status Felder socLimit der Zendure Wechselrichter übergeben werden. In dem Fall wäre (nach aktueller Vermutung) 0 = keine Begrenzung und 1 = Entladelimit erreicht. Die SmartFlow-Integration scheint aber noch den Wert 2 = Ladelimit erreicht zu nutzen (auch nur Vermutung bei kurzem Blick in den Quelltext). Frage: Wäre es hier korrekt, wenn ich den socLimit der Wechselrichter 1:1 einsetze oder müsste noch etwas mehr Logik ergänzt werden?

"Preisverlauf (z. B. Tibber / EPEX)", "Aktueller Strompreis": Ich nutze aktuell keinen dynamischen Stromtarif. Würde ich einen nutzen, wäre mir nicht klar, was ich (insbesondere beim Preisverlauf) anbieten müsste. Frage: Gibt es hier die Möglichkeit, mit einfachen Werten die Regelung so zu konfigurieren, dass die Ladung nach dynamischen Strompreisen irrelevant ist?

TL;DR:
Die optionalen Felder sind bei mir in Home Assistant gerade leider nicht optional. Aber vielleicht gibt es einen Workaround.

[PalmManiac]

Genau richtig, bei SoC-Limit Status kommt die Entität socLimit rein. Der Hintergrund ist, dass die Zendure-Steuerung z.b. einen Ladevorgang schon abbricht, wenn ein Akku von mehreren die 100% erreicht hat. Dabei ist es egal, was die Gesamtkapazität anzeigt. Der Sensor wäre also wichtig.

Wenn du keinen dynamischen Strompreis nutzt, aber eine starke PV-Anlage hast, dann wäre für dich der Sommer-Modus richtig. Dieser Modus richtet sich nicht nach dem Preis, sondern nach der Maximierung der Autarkie. Es würde also mit PV-Strom geladen und sofort wieder entladen, wenn Bedarf da ist.

In die neue Version der Anleitung werde ich die Sensoren und die Konfiguration mal ausführlicher erklären, aber auch direkt die Bezeichnungen werde ich mit kurzen Hinweisen versehen. Das hab ich selbst schon festgestellt, dass es da etwas Informativer sein müßte.

[PalmManiac]

Im Konfigurationsmenü habe ich jetzt Erklärungen nachgerüstet, die dann zusätzlich unter dem jeweiligen Auswahlabschnitt angezeigt werden. :) Kommt mit einer der nächsten Updates.

[ldoellin]

Ich habe die gleiche Fehlermeldung bei optionalen Sensoren wie Preisverlauf und Aktueller Strompreis.
den Sensor für aktuellen Strompreis habe ich noch, aber Preisverlauf nutze ich nicht da ich keinen dynamischen Tarif habe.

[PalmManiac]

Versuche mal folgendes: Erstelle dir einen Helfer, am besten ein Number-Helper, nenne ihn Aktueller Strompreis oder so und stelle dort deinen Strompreis ein. Den nimmst du dann für das Feld Aktueller Strompreis. Kommst du dann weiter?

Ich arbeite gerade an der V2.0, da der Code langsam sehr unübersichtlich und unstrukturiert wurde. Wenn ich alles fertig habe, dann spiele ich das mal theoretisch durch, wie sich der neue Code verhält, wenn man keinen dynamischen Preis hat. Eigentlich hätte es auch ohne klappen müssen, aber es kann sich da ein Problem eingeschlichen haben auf dem Weg zur V1.5.1. ;)

[ldoellin]

Einen Strompreissensor habe ich ja (von der Octopus Integration), aber ich komme nicht weiter da ich keinen Preisverlaufsensor habe.

Ich habe den Strompreissensor einfach auch bei Preisverlauf eingetragen, weiß aber nicht was das für Auswirkungen hat.
Den Preisverlaufssensor kann ich nicht freilassen.

[PalmManiac]

Ach so, Festpreis. Eigentlich sollte sich das System in so einem Fall wie im Sommer-Modus verhalten und sich nicht weigern die Konfiguration ohne diese Sensoren durchzuführen. Ich schaus mir mal an.

[ldoellin]

Jein, durch EnWG Modul 3 und günstigen Nachttarif bei Octopus habe ich 5 verschiedene Preise pro Tag, die sich aber natürlich jeden Tag wiederholen.
Ein Forecast für die Planung wäre dann schon gut, da von 11ct bis 38ct alles dabei ist.

[RallyeB]

Danke für die Info!

Ich werde für den "SoC-Limit Status" einen Helper, wie oben empfohlen nehmen und für die beiden anderen Felder irgendeinen Number Wert.

Die optionalen Werte scheinen mit =entry.data.get() geholt zu werden und die drei Felder sind auch Optional(). Kann es sein, dass die Felder dann in der Eingabemaske korrekt leer sein dürfen (None), aber später bei der "Nutzung" (=entry.data.get()) das get(None) in einen Fehler läuft?

Ich probiere es erst mal mit Platzhaltern 👍

[PalmManiac]

Gibt es bei den Octopus-Entitäten keine, die in den Attributen vielleicht die Preisdaten liefert? Bei Tibber ist das so. Von außen siehst du nix außer den aktuellen Preis, in den Attributen werden dann aber alle Preise in 15Minuten-Schritten für 2 Tage geliefert. Hast du schon mal nachgesehen? Wenn es ihn gibt, dann schick mir mal den Inhalt der Attribute. Wenn nicht und die Preise ändern sich ja nie, vielleicht kannst du dann einen eigenen Sensor bauen, der die Preise ähnlich liefert. Wenn du das machen willst, dann würde ich dir zur Orientierung mal den von Tibber schicken, dann hast du das Format, den Aufbau und die Infos. Da hängt ne json dran, glaube ich.

[ldoellin]

Doch, der Preissensor hat in den Attributen auch die Timeslots mit Namen und Preisinfo.
(Momentan sind es nur 2 Slots, werden bei mir bald aber 5 sein. Ich hoffe Octopus gibt das dann in der Entität richtig weiter)

Hiermit kann man sie in ein json schreiben:

template:
  - sensor:
      - name: "Octopus Timeslots JSON"
        state: "ok"
        attributes:
          slots: >
            {% set slots = state_attr('sensor.octopus_energy','timeslots') %}
            {% if slots %}
            [
            {% for s in slots %}
              {
                "name": "{{ s.name }}",
                "from": "{{ s.activation_rules[0].from_time }}",
                "to": "{{ s.activation_rules[0].to_time }}",
                "rate": {{ s.rate | float }}
              }{% if not loop.last %},{% endif %}
            {% endfor %}
            ]
            {% else %}
            []
            {% endif %}

[PalmManiac]

Bingo, damit kann ich was anfangen und das wäre dann auch der Sensor, der ins Feld für dynamische Preise rein müßte.

Es gibt hier noch einen anderen Nutzer mit Octopus und dynamischen Preisen. Wenn er funktioniert, dann du auch. Das Datenformat ist ähnlich dem von Epex und das funktioniert schon. Ich schaus mir mal an und schaue, dass ich die notwendigen Anpassungen in den V2 Release mit einbauen kann.

[PalmManiac]

Die Beta2 ist raus. Einfach aktualisieren, danach in die Konfiguration und dort die Kapazität eines einzelnen Akku-Packs einstellen. In der GUI dann oben die Anzahl der verwendeten Akku-Packs einstellen und fertig. Die Tests können beginnen. :) Octopus-Energy wird jetzt unterstützt. :)

[RallyeB]

Versuche mal folgendes: Erstelle dir einen Helfer, am besten ein Number-Helper, nenne ihn Aktueller Strompreis oder so und stelle dort deinen Strompreis ein. Den nimmst du dann für das Feld Aktueller Strompreis. Kommst du dann weiter?

Version 1.5.1
Ich habe einen Number Helper mit meinem aktuellen Strompreis erstellt und konnte diesen in beiden Feldern "Preisverlauf" und "Aktueller Strompreis" wählen.
Im Feld "SoC-Limit Status" wird das socLimit des SF2400AC genutzt.

Damit werden die Felder korrekt validiert.
Ich hatte oben aber einen logischen Dreher. Korrekt ist: 0 = keine Begrenzung, 1 = Batterie voll / Ladelimit erreicht und 2 = Batterie leer / Entladelimit erreicht.

Anschließend startet die Integration. 👍

[PalmManiac]

V2.0.0-Beta2 ist raus. Das Feld Preisverlauf sollte kein Pflichtfeld sein und darf auch leer bleiben.