Undefined subroutine &main::HMinfo_init

Begonnen von DS_Starter, 17 Oktober 2021, 12:08:56

Vorheriges Thema - Nächstes Thema

DS_Starter

Hallo,

habe auf meinem Testsystem heute früh mal wieder Homematic upgedated.
Nun stürzt FHEM ab mit:


Undefined subroutine &main::HMinfo_init ....


ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Beta-User

HMinfo ist definiert oder nicht?

Wenn ja: "version"?

dto. für CUL_HM. Speziell: das ist nicht zufällig "excluded_from_update"?
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

DS_Starter

Moin,

auf meinem Testsystem ist lediglich der ActionDetector vom Typ CUL_HM definiert, sonst nichts. Dieser wird beim Start geladen.
An dem Testsystem gibt es zur Zeit auch keine HM-Komponenten.
Die Versionen von CUL_HM, HMinfo usw. sind alle die im offiziellen Repo eingecheckt sind. Auf meinem Testsystem sind auch keine Excludes bezüglich der Homematic Module vorhanden ... das wäre jetzt zu einfach.  ;)

Ich habe jetzt die vorherige CUL_HM (FVERSION 10_CUL_HM.pm:0.250590/2021-10-10) wiederhergestellt. Damit stürzt das System nun nicht mehr ab.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Beta-User

Ah, ok, dann verstehe ich auch den Crash, hatte nicht wahrgenommen, dass Martin ein update bereitgestellt hat.

@Martin: Das sieht mir nach einer ähnlichen Konstellation aus wie aus der August-Version
+    #if ($modules{HMinfo}){
+    #Beta-User: prevent crash, wenn no HMinfo device is defined
+    if (defined &HMinfo_tempListDefFn){
+       if (!$template){ $template = HMinfo_tempListDefFn()   .":$fn"      ;}


Diese an mehreren Stellen vorkommende Abfrage nach "if ($modules{HMinfo})" ist nur passend, wenn auch eine HMinfo-Instanz definiert ist...

(Ich nehm's mal auf meine Liste).
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

DS_Starter

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Beta-User

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

DS_Starter

Hab CUL_HM aus dem angegeben Thread getestet. Scheint zu klappen.
Jedenfalls stürzt FHEM nicht mehr ab.

LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

martinp876

danke und sorry.
Anderungen zur Prüfung von HMInfo eingebaut.
Das mit den "Clients" werden ich noch einmal prüfen. Aus meiner Sicht ist es ein fehlen der Daten in den IOs und sollte dort gelöst werden.

Beta-User

Na ja, genau das Thema :CLIENTS: hatten wir neulich bzgl. HMLAN, und da schien die Entscheidung klar in die andere Richtung zu gehen ;D . Vermutlich wäre der Rechenaufwand geringer, wenn man es in HMLAN umbiegt (das ist der aus dem Standard fallende "Problemfall", wenn ich das richtig interpretiere).

Falls du HMLAN anfaßt: da war noch das Thema mit dem timing...
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