76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

minierm · 20 Januar 2025, 15:59:06

Zitat von: DS_Starter am 05 Januar 2025, 23:30:51- die Batterien bzw. deren Ladungsempfehlungs-Status für die kommenden Stunden können in der
Balkengrafik Ebene 1 eingeblendet werden. Ein Mouse-Over zeigt nähere Informationen zum Batteriestatus.

- Zur grafischen Steuerung der Batterien gibt es nun zusätzliche optionale Schlüssel und den setupBatteryDevXX Attributen

Ich fände es noch gut, wenn in der Vergangenheit der tatsächliche Ladestand der Batterie angezeigt wird, von mir aus auch über Parameter einblendbar.
Beim Forecast wird übrigens ein SoC von über 100% prognostiziert...
Warum meine Werte so schräg sind muss ich noch untersuchen, aber ich hab ja auch das Problem mit dem PV Zählerstand-Fehler, obwohl alles richtig angezeigt wird.
Du darfst diesen Dateianhang nicht ansehen.

300P · 20 Januar 2025, 16:18:35

Im Attribut "setupBatteryDev1" wird unter "cap" der Wert "Nennkapazität"eingetragen, den der Hersteller für diese Batterie (=100%) angibt:

Code Auswählen

cap    installierte Batteriekapazität. Option kann sein:
numerischer Wert - direkte Angabe der Batteriekapazität in Wh
<Readingname>:<Einheit> - Reading welches die Kapazität liefert und Einheit (Wh, kWh)

Im Lauf der Zeit steht dieser Wert aber dann nicht mehr voll zur Verfügung.
Er verringert sich leider immer mehr (damit meinte ich "Rest-Batteriekapazität" im Verhältnis zur Nennkapazität SoH).....

Im BWR kann man diesen (meist) als Readingwert % / Faktor etc. sehen.

Bei mir ist er bei einer Batterie bei 0.83 und bei einer bei 0.93.
Somit habe ich bei einer Nennkapazität von 9800 Watt bei der ersten Batterie nur noch (9800 * 0.83) 8134 Watt und bei der anderen (9800 * 0.93) 9114 Watt Restkapazität als Batteriespeicher zur Verfügung.
Der Wechselrichter berücksichtigt dies bei der Angabe bzw. Berechnung und anzeige des Ladestatus aber bereits.
Der Wert nützt mir deshalb auch nicht viel im SF.

Das ist ebenfalls ein reine Information wie "schlecht" meine Batterien im laufe der Betriebsjahre geworden sind.
Den Wert braucht man n.m.M. in SF auch nicht.

Gruß
300P

300P · 20 Januar 2025, 16:22:18

Zitat von: minierm am 20 Januar 2025, 15:59:06Ich fände es noch gut, wenn in der Vergangenheit der tatsächliche Ladestand der Batterie angezeigt wird, von mir aus auch über Parameter einblendbar.
Beim Forecast wird übrigens ein SoC von über 100% prognostiziert...
Warum meine Werte so schräg sind muss ich noch untersuchen, aber ich hab ja auch das Problem mit dem PV Zählerstand-Fehler, obwohl alles richtig angezeigt wird.

Nutze doch "graphicBeam3Content" und "graphicBeam4Content"

DS_Starter · 20 Januar 2025, 16:34:29

ZitatBeim Forecast wird übrigens ein SoC von über 100% prognostiziert...

Da fehlt eine Grenze nach oben im Code.
Fixe ich.

ZitatIch fände es noch gut, wenn in der Vergangenheit der tatsächliche Ladestand der Batterie angezeigt wird, von mir aus auch über Parameter einblendbar.

Der Wunsch kam hier bereits weiter vorn.
Das ist für mich schon etwas mehr Aufwand weshalb ich darauf verzichtet habe. Aber wenn es genug Interessenten dafür gibt kann ich mir das schon mal vornehmen.
Alternativ kann man aktuell dem Hinweis von 300P folgen ...

300P · 20 Januar 2025, 16:50:33

Zitat von: minierm am 20 Januar 2025, 15:59:06Beim Forecast wird übrigens ein SoC von über 100% prognostiziert...
Warum meine Werte so schräg sind muss ich noch untersuchen, aber ich hab ja auch das Problem mit dem PV Zählerstand-Fehler, obwohl alles richtig angezeigt wird.

Evtl. hast du noch nicht alle aktuellen Updates von SF geladen - da fehlen die 2 neuen Symbole (Wiki / Mitteilung)

Adimarantis · 20 Januar 2025, 17:20:59

Im Rahmen meiner ersten Einarbeitung in das Modul, hab ich Fragen zu den Comsumern:

pCurr: kann ich da auch einen DeviceNamen angeben? Ich hab gleich 2 Fälle bei denen der Stromverbrauch in einem ganzen anderen Device gemessen wird, als das eigentlich zu steuernde Device?

Wahrscheinlich hab ich all die Möglichkeiten noch nicht voll durchblickt um Geräte einzuschalten. Ich hätte aber folgendes Szenarios:

1. Eine Waschmaschine soll verzögert eingeschaltet werden. Es gibt ein Trigger, dass der RemoteStart (HomeConnect) aktiviert wurde. Wenn genug Strom da ist, kann sie gleich loslaufen, sonst darf sie maximal 30 Minuten stehen, sonst leidet der WAF. (Ähnliches für Spülmaschine) - eigentlich soll das hauptsächlich verhindern, dass beide Waschmaschinen gleichzeitig ihren Peak Verbrauch haben, was potentiell den Inverter meiner Batterie überfordern könnte.
2. Warmwasserwärmepumpe soll nur laufen wenn genug Strom da ist. Bei Überschuss bis zu 60 Grad, sonst reichen 50 Grad - wenn klar ist das die nächsten X Stunden kein Solarstrom da ist oder eine Mindesttemperatur unterschritten ist, muss sie trotzdem laufen, damit keiner kalt duschen muss
3. Umwälzpumpe Pool soll X Stunden am Tag laufen - wann ist egal, aber wenn der Strom nicht kommt, müssen die X Stunden/Tag trotzdem erreicht werden damit er nicht grün wird
4. Trockner darf pausiert werden, wenn nicht genug Strom da ist, soll aber auf jeden Fall spätestens nach X Stunden fertig sein

300P · 20 Januar 2025, 18:02:11

Zitat von: Adimarantis am 20 Januar 2025, 17:20:59Im Rahmen meiner ersten Einarbeitung in das Modul, hab ich Fragen zu den Comsumern:

pCurr: kann ich da auch einen DeviceNamen angeben? Ich hab gleich 2 Fälle bei denen der Stromverbrauch in einem ganzen anderen Device gemessen wird, als das eigentlich zu steuernde Device?

Auszug aus dem Wiki....

Code Auswählen

In dem nachfolgenden Beispiel (Homematic) ist eg.az.fridge_Pwr FHEM Device für die Energiemessung. Die Schlüssel pcurr und etotal geben Readings in diesem Device an damit SolarForecast den Verbrauch und die Energiemengen auslesen kann. Demgegenüber ist im Schlüssel switchdev das zugehörige Schalter-Device der Kombination angegeben.

eg.az.fridge_Pwr
type=noSchedule switchdev=eg.az.fridge_Sw power=0 icon=fridge pcurr=power:W:5 etotal=energyCalc:Wh 
swstate=state:on:off auto=automatic

Adimarantis · 20 Januar 2025, 18:45:19

Zitat von: 300P am 20 Januar 2025, 18:02:11Auszug aus dem Wiki....

Ja, aber nicht ganz die Lösung die ich im Sinn hatte.
Das Hauptdevice wäre dann der Stromzähler während das eigentlich zu regelnde Device nur im switchdev versteckt ist.
Ich fände es schicker, wenn man z.B. pcurr=[stromzähler:power]:W angeben könnte.
Entsprechend könnte man das auch für etotal und swstate machen (und sich switchdev komplett sparen)

DS_Starter · 20 Januar 2025, 19:02:27

ZitatIch fände es schicker, wenn man z.B. pcurr=[stromzähler:power]:W angeben könnte.
Entsprechend könnte man das auch für etotal und swstate machen (und sich switchdev komplett sparen)

Frage drei Leute und du bekommst drei Meinungen.

Der nächste würde einwenden wieso er denn vor jedes Reading noch das Device in den Schlüssel pcurr, etotal bzw. swstate, on, off etc. angeben muß wo doch eine einmalige Angabe reichen sollte das Device für Messen und Schalten zu definieren. Der Rest ergibt sich dann daraus ... und dieser Meinung bin ich ebenso.

Aber, wie gesagt, hat da wohl jeder so seine Vorlieben.

EDIT: Deine anderen UseCases für Verbraucher würde ich ggf. auch über das Wiki beantworten wenn es sich anbietet sie gleich für die Nachnutzung zu beschreiben. Sonst ist es einfach zu uneffektiv hier zu antworten ... das geht verloren.

Adimarantis · 20 Januar 2025, 19:09:47

Zitat von: DS_Starter am 20 Januar 2025, 19:02:27Der nächste würde einwenden wieso er denn vor jedes Reading noch das Device in den Schlüssel pcurr, etotal bzw. swstate, on, off etc. angeben muß wo doch eine einmalige Angabe reichen sollte

Das hatte ich Optional im Sinn - default wäre das Hauptdevice. Leider ist der ":" als Trenner vergeben, daher mein Beispiel mit Klammer wie in DOIF. Außerdem musst du ja möglichst Rückwärtskompatibel bleiben.
Aber wenn das nicht geht, eventuell zumindest eine Option den Namen zu überschreiben (aktuell ist ja scheinbar der alias der "Hauptdevice")?

ZitatEDIT: Deine anderen UseCases für Verbraucher würde ich ggf. auch über das Wiki beantworten wenn es sich anbietet sie gleich für die Nachnutzung zu beschreiben. Sonst ist es einfach zu uneffektiv hier zu antworten ... das geht verloren.

Gerne. Das mach ich auch oft so.

DS_Starter · 20 Januar 2025, 19:18:52

ZitatAber wenn das nicht geht, eventuell zumindest eine Option den Namen zu überschreiben (aktuell ist ja scheinbar der alias der "Hauptdevice")?

Das ist eigentlich eine Fallunterscheidung.
Vereint das Device Messung und Schaltung gibt man das Device am Beginn des Attr an und gut.
Sind Messung und Schaltung getrennt, gibt man das Device für die Messung am Beginn des Attr an und das Device für das Schalten über switchdev=<Dev> und damit ist die Sache erledigt.

Für diverse Anzeigen Mouse-Over etc. wird der Alias (falls gesetzt) als sprechender Name für die jeweiligen Devices herangezogen.
Insofern habe ich nicht wirklich verstanden was du gern überschreibbar haben möchtest?

Adimarantis · 20 Januar 2025, 19:26:54

Zitat von: DS_Starter am 20 Januar 2025, 19:18:52Insofern habe ich nicht wirklich verstanden was du gern überschreibbar haben möchtest?

Den Namen der in der Verbraucherliste (Grafikbereich 3) steht (bzw. MouseOver in der Grafik 5)
Da steht halt statt dem eigentlichen Gerät um das es geht jetzt "Stromzähler ..."

DS_Starter · 20 Januar 2025, 19:27:53

@minierm,

hast du in deinem Batteriedevice den Schlüssel "cap" angegeben und hat der den korrekten Wert?
Lt. Codierung kann SoC > 100% nur auftreten wenn die erreichte Ladung der Batterie über dem Wert lt. Schlüssel 'cap' liegt.

DS_Starter · 20 Januar 2025, 19:32:32

ZitatDen Namen der in der Verbraucherliste (Grafikbereich 3) steht (bzw. MouseOver in der Grafik 5)
Da steht halt statt dem eigentlichen Gerät um das es geht jetzt "Stromzähler ..."

Ja, bei diesen Anzeigen verwende ich den Alias der Dev sofern gesetzt. Der Alias ist meist ein sprechender Name der das Device besser beschreiben kann. Im einfachsten Fall einfach den Alias des Dev abändern oder gar löschen wenn er nicht gebraucht wird. Dann kommt der FHEM-Devicename.

Edit: Was auch relativ problemlos umsetzbar wäre z.B. bei der Definition

Code Auswählen

Steckdose1[:Alias für das Dev] switchdev=Steckdose1[:Alias für das Schalterdevice] icon=inverter@brown

Damit könnte man in SF einen anderen Alias verwenden als den Alias den man dem Devices in FHEM gegeben hat.

Adimarantis · 20 Januar 2025, 19:55:01

Zitat von: DS_Starter am 20 Januar 2025, 19:32:32Edit: Was auch relativ problemlos umsetzbar wäre z.B. bei der Definition

Code Auswählen Erweitern
Steckdose1[:Alias für das Dev] switchdev=Steckdose1[:Alias für das Schalterdevice] icon=inverter@brownDamit könnte man in SF einen anderen Alias verwenden als den Alias den man dem Devices in FHEM gegeben hat.

Das wäre doch schön - wenn ich den Alias im Device ändere schauts in der FHEM Übersicht wieder seltsam aus.