Hallo,
ich habe heute morgen ein Update von meiner FHEM-Instanz (Docker) angestoßen mit dem Ergebnis das dieser nun leider
nicht mehr startet bzw. crasht.
Bisher liefen alle Update problemlos, die fhem.cfg wurde auch nicht manuell verändert....und dennoch kommt im Logfile dieser Eintrag:
Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 136, <$fh> line 1673.
Dann wird wohl erneut ein Start versucht - mit dem selben Ergebins.
Immer kommt dieser Eintrag im Log und FHEM ist per Weboberfläche nicht erreichbar.
Sobald ich das Backup wieder einspiele, läuft alle wie gehabt - Update anschubsen: Gleicher Fehler.
Hat jemand eine Idee an was das liegen könnte?
VG
Thorsten
Kurzer Zwischenbericht:
In einem anderen Forenbeitrag habe ich etwas gelesen das evtl. Devices früher geladen werden als die CCU - Habe schweren Herzens die
fhem.cfg manuell editiert und angeschaut: Es scheint als würde die CCU später geladen als HM-Devices.
Vorgehen: Alle CCU-Devices ziemlich weit oben in der fhem.cfg eingefügt.
Somit scheint es zu gehen - allerdings bekomme ich beim starten von FHEM nun folgende Logeinträge:
2022.02.18 08:42:45 2: HMCCURPCPROC [d_rpc168006HmIP_RF] RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
no element found at line 1, column 0, byte -1:
9^
4713531094000
at /usr/share/perl5/RPC/XML/Client.pm line 436.
2022.02.18 08:42:45 2: HMCCURPCPROC [d_rpc168006HmIP_RF] Retrying request getParamsetDescription
2022.02.18 08:42:45 2: HMCCURPCPROC [d_rpc168006HmIP_RF] RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
no element found at line 1, column 0, byte -1:
9^
4713531094000
at /usr/share/perl5/RPC/XML/Client.pm line 436.
2022.02.18 08:42:45 2: HMCCURPCPROC [d_rpc168006HmIP_RF] Retrying request getParamsetDescription
2022.02.18 08:42:45 2: HMCCURPCPROC [d_rpc168006HmIP_RF] Error(s) while fetching parameter set descriptions 001299939605E5. Error while executing RPC multicall request: RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
no element found at line 1, column 0, byte -1:
9^
4713531094000
at /usr/share/perl5/RPC/XML/Client.pm line 436.
2022.02.18 08:43:17 2: HMCCURPCPROC [d_rpc168006HmIP_RF] RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
no element found at line 1, column 0, byte -1:
9^
4713531556768
at /usr/share/perl5/RPC/XML/Client.pm line 436.
2022.02.18 08:43:17 2: HMCCURPCPROC [d_rpc168006HmIP_RF] Retrying request getParamsetDescription
2022.02.18 08:43:47 2: HMCCURPCPROC [d_rpc168006HmIP_RF] RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
no element found at line 1, column 0, byte -1:
9^
4713531556768
at /usr/share/perl5/RPC/XML/Client.pm line 436.
2022.02.18 08:43:47 2: HMCCURPCPROC [d_rpc168006HmIP_RF] Retrying request getParamsetDescription
2022.02.18 08:43:47 2: HMCCURPCPROC [d_rpc168006HmIP_RF] Error(s) while fetching parameter set descriptions 00155993965479. Error while executing RPC multicall request: RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
no element found at line 1, column 0, byte -1:
9^
4713531556768
at /usr/share/perl5/RPC/XML/Client.pm line 436.
2022.02.18 08:44:07 2: HMCCU [HM_CCU3] Read 581 Paramset Descriptions for interface HmIP-RF
2022.02.18 08:44:07 2: HMCCU [HM_CCU3] Reading Peer Descriptions for interface HmIP-RF
2022.02.18 08:44:07 2: HMCCU [HM_CCU3] Read 36 Peer Descriptions for interface HmIP-RF
Hat jemand eine Idee was hier schief läuft?
Es kommt hin und wieder vor, dass FHEM beim Speichern der Config die I/O Devices nicht zuerst in die fhem.cfg schreibt. Keine Ahnung, woran das liegt.
Eigentlich sind I/O Devices und ihre abhängigen Client-Devices an dem Internal "Clients" im I/O Device identifizierbar.
Bei HMCCU sieht dieser Eintrag so aus:
Clients :HMCCUDEV:HMCCUCHN:HMCCURPCPROC:
FHEM weiß also, dass HMCCU ein I/O Device für HMCCUDEV usw ist
Zitat von: zap am 18 Februar 2022, 11:55:56
Es kommt hin und wieder vor, dass FHEM beim Speichern der Config die I/O Devices nicht zuerst in die fhem.cfg schreibt. Keine Ahnung, woran das liegt.
MWn. ist das keine "Aufgabe", die fhem.pl erledigen würde. In der cfg werden die Geräte nach meinem Kenntnisstand so abgelegt, wie sie - zeitlich gesehen - nacheinander definiert wurden.
Dieses Reihenfolgeproblem haben die meisten anderen zwiestufigen Module in der Regel selbst intern gelöst (Timer, vorher checken, ob es die andere Funktion gibt, use ..., whatever).
PS: bei configDB kann man nicht einfach die Reihenfolge manuell ändern, und ein IO nachträglich dadurch nach vorne zu holen, dass man alles andere löscht, ist irgendwie auch keine Option (und in der DB selbst rumzumurksen erst recht nicht).
Ich hatte den Fehler nach einem update vorgestern auch, aber er hatte vorher HttpUtils.pm angemeckert. Shutdown-restart hat erstmal nicht geholfen. Nachdem ich dann das backup eingespielt hatte, und shutdown und restart lief FHEM dann wieder. Nach einem neuerlichen Update lief es dann mit den neuen modulen auch.2022.02.16 14:47:59 1: reload: Error:Modul 88_HMCCU deactivated:
Attempt to reload HttpUtils.pm aborted.
Compilation failed in require at ./FHEM/88_HMCCU.pm line 38, <$fh> line 3589.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 38, <$fh> line 3589.
2022.02.16 14:47:59 0: Attempt to reload HttpUtils.pm aborted.
Compilation failed in require at ./FHEM/88_HMCCU.pm line 38, <$fh> line 3589.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 38, <$fh> line 3589.
Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 136, <$fh> line 3631.
Hast Du autosave eingeschaltet?
Bei mir war/ist ,,attr global autosave 0". Wieso?
fhem_1 | 2022.04.08 21:17:27.253 1: HMCCU [d_ccu] Reading device config from CCU. This may take a couple of seconds ...
fhem_1 | 2022.04.08 21:17:27.254 2: HMCCU [d_ccu] Reading Device Descriptions for interface BidCos-RF
fhem_1 | 2022.04.08 21:17:27.363 2: HMCCU [d_ccu] Read 97 Device Descriptions for interface BidCos-RF
fhem_1 | 2022.04.08 21:17:27.363 2: HMCCU [d_ccu] Reading Paramset Descriptions for interface BidCos-RF
fhem_1 | 2022.04.08 21:17:27.857 2: HMCCU [d_ccu] Read 209 Paramset Descriptions for interface BidCos-RF
fhem_1 | 2022.04.08 21:17:27.857 2: HMCCU [d_ccu] Reading Peer Descriptions for interface BidCos-RF
fhem_1 | 2022.04.08 21:17:27.869 2: HMCCU [d_ccu] Read 12 Peer Descriptions for interface BidCos-RF
fhem_1 | 2022.04.08 21:17:27.870 2: HMCCU [d_ccu] Reading Device Descriptions for interface HmIP-RF
fhem_1 | 2022.04.08 21:17:27.957 2: HMCCU [d_ccu] Read 80 Device Descriptions for interface HmIP-RF
fhem_1 | 2022.04.08 21:17:27.957 2: HMCCU [d_ccu] Reading Paramset Descriptions for interface HmIP-RF
fhem_1 | 2022.04.08 21:17:57.976 2: HMCCURPCPROC [d_rpc000015HmIP_RF] RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
fhem_1 | no element found at line 1, column 0, byte -1:
fhem_1 | 9^
fhem_1 | 4899695129920
fhem_1 | at /usr/share/perl5/RPC/XML/Client.pm line 426.
fhem_1 |
fhem_1 | 2022.04.08 21:17:57.976 2: HMCCURPCPROC [d_rpc000015HmIP_RF] Retrying request getParamsetDescription
fhem_1 | 2022.04.08 21:18:27.995 2: HMCCURPCPROC [d_rpc000015HmIP_RF] RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
fhem_1 | no element found at line 1, column 0, byte -1:
fhem_1 | 9^
fhem_1 | 4899695129920
fhem_1 | at /usr/share/perl5/RPC/XML/Client.pm line 426.
fhem_1 |
fhem_1 | 2022.04.08 21:18:27.995 2: HMCCURPCPROC [d_rpc000015HmIP_RF] Retrying request getParamsetDescription
fhem_1 | 2022.04.08 21:18:27.995 2: HMCCURPCPROC [d_rpc000015HmIP_RF] Error(s) while fetching parameter set descriptions 00129993951902. Error while executing RPC multicall request: RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
fhem_1 | no element found at line 1, column 0, byte -1:
fhem_1 | 9^
fhem_1 | 4899695129920
fhem_1 | at /usr/share/perl5/RPC/XML/Client.pm line 426.
fhem_1 |
fhem_1 | 2022.04.08 21:18:58.012 2: HMCCURPCPROC [d_rpc000015HmIP_RF] RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
fhem_1 | no element found at line 1, column 0, byte -1:
fhem_1 | 9^
fhem_1 | 4899695129920
fhem_1 | at /usr/share/perl5/RPC/XML/Client.pm line 426.
fhem_1 |
fhem_1 | 2022.04.08 21:18:58.012 2: HMCCURPCPROC [d_rpc000015HmIP_RF] Retrying request getParamsetDescription
fhem_1 | 2022.04.08 21:19:28.028 2: HMCCURPCPROC [d_rpc000015HmIP_RF] RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
fhem_1 | no element found at line 1, column 0, byte -1:
fhem_1 | 9^
fhem_1 | 4899695129920
fhem_1 | at /usr/share/perl5/RPC/XML/Client.pm line 426.
fhem_1 |
fhem_1 | 2022.04.08 21:19:28.028 2: HMCCURPCPROC [d_rpc000015HmIP_RF] Retrying request getParamsetDescription
fhem_1 | 2022.04.08 21:19:28.028 2: HMCCURPCPROC [d_rpc000015HmIP_RF] Error(s) while fetching parameter set descriptions 00155993959463. Error while executing RPC multicall request: RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
fhem_1 | no element found at line 1, column 0, byte -1:
fhem_1 | 9^
fhem_1 | 4899695129920
fhem_1 | at /usr/share/perl5/RPC/XML/Client.pm line 426.
fhem_1 |
fhem_1 | 2022.04.08 21:19:58.045 2: HMCCURPCPROC [d_rpc000015HmIP_RF] RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
fhem_1 | no element found at line 1, column 0, byte -1:
fhem_1 | 9^
fhem_1 | 4899695129920
fhem_1 | at /usr/share/perl5/RPC/XML/Client.pm line 426.
fhem_1 |
fhem_1 | 2022.04.08 21:19:58.046 2: HMCCURPCPROC [d_rpc000015HmIP_RF] Retrying request getParamsetDescription
fhem_1 | 2022.04.08 21:20:28.063 2: HMCCURPCPROC [d_rpc000015HmIP_RF] RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
fhem_1 | no element found at line 1, column 0, byte -1:
fhem_1 | 9^
fhem_1 | 4899695129920
fhem_1 | at /usr/share/perl5/RPC/XML/Client.pm line 426.
fhem_1 |
fhem_1 | 2022.04.08 21:20:28.063 2: HMCCURPCPROC [d_rpc000015HmIP_RF] Retrying request getParamsetDescription
fhem_1 | 2022.04.08 21:20:28.063 2: HMCCURPCPROC [d_rpc000015HmIP_RF] Error(s) while fetching parameter set descriptions 00155993957869. Error while executing RPC multicall request: RPC request getParamsetDescription failed: RPC::XML::Client::simple_request:
fhem_1 | no element found at line 1, column 0, byte -1:
fhem_1 | 9^
fhem_1 | 4899695129920
fhem_1 | at /usr/share/perl5/RPC/XML/Client.pm line 426.
fhem_1 |
fhem_1 | 2022.04.08 21:20:31.270 2: HMCCU [d_ccu] Read 191 Paramset Descriptions for interface HmIP-RF
fhem_1 | 2022.04.08 21:20:31.270 2: HMCCU [d_ccu] Reading Peer Descriptions for interface HmIP-RF
fhem_1 | 2022.04.08 21:20:31.288 2: HMCCU [d_ccu] Read 2 Peer Descriptions for interface HmIP-RF
fhem_1 | 2022.04.08 21:20:31.312 2: HMCCU [d_ccu] Read device configuration in 184.059465885162 seconds: devices/channels=177 parametersets=400 links=14
fhem_1 | 2022.04.08 21:20:31.312 2: HMCCU [d_ccu] RPC device for interface BidCos-RF: d_rpc000015BidCos_RF
fhem_1 | 2022.04.08 21:20:31.312 2: HMCCU [d_ccu] RPC device for interface HmIP-RF: d_rpc000015HmIP_RF
Ich kämpfe auch mit dem Fehler. Fhem startet aber es dauert halt auch sehr lange, bis er an diesen Fehlermeldungen vorbei ist.
Ich habe bereits die HMCCU und HMCCURPCPROC Definitionen nun nach vorn gepackt, direkt nach dem FHEMWEB und so alles durch ist. Leider ohne Erfolg.
Hi,
Ich habe nach einem Update gestern ebenfalls die Probleme, das FHEM nicht mehr startet.
Ein Backup direkt vor dem Update gefertigt, bringt keine Abhilfe.
EDIT
FHEM startet sehr wohl, ist aber per Browser nicht erreichbar.
Das Logfile spricht dazu folgendes:
2022.04.09 13:19:56 1: reload: Error:Modul 88_HMCCU deactivated:
Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base ./FHEM/lib) at ./FHEM/88_HMCCU.pm line 36, <$fh> line 202.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 36, <$fh> line 202.
2022.04.09 13:19:56 0: Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base ./FHEM/lib) at ./FHEM/88_HMCCU.pm line 36, <$fh> line 202.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 36, <$fh> line 202.
Aktuell fehlt mir noch der richtige Ansatz, um das Problem zu beheben.
Interessant dabei:
Eine andere Installation habe ich gestern ebenfalls aktualisiert, dort habe ich die Probleme nicht.
vb
Zitatyou may need to install the RPC::XML::Client module
hinweis befolgt?
wo liegt die datei?
ist sie im pfad (@inc) vorhanden?
Da es vorher ja auch funktionierte, habe ich diesen Hinweis gekonnt ignoriert. ::)
Habe ich jetzt aber nachgeholt und neu installiert.
Server dauerte ewig, Client wurde nichts gemacht da bereits vorhanden.
Bzgl. der Datei hilf mir mal bitte auf die Sprünge, welche soll wo liegen?
Wenn ich 88_HMCCUDEV und 88_HMCCUCHN umbenenne, startet FHEM und ist auch wieder erreichbar.
Natürlich ohne die HM Funktionalität.
vb
edit:
ich habe jetzt von hier: https://forum.fhem.de/index.php?topic=61370.0 (https://forum.fhem.de/index.php?topic=61370.0) den Rat von Otto123 befolgt und folgendes versucht:
ZitatHi,
Alternativ zu cpan :-X sollte man unter debian/raspbian also auf dem pi auch das Paket librpc-xml-perl installieren können.
Also angemeldet am Pi dann
Code: [Auswählen]
sudo apt-get update && sudo apt-get install -y librpc-xml-perl
Gruß Otto
mit Erfolg!
FHEM startet wieder und ist arbeitswillig.
Einzig die Geräte und Channel aus der CCU fehlen, aber das is bei mir zum Glück nicht viel.
vb
Mit dem heutigen Update hab ich den gleichen Fehler. Die 88_HM*.pm sind vom 29.10.2024 07:55, umbennenen von 88_HMCCUCHN.pm und 88-.HMCCUDEV.pm lässt FHEM starten.
Was kann ich per Log beitragen?
Was heißt
Zitat von: pcbastler am 29 Oktober 2024, 21:26:05den gleichen Fehler
?
Dies hier?
Zitat von: smeagel am 18 Februar 2022, 08:03:42Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 136, <$fh> line 1673.
Poste doch auch einfach mal dein Log.
Zitat von: pcbastler am 29 Oktober 2024, 21:26:05Die 88_HM*.pm sind vom 29.10.2024 07:55
Die Dateien wurden laut svn seit 14. April 2024 nicht geändert.
Wo hast Du Dateien mit diesem Datum her?
ich hab mit Proxmox-Helper-Scripts einen FHEM-LXC aufgesetzt, gestern brachte apt upgrade die neuen Dateien. Ich hole mal den Stand meiner alten VM, die hab ich glücklicherweise noch.
Fehlermeldung ist
Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 128, <$fh> line 1108.
Ich hab allerdings eine CCU2 außer Betrieb genommen, kann es sein dass die noch irgendwo hinterlegt ist?
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....
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.
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....
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.
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....
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...
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.
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...
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.
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?).
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.
Zitat von: zap am 03 November 2024, 22:26:59Das 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).
Zitat von: Beta-User am 04 November 2024, 05:22:00Zitat von: zap am 03 November 2024, 22:26:59Das 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 :)
Zitat von: zap am 04 November 2024, 11:32:40Eigentlich 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...