[Gelöst] Kollision bei FHT zwischen CUL und RFR

[td]

Hallo,

ich habe das Problem, daß mein RFR (definiert mit RFR-Code 0301, daher der Name RFR0301) das Senden von Paketen meiner eigentlichen CUL (RFR-Code 0100) unterbindet. Das FHT läßt sich auslesen, als IODev ist dort die CUL definiert, als LASTInputDev wird aber immer RFR0301 gesetzt.

Ein Befehl, z. B. das Setzen von desired-temp erzeugt im CUL-Puffer den richtigen Befehl (get CUL raw T02 -> CUL raw => 1018:4113); FHT-ID ist tatsächlich 1018. Dieser wird allerdings nicht gesendet. Mache ich die RFR0301 stromlos, kann die CUL korrekt zum FHT senden.

Irgendwie versucht fhem zwanghaft die FHT-Befehle per RFR0301 zu versenden.

Kann bitte jemand helfen?

Gruß
td

[rudolfkoenig]

Vermutlich hat das RFR die gleiche FHT-ID wie das CUL.

[td]

Hallo Rudolf,

aua aua, tatsächlich:

fhem> get CUL raw T01
CUL raw => 1010
fhem> get RFR0301 raw T01
RFR0301 raw => 1010

also:
fhem> set RFR0301 raw T011030
fhem> get RFR0301 raw T01
RFR0301 raw => 1030

aber: Keine Änderung. Auch nicht nach Stromlosmachen von RFR0301 und Rücksetzen CUL mittels "set CUL raw B00".
Ein erneutes Senden eines FHT-Kommandos ergibt wieder:
fhem> get CUL raw T02
CUL raw => 1018:410B
und wird nicht abgearbeitet.
Auch ein Durchstarten von fhem ergibt keine Änderung. Nach dem Empfangen der ersten Informationen bei fhem seitens des FHT wird wieder RFR0301 als LASTInputDev angezeigt.

Ideen? Ahnungen?

Gruß
td

[td]

Das Spiel geht weiter:
RFR0301 habe ich an USB angeschlossen und per "set CUL raw e" komplett zurückgesetzt, die RFR-uid 0301 und die FHT-ID 1030 neu zugewiesen -> Keine Änderung.

Ich besitze noch eine weitere CUL, die nun als RFR0201, uid-RFR 0201, FHT-ID 1020 definiert ist. Es gibt kein Problem bzgl. der Einbindung in fhem.

Insgesamt sind bei mir im Haus 3 FHT im Einsatz; alle explizit mit der CUL als IODev definiert. Zwei besitzen nun LastInputDev RFR0201, eines RFR0301. Dieses wie gehabt mit den bekannten Problem, daß die CUL Ihre Pakete, unabhängig vom FHT, nicht mehr abarbeitet.

Mit Bitte um Unterstützung.

td

[rudolfkoenig]

Wenn ein RFR kein FHT bedienen soll, dann bitte es mit 0000 als FHTid definieren.
Ein FHT (oder CUL) kann auch dann lastiodev sein, wenn es nicht mit dem FHT gepaart ist, und nur passiv lauscht.

[td]

Hallo Rudi,

natürlich funktioniert es so, wie du beschrieben hast. Die FHT-ID der RFR muß auf "0000" gesetzt werden.

So etwas Dämliches, aber hinterher ist ja alles so logisch!

Danke und Gruß!
td