fhem.pl od. 00_CUL.pm: lower case als upper case interpretiert ?

[KölnSolar]

Ich musste heute seltsames in meinem Testsystem(Rpi-wheezy m. busware-CUL-V3 aculfw 1.23.08) feststellen. Plötzlich hatte ich im Room=neu zig neue Hoermann-devices, obwohl hier kein einziges physisch in der Nähe ist 

Nach eingehender Analyse stellte ich fest, dass gleichzeitig meine Revolts sich nicht mehr melden. Just seitdem autocreate Hoermann-devices anlegte.

Code Auswählen Erweitern

CUL433_MSGCNT 395
CUL433_RAWMSG r40dae5000032000864a079
CUL433_RSSI -72
CUL433_TIME 2017-11-26 12:16:32
DEF 40dae50000

IODev CUL433
LASTInputDev CUL433
MSGCNT 395
NAME CUL_HOERMANN_40dae50000
NR 4616
STATE Defined
TYPE CUL_HOERMANN
Readings
state toggle 2017-11-26 12:16:32
Interessant ist, dass die devices trotz datatype=r(wie Revolt) als Hoermann(datatype=R) angelegt wurden. Reopen des CUL u. disconnect schafften keine Abhilfe. Mit einem shutdown/restart war der Spuk vorbei.

Nicht wirklich schlimm, aber ich wüßte gerne, warum und wo plötzlich der datatype=r als "R" interpretiert wurde.

Einziger (kaum vorstellbarer)Gedanke, was der Auslöser war: Der Rpi hängt per Kabel an einem WLAN-AP. Dieser ist per WLAN mit dem Router verbunden. Nachts wird das WLAN des Routers abgeschaltet u. damit die Inet-Verbindung gekappt. Um 6 wird sie wieder aktiviert u. seit 5:59:57 hatte ich Hoermann-devices 

Schönen Sonntag
Markus

[rudolfkoenig]

Ist ein Bug, mir ist noch unklar, wo genau.
Dispatch prueft bei allen geladenen Modulen gegen den Match Regexp des logischen Moduls, ob die Nachricht passt, _case insensitive_
Falls nicht gefunden wurde, dann wird gegen dem MatchList Regexp des physischen Moduls geprueft, welcher der logischen Module zu laden ist, _case sensitive_. Ich meine case insensitive fuer den ersten Fall eingefuehrt zu haben, weil FHZ und CUL die Daten mit unterschiedlichen case geliefert haben, und habe damit implizit vorausgesetzt, dass es nicht mehrere Module geben darf, deren Regexp case insensitive gleich ist.

Irgendwo muesste ich was aendern, mir sind die Konsequenzen noch nicht ganz klar.

Als Workaround koenntest du alle HOERMANN Definitionen entfernen, damit werden dann keine Neuen angelegt, es sei denn es kommen zu kurze Revolt-Daten.

[KölnSolar]

Hi Rudi,
dank Dir für die Antwort. Grundsätzlich funktioniert es ja einwandfrei. Irgendein "Ereignis" muss zu der Änderung geführt haben, also
generell case sensitive --> Ereignis --> generell case insensitive

Als Workaround koenntest du alle HOERMANN Definitionen entfernen, damit werden dann keine Neuen angelegt, es sei denn es kommen zu kurze Revolt-Daten.

Kein Thema. War ja eh im Testsystem. Apropos kurz: case sensitivity hin od. her: Die Länge ist ja unterschiedlich zwischen Revolt u. Hoermann. Wieso wurde dann auf Hoermann gematcht ?

[rudolfkoenig]

Aus 18_CUL_HOERMANN.pm:

Code Auswählen Erweitern

  $hash->{Match}     = "^R..........";
Es wird also nur geprueft, dass es mit R anfaengt, und mind. 10 Zeichen kommen.
Habs jetzt geaendert in

Code Auswählen Erweitern

  $hash->{Match}     = "^R..........\$";