76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

mmmmh kann das Ergebnis vom "get ... ValConsumer" hier irgendwie nicht einfügen - kommt immer wieder die Meldung des Forums mit "Bitte versuche es nochmal. Sollte der Fehler wieder auftreten, informiere bitte den Administrator."

Versuche es gleich von einem anderen Rechner.

[300P]

...scheinbar (komplett) zu groß:

Hier der Consumer 7 /8:

Code Auswählen Erweitern


07 => alias => SW Urlaubslicht-Wohnzimmer
      asynchron => 0
      auto => 1
      autoreading => solarforecast_auto
      avgenergy => 0.01
      currpowerpercent => 0
      cycleDayNum => 0
      cycleStarttime => 1732651456
      cycleTime => 70.75
      dspignorecond =>
      dswitch => tuya_local_bfac44fb487476efd1vhdu
      dswoffcond =>
      dswoncond =>
      energythreshold =>
      epiecAVG => 1=0.00
      epiecAVG_hours => 1
      epiecHist => 1
      epiecHist_1 => 1=0.01 2=0.00
      epiecHist_10 =>
      epiecHist_1_hours => 2
      epiecHist_2 =>
      epiecHist_3 =>
      epiecHist_4 =>
      epiecHist_5 =>
      epiecHist_6 =>
      epiecHist_7 =>
      epiecHist_8 =>
      epiecHist_9 =>
      epiecHour => -1
      epiecStartEtotal => 63.908
      epiecStartTime => 1732651441
      epieces => 1=5.00
      exconfc => 0
      hysteresis => 0
      icon => weather_sunset@orange
      interruptable => 0
      isConsumptionRecommended => 1
      isIntimeframe => 0
      lastMinutesOn => 0
      lastOnTime => 1732655716
      locktime => 0:0
      logoffon => off
      mintime => 60
      minutesOn => 0
      mode => can
      name => tuya_local_bfac44fb487476efd1vhdu
      noshow => 0
      notafter =>
      notbefore =>
      offcom =>
      offreg => off
      oncom =>
      onoff => off
      onreg => on
      physoffon => off
      planSupplement =>
      planstate => noSchedule
      power => 5
      powerthreshold => 3
      remainTime => 0
      retotal => energy
      rigncond =>
      rpcurr => cur_power
      rswoffcond =>
      rswoncond =>
      rswstate => state
      runtimeAvgDay => 72.00
      spignorecondregex =>
      startTime => 1732654800
      state => off
      swoffcondregex =>
      swoncondregex =>
      type => noSchedule
      uetotal => Wh
      upcurr => W

08 => alias => SW Urlaubslicht-Wohnzimmer
      asynchron => 0
      auto => 1
      autoreading => solarforecast_auto
      avgenergy => 0.14
      currpowerpercent => 0
      cycleDayNum => 0
      cycleStarttime => 1732651456
      cycleTime => 70.75
      dspignorecond =>
      dswitch => tuya_local_bfac44fb487476efd1vhdu
      dswoffcond =>
      dswoncond =>
      energythreshold =>
      epiecAVG => 1=0.00
      epiecAVG_hours => 1
      epiecHist => 3
      epiecHist_1 => 1=0.00
      epiecHist_10 => 1=0.00
      epiecHist_10_hours => 0
      epiecHist_1_hours => 0
      epiecHist_2 => 1=0.00
      epiecHist_2_hours => 1
      epiecHist_3 => 1=0.01 2=0.00
      epiecHist_3_hours => 2
      epiecHist_4 => 1=0.03 2=0.00
      epiecHist_4_hours => 2
      epiecHist_5 => 1=0.00
      epiecHist_5_hours => 0
      epiecHist_6 => 1=0.00
      epiecHist_6_hours => 0
      epiecHist_7 => 1=0.00
      epiecHist_7_hours => 0
      epiecHist_8 => 1=0.00
      epiecHist_8_hours => 0
      epiecHist_9 => 1=0.00
      epiecHist_9_hours => 0
      epiecHour => -1
      epiecStartEtotal => 63.908
      epiecStartTime => 1732651471
      epieces => 1=5.00
      exconfc => 0
      hysteresis => 0
      icon => weather_sunset@orange
      interruptable => 0
      isConsumptionRecommended => 1
      isIntimeframe => 0
      lastMinutesOn => 0
      lastOnTime => 1732655716
      locktime => 0:0
      logoffon => off
      mintime => 60
      minutesOn => 0
      mode => can
      name => tuya_local_bfac44fb487476efd1vhdu
      noshow => 0
      notafter =>
      notbefore =>
      offcom =>
      offreg => off
      oncom =>
      onoff => off
      onreg => on
      physoffon => off
      planSupplement =>
      planstate => noSchedule
      power => 5
      powerthreshold => 3
      remainTime => 0
      retotal => energy
      rigncond =>
      rpcurr => cur_power
      rswoffcond =>
      rswoncond =>
      rswstate => state
      runtimeAvgDay => 128.58
      spignorecondregex =>
      startTime => 1732654800
      state => off
      swoffcondregex =>
      swoncondregex =>
      type => noSchedule
      uetotal => Wh
      upcurr => W
und Auszug (RAW) des Device

Code Auswählen Erweitern

attr Forecast consumer01 FBDECT_fbahahttp_11657_0127183 icon=scene_washing_machine@orange type=washingmachine power=10 swstate:state notbefore=09 notafter=20 pcurr=power:W:3 etotal=energy:Wh interruptable=1 auto=solarforecast_auto
attr Forecast consumer02 FBDECT_fbahahttp_E8_DF_70_07_3E_57 icon=light_floor_lamp@orange type=other power=15 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto
attr Forecast consumer03 FBDECT_fbahahttp_E8_DF_70_07_42_0B icon=raspberrypi@orange type=other power=8 swstate:state pcurr=power:W:1 etotal=energy:Wh interruptable=0 auto=solarforecast_auto
attr Forecast consumer04 FBDECT_fbahahttp_11657_0067275 icon=springbrunnen_icon@orange type=other power=50 swstate:state pcurr=power:W:10 etotal=energy:Wh interruptable=0 auto=solarforecast_auto
attr Forecast consumer05 FBDECT_fbahahttp_34_31_C4_D4_31_37 icon=sani_domestic_waterworks@orange type=other power=10 swstate:state pcurr=power:W:3 etotal=energy:Wh auto=solarforecast_auto
attr Forecast consumer06 tuya_local_bf5037060f450bdbd4rl0q icon=scene_clothes_dryer@orange type=dryer power=10 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto
attr Forecast consumer07 tuya_local_bfac44fb487476efd1vhdu icon=weather_sunset@orange type=noSchedule power=5 swstate:state pcurr=cur_power:W:3 etotal=energy:Wh auto=solarforecast_auto
attr Forecast consumerAdviceIcon light_light_dim_100@gold
at
EDIT 1:

Ich lösche jetzt einmal den Consumer 7 (8 ist als Attribut ja nicht vorhanden).



....
der Consumer8 bleibt auch nach einem FHEM-Neustart bestehen ?!?

EDIT 2:
Lege (Kopie von Consumer 7 ) den Consumer 8 einfach jetzt mal an.

Jetzt ist nur noch ein Consumer ( vorhanden... ? ? ?

EDIT 3:
Grad fäll mir ein das ich vor einiger Zeit den Consumer 7 gelöscht hatte.
Irgendwann danach habe ich den Consumer 8 in Consumer 7 kopiert und danach den Consumer 8 gelöscht.(diverse reboot / Neustart nach dem löschen)
Vermutlich bleibt irgendwo (Moduldaten/FHEM) davon was hängen und hat diese Daten jetzt im Hintergrund hervorgekramt.

[DS_Starter]

Moin,

deswegen wird der Consumer angezeigt. Die Infos werden bei einem Restart aus ../FHEM/FhemUtils/PVCsm_SolarForecast_<name> wiederhergestellt.
In diesem File ist der Consumer noch vorhanden und wurde beim Löschen des Attr nicht rausgelöscht bzw. vllt. das File mal wiederhergestellt aus einem Backup?

Ist jetzt schwer zu sagen, evtl. siehst du am Timestamp des Files einen Hinweis.

Zur Lösung lege das Attr Consumer08 mit beliebigen Inhalt einfach nochmal an und lösche es dann gleich wieder. In dem besagten File sollte der Consumer dann auch entfernt sein.

[300P]

Jepp  - das war die Lösung

[DS_Starter]

Vermutlich bleibt irgendwo (Moduldaten/FHEM) davon was hängen und hat diese Daten jetzt im Hintergrund hervorgekramt.

Die oben angebene Datei ist der heilige Gral für die Consumer.    Sie wird auch regelmäßig oder beim shutdown bzw. bei den Änderungen der Consumer-Attr geschrieben.
Möglicherweise ist da mal was schief gegangen.

Ich stelle ja schon zwei Cache-Files zum Recover in "set ... operatingMemory recover-<Datei>" zur Verfügung.
Damit kann man ältere Versionen dieser Cache-Dateien zurückholen. Vllt. macht es Sinn auch die Consumerdatei mit anzubieten. Muss ich mal überlegen. Da sind auch Bewegungsdaten drin wie Einplanungen etc. Könnte auch kontraproduktiv sein ältere Stände einzuspielen.
Wie dem auch sein, muß ich mir erst durch den Kopf gehen lassen.

[DS_Starter]

@all,

weiter vorn gab es ein paar Diskussionen zum Thema (negativen) Verbrauch und der Berechnung des Verbrauchs.
Ich habe einen Beitrag im Wiki zu diesem Thema eingefügt.

Begleitend dazu ist eine neue Version 1.37.8 eingecheckt (und auch im contrib abgelegt) die bei gesetzten Attr ctrlDebug=collectData eine bessere Nachvollziehbarkeit bzgl. "Consumption" bietet.

LG

[DS_Starter]

Hallo zusammen,

wie ihr sicherlich bemerkt habt, wurden die letzten Tage bereits einige Updates des Moduls ausgeliefert.
Nun ist die V 1.38.0 eingecheckt und auch im contrib verfügbar.
Wenn ihr die contrib Version vorab nutzen möchtet unbedingt FHEM restarten nach dem Download.

Mit dieser Version ist der Request von Fichtennadel aus #1310 umgesetzt.
Es ist nun möglich die Datenquellen für Strahlungsdaten und Wetterdaten weitestgehend unabhängig voneinder einzusetzen, auch wenn beides API-Dienste sind.
Ein Einschränking gibt es wenn beide Dienste OpenMeteo Services sind. Dann wird auf einen Dienst harmonisiert da es hinsichtlich der täglichen Abrufe Beschränkungen gibt die es zu beachten gilt, insbesondere bei Ensemble-API's in Verbindung mit mehreren vorhandenen Strings.

Zur Umsetzung wurden die modulinternen Steuerungsstrukturen umgebaut und entkoppelt.
Sichtbar für den User sind insbesondere folgende Punkte:

- Getter solApiData in radiationApiData umbenannt!
- neue Getter statusApiData, weatherApiData
- zusätzlich zum Internal MODEL gibt es nun auch ein Internal WEATHERMODEL

Weiterhin:

- bei der Umbennung des SF-Devices werden auch die Sicherungsdateien im Verz. ../FHEM/FhemUtils entsprechend
  umbenannt/angepasst. Der User muß sich darum nicht kümmern.


@Fichtennadel, ich hatte dir schon eine PM bzgl. eines evtl. separaten OpenMeteo Devices geschrieben.
Bei meinen Umbauten ist mir noch einmal bewusst geworden, dass ein separates Devices nicht so ohne Weiteres realisierbar ist wenn es auch die PV Prognosedaten (GTI) bereitstellen soll.
Grund ist, dass man OpenMeteo die Anlagendaten wie Azimuth und Neigungswinkel mitgeben muss und dies auch für jeden einzelnen vorhandenen String separat an die OpenMeteo-API senden muß. Die Daten müssen dann entsprechend der Anlagenarchitektur konsolidiert werden. So wird es im SF-Modul intern ausgeführt.
Bei einem separaten OpenMeteo-Modul hat man die benötigten Input-Parameter nicht verfügbar. Man kann sie natürlich aus dem SF-Device holen, aber dann stellt sich die Frage nach dem Sinn eines separaten Moduls.

Was aber ganz autark gehen würde, ist die Bereitstellung von Wetterdaten. Sie wären unabhängig.

LG,
Heiko

[SparcWolf]

Hallo Heiko,

bei mir ist irgendwann ein roofIdentPair verloren gegangen.
Ich hatte gestern auf 1.37.8 aktualisiert.
Heute Morgen war dann die API rot (Oben Rechts).
Der Check hat dann gemeldet, dass für eine Fläche die API Daten fehlen.
Leider kann ich nicht sagen, ob der Fehler schon vorher da war.

Ich habe beide Flächen eingetragen und jetzt läuft es wieder.
Ich habe einen API-Key und zwei rtIDs.

Viele Grüße,
  Guido.

[DS_Starter]

Hi Guido,

möglicherweise hast du längere Zeit kein Update vorgenommen.
Bei den aktuell dynamischen Weiterentwicklungen achte ich darauf dass "unterwegs" möglichst nichts verloren geht.
Es ist für die User wahrscheinlich nicht so einfach jedes Update mitzumachen. Deswegen bleibt durch die Weiterentwicklung verursachtes internes automatisches Datenmanagement über längere Zeit erhalten. Irgendwann (so ca. 1-2 Monate) entferne ich den Code jedoch. Wer also längere Zeit nicht upgedated hat, könnte in ein solches "Problem" laufen. Wobei in den meisten Fällen, wie jetzt bei dir, ein einfaches Korrigieren der fehlenden Werte reicht es zu lösen.

Manchmal kann ich jedoch trotz aller Tests auch einen Fehler machen, das ist ganz klar.
Deswegen sind solche Hinweise sehr hilfreich, vielen Dank dafür!

LG,
Heiko

[DS_Starter]

Guten Abend,

morgen früh gibt es wieder ein Update des Moduls und auch der Bibliotheken ErrCodes.pm, SMUtils.pm

Die Inverter (setupInverterDevXX) und das Meterdevice (setupMeterDev) können jetzt mit dem optionalen Schlüssel asynchron=1 versehen werden.

Ist dieser Parameter gesetzt, wird bei Empfang eines Events eines Inverters oder des Meters die Datensammlung des Moduls unabhängig/zusätzlich der Einstellung von Attr ctrlInterval gestartet.
Dadurch ist es möglich, die Daten im Modul mit den Readings/Daten der Inverter und des Meters zeitgleich synchron zu halten.
Sollte es notwendig oder gewünscht werden, kann ich diese Funktionalität auch noch auf die Geräte in setupOtherProducerXX, setupBatteryDev erweitern.

LG,
Heiko   

[stefanru]

Hi Heiko,

das klingt sehr interessant.
Werde ich mir anschauen.

Danke!
Stefan

[TheTrumpeter]

bei Empfang eines Events eines Inverters oder des Meters die Datensammlung des Moduls unabhängig/zusätzlich der Einstellung von Attr ctrlInterval gestartet

Was hat das für einen Einfluss auf die Rechenlast?
(Sowohl Inverter als auch Meter laufen bei mir im 5-Sekunden-Takt...)

[The Grue]

Gibt es eine Möglichkeit den `mode` eines Consumers per Reading zu steuern?

Anwendungsfall: Der Akku meines Rollers soll geladen werden. Erstmal ist es nicht dringend, also wäre der Mode "can". Wenn ich aber erfahre, daß ich morgen unbedingt weg muss, würde ich gerne auf "must" umschalten.

Weiter so und großes Dankeschön

[DS_Starter]

Was hat das für einen Einfluss auf die Rechenlast?
(Sowohl Inverter als auch Meter laufen bei mir im 5-Sekunden-Takt...)

Die Frage ist pauschal nicht zu beantworten. Das hängt auch davon ab wie leistungsfähig dein Server ist.
Ganz allgemein würde ich mit etwas mehr Last rechnen, konnte bei mir aber keinen meßbaren Effekt (Sysmon) feststellen.
Dieses Feature ist als Option zu verstehen für die User denen es hilfreich ist. Einfach ausprobieren.
Falls die Belastung dadurch zu hoch werden sollte -> nicht nutzen.

Gibt es eine Möglichkeit den `mode` eines Consumers per Reading zu steuern?

Aktuell nicht, kann ich aber ähnlich dem Verfahren im Schlüssel "noshow=[Device:]Reading" implementieren.

[DS_Starter]

@The Grue, @all,

in meinem contrib liegt die V 1.39.2

Neben ein paar Code Änderungen/Verbesserungen und der Möglichkeit setupBatteryDev als asynchron kennzeichnen zu können, kann man den Consumer-Key 'mode' nun auch als Device:Reading Kombination angeben.
Die Hilfe gibt eine entsprechende Erläuterung.

Denkt bitte daran nach einer dynamischen Mode-Änderung auch eine Neuplanung des Consumers (zb. mit set ... consumerNewPlanning XX) vorzunehmen. Erst dann bekommt das interne Planungstool die Änderung des angegebenen Readings mit (Sonst erst bei der nächsten regulären Einplanung). Das kann man mit einem Notify auf die angegebene Device:Reading Kombination automatisieren.

Nach dem Download des Moduls Restart nicht vergessen!

LG,
Heiko