Hallo zusammen,
ich habe heute einen neuen Rollo-Aktor eingebaut und auf ein seltsames Phänomen gestossen:
Der Rolloaktor sendet seine Befehle alle brav an den FHEM-Server und dort werden diese auch korrekt erkannt und verarbeitet - ich kann also den Status des Rollos immer sehen.
Wenn ich aber Befehle vom FHEM an den Aktor senden möchte, bekomme ich Probleme.
Im Event-Log bekomme ich folgende Einträge:
2014-03-27 19:55:11 CUL_HM Wohnzimmer_Rollo_Kueche set_off
2014-03-27 19:55:30 CUL_HM Wohnzimmer_Rollo_Kueche sabotageAttackId: ErrIoId_F12909 cnt:17
2014-03-27 19:55:30 CUL_HM Wohnzimmer_Rollo_Kueche sabotageAttackId: ErrIoId_F12909 cnt:18
2014-03-27 19:55:30 CUL_HM Wohnzimmer_Rollo_Kueche sabotageAttackId: ErrIoId_F12909 cnt:19
2014-03-27 19:55:30 CUL_HM Wohnzimmer_Rollo_Kueche sabotageAttackId: ErrIoId_F12909 cnt:20
2014-03-27 19:55:30 CUL_HM Wohnzimmer_Rollo_Kueche ResndFail
2014-03-27 19:55:30 CUL_HM Wohnzimmer_Rollo_Kueche MISSING ACK
Es wurden auch laut Info nur 2 Message vom FHEM versendet:
rssi_myCUL avg:-57 min:-57 max:-57 lst:-57 cnt:2
Habt ihr eine Idee, woran das liegen könnte?
Viele Grüße
Eniac
das Device wird gesteuert von einer HMId "F12909". Ist das die ID deines IO device? hast du mehrere IO devices?
Wie sind die IDs?
Mit welcher ID ist dein Wohnzimmer_Rollo_Kueche gepairt?
Hallo Martin,
erstmal Danke, dass du immer so schnell meine (und auch die anderen Fragen) beantwortest.
Ich habe nur ein CUL_HM mit der ID F12909, der Küchenrollo-Aktor ist mit dem CUL_HM gepairt.
Für mich sieht das von den Werten auch alles okay aus, anbei mal ein List des Devices
Internals:
DEF 21AA92
IODev myCUL
LASTInputDev myCUL
MSGCNT 3
NAME Wohnzimmer_Rollo_Kueche
NR 127
STATE on
TYPE CUL_HM
lastMsg No:B5 - t:10 s:21AA92 d:000000 0601C800
myCUL_MSGCNT 3
myCUL_RAWMSG A0DB5C41021AA920000000601C800::-77.5:myCUL
myCUL_RSSI -77.5
myCUL_TIME 2014-03-28 08:21:02
protCmdDel 10
protErrIoId_F12909 24 last_at:2014-03-28 07:30:13
protLastRcv 2014-03-28 08:21:02
protResnd 18 last_at:2014-03-28 07:30:13
protResndFail 6 last_at:2014-03-28 07:30:18
protSnd 6 last_at:2014-03-28 07:30:00
protState CMDs_done_Errors:1
rssi_at_myCUL avg:-81.5 min:-81.5 max:-81.5 lst:-81.5 cnt:1
rssi_at_rpt_myCUL avg:-77.25 min:-77.5 max:-77 lst:-77.5 cnt:2
Readings:
2014-03-27 11:57:42 CommandAccepted yes
2014-03-27 11:55:50 D-firmware 2.2
2014-03-27 11:55:50 D-serialNr KEQ0158639
2014-03-27 11:56:11 PairedTo 0xF12909
2014-03-27 11:55:10 R-confBtnTime 255 min
2014-03-27 11:55:12 R-driveDown 50 s
2014-03-27 11:55:12 R-driveTurn 0.5 s
2014-03-27 11:55:12 R-driveUp 50 s
2014-03-27 11:55:10 R-intKeyVisib invisib
2014-03-27 11:55:10 R-localResDis off
2014-03-27 11:55:10 R-pairCentral 0xF12909
2014-03-27 11:55:12 R-refRunCounter 0
2014-03-27 11:55:12 R-sign off
2014-03-27 11:55:12 R-statusInfoMinDly 3 s
2014-03-27 11:55:12 R-statusInfoRandom 0 s
2014-03-27 11:55:12 R-transmitTryMax 6
2014-03-27 20:21:33 RegL_00:
2014-03-28 08:21:02 deviceMsg on (to broadcast)
2014-03-28 08:21:02 level 100
2014-03-28 08:21:02 motor stop:on
2014-03-28 08:21:02 pct 100
2014-03-28 08:21:02 recentStateType info
2014-03-28 07:30:13 sabotageAttackId ErrIoId_F12909 cnt:24
2014-03-28 08:21:02 state on
2014-03-28 08:21:02 timedOn off
Helper:
cSnd 11F1290921AA920201C80000
dlvlCmd ++A011F1290921AA920201C80000
getCfgList all
getCfgListNo ,3
mId 006A
rxType 1
Io:
newChn +21AA92,00,01,1E
nextSend 1395991262.35852
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_mycul:
avg -81.5
cnt 1
lst -81.5
max -81.5
min -81.5
At_rpt_mycul:
avg -77.25
cnt 2
lst -77.5
max -77
min -77.5
Attributes:
IODev myCUL
autoReadReg 4_reqStatus
expert 2_full
firmware 2.2
group Rollos
model HM-LC-Bl1PBU-FM
peerIDs 00000000,
room Wohnzimmer
serialNr KEQ0158639
subType blindActuator
webCmd statusRequest:toggle:on:off:up:down:stop
Ich habe aber parallel mit einige sehr seltsame Verhaltensweisen, die ähnlich sind (ein neuer Fenstersensor, der seine Zustandsänderungen an die FHEM-Zentrale schickt, aber wohl offensichtlich kein ACK von der Zentrale erhält, etc). Daher hatte ich gestern auch nochmal ein Update des Gesamtsystems gemacht, aber ohne Erfolg.
Hast du eine Idee?
Viele Grüße
Eniac
ah - jetzt:
Du hast in myCUL die ID nicht gesetzt sondern nutzt den Default.
wenn du ein
attr myCUL hmId F12909
machst - mit save - ist es erledigt.
Hallo Martin,
vielen Dank für den Vorschlag. Habe ich direkt auch so umgesetzt - jetzt kommen keine Fehlermeldungen wegen SabotageAttack, aber leider erhält / akzeptiert der Rollo immer noch keine Befehle von der Zentrale.
Es ist so, als würde die FHEM-Zentrale nicht antworten. Wenn ich die Infos vom Rollo-Aktor richtig interpretiere, hat er bisher noch keine Antwort von der Zentrale erhalten:
protLastRcv 2014-03-28 10:05:38
protResnd 36 last_at:2014-03-28 20:50:39
protResndFail 12 last_at:2014-03-28 20:50:45
protSnd 12 last_at:2014-03-28 20:50:29
protState CMDs_done_Errors:1
rssi_at_myCUL avg:-77.83 min:-81.5 max:-76 lst:-76 cnt:3
rssi_at_rpt_myCUL avg:-76.5 min:-77.5 max:-75.5 lst:-75.5 cnt:4
Kann es ggf. ein Problem beim Pairing gegeben haben? Soll ich das Device nochmal löschen, auf Werkszustand zurücksetzen und neu pairen?
Oder habt ihr noch eine Idee?
Viele Grüße
Eniac
ZitatEs ist so, als würde die FHEM-Zentrale nicht antworten
umgekehrt - das Device antwortet nicht.
ZitatKann es ggf. ein Problem beim Pairing gegeben haben?
ja
ZitatSoll ich das Device nochmal löschen,
nicht notwendig
Zitatauf Werkszustand zurücksetzen
erst einmal nicht notwendig
Zitatund neu pairen?
ja. Probiere beide Varianten: hmPairForSec und hmPairSerial.
gepairt ist nur, wenn nach lesen der Config um Register pairCentral die hmId des IO device steht.
Hallo zusammen,
manche Dinge können so einfach sein!
Ich habe das nochmal gepaired, wie von Martin empfohlen und es funktioniert jetzt wunderbar!
Vielen Dank für den Tip!
Viele Grüße
Eniac