HM-SEC-SD-2 zum verrückt werden :-(

[frank]

batterie devices legen sich immer schlafen und müssen also geweckt werden.

manche, auch rm, unterstützen burstmode. dann halten sie keinen tiefschlaf, sondern "dösen" nur und lauschen auf burst messages, um dadurch geweckt zu werden.
haben diese rm nicht sogar einen "speziellen" burstmode? vielleicht unterstützt dein cul das nicht.

[andre070]

Geschafft!!!!!!!!!!

Also, alles noch mal auf 0, dann den virtuellen Teamlead angelegt. VCCU so gelassen, war ja nach der Neueinrichtung ok.
Dann den 1. RM neu angelernt, nachdem auch der resettet wurde. Das klappte auf Anhieb.

Schön zu sehen das

PairedTo
R-pairCentral

sofort richtig gesetzt wurden. Dann ins Team aufgenommen und ein wenig getestet. Alles ok. Teamcall funktioniert, on / off ebenso. Der wichtige Log Eintrag erfolgt jetzt auch. SUPER!!!


ABER:

Kommen wir zum 2. RM. exakt gleiches vorgehen, aber das Pairing klappte nicht sauber, mal war PairedTo gesetzt, aber nicht
R-pairCentral. Noch mal und noch mal probiert..klappte nicht. RM auf set unpair gesetzt. Fhem shutdown restart, dann noch mal das Pairing. Endlich..beide Werte wurden gesetzt!!!!

Jetzt funktioniert es so wie es soll. get hminfo gibt auch keine Fehler mehr aus.


Meine Anfangsproblematik beruht scheinbar darauf, das ich bisher glaubte, wenn ein getconfig ist erfolgreich, die Kommunikation und das Erkennen abgeschlossen ist. Dem ist aber wohl nicht so. Das es Anfangs nicht ging, liegt sicher genau da dran, das entweder einer oder beide RMs nicht 100% gepaired waren.

Puhh..so, nun weiss ich einfch das diese RM "Zicken" sind beim pairen. Ist das erfolgreich, ist der Rest "wie gewohnt".

Dennoch vielen Dank an ale Beteiligten im Thread, denn ohne den Hinweis auf Pairing, hätte ich so genau da gar nicht drauf geschaut!!

Noch einmal: DANKE !!


   

[amenomade]

einer oder beide RMs nicht 100% gepaired waren.

Vom Anfang an gesagt