76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

DS_Starter · 03 Mai 2025, 15:42:54

Also was ich zunächst sehe ist, dass locktime korrekt berücksichtigt, aber falsch geloggt wird:

...
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 15 seconds
...
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28

Letzter Start war entgegen dem Log um 14:54:28, sieht man ganz am Anfang des Log. Bei 300 Sek locktime wäre 15:59:28 das Ende, was auch richtig gewertet wird. Aktuell ist es 14:59:13 und es wird 15 Sekunden Restlocktime ausgegeben -> das passt.
Die Logausgabe "last cycle start time: 2025-05-03 14:55:28" stimmt nicht, schaue ich mir an.

Etwas später:

2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2656 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 0
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - send switch command now: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off"

2025.05.03 14:59:43 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28

Ist völlig i.O., die locktime ist um und kein Überschuß mehr. Bei der Endzeit gibt es ein paar Sekunden Unterschied, schaue ich mir auch an. Kann es sein, dass die Änderungszeit der Statusreadings etwas von der Zeit im SF abweicht? Kann ich mir momentan nicht erklären, sieht aber so aus.

Das wars schon im Prinzip. Danach sieht man wieder wie die remainLockTime heruntergezählt wird:

Code Auswählen

2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 240 seconds
Ist auch ok.

DS_Starter · 03 Mai 2025, 16:03:44

Hallo 87insane,

in meinem contrib liegt die V 1.51.9 zum testen des Inverter im BKW.

Man kann nun strings=none im IntverterDev angeben. Dadurch werden die Eigenschaften des Inverters verändert.
Das setup-Attribut wäre etwa so anzugeben:

Code Auswählen

<Inverter-Device>  
pv=energie_aus_bat:W etotal=etotal_inv:kWh
capacity=1000
strings=none
icon=inverter@darkorange:inverter@grey

Im Icon bietet sich an die Sonne zu ersetzen, da der Inverter aus der Bat gespeist wird.

Die Flußgrafik ist erst halb fertig. Hier fehlt noch die Verknüpfung von Bat -> Inverter wie im Anhang dargestellt.
Es kommt erstmal auf die Logik an.

LG,
Heiko

Adimarantis · 03 Mai 2025, 16:36:29

Hallo Heiko,

Zitat von: DS_Starter am 03 Mai 2025, 10:18:43Ich denke es ist alles richtig konfiguriert. Wie sieht denn das Attr setupStringPeak aus?

Habe ich entsprechend der technischen Spezifikation der Strings definiert:

Code Auswählen

setupStringPeak:NW=5.84 SO=5.34Wie gesagt erreichen diese durch ihre Ausrichtung etc. eigentlich nie das technische Peak. Ich bin davon ausgegangen, dass dies mit Hilfe der Orientierung und Neigung berücksichtigt wird. Besonders beim SO-Dach gibt es allerdings Verluste durch die Optimierer und falsche Wechselrichterwahl (das hat der Solateur so richtig verbockt, hab ich jetzt zumindest halbwegs korrigiert). Da sind 4500 Peak wahrscheinlich das Maxiumum. Beim NW macht der Wechselrichter dann auch bei 5000 Schluss.

ZitatAuf dem Screenshot kann ich leider nichts erkennen, außer dass es zwei schöne gegenseitig versetzte Kurven mit jweils einem Maximum gibt. Den 14:00 Punkt sehe ich nicht.

Ja, die SVGs sind da leider u.U. schwer zu lesen/konfigurieren.
Der Schnittpunkt der beiden Kurven ist ziemlich genau gegen 14:00 bei einem Wert von ca. 3000 Watt, das jeweilige Maximum bei etwa 4000 Watt.
Der Algorithmus scheint aber zu glauben, dass im Mittelbereich der Überlappung beide Strings fast auf volle Leistung gehen - was bei 180 Grad entgegengesetzten Dächern aber doch generell unrealistisch sein sollte.

Gerade bemerkt das die KI Status "rot" hatte, weil Storage voll war - vielleicht hat das zusätzliche Probleme verursacht - zumindest wird er Probleme gehabt haben zu lernen.

Jörg

DS_Starter · 03 Mai 2025, 16:59:14

Hallo Jörg,

Strings sehen auch gut aus.

ZitatIch bin davon ausgegangen, dass dies mit Hilfe der Orientierung und Neigung berücksichtigt wird.

Ja natürlich sind die Ergebnisse der gewählten API (KI ohnehin) unter Berücksichtigung der Ausrichtung der Module und weiterer Parameter.
Nur das absolut rechnerische Maximum wird durch mich begrenzt, und das sind die Summen der Inverterleistungen bzw. max. möglichen Stringleistungen.
Das sind aber nur ein Hilfsmittel. Wenn die Ergebnisse der API, der evtl. Korrekturfaktoren und/oder KI ein Ergebnis nahe der Realität bringen, was ja unser Ziel ist, wird die künstliche Begrenzung nicht eingreifen müssen.

ZitatDer Algorithmus scheint aber zu glauben, dass im Mittelbereich der Überlappung beide Strings fast auf volle Leistung gehen

Kommt auf die gewählte API an. Beim DWD-Device rechnen wir im Modul jeden einzelnen String nach der Methode von pah und bilden die Summe. Bei anderen API's liefert die API für jeden einzelnen String die Prognosewerte, die sich dann summieren. Also den EINEN Algo gibt es so nicht. Die KI (wenn aktiviert) übersteuert ggf. je nach gewählter Option.

Du kannst uns ja mal die Readings pvCorrectionFactor_XX zeigen. Das ist i.A. recht aufschlußreich.

Grüße,
Heiko

300P · 03 Mai 2025, 17:42:35

Zitat von: DS_Starter am 03 Mai 2025, 15:42:54Also was ich zunächst sehe ist, dass locktime korrekt berücksichtigt, aber falsch geloggt wird:

...
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 15 seconds
...
2025.05.03 14:59:13 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28

Letzter Start war entgegen dem Log um 14:54:28, sieht man ganz am Anfang des Log. Bei 300 Sek locktime wäre 15:59:28 das Ende, was auch richtig gewertet wird. Aktuell ist es 14:59:13 und es wird 15 Sekunden Restlocktime ausgegeben -> das passt.
Die Logausgabe "last cycle start time: 2025-05-03 14:55:28" stimmt nicht, schaue ich mir an.

Etwas später:

2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2656 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 0
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - send switch command now: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off"

2025.05.03 14:59:43 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28

Ist völlig i.O., die locktime ist um und kein Überschuß mehr. Bei der Endzeit gibt es ein paar Sekunden Unterschied, schaue ich mir auch an. Kann es sein, dass die Änderungszeit der Statusreadings etwas von der Zeit im SF abweicht? Kann ich mir momentan nicht erklären, sieht aber so aus.

Das wars schon im Prinzip. Danach sieht man wieder wie die remainLockTime heruntergezählt wird:

Code Auswählen Erweitern
2025.05.03 15:00:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 240 seconds
Ist auch ok.

Schau einmal hier - ist doch eigentlich okay mit der End-Last-Cycle-Zeit:

2025.05.03 14:59:28 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 208.3
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2653 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - isInLocktime: 1
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: on
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:28 1: Forecast DEBUG> consumer "06" - last cycle end time: still running

2025.05.03 14:59:43 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 0
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 0 W
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - current planning state: continued
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2656 W, nompower: 2170, surplus: 0 W, planstate: continued:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - isInLocktime: 0
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - send switch command now: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off"
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - current planning state: interrupting
2025.05.03 14:59:43 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:43 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28

2025.05.03 14:59:49 1: Forecast DEBUG> ############### consumerSwitching consumer "06" ###############
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - ConsumptionRecommended calc method: average:10, value: 0
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - additional consumption after switching on (if currently 'off'): 2170 W
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - physical Switchstate before switching: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - logical Switchstate before switching: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - general switching parameters => auto mode: 1, Current household consumption: 2656 W, nompower: 2170, surplus: 0 W, planstate: interrupted:, starttime: 03.05.2025 10:47:30
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - isInLocktime: 1, remainLockTime: 294 seconds
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - current planning state: interrupted
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - cycleDayNum: 5
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-03 14:55:28
2025.05.03 14:59:49 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-03 14:59:28

Meinem Fehler mit dem "external switch" bleib und bin ich weiter auf der Spur - sobald ich was sehe melde ich mich wieder.

Danke für die Unterstützung und deine Zeit

Gruß
300P

300P · 03 Mai 2025, 18:09:55

Zitat von: Adimarantis am 03 Mai 2025, 09:40:53Hallo,

ich bekomme für meine Anlage einen etwas seltsamen Forecast beim Übergang vom Ostdach auf das Westdach.
Insbesondere der Forecast für 14:00 ist massiv zu hoch.
Das hier sollten die relevanten Teile der Config sein:
Code Auswählen Erweitern
setupStringAzimuth:NW=120 SO=-60 setupStringDeclination:NW=45 SO=45 setupInverterDev01:Sungrow pv=Total_DC_Power:W etotal=kWh:kWh capacity=5800 strings=NW setupInverterDev02:Fronius pv=Total_DC_Power:W capacity=5400 etotal=kWh:kWh strings=SOAnbei ein Tagesgraph eines durchweg sonnigen Tages, der den Effekt verdeutlicht. Ich muss dazu sagen, dass es speziell auf der SO Seite am Nachmittag Verschattungen gibt und alle Panels mit Optimierern laufen. Müsste ich das anders konfigurieren?
Allerdings habe ich schon Forecasts von 10KW für den 14:00 Timeslot gesehen - realistisch schaffen beide Anlagenteile aufgrund der Ausrichtung aber maximal so jeweils 4200W Peakleistung und der gemeinsame Peak geht kaum über 6KW hinaus.

Gruß,
Jörg

Hallo Jörg,

eine ähnliche Konfiguration gibt es bei mir - evtl. sogar noch komplexer.

Code Auswählen

attr Forecast setupBatteryDev01 SBS37 pin=-pout:kW pout=total_pac:kW pinmax=3680 poutmax=3680 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap:Wh show=3:top icon=@yellow:@green:@red:@white asynchron=0
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW pinmax=2500 poutmax=2500 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=bat_residual_cap:Wh show=3:top icon=@yellow:@green:@red:@blue asynchron=0
attr Forecast setupInverterDev01 SB25 pv=total_pac:kW etotal=etotal:kWh capacity=2500 strings=GarageSE limit=100 asynchron=0
attr Forecast setupInverterDev02 SB30 pv=total_pac:kW etotal=etotal:kWh capacity=3000 strings=GarageNW,HausNW limit=100 asynchron=0
attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=100 asynchron=0
attr Forecast setupInverterStrings GarageSE,GarageNW,HausNW,HausSW,HausSE1,HausSE2
attr Forecast setupMeterDev SMA_Energymeter gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh gfeedin=Einspeisung_Wirkleistung:W feedtotal=Einspeisung_Wirkleistung_Zaehler:kWh conprice=0.25:€ feedprice=0.08123:€
attr Forecast setupRadiationAPI OpenMeteoDWD-API
attr Forecast setupStringAzimuth GarageSE=-55 GarageNW=135 HausNW=135 HausSW=35 HausSE1=-55 HausSE2=-55
attr Forecast setupStringDeclination GarageSE=38 GarageNW=38 HausNW=48 HausSW=48 HausSE1=48 HausSE2=48
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.100 HausSE2=2.100
attr Forecast setupWeatherDev1 OpenMeteoDWD-API

Da werden die Leistungen der einzelnen String sogar schon vorab durch den WR schon gekappt.

Aber - die Gesamtleistung meiner PV hat augenscheinlich den Vorteil, dass sie durch die verteilten 3 Stringrichtungen schön langsam hoch und wieder runter geht.(rote Linie 1 SVG)
Man könnte sagen :"Das war so von Anfang an so gewollt"

Insgesamt lag die Prognose am Anfang 20-40 % daneben - mit der Zeit bin ich jetzt real so um die +/-10 % gegenüber den Berechnungen.

Gruß
300P

300P · 04 Mai 2025, 15:58:04

@DS_Starter

Heute gab es Erfolg bei der Suche mit meinem Heater "external switch"-Bug:
z.B.
ohne log

2025.05.04 13:49:17 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched off
2025.05.04 13:49:32 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched on

mit special-log

2025.05.04 14:43:29 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched off
2025.05.04 14:43:44 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched on

==>> siehe txt-Datei

Gruß
300P

DS_Starter · 04 Mai 2025, 19:23:55

@300P,

ich habe einen Ansatz.
Der Heater ist ja ein MQTT-Device. Im Log sieht man, dass dieses Device asynchron arbeitet (hätte mir auch ohne Log klar sein müssen

). Im Consumer Attribut ist aber synchron (asynchron=0) spezifiziert.
Das führt im Prinzip dazu, dass nach einem on/off Kommando das Ergebnis nicht registriert wird, weil der Event des Consumers ignoriert wird. Erst beim nächsten regulären Zyklus.
Schalte in dem Attr asynchron=1 bitte ein und im ctrlDebug zusätzlich notifyHandling ein damit man die Eventverarbeitung sieht bzw. was da abläuft oder nicht. Dann schauen wir nochmal.

LG,
Heiko

300P · 04 Mai 2025, 19:38:50

MQTT-Gerät ?

sorry -editiert

Code Auswählen

defmod FBDECT_fbahahttp_E8_DF_70_07_42_0B FBDECT fbahahttp:E8_DF_70_07_42_0B switch,powerMeter,switch
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B DbLogExclude .*
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B DbLogInclude power,energy
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B alias _WP_Heizstab_WW
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B event-min-interval power:300,energy:300
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B event-on-change-reading power,energy
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B event-on-update-reading power,energy
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B model Powerline546E
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B room FBDECT
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B userReadings solarforecast_auto
attr FBDECT_fbahahttp_E8_DF_70_07_42_0B verbose 2

300P · 04 Mai 2025, 19:48:45

Zitat von: DS_Starter am 04 Mai 2025, 19:23:55@300P,
Schalte in dem Attr asynchron=1 bitte ein und im ctrlDebug zusätzlich notifyHandling ein damit man die Eventverarbeitung sieht bzw. was da abläuft oder nicht. Dann schauen wir nochmal.

Hallo Heiko,

das ist jetzt eingeschaltet (auf 1 geändert) - Morgen schauen wir mal was passiert.
Danke

Gruß
300P

DS_Starter · 04 Mai 2025, 19:53:11

HTTP wollte ich schreiben ... man sollte nicht soviel parallel machen

Aber um was es mir geht, ist hier zu sehen:

2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - device 'FBDECT_fbahahttp_E8_DF_70_07_42_0B' is used as switching device
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - Interrupt Characteristic value: 1
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - send switch command now: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on"
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - current planning state: continuing
2025.05.04 14:03:36 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - physical Switchstate after switching: on
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - logical Switchstate after switching: off
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - cycleDayNum: 3
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - last cycle start time: 2025-05-04 13:49:47
2025.05.04 14:03:36 1: Forecast DEBUG> consumer "06" - last cycle end time: 2025-05-04 13:56:21

Die SF Routine wartet nicht auf das Schaltergebnis des Devices weil es non-blocking arbeitet, also asynchron.

Edit: Ich bin mir jetzt nicht mehr so sicher ob ich auf dem richtigen Weg bin. Ist, glaube ich, nicht mein Tag heute.

Aber sei es drum, ein Versuch ist es wert.
Schauen wir morgen nochmal drauf.

Bitschubser · 05 Mai 2025, 17:23:54

Kann man irgendwo angeben dass der Akku bitte bis z.b. 14:00 Uhr gefüllt sein soll?
Bisher ist es bei mir so, dass der Akku erst zum Abend gefüllt ist.
Wenn ich aber Nachmittags mit dem Auto nach Hause komme, dann wäre es schön, wenn der Hausakku bereits voll wäre, sodass der dann noch vorhandene Überschuss dann ins Auto wandern kann.

Gruß Jens

DS_Starter · 05 Mai 2025, 17:40:17

Hallo Jens,

bisher gibt es dieses Feature nicht, müsste ich einbauen bzw. mich damit beschäftigen eine solche Logik zu erstellen.

LG,
Heiko

Prof. Dr. Peter Henning · 05 Mai 2025, 18:01:45

Zitat von: Bitschubser am 05 Mai 2025, 17:23:54Kann man irgendwo angeben dass der Akku bitte bis z.b. 14:00 Uhr gefüllt sein soll?

Klar. Wenn es uns gelingt, die Wettersteuerung in FHEM zu integrieren. Dann kann man wählen, wann wieviel Sonne scheint.

LG

pah

300P · 05 Mai 2025, 18:24:26

Zitat von: DS_Starter am 04 Mai 2025, 19:53:11.....
Ich bin mir jetzt nicht mehr so sicher ob ich auf dem richtigen Weg bin. Ist, glaube ich, nicht mein Tag heute. Aber sei es drum, ein Versuch ist es wert.
Schauen wir morgen nochmal drauf.

Hallo Heiko,

neuer Versuch (wenn du das mit dem Wetter im Griff hast

)
=>> ctrlDebug bzw. zusätzlich notifyHandling
Anbei die Log-Datei (gezippt wegen der Größe - aber mit mehrfachen on/off des "Heater").

Gruß
300P