Hallo,
habe eben meinen CUL erfolgreich in FHEM angemeldet.
Nun wollte ich per hmPairForSec 60 den Funk-Schaltaktor anlernen (also Taste am Aktor bis zum Blinken gedrückt).
Es wird auch ein CUL HM angelegt aber es scheint ein problem zu geben weil die Ausgabe wie folgt aussieht:
powerMeter
HM_2B35B1 RESPONSE TIMEOUT:RegisterRead getConfig clear msgEvents
Das sieht nicht normal aus und ich habe auch keine Möglichkeit über FHEM irgendetwas zu schalten.
Habe ich etwas falsch gemacht? Wenn ja was und wie geht es richtig?
Vielen Dank für Eure Hilfe.
Hallo TSCH,
Bin an meinem HM-Rollo-Aktor auch bald verzweifelt.
Hatte das gleiche Problem.
Bei mir hat geholfen, dass ich nach dem ich den Aktor in den Anlernmodus gebracht habe,
den Taster noch 2 mal kurz hintereinander gedrückt habe.
Vielen Dank für den Tipp. Werde ich mal testen und berichten.
Poste doch mal bitte ein list HM_2B35B1
Aber in Code tags!
Gruß Otto
Hier die gewünschte Ausgabe:
Internals:
DEF 2B35B1
IODev CUL1
NAME HM_2B35B1
NR 21
NTFY_ORDER 50-HM_2B35B1
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
Readings:
2016-07-21 17:18:28 Activity dead
2016-07-21 16:58:23 D-firmware 1.6
2016-07-21 16:58:23 D-serialNr LEQ0273082
2016-07-21 16:58:23 R-pairCentral set_0xF11234
2016-07-21 17:20:22 RegL_00.
2016-07-21 17:02:03 state RESPONSE TIMEOUT:RegisterRead
Helper:
HM_CMDNR 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +2B35B1,00,00,00
prefIO
rxt 0
vccu
p:
2B35B1
00
00
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Attributes:
IODev CUL1
autoReadReg 4_reqStatus
expert 2_raw
room CUL_HM
@pink99panther
Das war ein super Tipp! Nachdem ich eben die o.g. Ausgabe gepostet habe, dachte ich: Versuch macht kluch und siehe da, gleiche Vorgehensweise wie gestern aber ein paarmal die Taste beim Pairing gedrückt und nun kann ich schalten.
Vielen Dank.
Gibt es dafür auch eine logische Erklärung?
Jetzt liefert
list HM_2B35B1
die Ausgabe:
Internals:
CUL1_MSGCNT 52
CUL1_RAWMSG A1402845E2B35B10000008000000000000000092FFD::-47.5:CUL1
CUL1_RSSI -47.5
CUL1_TIME 2016-07-22 16:17:48
DEF 2B35B1
IODev CUL1
LASTInputDev CUL1
MSGCNT 52
NAME HM_2B35B1
NR 21
NTFY_ORDER 50-HM_2B35B1
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_2B35B1_Sw
channel_02 HM_2B35B1_Pwr
channel_03 HM_2B35B1_SenPwr
channel_04 HM_2B35B1_SenI
channel_05 HM_2B35B1_SenU
channel_06 HM_2B35B1_SenF
lastMsg No:02 - t:5E s:2B35B1 d:000000 8000000000000000092FFD
protLastRcv 2016-07-22 16:17:48
protSnd 68 last_at:2016-07-22 16:16:36
protState CMDs_done
rssi_CUL1 avg:-41 min:-41 max:-41 lst:-41 cnt:4
rssi_at_CUL1 avg:-48.47 min:-55.5 max:-44.5 lst:-47.5 cnt:52
Readings:
2016-07-22 16:12:27 Activity alive
2016-07-22 16:12:27 CommandAccepted yes
2016-07-22 16:12:27 D-firmware 1.6
2016-07-22 16:12:27 D-serialNr LEQ0273082
2016-07-22 16:12:31 PairedTo 0xF11234
2016-07-22 16:12:31 R-pairCentral 0xF11234
2016-07-22 16:12:31 RegL_00. 02:01 0A:F1 0B:12 0C:34 18:00 00:00
2016-07-22 16:12:22 recentStateType info
2016-07-22 16:16:36 state CMDs_done
Helper:
HM_CMDNR 2
cSnd 11F112342B35B10201C80000,11F112342B35B10201000000
mId 00AC
rxType 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +2B35B1,00,00,00
nextSend 1469204268.78438
prefIO
rxt 0
vccu
p:
2B35B1
00
00
00
Mrssi:
mNo 02
Io:
CUL1 -45.5
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
prs 1
Rssi:
Cul1:
avg -41
cnt 4
lst -41
max -41
min -41
At_cul1:
avg -48.4711538461538
cnt 52
lst -47.5
max -44.5
min -55.5
Shadowreg:
Attributes:
IODev CUL1
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.6
model HM-ES-PMSw1-Pl
room CUL_HM
serialNr LEQ0273082
subType powerMeter
Naja ob die Erklärung logisch ist ... 8)
Du siehst bei der zweiten Ausgabe
PairedTo 0xF11234
R-pairCentral 0xF11234
Bei deinem ersten List siehst Du:
R-pairCentral set_0xF11234
Das bedeutet das pairing war angestossen aber noch nicht fertig. Meist braucht die Übertragung aller Daten etwas. Offenbar kann es passieren, dass dabei nicht alle Daten ankommen/welche Verloren gehen.
Offenbar übertragen die Aktoren auch bloß eine bestimmte Datenmenge pro Vorgang. Manchmal wird auch bloß in FHEM nicht alles angezeigt.
Es hilft
- erstmal Ruhe bewahren und warten
- Aktualisieren im Browser drücken
- Taste zum Anlernen nochmal drücken, wenn er dabei nicht in den Anlernmodus geht (ruhiges Blinken in einer Farbe) sondern hektische Blinkvorgänge mit einem grünen Blinker ende - dann waren noch Daten zu übertragen.
- nochmal den pairing Vorgang auslösen ohne etwas zu löschen oder zu resetten.
Manchmal hilft auch Handbuch lesen(auch wenn es blöd klingt), da der Anlernmodus durchaus von Gerät zu Gerät unterschiedlich eingeleitet wird. Sonst macht man reset statt anlernen.
Das ist wenig konkret zu Deinem Problem, aber meine Erfahrung zum Thema.
Gruß Otto
Ob noch Daten zu uebertragen sind zeigt cmdspending zuverlaessig an.
Es wird auch angezeigt ob fhem fertig ist oder noch überträgt. Das sollten die eigentlichen Kriterien sein.
Mein Tip ist hierbei hminfo protoevents in einem Fenster offen zu haben und zu aktualisieren. Da sieht man wie es mit der Übertragung steht.
Probieren geht auch, ist aber eben nur probieren. Nicht zuverlaessig.
Läßt sich eigentlich in der FHEM-Oberfläche die Signalstärke mit dem die HM-Aktoren vom CUL empfangen werden anzeigen?
Ich war heute total überrascht, dass der Pi mit CUL vom Dachboden bis ins Kellerbüro reicht.
schon mal in die detailansicht beim hm-device geschaut?
oder get hminfo rssi?