V3-Protokoll Geräte werden nicht ausgelesen

[brownandi]

Hi,
musste nach sehr langer Zeit meinen FHEM Server neu installieren. Bei dieser Gelegenheit habe ich meinen Culv3 Stick auch gleich auf die letzte verfügbare Version upgedated.
   
version: V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUL433 (F-Band: 433MHz)
ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB

FHEM ist auf dem aktuellsten Stand.

Mein Problem ist, dass zwar alle v1 Schalter/Steckdosen automatisch erkannt werden und funktionieren wie vorher, aber alle neueren v3-Protokoll Schalter/Steckdosen werden nicht mehr erkannt.
autocreate legt nichts an und ich sehe auch nichts im Event Monitor.

Habt ihr eine Idee, an was es liegen könnte? Bin ratlos.

Danke!

[xgadscu]

Hallo,

ich habe genau diesselbe Konstellation und suche seit Tagen danach, warum gewisse Dinge nicht mehr funktionieren. Heute habe ich mich etwas intensiver damit beschäftigt und folgendes herausgefunden:

• alle Intertechno-V3-Devices (Fernbedienungen und Steckdosen) kommunizieren nicht mehr mit FHEM. Steckdosen können nicht mehr über FHEM geschaltet werden. Fernbedienungssignale kommen in FHEM nicht an.
• Intertechno-V1-Devices funktionieren wie gehabt.

Vorher lief alles problemlos mit CUL und Cunx:
Version: V 1.23.04 a-culfw Build: 127 (2016-12-16_23-39-31) CUL433 (F-Band: 433MHz)
ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
und
Version: V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CSM433 (F-Band: 433MHz)
ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB

Ich habe in diesem Bereich wochenlang nichts verändert. Der Fehler kann eigentlich nur durch einen SW-Update hereingekommen sein.

Hat jemand eine Idee.

Gruß xgadscu

[noansi]

Hallo Rudolf,

in fhem.pl Zeile 4021 hast Du Ende Juni/Anfang Juli den match zu $hash->{MatchList} keys case insensitive gemacht.
Das führt hier zu den Problemen, denke ich.
Was war der Grund?

Gruß, Ansgar.

[noansi]

Hallo Rudolf,

in Changeset 22261 hast Du die Änderung mit case insensitve gemacht, um <NL> in Multiline Messages zu ermöglichen.

Das passt in Zeile 4021 bzw. damals 4008 aber definitiv nicht zu 00_CUL.pm, da es case sensitive matches in der matchlist hat.

Code: [Auswählen]

my %matchListSlowRF = (
    "0:FS20V"     => "^81..(04|0c)..0101a001......00[89a-f]...",
    "1:USF1000"   => "^81..(04|0c)..0101a001a5ceaa00....",
    "2:BS"        => "^81..(04|0c)..0101a001a5cf",
    "3:FS20"      => "^81..(04|0c)..0101a001",
    "4:FHT"       => "^81..(04|09|0d)..(0909a001|83098301|c409c401)..",
    "5:KS300"     => "^810d04..4027a001",
    "6:CUL_WS"    => "^K.....",
    "7:CUL_EM"    => "^E0.................\$",
    "8:HMS"       => "^810e04......a001",
    "9:CUL_FHTTK" => "^T[A-F0-9]{8}",
    "A:CUL_RFR"   => "^[0-9A-F]{4}U.",
    "B:CUL_HOERMANN"=> "^R..........",
    "C:ESA2000"   => "^S................................\$",
    "D:CUL_IR"    => "^I............",
    "E:CUL_TX"    => "^TX[A-F0-9]{10}",
    "F:Revolt"    => "^r......................\$",
    "G:IT"        => "^i......",
    "H:STACKABLE_CC"=>"^\\*",
    "I:UNIRoll"   => "^[0-9A-F]{5}(B|D|E)",
    "J:SOMFY"     => "^Y[r|t|s]:?[A-F0-9]+",
    "K:CUL_TCM97001"  => "^s[A-F0-9]+",
    "L:CUL_REDIRECT"  => "^o+",
    "M:TSSTACKED"=>"^\\*",
    "N:STACKABLE"=>"^\\*",
);

10_CUL_IR.pm hat ebenfalls einen case sensitiven Modul Match

Code: [Auswählen]

  $hash->{Match}     = "^I............";
gegenüber 10_IT.pm

Code: [Auswählen]

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

Ich denke, Quark kommt an: https://forum.fhem.de/index.php/topic,112399.msg1068228.html#msg1068228 

Mit andererer Reihenfolge in der SlowRF matchlist wäre es vermutlich erst viel später aufgefallen.

Gruß, Ansgar.

[rudolfkoenig]

Danke fuer den Hinweis.
Ich habe die Aenderung vor zwei Monaten deswegen case insensitive gemacht, um es mit der Match-Logik (was beim autocreate/load) verwendet wird, gleichzuziehen, und der ist seit 7+ Jahren so.

Ich habe jetzt bei beiden das i entfernt, bin gespannt auf neue Probleme.
Ich meine aber, dass die deswegen auftauchenden Probleme in den jeweiligen Modulen zu fixen sind, und nicht in fhem.pl.

[noansi]

Hallo Rudolf,

danke!

Ich meine aber, dass die deswegen auftauchenden Probleme in den jeweiligen Modulen zu fixen sind, und nicht in fhem.pl.

Dem stimme ich zu.

Gruß, Ansgar.

[xgadscu]

Hallo,

ich habe die aktuellen Updates eingespielt. Die IT-V3-Devices arbeiten, soweit ich dies bisher beurteilen kann, wieder normal. Es werden auch keine CUL_IR- bzw. CUN_IR-Devices mehr per autocreate angelegt.

Ab und zu taucht lediglich noch folgender Log-Eintrag auf:

Code: [Auswählen]

2020.08.20 13:33:57 2: IT IODev device didn't answer is command correctly:   raw => i5AA559A9666695550A

Dies zur Information.
Ich hatte mich ja auch in folgendem Beitrag eingeklinkt und dort weitere Details beschrieben: https://forum.fhem.de/index.php/topic,113406.msg1078230.html#msg1078230

Gruß xgadscu

[blackbite]

Danke fuer den Hinweis.
Ich habe die Aenderung vor zwei Monaten deswegen case insensitive gemacht, um es mit der Match-Logik (was beim autocreate/load) verwendet wird, gleichzuziehen, und der ist seit 7+ Jahren so.

Ich habe jetzt bei beiden das i entfernt, bin gespannt auf neue Probleme.
Ich meine aber, dass die deswegen auftauchenden Probleme in den jeweiligen Modulen zu fixen sind, und nicht in fhem.pl.

Seit der Änderung erscheinen bei mir IT-Devices, auf einmal neu im Log. Scheinbar werden die IT-Funkaktoren jetzt als komplett neue Devices erkannt, wenn diese nicht über FHEM, sondern über IT-Sender, Fernbedienungen, einem IT-Bewegungsmelder, oder in meinem Fall einem Lightmanager (JBMedia) geschaltet werden.
Schönes Beispiel im Log ist der bekannte WZ_PS_IT_AV (IT-Funksteckdose). Dieser wurde einmal von mir über FHEM ein und ausgeschaltet. Danach wurde er über eine Fernbedienung (Lightmanager) ein und ausgeschaltet und FHEM will nun eine neues Device IT_V3_cba280 mit einem völlig anderen Code haben. Ich werde aus dem Querlesen der Threads nicht wirklich schlau. Mein Config bezüglich der IT-Devices und Fernbedienungen ist seit Jahren stabil und unverändert gelaufen.

Code: [Auswählen]

2020.08.24 07:50:07 3: CUL433 IT: SZ_IT_Bett on->on
2020.08.24 07:55:07 3: CUL433: Unknown code i5996a95965569696, help me!
2020.08.24 07:56:12 3: CUL433: Unknown code i5996a95965569596, help me!
2020.08.24 07:56:13 3: CUL433: Unknown code i5996a95965569596, help me!
2020.08.24 07:56:13 3: CUL433: Unknown code i5996a95965569596, help me!
2020.08.24 07:56:14 3: CUL433: Unknown code i5996a95965569596, help me!
2020.08.24 08:20:57 3: CUL433 IT_set: WZ_PS_IT_AV on
2020.08.24 08:21:00 3: CUL433 IT_set: WZ_PS_IT_AV off
2020.08.24 08:21:28 2: CUL433 IT: IT_V3_cba280 (0000000110010111010001010000000) not defined (Address: 00000001100101110100010100 Group: 0 Unit: 0000 Switch code: 1)
2020.08.24 08:21:30 2: CUL433 IT: IT_V3_cba280 (0000000110010111010001010000000) not defined (Address: 00000001100101110100010100 Group: 0 Unit: 0000 Switch code: 0)
Meine Vermutung ist, dass das Sendende Gerät - also mein Lightmanager nun plötzlich als neues Device erstmals empfangen und erkannt wird. Ebenso wie der IT-Bewegungsmelder, dessen Schaltvorgänge plötzlich im Log auftauchen (SZ_IT_Bett on->on), was zuvor auch nie der Fall war. Also alles, was nicht direkt über FHEM geschaltet wird, scheint nun aufzutauchen...
Wenn das nun so gewollt sein sollte, muss ich dann alle diese Devices neu anlegen und ignoren?