FHEM startet nicht mehr nach Update - 88_HMCCUDEV.pm

Begonnen von smeagel, 18 Februar 2022, 08:03:42

Vorheriges Thema - Nächstes Thema

betateilchen

Zitat von: pcbastler am 30 Oktober 2024, 08:28:12ich hab mit Proxmox-Helper-Scripts einen FHEM-LXC aufgesetzt, gestern brachte apt upgrade die neuen Dateien.

Mit den Container-Konstrukten kenne ich mich nicht aus, aber bist Du sicher, dass FHEM Dateien per "apt upgrade" aktualisiert werden?

Für mich klingt das spontan eher danach, dass Du wieder alte Dateien eingespielt und damit Dein funktionierendes FHEM beschädigt hast.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

pcbastler

#16
also alles auf Anfang:
apt reinstall fhem (Prpository ist  https://debian.fhem.de/nightly/ )
als erstes noch contrib/dblog/db.conf angepasst
dann gestartet:

2024.10.30 09:22:45 1: Including fhem.cfg
2024.10.30 09:22:45 2: logdb - Subprocess >65711< initialized ... ready for non-blocking operation
2024.10.30 09:22:45 2: eventTypes: loaded 3238 lines from ./log/eventTypes.txt
2024.10.30 09:22:46 1: HMLAN_Parse: HMLAN1 new condition disconnected
2024.10.30 09:22:46 1: [Alarm_Define] data hash restored from save file with date 2020-11-18 18:19:36
Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 128, <$fh> line 1108.

Die abgeschaltete CCU2 ist erstmal auch wieder eingeschaltet.
Gelöst: die CCU2 hatte ich als device schon gelöscht, einige Geräte hatten diese aber noch als IO-Device. Das hat dann wohl nicht ganz gepasst....

zap

Schau mal in der fhem.cfg, ob das IO Device (Modul HMCCU) vor den HMCCUDEV und HMCCUCHN Devices definiert wird. Falls nicht, ändere die Reihenfolge.

Die Fehlermeldung deutet eher darauf hin, dass HMCCU noch nicht geladen war, aber eine Funktion aus dem Modul aufgerufen werden sollte.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

betateilchen

Das Problem ist doch schon gelöst?

Zitat von: pcbastler am 30 Oktober 2024, 09:27:11Gelöst: die CCU2 hatte ich als device schon gelöscht, einige Geräte hatten diese aber noch als IO-Device. Das hat dann wohl nicht ganz gepasst....
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Zitat von: betateilchen am 30 Oktober 2024, 17:13:55Das Problem ist doch schon gelöst?
Eigentlich ist das Problem imo erst dann (richtig) gelöst, wenn die beiden Module nicht mehr in der passenden Reihenfolge geladen werden müssen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

pcbastler

Es lag ja nicht an der Reihenfolge. Alle HM-Geräte hatte ich auf die CCU3 migriert (zumindest in der CCU), damit war die CCU2 jetzt obsolet und wurde im FHEM gelöscht. Der Hinweis vor dem Löschen: "device xxx ist noch referenziert" (Sei es als IO-Device, in Automatisierungen, oder ...) wäre ein Anfang.

Beta-User

Zitat von: pcbastler am 30 Oktober 2024, 18:16:45Es lag ja nicht an der Reihenfolge.
Aha....
Die log-Meldung hätte ich anders interpretiert...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

zap

Lag mit ziemlicher Sicherheit an der geänderten Reihenfolge der Device-Definition. Die neue CCU (I/O-Device) wurde nachträglich definiert => Das define stand hinter den Geräten => Funktionen aus dem I/O Device können nicht genutzt werden.

Ich hatte mal das explizite Laden von HMCCU in den Client-Modulen drinstehen, habe es irgendwann aber auskommentiert. Kann mich nur gerade nicht erinnern warum.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Beta-User

Zitat von: zap am 31 Oktober 2024, 10:47:46Ich hatte mal das explizite Laden von HMCCU in den Client-Modulen drinstehen, habe es irgendwann aber auskommentiert. Kann mich nur gerade nicht erinnern warum.
Alternativ:
- Funktionsaufruf erst nach $init_done, sonst per timer?
- vorab prüfen, ob die Funktion defined ist, sonst (aber erst wenn $init_done) einen Logeintrag (verbose 1?).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files