Nach fhem Update lässt sich fhem nicht mehr im Browser aufrufen

[ToSchu]

Hallo,

nach dem Update der Module

59_Twilight.pm
98_HTTPMOD.pm

startet mein fhem immer selbstständig neu.

Twilight verwende ich gar nicht.

Aktuelle Version in fhem:
59_Twilight.pm                22777 2020-09-16 05:56:12Z Beta-User
98_HTTPMOD.pm             22840 2020-09-24 17:38:06Z StefanStrobel

Hat jemand eine Idee, wie ich feststellen kann warum diese Module fhem zum neu starten bringen, da ich im Logfile nichts dazu finden kann.

Gruß

[Beta-User]

Hmm: Zum einen gibt es von beiden Modulen neuere Updates, und zum Absturz können nur Module führen, die definiert und geladen werden.

Von daher würde ich vorschlagen, beide aus dem svn zu holen und die vorhandenen Dateien zu ersetzen. Übergangsweise könnte es auch reichen, beide schlicht umzubenennen, dann ein update durchzuführen und FHEM neu zu starten.

[ToSchu]

Hallo Beta-User,

ich habe mich wohl missverständlich ausgedrückt.

Diese Versionen funktionieren bei mir aktuell einwandfrei:

59_Twilight.pm                22777 2020-09-16 05:56:12Z Beta-User
98_HTTPMOD.pm             22840 2020-09-24 17:38:06Z StefanStrobel

Ich habe das Update der Module zur Zeit excluded.

Sobald ich die neuere Version verwende, also update funktioniert mein fhem nicht mehr.

Gruß

[Beta-User]

Hm, kann nur was zu Twilight sagen: Das habe ich nach der genannten Version ziemlich umgebaut, und dabei auch den größten Teil der für interne Zwecke gedachten Funktionen in ein package eingebettet. FALLS du also irgendein Modul nutzt, das meint, sich an diesen internen Funktionen "bedienen" zu müssen: Das wird nicht mehr so ohne weiteres gehen, und ich werde das auch ganz sicher nicht reanimieren.

Soweit ersichtlich, machen offizielle Module das nicht, aber in dem (leider geschlossenen Thread) https://forum.fhem.de/index.php/topic,115130.0.html _könnte_ das die Ursache für den Absturz wegen des Moduls 98_PS4.pm sein. Ein grep nach "myInternalTimer" im Modulverzeichnis könnte dazu mehr Infos liefern.

Aber irgendwas vor dem Restart sollte doch im log stehen...?

Ansonsten eben eines nach dem anderen updaten und schauen, was wirklich weiterbringt...

[betateilchen]

Hast Du mal probiert, die beiden von Dir verdächtigten Module einzeln zu aktualisieren?

Twilight verwende ich gar nicht.

Wenn Du Twilight nicht verwendest, wird es von FHEM nicht geladen und sollte somit nicht für FHEM Neustarts verantwortlich sein.

[ToSchu]

Hallo,

zumindest taucht Twilight bei einem list nicht auf.

Mein UpdateCheck Result schaut nun so aus und fhem funktioniert einwandfre mit den oben genannten alten Versionen der Module:

Downloading https://fhem.de/fhemupdate/controls_fhem.txt

fhem
List of new / modified files since last update:
UPD FHEM/46_TRX_SECURITY.pm (excluded from update)
UPD FHEM/59_Twilight.pm (excluded from update)
UPD FHEM/98_HTTPMOD.pm (excluded from update)
UPD www/images/default/favicon.ico (excluded from update)
Downloading https://raw.githubusercontent.com/ThorstenPferdekaemper/FHEM-FUIP/master/controls_fuip.txt

fuip
nothing to do...
Downloading https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

signalduino
nothing to do...

Gruß

[betateilchen]

Aber irgendwas vor dem Restart sollte doch im log stehen...?

Ansonsten eben eines nach dem anderen updaten und schauen, was wirklich weiterbringt...

Alternativ: FHEM manuell auf der Konsole starten und beobachten, was auf der Konsole passiert, oft taucht dort in solchen Problemfällen eine Fehlermeldung auf, mit der man weiterkommt.

[betateilchen]

Mein UpdateCheck Result schaut nun so aus und fhem funktioniert einwandfre mit den oben genannten alten Versionen der

und was wollen uns diese Worte nun sagen? Das wussten wir doch schon vorher.

[Beta-User]

Wenn Du Twilight nicht verwendest, wird es von FHEM nicht geladen und sollte somit nicht für FHEM Neustarts verantwortlich sein.

...alle Theorie ist grau...

Das "Problem" mit Twilight ist folgendes: Es gab einige Module, die das ohne Wissen des Users im Hintergrund geladen hatten, weil die Art und Weise, wie da InternalTimer aufgerufen wird m.E. eigentlich ganz nett ist. Diese Tür ist jetzt aber zu, was eben diese Art Ärger verursachen kann. Es sollte aber (indirekt) im Log stehen. Und wenn es geladen ist, müßte man das auch abckecken können, auf die Schnelle habe ich dazu aber nicht die Syntax parat.

Fyi: Was diese Sache mit der InternalTimer-Veraltung angeht, bin ich im Hintergrund grade in der Diskussion mit Sidey betr. die korrekte Verwendung bzw. ggf. Änderung von https://svn.fhem.de/trac/browser/trunk/fhem/lib/FHEM/Core/Timer/Helper.pm.

[Beta-User]

@ToSchu:
Alternativ kannst du die beiden (bzw. bis zu 4) Funktionen, um die es hier geht, einfach in eine myUtils-File packen:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/59_Twilight.pm?rev=22777#L137 bis L178 bzw. L186

[betateilchen]

...alle Theorie ist grau...

Das "Problem" mit Twilight ist folgendes: Es gab einige Module, die das ohne Wissen des Users im Hintergrund geladen hatten

Das hatte ich auch vermutet und deshalb hatte ich vor meiner theoretischen Aussage im kompletten aktuellen FHEM-Zweig gesucht, ob ich ein anderes Modul finde, das Twilight (über die vorgesehenen Mechanismen) nachlädt. Die Suche war allerdings erfolglos.

[ToSchu]

Hallo,

das Problem mit HTTPMOD ist nicht mehr vorhanden, keine Ahnung woran es lag.

Das Problem mit Twilight ist immer noch vorhanden.

Ich habe wie oben angefragt einmal mit grep die myInternalTimer abgefragt, dies ist die Ausgbe:

grep -r 'myInternalTimer' ./
./53_Silvercrest_SWS_A1_Wifi.pm:    myInternalTimer      ("ping",     gettimeofday() + $int, "Silvercrest_SWS_A1_Wifi_UpdateReadings", $hash, 0);
./59_Twilight.pm:sub myInternalTimer {
./59_Twilight.pm:      $myHash = myInternalTimer($ereignis, $hash->{TW}{$ereignis}{TIME}, "Twilight_fireEvent", $hash, 0);
./59_Twilight.pm:  return myInternalTimer ("Midnight", $midnight, "Twilight_Midnight", $hash, 0) if $mode eq "Mid";
./59_Twilight.pm:  return myInternalTimer   ("Midnight", $midnight, "Twilight_WeatherTimerUpdate", $hash, 0);
./59_Twilight.pm:  myInternalTimer             ("Midnight", $midnight, "Twilight_Midnight", $hash, 0);
./59_Twilight.pm:        myInternalTimer       ("weather", $tim-60*60, "Twilight_WeatherTimerUpdate", $hash, 0);
./59_Twilight.pm:  return myInternalTimer("sunpos", time()+$hash->{SUNPOS_OFFSET},  "Twilight_sunpos", $hash, 0);

Ich kann hier aber nur erkennen, dass Twilight von Twilight genutzt wird oder verstehe ich das falsch.

Gruß

[Beta-User]

...also doch ein Treffer bei einem inoffiziellen Modul...

Du solltest das "Silvercrest"-Ding überarbeiten (lassen) - z.B. da die betreffenden Routinen (die eine wird nicht reichen, es sind vermutlich drei oder vier) aus Twilight direkt reinkopieren (und dann einschl. der Aufrufe in was "besseres" umbenennen als my.*) oder eben - wie schon vorgeschlagen - in eine eigene myUtils packen. Sonst bleibt das auf immer abhängig von einer alten Twilight-Version (die auch geladen sein muss!)... Kann auch sein, dass das ein ESP8265 oder ESP8266-basiertes Gerät ist, das sich mit Tasmota flashen läßt - das wäre dann die einfachere Variante (@MQTT2_.*).

Innerhalb Twilight besteht das Problem in der Tat nicht, weil das - in sich konstistent - überarbeitet ist.

[Beta-User]

...was solls...

Anbei das entsprechend überarbeitete Modul auf Basis von dem, was SebiM hier gepostet hatte: https://forum.fhem.de/index.php/topic,38112.msg524963.html#msg524963

Darfst es gerne nach dem Testen (Modul reinkopieren, normales update machen, dann FHEM neu starten) dann auch in dem zugehörigen Thread posten...

[ToSchu]

Hallo Beta-User,

vielen Dank für die Bereitstellung der modifizierten Moduls!! Deine Modifikationen haben mein Problem gelöst! Ich habe das Modul ausgiebig getestet und in meinem System aktiv im Betrieb und kann keine negativen Auswirkungen feststellen!

Nochmals Danke!

Gruß

toschu