76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

dyna

Hallo Heiko,

ich habe das gleiche Problem wie Stefan. Es sieht so aus als wenn Perl ab dem Tageswechsel auf 100% hing.

Grüße
Jens

erwin

Hi Heiko,
ich kann Stefan's Beobachtungen bestätigen...
von vorgestern auf gestern: perl process auf 100% genau um Mitternacht .. ich dachte an Zufall ...
von gestern auf heute: perl process auf 100% genau um Mitternacht
kill - Neustart bringt nix, sofort wieder auf 100%
kill - löschen Solarforcast - start ok - neu-def (mit gleichen Namen/Param) - 100% cpu
kill - löschen Solarforcast - start ok - neu-def mit andern dev-namen, gleichen param - ok bis zur nächste Mitternacht.
defs : solarfc -> ICON, wetter -> icon
Bild info:
-FCtime 2024-03-25 23:51:04
-OpenMeteo: 2024-03-25 23:51:04
-last update: 2024-03-26 00:01:52
... werde weiter beobachten
l.g. erwinDu darfst diesen Dateianhang nicht ansehen.

PS: jetzt noch einen Versuch:
-kill - selbe Konfig ABER: ctrlWeatherDev1 auf myDWD_OpenData geändert... fhem kommt hoch ohne Problem..
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

kask

Habe das selbe Problem.

Der Perl prozess scheint zu hängen.
Keinerlei Probleme in den system logs zu sehen.

Ein "service fhem stop" & "service fhem start" bringt fhem wieder hoch.

Habe OpenMeteoDWD-Api als ctrlWeatherDev1.



kask

Da fällt mir ein Wir hatten das auch schon einmal mit dem dwd forcast und den ersten schritten mit der KI in dem Modul.
Da war auch um 0 Uhr schluß mit lustig. Da hat fhem 1h lang immer neugestartet (wenigstens, jetzt sieht man nix mehr).
War wohl damals ein Problem mit der Uhrzeit (Deutschland +1h).
Weiß das nicht, mehr genau wie das war.

DS_Starter

Moin,

kann eure Meldungen bestätigen. Wegen der Meldung mal in meine CPU-Loggings geschaut.
Kurz nach 00:00 100% , endet ab ca. 01:00.
Das ist jetzt eine unschön auch in Bezug auf die Fehlersuche. Im Log wird man nichts sehen weil ja nichts mehr geloggt werden kann.

Ich melde mich wieder.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

300P

Hallo Heiko,

wie wär's mit einem ,,optimierten" Link auf den letzten neuen Eintrag im Anzeigekopf ?

Dann würde es auch bei denjenigen besser treffen die ans Ende der Einträge müssen bzw. Einträge anders sortiert anzeigen lassen.

Oder spricht da was gegen...?

https://forum.fhem.de/index.php?topic=137058.new#new

FHEM 6.3 - Raspberry Pi 3 / Pi 4 - VControl300 mit VITOVALOR 300P - SMAEM - SMAInverter - DbLog/DbRep - MariaDB/QNAP - div. HTTPMOD - div. Modbus ser+TCP - SolarForecast - Tibber + Ladung mit SMA-SBS25

DS_Starter

Kommt mit in die nächste Version. Danke 300P.
Begebe mich jetzt erstmal auf Problemsuche ...
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

kask

Ehrlich gesagt weiß ich nicht ob das so schlau ist.

Ich habe das wie folgt begründet warum du auf den Thread linkst:
-Du hast ein neuen Thread erstellt wo es nur um das Modul selbst geht. Damit steuerst du die Leute vereinfacht in den Thread.
-Du erleichterst dem neuen Modul-User die Kontaktaufnahme, da er dann direkt weiß wo er was schreiben muß.
Und keinen neuen Thread aufmacht den du erstmal finden mußt zum supporten.

Warum ich das mit dem 'new' nicht gut finde ist, das der neue User dann irgend wohin geleitet wird wo erst einmal (vermutlich) kein Zusammenhang zu seinem aktuellen Problem erkennt.
Außerdem weiß der alte User das man oben mal eben auf z.B. Seite 18 klicken kann.
Der neue User sieht dann im ersten Post des Threads direkt das er da richtig ist mit Problemen um das Modul.

So mein Gedankengang. Ich würde mir das also überlegen das wirklich auf den neusten Post zu linken. Weil das ist auch nur interresant wenn man wirklich aktiv am geschen teilgenommen hat. Ansonsten heißt es eh wieder zurück blättern um den Anschluß zu finden.

Also ich würde mir das noch einmal überlegen. Bestandsuser beglücken oder Newbies den Einstieg erleichtern!
Ich bin da eher beim Welpenschutz und würde das lassen wie es ist.

Aber das obliegt alles dem Ersteller des Modules.
Also Heiko, mach was'se willst und für dich am besten/schlüssigsten ist ;)




DS_Starter

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

kask

Als Lösungsansatz.
Du könntest ein attr einpflegen.
Sowas wie "opennewestforumpost" der aktiv angelegt werden muß. wenn das attr nicht da (standard) dann 0 ansonsten 1|0.
Bei 1 addest du halt die paar zeichen (.new#new) an den link.
Somit linkst du erstmal auf den Topic und für die Bestandkunden ist das dann auswählbar wo es hin geht.
Frist ja kein Brot die 4 Zeilen quelltext mehr.

DS_Starter

Überlege ich mir noch. Die Lösung des CPU Problems hat erstmal Prio.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

kask

Zitat von: DS_Starter am 26 März 2024, 18:25:50..
Begebe mich jetzt erstmal auf Problemsuche ...

Ich habe das noch einmal bei mir analysiert was heute morgen passiert ist.
Ab 00:06 geht meine CPU hoch und sinkt wieder ca. 00:29. Also ca. 25min. Fhem selbst hing aber heute morgen noch, bzw. reagierte nicht mehr. Keine DB_Logs ab 01:00.
der letzte DBlog eintrag meiner devices die Signalduino nutzen waren 2024-03-25 23:59:57. Das hätte spätestens nach 15min ein neuer Eintrag auftauchen müssen.
Bis 2024-03-26 00:08:05 liefert der fhem interen mqtt-broker noch Daten (Da rasselt es nur so an logs normalerweise). Deconz lieferte das letzte mal Einräge im DBlog um 2024-03-26 01:00:39.
Also stirbt so nach und nach alles weg.

Edit: um 06:15 kommen wieder deconz Einträge. Also da lebte doch noch was, oder wieder was.
Habe um 06:55 fhem restartet.




DS_Starter

#267
Ich vermute einen Sperrzustand oder eine Schleife, wobei ich momentan einen Sperrzustand beim gleichzeitigen File-Write favorisiere. Wird sich heute zeigen.
Ich habe bei mir auf OS-Ebene einen Überwachungsmechanismus eingebaut. Er überprüft ob FHEM noch reagiert und ansonsten nach X Minuten FHEM automatisch restartet.
Wenn ich nicht das Log sichte, merke ich morgens nichts davon dass zwischen 0-1 dieser Zustand eingetreten ist (wenn ich nicht gerade solange auf bleibe).

Was ich schon weiß, der AI Learning Vorgang ist es nicht. Er läuft auch in der Stunde ab Mitternacht.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

kask

Waaaas? Keine mail, push oder sonstwas Nachricht das dein System macht was es will bzw. nicht macht was es soll?
Das ist doch Blasphemie.
So ein reset wüßte ich schon gerne wenn das einfach so passiert.
Gerade automatisiert wie bei Dir mit einer Überwachungsfunktion und nicht erst nach dem durchforsten von Logs.
Das kost doch Zeit. Gucken, ahhh war nix, ok!. Das 3 Tage lang und dann wird nur noch spradisch geschaut und irgend wann garnicht mehr. Und nach 3 wochen stellt man fest das das System jeden nacht x mal restartet. Ab da guckt man dann wieder täglich, dann sporadisch.
Da kannst du ja froh sein das du hier die User hast die das für dich überwachen und melden ;)

DS_Starter

#269
 :)
Wenn es "normal" restartet bekomme ich eine Nachricht über meinen Synology Chat. Aber dafür muss FHEM zumindest in der Lage sein nach dem Restart eine Message abzusetzen, was im vorliegenden Fall offensichtlich nicht der Fall war.
Ansonsten passt das schon.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter