Ich habe ein Problem mit einem device und möchte es eigentlich gerne auf werkseinstellung zurücksetzen. Dummerweise wird das device schon in mehreren Doifs und anderen Funktionen verwendet. Mein Plan ist deshalb dass device zu löschen, es zu resetten, neu zu pairen und dann wieder auf den ursprünglichen Namen umzubenennen.
Bleiben beim Löschen des devices noch die ganzen Doifs und andere Funktionen erhalten? Oder wird das auch mit gelöscht? Und wenn ich das device wieder auf den ursprünglichen Namen umbenenne, funktionieren dann noch die ganzen alten Doifs?
Warum resetten, löschen, neu anlegen und umbenennen?
Was für ein Gerät ist es?
Pairing klingt nach Homematic?!
Da kann man auch einfach so "drüber pairen"...
Aber poste doch mal ein list von dem Device...
...und schildere warum den "Amok"...
Aber trotzdem die Antworten zu den Fragen:
Nein, normalerweise werden "verknüpfte" notify/DOIF etc. nicht mit gelöscht, wenn du NUR direkt beim Device unten den "Delete this Device" link nutzt.
Bei Löschen mit devspec oder/und RegEx kann schon mehr gelöscht werden ;)
Und wenn nach dem Umbenennen wieder die gewohnten Events kommen (sollte ja), dann funktionieren auch notify/DOIF etc. wieder (wenn zuvor auch schon funktioniert)...
Gruß, Joachim
Ich habe ein Problem mit einem Homematic Fensterkontakt. Wenn ich ein GetConfig mache und den Taster am FK drücke blinkt der FK erst orange und geht dann auf rot. Gestern war anscheinend der DutyCycle überschritten, da hat er nur noch rot geleuchtet.
Heute funktioniert er - zumindest was die Heizungsregler betrifft - wieder ganz normal und quittiert ein offenes oder geschlossenes Fenster mit grün.
Aber der Fehler mit GetConfig ist immer noch da. Das komische ist dass beim FK die Liste der PeerIDs komplett leer ist. Also kein 000000 oder gepeerte Heizungsregler - die Liste ist komplett leer. Ich sehe auch im Log vom FK dass beim Auslesen der peerlist ein Timeout kommt:
2019-12-08_16:04:03 ku.fk.Schiebetuer ResndFail
2019-12-08_16:04:04 ku.fk.Schiebetuer RESPONSE TIMEOUT:PeerList
Ich vermute dass der FK irgendwie hängt und überlege ihn deshalb auf Werkseinstellung zurückzusetzen, aber vorher aus FHEM zu löschen. Nach erneutem Pairen würde ich den gleichen Namen wieder verwenden damit die alten Doif wieder funktionieren. Klar, Peering muss ich neu machen.
Hi,
wie Joachim gestern schon gesagt hat, bevor Du Dir unnötigen Aufwand machst: wiederhole einfach den Pairing Vorgang OHNE Reset, OHNE Löschen.
Pass auf, dass Du den Sensor beim Pairen nicht auslöst, sondern die Configtaste drückst um die Datenübertragung anzustoßen.
Hast Du hmInfo definiert? Was sagt da configCheck zu deinem System ?
Gruß Otto
Hallo Otto,
das mit dem erneuten Pairing habe ich schon versucht, da hat der FK am Ende auch grün geleuchtet. Die PeerList ist allerdings immer noch leer. Mein FK sieht so aus:
Internals:
DEF 44257C
FUUID 5cb63bfb-f33f-d318-6683-f8d5e56a3dd28e23
HMLAN1_MSGCNT 1065
HMLAN1_RAWMSG E44257C,0000,682D381B,FF,FFAE,4A800244257C3012350011AC5097
HMLAN1_RSSI -82
HMLAN1_TIME 2019-12-08 21:29:29
IODev gl.gw.Wemos
LASTInputDev HMLAN1
MSGCNT 2137
NAME ku.fk.Schiebetuer
NOTIFYDEV global
NR 59
NTFY_ORDER 50-ku.fk.Schiebetuer
STATE closed
TYPE CUL_HM
chanNo 01
gl.gw.Wemos_MSGCNT 1072
gl.gw.Wemos_RAWMSG 040C00294A800244257C3012350011AC5097
gl.gw.Wemos_RSSI -41
gl.gw.Wemos_TIME 2019-12-08 21:29:28
lastMsg No:4A - t:02 s:44257C d:301235 0011AC5097
protCmdDel 15
protEvt_AESCom-ok 3 last_at:2019-12-08 21:29:28
protLastRcv 2019-12-08 21:29:28
protRcv 109 last_at:2019-12-08 21:29:28
protRcvB 16 last_at:2019-12-08 18:07:37
protResnd 6 last_at:2019-12-08 15:07:06
protResndFail 2 last_at:2019-12-08 16:04:03
protSnd 60 last_at:2019-12-08 21:29:28
protState CMDs_done
rssi_at_HMLAN1 cnt:1065 min:-92 max:-54 avg:-68.51 lst:-82
rssi_at_gl.gw.Wemos cnt:1069 min:-52 max:-36 avg:-40.33 lst:-41
READINGS:
2019-12-08 21:29:26 Activity alive
2019-12-08 21:29:28 CommandAccepted yes
2019-12-08 21:29:26 D-firmware 1.0
2019-12-08 21:29:26 D-serialNr MEQ1723075
2019-12-08 12:44:10 PairedTo 0x301235
2019-12-07 10:52:45 R-cyclicInfoMsg on
2019-12-07 10:52:45 R-eventDlyTime 0 s
2019-12-07 21:41:26 R-ku.ht.Heizung_WindowRec-expectAES set_off
2019-12-07 21:41:26 R-ku.ht.Heizung_WindowRec-peerNeedsBurst set_on
2019-12-08 21:29:26 R-pairCentral set_0x301235
2019-12-07 10:52:45 R-sabotageMsg on
2019-12-07 10:52:45 R-sign on
2019-12-08 21:29:28 aesCommToDev ok
2019-12-08 21:29:28 aesKeyNbr 00
2019-12-08 20:55:43 alive yes
2019-12-08 20:55:43 battery ok
2019-12-08 20:55:43 contact closed (to VCCU)
2019-12-07 10:46:50 powerOn 2019-12-07 10:46:50
2019-12-08 20:55:43 recentStateType info
2019-12-08 20:55:43 sabotageError off
2019-12-08 20:55:43 state closed
2019-12-08 18:07:37 trigDst_az.ht.Heizung noConfig
2019-12-08 18:07:37 trigDst_ku.ht.Heizung noConfig
2019-12-08 18:07:38 trigDst_wz.Ht.Couch noConfig
2019-12-08 18:07:37 trigDst_wz.ht.Essecke noConfig
2019-12-08 18:07:39 trigger_cnt 14
helper:
HM_CMDNR 74
PONtest 0
cSnd 0130123544257C000802010A300B120C35,0130123544257C0006
getCfgList all
getCfgListNo ,4
mId 00C7
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newCh 1
newChn +44257C,00,00,00
nextSend 1575836968.56129
prefIO
rxt 2
vccu VCCU
p:
44257C
00
00
00
mRssi:
mNo 4A
io:
HMLAN1:
-82
-82
gl.gw.Wemos:
-33
-33
prt:
bErr 0
sProc 0
sleeping 0
q:
qReqConf 00
qReqStat
regCollect:
role:
chn 1
dev 1
rssi:
at_HMLAN1:
avg -68.519248826291
cnt 1065
lst -82
max -54
min -92
at_gl.gw.Wemos:
avg -40.3302151543499
cnt 1069
lst -41
max -36
min -52
shadowReg:
RegL_00. 02:01 0A:30 0B:12 0C:35
tmpl:
Attributes:
IODev gl.gw.Wemos
IOgrp VCCU:gl.gw.Wemos
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
icon fts_window_1w
model HM-SEC-SCO
peerIDs
room Kueche
serialNr MEQ1723075
subType threeStateSensor
Danach habe ich noch versucht erneut zu Peeren aber da hat der FK am Ende rot geleuchtet protState steht noch auf CMDs_pending. Das ist doch nicht normal beim FK, der zickt doch rum.
Und ja, im HMinfo habe ich neben dem Fehler noch andere kleine Baustellen (obwohl sonst alles funktioniert). Die Fehler muss ich nach und nach mal beseitigen.
cmds_pending ist gerade beim FK normal.
Da Batterie-betrieben überträgt er halt nur ab und an Daten oder eben "Konfig-Taster" drücken (aufwecken).
Peering nach Pairing geht nur noch per Befehl von der Zentrale/fhem (hast du verm. ja auch so gemacht)...
Gepaired ist er ja jetzt so wie's aussieht...
Mach doch mal clear message und dann ein getConfig inkl. "Knöpfchen drücken"...
Und dann mal sehen was hminfo "sagt"...
Gruß, Joachim
Zitat von: teichtaucher am 08 Dezember 2019, 21:39:41
Das ist doch nicht normal beim FK, der zickt doch rum.
Doch der FK ist ne kleine Zicke.
configtaster nochmal drücken und viel Ruhe bewahren. Und erst wieder getconfig machen, wenn cmds pending weg ist.
So, mal ein kleines Statusupdate: Habe ein getConfig gemacht und den Taster gedrückt aber am Ende der Kommunikation geht der FK immer auf rot. Witzigerweise sehe ich in FHEM CMDs_done. Aber ich sehe immer noch keine PeerList :-(
Gut, er scheint immer noch zu funktionieren, die Heizungsregler fahren runter wenn das Fenster offen ist. Sieht halt nicht gut aus in hmInfo aber vielleicht muss ich einfach mit diesem Schönheitsfehler leben. Ansonsten überlege ich mir das und setze ihn wirklich einfach auf Werkseinstellung zurück.
Trotzdem danke für Eure Hilfe.
Und einfach nochmal pairen OHNE reset?
Habe ich gerade nochmal versucht aber ohne Änderung. Der FK sieht so aus:
Internals:
DEF 44257C
FUUID 5cb63bfb-f33f-d318-6683-f8d5e56a3dd28e23
HMLAN1_MSGCNT 1109
HMLAN1_RAWMSG E44257C,0000,6D515829,FF,FFB3,F3800244257C301235000D4E5486
HMLAN1_RSSI -77
HMLAN1_TIME 2019-12-09 21:26:50
IODev gl.gw.Wemos
LASTInputDev HMLAN1
MSGCNT 2233
NAME ku.fk.Schiebetuer
NOTIFYDEV global
NR 59
NTFY_ORDER 50-ku.fk.Schiebetuer
STATE closed
TYPE CUL_HM
chanNo 01
gl.gw.Wemos_MSGCNT 1124
gl.gw.Wemos_RAWMSG 040C0029F3800244257C301235000D4E5486
gl.gw.Wemos_RSSI -41
gl.gw.Wemos_TIME 2019-12-09 21:26:50
lastMsg No:F3 - t:02 s:44257C d:301235 000D4E5486
protCmdDel 23
protEvt_AESCom-ok 10 last_at:2019-12-09 21:26:50
protLastRcv 2019-12-09 21:26:50
protRcv 153 last_at:2019-12-09 21:26:50
protRcvB 16 last_at:2019-12-08 18:07:37
protResnd 12 last_at:2019-12-09 18:26:42
protResndFail 4 last_at:2019-12-09 19:27:41
protSnd 113 last_at:2019-12-09 21:26:49
protState CMDs_done
rssi_at_HMLAN1 cnt:1109 min:-92 max:-54 avg:-68.66 lst:-77
rssi_at_gl.gw.Wemos cnt:1114 min:-52 max:-36 avg:-40.38 lst:-41
READINGS:
2019-12-09 21:26:47 Activity alive
2019-12-09 21:26:50 CommandAccepted yes
2019-12-09 21:26:47 D-firmware 1.0
2019-12-09 21:26:47 D-serialNr MEQ1723075
2019-12-09 16:27:26 PairedTo 0x301235
2019-12-07 10:52:45 R-cyclicInfoMsg on
2019-12-07 10:52:45 R-eventDlyTime 0 s
2019-12-07 21:41:26 R-ku.ht.Heizung_WindowRec-expectAES set_off
2019-12-07 21:41:26 R-ku.ht.Heizung_WindowRec-peerNeedsBurst set_on
2019-12-09 21:26:47 R-pairCentral set_0x301235
2019-12-07 10:52:45 R-sabotageMsg on
2019-12-07 10:52:45 R-sign on
2019-12-09 21:26:50 aesCommToDev ok
2019-12-09 21:26:50 aesKeyNbr 00
2019-12-09 21:18:49 alive yes
2019-12-09 21:18:49 battery ok
2019-12-09 21:18:49 contact closed (to VCCU)
2019-12-07 10:46:50 powerOn 2019-12-07 10:46:50
2019-12-09 21:18:49 recentStateType info
2019-12-09 21:18:49 sabotageError off
2019-12-09 21:18:49 state closed
2019-12-08 18:07:37 trigDst_az.ht.Heizung noConfig
2019-12-08 18:07:37 trigDst_ku.ht.Heizung noConfig
2019-12-08 18:07:38 trigDst_wz.Ht.Couch noConfig
2019-12-08 18:07:37 trigDst_wz.ht.Essecke noConfig
2019-12-08 18:07:39 trigger_cnt 14
helper:
HM_CMDNR 243
PONtest 0
cSnd 0130123544257C000802010A300B120C35,0130123544257C0006
getCfgList all
getCfgListNo ,4
mId 00C7
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newCh 1
newChn +44257C,00,00,00
nextSend 1575923210.22873
prefIO
rxt 2
vccu VCCU
p:
44257C
00
00
00
mRssi:
mNo F3
io:
HMLAN1:
-77
-77
gl.gw.Wemos:
-33
-33
prt:
bErr 0
sProc 0
sleeping 0
q:
qReqConf 00
qReqStat
regCollect:
role:
chn 1
dev 1
rssi:
at_HMLAN1:
avg -68.663660955816
cnt 1109
lst -77
max -54
min -92
at_gl.gw.Wemos:
avg -40.3877917414722
cnt 1114
lst -41
max -36
min -52
shadowReg:
RegL_00. 02:01 0A:30 0B:12 0C:35
RegL_04.ku.ht.Heizung_WindowRec 01:01
tmpl:
Attributes:
IODev gl.gw.Wemos
IOgrp VCCU:gl.gw.Wemos
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
icon fts_window_1w
model HM-SEC-SCO
peerIDs
room Kueche
serialNr MEQ1723075
subType threeStateSensor
Der ist noch nicht ganz fertig:
2019-12-09 21:26:47 R-pairCentral set_0x301235
nochmal Taste drücken und Ruhe bewahren :)
Schalte vielleicht besser für den Pairing Vorgang den HMLAN aus. Nur ein IO ist meist besser :)
So, hat leider alles nichts gebracht. Ich konnte aber in der Zwischenzeit mal die anderen FKs richtig konfigurieren. Und dabei ist mir folgendes aufgefallen:
- Wenn ein FK mit mehreren RTs gepeered wird meldet der FK relativ schnell den DutyCycle Error. Also muss man hier wirklich abwarten und dann weitermachen.
- Teilweise sehe ich jetzt auch bei den neuen FKs wenn sie mit einige RTs gepeered sind dass die PeerList nicht vollständig ist.
Kann es sein dass der FK ab einer kritischen Menge an RTs die getConfig-Daten gar nicht vollständig übertragen kann ohne in ein DutyCycle Fehler zu laufen? Dann wäre das ja ein generelles Problem und hmInfo kann man gar nicht sauber bekommen?
Sauber bekommt man es dann nur wenn man die FKs über einen virtuellen FK gruppiert.
Meine Vermutung war richtig. Ich habe jetzt bei allen FKs das Peering mit den RTs aufgehoben. Und siehe da, auf einmal haben die FKs auch auf ein GetConfig (mit grün) geantwortet. Ich denke dass bei zu vielen Peerings die Funklast von den FKs schnell am Ende ist und die auf DutyCycle Error gehen. Jetzt wo die Peerings aufgehoben sind reagieren alle FKs total schnell und antworten auf jedes Kommando.
Ich habe mir statt direktem Peering einen virtuellen FK angelegt und den mit allen fünf RTs gepeered. Ein DoIf (mit 30s wait delay) löst jetzt den virtuellen FK aus sobald ein Fenster offen ist. Neben dem jetzt fehlerfreien Betrieb hat man noch andere Vorteile:
-Durch das wait löst nicht jede kurze Fensteröffnung ein Runterregeln aus.
-Ein nicht erkanntes geschlossenes Fenster führt trotzdem dazu dass die Heizung wieder hoch regelt.
-Es ist viel übersichtlicher da jedes offene Fenster in nur einem virtuellen FK gehändelt wird statt dass jeder FK mit jedem RT gepeered ist.
Und jetzt ist auch HmInfo sauber :-)