Leistungsprognose für Wechselrichter

[DS_Starter]

@kask, ich habe mir deine Anmerkungen zu SoH nochmal durch den Kopf gehen lassen und habe den SoH-Terminus komplett eliminiert und durch eine andere/inhaltlich passendere Form ersetzt.
Das Steuerungsattribut ist auf Keys umgesetzt und ermöglicht so maximale Flexibilität.
Der Hilfetext lautet nun wie folgt:

ctrlBatSocManagement lowSoc=<Wert> upSoC=<Wert> [maxSoC=<Wert>] [careCycle=<Wert>]
Sofern ein Batterie Device (currentBatteryDev) installiert ist, aktiviert dieses Attribut das Batterie SoC-Management. Dadurch wird das Reading Battery_OptimumTargetSoC erstellt.
Dieses Reading kann zur Steuerung des SoC (State of Charge) im Batterie Device verwendet werden.
Anzugeben sind:

    lowSoc      unterer Mindest-SoC, die Batterie wird nicht tiefer als dieser Wert entladen (> 0)
    upSoC       oberer Mindest-SoC, der übliche Wert des optimalen SoC bewegt sich zwischen 'lowSoC'
                und diesem Wert.
    maxSoC      maximaler Mindest-SoC, SoC Wert der mindestens im Abstand von 'careCycle' Tagen erreicht
                werden muß um den Ladungsausgleich im Speicherverbund auszuführen.
                Die Angabe ist optional (default: 95 bzw. <= 100)
    careCycle   maximaler Abstand in Tagen, der zwischen zwei Ladungszuständen von mindestens 'maxSoC'
                auftreten darf. Die Angabe ist optional (default: 30)


Alle Werte sind ganze Zahlen in %. Dabei gilt: 'lowSoc' < 'upSoC' < 'maxSoC'.
Die Ermittlung des optimalen SoC erfolgt nach folgendem Schema:

1.    Ausgehend von 'lowSoc' wird der SoC am folgenden Tag um 5%, aber nicht höher als
   'upSoC' inkrementiert, sofern am laufenden Tag 'maxSoC' nicht erreicht wurde.
2.    Wird am laufenden Tag 'maxSoC' (wieder) erreicht, wird SoC um 5%, aber nicht tiefer als 'lowSoc', verringert.
3.    SoC wird soweit verringert, dass die prognostizierte PV Energie des aktuellen bzw. des folgenden Tages
   von der Batterie aufgenommen werden kann. SoC wird nicht tiefer als 'lowSoc' verringert.
4.    Das Modul erfasst den letzten Zeitpunkt am 'maxSoC'-Level, um eine Ladung auf 'maxSoC' mindestens alle 'careCycle'
   Tage zu realisieren. Zu diesem Zweck wird der optimierte SoC in Abhängigkeit der Resttage bis zum nächsten
   'careCycle' Zeitpunkt derart verändert, dass durch eine tägliche 5% SoC-Steigerung 'maxSoC' am 'careCycle' Punkt
   rechnerisch erreicht wird. Wird zwischenzeitlich 'maxSoC' erreicht, beginnt der 'careCycle' Zeitraum erneut.

    Beispiel:
    attr <name> ctrlBatSocManagement lowSoc=10 upSoC=50 maxSoC=99 careCycle=25

[stefanru]

Ich habe das Wiki überarbeitet (https://wiki.fhem.de/wiki/SolarForecast_FTUI_Widget).

@stefanru, Beim Test des widget_forecast Widgets ist mir aufgefallen, dass keine Befehle (update, ein/aus usw.) ausgeführt werden können und auf Fehler im JS laufen. Ich weiß auch schon woran es liegt und werde demnächst einen Fix ausrollen. Dann wird auch gleich das Update über den getter ftuiFramefiles getestet.

Hi Heiko,

oh stimmt, den Fehler hatte ich nicht bemerkt.
Ich bin zur Zeit etwas im Stress, schaue mir deine Lösung bei Gelegenheit an.

Danke,
Stefan

[CaptainHook]

Moin Zusammen,

was war den der Trick mit FTUI und der Skalierung? Die js, und css Dateien liegen im entsprechenden Ordner.

Code Auswählen Erweitern

<div data-type="forecast" data-device="SolarForecast_AI" data-get="state" data-html="forecast_noHead_noCons"></div>

Viele Grüße,
Stephan

[DS_Starter]

Hallo Stephan,

ich bin mir nicht sicher ob es da einen "Trick" gibt. Ich selber nutze die Widgets nur testweise, sehen aber beide vollkommen i.O. ohne irgendwelche besonderen Einstellungen.
Aber ich bin da nicht so der FTUI Spezi, vllt. Stefan, caldir65 oder kask.

LG

[kask]

Wie kann ich den den SOH selber bestimmen, um z.B. mal das E-Auto zu checken, da habe ich noch 5 Jahre Gewährleistung auf den Accu und möchte schnell reagieren können.

Den Soh kannst du dir nur bestimmen wenn du die Zellen einmal komplett leer machst und dann wieder voll lädst.
Dann schauen wieviel Ah hast du rein geschoben und wieviel war es einst. Ohne Referenzwert ist es schwer.

Anhand des Spannungslevels bekommst du nichts brauchbares raus. Zudem Brauchst du Zellendaten wieviel EntladeSpannung ist leer und wieviel Ladespannung ist voll.

Bei einem E-auto wird das doch sicher mit geloggt.
Ansonsten Routen vergleichen von jetzt und damals und da denn verbrauch kontrollieren bei ungefähren selben Witterungsverhätnissen. Würde ich mal versuchen.

[stefanru]

Hi,

nein eigentlich gibts da keinen Trick.
Sollte einfach so passen.

Habe deinen Zeile bei mir probiert funktioniert ohne Probleme.
<div data-type="forecast" data-device="SolarForecast_AI" data-get="state" data-html="forecast_noHead_noCons"></div>

Hab sogar das css weg gemacht geht immer noch.

Das Problem war doch hier schonmal?
War da nicht jemand fremde icons reingerutscht?
Heiko ich glaube du hattest geholfen das zu finden da war ein falsches PNG irgendwo oder soetwas.

Gruß,
Stefan

[CaptainHook]

Moin,

Fehler gefunden, mir fehlte die Datei "css/ftui_forecast.css", es scheint als ob diese vom Module nicht automatisch erzeugt wird.
Der File check prüft diese nicht, siehe Screenshot. Version ist die 1.5.1

Grüße,
Stephan

[DS_Starter]

Moin,

Der File check prüft diese nicht, siehe Screenshot. Version ist die 1.5.1

Erstelle / Teste gerade die V1.6.0. In der V passt der Check (siehe Anhang).

LG

[grappa24]

Eine Frage zur Consumer-Steuerung

Code Auswählen Erweitern

MQTT2_shellyplug_s_977FC2 type=charger mintime=180 mode=can on=on off=off power=0 pcurr=relay_0_power auto=automatic interruptable=1 icon=batterie
mein o.a. Consumer wird geladen, obwohl gerade kein PV-Überschuss existiert. Hab ich da etwas falsch verstanden?

[DS_Starter]

Hab ich da etwas falsch verstanden?

Etwas nicht beachtet. Die Angabe power=0 bwirkt, dass ein PV Überschuß nicht beachtet wird.
Du musst power=X angeben, wobei X die typische Leistungsaufnahme von MQTT2_shellyplug_s_977FC2 ist.

[stefanru]

Moin,

Fehler gefunden, mir fehlte die Datei "css/ftui_forecast.css", es scheint als ob diese vom Module nicht automatisch erzeugt wird.
Der File check prüft diese nicht, siehe Screenshot. Version ist die 1.5.1

Grüße,
Stephan

Ah ok, interessant.
Dann war bei mir die CSS wohl noch im Browser Cache, hatte extra versucht den Fehler ohne CSS nachzustellen.
Naja hauptsache du hast es gefunden und Heiko hat den Check ja schon angepasst, super!

Danke,
Stefan

[DS_Starter]

Hallo zusammen,

ich habe die Version 1.6.0 zunächst in mein contrib geladen damit, wer möchte, sie mal mit testen kann.

Changelog:

- im set currentBatteryDev gibt es den neuen optionalen key 'cap', der die nominale Kapazität des angeschlossenen Batterieverbundes benennt
- das neue Attr ctrlBatSocManagement aktiviert das Battrie SoC Management und stellt einen optimalen
  SoC im Reading Battery_OptimumTargetSoC zur Verfügung.
- ein Problem im Hysteresealgo der Consumersteuerung ist gefixt, dazu ist auch die Hilfe angepasst
- der Einordnung des Bewölkungsgrades, Regengrades und Temp. in die sogenannten Bins ist verfeinert/verbessert
- kleinere Code Anpassungen und Fixes

Gerade das Ergebnis der SoC Berechnung ist momentan im Fokus meiner Tests. Ich steuere damit noch nichts aktiv, sondern stelle den SoC wie vom Modul vorgeschlagen manuell in der Batterie ein und verfolge aktiv wie sich das Verhalten darstellt.
In der Hilfe zum Attr ctrlBatSocManagement steht genau drin wie es anzulegen ist und wie das Optimierungsverfahren gebaut ist.
Wer das Attr ctrlBatSocManagement mal testen möchte, kann das gern ausprobieren. Aber vorerst bitte "trocken" üben und schauen wie sich die Anlage verhält.

LG,
Heiko

[kask]

Vieleicht hilft es ja auch einem.
Da ich mir gefühlte 4515188 mal die pvHistory versemmelt habe. Zum löschen der Falscheinträge noch einmal 9808848 Jahre die Historys durchsucht habe.
War ich es nun leid und habe mir ein kleines Tool gebastelt um die falschen  Datensätze schnell zu lokalisieren.
Dazu kopiere ich mir einfach den Text aus dem "get forecast pvHistory" Antwortfenster und öffne das kopierte dann in dem Tool über den Button.
Ein sortieren der einzelnen Spalten erfolgt über einen klick auf den Header der Spalten (auf.-und abwärts im wechsel). Recht simpel.

[DS_Starter]

Interessant wäre natürlich wieso du dir so oft Falscheinträge einhandelst.
Hast du eine Idee?

[kask]

Weil ich doof bin
Ich spiele hier und da rum. Optimiere das ein oder andere. Zumindest ist das der Plan. Und dann schwups was nicht bedacht. Eigentlich immer kaputt optimieren 
Das habe ich drauf!

Und irgend wann fällt mir auf das irgend was nicht stimmt, meist bis jetzt der Comsumption forecast.
Und dann geht das suchen los wann ich was vermamelt habe.

So wie auf den Bildern zusehen.
Am 18ten um 15Uhr ging was schief.

Eintrag gelöscht, und sofort ist alles tutti.