FHEM Crash nach update

Begonnen von Firefield, 18 April 2021, 14:04:37

Vorheriges Thema - Nächstes Thema

Firefield

Hi

Ich poste hier leider immer nur wenn ich irgendwelche Probleme habe. Denke mir zwar jedes Mal, dass ich etwas aktiver sein sollte. Bloß wenns dann läuft tritt das in den Hintergrund und ich finde andere Dinge...

Mein Problem war diesmal das Update. Das letzte war im Februar. Nach dem Neustart stürzte FHEM dann ständig ab. FHEM läuft bei mir unter Debian auf einem NUC als Service und mit ConfigDB. Im Logfile stand dann das:
 
2021.04.18 11:02:37 2: DbLog MariaDB - Last database write cycle due to shutdown ...
2021.04.18 11:02:37 1: Server shutdown delayed due to MariaDB for max 10 sec
2021.04.18 11:02:37 2: DbLog MariaDB - no data for last database write cycle
2021.04.18 11:02:37 0: Server shutdown
2021.04.18 11:02:38 3: LaCrosse: Unknown device 08, please define it
2021.04.18 11:02:41 3: telnetPort: port 7072 opened
2021.04.18 11:02:41 3: WEB: port 8083 opened
2021.04.18 11:02:41 3: WEBphone: port 8084 opened
2021.04.18 11:02:41 3: WEBtablet: port 8085 opened
2021.04.18 11:02:41 2: eventTypes: loaded 3181 lines from ./opt/fhem/log/eventTypes.txt
2021.04.18 11:02:42 3: Opening SCLX85 device 192.168.178.25:23
2021.04.18 11:02:42 1: HMLAN_Parse: HM new condition disconnected
2021.04.18 11:02:42 3: Opening HM device 192.168.178.37:1000
2021.04.18 11:02:42 1: HMLAN_Parse: HM new condition init
2021.04.18 11:02:42 3: HM device opened
2021.04.18 11:02:42 1: PERL WARNING: Useless use of anonymous hash ({}) in void context at ./FHEM/10_CUL_HM.pm line 7418.
2021.04.18 11:02:43 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/32_withings.pm line 527, <DATA> line 851.
2021.04.18 11:02:43 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/32_withings.pm line 550, <DATA> line 851.
2021.04.18 11:02:44 1: dewpoint Taupunkt: attribute 'absFeuchte' is deprecated, please use 'absoluteHumidity'
Undefined subroutine &main::WeekdayTimer_Define called at ./FHEM/98_Heating_Control.pm line 75.
2021.04.18 11:02:45 3: telnetPort: port 7072 opened
2021.04.18 11:02:45 3: WEB: port 8083 opened
2021.04.18 11:02:45 3: WEBphone: port 8084 opened
2021.04.18 11:02:45 3: WEBtablet: port 8085 opened
2021.04.18 11:02:46 2: eventTypes: loaded 3181 lines from ./opt/fhem/log/eventTypes.txt
2021.04.18 11:02:46 3: Opening SCLX85 device 192.168.178.25:23
2021.04.18 11:02:46 1: HMLAN_Parse: HM new condition disconnected
2021.04.18 11:02:46 3: Opening HM device 192.168.178.37:1000
2021.04.18 11:02:46 1: HMLAN_Parse: HM new condition init
2021.04.18 11:02:46 3: HM device opened
2021.04.18 11:02:47 1: PERL WARNING: Useless use of anonymous hash ({}) in void context at ./FHEM/10_CUL_HM.pm line 7418.
2021.04.18 11:02:47 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/32_withings.pm line 527, <DATA> line 851.
2021.04.18 11:02:47 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/32_withings.pm line 550, <DATA> line 851.
2021.04.18 11:02:48 1: dewpoint Taupunkt: attribute 'absFeuchte' is deprecated, please use 'absoluteHumidity'
Undefined subroutine &main::WeekdayTimer_Define called at ./FHEM/98_Heating_Control.pm line 75.
2021.04.18 11:02:49 3: telnetPort: port 7072 opened


Die drei Perl Warnings kamen vorher nicht, das mit absFeuchte und absoluteHumidity war mir auch nicht aufgefallen. Allerdings war der letzte Neustart halt im Februar. Denk aber nicht, dass das der Grund war, sondern eher der Eintrag Datum/Zeit – undefined subroutine.
Zuerst hatte ich 10_CUL_HM.pm und 98_Heating_Control.pm zurückgerollt. Die Meldungen vor der undefined subroutine hatten sich dann etwas geändert

ndefined subroutine &main::WeekdayTimer_Define called at ./FHEM/98_Heating_Control.pm line 74.
2021.04.18 12:20:09 3: telnetPort: port 7072 opened
2021.04.18 12:20:09 3: WEB: port 8083 opened
2021.04.18 12:20:09 3: WEBphone: port 8084 opened
2021.04.18 12:20:09 3: WEBtablet: port 8085 opened
2021.04.18 12:20:09 2: eventTypes: loaded 3181 lines from ./opt/fhem/log/eventTypes.txt
2021.04.18 12:20:10 3: Opening SCLX85 device 192.168.178.25:23
2021.04.18 12:20:10 1: HMLAN_Parse: HM new condition disconnected
2021.04.18 12:20:10 3: Opening HM device 192.168.178.37:1000
2021.04.18 12:20:10 1: HMLAN_Parse: HM new condition init
2021.04.18 12:20:10 3: HM device opened
2021.04.18 12:20:11 3: TFGast: unknown attribute .mId. Type 'attr TFGast ?' for a detailed list.
2021.04.18 12:20:11 3: ActionDetector: unknown attribute .mId. Type 'attr ActionDetector ?' for a detailed list.
2021.04.18 12:20:11 3: Terrasse_S: unknown attribute .mId. Type 'attr Terrasse_S ?' for a detailed list.
2021.04.18 12:20:11 3: BoFe: unknown attribute .mId. Type 'attr BoFe ?' for a detailed list.
2021.04.18 12:20:12 1: dewpoint Taupunkt: attribute 'absFeuchte' is deprecated, please use 'absoluteHumidity'
Undefined subroutine &main::WeekdayTimer_Define called at ./FHEM/98_Heating_Control.pm line 74.
2021.04.18 12:20:13 3: telnetPort: port 7072 opened
2021.04.18 12:20:13 3: WEB: port 8083 opened
2021.04.18 12:20:13 3: WEBphone: port 8084 opened
2021.04.18 12:20:13 3: WEBtablet: port 8085 opened
2021.04.18 12:20:13 2: eventTypes: loaded 3181 lines from ./opt/fhem/log/eventTypes.txt

[/code]

Hatte aber irgendwie keine Wirkung. Dann hatte ich das komplette Update zurückgerollt. Jetzt startet das wieder und ich muss wohl die config etwas zurückdrehen, da es einige Attribute mit ,?' gibt
Woran lag das aber? Mir ist nicht bewusst was ich falsch gemacht hätte beim Update. Oder hat sich irgendwann etwas geändert was ich komplett übersehen habe?  Bzw. was müsste ich vorher tun damit mir das nicht weiterhin beim Update passiert?

Gigabyte GB-BACE-3150, 8GB RAM, 120GB SSD, Proxmox mit FHEM-VM und DB-VM| (ab und an aktuelles) FHEM mit ConfigDB+LogDB. MariaDB + phpmyadmin. | Zwave.me USB dongle, Jeelink, HM, BTLE und HUEbridge.

rudolfkoenig

Zunaechst muesste man feststellen, warum FHEM abstuerzt, das "wie" ist in der Wiki beschrieben:
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
Ich empfehle die Version mit "perl fhem.pl -d configDB".

Beta-User

WDT auf eine alte Version, dann Heating_Control in WDT umwandeln. Siehe CHANGED und Wiki zu HC.
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

CoolTux

Warum!
Undefined subroutine &main::WeekdayTimer_Define

Scheint Probleme mit WeekdayTimer zu geben.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Probleme? Volle Absicht, lange angekündigt!
Meine Antwort ging wohl unter, oder?
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

CoolTux

Zitat von: Beta-User am 18 April 2021, 14:26:25
Probleme? Volle Absicht, lange angekündigt!
Meine Antwort ging wohl unter, oder?

Du hast zu schnell geantwortet  ;D
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rudolfkoenig

Das Problem in WDT duerfte aber "nur" fuer eine Meldung in FHEM-Log und fuer nicht definierte WeekDayTimer Instanzen sorgen, aber nicht fuer einen FHEM-Crash.
Uebersehe ich etwas?

Beta-User

Der Aufruf kommt aus Heating_Control. Das ist nicht mehr supported, und hatte sich die Funktio "geborgt" (>1 Jahr verbose-1 Meldungen im Log!).
Nutzt man WDT statt HC (Funktion ist identisch!), wird die korrekte (package-) Funktion aufgerufen.
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

Firefield

danke für die antworten :)  :D besonders am sonntag
meine nächste idee wäre gewesen die heatingcontrols zu löschen.
stehe natürlich nun etwas beträufelt da, weil ich die migration zu wdt nicht mitbekommen hab...  :-[
fhem stürzt nun nach dem update nicht mehr ab. vielen dank nochmal (:
Gigabyte GB-BACE-3150, 8GB RAM, 120GB SSD, Proxmox mit FHEM-VM und DB-VM| (ab und an aktuelles) FHEM mit ConfigDB+LogDB. MariaDB + phpmyadmin. | Zwave.me USB dongle, Jeelink, HM, BTLE und HUEbridge.

Beta-User

Sorry für den crash, aber keine Sorge. Es gab mindestens einen anderen User, der das auch erst mitbekommen hat, als FHEM nicht mehr wollte.


Bitte künftig vor updaes nach langer update-Pause unbedingt CHANGED ansehen. Zumindest sehe ich keine andere Möglichkeit, derartige Änderungen mitzuteilen...
Update scheint auch irgendwann die Löschungen nicht mehr nachzuverfolgen...
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

Firefield

für den crash kannste ja nix, das lag pur an mir.
hatte mir auch schon gedanken gemacht wie ich das vermeiden kann. changed sowie das ankündigungen forum lesen erspart mir sowas. fhem läuft derzeit so gut, dass ich vergesse dass ich bei so nem projekt ab und an doch etwas zeit dafür einplanen sollte ^^
Gigabyte GB-BACE-3150, 8GB RAM, 120GB SSD, Proxmox mit FHEM-VM und DB-VM| (ab und an aktuelles) FHEM mit ConfigDB+LogDB. MariaDB + phpmyadmin. | Zwave.me USB dongle, Jeelink, HM, BTLE und HUEbridge.