ECMDDevice - neuerdings Fehler "unknown attribute IODev..." im Logfile

[tpm88]

Hallo,

seit einem meiner letzten Updates diese Woche sehe ich folgende Fehlermeldungen beim Neustart des FHEM-Servers für jedes ECMDDevice (Relais und 1wire DS1820 am AVR Netio). Mit FHEM Stand 23.02.2014 gab es die Meldungen noch nicht.

Code Auswählen Erweitern


2014.03.13 10:00:46 3: ECMD opening NETIO (protocol telnet, device 192.168.8.18:2701)
2014.03.13 10:00:46 3: ECMD device opened
2014.03.13 10:00:47 3: ds_test: unknown attribute IODev. Type 'ds_test ?' for a detailed list.
...
2014.03.13 10:00:47 3: Relais5: unknown attribute IODev. Type 'attr Relais5 ?' for a detailed list.
2014.03.13 10:00:47 3: Relais6: unknown attribute IODev. Type 'attr Relais6 ?' for a detailed list.


Da sich die ECMD Module selber allerdings zuletzt Anfang Januar geändert haben, muß die Ursache woanders ( fhem.pl ?? ) liegen.

Ich habe das Attribut IODev für die ECMDDevices nicht manuell angelegt. Lösche ich das Attribut, gefolgt von Save Config und Restart, sind die Meldungen beim Restart zunächst weg. Allerdings wird das Attribut nach dem Neustart sofort automatisch für alle ECMDDevices wieder eingetragen!!

So sieht es nach einem Neustart von FHEM aus:

Code Auswählen Erweitern

list ds_test

Internals:
   DEF        ONEWIRE 10cc858d0208007d
   IODev      NETIO
   NAME       ds_test
   NR         91
   STATE      temp 19.9
   TYPE       ECMDDevice
   Readings:
     2013-11-18 09:54:39   messen          19.6
     2013-11-18 09:56:21   state           temp 19.9
     2013-11-18 09:56:21   temp            19.9
   Fhem:
     classname  ONEWIRE
     Params:
       devID      10cc858d0208007d
Attributes:
   IODev      NETIO
   room       Test


Code Auswählen Erweitern

list NETIO



Internals:
   DEF        telnet 192.168.8.18:2701
   DeviceName 192.168.8.18:2701
   FD         25
   NAME       NETIO
   NR         63
   PARTIAL   
   Protocol   telnet
   STATE      Initialized
   TYPE       ECMD
   Readings:
     2013-11-18 09:56:00   raw             OK
   Fhem:
     Classdefs:
[...]

Die Funktionalität der ECMDDevices ist nicht betroffen - einzig die Meldungen im FHEM Log sind "unschön"...

Gruss
Tobias

Hier noch der aktuelle Stand der betroffenen Module:

Code Auswählen Erweitern


version

# $Id: fhem.pl 5197 2014-03-10 21:07:30Z rudolfkoenig $
...
# $Id: 66_ECMD.pm 4426 2013-12-20 15:47:05Z borisneubert $
# $Id: 67_ECMDDevice.pm 3412 2013-07-13 11:21:18Z rudolfkoenig $
...


[rudolfkoenig]

Weil neuerdings fhem.pl automatisch in der AssignIoPort() Aufruf das IODev Attribut setzt. Dass ECMDDevice kein IODev Attribut anbietet, aber trotzdem AssignIoPort() aufruft, ist mAn ein Fehler, und muesste in ECMDDevice gefixt werden.

[kpwg]

seit einem meiner letzten Updates diese Woche sehe ich folgende Fehlermeldungen beim Neustart des FHEM-Servers für jedes ECMDDevice (Relais und 1wire DS1820 am AVR Netio). Mit FHEM Stand 23.02.2014 gab es die Meldungen noch nicht.

Die Funktionalität der ECMDDevices ist nicht betroffen - einzig die Meldungen im FHEM Log sind "unschön"...

Kann ich so bestätigen. Vor allem mit vielen ECMDDevices ist es nervig, funktioniert aber trotzdem.

Wer könnte es bei Gelegenheit fixen? (Und den Postproc-Bug zumindest reproduzieren?)

Viele Grüße, Ricardo

[ntruchsess]

Dass ECMDDevice kein IODev Attribut anbietet, aber trotzdem AssignIoPort() aufruft, ist mAn ein Fehler, und muesste in ECMDDevice gefixt werden.

Das sehe ich nicht als Fehler. AssignIOPort ist schließlich die einzige Funktion mit der man ein passendes IODevice automatisch finden kann. Warum bitteschön sollte das davon abhängig sein, ob ein Modul IODev als Attribut anbietet? AssignIOPort sollte in der AttrList der Instanz nachsehen, ob das Attribut unterstützt wird.

[rudolfkoenig]

Im Lichte deiner TCP-Server Erklaerung verstehe ich deine Argumentation (aber auch nur in diesem Fall), und ich meine weiterhin, dass das Fehlen des Attributes beim ECMDDevice ein Fehler ist.

Ab sofort setzt aber AssignIOPort das Attribut nur dann, falls das Modul es anbietet.

[ntruchsess]

Und, hast Du einen kreativen Vorschlag, wie man mit dem TCP-Server jetzt umgehen sollte?

[ntruchsess]

Ich sehe es grundsätzlich als problematisch, dass man AssignIOPort nicht mehr ohne den Seiteneffekt IODev als Attribut persistent zu setzten aufrufen kann und dass es für die alte Funktionalität keinen Ersatz gibt (wenn man sich den code nicht ins Modul dupliziert). Es ist ja nicht nur Autocreate, welches das aufruft.

Mein Vorschlag wäre, das in zwei Methoden aufzutrennen: Eine LookupIOPort, die ein zum hash passendes IODevice heraussucht (also das, was AssignIOPort bis zum November mal war), und eine zweite AssignIOPort, die das Attribut und den IODev-Hashwert koppelt. Dann aber bitte auch so konsequent, dass ein schon gesetztes IODev-attribut benutzt wird, wenn man kein iodev als Argument übergibt (um ein solches Aufrufschema, bei dem man den IODev-attribut-wert erst mal selber ermitteln muss, zu vermeiden). AssignIOPort ruft dann LookupIOPort für den Fall auf, dass weder ein iodev als Argument übergeben wird, noch das IODev-attribut schon gesetzt ist.

[rudolfkoenig]

Ich weiss nicht, welchen Fall du nicht abdecken kannst, vermutlich verstehe ich dein Problem noch nicht. AssignIoPort kann keine Ruecksicht auf das Attribut nehmen, da es beim Aufruf es noch nicht gesetzt ist.

um ein solches Aufrufschema,...

Ich wuerde AssignIoPort mit dem $iodev Vorschlag aufrufen, ohne nach einem Attribut zu suchen. Und ich wuerde nicht die() aufrufen: nur weil ein Modul ungluecklich ist, muessen doch die anderen nicht drunter leiden.

[ntruchsess]

AssignIoPort kann keine Ruecksicht auf das Attribut nehmen, da es beim Aufruf es noch nicht gesetzt ist.

Hast die 75 existierenden Aufrufe daraufhin untersucht dass sie AssignIoPort ausschließich zum Zeitpunkt des Defines und sonst nie aufrufen?

Ich wuerde AssignIoPort mit dem $iodev Vorschlag aufrufen, ohne nach einem Attribut zu suchen.

Wäre nicht schlau, den existierenden Attribut-wert durch wegzulassen kaput zu machen. (Siehe Antwort auf o.g. Frage)

Und ich wuerde nicht die() aufrufen: nur weil ein Modul ungluecklich ist, muessen doch die anderen nicht drunter leiden.

Nennt sich Exceptionhandling. Viel zuverlässiger (und einfacher) als Fehlerfälle über wechselnde Returnvaluekonventionen abzufangen.

- Norbert

[Dr. Boris Neubert]

Dieses Topic ist mir entgangen.

Da ich eh dran bin, werde ich IODev am ECMDDevice ergänzen, zumal ich es selbst wegen meiner zwei Avrnetios brauche.

Coming soon...
Boris

[rudolfkoenig]

@Norbert: ich habe AssignIoPort erweitert, damit sie beim gesetzten IODev Attribut dieses uebernimmt.
Damit sollte dein Aufruf im Link unten einfacher zu schreiben sein. Eine Aenderung ist aber nicht notwendig.

[ntruchsess]

@Rudolf: danke.

[Dr. Boris Neubert]

Hallo,

die Testversionen von ECMD und ECMDDevice, siehe http://forum.fhem.de/index.php/topic,21515.msg155085.html, honorieren nun das IODev-Attribut. Tester willkommen, aber Achtung: die Klassendefinitionen müssen angepaßt werden. Müssen sie aber in zwei Wochen sowieso, wenn die Version freigelassen wird.

Viele Grüße
Boris