Nach dem Erfolg letztens probiere ich doch gleich mein Glück nochmal.
Ich habe einen HM-LC-SW1-BA-PCB seit ca. einem Jahr mit Pausen (da für Gartenbewässerung im Winter außer Betrieb) im Einsatz, ohne Schwierigkeiten damit festustellen - bis vor einigen Tagen.
Jetzt meldet er aber schon einige Male für längere Zeit (im Bereich mehrerer Minuten, beobachtet nicht länger als vielleicht 1/2 Stunde) MISSING ACK. Dann geht er wieder ohne weiteres. Empfang ist eigentlich gut (aktuell RSSI von zwei IODevs über VCCU -83 bzw -72).
Der Laie fragt sich nun: Gibt es vielleicht auch einen "Billigkondensator", der ausgetauscht werden kann/sollte? :o
Wie steuerst Du ihn an wenn er missing ack zeigt? Mit FHEM oder mit einem Peer -> Fernbedienung/andere Sensor?
Stichwort: peerNeedsBurst on
Gruß Otto
Ausschließlich mittels FHEM.
Die Tiefen der Möglichkeiten von Homematic sind mir noch verborgen.
ZitatEmpfang ist eigentlich gut (aktuell RSSI von zwei IODevs über VCCU -83 bzw -72).
-80 ist so die Grenze zwischen geht / geht nicht :)
Aber ist eigentlich ok. Ich habe auch einen HM-LC-SW1-BA-PCB der einmal im Jahr zickt. Da nehm ich ihn mal vom Strom und dann ist es wieder gut. hast Du probiert? Oder sowieso frisch eingeschaltet?
poste mal ein list vom aktor.
Er ist seit ca. April wieder im Einsatz und vorletztes Wochenende hatte ich ihn mal für einige Minuten getrennt vom Strom, wegen anderer Installationen. Aufgefallen ist mir das eben die letzten 2-3 Tage. Ich logge ja seinen Zustand mit und kann da sehen, dass es seit Dienstag zweimal auftrat (einzelne kurze Aussetzer ausßer Acht gelassen - ist halt Funk), früher kann ich nicht wirklich rekonstruieren, was ich da selber gerade gemacht habe.
Ist gut, ich beobachte einfach mal. Es ist kein wirklich kritscher Schalter. Ich steuere damit eines der Hauptventile der Gartenbewässerung. Schlimmstenfalls fällt halt mal eine Bewässerung aus. Nebenbei: Ist der Befehl "on-for-timer" wie bei FS20 auch intern oder durch FHEM realisiert?
Und zur Frage nach dem list:
Internals:
DEF 507161
FUUID 5c4e008f-f33f-10de-a8e1-400ae66cb2ba54de
HMLANGW_MSGCNT 80
HMLANGW_RAWMSG 050000528D80025071612807650101000049
HMLANGW_RSSI -82
HMLANGW_TIME 2019-08-30 11:54:04
HMUSB_MSGCNT 59
HMUSB_RAWMSG RE1F23CFD,0001,22BA1064,FF,FFB9,8D80025071612807650101000049
HMUSB_RSSI -71
HMUSB_TIME 2019-08-30 11:54:05
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 139
NAME HM_507161
NOTIFYDEV global
NR 1414
NTFY_ORDER 50-HM_507161
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:8D - t:02 s:507161 d:280765 0101000049
protCmdDel 23
protLastRcv 2019-08-30 11:54:04
protRcv 73 last_at:2019-08-30 11:54:04
protResnd 30 last_at:2019-08-30 07:55:12
protResndFail 22 last_at:2019-08-30 07:44:54
protSnd 92 last_at:2019-08-30 11:54:04
protSndB 109 last_at:2019-08-30 11:54:04
protState CMDs_done
rssi_HMLANGW cnt:3 min:-91 max:-83 avg:-86.66 lst:-83
rssi_HMUSB cnt:64 min:-87 max:-70 avg:-76.89 lst:-73
rssi_at_HMLANGW cnt:80 min:-87 max:-80 avg:-82.58 lst:-82
rssi_at_HMUSB cnt:59 min:-88 max:-69 avg:-76.84 lst:-71
READINGS:
2019-08-30 11:54:04 CommandAccepted yes
2017-06-29 22:10:57 D-firmware 1.7
2017-06-29 22:10:57 D-serialNr NEQ1580830
2019-08-17 19:21:19 PairedTo 0x280765
2018-07-03 21:06:25 R-pairCentral 0x280765
2017-06-29 22:01:56 R-sign off
2019-08-17 19:21:19 RegL_00. 00:00 02:01 05:00 0A:28 0B:07 0C:65 12:50
2019-08-17 19:21:19 RegL_01. 00:00 08:00
2019-08-30 11:54:04 battery ok
2019-08-30 11:54:04 deviceMsg off (to VCCU)
2019-08-30 11:54:04 level 0
2019-08-30 11:54:04 pct 0
2019-08-17 18:36:32 powerOn 2019-08-17 18:36:32
2019-08-30 11:54:04 recentStateType ack
2019-08-30 11:54:04 state off
2019-08-30 11:54:04 timedOn off
helper:
HM_CMDNR 141
cSnd 112807655071610201000000,112807655071610201000000
dlvlCmd ++A0112807655071610201000000
mId 006C
peerFriend peerSens,peerVirt
peerOpt 3:switch
regLst 0,1,3p
rxType 2
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +507161,00,00,00
nextSend 1567158844.91633
prefIO
rxt 0
vccu VCCU
p:
507161
00
00
00
mRssi:
mNo 8D
io:
HMLANGW:
-82
-82
HMUSB:
-69
-69
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rssi:
HMLANGW:
avg -86.6666666666667
cnt 3
lst -83
max -83
min -91
HMUSB:
avg -76.890625
cnt 64
lst -73
max -70
min -87
at_HMLANGW:
avg -82.5875
cnt 80
lst -82
max -80
min -87
at_HMUSB:
avg -76.8474576271187
cnt 59
lst -71
max -69
min -88
Attributes:
IODev HMUSB
IOgrp VCCU
alias Haupthahn_Garten
autoReadReg 4_reqStatus
devStateIcon off:time_manual_mode on:sani_water_hot@red
expert 2_raw
firmware 1.7
group Bewässerung
icon sani_water_tap
ignore 0
model HM-LC-SW1-BA-PCB
msgRepeat 1
peerIDs 00000000,
room Außen,CUL_HM,Pflanzen
serialNr NEQ1580830
subType switch
webCmd statusRequest:toggle:
on-for-timer macht der Aktor selbst.
@Otto123
Muss mir jetzt endlich mal die Zeit nehmen und Deinen Blog diesbezüglich zu studieren.
zeig noch ein list vom hmusb.
eventuell gibt es "aussetzer" beim io wechsel, wenn der hmusb "ausfällt".
Interessante Überlegung. Wobei ich beim HMUSB eigentlich keine Aussetzer wahrnehme, sondern eher beim HMLANGW/HMUARTLGW, daher hier mal beide Listings.
HMUSB:
Internals:
DEF 192.168.178.55:1234
DeviceName 192.168.178.55:1234
FD 19
FUUID 5c4e0080-f33f-10de-eb40-1cffaa6938572d53
HMUSB_MSGCNT 16022
HMUSB_TIME 2019-08-30 14:27:09
IFmodel USB
NAME HMUSB
NR 61
NTFY_ORDER 50-HMUSB
PARTIAL
RAWMSG E4AA1BC,0000,23463565,FF,FFB0,B6845E4AA1BC00000085AC9C0000000000093AFE
RSSI -80
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 7
msgKeepAlive dlyMax:18.184 bufferMin:-13
msgLoadCurrent 0
msgLoadHistoryAbs 5min steps: 0/0/0/0/0/0/0/0/0/0/0/0
msgParseDly min:-9191 max:9433 last:819 cnt:14627
owner 280765
owner_CCU VCCU
uptime 006 164:23:28.855
READINGS:
2019-08-27 16:16:18 D-HMIdAssigned 280765
2019-08-27 16:16:18 D-HMIdOriginal 3085C4
2019-08-27 16:16:18 D-firmware 0.967
2019-08-27 16:16:18 D-serialNr LEQ1197979
2019-08-27 16:16:18 Xmit-Events ok:1 disconnected:1 init:1
2019-08-27 16:16:18 cond ok
2019-08-30 14:27:14 loadLvl low
2017-11-27 17:00:15 prot_ERROR-Overload last
2018-01-21 22:15:29 prot_Warning-HighLoad last
2019-08-27 16:15:31 prot_disconnected last
2019-08-27 16:15:31 prot_init last
2019-08-27 16:16:18 prot_ok last
2017-03-05 01:08:04 prot_timeout last
2019-08-27 16:15:31 state opened
helper:
assIdCnt 7
assIdRep 7
info 03C7,LEQ1197979,3085C4,280765
setTime 47826
cnd:
0 1
253 1
255 1
dly:
cnt 14627
lst 819
max 9433
min -9191
ids:
33C21B:
cfg +33C21B,00,00,00
chn 02
flg 0
msg
name HM_33C21B
to 1567088388.60546
41BA46:
cfg +41BA46,00,00,00
name Licht_Ku
41C3DD:
cfg +41C3DD,00,00,00
chn 02
flg 0
msg
name Licht_Da
to 1567057353.55794
41C455:
cfg +41C455,00,00,00
chn 01
flg 0
msg
name Licht_Ki
to 1567016709.6116
4AA1BC:
cfg +4AA1BC,00,00,00
chn 01
flg 0
msg
name HM_4AA1BC
to 1566915385.52077
4CAE58:
cfg +4CAE58,00,00,00
chn 01
flg 0
msg
name HM_4CAE58
to 1566915386.51457
507161:
cfg +507161,00,00,00
chn 02
flg 0
msg
name HM_507161
to 1567158846.30613
k:
BufMin -13
DlyMax 18.184
Next 1567168059.26312
Start 1567168034.26312
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0xb8628790)
q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 0
loadNo 5
scnt 6
ald:
0
0
0
0
0
0
0
0
0
0
0
0
apIDs:
ref:
drft -5.33276450511945e-05
hmtL 591808855
kTs 0
offL 1566576225419
sysL 1567168009228
Attributes:
hmId 280765
hmLanQlen 1_min
icon dash_button
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room CUL
Und HMLANGW:
Internals:
AssignedPeerCnt 2
CNT 115
Clients :CUL_HM:
DEF 192.168.178.170
DEVCNT 115
DevState 99
DevType LGW
DeviceName 192.168.178.170:2000
FD 174
FUUID 5c4e0081-f33f-10de-f69d-b11956bd1493fc57
LastOpen 1567145952.16402
NAME HMLANGW
NOTIFYDEV global
NR 63
NTFY_ORDER 50-HMLANGW
PARTIAL
RAWMSG 040206
RSSI -44
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model eQ3-HM-LGW
msgLoadCurrent 3
msgLoadHistory 0/1/0/0/-1/0/0/0/1/0/0/0
msgLoadHistoryAbs 3/3/2/2/2/3/3/3/3/2/2/2/2
owner 280765
owner_CCU VCCU
Helper:
CreditTimer 1483
FW 66561
Initialized 1
AckPending:
LastSendLen:
3
3
Log:
IDs:
RoundTrip:
Delay 0.00469303131103516
loadLvl:
lastHistory 1567168158.21516
MatchList:
1:CUL_HM ^A......................
Peers:
3E57B1 +3E57B1,00,00,00
50722A +50722A,00,00,00
READINGS:
2019-08-30 08:19:17 D-HMIdAssigned 280765
2019-08-30 08:19:18 D-HMIdOriginal FFFFFF
2019-08-30 08:19:12 D-LANfirmware 1.1.5
2019-08-30 08:19:18 D-firmware 1.4.1
2019-08-30 08:19:12 D-serialNr PEQ1715998
2019-08-30 08:19:12 D-type eQ3-HM-LGW
2019-08-30 08:19:18 cond ok
2019-08-30 14:23:04 load 3
2019-08-30 08:19:18 loadLvl low
2019-08-30 08:19:12 state opened
helper:
keepAlive:
CNT 60
DEVCNT 59
DevState 99
DevType LGW-KeepAlive
DeviceName 192.168.178.170:2001
FD 178
LastOpen 1567145953.04773
NAME HMLANGW:keepAlive
NR 478211
PARTIAL
STATE opened
TEMPORARY 1
TYPE HMUARTLGW
XmitOpen 0
Helper:
NextKeepAlive 1567168240.76558
Log:
Resolve 1
IDs:
READINGS:
2019-08-30 08:19:13 state opened
Attributes:
hmId 280765
icon hm_ccu
lgwPw bEEewJ+THm
room CUL
Naja.. Bei der LGW bist Du schon out...
rssi_HMLANGW cnt:3 min:-91 max:-83 avg:-86.66 lst:-83
Mit attr <device> IOgrp <vccu>:<preferredIO> kannst Du dem Device sagen, er soll lieber HMUSB benutzen
Ist ja schon richtig - im Grunde. Aber da der HMUSB an einem Raspberry häng und nicht direkt am Cubietruck mit dem FHEM und daher "nur" über LAN eingebunden ist, dementsprechend beim Versagen dieses Weges die Verbindung zu dem HM-Komponenten komplett weg wäre, habe ich ja extra den HMLANGW zur Redundanz angeschafft. Tests haben mir gezeigt, dass die Verbindung beim Ausstecken des HMUSB auch trotz niedrigem RSSI im Regelfalle geht.
Aber ich verstehe Dich richtig: Das wäre mit Deinem Hinweis trotzdem gegeben? Dann verstehe ich auch wieder einen Punkt mehr der CommandRef ;) . Hab's jetzt Mal so angepasst wie Du sagst.
Danke.
2019-08-27 16:16:18 Xmit-Events ok:1 disconnected:1 init:1
seit dienstag nachmittag läuft er unauffällig.
es könnte auch sein, dass nach fhem restart zunächst das "falsche" io assigned wird: das erste (oder letzte?) im attr IOList der vccu. dann müsste es seit dienstag aber auch einige restarts gegeben haben. mit prefered io könnte das behoben sein.
ich würde sonnst mal die rssi beim aktor loggen. mit "attr logIDs 1" gibt es rssi readings beim aktor. vielleicht gibt das hinweise.
Naja beim Aktor gab es das hier:
protResnd 30 last_at:2019-08-30 07:55:12
protResndFail 22 last_at:2019-08-30 07:44:54
Dazu passt irgendwie das danach das Langateway um 8:19 "neu gemacht" wurde?
Zeig doch auch mal bitte ein list der VCCU
Gruß Otto
Das passt eigentlich ganz gut dazu, was das Logging für den Aktor sagt in diesem Zeitbereich (siehe unten). Ich hatte da versucht, über die Vorgabe von IOdev die Verbindung wieder herzustellen - was im Nachhinein wohl eigentlich wegen der Definition von VCCU ja sinnlos hätte sein sollen. Und jetzt, wo Du's sagst: Ja, ich habe tatsächlich am Dienstag auch, als die Verbindung weg war, ein Update von FHEM mit anschließendem Restart gemacht - Neustart um 16:15
Danach war auch alles gut, bis eben heute morgen das Phänomen wieder auftrat (zweiter Code unten).
Gut besten Dank, das gibt mir einen Hinweis, dass der Aktor durchaus von den Bauteilen absolut in Ordnung ist, sage ich jetzt mal. Sollte das nicht sein, wird es sich ja zeigen, ich werde natürlich berichten in diesem Falle.
Nebenbei aber vielleicht mit von Bedeutung: Vor ca. 4 Wochen habe ich mein HMLANGW austauschen müssen, weil das Netzteil defekt war und Amazon nur komplett tauscht. Auch beim neuen Gerät habe ich aber wie schon beim Vorgänger immer wieder Trennungen (siehe unten dritter Code), die ich mit Freezes in Zusammenhang sehe. Diese habe ich schon einige Zeit im Blick. Vielleicht war das auch mit im Spiel, wenn dummerweise der betroffene Aktor doch heute morgen mit dem HMLANGW statt mit dem HMUSB verbunden war. Obwohl ich das im Logging nicht sehe.
Ich danke mal soweit. Das RSSI-Loggen werde ich mal aufgreifen. Ist das dann nicht das Attribut rssiLog? ligIDs gibt's wohl nicht.
Besten Dank. Will jetzt aber auch nicht mehr Wirbel machen wegen der zwei Aussetzer, vielleicht bleibt es ja mit der prefered IO wieder stabil.
@Otto123
Dein Post kam jetzt kurz vor meiner Antwort. Denke, der dritte Code passt dazu. Das list des VCCU kommt als vierter Code.
EDIT: Da ging gerade was gewaltig schief mit den Codes. Folgt sofort.
Erster Aussetzet Dienstag, Logging Aktor:
2019-08-27_15:57:35 HM_507161 timedOn: off
2019-08-27_15:57:40 HM_507161 set_on
2019-08-27_15:57:51 HM_507161 ResndFail
2019-08-27_15:57:51 HM_507161 MISSING ACK
2019-08-27_15:58:22 HM_507161 set_on
2019-08-27_15:58:34 HM_507161 ResndFail
2019-08-27_15:58:35 HM_507161 MISSING ACK
2019-08-27_15:58:37 HM_507161 set_off
2019-08-27_15:58:49 HM_507161 ResndFail
2019-08-27_15:58:49 HM_507161 MISSING ACK
2019-08-27_16:01:39 HM_507161 set_off
2019-08-27_16:01:47 HM_507161 ResndFail
2019-08-27_16:01:47 HM_507161 MISSING ACK
2019-08-27_16:02:17 HM_507161 set_off
2019-08-27_16:02:25 HM_507161 ResndFail
2019-08-27_16:02:26 HM_507161 MISSING ACK
2019-08-27_16:03:35 HM_507161 set_on
2019-08-27_16:03:48 HM_507161 ResndFail
2019-08-27_16:03:48 HM_507161 MISSING ACK
2019-08-27_16:03:50 HM_507161 set_off
2019-08-27_16:04:02 HM_507161 ResndFail
2019-08-27_16:04:02 HM_507161 MISSING ACK
2019-08-27_16:06:15 HM_507161 set_off
2019-08-27_16:06:23 HM_507161 ResndFail
2019-08-27_16:06:24 HM_507161 MISSING ACK
2019-08-27_16:07:55 HM_507161 set_on
2019-08-27_16:08:07 HM_507161 ResndFail
2019-08-27_16:08:07 HM_507161 MISSING ACK
2019-08-27_16:08:10 HM_507161 set_off
2019-08-27_16:08:19 HM_507161 ResndFail
2019-08-27_16:08:20 HM_507161 MISSING ACK
2019-08-27_16:12:42 HM_507161 set_off
2019-08-27_16:12:45 HM_507161 battery: ok
2019-08-27_16:12:45 HM_507161 deviceMsg: off (to VCCU)
2019-08-27_16:12:45 HM_507161 level: 0
2019-08-27_16:12:45 HM_507161 pct: 0
2019-08-27_16:12:45 HM_507161 off
2019-08-27_16:12:45 HM_507161 timedOn: off
2019-08-27_16:16:37 HM_507161 ResndFail
2019-08-27_16:16:37 HM_507161 MISSING ACK
2019-08-27_16:16:46 HM_507161 unreachable
2019-08-27_16:17:41 HM_507161 set_off
2019-08-27_16:17:52 HM_507161 ResndFail
2019-08-27_16:17:53 HM_507161 MISSING ACK
2019-08-27_16:22:49 HM_507161 set_on
2019-08-27_16:22:59 HM_507161 ResndFail
2019-08-27_16:23:00 HM_507161 MISSING ACK
2019-08-27_16:23:01 HM_507161 set_off
2019-08-27_16:23:10 HM_507161 ResndFail
2019-08-27_16:23:10 HM_507161 MISSING ACK
2019-08-27_16:29:59 HM_507161 set_toggle
2019-08-27_16:29:59 HM_507161 battery: ok
2019-08-27_16:29:59 HM_507161 deviceMsg: on (to VCCU)
2019-08-27_16:29:59 HM_507161 level: 100
2019-08-27_16:29:59 HM_507161 pct: 100
2019-08-27_16:29:59 HM_507161 on
Zweiter Aussetzer heute morgen:
2019-08-29_19:05:28 HM_507161 timedOn: off
2019-08-30_07:34:39 HM_507161 set_on
2019-08-30_07:34:47 HM_507161 ResndFail
2019-08-30_07:34:48 HM_507161 MISSING ACK
2019-08-30_07:35:03 HM_507161 set_on-for-timer 7200
2019-08-30_07:35:12 HM_507161 ResndFail
2019-08-30_07:35:13 HM_507161 MISSING ACK
2019-08-30_07:35:30 HM_507161 set_off
2019-08-30_07:35:42 HM_507161 ResndFail
2019-08-30_07:35:43 HM_507161 MISSING ACK
2019-08-30_07:36:05 HM_507161 set_off
2019-08-30_07:36:15 HM_507161 ResndFail
2019-08-30_07:36:15 HM_507161 MISSING ACK
2019-08-30_07:36:31 HM_507161 set_on
2019-08-30_07:36:40 HM_507161 ResndFail
2019-08-30_07:36:40 HM_507161 MISSING ACK
2019-08-30_07:36:42 HM_507161 set_on
2019-08-30_07:36:51 HM_507161 ResndFail
2019-08-30_07:36:51 HM_507161 MISSING ACK
2019-08-30_07:37:31 HM_507161 set_toggle
2019-08-30_07:37:39 HM_507161 ResndFail
2019-08-30_07:37:40 HM_507161 MISSING ACK
2019-08-30_07:37:42 HM_507161 set_toggle
2019-08-30_07:37:51 HM_507161 ResndFail
2019-08-30_07:37:51 HM_507161 MISSING ACK
2019-08-30_07:40:39 HM_507161 set_on
2019-08-30_07:40:47 HM_507161 ResndFail
2019-08-30_07:40:48 HM_507161 MISSING ACK
2019-08-30_07:41:00 HM_507161 set_on
2019-08-30_07:41:11 HM_507161 ResndFail
2019-08-30_07:41:11 HM_507161 MISSING ACK
2019-08-30_07:42:44 HM_507161 set_on
2019-08-30_07:42:52 HM_507161 ResndFail
2019-08-30_07:42:52 HM_507161 MISSING ACK
2019-08-30_07:42:58 HM_507161 set_on
2019-08-30_07:43:06 HM_507161 ResndFail
2019-08-30_07:43:07 HM_507161 MISSING ACK
2019-08-30_07:43:09 HM_507161 set_on
2019-08-30_07:43:20 HM_507161 ResndFail
2019-08-30_07:43:21 HM_507161 MISSING ACK
2019-08-30_07:43:25 HM_507161 set_toggle
2019-08-30_07:43:35 HM_507161 ResndFail
2019-08-30_07:43:35 HM_507161 MISSING ACK
2019-08-30_07:43:42 HM_507161 set_off
2019-08-30_07:43:51 HM_507161 ResndFail
2019-08-30_07:43:51 HM_507161 MISSING ACK
2019-08-30_07:44:44 HM_507161 set_on
2019-08-30_07:44:54 HM_507161 ResndFail
2019-08-30_07:44:54 HM_507161 MISSING ACK
2019-08-30_07:45:16 HM_507161 set_off
2019-08-30_07:45:16 HM_507161 battery: ok
2019-08-30_07:45:16 HM_507161 deviceMsg: off (to VCCU)
2019-08-30_07:45:16 HM_507161 level: 0
2019-08-30_07:45:16 HM_507161 pct: 0
2019-08-30_07:45:16 HM_507161 off
2019-08-30_07:45:16 HM_507161 timedOn: off
Logging bei Disconnect HMLANGW:
2019.08.30 08:19:11.170 1: [Freezemon] myFreezemon: possible freeze starting at 08:19:03, delay is 8.169 possibly caused by: no bad guy found :-(
2019.08.30 08:19:11.257 1: HMUARTLGW HMLANGW:keepAlive KeepAlive sent 6.089s too late, this might cause a disconnect!
2019.08.30 08:19:11.674 1: 192.168.178.170:2001 disconnected, waiting to reappear (HMLANGW:keepAlive)
2019.08.30 08:19:11.765 1: 192.168.178.170:2000 disconnected, waiting to reappear (HMLANGW)
2019.08.30 08:19:12.168 3: Opening HMLANGW:keepAlive device 192.168.178.170:2001
2019.08.30 08:19:12.178 1: 192.168.178.170:2000 reappeared (HMLANGW)
2019.08.30 08:19:13.050 3: HMLANGW:keepAlive device opened
2019.08.30 08:19:13.113 3: HMUARTLGW HMLANGW BidCoS-port opened
2019.08.30 08:19:13.880 3: HMUARTLGW HMLANGW:keepAlive KeepAlive-port opened
list VCCU
Internals:
DEF 280765
FUUID 5c4e0082-f33f-10de-e555-b992c74af0231a3f
HMLANGW_MSGCNT 222
HMLANGW_RAWMSG 0500003A8DB0112807655071610201000000
HMLANGW_RSSI -58
HMLANGW_TIME 2019-08-30 11:54:04
HMUSB_MSGCNT 3929
HMUSB_RAWMSG E280765,0000,2396C2E1,FF,FFC2,0C80022807653E57B100
HMUSB_RSSI -62
HMUSB_TIME 2019-08-30 15:55:09
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 4151
NAME VCCU
NOTIFYDEV global
NR 65
NTFY_ORDER 50-VCCU
STATE HMUSB:ok,HMLANGW:ok
TYPE CUL_HM
assignedIOs HMLANGW,HMUSB
chanNo 01
lastMsg No:0C - t:02 s:280765 d:3E57B1 00
protLastRcv 2019-08-30 15:55:09
protRcv 3981 last_at:2019-08-30 15:55:09
protRcvB 137 last_at:2019-08-30 14:22:50
rssi_at_HMLANGW cnt:222 min:-62 max:-55 avg:-56.99 lst:-58
rssi_at_HMUSB cnt:3928 min:-68 max:-56 avg:-60 lst:-62
READINGS:
2019-08-30 15:55:09 CommandAccepted yes
2019-08-30 08:19:18 IOopen 2
2019-08-30 08:19:18 state HMUSB:ok,HMLANGW:ok
2019-08-28 07:11:52 unknown_239525 received
2019-08-14 09:45:46 unknown_45808A received
2019-08-07 17:11:01 unknown_47EFD2 received
2019-08-21 10:21:28 unknown_69F014 received
2019-08-21 06:16:23 unknown_A3B60E received
helper:
HM_CMDNR 12
PONtest 1
mId FFF0
peerFriend peerSD,peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
nextSend 1567169349.3925
prefIO
vccu
ioList:
HMUSB
HMLANGW
mRssi:
mNo 0C
io:
HMLANGW:
HMUSB:
-58
-58
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
rssi:
at_HMLANGW:
avg -56.990990990991
cnt 222
lst -58
max -55
min -62
at_HMUSB:
avg -60.0081466395113
cnt 3928
lst -62
max -56
min -68
Attributes:
IODev HMUSB
IOList HMUSB,HMLANGW
expert 2_raw
icon hm_ccu
model CCU-FHEM
room CUL
subType virtual
webCmd virtual:update
Oh ich hatte es vermutet: der VCCU fehlt das attr IOgrp auf sich selbst!
Ohne das attr ist die VCCU bei Ausfall eines IO nicht in der Lage den richtigen Sender zu setzen.
https://forum.fhem.de/index.php/topic,88621.msg811397.html#msg811397
Gruß Otto
... okay ... das muss ich mir ansehen.
Ich habe das VCCU ursprünglich mal angelegt, ohne wirklich zu wissen, wie das im Detail funktioniert. Dieser Aspekt war mir komplett unbewusst. Seltsam ist aber dann doch, dass es ansonsten immer funktioniert hat, oder etwa nicht? Ich habe öfters probehalber wechselweise HMLANGW und HMUSB ausgesteckt und an einzelnen Aktoren (nicht am aktuell hier besprochenen) die Funktion geprüft, und es hat immer funktioniert. Nun gut, ich glaube Dir natürlich schon, dass Du an sich Recht hast. Werde das mit definieren.
EDIT: Etwas irritiert mich die Beschreibung:
attr VCCU IOgrp <Name der vccu>
"Name der vccu" ist doch exemplarisch im vorderen Teil schon mit "VCCU" gesetzt, warum dann nicht auch hinten? Es kann dann doch nichts anderes da stehen, oder übersehe ich wieder etwas?
BTW: Im zweiten identischen Aktor hatte ich die Definition auch mit dem preferedID, muss das also schon mal gewusst haben - ist das einsetzende Demenz :o
Ich sage nicht das es die Lösung Deines Problemes ist ;) aber es ist auf alle Fälle nicht richtig und ich habe das erst vor ca. 1 Jahr so im Wiki nachgetragen.
Ich habe damals entdeckt "Das ist sicher nur ein Problem wenn man pairen will. " Aber wer weiß :)
Gruß Otto
Auf jeden Fall wird mir das dann helfen, wenn ich demnächst den Austausch des Wandschalters pairen muss. Jetzt ist es drin. Und ob das Problem weiter besteht wird sich zeigen.
Beste Grüße
duke-f
Zitat von: duke-f am 30 August 2019, 16:46:49
EDIT: Etwas irritiert mich die Beschreibung:
attr VCCU IOgrp <Name der vccu>
"Name der vccu" ist doch exemplarisch im vorderen Teil schon mit "VCCU" gesetzt, warum dann nicht auch hinten? Es kann dann doch nichts anderes da stehen, oder übersehe ich wieder etwas?
Ja hast Du sicher Recht, ich sehe es mir an und gehe noch mal in mich. ;D
Irgendwas verwirrt irgendwen immer :)
ZitatDas RSSI-Loggen werde ich mal aufgreifen. Ist das dann nicht das Attribut rssiLog? ligIDs gibt's wohl nicht.
richtig,
demenz ist wohl überall. ;)
Zitat von: Otto123 am 30 August 2019, 18:21:42
Irgendwas verwirrt irgendwen immer :)
Da ist was dran - irgenwie verwirrend ... :o
Hab das Wiki vereinheitlicht. https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Einrichten
Ist ja jetzt wieder einige Zeit her. Und gewässert wird auch nicht mehr. Gerade muss ich aber bei einem Probelauf feststellen, dass mein Problem nach wie vor besteht. Vielleicht liegt es am Aktor selber oder es gibt Komponenten in der Nachbarschaft, die stören. Einen zweiten, identischen Aktor, den ich in ähnlicher Position mit praktisch identischer Konfiguration betreibe, zeigt das Phänomen nicht.
Mal sehen, wie sich der "Trockenlauf" im Winter im Keller zeigt.
Hi, gabe es hier etwas neues im Keller?
Ich hatte meine HM-LC-SW1-BA-PCB nur wenige Tage in Betrieb und bekam dann immer wieder MISSING ACK. Irgendwie ist das Ding schräg oder etwas angeschlagen.
In den Logs / Event Monitor habe ich nichts verdächtiges finden können. Ein aus und einstecken der Stromversorgung hat das Problem immer wieder für wenige Stunden gelöst.
Da es an einer kritischen Stelle der Infrastruktur eingesetzt wurde, habe ich es dann gleich wieder durch eine Steckdose ersetzt.
Grüße, Frood
zeig doch mal ein list vom aktor.
DEF 750D25
FUUID 614269c6-f33f-9562-9395-af77196b2bfd3c1c
HMGW1_MSGCNT 10
HMGW1_RAWMSG 050000332A8400750D2500000017006C5345513132303633343010410100
HMGW1_RSSI -51
HMGW1_TIME 2021-09-18 21:10:34
IODev HMGW1
LASTInputDev HMGW1
MSGCNT 10
NAME HM_750D25
NR 418
NTFY_ORDER 50-HM_750D25
STATE on
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
lastMsg No:2A - t:00 s:750D25 d:000000 17006C5345513132303633343010410100
protCmdDel 6
protLastRcv 2021-09-18 21:10:34
protRcv 10 last_at:2021-09-18 21:10:34
protResnd 6 last_at:2021-09-18 20:38:10
protResndFail 6 last_at:2021-09-18 20:38:15
protSnd 18 last_at:2021-09-18 21:10:30
protSndB 13 last_at:2021-09-18 21:07:52
protState CMDs_done
rssi_at_HMGW1 cnt:10 min:-54 max:-48 avg:-51.3 lst:-51
.attraggr:
.attrminint:
Helper:
DBLOG:
powerOn:
myDbLog:
TIME 1631992071.7323
VALUE 2021-09-18 21:07:51
READINGS:
2021-09-18 21:10:34 .D-devInfo 410100
2021-09-18 21:10:34 .D-stc 10
2021-09-15 23:46:57 .R-intKeyVisib invisib
2021-09-15 23:46:57 .R-ledMode off
2021-09-15 23:46:57 .R-lowBatLimitBA 10.5 V
2021-09-15 23:46:57 .R-pairCentral 0xAFFECC
2021-09-15 23:46:57 .R-sign off
2021-09-18 21:07:54 .associatedWith HM_750D25,HM_750D25
2021-09-18 21:07:54 .peerListRDate 2021-09-18 21:07:54
2021-09-18 21:10:34 .protLastRcv 20210918211034
2021-09-17 17:15:20 CommandAccepted yes
2021-09-18 21:10:34 D-firmware 1.7
2021-09-18 21:10:34 D-serialNr SEQ1206340
2021-09-18 21:10:30 IODev HMGW1
2021-09-18 21:07:53 PairedTo 0xAFFECC
2021-09-18 21:07:53 RegL_00. 00:00 02:01 05:00 0A:AF 0B:FE 0C:CC 12:69
2021-09-18 21:07:54 RegL_01. 00:00 08:00
2021-09-18 21:10:30 battery ok
2021-09-18 21:08:54 cfgState ok
2021-09-18 21:10:30 commState CMDs_done
2021-09-18 21:10:30 deviceMsg on (to VCCU)
2021-09-18 21:10:30 level 100
2021-09-18 21:10:30 pct 100
2021-09-18 21:07:51 powerOn 2021-09-18 21:07:51
2021-09-18 21:10:30 recentStateType info
2021-09-18 21:10:30 state on
2021-09-18 21:10:30 timedOn off
2021-09-17 20:46:53 trigLast fhem:02
helper:
HM_CMDNR 81
PONtest 0
cSnd 01AFFECC750D2501040000000001,01AFFECC750D250103
cfgStateUpdt 0
lastMsgTm 1631992234.77726
mId 006C
peerFriend peerSens,peerVirt
peerIDsRaw ,00000000
peerIDsState complete
peerOpt 3:switch
regLst 0,1,3p
rxType 2
supp_Pair_Rep 1
cmds:
TmplKey :no:1631981053.70949
TmplTs 1631981053.70949
cmdKey 1:1:0::HM_750D25:006C:01:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
on noArg
on-for-timer -ontime-
on-till -time-
pair noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
toggle noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt HM_5FE8DE_MOTION_BATH,HM_653B50_SenF,HM_653B50_SenI,HM_653B50_SenPwr,HM_653B50_SenU,HM_67B628_Btn_01,HM_67B628_Btn_02,HM_67B628_Btn_03,HM_67B628_Btn_04,HM_67B628_Btn_05,HM_67B628_Btn_06,HM_6AA531_Btn_01,HM_6AA531_Btn_02,HM_6CA9C4_Btn_01,HM_6CA9C4_Btn_02,HM_72C5C2_KLINGEL,VCCU_Btn1,VCCU_Btn2,Vact_2Taster,Vact_Taster
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 0
det 0
raw 1
tpl 0
io:
flgs 0
newChn +750D25,00,00,00
nextSend 1631992234.86607
rxt 0
vccu VCCU
p:
750D25
00
00
00
prefIO:
HMGW1
mRssi:
mNo 2A
io:
HMGW1:
-45
-45
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
rspWait:
tryMsg:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
prs 1
rssi:
at_HMGW1:
avg -51.3
cnt 10
lst -51
max -48
min -54
shadowReg:
tmpl:
Attributes:
.mId 006C
IOgrp VCCU:HMGW1
autoReadReg 4_reqStatus
expert rawReg
firmware 1.7
model HM-LC-SW1-BA-PCB
msgRepeat 1
peerIDs 00000000
room 01a_FLOOR,CUL_HM
serialNr SEQ1206340
subType switch
webCmd statusRequest:toggle:on:off
zur beurteilung des funk fehlen die rssi, die das device ermittelt. mit einigen erfolgreichen statusrequest sollten die auftauchen.
zeig noch ein list vom io.
sind die antennen von io und device noch original, oder getuned?
um zu "sehen", wo es genau zwickt, müsstest du mal die rawmessages sniffen, wie im wiki beschrieben.
gibt es freezes?
schon mal apptime und/oder freezemon angeworfen?
eine korrelation mit poweron wäre seltsam.
vermutlich eine täuschung, da "missing_ack" nur länger sichtbar bleibt? das ist ja kein zustand, sondern nur ein kurzes ereignis.
ansonnsten vielleicht ein netzteil problem.
Ich habe das Ding jetzt rausgeworfen, daher kann ich erst mal keine weiteren Details liefern.