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.
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:
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
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:
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 $
...
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.
Zitat von: tpm88 am 13 März 2014, 10:25:37
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
Zitat von: rudolfkoenig am 13 März 2014, 10:59:55
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.
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.
Und, hast Du einen kreativen Vorschlag, wie man mit dem TCP-Server jetzt umgehen sollte?
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 (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_FRM.pm#L539), 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.
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.
Zitatum ein solches Aufrufschema (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_FRM.pm#L539),...
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.
Zitat von: rudolfkoenig am 16 März 2014, 18:42:22
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?
Zitat von: rudolfkoenig am 16 März 2014, 18:42:22
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)
Zitat
Und ich wuerde nicht die() aufrufen: nur weil ein Modul ungluecklich ist, muessen doch die anderen nicht drunter leiden.
Nennt sich Exceptionhandling (http://perldoc.perl.org/functions/die.html). Viel zuverlässiger (und einfacher) als Fehlerfälle über wechselnde Returnvaluekonventionen abzufangen.
- Norbert
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
@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.
@Rudolf: danke.
Hallo,
die Testversionen von ECMD und ECMDDevice, siehe http://forum.fhem.de/index.php/topic,21515.msg155085.html (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