Absturz nach Update von 10_MYSENSORS_DEVICE.pm

Begonnen von Besamin, 07 Januar 2019, 22:45:24

Vorheriges Thema - Nächstes Thema

Besamin

Hi Leute,
ich habe gestern abend ein Update über Fhem laufen lassen und seitdem stürzt das System jedes Mal ab sobald ich ein Mysensors-Gerät aufrufe. Das Logfile sagt dann als letzter Eintrag:
Undefined subroutine &MYSENSORS::DEVICE::getFirmwareTypes called at ./FHEM/10_MYSENSORS_DEVICE.pm line 247.

Meine bisherige Lösung ist die Datei manuell mit der Vorgängerversion zu überschreiben. Hat sonst noch jemand das Problem oder einen dauerhaften Lösungsvorschlag? Laut SVNLOG wurde am 4.1. ein Update freigegeben.

Beta-User

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

Besamin

#2
Hi Beta-User,

Es handelt sich um:
# $Id: 00_MYSENSORS.pm 17290 2018-09-06 08:29:45Z Hauswart $

und
# $Id: 10_MYSENSORS_DEVICE.pm 18131 2019-01-04 11:58:28Z Beta-User $


Herzlichen Dank schonmal!

Beta-User

Hmmm,

vorab noch eine Frage: Kannst du feststellen, ob in der Konfiguration erst das GW steht und dann das/die Devices oder anders herum?

Wenn erst eine Node: könntest du das testweise tauschen (Achtung: manuelles Editieren der cfg sollte man eigentlich nicht empfehlen...)?
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

Beta-User

Vorneweg evtl. noch folgender Test für eine Änderung von 10_MYSENSORS_DEVICE.pm im Zeile 247:

$hash->{sets}->{fwType} = join(",", MYSENSORS::getFirmwareTypes($hash->{IODev}));

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

Beta-User

Wie hier berichtet wurde, scheint die vorgeschlagene Änderung in Zeile 247 aus #5 das Problem zu beheben.
Ich checke das heute abend dann ein.
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

hexenmeister

Ich habe das Gefühl, dass das nicht immer ausreichen wird. Vermutlich kann die Reihenfolge der Definitionen im Config trotzdem zu Problemen führen. Ich schlage vor, im BEGIN-Block (Zeile 72) das IO-Modul explizit zu laden (main::LoadModule("MYSENSORS");). Damit dürfte zumindest kein harter Abbruch mehr geben.


...
BEGIN {
  main::LoadModule("MYSENSORS");
  MYSENSORS->import(qw(:all));

  GP_Import(qw(
    AttrVal
    readingsSingleUpdate
...

Beta-User

Großes Danke für's Drübersehen!

Hab's eben eingecheckt.
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