Hi,
in meiner bisherigen Installation hatte ich zwei "normale" Max-Cubes, um funktechnisch das Haus abzudecken - das hat an sich auch gut funktioniert, lediglich alle zwei bis drei Wochen musste ich die Teile stromlos machen, damit wieder alles ging.
Also habe ich heute beide Geräte umgeflasht als CUL (V: 1.23.04 a-culfw). Soweit so gut - beide Geräte sind einfandfrei in FHEM angelegt.
Anscheinend laufe ich in das gleiche Problem wie hier durch zweinundzwanzig bereits beschrieben: https://forum.fhem.de/index.php/topic,60009.msg513543.html#msg513543 (https://forum.fhem.de/index.php/topic,60009.msg513543.html#msg513543).
Die Option, die CULs soweit voneinander zu entfernen, dass diese sich nicht sehen, habe ich leider nicht.
Was mich wundert: Es sendet immer nur der eine CUL - der andere greift nicht wirklich ins Geschehen ein. Hier mal die Defines / List:
Internals:
CFGFN
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:
DEF 192.168.0.53:2323 0000
DeviceName 192.168.0.53:2323
FD 24
FHTID 0000
FZ.ELW.CUL_MSGCNT 174
FZ.ELW.CUL_TIME 2016-12-17 18:30:25
NAME FZ.ELW.CUL
NR 177
PARTIAL
RAWMSG Z0CFD04421365410000000024B527
RSSI -54.5
STATE Initialized
TYPE CUL
VERSION V 1.23.04 a-culfw Build: 127 (2016-12-16_23-39-31) CUBe (F-Band: 868MHz)
initString X21
Zr
Matchlist:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
Readings:
2016-12-17 18:16:49 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2016-12-17 18:08:14 cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
2016-12-17 18:16:54 credit10ms 900
2016-12-17 18:30:25 state Initialized
2016-12-17 17:58:29 uptime 0 00:07:51
2016-12-17 17:58:22 version V 1.23.04 a-culfw Build: 127 (2016-12-16_23-39-31) CUBe (F-Band: 868MHz)
Attributes:
addvaltrigger 1
rfmode MAX
room MAX
Und der hier der zweite
Internals:
CFGFN
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:
DEF 192.168.0.52:2323 0000
DeviceName 192.168.0.52:2323
FD 22
FHTID 0000
NAME WZ.EG.CUL
NR 174
NR_CMD_LAST_H 18
PARTIAL
RAWMSG Z0CFB0442136C9E0000000028C11E
RSSI -59
STATE Initialized
TYPE CUL
VERSION V 1.23.04 a-culfw Build: 127 (2016-12-16_23-39-31) CUBe (F-Band: 868MHz)
WZ.EG.CUL_MSGCNT 144
WZ.EG.CUL_TIME 2016-12-17 18:31:12
initString X21
Zr
Za123456
Zw111111
Matchlist:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
Readings:
2016-12-17 17:32:33 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2016-12-17 18:08:13 cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
2016-12-17 18:30:12 credit10ms 403
2016-12-17 18:31:12 state Initialized
2016-12-17 16:32:22 uptime 0 02:09:49
XMIT_TIME:
1481994493.57236
1481994493.87324
1481994525.43826
1481994531.96524
1481994538.49429
1481994545.01961
1481994546.54056
1481994548.06377
1481994565.38891
1481994997.81123
1481995004.33841
1481995010.8652
1481995017.39212
1481995035.49646
1481995065.0055
1481995177.51797
1481995298.67775
1481995411.20772
Attributes:
addvaltrigger 1
rfmode MAX
room MAX
Letzerer sendet auch - der erste anscheinend nicht...
Hier noch das lsit des CULMAX:
Internals:
CFGFN
DEF 123456
FZ.ELW.CUL_MSGCNT 184
FZ.ELW.CUL_RAWMSG Z0C14044213658B0000000026D1
FZ.ELW.CUL_RSSI -84
FZ.ELW.CUL_TIME 2016-12-17 18:31:59
IODev WZ.EG.CUL
LASTInputDev FZ.ELW.CUL
MSGCNT 187
NAME CULMAX0
NR 175
STATE Defined
TYPE CUL_MAX
WZ.EG.CUL_MSGCNT 147
WZ.EG.CUL_RAWMSG Z0C14044213658B0000000026D1
WZ.EG.CUL_RSSI -62.5
WZ.EG.CUL_TIME 2016-12-17 18:31:59
addr 123456
cnt 0
pairmode 0
retryCount 0
Readings:
2016-12-17 18:17:00 packetsLost 13
sendQueue:
Attributes:
IODev WZ.EG.CUL
room CUL_MAX,MAX
verbose 1
Bin für jeden Tip dankbar.
Gruß,
Tom
Der Cube sendet ja auch nur, wenn das device, das angesprochen wird das zu dem Cube gehörende CULMAX als attr IODev angegeben hat. Das CULAX wiederum bekommt als attr IODev den jeweiligen Cube angegeben.
Beispiel:
define CUBe_1 CUL 192.168.100.1:2323 0000
attr CUBe_1 rfmode MAX
define CUBe_2 CUL 192.168.100.2:2323 0000
attr CUBe_2 rfmode MAX
define CULMAX_1 CUL_MAX 123456
attr CULMAX_1 IODev CUBe_1
define CULMAX_2 CUL_MAX 654321
attr CULMAX_2 IODev CUBe_2
define MAX_1 MAX HeatingThermostatPlus fffff1
attr MAX_1 IODev CULMAX_1
define MAX_2 MAX HeatingThermostatPlus fffff2
attr MAX_2 IODev CULMAX_2
So wird das MAX_1 über den Cube_1 und as MAX_2 über den Cube_2 gesteuert. Empfangen tun alle Cubes immer alles on alled devices. Das ist egal.
Hi,
super Hinweis - den habe ich mittlerweile auch in dem englisch-sprachigen Thread gefunden. Zuerst hatte ich mit sendpool rumprobiert, aber hier habe ich - ähnlich wie bei den Cubes - wieder eine 1:n Zuteilung. Das Beide CULs lauschen ist ok für mich.
Danke für den Hinweis.
Jetzt also nur alle Wandthermostate neu anlernen, die am falschen Backend gelandet sind ;-)