Hallo,
ich habe mir heute wiedermal einen HM-LC-SW1-FM gekauft (Gerät hat auch nur einen Kanal zum Anschließen) und wollte ihn an meiner VCCU per autocreate anlernen.
Allerdings wird er als HM-LC-SW2-FM erkannt und eingerichtet.
Leider funktioniert dann halt leider nicht mehr (nur mehr Time-outs und Missing Ack).
Ich habe den HM-LC-SW1-FM schon mehrmals per Werksreset zurückgesetzt. Hilft alles nichts.
Ich bin ziemlich ratlos und dankbar für jede Hilfe.
lg, Gerhard
fhem ist am letzten Stand.
Ein list ergibt folgendes:
Internals:
CFGFN
DEF 652C45
IODev hmusb2
LASTInputDev hmusb
MSGCNT 28
NAME HM_652C45
NOTIFYDEV global
NR 1967
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
channel_01 HM_652C45_Sw_01
channel_02 HM_652C45_Sw_02
hmusb2_MSGCNT 14
hmusb2_RAWMSG 0501002C9AA010652C451234560100000000
hmusb2_RSSI -44
hmusb2_TIME 2018-11-30 23:47:39
hmusb_MSGCNT 14
hmusb_RAWMSG E652C45,0000,834D15CD,FF,FFC9,9AA010652C451234560100000000
hmusb_RSSI -55
hmusb_TIME 2018-11-30 23:47:39
lastMsg No:9A - t:10 s:652C45 d:123456 0100000000
protCmdDel 6
protLastRcv 2018-11-30 23:47:39
protRcv 14 last_at:2018-11-30 23:47:39
protResnd 6 last_at:2018-11-30 23:47:58
protResndFail 2 last_at:2018-11-30 23:48:04
protSnd 20 last_at:2018-11-30 23:47:42
protState CMDs_done_Errors:1
rssi_at_hmusb cnt:14 min:-63 max:-54 avg:-57.64 lst:-55
rssi_at_hmusb2 cnt:14 min:-54 max:-44 avg:-47.14 lst:-44
READINGS:
2018-11-30 23:47:09 CommandAccepted yes
2018-11-30 23:47:08 D-firmware 2.8
2018-11-30 23:47:08 D-serialNr OEQ2069117
2018-11-30 23:47:12 PairedTo 0x123456
2018-11-30 23:47:12 R-pairCentral 0x123456
2018-11-30 23:47:12 RegL_00. 00:00 02:01 0A:12 0B:34 0C:56 15:FF 18:00
2018-11-30 23:48:04 state RESPONSE TIMEOUT:RegisterRead
helper:
HM_CMDNR 155
cSnd 01123456652C450103,01123456652C4502040000000001
mId 0009
regLst ,0,1,3p
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +652C45,00,00,00
nextSend 1543618059.30875
prefIO
rxt 0
vccu
p:
652C45
00
00
00
mRssi:
mNo 9A
io:
hmusb:
-55
-55
hmusb2:
-36
-36
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
prs 1
rpt:
IO hmusb2
flg A
ts 1543618059.04431
ack:
HASH(0x4be4dc8)
9A8002123456652C4500
rssi:
at_hmusb:
avg -57.6428571428571
cnt 14
lst -55
max -54
min -63
at_hmusb2:
avg -47.1428571428571
cnt 14
lst -44
max -44
min -54
shadowReg:
tmpl:
Attributes:
IODev hmusb2
IOgrp VCCU:hmusb2
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.8
model HM-LC-SW2-FM
room CUL_HM
serialNr OEQ2069117
subType switch
webCmd getConfig:clear msgEvents
mId 0009
scheinbar meldet der aktor in der anlernmessage die falsche model id. beim sw1 sollte 0004 kommen.
ich glaube es gab hier schon mal so einen fall.
da hilft eigentlich nur umtauschen.
oder ist das der gebrauchte, von dem hier schon berichtet wurde? :)
Hallo,
Den Schalter habe ich gestern neu gekauft.
Eigenartig.
Werde ihn mal umtauschen.
Danke!
Lg, Gerhard
Habe das Teil nun umgetauscht und mir einen neuen HM-LC-SW1-FM geholt.
Aber leider das gleiche Problem.
Erkannt und eingerichtet wird ein HM-LC-SW2-FM.
Nach 5 mal Pairen mit der VCCU und einigen getConfig funktioniert zwar das Device immer noch nocht ("RESPONSE TIMEOUT:RegisterRead" und "MISSING ACK").
Aber der als Channel 1 dargestellte Schalter funktioniert und kann ein- und ausgeschaltet werden.
Hat noch jemand anders das Problem?
Eventuell hat der Hersteller da was geändert?
lg, Gerhard
du hast also beim selben händler einen anderen bekommen?
sniffe mal die anlernmessage wie im wiki homematic sniffen beschrieben.
hier gab es den fall schon mal:
https://forum.fhem.de/index.php/topic,32853.msg252372.html#msg252372 (https://forum.fhem.de/index.php/topic,32853.msg252372.html#msg252372)
kannst jetzt folgendes probieren
losche die zwei Define von den kanälen xxxxxx01 xxxxxx02
und stelle im Device xxxxxx das attr Model auf HM-LC-SW1-FM
so wie es immoment ist versucht er den 2 Kanal zu lesen, den es nicht gibt.
ich habe nun folgendes getan:
attr global verbose 1
attr global mseclog 1
attr <hmio> logIDs all,sys
Das ergibt folgende log-Einträge für meinen hmusb2:
2018.12.02 00:01:05.943 0: HMUARTLGW hmusb2 send: 00 08
2018.12.02 00:01:05.964 0: HMUARTLGW hmusb2 recv: 00 040247, state 98
2018.12.02 00:01:05.977 0: HMUARTLGW hmusb2 GetSet Ack: 02, state 98
2018.12.02 00:01:05.979 0: HMUARTLGW hmusb2 roundtrip delay: 0.0156
2018.12.02 00:01:07.891 0: HMUARTLGW hmusb2 recv: 01 05 00 00 37 msg: 2F 84 00 652C3F 000000 2800094F45513230363931333910010100
2018.12.02 00:01:07.988 1: in UNDEFINED
2018.12.02 00:01:07.989 1: in DEFINED
2018.12.02 00:01:07.991 1: in DEFINED
2018.12.02 00:01:07.993 1: in UNDEFINED
2018.12.02 00:01:07.995 1: in DEFINED
2018.12.02 00:01:07.997 1: in DEFINED
2018.12.02 00:01:08.223 1: in DEFINED
2018.12.02 00:01:08.226 1: in DEFINED
2018.12.02 00:01:08.435 1: in DEFINED
2018.12.02 00:01:08.438 1: in DEFINED
2018.12.02 00:01:08.531 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 57 A0 01 123456 652C3F 00050000000000
2018.12.02 00:01:09.082 0: HMUARTLGW hmusb2 recv: 01 04 03 00 37 msg: 57 80 02 652C3F 123456 00
2018.12.02 00:01:09.169 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 58 A0 01 123456 652C3F 000802010A120B340C56
2018.12.02 00:01:09.341 0: HMUARTLGW hmusb2 recv: 01 04 03 00 38 msg: 58 80 02 652C3F 123456 00
2018.12.02 00:01:09.450 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 59 A0 01 123456 652C3F 0006
2018.12.02 00:01:09.619 0: HMUARTLGW hmusb2 recv: 01 04 03 00 3A msg: 59 80 02 652C3F 123456 00
2018.12.02 00:01:12.937 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 5A A0 01 123456 652C3F 00040000000000
2018.12.02 00:01:13.180 0: HMUARTLGW hmusb2 recv: 01 0402, state 100
2018.12.02 00:01:13.192 0: HMUARTLGW hmusb2 Ack: 02
2018.12.02 00:01:13.199 0: HMUARTLGW hmusb2 recv: 01 05 01 00 32 msg: 5A A0 10 652C3F 123456 0202010A120B340C5615FF1800
2018.12.02 00:01:13.281 0: HMUARTLGW hmusb2 send: 01 06652C3F000000
2018.12.02 00:01:13.467 0: HMUARTLGW hmusb2 recv: 01 04070101000EFFFFFFFFFFFFFFFF, state 90
2018.12.02 00:01:13.479 0: HMUARTLGW hmusb2 GetSet Ack: 07, state 90
2018.12.02 00:01:13.481 0: HMUARTLGW hmusb2 added peer: 652C3F, aesChannels: FFFFFFFFFFFFFFFF
2018.12.02 00:01:13.533 0: HMUARTLGW hmusb2 send: 01 06652C3F000000
2018.12.02 00:01:13.553 0: HMUARTLGW hmusb2 recv: 01 05 01 00 33 msg: 5A A0 10 652C3F 123456 0202010A120B340C5615FF1800
2018.12.02 00:01:13.698 0: HMUARTLGW hmusb2 recv: 01 04070101000EFFFFFFFFFFFFFFFF, state 93
2018.12.02 00:01:13.742 0: HMUARTLGW hmusb2 GetSet Ack: 07, state 93
2018.12.02 00:01:13.758 0: HMUARTLGW hmusb2 added peer: 652C3F, aesChannels: FFFFFFFFFFFFFFFF
2018.12.02 00:01:13.778 0: HMUARTLGW hmusb2 recv: 01 05 01 00 35 msg: 5B A0 10 652C3F 123456 030000
2018.12.02 00:01:14.144 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 5C A0 01 123456 652C3F 01040000000001
2018.12.02 00:01:14.315 0: HMUARTLGW hmusb2 recv: 01 0402, state 100
2018.12.02 00:01:14.335 0: HMUARTLGW hmusb2 Ack: 02
2018.12.02 00:01:14.367 0: HMUARTLGW hmusb2 recv: 01 05 01 00 36 msg: 5C A0 10 652C3F 123456 030800
2018.12.02 00:01:14.572 0: HMUARTLGW hmusb2 recv: 01 05 01 00 36 msg: 5D A0 10 652C3F 123456 02300657245600
2018.12.02 00:01:14.828 0: HMUARTLGW hmusb2 recv: 01 05 01 00 36 msg: 5E A0 10 652C3F 123456 030000
2018.12.02 00:01:15.166 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 5F A0 01 123456 652C3F 0103
2018.12.02 00:01:15.333 0: HMUARTLGW hmusb2 recv: 01 0402, state 100
2018.12.02 00:01:15.345 0: HMUARTLGW hmusb2 Ack: 02
2018.12.02 00:01:15.359 0: HMUARTLGW hmusb2 recv: 01 05 01 00 36 msg: 5F A0 10 652C3F 123456 0100000000
2018.12.02 00:01:15.657 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 60 A0 01 123456 652C3F 02040000000001
2018.12.02 00:01:16.693 0: HMUARTLGW hmusb2 recv: 01 0404, state 100
2018.12.02 00:01:16.704 0: HMUARTLGW hmusb2 can't send due to unknown problem (no response?)
2018.12.02 00:01:20.361 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 60 A0 01 123456 652C3F 02040000000001
2018.12.02 00:01:21.317 0: HMUARTLGW hmusb2 recv: 01 0404, state 100
2018.12.02 00:01:21.328 0: HMUARTLGW hmusb2 can't send due to unknown problem (no response?)
2018.12.02 00:01:22.132 0: HMUARTLGW hmusb2 send: 00 08
2018.12.02 00:01:22.151 0: HMUARTLGW hmusb2 recv: 00 040249, state 98
2018.12.02 00:01:22.163 0: HMUARTLGW hmusb2 GetSet Ack: 02, state 98
2018.12.02 00:01:22.165 0: HMUARTLGW hmusb2 roundtrip delay: 0.0140
2018.12.02 00:01:26.011 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 60 A0 01 123456 652C3F 02040000000001
2018.12.02 00:01:27.189 0: HMUARTLGW hmusb2 recv: 01 0404, state 100
2018.12.02 00:01:27.201 0: HMUARTLGW hmusb2 can't send due to unknown problem (no response?)
2018.12.02 00:01:27.213 0: HMUARTLGW hmusb2 send: 00 08
2018.12.02 00:01:27.245 0: HMUARTLGW hmusb2 recv: 00 040249, state 98
2018.12.02 00:01:27.257 0: HMUARTLGW hmusb2 GetSet Ack: 02, state 98
2018.12.02 00:01:27.259 0: HMUARTLGW hmusb2 roundtrip delay: 0.0265
2018.12.02 00:01:30.394 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 60 A0 01 123456 652C3F 02040000000001
2018.12.02 00:01:31.321 0: HMUARTLGW hmusb2 recv: 01 0404, state 100
2018.12.02 00:01:31.336 0: HMUARTLGW hmusb2 can't send due to unknown problem (no response?)
2018.12.02 00:01:35.926 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 61 A0 01 123456 652C3F 00040000000000
2018.12.02 00:01:36.185 0: HMUARTLGW hmusb2 recv: 01 0402, state 100
2018.12.02 00:01:36.197 0: HMUARTLGW hmusb2 Ack: 02
2018.12.02 00:01:36.205 0: HMUARTLGW hmusb2 recv: 01 05 01 00 36 msg: 61 A0 10 652C3F 123456 0202010A120B340C5615FF1800
2018.12.02 00:01:36.341 0: HMUARTLGW hmusb2 recv: 01 05 01 00 36 msg: 62 A0 10 652C3F 123456 030000
2018.12.02 00:01:36.778 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 63 A0 01 123456 652C3F 01040000000001
2018.12.02 00:01:37.052 0: HMUARTLGW hmusb2 recv: 01 0402, state 100
2018.12.02 00:01:37.064 0: HMUARTLGW hmusb2 Ack: 02
2018.12.02 00:01:37.070 0: HMUARTLGW hmusb2 recv: 01 05 01 00 36 msg: 63 A0 10 652C3F 123456 030800
2018.12.02 00:01:37.206 0: HMUARTLGW hmusb2 send: 00 08
2018.12.02 00:01:37.230 0: HMUARTLGW hmusb2 recv: 01 05 01 00 36 msg: 64 A0 10 652C3F 123456 02300657245600
2018.12.02 00:01:37.275 0: HMUARTLGW hmusb2 recv: 00 04024A, state 98
2018.12.02 00:01:37.287 0: HMUARTLGW hmusb2 GetSet Ack: 02, state 98
2018.12.02 00:01:37.450 0: HMUARTLGW hmusb2 recv: 01 05 01 00 36 msg: 65 A0 10 652C3F 123456 030000
2018.12.02 00:01:37.736 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 66 A0 01 123456 652C3F 0103
2018.12.02 00:01:37.898 0: HMUARTLGW hmusb2 recv: 01 0402, state 100
2018.12.02 00:01:37.909 0: HMUARTLGW hmusb2 Ack: 02
2018.12.02 00:01:37.922 0: HMUARTLGW hmusb2 recv: 01 05 01 00 36 msg: 66 A0 10 652C3F 123456 0100000000
2018.12.02 00:01:38.209 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 67 A0 01 123456 652C3F 02040000000001
2018.12.02 00:01:39.223 0: HMUARTLGW hmusb2 recv: 01 0404, state 100
2018.12.02 00:01:39.249 0: HMUARTLGW hmusb2 can't send due to unknown problem (no response?)
2018.12.02 00:01:42.895 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 67 A0 01 123456 652C3F 02040000000001
2018.12.02 00:01:44.061 0: HMUARTLGW hmusb2 recv: 01 0404, state 100
2018.12.02 00:01:44.074 0: HMUARTLGW hmusb2 can't send due to unknown problem (no response?)
2018.12.02 00:01:48.665 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 67 A0 01 123456 652C3F 02040000000001
2018.12.02 00:01:49.824 0: HMUARTLGW hmusb2 recv: 01 0404, state 100
2018.12.02 00:01:49.846 0: HMUARTLGW hmusb2 can't send due to unknown problem (no response?)
2018.12.02 00:01:52.238 0: HMUARTLGW hmusb2 send: 00 08
2018.12.02 00:01:52.260 0: HMUARTLGW hmusb2 recv: 00 04024C, state 98
2018.12.02 00:01:52.272 0: HMUARTLGW hmusb2 GetSet Ack: 02, state 98
2018.12.02 00:01:52.274 0: HMUARTLGW hmusb2 roundtrip delay: 0.0163
2018.12.02 00:01:52.790 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 67 A0 01 123456 652C3F 02040000000001
2018.12.02 00:01:53.683 0: HMUARTLGW hmusb2 recv: 01 0404, state 100
2018.12.02 00:01:53.700 0: HMUARTLGW hmusb2 can't send due to unknown problem (no response?)
2018.12.02 00:01:54.391 0: HMUARTLGW hmusb2 recv: 01 05 00 00 2D msg: 8D 86 10 4F0DCB 000000 0A89050B0000
2018.12.02 00:02:07.354 0: HMUARTLGW hmusb2 send: 00 08
2018.12.02 00:02:07.379 0: HMUARTLGW hmusb2 recv: 00 04024C, state 98
2018.12.02 00:02:07.389 0: HMUARTLGW hmusb2 GetSet Ack: 02, state 98
2018.12.02 00:02:07.392 0: HMUARTLGW hmusb2 roundtrip delay: 0.0171
2018.12.02 00:01:15.657 0: HMUARTLGW hmusb2 send: 01 02 00 00 00 msg: 60 A0 01 123456 652C3F 02040000000001
2018.12.02 00:01:16.693 0: HMUARTLGW hmusb2 recv: 01 0404, state 100
2018.12.02 00:01:16.704 0: HMUARTLGW hmusb2 can't send due to unknown problem (no response?)
man sieht es ja, sobald versucht wird den 2. channel zu öffnen kommt (no response?) , es gibt ihn ja auch nicht.
Hallo fhem-hm-knecht,
ich habe die fhem.cfg geändert, wie Du gesagt hast.
model HM-LC-SW1-FM
webCmd statusRequest:toggle:on:off
Und die defines für beide Kanäle gelöscht.
Damit klappt es - eigenartiges Verhalten.
Das ist aber nicht im Sinne des Erfinders. Oder?
Vielen Dank!
lg, Gerhard
natürlich nicht.
Wenn du es in den attributen änderst und einmal config drückst wird es automatisch überschrieben. Du solltest es also zumindest im UserConfig manifestieren um es bei einem neustart wieder zu korrigieren.
Hallo,
tut mir leid, das verstehe ich nicht ganz.
Wo soll ich "config" drücken?
lg, Gerhard
Hallo gestein,
ich hatte kürzlich ein eigenes Thema aufgemacht "HM-LC-Sw1-FM lässt sich nach DELETE DEVICE nicht mehr erneut anlernen" https://forum.fhem.de/index.php/topic,94102.0.html (https://forum.fhem.de/index.php/topic,94102.0.html) bei dem sich herausstellte, dass ich dasselbe Problem "HM-LC-SW1-FM wird als HM-LC-SW2-FM erkannt" habe. Übrigens ebenfalls mit einem gebrauchten und einem neuen Aktor, daher vermute ich, dass es was mit meinem letzten Update von FHEM zu tun hat (Revision: 17469).
Wie ich Euch verstanden habe, scheinst Du es händisch hinbekommen zu haben, den Aktor wieder zum laufen zu bringen?! Ich kriegs leider nicht hin und verstehe nicht genau, was mit "losche die zwei Define von den kanälen xxxxxx01 xxxxxx02" gemeint ist. Soll ich wirklich beide löschen, also auch denjenigen, den ich eigentlich zum schalten brauche? bei mir "channel_01 HM_65CA36_Sw_01" und "channel_02 HM_65CA36_Sw_02"?
Hier ist mein Eventverlauf, von RESET mit Anlernen, Modeländerung und Löschen von channel_02":
2018-12-09 12:09:57 CUL_HM HM_65CA36 powerOn: 2018-12-09 12:09:57
2018-12-09 12:09:57 CUL_HM HM_65CA36_Sw_01 deviceMsg: off (to broadcast)
2018-12-09 12:09:57 CUL_HM HM_65CA36_Sw_01 level: 0
2018-12-09 12:09:57 CUL_HM HM_65CA36_Sw_01 pct: 0
2018-12-09 12:09:57 CUL_HM HM_65CA36_Sw_01 off
2018-12-09 12:09:57 CUL_HM HM_65CA36_Sw_01 timedOn: off
2018-12-09 12:10:06 CUL_HM HM_65CA36 Info_Cleared
2018-12-09 12:10:11 CUL_HM HM_65CA36_Sw_02 unreachable
2018-12-09 12:10:16 Global global DELETED HM_65CA36_Sw_02
2018-12-09 12:10:17 HMLAN HMCFGLAN loadLvl: low
2018-12-09 12:10:36 Global global ATTR HM_65CA36 model HM-LC-SW1-FM
2018-12-09 12:10:42 HMLAN HMCFGLAN loadLvl: low
2018-12-09 12:11:01 CUL_HM HM_65CA36 CMDs_pending
2018-12-09 12:11:01 CUL_HM HM_65CA36 CMDs_pending
2018-12-09 12:11:01 CUL_HM HM_65CA36 CMDs_pending
2018-12-09 12:11:07 HMLAN HMCFGLAN loadLvl: low
2018-12-09 12:11:19 CUL_HM HM_65CA36 ResndFail
2018-12-09 12:11:19 CUL_HM HM_65CA36 CMDs_done_Errors:1
2018-12-09 12:11:19 CUL_HM HM_65CA36 RESPONSE TIMEOUT:RegisterRead
2018-12-09 12:11:32 HMLAN HMCFGLAN loadLvl: low
Internals:
CFGFN
DEF 65CA36
HMCFGLAN_MSGCNT 2
HMCFGLAN_RAWMSG E65CA36,0000,5981D4C0,FF,FFB9,00841065XXXXX6010000
HMCFGLAN_RSSI -71
HMCFGLAN_TIME 2018-12-09 12:09:57
IODev HMCFGLAN
LASTInputDev HMCFGLAN
MSGCNT 2
NAME HM_65CA36
NOTIFYDEV global
NR 176
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
channel_01 HM_65CA36_Sw_01
protCmdDel 3
protResnd 3 last_at:2018-12-09 12:11:14
protResndFail 1 last_at:2018-12-09 12:11:19
protSnd 1 last_at:2018-12-09 12:11:01
protState CMDs_done_Errors:1
rssi_at_HMCFGLAN cnt:2 min:-71 max:-68 avg:-69.5 lst:-71
READINGS:
2018-12-09 12:09:44 D-firmware 2.8
2018-12-09 12:09:44 D-serialNr OEQXXXX779
2018-12-09 12:12:44 RegL_00.
2018-12-09 12:09:57 powerOn 2018-12-09 12:09:57
2018-12-09 12:11:19 state RESPONSE TIMEOUT:RegisterRead
helper:
HM_CMDNR 1
PONtest 0
cSnd 0103140865CA36010E,0103140865CA3600040000000000
mId 0009
regLst ,0
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +65CA36,00,00,00
nextSend 1544353797.79549
prefIO
rxt 0
vccu
p:
65CA36
00
00
00
mRssi:
mNo 00
io:
HMCFGLAN:
-69
-69
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
at_HMCFGLAN:
avg -69.5
cnt 2
lst -71
max -68
min -71
tmpl:
Attributes:
IODev HMCFGLAN
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.8
model HM-LC-SW1-FM
room CUL_HM
serialNr OEQXXXX779
subType switch
webCmd getConfig:clear msgEvents
Also wenn ich jetzt beide Kanäle lösche und webCmd in FHEM.cfg wie geschrieben verändere schauts zwar besser aus, aber ich bekomme in den Readings trotzdem "MISSING ACK" und bei protState steht "CMDs_dome_Errors:1" und der Aktor reagiert nicht auf ON/OFF:
Internals:
DEF 65CA36
IODev HMCFGLAN
NAME HM_65CA36
NOTIFYDEV global
NR 49
STATE MISSING ACK
TYPE CUL_HM
protCmdDel 7
protResnd 12 last_at:2018-12-09 12:36:29
protResndFail 4 last_at:2018-12-09 12:36:34
protSnd 4 last_at:2018-12-09 12:36:15
protState CMDs_done_Errors:1
READINGS:
2018-12-09 12:29:02 D-firmware 2.8
2018-12-09 12:29:02 D-serialNr OEQXXXX779
2018-12-09 12:35:22 RegL_00.
2018-12-09 12:29:15 powerOn 2018-12-09 12:29:15
2018-12-09 12:36:34 state MISSING ACK
helper:
HM_CMDNR 68
cSnd 0103140865CA36010E,1103140865CA360201C80000
dlvl C8
dlvlCmd ++A01103140865CA360201C80000
mId 0004
regLst ,0
rxType 1
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +65CA36,00,00,00
prefIO
rxt 0
vccu
p:
65CA36
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
tmpl:
Attributes:
IODev HMCFGLAN
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.8
model HM-LC-SW1-FM
room CUL_HM
serialNr OEQXXXX779
subType switch
webCmd statusRequest:toggle:on:off
das device sendet eine "config-msg" wenn man config drückt. Diese kann man nicht erzwingen. Wenn also diese config-msg erkannt wird,wrid sie verarbeitet. FHEM merkt sich alle Daten und legt - falls erforderlich - alle entities an.
Bei einem Device mit einem Kanal ist es nur eine Entity - also alles in Butter.
Dein Device ist aber nicht gepairt. Es wird kommandos von FHEM nicht akzeptieren.
also probiere ein
set HMCFGLAN hmPairSerial OEQXXXX779
dann lese die Daten des Device aus
set HM_65CA36 getConfig
attr HM_65CA36 autoReadReg 5_readMissing
SUUPPEERR! Das wars, endlich gehts, wielen Dank!!! :D :D :D
Hallo,
ich hatte die Zeilen manuell aus der fhem.cfg gelöscht.
Damit ging es dann ohne Probleme und ohne Fehlermdlungen.
Auch bei meinem Dimmer hatte ich das Problem, dass ich auch über die fhem.cfg gelöst habe.
Hauptsache es funktioniert nun für Dich.
lg, Gerhard
Hallo,
ich habe das gleiche Problem.
Der letzte HM-LC-SW1-FM (mit FW 2.8 ) den ich mir vor kurzem gekauft hatte wird als HM-LC-SW2-FM erkannt.
Das sowohl unter FHEM, als auch mit der Konfigurations-SW von Homematic und dem HM USB Konfigurations-Adapter (HM-CFG-USB2).
Im Screenshot (siehe Anhang) von der Konfig-SW ist ein HM-LC_SW2-FM gezeigt mit zwei Kanälen (so wie es sein sollte).
Der Besagte HM-LC-SW1-FM wird sls SW2 mit nur mit einem Kanal angezeigt.
Bei mir funktioniert er soweit in FHEM. Einziges Problem - welches nicht weiter stört - ist, dass ein
set DEVICE getConfig
immer mit:
RESPONSE TIMEOUT:RegisterRead
endet.
Scheint ein Problem mit der FW2.8 zu sein.
Gruß,
Jürgen.
Mich beschleicht ja direkt der Verdacht, dass eQ3 neuerdings eine vollständig einheitliche Firmware auf die Dinger bügelt und es der CCU überlässt herauszufinden, ob der Schalter dann einen oder zwei Kanäle hat. Allerdings ist ja die Bezeichnung des Aktors dann auch falsch (SW2 statt SW1).
Wenn das so weitergeht, müssen wir Martin um eine ähnliche Automatik anbetteln...
@sensorle: lösche den zweiten Kanal in FHEM...
Hi Pfriemler,
habe den zweiten Kanal gelöscht.
getConfig funktioniert jetzt ohne Fehlermeldung. Danke für den Tipp!
Die falsche Anzeige des HM-LC-SW1-FM bleibt natürlich.
Gruß,
Jürgen.
Hallo,
mir ist eben aufgefallen, dass ich zwei Aktoren HM-LC-SW1-FM - ebenfalls - mit FW 2.8 habe, die sich richtig anmelden. Sowohl in FHEM, als auch in der Konfigurations-SW des USB-Konfigurators.
Evtl. also doch ein HW Defekt oder eine falsch konfigurierte HW?
Das Model wird von FHEM (ausschliesslich) an der ModelID erkannt welche in der Config message übertragen wird. Ich kann die MID nicht selbst auslesen.
Die ModelID 0009 ist dem HM-LC-Sw2-FM zugewiesen.
Mit
get hm models -f LC-S
bekommst du die Model Typen mit ihren IDs.
Wenn sich ein Device nicht mit der entsprechenden ID meldet könnte ich einen Fehler gemacht haben (in diesem Fall nicht) oder eq3 hat es nicht korrekt geflasht
Martin, es darf als erwiesen gelten, dass einige dieser Aktoren (Sw1-FM und Sw2-FM) in letzter Zeit - und zwar kreuzweise - falsche mID liefern. Deine Erkennung arbeitet vermutlich korrekt, vermutlich hat eQ3 fehlerhaft geflasht.
Der von sensorle hier gezeigten Screenshot zeigt ja sogar eine Falschanmeldung im Konfigurator, wobei dieser aus irgendeinem Grund in der Lage ist, nicht existierende Kanäle selbständig auszublenden. So ein Test im Hintergrund kann erst nach gesicherter Kommunikation erfolgen. Wenn man hier aus FHEM heraus korrigierend eingreifen wöllte, müsste man nach - etwa im Rahmen eines configChecks getConfigs von den Kanälen anfordern, bei gesicherter Kommunikation mit Kanal 1 den Kanal 2 mehrmals probieren - und dann den Kanal 2 löschen. Welche Gefahren sich daraus ergeben, dürfte klar sein. Allenfalls könnte man den User fragen, ob er einen 1- oder 2-Kanaler verbaut hat, und die Löschung so - auf sein Risiko - anbieten - bzw. das Model sauber neukonfigurieren, d.h. mit einer anderen MID und allen entsprechenden Folgen (reiner Einkanaler Device/Switch).
Zitatvermutlich hat eQ3 fehlerhaft geflasht.
korrekt. Kann ich erst einmal nichts machen.
Zitatin der Lage ist, nicht existierende Kanäle selbständig auszublenden.
gut möglich. Es gibt da weitere Infos im XML über die Anzahl der Kanäle. Die kann ich nicht auslesen.
ZitatWenn man hier aus FHEM heraus korrigierend eingreifen wöllte, müsste man nach - etwa im Rahmen eines configChecks getConfigs von den Kanälen anfordern, bei gesicherter Kommunikation mit Kanal 1 den Kanal 2 mehrmals probieren - und dann den Kanal 2 löschen.
So weit korrekt. Allerdings will ich so einen workround nicht einbauen. Das ist sehr viel gebastel.... no!
CUL_HM speichert nicht die ModelID (MID) sondern das Model (besser lesbar, kein wirklicher Grund).
FHEM wird beim Empfang jeder Config msg die Konfiguration kompletieren, also fehlende Kanäle anlegen. Das werde ich auch nicht ändern.
Die saubere Lösung ist ein neues Attribut
modelForce. Der gestresste Anwender kann hier einen Model-namen eintragen worauf hin die gelesene MID ignoriert wird. Das klappt dann immer.
Ist aber einiges an Umstellung, da die Basis geändert wird. Ich werde wohl bis morgen brauchen :)
Zitat von: martinp876 am 03 Januar 2019, 16:54:21
Die saubere Lösung ist ein neues Attribut modelForce. Der gestresste Anwender kann hier einen Model-namen eintragen worauf hin die gelesene MID ignoriert wird. Das klappt dann immer.
Ist aber einiges an Umstellung, da die Basis geändert wird. Ich werde wohl bis morgen brauchen :)
Alle Daumen hoch, das ist genau die richtige Lösung. Und sie darf auch viel länger brauchen...
Strukturell kämpfe ich noch mit der wilden Struktur von fhem. Ich erinnere mich, dass model "ungefragt" von unterschiedlichen Modulen genutzt wird. Jetzt muss ich also Model ändern um konsistent zu bleiben. Dabei will ich aber den original Wert nicht verlieren.
Wie einfach wäre es mit einer saubren Interface struktur. Da könnte ich den wert einfach korrekt zusammen basteln.
Genug gejammert, ich feile noch etwas.
Hallo Martin,
also mit
get hminfo models -f LC-S
bekomme ich folgendes Resultat (siehe Screenshot)
die ID 0009 kommt vor.
Ich habe aber auch tatsächlich einen HM-LC-Sw2-FM im Einsatz.
In der Datei .dev auf meinem Win7 Rechner, die von der Konfigurator-SW angelegt wird sieht die erste Zeile übrigens so aus:
<device serial="OEQ2071909" type="HM-LC-Sw2-FM" address="0x65C6E2" aes_key_index="1" firmware_version="2.8" bidcos_interface="JEQ0700648" sysinfo="00800065C6E21EBB7E2800094F45513230373139303910010100">
ich vermute mal stark, dass die fett markierten Ziffern die ModulID ist - und damit eindeutig falsch.
Vielen Dank, dass du eine Lösung für dieses Fehler von eQ3 in FHEM in Aussicht stellst! :) :)
PS:
Angelernt habe ich den Switch übrigens über die Seriennummer - also nicht über Tastendruck
0009 ist das 2kanalige. 0004 ist das 1kanalige.
Die 0009 hast du korrekt erkannt
Die config message kommt auch bei pairserial. Hm..... gute Idee - könnte man evtl nutzen. Hätte ich auch drauf kommen können.
Anbei die neue Version - mal zum Testen.
Top Level: Das Attribut modelForce überschreibt das Attribut model. Liegt der Bug vor muss man hier das korrekte Model eintragen.
Low Level:
Die Reconfig greift jetzt härter durch. Unbekannte Kanäle (nicht in der Config den Models) werden gelöscht.
Attribute model, subType und .mId sind von User nicht änderbar - und sollten es auch nicht.
Kollateral-Funktionen: Man kann ein Device simulieren. Legt man ein Device leer an kann man das Model setzen. Dann werden alle Kanäle angelegt. Man kann die regList einsehen alsoauch die cmdList.
Bitte prüfen, ob es hackt.
Zitat von: martinp876 am 04 Januar 2019, 12:51:43
Kollateral-Funktionen: Man kann ein Device simulieren. Legt man ein Device leer an kann man das Model setzen. Dann werden alle Kanäle angelegt. Man kann die regList einsehen alsoauch die cmdList.
Das ist eine super Idee. Endlich kann ich ein Test-System mit meinen HM-Devices anlegen ohne alles in Dummies wandeln zu müssen.
Huh ... das ist spaßig! ;D
Meinen HM-LC-Sw2-FM als Sw1 zu redefinieren hat funktioniert. Ein Kanal weg, es schaltet weiterhin die 1.
Dann habe ich mal einen HM-LC-Sw4-DR draus gemacht. Vier Kanäle, bei drei und vier erwartungsgemäß MISSING_ACK.
Dann wieder einen HM-LC-Sw2-FM ...
Und nun habe ich ein Gerät mit model HM-LC-Sw2-FM, einen 1. Kanal mit model HM-LC-Sw2-FM und einen zweiten Kanal mit model HM-LC-Sw4-DR ???
Problem also: Das Model in den Kanälen wird nur aktualisiert, wenn der betreffende Kanal automatisch hinzugefügt wurde, aber nicht bei bestehenden. Kreuztest nach Restart: Ändert man den HM-LC-Sw2-FM in einen HM-LC-Sw1-FM, bleibt in seinem nun noch einzigen Kanal ein HM-LC-Sw2-FM als model stehen.
Und im übrigen halte ich modelForce in den Kanälen für überflüssig. Oder was spricht dafür, es dort zu lassen?
Ansonsten aber: KLASSE!
Uuuh ... doch eine Nebenwirkung. Im so umgebauten/rekonfigurierten HM-LC-Sw2-FM wirft das Ausschalten des zweiten Kanals (und nur dieses) einen Fehler im Log:
2019.01.04 13:50:05 3: CUL_HM set HM_42A296_Sw_02 off
2019.01.04 13:50:09 1: PERL WARNING: Use of uninitialized value $cmd in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 4127.
2019.01.04 13:50:09 1: stacktrace:
2019.01.04 13:50:09 1: main::__ANON__ called by ./FHEM/10_CUL_HM.pm (4127)
2019.01.04 13:50:09 1: main::CUL_HM_Set called by fhem.pl (3605)
2019.01.04 13:50:09 1: main::CallFn called by fhem.pl (1811)
2019.01.04 13:50:09 1: main::DoSet called by fhem.pl (1844)
2019.01.04 13:50:09 1: main::CommandSet called by fhem.pl (1218)
2019.01.04 13:50:09 1: main::AnalyzeCommand called by fhem.pl (1064)
2019.01.04 13:50:09 1: main::AnalyzeCommandChain called by ./FHEM/90_at.pm (181)
2019.01.04 13:50:09 1: main::at_Exec called by fhem.pl (3153)
2019.01.04 13:50:09 1: main::HandleTimeout called by fhem.pl
Das scheint jetzt auch noch andere Geräte zu verwirren ... Bin erst mal auf die alte 10_CUL_HM zurück...
Die re-definition und das Anlegen der Kanäle wird mit jeder Config Message geprüft. Schon immer.
Bestehende Kanäle werden nicht gelöscht. Es wird das Model geändert und die SubType Info kommt eh aus den Device.
=> der Kanal behält den Namen und die Attribute (auser model)
=> Auch gelesene Registerwerte würden erst einmal bleiben. Bis man ein getConfig macht (was bei autoReadReg automatisch, Zeitversetzt passieren sollte).
Der Kanal 1 bleibt immer erhalten, so er existiert. Ein formaler Anwender spaltet auch ein-Kanal Devices in Kanal 1 und Device. Somit darf ich diesen nicht löschen.
Der Fehler bei dir ist Seltsam. kannst du ein
set HM_42A296_Sw_02 ?
ausführen und mir schicken? Und sicherheitshalber ein List des Device und Kanal.
Zitat von: martinp876 am 04 Januar 2019, 15:01:12
... Bestehende Kanäle werden nicht gelöscht.
Doch ... nach dem Setzen von modelForce auf HM-LC-Sw1-FM hatte der Sw2 seinen zweiten Kanal verloren.
ZitatEs wird das Model geändert
Wurde eben gerade nicht. Blieb auf HM-LC-Sw2-FM. Ich habe allerdings kein getConfig gemacht. In den Kanälen, wohlgemerkt. Im Device ändert sich die model-Bezeichnung.
ZitatDer Kanal 1 bleibt immer erhalten, so er existiert. Ein formaler Anwender spaltet auch ein-Kanal Devices in Kanal 1 und Device. Somit darf ich diesen nicht löschen.
Finde ich auch gut so. Ich bin allerdings auch nicht formal, habe noch nie Einkanaler in Gerät und Kanal gespalten.
Zitat
Der Fehler bei dir ist Seltsam. kannst du ein
set HM_42A296_Sw_02 ?
ausführen und mir schicken? Und sicherheitshalber ein List des Device und Kanal.
Nicht sofort. Ich bin ja erst mal wieder zurück auf die offizielle Version, weil das hier mein Produktivsystem ist (habe keine anderen) und vor dem Wochenende ist ein logmüllendes System kontraproduktiv ;D
Ok, schlecht ausgedrückt. Besteht ein Kanal und wird er im neuen Model benötigt wird er nicht gelöscht.
Oder: überzählige werden gelöscht, fehlende kreiert.
Das attr model aller entities muss geändert werden. Alle haben dann das gleiche. Prüfe ich gleich. Nicht mit dem namen verwechseln. Namen gehören dem Anwender. Ich trage nur einen default ein.
Ich bin auch nicht konsequent. Habe allerdings gerade erst 2 einkanäler gesplittet. Auf der Webseite sehe ich dann eine Gruppe devices und eine Gruppe Kanäle.
Ok, dann schaue ich, was ich so sehen kann. Bei meinem Versuch hat sich nichts verhädert
da hast du mich doch erwischt. Das Kommando war eine Zeile zu hoch :)
Was ich allerdings nicht verstehe: welche Probleme hat es sonst gegeben? In welchem Bereich? Ich nehmen an, dass du mit modelForce nur an einem Device gespielt hast. Waren auch andere betroffen?
Zitat von: martinp876 am 04 Januar 2019, 16:40:50
da hast du mich doch erwischt. Das Kommando war eine Zeile zu hoch :)
Genau, nicht nur neu angelegte Kanäle eines Gerätes be_model_n, sondern alle.
Zitat
Was ich allerdings nicht verstehe: welche Probleme hat es sonst gegeben? In welchem Bereich?
Ich nehmen an, dass du mit modelForce nur an einem Device gespielt hast. Waren auch andere betroffen?
Soweit ich gesehen habe, waren keine anderen betroffen. mit $cmd hast Du ja auch was geändert, also sehen wir mal.
Aktuell, nach reload, schaltet alles fehlerfrei.
modelForce wird auch in den Kanälen angeboten - aber der Versuch es zu setzen, wird mit "only valid for devices" zurückgewiesen. Gut.
1. Sw2-Fm wird zum Sw1-FM. Es wird Kanal 2 gelöscht. Kanal 1 behält model HM-LC-SW2-FM.
2. Sw2-Fm wird zum Sw4-DR. Es werden alle Kanäle umbenannt.
3. Sw4-DR wird zum Sw1-FM. Drei Kanäle werden gelöscht, Kanal 1 model heißt immer noch HM-LC-Sw4-DR.
4. Sw1-FM wird zum Sw2-FM. Die Kanalmodels stimmen wieder alle.
Ergo: Werden nur Kanäle gelöscht, bleibt es beim alten. Werden neue hinzugefügt, dann werden auch alle umbe_model_t.
Ich blick's nicht, warum.
Dann: nach dieser Aktion liefert "set <Aktorchannel> ?"
...Sw_01: Unknown argument ?, choose one of clear getConfig getRegRaw inhibit off on-for-timer on-till on peerBulk peerIODev press regBulk regSet sign statusRequest templateDel toggle
...Sw_02: Unknown argument ?, choose one of clear getConfig getRegRaw inhibit off on-for-timer on-till on peerBulk peerIODev regBulk regSet statusRequest templateDel toggle
Im zweiten Kanal fehlt "press" und "sign".
Richtig spooky wird es, wenn man jetzt modelForce löscht. Das schmeißt wieder alles bis auf den ersten Kanal raus, das model und subtype sind gelöscht und auch der erste Schaltkanal unbedienbar, weil on und off etc. fehlen. Überhaupt wird es jetzt zum HM-Dummy, inkl. dessen Menü-dropdowns.
model händisch zu setzen gibt einen Hinweistext - sehr gut.
Setzt man modelForce wieder, wird es wieder und alles funktioniert.
Ansonsten muss man das Gerät löschen und neu anlernen, damit es von autocreate angelegt wird.
Viel Stoff, ich weiß... aber es muss ja nicht alles heute sein... ;D ;D
ZitatmodelForce wird auch in den Kanälen angeboten
Ziemlich nervig. Leider gibt es keine wirklich gute möglichkeit attribute auf relevante entities zu begrenzen (analog Command)
Zitat2. Sw2-Fm wird zum Sw4-DR. Es werden alle Kanäle umbenannt.
nein. Umbenannt wird nie ein Kanal. Die Namen sind zufällig gleich.
Zitat3. Sw4-DR wird zum Sw1-FM. Drei Kanäle werden gelöscht, Kanal 1 model heißt immer noch HM-LC-Sw4-DR.
Bei mir heist er y_Sw_01. Vorher wie nachher
HM-LC-SW4-DR angelegt
NAME y
channel_01 y_Sw_01
channel_02 y_Sw_02
channel_03 y_Sw_03
channel_04 y_Sw_04
Zitatgeändert nach HM-CC-RT-DN
channel_01 y_Sw_01
channel_02 y_Sw_02
channel_03 y_Sw_03
channel_04 y_Sw_04
channel_05 y_ClimaTeam
channel_06 y_remote
namen NICHT geändert
Geändert nach HM-LC-SW1-FM und Kanal 1 gelöscht
- kein KanalZitatgeändert nach HM-CC-RT-DN
channel_01 y_Weather
channel_02 y_Climate
channel_03 y_WindowRec
channel_04 y_Clima
channel_05 y_ClimaTeam
channel_06 y_remote
neue Namen
geändert nach HM-LC-SW2-FM
channel_01 y_Weather
channel_02 y_Climatenamen stabil
geändert nach HM-RC-19-B
channel_01 y_Weather
channel_02 y_Climate
channel_03 y_Btn_03
channel_04 y_Btn_04
channel_05 y_Btn_05
channel_06 y_Btn_06
channel_07 y_Btn_07
channel_08 y_Btn_08
channel_09 y_Btn_09
channel_0A y_Btn_10
channel_0B y_Btn_11
channel_0C y_Btn_12
channel_0D y_Btn_13
channel_0E y_Btn_14
channel_0F y_Btn_15
channel_10 y_Btn_16
channel_11 y_Btn_17
channel_12 y_Dispkeine Namensänderung existierender Kanäle.
ZitatRichtig spooky wird es, wenn man jetzt modelForce löscht.
nun - sollte nicht sein. Aber hast du einmal restartet? Das ist notwendig. Dann wird für jedes Device das hidden Attribut ".mId" angelegt. Löschst du modelForce wird auf das orginal zurückgeschaltet.
Man sollte also dazu sagen, dass man einen Reboot durchführen sollte. Und dann ein Save.
Mache ein Backup deiner .cfg files vorab.
ZitatViel Stoff, ich weiß... aber es muss ja nicht alles heute sein..
eigentlich nicht. Nur das mit dem Fehlenden Kommando muss ich noch suchen. Aber danke fürs testen.
Du kannst mit
Zitat{$attr{<devName}{".mId"}="0009"}
die mId setzen (ohne netz und doppelten Boden).
Wenn du nun modelForce löschst ist alles gut. Du wirst den 2-kanaler erhalten.
Moinmoin,
ich war etwas unpräzise und Du hast es anders verstanden. Es ging nie um die Namen, sondern um das Attribut model in den Kanälen. Die Kanäle werden richtig benannt wenn sie hinzugefügt werden, aber model ändert sich eben nur beim Zufügen von Kanälen, die zurechtgerückte Zeile hat das Problem nur halb gelöst...
Der .mId-Mechanismus klingt gut. Habe ich nicht gesehen, die aber beim list zu sehen sein.
Habe ich es richtig verstanden: das .mId wird bei jedem HM-Gerät bei einem Neustart angelegt? Dann sollte das ja ausreichen, ich hatte gestern beim zweiten Versuch nur reloaded. Nach (!) dem Löschen von modelForce half ein Neustart jedenfalls nichts mehr.
In jedem Fall sollte aber sichergestellt sein, dass ein User in einer Sitzung modelForce anlegen und wieder löschen kann, daher muss es auch beim (auto)create angelegt werden (ich habe noch nicht geprüft ob das so ist.
Ich hätte. mId an das Zufügen von modelForce geknüpft: ist es noch nicht vorhanden, wird model nach .mId gerettet...
Wenn man Attribute bei den Kanälen nicht ausblenden kann ... das ist kein Beinbruch. Das Popup erklärt ja den Fehlversuch und hilft beim Lernen.
das mit dem fehlenden Kommando kann ich nicht erkennen. Siehe Ablauf.
delete Tasse
define Tasse CUL_HM C0FFEE
attr Tasse modelForce HM-LC-SW2-FM
attr Tasse modelForce HM-LC-SW4-DR
attr Tasse modelForce HM-LC-SW2-FM
attr Tasse modelForce HM-LC-SW2-FM
set Tasse_Sw_01 ?
Unknown argument ?, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw inhibit:on,off off:noArg
on-for-timer on-till on:noArg peerBulk peerIODev press regBulk regSet sign:on,off statusRequest:noArg templateDel toggle:noArg
set Tasse_Sw_02 ?
Unknown argument ?, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw inhibit:on,off off:noArg
on-for-timer on-till on:noArg peerBulk peerIODev press regBulk regSet sign:on,off statusRequest:noArg templateDel toggle:noArg
ja, beim ein-kanaler hatte ich model vergessen. Ist korrigiert.
ZitatHabe ich nicht gesehen, die aber beim list zu sehen sein.
attr global schoInternalValues 1muss gesetzt sein. Sonst wird es nicht angezeigt. Leider auch nicht bei list.
Zitatdas .mId wird bei jedem HM-Gerät bei einem Neustart angelegt?
nein, wäre kontraproduktiv. Es ist erst einmal ein Attribut welches gespeichert wird. Ist nach dem Laden das Attribut nicht zu sehen, wird es aus model zurückgerechnet und gesetzt.
.mId wird ggf beim Empfang einer configmessage auf den dort empfangenen Wert gesetzt.
ZitatNach (!) dem Löschen von modelForce half ein Neustart jedenfalls nichts mehr.
zu wenig details. Wenn du reloaded hattest und das Device existierte sollt .mId existent gewesen sein.
Der Ablauf:
- du legst device an, setzt modelForce => model wird gesetzt
- du löschst modelForce => rückbau auf basis von .mId. Da es nicht vorhanden ist bleibt model leer. Ein virtuelles Device
- du setzt modelForce, speicherst und reloadest => .mId wird auf basis model gesetzt.
- du löschst modelForce => model wird auf Basis .mId neu berechnet - bleibt also unverändert
ZitatIn jedem Fall sollte aber sichergestellt sein, dass ein User in einer Sitzung modelForce anlegen und wieder löschen kann
kann er doch. Beachte, was das Ziel ist. Man kann den eQ3 Bug umgehen. Oder ein Dummy erstellen welches die Register und Kommandos wiedergibt. Das sollte alles prima abgedekt sein. Es geht nichts kaputt.
Wenn ein User einen ordentlichen Update macht erfolgt ein Reboot. Ein Reload des cul_hm ist nicht ausreichend, da .mId nicht angelegt wird.
Hallo,
habe die neue Version mal mit dem Schalter der sich falsch meldet getestet. Sorry, dass ich mich erst jetzt melde...
Wenn ich mit modelForce aus dem HM-LC-SW2-FM einen HM-LC-SW1-FM mache (was er ja tatsächlich ist), dann wird er angezeigt wie vorher, mit dem Unterschied, dass Kanal 2 entfernt wurde (siehe Screenshot 1).
Das ist ähnlich wie ich es vorher hatte, als ich den Kanal 2 mit DeletDevice glöscht hatte.
Im verbleibenden Kanal 1 steht dann immer noch HM-LC-SW2-FM als Attribut (siehe Screenshot 2).
Grundsätzlich sieht der mit modelForce geänderte Schalter aus wie ein Mehrfach Schalter mit einem Kanal. Damit unterscheidet er sich von einem "normalen" HM-LC-SW1-FM, bei dem keine Kanäle in den Internals angezeigt werden.
Fazit: Die Änderung funktioniert. FHEM verhält sich damit ähnlich wie die HM Konfigurations-SW meines USB-Sticks.
Danke Martin!
:)
Nachtrag:
musste bei allen anderen Devices ebenfalls modelForce ausführen.
Habe ich leider zu spät bemerkt - Sorry.
Siehe auch hier:
https://forum.fhem.de/index.php/topic,95409.msg882568.html#msg882568 (https://forum.fhem.de/index.php/topic,95409.msg882568.html#msg882568)
Ouu... Martin, da hat was noch nicht funktioniert.
Den allerletzten Zwischenstand kann ich jetzt nicht mehr nennen, aber in der vor dem heuten reboot gespeicherten fhem.cfg stand (in Auszügen):
define HM_42A296 CUL_HM 42A296
attr HM_42A296 .mId 0009
attr HM_42A296 IODev HMUART
attr HM_42A296 IOgrp vccu:HMUART
...
attr HM_42A296 model HM-LC-SW2-FM
...
attr HM_42A296 subType switch
...
define HM_42A296_Sw_01 CUL_HM 42A29601
...
attr HM_42A296_Sw_01 model HM-LC-SW2-FM
...
define HM_42A296_Sw_02 CUL_HM 42A29602
attr HM_42A296_Sw_02 model HM-LC-SW2-FM
Bis hierhin alles korrekt und funktionierend. Aber:
Nach dem Neustart finde ich ein rotes Fragezeichen: "structural changes: delete HM_42A296_Sw_02 CUL_HM 42A29602" - der zweite Kanal ist weg.
Gerätelist: model und subtype fehlen.
Internals:
DEF 42A296
IODev HMUART
NAME HM_42A296
NOTIFYDEV global
NR 908
NTFY_ORDER 50-HM_42A296
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_42A296_Sw_01
READINGS:
...
2019-01-05 12:42:04 .protLastRcv 2019-01-05 12:42:04
2019-01-04 17:56:08 D-firmware 2.8
...
2019-01-04 17:55:57 RegL_00. 00:00 02:01 0A:14 0B:11 0C:AB 15:FF 18:00
2019-01-05 12:41:18 powerOn 2019-01-05 12:41:18
2019-01-05 12:42:04 state CMDs_done
helper:
HM_CMDNR 65
mId
subType
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +42A296,00,01,00
rxt 0
vccu vccu
p:
42A296
00
01
00
prefIO:
HMUART
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
tmpl:
Attributes:
.mId 0009
IODev HMUART
IOgrp vccu:HMUART
alias HM_42A296 (2fach Switch UP, Fundus)
...
subType
webCmd getConfig:clear msgEvents
model:
beachte vor allem die letzte Zeile: Der Doppelpunkt steht im list, im Web-Def fehlt das Attribut komplett.
Im (einzigen) Kanal befindet sich noch das korrekte model-Attribut.
Ich mach erst mal nix weiter...
Ach du dicke Scheiße ... hier gab es nach einem weiteren Neustart gerade massiven Kahlschlag, alle models meiner HM-Geräte sind weg.
Ich muss jetzt einen shutdown fahren, das official 10_CUL_HM.pm einspielen und die Config restoren.
Alle die ihr das hier bisher verwendet - schaut mal wie es Euch ergeht ...
Zitat von: Pfriemler am 07 Januar 2019, 11:08:56
Ach du dicke Scheiße ... hier gab es nach einem weiteren Neustart gerade massiven Kahlschlag, alle models meiner HM-Geräte sind weg.
Ich muss jetzt einen shutdown fahren, das official 10_CUL_HM.pm einspielen und die Config restoren.
Alle die ihr das hier bisher verwendet - schaut mal wie es Euch ergeht ...
So wie ich das Forum lese: Das Problem gibt es auch mit der Version aus dem SVN. Du solltest dir also eher eine aus dem Restore/Backup holen ...
@ Pfriemler
https://forum.fhem.de/index.php/topic,95409.0.html (https://forum.fhem.de/index.php/topic,95409.0.html)
Umso schlimmer, dass es jetzt alle betrifft ... :-\
Yep, ich habe aber kein Update gemacht, sondern die von Martin vor ein paar Tagen hier experimental eingestellte Version ausprobiert.
Die scheint jetzt etwas vorschnell den Weg ins SVN gefunden zu haben, nachdem die ersten Tests noch recht vielversprechend aussahen ...
aber martin wohl, da es bereits offiziell ein attr modelForce zu geben scheint.
@pfriemler
sag mal, hast du deinen beitrag #45 editiert?
bei meiner antwort #46 habe ich nur den ersten absatz aus #45 gesehen, auch ohne die fette überschrift. allerdings sehe ich nun keinen hinweis, dass du #45 editiert hättest.
ich bin total verwirrt und das nicht zum ersten mal.
muss ich dringend zum arzt? :-[
Ja hatte ich.
Nein, mit Dir ist alles gut.
Wenn man seinen eigenen Beitrag innerhalb der ersten Minute ändert, kommt der Hinweis auf die Änderung nicht.
Ich profitiere sehr davon als Zu-Schnell-Absender ;D
danke, das beruhigt mich etwas. :)
Habe noch einen Update eingestellt.
Bei virtuellen devices gab es noch ein Problem. Und ein paar weitere Details
Hallo,
also bei mir wissen auch mit dem neuen Update (und anschließendem Neustart) die Devices nicht mehr welches Model sie sind.
Als Beispiel der Auszug aus der FHEM.cfg vor und nach dem Update für einen Switch
Vor dem Update:
define LichtFlurEG CUL_HM 1F254C
attr LichtFlurEG IODev myHmUART
attr LichtFlurEG autoReadReg 4_reqStatus
attr LichtFlurEG expert 2_raw
attr LichtFlurEG firmware 1.9
attr LichtFlurEG model HM-LC-SW1-FM
attr LichtFlurEG peerIDs 00000000,1F254C01,20B84201,6224C801,
attr LichtFlurEG room FLurEG,CUL_HM
attr LichtFlurEG serialNr KEQ0034276
attr LichtFlurEG subType switch
attr LichtFlurEG webCmd statusRequest:toggle:on:off
define FileLog_LichtFlurEG FileLog /media/usb/LichtFlurEG-%Y.log LichtFlurEG
attr FileLog_LichtFlurEG logtype text
attr FileLog_LichtFlurEG room CUL_HM
nach dem Update
define LichtFlurEG CUL_HM 1F254C
attr LichtFlurEG .mId 0004
attr LichtFlurEG IODev myHmUART
attr LichtFlurEG autoReadReg 4_reqStatus
attr LichtFlurEG expert 2_raw
attr LichtFlurEG firmware 1.9
attr LichtFlurEG model HASH(0x1b42458)
attr LichtFlurEG peerIDs 00000000,1F254C01,20B84201,6224C801,
attr LichtFlurEG room FLurEG,CUL_HM
attr LichtFlurEG serialNr KEQ0034276
attr LichtFlurEG subType
attr LichtFlurEG webCmd statusRequest:toggle:on:off
define FileLog_LichtFlurEG FileLog /media/usb/LichtFlurEG-%Y.log LichtFlurEG
attr FileLog_LichtFlurEG logtype text
attr FileLog_LichtFlurEG room CUL_HM
attr LichtFlurEG model HASH(0x1b42458)
Mache ich was falsch oder liegts am Update?
Danke,
Jürgen
da es von 16Uhr heute ist, mußt du aus dem SVN holen , oder bis morgen fruh nach 8Uhr warten
Hallo Hary,
Ooops, das wusste ich nicht.
Habs eben aus dem SVN geholt.
Nach dem Neustart sind alle Devices noch wie sie sein sollten.
Wenn ich jetzt allerdings versuche meinen fälschlicherweise als HM-LC-Sw2-FM erkannten Schalter mit
attr LichtDusche modelForce HM-LC-SW1-FM
als HM-LC-SW1-FM zu deklarieren kommt die Meldung
invalid model name:HM-LC-SW1-FM. Please check options
mache ich noch was falsch?
Danke
Jürgen
Habe heute morgen noch mal ein komplettes Update durchgeführt (gestern Abend hatte ich nur die 10_CUL_HM.pm ersetzt).
Jetzt funktioniert modelForce!
Meine HM-LC-SW1-FM der sich fälschlicherweise als HM-LC-SW2-FM meldet (mit 2 Kanälen) wird nach
attr modelForce HMxxxx HM-LC-SW1-FM
ein Switch mit nur einem Kanal zur Auswahl.
Von einem echten HM-LC-SW1-FM unterscheidet er sich aber noch.
Auszug der fhem.cfg für einen echten HM-LC-SW1-FM:
define LichtFlurEG CUL_HM 1F254C
attr LichtFlurEG .mId 0004
attr LichtFlurEG IODev myHmUART
attr LichtFlurEG autoReadReg 4_reqStatus
attr LichtFlurEG expert 2_raw
attr LichtFlurEG firmware 1.9
attr LichtFlurEG model HM-LC-SW1-FM
attr LichtFlurEG peerIDs 00000000,1F254C01,20B84201,6224C801,
attr LichtFlurEG room FLurEG,CUL_HM
attr LichtFlurEG serialNr KEQ0034276
attr LichtFlurEG subType switch
attr LichtFlurEG webCmd statusRequest:toggle:on:off
define FileLog_LichtFlurEG FileLog /media/usb/LichtFlurEG-%Y.log LichtFlurEG
attr FileLog_LichtFlurEG logtype text
attr FileLog_LichtFlurEG room CUL_HM
Auszug der .cfg für den mit modelForce geänderten HM-LC-SW2-FM
define LichtFlurEG CUL_HM 1F254C
define LichtDusche CUL_HM 65C6E2
attr LichtDusche .mId 0009
attr LichtDusche IODev myHmUART
attr LichtDusche autoReadReg 4_reqStatus
attr LichtDusche expert 2_raw
attr LichtDusche firmware 2.8
attr LichtDusche model HM-LC-SW1-FM
attr LichtDusche modelForce HM-LC-SW1-FM
attr LichtDusche room CUL_HM
attr LichtDusche serialNr OEQ2071909
attr LichtDusche subType switch
attr LichtDusche webCmd getConfig:clear msgEvents
define FileLog_LichtDusche FileLog /media/usb/LichtDusche-%Y.log LichtDusche
attr FileLog_LichtDusche logtype text
attr FileLog_LichtDusche room CUL_HM
define LichtDusche_Sw_01 CUL_HM 65C6E201
attr LichtDusche_Sw_01 model HM-LC-SW1-FM
attr LichtDusche_Sw_01 peerIDs 00000000,20B71F01,65C6E201,
attr LichtDusche_Sw_01 room Bad
attr LichtDusche_Sw_01 webCmd statusRequest:toggle:on:off
Darf ich die fhem.cfg manuel so ändern, dass für den HM-LC-SW2-FM die Konfiguration des HM-LC-SW1-FM übernehme, also so:
define LichtFlurEG CUL_HM 1F254C
attr LichtFlurEG .mId 0004
attr LichtFlurEG IODev myHmUART
attr LichtFlurEG autoReadReg 4_reqStatus
attr LichtFlurEG expert 2_raw
attr LichtFlurEG firmware 1.9
attr LichtFlurEG model HM-LC-SW1-FM
attr LichtFlurEG peerIDs 00000000,1F254C01,20B84201,6224C801,
attr LichtFlurEG room FLurEG,CUL_HM
attr LichtFlurEG serialNr KEQ0034276
attr LichtFlurEG subType switch
attr LichtFlurEG webCmd statusRequest:toggle:on:off
define FileLog_LichtFlurEG FileLog /media/usb/LichtFlurEG-%Y.log LichtFlurEG
attr FileLog_LichtFlurEG logtype text
attr FileLog_LichtFlurEG room CUL_HM
Es funktioniert soweit. Der Switch wird jetzt angezeigt wie jeder andere HM-LC-SW1-FM.
Habe ich durch die manuelle Anpassung der fhem.cfg irgenwelche Effekte zu befürchten?
Danke,
Jürgen.
hallo martin,
ich habe gerade ein update gemacht und stelle folgendes im frontend fest:
1. beim attr model gibt es keine selectbox mehr. der aktuelle attr eintrag erscheint nur noch in einem textfeld.
für eigene devices, wie den universalsensor von dirk, gilt zusätzlich:
2. beim attr subType fehlen die "custom"-subtypes in der selectliste. der bereits vorhandene subtype im attribut wird allerdings noch in der attributübersicht angezeigt.
hallo martin,
schlimmer ist noch:
3. beim teamlead device fehlt jetzt das attr subType. ich kann es über das front end auch nicht setzen. wenn ich virtual aus der selectliste auswähle, erscheint ein popup mit der meldung: " subType illegal for virtual devices "
ohne das attribut fehlen wichtige events beim teamlead. bitte dringend fixen.
4. bei attr model steht jetzt: "VIRTUAL". war das nicht sonst kleingeschrieben? ich muss mal stöbern.
genau: sonst war attr model=virtual_X mit der anzahl der chn.
edit:
es betrifft bei mir alle virtuellen devices. (vccu, tc, teamlead, standard)
obwohl es auf der detailseite der virtuellen devices kein attr subType mehr gibt, zeigt "get hminfo param subType" bei allen virtuellen devices noch "virtual" an.
hast du das konzept der attribute bei virtuellen devices geändert?
Zitat von: frank am 08 Januar 2019, 12:27:57
bei attr model steht jetzt: "VIRTUAL". war das nicht sonst kleingeschrieben? ich muss mal stöbern.
es ist kleingeschrieben
hallo martin,
ZitatDie alten Versionen sind wieder eingecheckt. Ein weiteres Update sollte funktionieren.
Betroffen sind 10_CUL_HM.pm und HMConfig.pm
zur zeit habe ich noch die versionen von gestern.
10_CUL_HM.pm 18170 2019-01-07 15:48:38Z martinp876
HMConfig.pm 18171 2019-01-07 15:50:38Z martinp876
00_HMLAN.pm 18152 2019-01-05 23:18:38Z martinp876
98_HMinfo.pm 17838 2018-11-25 10:51:09Z martinp876
ZitatNun würde mich noch interessieren, wer sinnvoll beschreiben kann, was bei ihm passiert ist. Ich habe auch Rachmelder und Teamleads - die sind sauber upgedated worden mit der neuen SW.
Die Änderungen werden kommen - und wenn ich die Probleme kenne, kann ich diese korrigieren und testen.
ich könnte also noch weiter testen. vielleicht zuerst nur den teamlead.
ich habe gestern um ca 10:28 das update gestartet (siehe timestamps von state/peerList beim teamleadchannel).
kurz vorher hatte ich erfolgreich set alarmOn/alarmOff ausgeführt (siehe wiederum die timestamps).
nach dem update habe ich ebenfalls set alarmOn/alarmOff ausgeführt. die rauchmelder haben wieder erfolgreich aufgeheult und sich auch wieder beruhigt. soweit alles gut.
aber: im teamleadchannel wurden keine readings aktualisiert (ausser triggerCnt) und auch keine events generiert (siehe wieder die timestamps). auch ein wiederholtes set alarmOn/alarmOff, sowie ein zusätzliches set teamCall, haben keine readings aktualisiert. nur die rauchmelder haben immer korrekt geheult.
das device von meinem teamlead:
Internals:
DEF AAAAAA
IODev hmlan1
LASTInputDev hmuart1
MSGCNT 26
NAME SDTeam
NOTIFYDEV global
NR 396
NTFY_ORDER 50-SDTeam
STATE CMDs_done
TYPE CUL_HM
channel_01 SDTeam_Btn1
cul868_MSGCNT 13
cul868_RAWMSG A0B859440AAAAAA1ACE1F0002::-57:cul868
cul868_RSSI -57
cul868_TIME 2019-01-08 13:30:35
hmuart1_MSGCNT 13
hmuart1_RAWMSG 05000029859440AAAAAA1ACE1F0002
hmuart1_RSSI -41
hmuart1_TIME 2019-01-08 13:30:35
lastMsg No:85 - t:40 s:AAAAAA d:1ACE1F 0002
protLastRcv 2019-01-08 13:30:35
protRcv 13 last_at:2019-01-08 13:30:35
protRcvB 13 last_at:2019-01-08 13:30:35
protSnd 13 last_at:2019-01-08 13:30:35
protSndB 13 last_at:2019-01-08 13:30:35
protState CMDs_done
rssi_at_cul868 cnt:13 min:-58 max:-57 avg:-57.34 lst:-57
rssi_at_hmuart1 cnt:13 min:-41 max:-41 avg:-41 lst:-41
.attraggr:
.attrminint:
READINGS:
2019-01-08 13:30:35 .protLastRcv 2019-01-08 13:30:35
2019-01-08 13:30:35 state CMDs_done
2019-01-08 13:30:35 trigger Short_2
2019-01-08 13:30:35 trigger_cnt 2
helper:
BNO 2
BNOCNT 1
HM_CMDNR 133
mId FFF1
regLst ,0
rxType 1
subType virtual
supp_Pair_Rep 0
expert:
def 1
det 0
raw 0
tpl 0
io:
newChn
nextSend 1546950636.08554
rxt 0
vccu ccu
p:
prefIO:
hmlan1
mRssi:
mNo 85
io:
cul868:
-57
-57
hmlan1:
hmuart1:
-41
-41
hmusb1:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_cul868:
avg -57.3461538461538
cnt 13
lst -57
max -57
min -58
at_hmuart1:
avg -41
cnt 13
lst -41
max -41
min -41
shadowReg:
tmpl:
Attributes:
.mId FFF1
IODev hmlan1
IOgrp ccu:hmlan1
group Rauchmelder
model VIRTUAL
room 01_ALARM
webCmd virtualder channel von meinem teamlead:
Internals:
.triggerUsed 0
DEF AAAAAA01
NAME SDTeam_Btn1
NOTIFYDEV global
NR 397
NTFY_ORDER 50-SDTeam_Btn1
STATE unknown
TESTNR 2
TYPE CUL_HM
chanNo 01
device SDTeam
peerList SD.SZ,SD.WZ,SD.AZ,
sdTeam sdLead
.attraggr:
.attrminint:
READINGS:
2019-01-08 09:33:29 eventNo 0C
2019-01-08 09:33:29 level 1
2019-01-08 10:28:31 peerList SD.SZ,SD.WZ,SD.AZ,
2019-01-08 09:32:50 recentAlarm SDTeam
2019-01-08 09:33:29 smoke_detect none
2019-01-08 10:28:22 state unknown
2018-11-29 11:23:50 teamCall from SDTeam:5
2019-01-08 13:30:01 trigger_cnt 12
helper:
fkt sdLead1
regLst
expert:
def 1
det 0
raw 0
tpl 0
role:
chn 1
shadowReg:
tmpl:
Attributes:
group Rauchmelder
model VIRTUAL
peerIDs 52BB9001,52BB9D01,52C4DF01,
room 01_ALARM
webCmd alarmOn:alarmOff:teamCall:teamCallBatin den 2 list fallen mir 3 dinge auf:
1. attr subType existiert nicht mehr.
2. attr model ist nun VIRTUAL, war früher virtual_1.
3. es gibt keine rssi oder andere einträge über den hmlan1, obwohl er die kommunikation macht.
die punkte 1. und 2. gelten für alle virtuellen devices.
allerdings zeigt "get hminfo param subType" für alle virtuellen devices virtual an.
sag was du noch benötigst.