Fhem startet nicht - top zeigt Fhem bei fast 100%

Begonnen von erdnar, 17 Juli 2022, 12:05:44

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: erdnar am 17 Juli 2022, 15:54:51
Ich habe gerade kühn und entschlussfreudig das Twilight neu definiert, aber das Modul nicht erneuert ...
Wenn du damit sagen willst, dass irgendeine ältere Version keine Probleme macht: Es ist nicht Twilight selbst, das das Problem verursacht, sondern irgendein anderer Code meint, sich Code ausborgen zu können, und das geht mit den neueren Versionen schief...

Dann müßte aber auch was mit "undefined subroutine xy" im log zu finden sein, oder (falls es ein "Modul" ist), dieses "Modul" kann nicht geladen werden, was dann in der fhem-Startmeldung auch vermerkt sein sollte (oder eben in $motd).

setuuid hat jedenfalls mit Koordinaten nichts zu tun.

Zitat
Naja, Fhem läuft  8)
Falls es mit einer neueren Version von Twilight jetzt klappt: Manche "Module", die sich code borgen gehen davon aus, dass Twilight zuerst geladen wird...
"Module" deswegen, weil das, was mir dazu bisher über den Weg gelaufen ist meistens schlecht gepflegter Code aus dem Forum oder anderswo her war für exotische Hardware...
Solltest du fixen, genauso wie das "Dauerwarning" run um expandJSON. (Ich würde das betreffende Zeug gleich nach MQTT2_DEVICE umziehen, das spart bestimmt einige von deinen vielen cfg-Zeilen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

erdnar

naja, ich habe ja das Twilight-Modul NICHT neu geladen sondern nur testweise neu "define Twili..." eingegeben. Es steht jetzt in der fhem.cfg am Ende.

Ich habe gerade festgestellt, dass in einem Dummy keine Readings mehr zu finden sind.
Die hatte ich mal als "Konstanten" hinterlegt.
Wo werden die gespeichert?

Beta-User

#17
Das klingt nicht nach einer nachhaltigen Lösung. Wie gesagt: afaik ist Twilight an sich sauber, aber vermutlich spukt da noch irgendwas rum, das dir irgendwann wieder auf die Füße fällt...

Die Vorgaben aus dem dummy waren in der statefile gespeichert (wie Readings im allgemeinen), und sind vermutlich im Zuge ständiger ungeplanter Neutstarts verloren gegangen. Was genau jeweils passiert ist, wäre immer noch interessant, es sollten eigentlich irgendwo vor "started with xy entities" Hinweise zu finden sein, warum FHEM gehangen hat.
Alternativ könnte auch im Linux-Log was zu finden sein, wenn systemd der Ansicht gewesen sein sollte, dass FHEM tot ist und es deswegen neu gestartet hat.

Ansonsten solltest du dich wirklich auf die Reise machen und die vielen Log-Einträge mal untersuchen und abstellen, wo es geht.

Nachbrenner: Manches, was du schreibst klingt nach direktem FHEM-geeditiere. Das ist gelegentlich auch für "überraschende" Effekte gut => lassen! Alles über FHEMWEB  (über das grüne Plus oder RAW-Definition) eingeben und gleich den Vorteil genießen, dass mehr Rückmeldungen über eventuelle Fehler kommen!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

erdnar

Ich fange mal hinten an
ZitatNachbrenner: Manches, was du schreibst klingt nach direktem FHEM-geeditiere.
Nein, ich editiere die fhem.cfg NIE ... Ausnahme war heute im Zuge der Fehlersuche.

Zitatwaren in der statefile gespeichert
Das klingt gut, muss ich nur in meiner Sicherung finden.

ZitatWas genau jeweils passiert ist, wäre immer noch interessant, es sollten eigentlich irgendwo vor "started with xy entities" Hinweise zu finden sein, warum FHEM gehangen hat.
Alternativ könnte auch im Linux-Log was zu finden sein, wenn systemd der Ansicht gewesen sein sollte, dass FHEM tot ist und es deswegen neu gestartet hat.
Naja, würde ich auch gerne wissen. Allerdings habe ich nicht so viel Ahnung und bin auf Hilfe angewiesen, die ich auch verstehe. Leider ist auch das Wiki teilweise in Expertensphären angesiedelt die ich von unten nur erahne.
Und das ist kein Vorwurf, nur (m)eine Feststellung.

So wieder mal vielen Dank, ich suche jetzt das statefile ...  ;D

erdnar

Habe das statefile (fhem.save) in der Sicherung gefunden und zurückgespielt.
Readings sind wieder da, Fhem läuft noch.

Danke
ErdnaR

Beta-User

Damit dein Log übersichtlicher wird...

Komisch bzw. vermeidbar finde ich v.a. zwei Typen von Einträgen:
Zitat von: erdnar am 17 Juli 2022, 12:05:44

2022.07.17 01:15:49 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/^MQ_171_soPOW:energyJson:.{ <-- HERE .*}$/ at ./FHEM/98_expandJSON.pm line 64, <$fh> line 3349.
[...]
2022.07.17 01:15:56 1: PERL WARNING: Subroutine HUEDevice_Initialize redefined at ./FHEM/31_HUEDevice.pm line 187, <$fh> line 5558.

Für den ersten siehe https://forum.fhem.de/index.php/topic,120418.0.html. Die zu bearbeitenden sollten sich mit folgendem finden lassen:
list TYPE=expandJSON DEF

Diese redefined-Warnung ist seltsam, ich unterstelle, dass da versehentlich Funktionen an den falschen Ort kopiert worden waren (99_myUtils-Dateien danach durchforsten, bitte). Eventuell kommt es auch von "LEDLeiste.5", falls das ein HUEDevice ist und vor dem IO geladen wird. Dann wäre es ggf. sinnvoll, das IO nach vorne zu verschieben oder die LED-Leiste durch Löschen + Neu anlegen hinter das IO zu verfrachten.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors