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:
----------------- -----------------
|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)
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
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
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.
Hallo rudolf,
danke für deine schnelle Antwort!
Zitat von: rudolfkoenig am 20 Oktober 2021, 19:16:33
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?
Zitat von: rudolfkoenig am 20 Oktober 2021, 19:16:33
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
ZitatWird 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
Wetter
Sensoren.
ZitatSollte 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 :)
ZitatDas 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.