Device einen CUL zuordnen oder ignorieren

[VC45]

Hallo zusammen!

Ich habe einen etwas "speziellen" Systemaufbau und habe ein Problem das ich nicht gelöst bekomme.

Ein grober Auszug meines Aufbaus für 433MHz-Geräte:

Code: [Auswählen]


----------------- -----------------
|myCUL_433 | |Temp-Fühler |
|CUL433MHz |O O O O|433MHz         |
|Home | |Home |
----------------- -----------------
()
()USB
()
----------------- ----------------- -----------------
|192.168.1.x | |192.168.1.x |        VPN <--->20km         |192.168.2.x |
|FHEM Server |-------|Fritz!Box |ooooooooooooooooooooooooooooooooooooooo|Fritz!Box |
|Home |  Eth |Home | INET |Extern |
----------------- ----------------- -----------------
| |
|Eth |Eth
| |
----------------- -----------------
----------------- |192.168.1.x | |192.168.2.x | -----------------
|Fernbedienung | |myCUL_NW1_1 |       |myCUL_NW3_1 | |Fernbedienung |
|Std1 - 433MHz |O O O O|CUNO433MHz | |CUNO433MHz |O O O O|433MHz         |
|Home | |Home | |Extern | |Nachbar |
----------------- ----------------- ----------------- -----------------
O O
O O
O O
----------------- -----------------
|Std1    |       |Temp-Fühler |
|433MHz | |433MHz |
|Home | |Extern |
----------------- -----------------

Mein Problem ist nun folgendes, ein Nachbar im Bereich vom Externen-Systemteil schaltet mit seiner FB die Steckdose (Std1) im Home-Systemteil, da scheinbar der gleiche CODE bzw. Hersteller der Funksteckdose verwendet wird. Leider kann bei meinen Funksteckdosen vom Typ Conecto kein Hauscode eingestellt werden, sondern nur die Nummer. Alle 4 Steckdosen verwende ich und werden von FHEM oder meiner FB geschalten.

Die Steckdosen reagieren auf alle im System eingebundenen CUL433MHz/SlowRF, egal welcher CUL433 im Attribut IODev festgelegt ist.
Diese Reaktion von FHEM ist sonst eine völlig normale (und sicher gewollte), wenn mehrere CUL433 vorhanden sind.

Vielleicht wäre es möglich, das Attribut "ignor" soweit aufzubohren, das es nicht nur "0" oder "1" sondern das auch ein oder mehrere IODevice ignoriert werden können.
Oder ein Attribut, welches eine Rückfalleben zu nicht in IODev ausgewählter CULs sperrt oder freigibt.
Interessant wäre auch eine ähnliche Zuordnung wie @Wzut im Module: 10_MAX.pm mit dem Attribut "CULDev" erfolgreich eingebaut hat.

Ich vermute das so eine Implementierung sehr aufwendig und für ein(mein) Problem ein überzogener Wunsch ist.
Hat jemand einen anderen Lösungsvorschlag ohne das ich die Conecto-Steckdosen aus den Verkehr zu ziehen muss?

Hier noch ein list der betroffenen Device

list vom externen CUL(CUNO)

Code: [Auswählen]

Internals:
   CMDS       bCFiAZNEGMKLUYRTVWXfz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT::SD_WS07:
   DEF        myCUL_NW3
   FUUID      61426264-f33f-4103-c1c5-c1cccf25b7655062
   IODev      myCUL_NW3
   NAME       myCUL_NW3_1
   NOTIFYDEV  myCUL_NW3
   NR         468
   NTFY_ORDER 50-myCUL_NW3_1
   PARTIAL   
   RAWMSG     omAAAAAAAAAAA02F
   RSSI       -50.5
   STATE      Initialized
   StackLevel 1
   TYPE       STACKABLE_CC
   VERSION    V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBEx4_83 (F-Band: 433MHz)
   initString X21
   myCUL_NW3_1_MSGCNT 9611
   myCUL_NW3_1_TIME 2021-10-20 18:12:13
   MatchList:
     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................................$
     C:SD_WS07  ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}
     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 ^\*
   OLDREADINGS:
   READINGS:
     2021-10-15 15:52:38   ccconf          freq:433.910MHz bWidth:812KHz rAmpl:42dB sens:4dB
     2021-10-15 22:57:14   cmds             b C F i A Z N E G M K L U Y R T V W X f z
     2021-10-20 18:12:13   state           Initialized
Attributes:
   group      CUL
   model      CUNO
   rfmode     SlowRF
   room       System

list der Std1

Code: [Auswählen]

Internals:
   DEF        000FF0F0FF FF F0
   FUUID      5f99cf85-f33f-4103-7d0a-106e674b480940aa
   IODev      myCUL_NW1_1
   LASTInputDev myCUL_NW3_1
   MSGCNT     27
   NAME       Std1
   NR         405
   STATE      off
   TYPE       IT
   XMIT       000ff0f0ff
   XMITdimdown 00
   XMITdimup  00
   XMIToff    f0
   XMITon     ff
   myCUL433_MSGCNT 13
   myCUL433_RAWMSG i014454
   myCUL433_RSSI -53.5
   myCUL433_TIME 2021-10-20 00:45:34
   myCUL_NW1_1_MSGCNT 15
   myCUL_NW1_1_RAWMSG i014454
   myCUL_NW1_1_RSSI -55
   myCUL_NW1_1_TIME 2021-10-20 00:45:35
   myCUL_NW3_1_MSGCNT 10
   myCUL_NW3_1_RAWMSG i014454
   myCUL_NW3_1_RSSI -64.5
   myCUL_NW3_1_TIME 2021-10-20 10:49:07
   CODE:
     1          000ff0f0ff
   READINGS:
     2021-10-15 22:56:13   IODev           myCUL_NW1_1
     2020-10-28 21:11:52   protocol        V1
     2021-10-20 10:49:07   state           off
Attributes:
   IODev      myCUL_NW1_1
   alias      STD1 Conecto LED Wz
   event-on-change-reading .*
   model      itswitch
   room       EG Wohnzimmer

MfG
VC45

[rudolfkoenig]

Das Problem muesste im IT Modul geloest werden.
Was Vergleichbares gibt es fuer CUL_WS, wo das IODev Attribut fuer diese Aufgabe zweckentfremdet wird.

Alternativ wird CUNO @ myCUL_NW3_1 mit einem Firmware ohne IT (HAS_INTERTECHNO in board.h) bestueckt.

[VC45]

Hallo rudolf,

danke für deine schnelle Antwort!

Das Problem muesste im IT Modul geloest werden.
Was Vergleichbares gibt es fuer CUL_WS, wo das IODev Attribut fuer diese Aufgabe zweckentfremdet wird.

Wird das IODev-Attribut bei CUL_WS fest zum lesen und schreiben verwendet? So ganz verstehe ich das nicht.
Sollte das Thema dann eher in die IT verschoben werden wenn Änderungen in der 10_IT.pm der Ansatz sind?

Alternativ wird CUNO @ myCUL_NW3_1 mit einem Firmware ohne IT (HAS_INTERTECHNO in board.h) bestueckt.

Mein CUNO @ myCUL_NW3_1 ist ein umgebauter MAX!-Cube, also ein CUL mir 868MHz Funk + zusätzlichen 433MHz Funkmodul und Firmware a-culfw 1.26.08 CUBEx4_BL.
Das würde ja sicher bedeuten die Firmware zu bereinigen und neu zu kompilieren?

Deine Lösungsvorschläge hören sich sehr interessant an aber übersteigen meine Fähigkeiten!

MfG
VC45

[rudolfkoenig]

Wird das IODev-Attribut bei CUL_WS fest zum lesen und schreiben verwendet?

Im klassischen FHEM-Modell hat ein Geraet beliebig viele Empfaenger, aber nur einen Sender, dieser wird mit dem IODev Reading oder Attribut festgelegt.
Das CUL_WS Modul missbraucht das IODev Attribut als Empfaenger-Identifikator. Das ist hier unproblematisch, weil hier Senden nicht vorgesehen ist, die Geraete sind WetterSensoren.

Sollte das Thema dann eher in die IT verschoben werden wenn Änderungen in der 10_IT.pm der Ansatz sind?

Ich kriege verschobene Themen nicht mit, ob der IT-Maintainer das tut, weiss ich nicht.
Und ob er gewollt ist, so eine Erweiterung in ein 10+ Jahre altes Modul einzubauen, auch nicht

Das würde ja sicher bedeuten die Firmware zu bereinigen und neu zu kompilieren?

Ja, wobei der Ausdruck "bereinigen" mAn nach nicht richtig ist, ich wuerde eher von einer geaenderten Konfiguration reden.