Leistungsprognose für Wechselrichter

[SparcWolf]

Ja stimmt. Schaue ich mir an.
Danke und Gruß,
  Guido.

[Hauswart]

Gemeint ist die Leistungsangabe für den Verbraucher lt. Herstellerangabe (so wie du es ztiert hast).
Eine Waschmaschine hat also ein Leistungsaufnahme von z.B. 2000W. Das ist anzugeben.
Nein, die Leistung in Watt.
Diese Grundlage hat nichts mit der power Angabe zu tun, zumindest nicht vordergründig.
Auch wenn die WM 2000W Leistung hat, wird sie in einer Stunde nicht 2000Wh verbrauchen, sondern (und das ist eine empirische Annahme) nur den Faktor 0.3 davon.
Dieses Aufteilung ist für die internen Berechnungsvorgänge von Bedeutung.
Nein, tut es nicht wie oben dargestellt.

power kann deswegen 0 gesetzt werden weil manche User die Einschaltung gemäß Planung auch ausführen lassen möchte wenn KEIN hinreichender Überschuß vorhanden ist. D.h. in diesem Fall wird wie geplant ein- und ausgeschaltet ohne den Überschuß zu beachten.

Okay danke. Dann ist es doch so wie ich anfangs vermute habe.

Bei Type other gebe ich aber dann aber die richtige Leistungaufnahme in Watt an? Sprich Kühlschrank hat theoretisch laut Datenblatt 100W ich weiss aber er verbraucht immer 40W, weil bei Type other nicht gerechnet wird.

Wäre es eventuell sinnvoll auch bei den anderen Typen eigene (ermittelte) Werte mitgeben zu können?

"washingmachine" => { f => 0.30, m => 0.40, l => 0.30, mt => 120

Code Auswählen Erweitern

MQTT2_DVES type=washingmachine,0.20,0.30,0.50,150 power=0 icon=scene_washing_machine swstate=state:on:off pcurr=ENERGY_Power:W etotal=ENERGY_Total:kWh

?

Oder bin ich derzeit auf dem Holzweg und es immer noch nicht verstanden?

[DS_Starter]

Moin,

Bei Type other gebe ich aber dann aber die richtige Leistungaufnahme in Watt an? Sprich Kühlschrank hat theoretisch laut Datenblatt 100W ich weiss aber er verbraucht immer 40W, weil bei Type other nicht gerechnet wird.

Eigentlich würde man hier 100W angeben, aber den Zusammenhang hast du richtig erkannt. 40W wäre ok.
Ich könnte natürlich auch noch einen Typ "fridge" eintragen.
Allerdings hatte ich es bisher als unwahrscheinlich angenommen, dass man einen Kühlschrank abhängig vom PV Überschuß schalten lässt ? Das verstehe ich ehrlich gesagt nicht.

Wäre es eventuell sinnvoll auch bei den anderen Typen eigene (ermittelte) Werte mitgeben zu können?

Daran habe ich auch schon gedacht, aber vorerst verworfen weil zuviel Freiheiten zu unvorhersehbaren Ergebnissen führen können. Vor allem wenn der Nutzer sich vorher nicht genügend Gedanken macht welche Auswirkungen die entsprechende Angabe hat.
Was ich aber vorhabe zu tun, ist diese Daten bei Verbrauchern mit Meßeinrichtungen aufzunehmen (passiert im Prinzip jetzt schon) und davon abgeleitet die default Werte zu interpolieren. Aber so einfach ist das im Detail auch nicht, vor allem im Bezug auf eine Fehlerbehandlung, Gerätetausch etc.

LG

[Dracolein]

Hier auch moin,
auf der Suche nach meinen aktuellen FHEMP-Probs habe ich gestern das Modul Freezemon installiert.

1.) Toi toi toi, seit 18h gestern abend noch keine erneuten Probleme aufgetaucht.
2.) Logfileeinträge gefunden, die ich informativ hier weitergeben möchte.
Soweit ich verstanden habe, wird alles >1s Freeze vom Modul erkannt und protokolliert. Vermutlich nicht relevant...
(habe freeze-Erkennung nun auf 2 Sekunden justiert)

1 - 2022-10-13: s:10:12:11 e:10:12:12 f:1.299 d:tmr-FHEM::SolarForecast::centralTask(PVVorschau)
1 - 2022-10-13: s:10:13:21 e:10:13:22 f:1.06 d:tmr-FHEM::SolarForecast::centralTask(PVVorschau)
1 - 2022-10-13: s:10:14:31 e:10:14:32 f:1.367 d:tmr-FHEM::SolarForecast::centralTask(PVVorschau)
1 - 2022-10-13: s:10:15:41 e:10:15:42 f:1.236 d:tmr-FHEM::SolarForecast::centralTask(PVVorschau)
1 - 2022-10-13: s:10:16:51 e:10:16:52 f:1.12 d:tmr-FHEM::SolarForecast::centralTask(PVVorschau)
1 - 2022-10-13: s:10:18:01 e:10:18:02 f:1.12 d:tmr-FHEM::SolarForecast::centralTask(PVVorschau)
1 - 2022-10-13: s:10:19:11 e:10:19:12 f:1.37 d:tmr-FHEM::SolarForecast::centralTask(PVVorschau)
1 - 2022-10-13: s:10:25:01 e:10:25:02 f:1.156 d:tmr-FHEM::SolarForecast::centralTask(PVVorschau)

Einzige sichtbare Aktivität des Moduls derzeit: es schaltet die Consumer an & aus wie gewünscht. Das tut es etwa seit 10h (vorher nicht ausreichend PV)

[ch.eick]

Moin,
Eigentlich würde man hier 100W angeben, aber den Zusammenhang hast du richtig erkannt. 40W wäre ok.
Ich könnte natürlich auch noch einen Typ "fridge" eintragen.
Allerdings hatte ich es bisher als unwahrscheinlich angenommen, dass man einen Kühlschrank abhängig vom PV Überschuß schalten lässt ? Das verstehe ich ehrlich gesagt nicht.

Das mache ich nur im Sommer mit dem Getränkekühlschrank, da ist aber nur der früheste Zeitpunkt und der späteste interessant.
Eigentlich reicht dafür auch eine reine Zeit/Kalender Steuerung, da im Sommer immer genügend Überschuss vorhanden ist und
auch die Temperatur gewährleistet werden sollte. Bei mir sind morgens um 9:00 uhr sogar noch die Eiswürfel im *** Fach gefroren.

Bei eine Gefriertruhe sollte man auf jeden Fall die Temperatur überwachen, da sollten aber 24h ohne sie zu öffnen möglich sein.

VG
   Christian

[DS_Starter]

Nein ist nicht relevant. Das sind keine wirklichen Freezes, die entstehen wenn durch einen externen Einfluß (DB oder Webseite antwortet nicht und FHEM muß warten) diese Situationen entstehen.

Solarforcast ist aber ein sehr aufwändiges und komplexes Modul. Es braucht also entsprechende Rechenpower.
Das sollte man wissen und beachten.

EDIT:

Einzige sichtbare Aktivität des Moduls derzeit: es schaltet die Consumer an & aus wie gewünscht. Das tut es etwa seit 10h (vorher nicht ausreichend PV)

Diese Schaltungen können natürlich zu Wartezuständen führen, je nachdem wie das "Consumermodul" arbeitet. Das kann SolarForecast nicht beeinflussen.

[Hauswart]

Moin,
Eigentlich würde man hier 100W angeben, aber den Zusammenhang hast du richtig erkannt. 40W wäre ok.
Ich könnte natürlich auch noch einen Typ "fridge" eintragen.
Allerdings hatte ich es bisher als unwahrscheinlich angenommen, dass man einen Kühlschrank abhängig vom PV Überschuß schalten lässt ? Das verstehe ich ehrlich gesagt nicht.

Es ist der Getränkekühlschrank in der Garage. Sehr gut dann habe ich es verstanden.

Daran habe ich auch schon gedacht, aber vorerst verworfen weil zuviel Freiheiten zu unvorhersehbaren Ergebnissen führen können. Vor allem wenn der Nutzer sich vorher nicht genügend Gedanken macht welche Auswirkungen die entsprechende Angabe hat.

Den Verbrauch genau analysieren und man kann in etwas abschätzen denke ich wie der Verbrauch sich verhält.

Was ich aber vorhabe zu tun, ist diese Daten bei Verbrauchern mit Meßeinrichtungen aufzunehmen (passiert im Prinzip jetzt schon) und davon abgeleitet die default Werte zu interpolieren. Aber so einfach ist das im Detail auch nicht, vor allem im Bezug auf eine Fehlerbehandlung, Gerätetausch etc.

Klingt sehr spannend. Z.B. durch Analyse von einem gesamten Lauf sich sogar selbst berechnen lassen? Natürlich nur wenn der Consumer auch seinen Verbrauch live mitteilt.

Danke übrigens für das Modul!

[DS_Starter]

Es ist der Getränkekühlschrank in der Garage. Sehr gut dann habe ich es verstanden.

Ich könnte den Typ mit einbauen. Wäre es hilfreich ?
Wenn ja, würde ich den Faktor 0.4  ( 100 -> 40) in den Berechnungshash für diesen Typ verwenden wollen.

[Dracolein]

Ich hätte eine Verständnisfrage zu Consumern.

Beim Maus-Hover auf das Uhrzeit-Symbol erscheint die zugehörigie Erklärung

Aktuelle Zeit liegt ausserhalb der Verbrauchsplanung
(klick für sofortige Verbrauchsplanung
...

Durch set xxx consumerImmediatePlaning.... kann ich die Planung anstoßen - ist verstanden und klappt.

Meine Frage: wann / wie oft plant das Modul selbstständig die Verbrauchsplanung?

Hintergrund:
Wieder bezogen auf meine IR-Heizungen, es ist z.B. vom Modul geplant 11:00 - 12:00 Uhr.
Entsprechend wird um 10:30 bei ausreichend PV-Überschuss der Consumer noch nicht automatisiert eingeschaltet.
Das würde ich jedoch gern hervorrufen, um überschüssigen Strom zu nutzen (und würde ggf. mithilfe o.g. Befehls ein kleines Doif basteln o.ä. glaubve aber primär ein Verständnisproblem zu haben)

(btw: mit frisch genähter Wunde am Finger tippt es sich grauenhaft  )

[vuffiraa]

Nein ist nicht relevant. Das sind keine wirklichen Freezes, die entstehen wenn durch einen externen Einfluß (DB oder Webseite antwortet nicht und FHEM muß warten) diese Situationen entstehen.

Solarforcast ist aber ein sehr aufwändiges und komplexes Modul. Es braucht also entsprechende Rechenpower.
Das sollte man wissen und beachten.

EDIT:Diese Schaltungen können natürlich zu Wartezuständen führen, je nachdem wie das "Consumermodul" arbeitet. Das kann SolarForecast nicht beeinflussen.

Zum Thema Freezes, mit deiner Version von gestern sind die Freezes bei mir beim Aufruf der SolaCast API von 10-12 Sekunden auf ca. 3 Sekunden runtergegangen. Im Log sehe ich zwar immer noch jeden Zugriff als Freeze, aber die Zeiten scheinen nicht mehr so dramatisch. Da fehlt nur noch eine kleine Optimierung  und mein System würde wieder Freeze-frei laufen. Bei mir ist die Erkennung eh schon auf > 2 Sekunden eingestellt.

VG

[Hauswart]

Ich könnte den Typ mit einbauen. Wäre es hilfreich ?
Wenn ja, würde ich den Faktor 0.4  ( 100 -> 40) in den Berechnungshash für diesen Typ verwenden wollen.

Die Leistungsaufnahme 100W war geraten, müsste ich erst nachschauen. Aber benötigt es bei einem konstanten Faktor (1.0) ja eigentlich auch nicht, dann gebe ich einfach weiterhin 40W ein? Oder siehst du weitere Vorteile darin?

[DS_Starter]

Meine Frage: wann / wie oft plant das Modul selbstständig die Verbrauchsplanung?

Die Einplanung erfolgt im Normalfall (es gibt Sonderfälle) täglich in der Stunde 00:00 - 01:00.
Es werden die Angaben im Consumer Attribut ausgewertet, insbesondere power (also was braucht der Consumer), notbefore und notafter (Zeitgrenzen die vom Anwender als Grenzwerte vorgegeben werden), mintime (wie lange muß der Consumer eingeplant werden) ausgewertet und in Relation zu den erwarteten Prognosen und Verbräuchen jeder Stunde gesetzt.
Hinzu kommt dann noch der mode (kann oder muß der Verbraucher geplat werden). Das bedeutet die Einplanung unterbleibt falls nicht genügend Überschuß erwartet wird und der mode=can ist.

Ob und wann ein Consumer innerhalb seiner Einplanung tatsächlich gestartet wird, hängt vom realen Überschuß ab in Verbindung mit den Vorgaben im Schlüssel swoncond, swoffcond, interruptable sowie on, off, auto.

Man kann den Zyklus automatisch neu planen lassen mit "set ... reset consumerPlanning <Verbrauchernummer>" wenn man das möchte.
Irgenwo weiter vorn habe ich einen Dummy aufgezeigt mit dem man etwas üben kann um das Verhalten kennenzulernen  ohne gleich produktiv einzusteigen.

Es ist ein weites Feld, ich weiß. Ein Wiki-Artikel ist überfälig ... Zeit ...

[DS_Starter]

Aber benötigt es bei einem konstanten Faktor (1.0) ja eigentlich auch nicht, dann gebe ich einfach weiterhin 40W ein? Oder siehst du weitere Vorteile darin?

Nur den Vorteil dass das Consumer Handling über die Schlüssel dann "aus einem Guß" für den User ist.
Sonst ist es eigentlich egal.

[DS_Starter]

Da fehlt nur noch eine kleine Optimierung  und mein System würde wieder Freeze-frei laufen.

Noch weniger Daten zu verarbeiten ist halt schwierig, siehe #1745 
Jetzt rufe ich nur noch den laufenden und kommenden Tag ab, weniger macht keinen Sinn.

[Dracolein]

Die Einplanung erfolgt im Normalfall (es gibt Sonderfälle) täglich in der Stunde 00:00 - 01:00.
Es werden die Angaben im Consumer Attribut ausgewertet, insbesondere power (also was braucht der Consumer), notbefore und notafter (Zeitgrenzen die vom Anwender als Grenzwerte vorgegeben werden), mintime (wie lange muß der Consumer eingeplant werden) ausgewertet und in Relation zu den erwarteten Prognosen und Verbräuchen jeder Stunde gesetzt.
Hinzu kommt dann noch der mode (kann oder muß der Verbraucher geplat werden). Das bedeutet die Einplanung unterbleibt falls nicht genügend Überschuß erwartet wird und der mode=can ist.

Ob und wann ein Consumer innerhalb seiner Einplanung tatsächlich gestartet wird, hängt vom realen Überschuß ab in Verbindung mit den Vorgaben im Schlüssel swoncond, swoffcond, interruptable sowie on, off, auto.

Man kann den Zyklus automatisch neu planen lassen mit "set ... reset consumerPlanning <Verbrauchernummer>" wenn man das möchte.
Irgenwo weiter vorn habe ich einen Dummy aufgezeigt mit dem man etwas üben kann um das Verhalten kennenzulernen  ohne gleich produktiv einzusteigen.

Es ist ein weites Feld, ich weiß. Ein Wiki-Artikel ist überfälig ... Zeit ...

Aha okay verstanden.
Noch eine Frage:
Wie nenne ich es..... das "Zeitfenster" welches die Planung vorsieht (ich bemerke bei mir ausschließlich immer nur 60 Minuten Zeitfenster), liesse sich das eventuell (zukünftig?) erweitern / beeinflussen?

Auf Basis der Prognose machen meine vom Modul geplanten Start-Zeitpunkte durchaus Sinn, enden aber nach Ablauf der 60 Minuten. Und dann wäre der restliche Nachmittag trotz massiv PV-Überschusses ungenutzt.
(Wobei.... ich mir irgendwie relativ sicher bin, dass meine Consumer tagsüber auch nach Überschreitung des 60-Min-Planungsfensters noch oft aktiviert wurden... kopfkratz)