MAX! mit 2x CUL's

[Edi77]

Hallo,

Ich habe einige Reichweitenprobleme und es kommt immer mehr zu Error, je mehr Thermostate ich montiere, das sieht man auch an der RSSI sind einige > -85 oder sogar >-90
Daher habe ich mir überlegt statt ein CUNO noch einen 2ten CUNO zu installieren.
Man kann ja in FHEM sagen ob der Thermostat von CUNO1 oder CUNO2 gesteuert wird, aber wie kann ich verhindern das ein Thermostat von beiden CUNOs gefunden wird?
Oder macht das keine Probleme?

[Wzut]

Man kann ja in FHEM sagen ob der Thermostat von CUNO1 oder CUNO2 gesteuert wird,

Falsch , denn das IODev an den MAX Geräten ist eben nicht wie z.B. bei HM direkt die Hardware sondern das logische CULMAX Device !
Und erst das CULMAX device selbst hat als IODevice den CUL, CUNO, etc.
D.h du kannst bei deinen Hardware Geräten ( CUL und seine Brüder) zwar mit dem Attribut sendpool arbeiten und sicherstellen das es keinen doppelten Empfang gibt,
aber beim senden bist du aufgeschmissen da eben nicht der Pool das Ziel ist sondern CULMAX. Such mal hier ein bischen, ich habe da schon einiges zu geschrieben und auch Lehrgeld gezahlt. Fazit : durch diesen Desgin Fehler der MAX! Module ist MAX eigentlich nur was Wohnungbesitzer, geht es aber um ein ganzes Haus dann hilft nur ein Wechsel zu einem "besseren" System wie z.B. HM oder die Aufteilung des Hauses in mehere Wohnungen - sprich mehr als ein CULMAX Device und damit verbunden verschiedene IDs.

[Edi77]

Meine jetzige Anbindung sieht im Moment so aus.
Ein alter RPi 1 mit COC mit ser2net zu meinem VM FHEM Server als CUL_MAX eingebunden.
Wenn ich jetzt den MAX Cube eine culfw installiere könnte ich den als MAXLAN mit einer anderen ID einbinden, und somit wäre das Problem gelöst?

[Edi77]

Ich glaub da habe ich einen Denkfehler den wenn ich den MAX Cube ein culfw installiere kann ich ihn ja nicht mit MAXLAN einbinden sondern das geht dann ja auch nur mit CUL_MAX?
Und wenn ich die culfw installiert habe, kann ich ja nicht mehr zurück zur Original Firmware, daher wollte ich das vorher geklärt haben bevor ich die culfw installiere.

Wenn ich jetzt den COC als CUL_MAX (ID 123456) und den MAX Cube (ID654321) als 2 verschiedene Device einbinde und die jeweiligen Geräte im Empfangsbereich anlerne sollte das doch gehen?

Oder unterstützt CUL_MAX nur ein Device und ich benötige dann eine 2te FHEM Installation?

[Wzut]

ja klar wenn du den Cube umflashst kommt CUL_MAX zum Einsatz !
Früher durfte nur ein CULMAX Device pro FHEM Instanz angelegt werden, das hatte dann aber M. Gehre als er noch aktiv war auf mein Bitten hin geändert, so das das heute kein Problem mehr sein sollte

[Edi77]

Danke Wzut für die schnelle Antwort, dann werde ich das diese Woche mal machen und hier berichten.

[Edi77]

Ich habe jetzt den COC und MAXCube auch noch auf 3600/1H geflasht statt den 900/15Min was auch einige Probleme löst.

Einige Devices liegen im Empfangsbereich beider CUL's

CULMAX0 = COC
CULMAX1 = Cube

Kann es da zu Probleme kommen?

Code Auswählen Erweitern


CULMAX0_MSGCNT

1
CULMAX0_TIME

2018-01-20 18:26:57
DEF
HeatingThermostat 1581cc
IODev

CULMAX1
LASTInputDev

CULMAX0
MSGCNT

1
NAME

MAX_Bad_oben_Handtuch_HZK
NR

1982
RSSI

-53.5
STATE

23.5 °C
TYPE

MAX
addr

1581cc
dstsetting

1
mode

1
rferror

0
type

HeatingThermostat


[Edi77]

Hallo,

Beide CULs laufen. Auf dem COC sind noch 25 Thermostate & Kontakte und auf dem Cube sind schon 2 - 3 Thermostate zum testen.
Ab 15:57 begann etwas die ganzen credits aufzubrauchen

Code Auswählen Erweitern


2018.01.25 15:59:44 5: MAXCOC sending Zs0f1104031234566543210012190f3b6c
2018.01.25 15:59:44 5: SW: Zs0f1104031234566543210012190f3b6c
2018.01.25 15:59:45 5: CUL/RAW: /Z0F1104031234566543210012190F3B6CFD

2018.01.25 15:59:45 4: CUL_Parse: CubeMAX Z0F1104031234566543210012190F3B6CFD -75.5
2018.01.25 15:59:45 5: CubeMAX: dispatch Z0F1104031234566543210012190F3B6C
2018.01.25 15:59:45 5: CUL_MAX_Parse: len 15, msgcnt 11, msgflag 04, msgTypeRaw TimeInformation, src 123456, dst 654321, groupid 0, payload 12190F3B6C
2018.01.25 15:59:45 5: CUL_MAX_Parse: rssi: -75.5
2018.01.25 15:59:45 5: Got request for TimeInformation, sending it
2018.01.25 15:59:47 5: SW: X
2018.01.25 15:59:47 5: CUL/RAW (ReadAnswer): 21  931

2018.01.25 15:59:47 5: CubeMAX sending Zs0f3504036543211234560012190f3b6f
2018.01.25 15:59:47 5: SW: Zs0f3504036543211234560012190f3b6f
2018.01.25 15:59:48 5: CUL/RAW: /Z0F35040
2018.01.25 15:59:48 5: CUL/RAW: Z0F35040/36543211
2018.01.25 15:59:48 5: CUL/RAW: Z0F3504036543211/23456001
2018.01.25 15:59:48 5: CUL/RAW: Z0F350403654321123456001/2190F3B6
2018.01.25 15:59:48 5: CUL/RAW: Z0F3504036543211234560012190F3B6/F04

2018.01.25 15:59:48 4: CUL_Parse: MAXCOC Z0F3504036543211234560012190F3B6F04 -72
2018.01.25 15:59:48 5: MAXCOC: dispatch Z0F3504036543211234560012190F3B6F
2018.01.25 15:59:48 5: CUL_MAX_Parse: len 15, msgcnt 35, msgflag 04, msgTypeRaw TimeInformation, src 654321, dst 123456, groupid 0, payload 12190F3B6F
2018.01.25 15:59:48 5: CUL_MAX_Parse: rssi: -72
2018.01.25 15:59:48 5: Got request for TimeInformation, sending it
2018.01.25 15:59:50 5: SW: X
2018.01.25 15:59:50 5: CUL/RAW (ReadAnswer): 21  711
2018.01.25 15:59:50 5: CUL/RAW (ReadAnswer):

2018.01.25 15:59:50 5: MAXCOC sending Zs0f1104031234566543210012190f3b72
2018.01.25 15:59:50 5: SW: Zs0f1104031234566543210012190f3b72
2018.01.25 15:59:52 5: CUL/RAW: /Z0F1104031234566543210012190F3B72FD

2018.01.25 15:59:52 4: CUL_Parse: CubeMAX Z0F1104031234566543210012190F3B72FD -75.5
2018.01.25 15:59:52 5: CubeMAX: dispatch Z0F1104031234566543210012190F3B72
2018.01.25 15:59:52 5: CUL_MAX_Parse: len 15, msgcnt 11, msgflag 04, msgTypeRaw TimeInformation, src 123456, dst 654321, groupid 0, payload 12190F3B72
2018.01.25 15:59:52 5: CUL_MAX_Parse: rssi: -75.5
2018.01.25 15:59:52 5: Got request for TimeInformation, sending it
2018.01.25 15:59:53 5: SW: X
2018.01.25 15:59:53 5: CUL/RAW (ReadAnswer): 21  826

2018.01.25 15:59:53 5: CubeMAX sending Zs0f3504036543211234560012190f3b75
2018.01.25 15:59:53 5: SW: Zs0f3504036543211234560012190f3b75
2018.01.25 15:59:53 2: CUL_MAX_SendQueueHandler: Missing ack from 654321 for 0f1104031234566543210012190f3b72
2018.01.25 15:59:53 5: SW: X
2018.01.25 15:59:53 5: CUL/RAW (ReadAnswer): 21  601
2018.01.25 15:59:53 5: CUL/RAW (ReadAnswer):

2018.01.25 15:59:53 5: MAXCOC sending Zs0f1204031234566543210012190f3b75
2018.01.25 15:59:53 5: SW: Zs0f1204031234566543210012190f3b75
2018.01.25 15:59:55 5: CUL/RAW: /Z0F1204031234566543210012190F3B75FD

2018.01.25 15:59:55 4: CUL_Parse: CubeMAX Z0F1204031234566543210012190F3B75FD -75.5
2018.01.25 15:59:55 5: CubeMAX: dispatch Z0F1204031234566543210012190F3B75
2018.01.25 15:59:55 5: CUL_MAX_Parse: len 15, msgcnt 12, msgflag 04, msgTypeRaw TimeInformation, src 123456, dst 654321, groupid 0, payload 12190F3B75
2018.01.25 15:59:55 5: CUL_MAX_Parse: rssi: -75.5
2018.01.25 15:59:55 5: Got request for TimeInformation, sending it
2018.01.25 15:59:56 2: ESPEasy ESPBridge83_192.168.1.87_30277: WARNING: value name or value is missing (192.168.1.87). Skip processing this value.
2018.01.25 15:59:56 2: ESPEasy ESPBridge83_192.168.1.87_30277: Data: {"module":"ESPEasy","version":"1.04","data":{"ESP":{"name":"ESP87","unit":8,"version":2,"build":20000,"build_notes":" - Mega","build_git":"v2.0.0-dev11","node_type_id":17,"sleep":0,"ip":"192.168.1.87"},"SENSOR":{"0":{"deviceName":"load","valueName":"","type":1,"value":"11"}}}}
2018.01.25 15:59:59 5: SW: X
2018.01.25 15:59:59 5: CUL/RAW (ReadAnswer): 21  720

2018.01.25 15:59:59 5: CubeMAX sending Zs0f3504036543211234560012190f3b7b
2018.01.25 15:59:59 5: SW: Zs0f3504036543211234560012190f3b7b
..................


Nach wenigen Minuten waren die Credits aufgebraucht.
Was ist hier die Ursache ?

Kann es sein das die beiden CUL versuchen sich gegenseitig die Zeit zu synchronisieren?

[Edi77]

Ich habe jetzt mal den Cube abgeschaltet und die Probleme tauchen nicht mehr auf.
Interessant dabei war noch wenn beide CULs an sind wir ein Device erstellt mit b.z. MAX_123456 und MAX_654321 das ein Wandthermostat sein soll.
Dieses Device existiert aber nicht, entspricht aber genau der 6 stelligen ID die ich den beiden CULs gegeben habe.

Wie passt das jetzt zusammen???

Dürfen sich die beiden CULs nicht gegenseitig sehen, also außerhalb des Empfangsbereich?

[Wzut]

es kann schon sein das du mit zwei Cubes/CULs in ein Zeit Sync Problem läufst , frage doch dazu mal bei den Gurus nach die das Thema aktuell diskutieren -> https://forum.fhem.de/index.php/topic,11148.0.html
Ich hatte damals auch das problem das der eine den anderen sieht und als WT anlegt. Ändere doch die Definition von WallMountedThermostat auf ShutterContact ( die bekommen doch keine Zeittelegramme ? ) und setze zusätzlich noch das Attribut ignore auf 1