76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Ein

Code Auswählen Erweitern

set ... consumerNewPlanning <Verbrauchernummer>

sollte helfen.

Ich würde aber empfehlen, den Key so zu schreiben:

Code Auswählen Erweitern

swstate=state:.*on.*:.*off.*

Manchmal verstecken sich Leer- oder nicht sichtbare Steuerzeichen in dem Reading was den Match verhindern könnte. Kommt auf den Versuch an.

[DS_Starter]

@all,
ein weiterer Schritt ist vorgenommen.

Umgesetzt ist jetzt der Setter inverterStrings in Attr setupInverterStrings.
Der ganze Prozess läuft nach einem Restart! automatisch ab.

WICHTIG nach dem Restart mit "save config" die FHEM Konfiguration sichern da ein neues Attribut gesetzt und das alte Reading gelöscht wird.

Weiterhin habe ich die Berechnung von ctrlGenPVdeviation=continuously überarbeitet. Ich bin der Ansicht den laufenden Status der Abweichung nun genauer entsprechend der Realität zu bestimmen.

Wer mag kann die neue V gleich aus meinem contrib ziehen und restarten. Ansonsten morgen früh im Update.

LG,
Heiko

[tomcat.x]

Hallo Heiko,

die Hilfe bei der Pflege des neuen Attributs stimmt nicht. Es wird die zu setupInverterDev angezeigt. Ist mir nur zufällig aufgefallen, weil ich über die Syntax (Trennung mit Komma) gestolpert bin und daraufhin mal reingeschaut hatte.

Viel Grüße
Thomas

[DS_Starter]

Hallo Thomas,

danke für die Info.
Kann ich bei mir bestätigen, allerdings ist es im Code der Hilfe korrekt hinterlegt.
Das ist interessant. Möglicherweise ein Problem für Rudolf König (FHEMWEB Javascript Finding).
Ich denke ich melde es ihm mal.

Grüße,
Heiko

[DS_Starter]

@Thomas,

habe den Fehler gefunden und gefixt. Kannst die V nochmal laden und die Lösung verfizieren.

LG

[tomcat.x]

@Heiko: Ja, jetzt passt es.

[texel]

Ein

Code Auswählen Erweitern

set ... consumerNewPlanning <Verbrauchernummer>

sollte helfen.

Ich würde aber empfehlen, den Key so zu schreiben:

Code Auswählen Erweitern

swstate=state:.*on.*:.*off.*

Manchmal verstecken sich Leer- oder nicht sichtbare Steuerzeichen in dem Reading was den Match verhindern könnte. Kommt auf den Versuch an.

Das war es wohl nun funktioniert alles und wurde heute richtig eingeplant. Lieben Dank!!

[Reinschki]

Heute morgen war mein Server down.
Ich betreibe Fhem im Docker Container!

Hier die letzten Zeilen im Log:

Code Auswählen Erweitern

2024.06.08 00:02:02.031 1: SolarForecast - WARNING - Attribute ctrlBatSocManagement is active, but the required key 'cap' is not setup in setupBatteryDev. Exit.
Illegal division by zero at ./FHEM/76_SolarForecast.pm line 10627.
2024.06.08 00:02:05.075 1: HMCCURPCPROC [d_rpc178070VirtualDevices] RPC server CB9292178080178070 stopped handling connections. PID=38614 run=-1
2024.06.08 00:02:05.095 1: HMCCURPCPROC [d_rpc178070VirtualDevices] Parent process (FHEM,PID=38125) not running. Shutting down RPC server process CB9292178080178070.
2024.06.08 00:02:05.121 1: HMCCURPCPROC [d_rpc178070VirtualDevices] Deregistering RPC server http://192.168.178.80:14702/fh9292 with ID CB9292178080178070 at http://192.168.178.70:9292/groups
2024.06.08 00:02:05.252 1: HMCCURPCPROC [d_rpc178070VirtualDevices] FHEM will be restarted automatically if restart is enabled in system.d configuration.
2024.06.08 00:02:06.526 1: HMCCURPCPROC [d_rpc178070BidCos_RF] RPC server CB2001178080178070 stopped handling connections. PID=38613 run=-1
2024.06.08 00:02:06.532 1: HMCCURPCPROC [d_rpc178070BidCos_RF] Parent process (FHEM,PID=38125) not running. Shutting down RPC server process CB2001178080178070.
2024.06.08 00:02:06.539 1: HMCCURPCPROC [d_rpc178070BidCos_RF] Deregistering RPC server http://192.168.178.80:7411/fh2001 with ID CB2001178080178070 at http://192.168.178.70:2001
2024.06.08 00:02:06.565 1: HMCCURPCPROC [d_rpc178070BidCos_RF] FHEM will be restarted automatically if restart is enabled in system.d configuration.
2024.06.08 00:02:06.839 1: HMCCURPCPROC [d_rpc178070HmIP_RF] RPC server CB2010178080178070 stopped handling connections. PID=38612 run=-1
2024.06.08 00:02:06.842 1: HMCCURPCPROC [d_rpc178070HmIP_RF] Parent process (FHEM,PID=38125) not running. Shutting down RPC server process CB2010178080178070.
2024.06.08 00:02:06.855 1: HMCCURPCPROC [d_rpc178070HmIP_RF] Deregistering RPC server http://192.168.178.80:7420/fh2010 with ID CB2010178080178070 at http://192.168.178.70:2010
2024.06.08 00:02:06.889 1: HMCCURPCPROC [d_rpc178070HmIP_RF] FHEM will be restarted automatically if restart is enabled in system.d configuration.
Hier die bemängelte konfig von setupBatteryDev:

Code Auswählen Erweitern

attr SolarForecast setupBatteryDev hame_energy pin=Solar_1_input_power:W pout=Output_power_1:W charge=Battery_percentage cap=2240:Wh
Was habe ich falsch gemacht?

Grüße
Reiner

[DS_Starter]

Moin,

Was habe ich falsch gemacht?

Wenn man cap als numerischen Wert direkt angibt, dann nur so:

        cap=2240

ohne Einheit.

Den Grund des Absturzes ('Illegal division by zero') muß ich im Modul anfangen.

LG,
Heiko

[DS_Starter]

Der Fix ist eingecheckt und für Sofort-Nutzer auch aus meinm contrib downloadbar.

[tpm88]

Hallo Heiko,

wir hatten das Thema schon einmal weiter oben im Thread (während deiner kurzen Abwesenheit) - aber ich möchte es nochmal andiskutieren.

Für mich sieht es so aus, daß das Modul ( übrigens Weltklasse  ) zeimlich genau um Mitternacht für etwa 6 Minuten meine CPU komplett auslastet und dabei die FHEM Hauptschleife praktisch komplett blockiert ( Lichtschalter funktionieren nicht mehr, etc etc ). Problem ist, daß ich drei SolarForecast Instanzen parallel betreibe (alle DWD basiert) - somit summiert sich der "Blackout" auf ca 19 Minuten...

Hier ein Auszug aus dem FHEM Log:

Code Auswählen Erweitern

2024.06.07 23:59:24 1: [Shelly_status] Device s25Sw01 has Error 'not connected (no route)', state is set to 'Error: Network'
2024.06.07 23:59:30 1: Timeout for VCONTROL300_DoUpdate reached, terminated process 2824736
2024.06.07 23:59:30 2: VCONTROL300: TCP connection closed
2024.06.07 23:59:38 3: [Shelly_status] s25Sw01: Error in callback, update in 10 seconds
2024.06.07 23:59:38 1: [Shelly_status] Device s25Sw01 has Error 'not connected (no route)', state is set to 'Error: Network'
2024.06.07 23:59:51 3: [Shelly_status] s25Sw01: Error in callback, update in 10 seconds
2024.06.07 23:59:51 1: [Shelly_status] Device s25Sw01 has Error 'not connected (no route)', state is set to 'Error: Network'
2024.06.08 00:00:01 3: TelegramBot_Callback my_TelegramBot: Digest: Number of poll failures on 2024-06-07 is :7:
2024.06.08 00:06:27 1: [Freezemon] fm: Long function call detected ReadyFn:PV_OpenMeteo - 383.791431 seconds
2024.06.08 00:12:46 1: [Freezemon] fm: Long function call detected ReadyFn:PV_forecast - 378.749563 seconds
2024.06.08 00:19:01 1: [Freezemon] fm: Long function call detected ReadyFn:PV_OM_Ensemble - 374.404332 seconds
2024.06.08 00:19:01 1: [Freezemon] fm: possible freeze starting at 00:00:05, delay is 1136.043 possibly caused by: fn-ReadyFn(PV_OpenMeteo) fn-ReadyFn(PV_forecast) fn-ReadyFn(PV_OM_Ensemble)
2024.06.08 00:19:01 3: [Shelly_status] s25Sw01: Error in callback, update in 10 seconds
2024.06.08 00:19:01 1: [Shelly_status] Device s25Sw01 has Error 'Error: Timeout connecting', state is set to 'Error: Network'
2024.06.08 00:19:01 3: mqttGarage: mqttGarage_100.64.2.106_49588/mqttHome left us (keepalive check)
2024.06.08 00:19:01 3: my_MQTT2: my_MQTT2_192.168.8.153_23948/DVES_375AB5 left us (keepalive check)
2024.06.08 00:19:01 3: my_MQTT2: my_MQTT2_192.168.8.160_27315/shellyuni-98CDAC2527EE left us (keepalive check)
2024.06.08 00:19:02 3: HMinfo hm get:update :
2024.06.08 00:19:02 3: CUL_HM set ActionDetector update noArg
2024.06.08 00:19:02 3: CUL_HM set vccu update noArg
2024.06.08 00:19:06 1: [YAAHM_updater] on device myHA called for this day
2024.06.08 00:19:06 3: Login denied via mqttGarage
2024.06.08 00:19:06 4: Connection accepted from mqttGarage_100.64.2.106_45266
2024.06.08 00:19:06 3: [Shelly_status] s1Switch01: Error in callback, update in 60 seconds
2024.06.08 00:19:06 1: [Shelly_status] Device s1Switch01 has Error 'not connected (no route)', state is set to 'Error: Network'

Man sieht ganz gut anhand der sonst alle 10 Sekunden ins Log trudelnden Shelly_status Meldungen, dass für 19 Minuten ab Mitternacht gar nichts geht.

Der FHEM Server läuft PROXMOX virtualisiert auf einem recht potenten (auf CORE i8 Basis) NUC - zu 100% ausgelastet ist während des Problems nur eine der beiden vCPUs. Und natürlich zieht der FHEM perl Prozess diese Last.

Hast Du eine Idee, was da passiert oder wie ich es besser eingrenzen kann? Mir würde eigentlich schon eine Bestätigung genügen, daß andere das Problem nicht haben. DNS Hänger würde ich als Ursache eigentlich ausschliessen - das FHEM global Attribut dnsServer habe ich gepflegt.

Tobi

[kask]

@tpm88
Ich habe das problem so nicht.

@Reinschki
Um 02:02 kommt der division fehler. Das last fhem aber nicht neustarten.
Ist ja auch nur eine warnung. Wenn es das wirklich wäre dann wäre die meldung vermutlich auch nicht da. Da das ja den process ins trudelt bring und dann wäre ein log meist auch nicht möglich. Da kommst du nur mit Debugging weiter. Und da sehe ich eher das problem bei HMCCURPCPROC. Un 02:05 eiert fhem ja mit dem device rum.

[DS_Starter]

Hallo Tobi,

habe so ein Problem auch nicht. Bei mir laufen zweimal 5 SF Instanzen auf verschiedenen Servern parallel. (NUC mit VMWare)

Um Mitternacht werden mit einem Versatz von einigen Sekunden/Minuten Aufräumarbeiten wie Löschen von Readings, Löschen von Daten interner Strukturen etc. durchgeführt. Diese Dinge werden in 4 bzw. 5 verschiedenen Tasks unterteilt ausgeführt.
Du kannst kurz vor Mitternacht in deinen SF Devices verbose=4 setzen. Dann kommen Meldungen wie:

Code Auswählen Erweitern

<name> - Daily special tasks - Task 1 finished

Damit kann man eingrenzen in welchem Task es bei dir vorkommt. Ich kann dann schauen was in dem Task drinsteckt.
Lässt du Freezemon bei dir ständig mitlaufen?
Wenn ja, würde ich das abschalten und nur im speziellen Bedarfsfall zur Analyse verwenden um eventuelle Seiteneffekte auszuschließen.

[tpm88]

Natürlich trat gestern Nacht die beschriebene Blockade nicht auf.

Geändert hatte ich vorher:
- FHEM update & restart
- freezemon deaktiviert
- at für verbose 4 im Zeitraum um Mitternacht definiert

Die special Tasks sind aus meiner Sicht unkritisch:

Code Auswählen Erweitern

root@pvefhem01:/opt/fhem/log# grep -a "Daily special tasks" fhem-2024-06.log
2024.06.09 00:00:04 4: PV_forecast - Daily special tasks - Task 1 started
2024.06.09 00:00:14 4: PV_forecast - Daily special tasks - Task 1 finished
2024.06.09 00:00:14 4: PV_OM_Ensemble - Daily special tasks - Task 1 started
2024.06.09 00:00:24 4: PV_OM_Ensemble - Daily special tasks - Task 1 finished
2024.06.09 00:00:24 4: PV_OpenMeteo - Daily special tasks - Task 1 started
2024.06.09 00:00:34 4: PV_OpenMeteo - Daily special tasks - Task 1 finished
2024.06.09 00:02:05 4: PV_forecast - Daily special tasks - Task 2 started
2024.06.09 00:02:05 4: PV_forecast - Daily special tasks - Task 2 finished
2024.06.09 00:02:05 4: PV_OM_Ensemble - Daily special tasks - Task 2 started
2024.06.09 00:02:05 4: PV_OM_Ensemble - Daily special tasks - Task 2 finished
2024.06.09 00:02:05 4: PV_OpenMeteo - Daily special tasks - Task 2 started
2024.06.09 00:02:05 4: PV_OpenMeteo - Daily special tasks - Task 2 finished
2024.06.09 00:05:05 4: PV_forecast - Daily special tasks - Task 3 started
2024.06.09 00:05:05 4: PV_forecast - Daily special tasks - Task 3 finished
2024.06.09 00:05:05 4: PV_OM_Ensemble - Daily special tasks - Task 3 started
2024.06.09 00:05:05 4: PV_OM_Ensemble - Daily special tasks - Task 3 finished
2024.06.09 00:05:05 4: PV_OpenMeteo - Daily special tasks - Task 3 started
2024.06.09 00:05:05 4: PV_OpenMeteo - Daily special tasks - Task 3 finished
2024.06.09 00:09:06 4: PV_forecast - Daily special tasks - Task 4 started
2024.06.09 00:09:06 4: PV_forecast - Daily special tasks - Task 4 finished
2024.06.09 00:09:06 4: PV_OM_Ensemble - Daily special tasks - Task 4 started
2024.06.09 00:09:06 4: PV_OM_Ensemble - Daily special tasks - Task 4 finished
2024.06.09 00:09:06 4: PV_OpenMeteo - Daily special tasks - Task 4 started
2024.06.09 00:09:06 4: PV_OpenMeteo - Daily special tasks - Task 4 finished

Ich lass den at für verbose 4 trotzdem mal ein paar Tage aktiv...

Danke
Tobi

[DS_Starter]

Ja das sieht io aus.
Ich persönlich tippe ganz stark auf einen negativen Zusammenhang mit freezemon.
Ein direktes Auftreten nach Reaktivierung von freezemon wäre die Verifizierung dieser Einschätzung.

Grüße,
Heiko