[erledigt] VCCU und HM-MOD-UART-RPI mit USR-TCP232-T2

[tndx]

Hallo zusammen,

ich habe das Funkmodul HM-MOD-UART-RPI mit einem USR-TCP232-T2 endlich erfolgreich eingebunden. Doch leider scheint es nicht so reibungslos, wie gehofft, zu funktionieren. Ich habe seit eh und je eine VCCU am laufen, bis jetzt mit einem CUL mit TSCUL-Firmware als IO-Device. Den CUL habe ich nun per Konfiguration deaktiviert (ungültige ID vergeben), das RPI-Modul eingebunden, dann ging es auch schon los:
- myHmUARTLGW hat die HMId nicht von der VCCU übernommen. Es wurde stets die HMId von meinem Testsystem angezeigt, wo das Ding zuletzt im Einsatz war. Erst das Setzen des Attributs "HMId" hat das Problem behoben, das sollte doch nicht notwendig sein?!
- Ich konnte erst keinen einzigen HM-Aktor schalten, bis ich manuell das Attribut "IODev" von "nanoCUL" auf "myHmUARTLGW" geändert habe, doch das sollte doch die VCCU übernehmen, oder? (1)
- Erst nach (1) sind dann die Einträge "HMUARTLGW myHmUARTLGW Adding peer 123456 failed! You have probably forced an unknown aesKey for this device." Doch auch die AES-Keys sollten doch automatisch von der VCCU bekannt gemacht werden?!
- Leider habe ich hier immer noch einen Sensor (HM-SEC-RHS, original, kein Nachbau), der immer noch nicht vernünftig funktioniert:

Code Auswählen Erweitern

2018-04-30_21:59:28 Kueche_Fenster_links aesCommToDev: fail
2018-04-30_21:59:28 Kueche_Fenster_links trig_aes_VCCU: fail:45
Laut Log war die letzte AES-Kommunikation (vor meinem heutigen IO-Devicetausch) am 22.04:

Code Auswählen Erweitern

2018-04-22_15:56:11 Kueche_Fenster_links aesCommToDev: ok
2018-04-22_15:56:11 Kueche_Fenster_links trig_aes_VCCU: ok:37
Seitdem habe ich definitiv nichts an der AES-Konfiguration geändert, warum klappt es jetzt nicht? Bei der Keymatic funktioniert es dagegen, echt rätselhaft.

Ist das Problem etwa, dass der CUL mit ungültiger ID immer noch im FHEM existiert? Aber das ist nach meinem Verständnis der Use Case "ein IO-Device fällt aus, VCCU switcht auf ein anderes IO-Device um".

[frank]

poste je ein list von vccu und hmuart.
was zeigt "get hminfo param -d IODev IOgrp"?

[tndx]

VCCU:

Code Auswählen Erweitern

entfernt

myHmUARTLGW:

Code Auswählen Erweitern

entfernt

gekürzte Fassung:

Code Auswählen Erweitern

entfernt

Die Frage wäre auch, wenn ich jetzt den Testbetrieb wieder beenden und vorerst wieder zum CUL als IO-Device zurückkehren will: wie stelle ich das am saubersten an?

[frank]

Die Frage wäre auch, wenn ich jetzt den Testbetrieb wieder beenden und vorerst wieder zum CUL als IO-Device zurückkehren will: wie stelle ich das am saubersten an?

ich würde erst einmal beide io der vccu zuordnen, mit attr IOList. dann kannst du über das attr IOgrp im jeweiligen device ein prefered io setzen, das bevorzugt genommen wird, sofern es verfügbar ist.

attr iogrp fehlt zb bei 3 devices. ausserdem hast du den cul häufig als prefered io gesetzt, obwohl er der vccu nicht zugeordnet ist. wer weiss schon, was dann passiert.

[frank]

eventuell stimmt in deiner fhem.cfg die reihenfolge der definitionen nicht.
erst die io, dann die vccu danach die devices.
wenn der hmuart ganz unten steht, wird wahrscheinlich die hmid nicht automatisch gesetzt.
in fhem.log könnten hinweise bei fhem restart auftauchen.

[tndx]

CUL hatte ich ja aus IOList gelöscht, nachdem es nicht funktionieren wollte. Aber hier hätte ich erwartet, dass die VCCU erst recht korrigierend eingreift.

Der Wechsel zurück auf CUL ging im übrigen problemlos, die ID des CUL korrigiert, in die IOList aufgenommen, den HMUARTLGW deaktiviert und schon ging es.

Ich werde bei nächster Gelegenheit mit der Reihenfolge der Definitionen rumspielen, obwohl ich erwarten würde, dass wenn ich die fhem.cfg nicht direkt editiere, die Reihenfolge entweder richtig oder egal ist.

Danke für Deine Unterstützung!