CUL_MAX mit zwei umgeflashten Cubes

Begonnen von Nuems, 22 August 2022, 19:39:08

Vorheriges Thema - Nächstes Thema

Nuems

Nach längerem Zögern habe ich mich entschlossen, auf CUL_MAX umzusteigen - insbesondere, weil man den Cube mittlerweile für weniger als €30 bekommt. Die Möglichkeit, mit mehreren CUNs die Reichweite zu vergrößern war dabei ein wichtiger Aspekt, denn bisher gab es mit der Original-FW auf dem Cube nicht in allen Zimmern immer eine zuverlässige Abdeckung.
Das Flashen habe ich hinbekommen und ich habe zwei umgeflashte Cubes im LAN, die ich auch in FHEM eingerichtet habe. Die Migration habe ich nach diesem Post erledigt, auch das hat geklappt, d.h., CUL_MAX ist definiert und bei allen MAX-Geräten als IODev hinterlegt. Nun stehe ich aber etwas auf dem Schlauch: Muss ich noch etwas tun, damit beide CUNs Nachrichten übermitteln?

Nuems

Ich gebe mir mal selbst eine vorläufige Antwort: Es scheint so zu sein, dass eine IOGrp sinnvoll wäre, insbesondere, wenn ich noch auf die Beta-Versionen der MAX-Module umsteigen möchte. Daraus ergibt sich eine neue Frage:
Habe ich es richtig verstanden, dass ich in einer IOGrp festlegen kann/muss, welcher CUN mit welchem MAX-Gerät spricht; in der Empfangsrichtung (MAX-Gerät sendet, CUN empfängt) aber beide CUNs lauschen und einfach der zum Zuge kommt, der zuerst etwas hört?

Wzut

Zitat von: Nuems am 23 August 2022, 16:01:16
Es scheint so zu sein, dass eine IOGrp sinnvoll wäre
ja kann man so sagen , immer sinnvoll wenn mehr als ein CUL vorhanden ist.
Aber ACHTUNG :
Multi IO läuft nur vernünftig mit den Beta Modulen !!!


Zitat von: Nuems am 23 August 2022, 16:01:16
Habe ich es richtig verstanden, dass ich in einer IOGrp festlegen kann/muss, welcher CUN mit welchem MAX-Gerät spricht
Nein das hast du leider nicht verstanden.
Jeder CUL empfängt selbstständig und gibt die Nachricht an das betroffene MAX Device weiter.
Wichtig ist das Thema Rückantwort bzw. FHEM soll an ein Device senden, hier sollte dann der "bessere" CUL am jeweiligen MAX Device mit dem Attribut CULdev festgelegt werden.
Wer der bessere ist steht in den Readings, Beispiel bei mir mit drei Empängern  :
2022-08-25 13:30:59   CUL1st          Keller_CUL -65.5
     2022-08-25 13:30:59   CUL2nd          Maple1 -72.9
     2022-08-25 13:30:59   CUL3rd          Cul433 -95.6

wie man sieht ist der  Keller_CUL mit seinem RSSI von -65.5 der beste Partner für dieses HT


Bei Verwendung von mehr als einem CUL solltest du ausserdem noch bei jedem CUL Device das Attribut maxid auf den gleichen Wert setzen wie beim CUL_MAX Device.   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Nuems

Vielen Dank, dann werde ich mal die entsprechenden Anpassungen vornehmen. Der Einsatz der Beta-Module ist in Planung, aber ich wollte die Migration von Cube auf CUN, den Einsatz des zweiten CUNs und die Nutzung der Beta-Module schrittweise durchführen, um eventuelle Probleme besser eingrenzen zu können.

Wzut

Zitat von: Nuems am 25 August 2022, 15:48:00
ich wollte die Migration von Cube auf CUN, den Einsatz des zweiten CUNs und die Nutzung der Beta-Module schrittweise durchführen
dann mach es in der Reihenfolge
1. ein Cube als CUL
2. Beta Module nutzen
3. zweiten CUL dazu nehmen und beim CUL_MAX Device die IOgrp setzen
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher