Hallo zusammen
Ich verzweifel hier gerade, beim Versuch, meinen frisch erworbenen Dimm Aktor mit fhem zu pairen.
Vorgegangen bin ich wie immer:
set SCC hmPairForSec 120 und den Anlernknopf am Aktor >4sec gedrückt. Die LED fängt an zu blinken, hört aber erst nach 20 sekunden auf. Das Device wird im Raum CUL_HM angelegt, lässt sich aber nicht ansteuern. Beim Versuch zu schalten kommt immer: MISSING ACK. Auf getConfig folgt: RESPONSE TIMEOUT:RegisterRead.
Hier das List:
Internals:
DEF 16932B
IODev SCC
LASTInputDev SCC1
MSGCNT 5
NAME HM_16932B
NOTIFYDEV global
NR 465
NTFY_ORDER 50-HM_16932B
SCC1_MSGCNT 4
SCC1_RAWMSG A1A01800016932B000FFF1200584945513030373138343720110100::-95:SCC1
SCC1_RSSI -95
SCC1_TIME 2018-01-25 11:20:48
SCC_MSGCNT 1
SCC_RAWMSG A0D00841016932B00000006010000::-84:SCC
SCC_RSSI -84
SCC_TIME 2018-01-25 10:59:36
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
hmPairSerial IEQ0071847
lastMsg No:01 - t:00 s:16932B d:000FFF 1200584945513030373138343720110100
protCmdDel 14
protLastRcv 2018-01-25 11:20:48
protResnd 21 last_at:2018-01-25 12:03:12
protResndFail 7 last_at:2018-01-25 12:03:17
protSnd 8 last_at:2018-01-25 12:02:58
protState CMDs_done_Errors:1
rssi_at_SCC lst:-84 cnt:1 min:-84 avg:-84 max:-84
rssi_at_SCC1 max:-95 min:-101 avg:-97.87 cnt:4 lst:-95
READINGS:
2018-01-25 11:20:48 D-firmware 1.2
2018-01-25 11:20:48 D-serialNr IEQ0071847
2018-01-25 10:59:36 deviceMsg off (to broadcast)
2018-01-25 10:59:36 dim stop:off
2018-01-25 11:16:24 level set_32
2018-01-25 10:59:36 overheat off
2018-01-25 10:59:36 overload off
2018-01-25 10:59:36 pct 0
2018-01-25 10:59:36 powerOn 2018-01-25 10:59:36
2018-01-25 10:59:36 recentStateType info
2018-01-25 10:59:36 reduced off
2018-01-25 12:03:17 state RESPONSE TIMEOUT:RegisterRead
2018-01-25 10:59:36 timedOn off
RegL_00.:
VAL
helper:
HM_CMDNR 44
PONtest 1
cSnd 11000FFF16932B0201C80000,01000FFF16932B00040000000000
dlvl C8
dlvlCmd ++A011000FFF16932B0201C80000
getCfgList all
getCfgListNo ,3
mId 0058
rxType 1
stateUpdatDly 120
supp_Pair_Rep 1
dir:
cur stop
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +16932B,00,00,00
nextSend 1516875648.99377
prefIO
rxt 0
vccu
p:
16932B
00
00
00
mRssi:
mNo 01
io:
SCC1 -95
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rssi:
at_SCC:
avg -84
cnt 1
lst -84
max -84
min -84
at_SCC1:
avg -97.875
cnt 4
lst -95
max -95
min -101
tmpl:
Attributes:
IODev SCC
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.2
model HM-LC-DIM1T-CV
room CUL_HM
serialNr IEQ0071847
subType dimmer
webCmd statusRequest:toggle:on:off:up:down
Hat jemand eine Idee?
edition
schlechter funk, siehe rssi.
also entfernung zum io verringern und drüberpairen.
Die Entfernung beträgt ca. 3,50m. Das kann ja wohl nicht sein.
Zitat von: edition am 25 Januar 2018, 12:33:29
Die Entfernung beträgt ca. 3,50m. Das kann ja wohl nicht sein.
Dann steckt eine Seite (scheinbar der Aktor) in einer Blechkiste.
->
rssi_at_SCC lst:-84 cnt:1 min:-84 avg:-84 max:-84
rssi_at_SCC1 max:-95 min:-101 avg:-97.87 cnt:4 lst:-95
BTW: Der SCC ist kein gut geeigneter IO für Homematic.
Bitte auch hier lesen -> https://forum.fhem.de/index.php/topic,83156.msg753825.html#msg753825
Gruß Otto
Ich mag nicht so recht daran glauben, das es ausschließlich am SCC liegt. Immerhin habe ich im ganzen Haus Homematic Komponenten verbaut, die alle problemlos funktionieren. Ich habe eher das Gefühl, das es am Dimmer selbst liegt.
Ich werde mich in meinem Bekanntenkreis umhören, wer da noch mit Homematic arbeitet. Dann werden wir versuchen, den Dimmer anzumelden. Wenn das nicht klappt, ist es eindeutig. Wenn doch, kann ich mir immer noch Gedanken über eine SCC Alternative machen.
edition
Zitat von: edition am 26 Januar 2018, 09:57:54
Ich mag nicht so recht daran glauben, das es ausschließlich am SCC liegt.
Moin,
Das habe ich auch nicht gesagt, aber Du glaubst ja auch nicht, dass es am Empfang liegt! rssi von kleiner -80 sprechen aber dafür!
Gruß Otto
liegt der dimmer in einer abgehängten decke mit profilen aus metall? vielleicht wirkt hier ein faraday'scher käfig. lass ihn mal heraushängen.
du nutzt 2 scc, aber keine vccu. warum?
stecken die beide auf dem selben pi?
Das Teil liegt auf dem Wohnzimmertisch und hat quasi "Sichtkontakt" zum Raspberry. Daher ja die Vermutung, das es am Gerät selbst liegt.
Ich habe 2 SCC im Einsatz. Einen für Homematic und den anderen für Intertechno. Über VCCU habe ich mir bisher keine Gedanken gemacht, weil doch alles funktioniert hat. Mir ist allerdings auch aufgefallen, das oftmals als LASTInputDev SCC1 steht. Vielleicht sollte ich mich mit dem Thema VCCU doch einmal beschäftigen.
edition
werden die 2 scc vielleicht falsch zugeordnet?
zieh mal den für it ab.
Ich muss gleich zur Arbeit und werde das frühestens heute Abend machen können.
Reicht es nicht aus, den SCC1 mittels # aus der fhem.cfg zu eliminieren und fhem neu zu starten? Dann könnte ich es mir sparen, den Raspberry zu zerlegen.
Etwas ähnliches habe ich schon einmal machen müssen, als ein Firmwareupdate eines hm-tc-it-wm-w-eu nicht glücken wollte.
edition
fhem nutzt dann nur einen. das verhindert aber nicht unbedingt, dass doch der falsche genutzt wird.
ich gehe davon aus, das beide scc unterschiedliche hardware haben, wegen der unterschiedlichen frequenzen.
Zitat von: edition am 25 Januar 2018, 12:06:37
Hallo zusammen
Ich verzweifel hier gerade, beim Versuch, meinen frisch erworbenen Dimm Aktor mit fhem zu pairen.
Vorgegangen bin ich wie immer:
set SCC hmPairForSec 120 und den Anlernknopf am Aktor >4sec gedrückt. Die LED fängt an zu blinken, hört aber erst nach 20 sekunden auf. Das Device wird im Raum CUL_HM angelegt, lässt sich aber nicht ansteuern. Beim Versuch zu schalten kommt immer: MISSING ACK. Auf getConfig folgt: RESPONSE TIMEOUT:RegisterRead.
Hat jemand eine Idee?
edition
Moin
Mal eine kurze Frage. Wenn Du siehst, dass der nach 20 Sekunden aufhert zu blinken, warum schickst du dann ein get config? Wenn der einfach aufhoert, dann hat er keinen Partner zum Pairen gefunden, steht so in der Anleitung! Und kann man auch gut im List sehen, da er mit niemandem gepairt ist!
Solange dies der Fall ist brauchst du nicht weitermachen. Und den Ratschlag meiner Vorredner, den entsprechenden SCC mal alleine zu betreiben solltest du ruhig annehmen, sonst suchst Du noch ewig!
Gruss Christoph
Zitat von: edition am 26 Januar 2018, 11:13:38
Das Teil liegt auf dem Wohnzimmertisch und hat quasi "Sichtkontakt" zum Raspberry. Daher ja die Vermutung, das es am Gerät selbst liegt.
Mein "Scherz" mit der Blechkiste hatte sich in dem verlinkten Thread dann leider als bitterer Wahrheit rausgestellt. Deswegen frag ich lieber nochmal: Der liegt nicht auf dem Tisch in der Keksdose? Der Tisch ist wegen Strahlenschutz zufällig mit Bleieinlage?
Gruß Otto
Nein, nichts dergleichen.
Der erste Versuch, das Gerät zu pairen fand wie immer in der Küche statt. Da habe ich bisher alle Netzbetriebenen Geräte gepairt. Netzkabel mit markierter Phasenlage angeschlossen, am Laptop im Wohnzimmer set SCC hmPairForSec 600 ausgelöst und in der Küche die Anlerntaste gedrückt. Wenn ich dann ins Wohnzimmer zurück kam, war der Cul_HM Raum da, in dem sich das Gerät dann befand. Hat immer funktioniert!
Ich glaube, der Dimmer hat einen Fehler. Das werde ich herausfinden, wenn ich beim Bekannten an der CCU2 anmelde. Dann werde ich sehen.
edition
Einmal den Vorgang sniffen.
Protokollevents sind geprüft?
Sollte die scc keinen timestamp unterstützen kann es schwer werden.
Die gute Nachricht vorneweg: Der Dimmer funktioniert und ist jetzt ordnungsgemäß gepairt!
Irgendwie hat mir das Thema keine Ruhe gelassen, so das ich heute schon früh wach war. Ich habe mir den Dimmer im Büro auf den Schreibtisch gelegt, das Netzkabel eingesteckt und einfach nochmal set SCC hmPairForSec 600 angestoßen. Nach dem drücken der Anlerntaste blinkte die LED dieses mal nur kurz. Und siehe da: Gerät gepairt und funktioniert. RSSI -64.
Also, wieder runter in die Küche. Dort angeschlossen und eingeschaltet: Funktioniert! RSSI -52,5, LASTInputDev SCC.
Es ist alles noch so, wie es vorher auch war. Ich habe nichts verändert!
Gruß
edition