FHEM startet nicht mehr nach Update - 88_HMCCUDEV.pm

[betateilchen]

ich 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.

[pcbastler]

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.

[betateilchen]

Das Problem ist doch schon gelöst?

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....

[Beta-User]

Das 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...

[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]

Es lag ja nicht an der Reihenfolge.

Aha....
Die log-Meldung hätte ich anders interpretiert...

[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.

[Beta-User]

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.

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?).

[zap]

Vermutlich falsche Reihenfolge der Devices in der fhem.cfg.

Das iO Device muss zuerst in der Config stehen. Da Du eine neue CCU definiert hast, steht das define nun nach den Devices.

[Beta-User]

Das iO Device muss zuerst in der Config stehen.

Die "Fehlerursache" war doch schon lange klar, die eigentliche Frage ist: Soll die HMCCU.*-Modul-Familie eine der wenigen 2-stufigen Modulfamilien bleiben, die mit dieser Art "Userfehler" ein Problem haben?!?

(Wir hatten dies Art Problem "früher" (>5 Jahre) relativ häufig, und afair haben alle betroffenen Maintainer ihre Module so geändert, dass die config-Reihenfolge irrelevat geworden ist). 

[zap]

Das iO Device muss zuerst in der Config stehen.

Die "Fehlerursache" war doch schon lange klar, die eigentliche Frage ist: Soll die HMCCU.*-Modul-Familie eine der wenigen 2-stufigen Modulfamilien bleiben, die mit dieser Art "Userfehler" ein Problem haben?!?

(Wir hatten dies Art Problem "früher" (>5 Jahre) relativ häufig, und afair haben alle betroffenen Maintainer ihre Module so geändert, dass die config-Reihenfolge irrelevat geworden ist). 

Ich denke darüber nach. Aktuell machen HMCCUDEV und HMCCUCHN einige Validitätschecks während der Definition der Client-Devices (existiert die angegbene Adresse in der CCU usw). Die würden dann erstmal wegfallen, da die dazu benötigten Daten (Liste der Homematic-Geräte der CCU) erst nach Definition des I/O Device vorhanden sind.
Eigentlich kein Problem, sofern niemand die Config manuell editiert und dabei Fehler macht. Denn bei der interaktiven Definition von Devices über die FHEM Oberfläche sind ja alle Daten vorhanden und die Validität der Angaben kann geprüft werden.

Also ja, ich denke "wohlwollend" darüber nach 

[Beta-User]

Eigentlich kein Problem, sofern niemand die Config manuell editiert und dabei Fehler macht.

Das Problem hier war, dass der User gerade nicht die config manuell editiert hatte, sondern (statt die IP per defmod zu ändern) seine "neue" CCU per define angelegt hat. Sowas kommt m.E. (ganz allgemein, unabhängig von HMCCU) recht häufig vor, nur ist es eben bei den meisten 2-stufigen Modulen zwischenzeitlich so gelöst, dass die kein Problem mit der Reihenfolge mehr haben.

Da ich eben eine Lösung für was ähnliches (PID20) gepostet habe, hier der Link zum diff für dieses Modul: https://forum.fhem.de/index.php?msg=1326439.

Die "Prüfungsroutine" wird bei PID20 per notifyfn gestartet; wenn HMCCU keine solche hat, sollte man die timer-basiert aufrufen. Das muss dann halt zu den timern passen, die ggf. die abhängigen Module starten (also vorher laufen).

PS: Bei CUL_HM war das auch eine Geburt, bis es letztlich dann gepaßt hat. Da waren auch noch die notify-Präfixe so anzupassen, dass erst die IO's konfiguriert wurden, etc. pp...