Mehrere Cub als CUL geflasht im Parallelbetrieb??

[sledge]

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.

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[zweiundzwanzig]

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:

Code Auswählen Erweitern


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.

[sledge]

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