76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

Zur Analyse wäre es gut, wenn Du nur SF mal disablen würdest und Info gibst, ob das Problem dann immer noch auftaucht. Auch wäre es toll, wenn Du mal den Linux-Kernel veranlassen würdest, etwas an Logging-Information auf einem nicht-flüchtigen Datenträger abzulegen. Eine Sichtung dieser Information offenbart nicht selten wertvolle Details über die man sonst nur spekulieren kann. 

Linux-Kernel Logging-Information erstellen.

Wie soll ich das am besten machen? Es gibt lokal eine SSD wie bei allen Pis bei mir.

Beginne erst einmal mit dem ersten Teil, dem Deaktivieren nur von SF. Dies erreichst Du dadurch, dass Du für SF das Attribut "disable" auf "1" setzt:

Code Auswählen Erweitern

attr <device> disable 1Danach solltest Du die neue Konfiguration für das Device speichern, insb. dann, wenn Du irgendwann danach FHEM noch einmal neu startest.

Sollte Dein Problem dann immer noch auftreten, dann ist es keines, welches durch SF verursacht wird.


PS: Gerne kannst Du schon einmal vorab probieren, ob Dein System vielleicht schon so eingerichtet ist, dass Logging-Daten auf einem nicht-flüchtigen Datenträger gespeichert werden. Hierzu kannst Du

Code Auswählen Erweitern

journalctlvon der Konsole aus aufrufen. Siehst Du dann auf der linken Seite in der (wahrscheinlich länglichen) Ausgabe ein Datum, welches vor dem letzten Neustart Deines Systems liegt, dann ist Dein System wie o.g. eingerichtet. Die Ausgabe von journalctl erfolgt übrigens seitenweise. Auf die jeweils nächste Seite kommst Du in der Regel durch Drücken der Taste f (forward) und auf die jeweils vorherige durch Drücken der Taste b (backward). Abbrechen kannst Du die seitenweise Ausgabe und damit auch das Programm journalctl in der Regel durch Drücken der Taste q (quit).

[Burny4600]

journalctl kenne ich und ist bei mir ohnehin im Hintergrund aktiv.

Zum Überblick habe ich den journalctl-Inhalt gelöscht. Vielleicht finde ich dieses Mal etwas aus dem journalctl.

[Parallix]

journalctl kenne ich und ist bei mir ohnehin im Hintergrund aktiv.

Zum Überblick habe ich den journalctl-Inhalt gelöscht. Vielleicht finde ich dieses Mal etwas aus dem journalctl.

Viel Erfolg dabei. Aber bitte zuerst SF mal disablen und damt prüfen, ob das Problem wirklich damit in Verbindung steht!

PS: Im Hintergrund arbeitet systemd-journald und nicht journalctl.

[kask]

Hallo,
ich mußte heute rebooten.
Danach kam FHEM nicht mehr hoch.
Die Logs sagen folgendes:

Code Auswählen Erweitern

Not an ARRAY reference at ./FHEM/76_SolarForecast.pm line 4217.
Ich habe dann kutze15 in der cfg mein victronSF device disabled. Dann lief wenigstens FHEM wieder.

Was ist da jetzt zermarmelt? bzw. woran könnte es liegen.

Edit.: sobald ich es wieder einschalte kachelt FHEM wieder ab. SF Version ist die aktuelle.

[Wolle02]

Einen solchen Fehler in Zusammenhang mit Virctron gab es hier schon mal. Vielleicht gleiche Ursache auf Virctronseite?

[DS_Starter]

Hallo kask,

die API Response von Victron enthält keine Daten. Normalerweise wird ein Array mit den Ergebnissen geliefert. Mein Victron Device läuft einwandfrei, liegt also nicht an Victron allgemein.
Ich werde den Fehler abfangen. Allerdings ist aktuell unklar warum Victron bei dir eine "leere" Antwort schickt.
Wenn ich den Array-Fehler abfange baue ich noch eine Logausgabe ein, damit man das Problem analysieren kann.

@Wolle02, sieht ganz danach aus, ja. Vermutlich nur eine andrere Stelle.

LG,
Heiko

[Wolle02]

Hallo Heiko, ich hätte auch mal eine Bitte bzw. Vorschlag. Ich weiß natürlich nicht welche Gedanken hier genau zu Grunde liegen und es ist auch eher nur kosmetischer Natur, aber wäre es eventuell möglich bei der Anzeige der Abweichung von der Prognose das Vorzeichen rumzudrehen? Bei einer Überproduktion wird immer Minus angezeigt und bei Unterproduktion ein Plus. Das verwirrt mich irgendwie immer.   

[DS_Starter]

... aber wäre es eventuell möglich bei der Anzeige der Abweichung von der Prognose das Vorzeichen rumzudrehen?

Möglich ist das natürlich. Es ist einfach eine Frage der Perspektive. In der aktuellen Ausprägung ist die Vorhersage "führend". Ist die Vorhersage kleiner als die Realität, ist die Abweichung negativ ->

 Abweichung = Vorhersage - Real

sonst positiv wenn Vorhersage zu optmistisch. Alles wird natürlich noch in Prozente umgerechnet. Ich denke wir hatten das Thema schon öfter. Vllt. macht es Sinn, in der Anlageneinstellung einen Param vorzusehen damit jeder die Perpektive einnehmen kann die ihm am logischten erscheint.

LG,
Heiko

[Wolle02]

Danke für die Erklärung wie das Vorzeichen zustande kommt. Ich dachte mir schon, dass das bestimmt nachvollziehbar ist. Trotzdem finde ich es verwirrend. Deshalb fände ich es toll wenn du das wählbar machen könntest. 

[kask]

OK,
das Problem wohnt bei mir! Und zwar musste ich vor einiger Zeit mein GX device neu ausetzten. Raspberry! Ist nach ca. 2 Jahren die SD Karte kaputt gegangen!
Jetzt bin ich auf das VRM Portal gegangen und da wurde mir gezeigt das mein Token nicht mehr ok ist. Musste ich neu erstellen.

Das SF schmiert zwar momentan immer noch ab wenn ich es versuche. Aber ich denke es geht später wieder.

Ein Abfangen wäre aber denoch ratsam!

[DS_Starter]

In meinem contrib liegt die V1.57.3.
Der Fehler wird abgefangen. Man sieht das Problem im API-State rechts oben in der Grafik.
ctrlDebug=apiCall liefert weitere Infos soweit möglich.

Kannst du ja mal ausprobieren.

[DS_Starter]

Ich habe noch ein Update im contrib nachgeschoben.
Das global Attr dnsServer wird in allen SF Models generell im configCheck berücksichtigt.

LG

[hugomckinley]

Bei mir spukt es. Ich glaube seit dem dem Update auf 76_SolarForecast.pm:v1.57.2-s30197/2025-08-15

Ich habe einen Consumer, bei dem definitiv alle Bedingungen für die swoffcond erfüllt sind.
Herauskommen tut das hier:

Code Auswählen Erweitern

2025.08.24 19:01:59 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "01" ###############
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - ConsumptionRecommended calc method: median:13, surplus: 0
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - method base: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - additional consumption after switching on (if currently 'off'): 0 W
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - current planning state: started
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - physical Switchstate before switching: on
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - logical Switchstate before switching: on
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - general switching parameters => auto mode: 1, Current household consumption: 1062 W, nompower: 250, surplus: 0 W, planstate: switched on: 2025-08-24 07:15:58 - 2025-08-24 22:59:58, starttime: 24.08.2025 07:15:58
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - isInLocktime: 0
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - Check Context 'switch on' => swoncond: 1, on-command: pump_low on
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - isAddSwitchOnCond Info: The return value "1" resulted in 'true' after exec "{main::Check_Pump_Low_On}"
-> Check successful
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - isAddSwitchOffCond Info: The return value "0" resulted in 'false' after exec "{main::Check_Pump_Low_Off}"
(the effect depends on the switch context)
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - device 'dum_valve' is used as switching device
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - Interrupt Characteristic value: 0 -> simple false
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - Check Context 'switch off' => swoffcond: 0, off-command: pump_low off
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - is Consumption recommended: 0
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - isAddSwitchOffCond Info: The return value "0" resulted in 'false' after exec "{main::Check_Pump_Low_Off}"
(the effect depends on the switch context)
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - current planning state: started
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - physical Switchstate after switching: on
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - logical Switchstate after switching: on
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - cycleDayNum: 1
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - last cycle start time: 2025-08-24 07:16:58
2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - last cycle end time: still running
Jetzt kommt das Merkwürdige:
Ich habe in die sub für swoffcond debug code eingefügt (unter edit files) und auf Speichern gedrückt.
Es wurde sonst überhaupt nichts geändert.
Der Vollständigkeit halber hier der Code:

Code Auswählen Erweitern

sub
Check_Pump_Low_Off{
my $ph = ReadingsVal($pool_dummy,"pump_high","on");
my $pha = ReadingsAge($pool_dummy,"pump_high",0);
my $sf = ReadingsVal($pool_dummy,"special_function","on");
my $vp = ReadingsVal($pool_dummy,"valve_position","");
Log3 ("Chief", 1, qq{Chief - $ph, $pha, $sf, $vp});
if(($amount > $desired_amount_l1)
&& (ReadingsVal($pool_dummy,"pump_high","on") eq "off"  && ReadingsAge($pool_dummy,"pump_high",0) >160)
&& ReadingsVal($pool_dummy,"special_function","") eq "none"
&& ReadingsVal($pool_dummy,"valve_position","") eq "normal"
)
{
Log3 ("SolarForecast", 1, qq{SolarForecats: Pump Low swoffcond - true});
return 1;
}else{
Log3 ("SolarForecast", 1, qq{SolarForecats: Pump Low swoffcond - false});
return 0;
}
}

Nach dem Speichern wird beim nächsten Zyklus sofort ausgeschaltet:

Code Auswählen Erweitern

2025.08.24 19:02:59 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "01" ###############
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - ConsumptionRecommended calc method: median:13, surplus: 0
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - method base: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - additional consumption after switching on (if currently 'off'): 0 W
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - current planning state: started
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - physical Switchstate before switching: on
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - logical Switchstate before switching: on
2025.08.24 19:02:59 1: Chief - off, 6960, none, normal
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - general switching parameters => auto mode: 1, Current household consumption: 1026 W, nompower: 250, surplus: 0 W, planstate: switched on: 2025-08-24 07:15:58 - 2025-08-24 22:59:58, starttime: 24.08.2025 07:15:58
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - isInLocktime: 0
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - Check Context 'switch on' => swoncond: 1, on-command: pump_low on
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - isAddSwitchOnCond Info: The return value "1" resulted in 'true' after exec "{main::Check_Pump_Low_On}"
-> Check successful
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - isAddSwitchOffCond Info: The return value "1" resulted in 'true' after exec "{main::Check_Pump_Low_Off}"
-> Check successful (the effect depends on the switch context)
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - device 'dum_valve' is used as switching device
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - Interrupt Characteristic value: 0 -> simple false
2025.08.24 19:02:59 1: Chief - off, 6960, none, normal
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - Check Context 'switch off' => swoffcond: 1, off-command: pump_low off
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - is Consumption recommended: 0
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - isAddSwitchOffCond Info: The return value "1" resulted in 'true' after exec "{main::Check_Pump_Low_Off}"
-> Check successful (the effect depends on the switch context)
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - send switch command now: "set dum_valve pump_low off"
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - current planning state: stopping
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - physical Switchstate after switching: off
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - logical Switchstate after switching: off
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - cycleDayNum: 1
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - last cycle start time: 2025-08-24 07:16:58
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - last cycle end time: 2025-08-24 19:01:59
Ich kann mir das überhaupt nicht erklären!?
Hat bisher funktioniert und jetzt plötzlich nicht mehr.
Was mir hier auch aufgefallen ist, dass hier swoncond und swoffcond jeweils 1 sind. Hat swoffcond eine höhere Priorität? Hat bisher so funktioniert. Ändere ich auf jeden Fall noch, dass nicht beides 1 ist.
Bei mir wird die sub für swoffcond auch zweimal ausgeführt in jedem Zyklus:

Code Auswählen Erweitern

2025.08.24 19:22:59 1: Chief - off, 8160, none, normal
2025.08.24 19:22:59 1: SolarForecats: Pump Low swoffcond - true
2025.08.24 19:22:59 1: Chief - off, 8160, none, normal
2025.08.24 19:22:59 1: SolarForecats: Pump Low swoffcond - trueIst das gewollt?

Ich hatte auch merkwürdiges Verhalten bei der swoncond und mit den Planungszeiten (mintime=SunPath und es wurde erst irgendwann für den Vormittag eingeplant). Aber dazu habe ich keine logs.Diese Probleme sind durch debugging, händisch ein- und ausschalten usw. grundlos wieder verschwunden. Aber wie gesagt ohne "Belege", was da falsch war.
Das einzige was mir dazu einfällt ist, dass FHEM (Stunden zuvor) neu gestartet wurde, bevor diese Probleme jeweils aufgetreten sind.

Grüße,
Hugo

[DS_Starter]

Hallo Hugo,

Ich habe einen Consumer, bei dem definitiv alle Bedingungen für die swoffcond erfüllt sind.

Naja, zumindest bringt deine Sub zu diesem Zeitpunkt ein "false" zurück. ->

Code Auswählen Erweitern

2025.08.24 19:01:59 1: energy_mgmt DEBUG> consumer "01" - isAddSwitchOffCond Info: The return value "0" resulted in 'false' after exec "{main::Check_Pump_Low_Off}"
(the effect depends on the switch context)
Weshalb kann nicht sagen, dazu kenne ich deine Verknüpfungen zuwenig. Aufgefallen ist mir nur, dass in deiner Sub die Variablen $amount ($amount > $desired_amount_l1) nicht zu finden sind. Zumindest sehe ich nicht wo sie definiert werden.


Eine Minute später ist die Bedingung erfüllt und dein Verbraucher wird mit dem Off-Kommando geschaltet:


2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - Check Context 'switch on' => swoncond: 1, on-command: pump_low on
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - isAddSwitchOnCond Info: The return value "1" resulted in 'true' after exec "{main::Check_Pump_Low_On}"
-> Check successful
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - isAddSwitchOffCond Info: The return value "1" resulted in 'true' after exec "{main::Check_Pump_Low_Off}"
-> Check successful (the effect depends on the switch context)
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - device 'dum_valve' is used as switching device
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - Interrupt Characteristic value: 0 -> simple false
2025.08.24 19:02:59 1: Chief - off, 6960, none, normal
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - Check Context 'switch off' => swoffcond: 1, off-command: pump_low off
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - is Consumption recommended: 0
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - isAddSwitchOffCond Info: The return value "1" resulted in 'true' after exec "{main::Check_Pump_Low_Off}"
-> Check successful (the effect depends on the switch context)
2025.08.24 19:02:59 1: energy_mgmt DEBUG> consumer "01" - send switch command now: "set dum_valve pump_low off"

Was mir hier auch aufgefallen ist, dass hier swoncond und swoffcond jeweils 1 sind. Hat swoffcond eine höhere Priorität?

Das ist ein anderer Kontext. Wenn dein Consumer noch nicht gestartet ist (planned->started), ist die swoncond relevant um als UND-Bedingung der Start freizugeben. Ist der Consumer gestartet, ist diese Bedingung nicht mehr relevant.
Die swoffcond ist der Gegenpart zum Beenden des Planungszyklus als ODER-Bedingung, entweder ist die Zeit um oder swoffcond zieht und beendet den Zyklus.

Bei mir wird die sub für swoffcond auch zweimal ausgeführt in jedem Zyklus:

Bei mir nicht.

Code Auswählen Erweitern

2025.08.24 20:31:14.998 1: SolCast - userFn SoCMgmnt -> Start batSocChargeMgmnt
2025.08.24 20:31:40.106 1: SolCast - userFn SoCMgmnt -> Start batSocChargeMgmnt
2025.08.24 20:31:43.973 1: SolCast - userFn SoCMgmnt -> Start batSocChargeMgmnt
2025.08.24 20:32:12.993 1: SolCast - userFn SoCMgmnt -> Start batSocChargeMgmnt

Der Aufruf des userExits ist nur einmal! im SF Code verankert. Möglicherweise rufst du deine Sub nochmal von außerhalb (notify, DOIF o.ä.) auf?

LG,
Heiko

[DS_Starter]

@all,

noch ein Update ist ins contrib gekommen.
planControl->genPVdeviation ist erweitert um den Perspektivwechsel für die Darstellung der Abweichung zu ermöglichen:

genPVdeviation    Legt die Methode zur Berechnung der Abweichung von prognostizierter und realer PV Erzeugung fest.
   Das Reading Today_PVdeviation wird in Abhängigkeit dieser Einstellung erstellt.
   Der optionale Zusatz ':reverse' legt fest, dass PV-Erzeugung > Prognose als positiver statt negariver Wert dargestellt wird (Perspektivwechsel)
   daily[:reverse] - Berechnung und Erstellung von Today_PVdeviation erfolgt nach Sonnenuntergang (default)
   continuously[:reverse] - Berechnung und Erstellung von Today_PVdeviation erfolgt fortlaufend
   
Technisch bedingt wird beim Setzen von genPVdeviation der Wert für heut und gestern zunächst gelöscht und muß sich erst wieder aufbauen.

LG,
Heiko