76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Meine Frau hat eben um ca 20:00 unsere Waschmaschine gepackt und wie immer per Alexa "geplant".

Welcher Befehl bezüglich des SF-Moduls wird denn bei der Planung per Alexa ausgeführt?

[Skusi]

Welcher Befehl bezüglich des SF-Moduls wird denn bei der Planung per Alexa ausgeführt?

-Der Ablauf ist folgender:
-Wir packen die Maschine die dauerhaft per Zigbee Steckdose ausgeschaltet ist.
-Dann schalten wir per Alexa diese Steckdose ein und starten die Maschine.
-Ein DOIF schaltet ab einer gewissen Leistung, die an der Steckdose gemessen wird wenn die Maschine
 erstmals Wasser zieht wieder aus und setzt ein Reading "automatic" im Steckdosen Device auf "1"
-Dieses Reading ist die im SF Modul im consumer hinterlegt und schaltet die Automatik ein.

Das funktioniert schon lange super.

Wenn ich so darüber nachdenke, stellt sich mir die Frage wann das SF Modul die Planung der Ein Aus Zeiten triggert. Und warum können Zeiten geplant werden die außerhalb der notbefore=09 notafter=17 liegen ?
 

[Max_Meyer]

ch bin sehr daran interessiert, von anderen Nutzern folgende Daten zu bekommen:

Für den Zeitraum 27.März - 3.April, sowie vom 4.April - 11.April

- Vom DWD vorhergesagte solare Einstrahlung
- Vom Modul SolarForecast vorhergesagtes solares Ergebnis
- Tatsächlich gemessenes solares Ergebnis
- Ungefährer Standort der Anlage

Hallo
anbei die gewünschten Daten - leider ein bisschen spät
Gruß Max

[Bison]

Hallo Heiko,

mein Consumer01 ist ein Entfeuchter im Keller. Dieser sollte bei Überschuss anspringen und dann für mindesten 15 Minuten laufen. Das  ein und ausschalten funktioniert so weit ganz gut mit folgendem Consumer01 Attribut.

STD_AKT_1_Pwr type=heater power=250 switchdev=STD_AKT_1_Sw mode=can icon=Ventilator_wind on=on off=off pcurr=power:W:250 etotal=energy:Wh interruptable=0 asynchron=0 swstate=state:on:off  locktime=900:900

allerdings feuert mir SolarForecast nun alle 4 sec ein on und später alle 4 sec ein off an meinen STD_AKT_1_Sw.

wie kann ich das abschalten weil meine FHEM Installation damit ganz schon ins schwitzen kommt.

Gruß

Bison

[DS_Starter]

@Skusi,

Wenn ich so darüber nachdenke, stellt sich mir die Frage wann das SF Modul die Planung der Ein Aus Zeiten triggert. Und warum können Zeiten geplant werden die außerhalb der notbefore=09 notafter=17 liegen ?

Das Modul führt ein Replanning für Verbraucher aus, die in der ursprünglich geplanten Zeit nicht gestartet wurden bzw. nicht gestartet werden konnnten. Der Key notafter=17 besagt, dass die geplante Startzeit nicht nach 17:00 sein soll. Aber es ist durchaus legitim den Verbraucher z.B. mit Startzeit 16:50 zu planen. Die Endezeit liegt dann entsprechend mintime nach 17:00, d.h. der Verbraucher kann durchaus nach 17:00 starten sobald die Automatic aktiviert wurde und die Zeit innerhalb der Planungzeit liegt.
Und weil der Verbaucher mit mode=must definiert ist, erfolgt die Einschaltung auch bei ungenügenden Überschuß.

Du kannst dir das genauer anschauen mit ctrl Debug=consumerPlanning,consumerSwitching.

Grüße,
Heiko

[DS_Starter]

@Bison,

allerdings feuert mir SolarForecast nun alle 4 sec ein on und später alle 4 sec ein off an meinen STD_AKT_1_Sw.

In diesem Fall bekommt SF den Schaltstatus nicht korrekt mitgeteilt und versucht immer wieder den on bzw. off-Status zu erreichen.
Du müsstest den Schlüssel swstate mit den richtigen Regex angeben.

LG,
Heiko

[Bison]

Hallo Heiko,

die Homematic Schalter

channel_01 STD_AKT_1_Sw
channel_02 STD_AKT_1_Pwr
channel_03 STD_AKT_1_SenPwr
channel_04 STD_AKT_1_SenI
channel_05 STD_AKT_1_SenU
channel_06 STD_AKT_1_SenF

haben die Informationen in diversen Channel versteckt.

könnte ich

swstate=STD_AKT_1_Sw:state:on:off

eingeben?

Gruß

Bison

[cbl]

An dieser Stelle mein Dank an alle, die Daten zur Verfügung gestellt haben ! Jetzt muss ich die "nur noch" irgendwie systematisieren.

Größere Abweichungen zwischen Prognose und Realität habe ich auch diese Woche (siehe Anhang(. Derart weit auseinander waren Prognose und Realität in den vorhergehenden Wochen selten. Die KI sagt bei mir allerdings neuerdings im Modul meist "KI arbeitet einwandfrei, aber für die aktuelle Stunde ist kein Wert verfügbar".
Im pvCorrectionFactor_* gab es heute in allen Stunden zwischen Sonnenauf- und -untergang 3 bis 8 "days in range", womit ich erwartet hätte, dass es zumindest etwas "Futter" für die Prognose gegegeben hätte.

Gruß
Christian

[DS_Starter]

@Bison,
ja die geteilten Homematic habe ich auch eingebunden.
Einfach:

 swstate=state:on:off

angeben. Hier ist ein komplettes Beipiel von meinem Homematicschalter:

Code Auswählen Erweitern

eg.flur.server_Pwr switchdev=eg.flur.server_Sw type=noSchedule power=70 icon=it_nas swstate=state:on:off pcurr=power:W etotal=energyCalc:Wh


[DS_Starter]

@Christian,

Die KI sagt bei mir allerdings neuerdings im Modul meist "KI arbeitet einwandfrei, aber für die aktuelle Stunde ist kein Wert verfügbar".

Ja, ist kein Grund zur Sorge. Allerdings sagt die KI "... liefert keinen Werte für die aktuelle Stunde".
Eine KI hat etliche Parameter die zu einer Entscheidung beitragen. Wenn es keine Entscheidung seitens der KI gibt, liefert sie keine und das Modul verwendet die Vorhersage des gewählten Dienstes mit Anpassungen durch die Modullogik.
Die pvCorrectionFactor_* gehören zur Modullogik. Die KI hat ihren eigenen Entscheidungpfad. Das kannst du die (näherungsweise) mit "get ... valDecTree aiRuleStrings" anschauen um eine ungefähre Vorstellung zu erhalten.

Auch wenn die Trefferquote der Vorhersagen schon ziemlich gut ist, unterliegen die Vorhersagen immer Störfaktoren. Eine Wolke über längere Zeit am falschen Fleck kann schon den Stundenwert stark beeinflussen.
Und wir müssen uns auch immer vor Augen halten, dass die Inputparameter über die gewählten Wetterdienste auch fehlerbehaftet sind und nicht immer und unbedingt die tatsächlichen Verhältnisse vorhersagen.

[cbl]

@cbl, mach mal bitte ein Screenhot der gesamten Grafik (mit Balken).
Bei mir sehe ich momentan kein Prob mit zu vielen Consumern und vermute eine Abhängigkeit in der Gesamtzusammenstellung.

Den Beitrag hatte ich übersehen.

Voilà:

Du darfst diesen Dateianhang nicht ansehen.

Gruß
Christian

[DS_Starter]

Moin Christian,

du kannst das Attr flowGraphicSize benutzen um das Größenverhältnis zu der übrigen Grafik anzupassen.

LG

[Bison]

Hallo Heiko,

ich habe den ganzen Tag mit Sonne genutzt um meinen Entfeuchter über SoalrForecast zum laufen zu bringen. Deinem Hinweis zur Folge habe ich swstate mir mal angeschaut. Hier habe ich folgendes Problem.

Im Homematic device Steckdose wird im Reading  STD_AKT_1_Sw im state set STD_AKT_1_Sw off noArg übergeben.

Die Abfrage von SolarForecast auf on/off match daher nicht und SolarForecast schickt erneut einen SetBefehl.

Der state ändert sich nicht und die Loop (Freund des Programmierers) ist da.

Ich habe versucht mir .*on.* oder .*off.*  den Loop zu unterbrechen. Das funktioniert leider nicht.

Ich denke  wenn das Attribut swstate auf das Haupt device STD_AKT_1 gehen würde wäre das schön.

Gruß

Bison

[DS_Starter]

Im Homematic device Steckdose wird im Reading  STD_AKT_1_Sw im state set STD_AKT_1_Sw off noArg übergeben.

Das verstehe ich nicht... Welches Reading ... state?
Du kannst dir im Device STD_AKT_1_Sw auch ein userReading anlegen welches den Schaltzustand abbildet und dieses Reading im SF angeben, also z.B.:

  swstate=<dein_userreading>:.*on.*:.*off.*

Ergänzung: Wenn du ctrlDebug=consumerSwitching setzt und das Ergebnis postest sieht man u.U. mehr bzgl. des Problems.

[cbl]

Moin Christian,

du kannst das Attr flowGraphicSize benutzen um das Größenverhältnis zu der übrigen Grafik anzupassen.

LG

Hallo,

vielen Dank für den Hinweis. In diesem Modul ist wirklich an alles gedacht! Natürlich löst das das Problem.
Ich wäre nur bei "Größe der Grafik" nicht an eine Abhängigkeit zu Verbrauchern darunter gekommen. Mit weniger Pixeln kann ich nun mehr sehen. 350 statt 400 Pixeln im Default haben das Problem bereits gelöst.

Vielen Gruß
Christian