Hallo Gemeinde,
habe leider immer wieder mal folgende Fehlermeldungen/Infomessages:
2019.09.11 06:23:05 1: waiting for: PeerList, got:RegisterRead # await msgNo:26, rec:23
2019.09.11 06:23:05 1: waiting for: PeerList, got:RegisterRead # await msgNo:26, rec:25
2019.09.11 06:23:09 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:35, rec:33
2019.09.11 06:23:09 1: waiting for: RegisterRead, got:RegisterRead # await msgNo:35, rec:33
Wie kann ich den Meldungen auf den grund gehen ?
VG Klaus
Sieht für mich absolut nicht wie eine Fehlermeldung aus. Eher wie eine Information.
Zitat von: CoolTux am 11 September 2019, 07:08:11
Sieht für mich absolut nicht wie eine Fehlermeldung aus. Eher wie eine Information.
Habe ich in der ersten Post geändert, Sorry ...
Leider habe ich das Problem immer wieder. Mir ist aufgefallen das ich es manchmal provozieren kann, indem ich einen getconfig mache. Evtl. ist es auch erwähnenswert, dass ich drei HMUART's nutze, einen direkt auf dem RPI, die anderen beiden über WLAN. Haben das vielleicht andere schon gefixt ?
Vg Klaus
Hi,
die WLAN Anbindungen haben meist hohe Latenzen. Für mich sieht das aus als gehen Nachrichten verloren. Ich habe auch einen HMUART am Wlan, aber diese Nachrichten kenne ich nicht.
Ist das Ganze mit VCCU, IOList, IOgrp richtig konfiguriert? Meldet hminfo irgendwelche Dinge?
Gruß Otto
Hallo Otto,
ja, läuft mit VCCU.
Hier mal der List meiner VCCU:
Internals:
DEF 29A083
FUUID 5c489c0d-f33f-b6d9-e563-4b600b9a77f3ec30
HMUART1_MSGCNT 215
HMUART1_RAWMSG 0500003FC1800229A08334439700
HMUART1_RSSI -63
HMUART1_TIME 2020-05-29 20:18:01
HMUART2_MSGCNT 489
HMUART2_RAWMSG 0500004817800229A0832EEC7C01015400
HMUART2_RSSI -72
HMUART2_TIME 2020-05-29 20:33:32
HMUART3_MSGCNT 501
HMUART3_RAWMSG 0500014B17800229A0832EEC7C01015400
HMUART3_RSSI -75
HMUART3_TIME 2020-05-29 20:33:32
IODev HMUART1
LASTInputDev HMUART2
MSGCNT 1205
NAME vccu
NOTIFYDEV global
NR 25
NTFY_ORDER 50-vccu
STATE HMUART1:ok,HMUART2:ok,HMUART3:ok
TYPE CUL_HM
assignedIOs HMUART1,HMUART2,HMUART3
chanNo 01
lastMsg No:17 - t:02 s:29A083 d:2EEC7C 01015400
protLastRcv 2020-05-29 20:33:32
protRcv 672 last_at:2020-05-29 20:33:32
protRcvB 24 last_at:2020-05-29 20:19:35
rssi_at_HMUART1 cnt:215 min:-76 max:-59 avg:-64.87 lst:-63
rssi_at_HMUART2 cnt:489 min:-94 max:-67 avg:-72.06 lst:-72
rssi_at_HMUART3 cnt:501 min:-82 max:-73 avg:-75.38 lst:-75
READINGS:
2020-05-29 20:33:32 CommandAccepted yes
2020-05-29 19:07:22 IOopen 3
2020-05-29 19:43:48 aesKeyNbr 02
2020-05-29 19:38:05 aesReqTo GA.taster
2020-05-29 20:33:32 recentStateType ack
2020-05-29 19:07:22 state HMUART1:ok,HMUART2:ok,HMUART3:ok
helper:
HM_CMDNR 23
PONtest 1
mId FFF0
peerFriend peerSD,peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
supp_Pair_Rep 0
ack:
cmds:
TmplKey :no:1590772030.58857
TmplTs 1590772030.58857
cmdKey :1:1:1::FFF0:01
TmplCmds:
cmdList:
assignHmKey:
assignIO:-IO- [set|unset]...
clear:[readings|rssi|msgErrors|msgErrors|unknownDev]
defIgnUnknown:
deviceRename:newName
fwUpdate:-filename- -bootTime- ...
getDevInfo:
hmPairForSec:-sec- ...
hmPairSerial:-serial-
peerChan:-btnNumber- -actChn- ... [single|dual|reverse] [set|unset] [actor|remote|both]
postEvent:-condition-
press:[long|short] [noBurst] [-repCount(long only)-] [-repDelay-] ...
raw:data ...
reset:
unpair:
update:
virtual:-noButtons-
expert:
def 1
det 1
raw 1
tpl 1
io:
nextSend 1590777212.97657
prefIO
vccu vccu
ioList:
HMUART1
HMUART2
HMUART3
mRssi:
mNo 17
io:
HMUART1:
HMUART2:
-72
-72
HMUART3:
-75
-75
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
rssi:
at_HMUART1:
avg -64.8790697674419
cnt 215
lst -63
max -59
min -76
at_HMUART2:
avg -72.0654396728016
cnt 489
lst -72
max -67
min -94
at_HMUART3:
avg -75.3812375249501
cnt 501
lst -75
max -73
min -82
tmpl:
Attributes:
IODev HMUART1
IOList HMUART1,HMUART2,HMUART3
IOgrp vccu
event-on-update-reading no
expert 251_anything
hmKey 01:749D19xxxxxxxxxxxxxxxxxxxx
icon radio_checked
model CCU-FHEM
room FHEM
subType virtual
webCmd virtual:update
Dass es im WLAN zu schwankenden lLatenzen kommt ist mir schon klar, aber ich dachte das FHEM das sozusagen sortiert..
Configcheck des hminfo meldet nichts
VG Klaus
Keine Ahnung, ob ich da richtig liege, aber alle Adapter empfangen quasi alle Pakete, da kann es meiner Meinung natürlich vorkommen, das Paket 10 von Adapter x schneller ans FHEM geliefert wird, als Paket 9 von Adapter Y.
Sieht an sich gut aus :)
Aber warum ist das gesetzt?
event-on-update-reading no
Damit erzeugt die VCCU keine Events mehr. Ich weiß nicht ob das gut oder schlecht ist, oder ob es was mit Deinem problem zu tun hat.
Dein HMKEY wäre Sicherheitsrelevant, den solltest Du aus dem Post entfernen. ;)
Hab erstmal keine Idee :'(
Gruß Otto
Hallo Otto,
event-on-update-reading no habe ich öfter gesetzt, um die Last meiner Meldungen zu reduzieren.
Event on Change oder update sezte ich eigentlich nur, wenn ich die meldungen brauche ..
VG Klaus
Ich setzt immer überall und per initscript Event on Change .* . Es gibt zu viele abhängige events notifies und Display frontends oder grafiken welche readings auswerten und dies auch mûssen. Das selektiv zu machen ist möglich aber aufwändig. Nicht mein fall.
Update hingegen benötige ich nicht. Die bringen nur etwas wenn man den zeitstempel nutzt. Bei grafiken berücksichtige ich das. Culhm sollte alle readings so ausgelegt haben dass es reicht auf änderungen zu reagieren.
Zur Fehlermeldung: das Protokoll hat eine andere als die empfangene messagesequenznumber empfangen. Das protokoll fängt dies ersr einmal ab und korrigiert es. Falls es am ende nicht klappt wird dies in der proto Anzeigen kund getan
Hilfreich sollte hier get hm protoEvents sein. Dies zeigt an welches device wie viele korrigierbare Fehler und nicht korrigierbare aufgetreten sind.
Mit set hm clearB msgErrors kann man die fehler ablöschen und weiter beobachten.
Ich finde das sieht so schlecht nicht aus...
protoEvents send to devices done:
name :State |CmdPend |Snd |SndB |Rcv |RcvB |Resnd #CmdDel |ResndFail |Nack |IOerr
AZ.hk : done | - | 1 | - | 204 | - | - # - | - | - | -
AZ.rm : done | - | 4 | 1 | 2 | - | - # - | - | - | -
Alarm_sir_ext : done | - | 3 | 3 | 3 | - | - # - | - | - | -
Alarm_sir_int : done | - | 5 | 4 | 3 | - | 1 # - | - | - | -
Alarm_switch : done | - | 4 | - | 6 | - | - # - | - | - | -
BC.motion : done | - | 44 | - | 317 | - | - # - | - | - | -
BD.bm : - | - | - | - | 415 | - | - # - | - | - | -
BD.fk : done | - | 14 | - | 11 | - | - # 2 | - | 1 | -
BD.hk : done | - | 3 | - | 207 | - | - # - | - | - | -
BD.licht : done | - | 55 | - | 163 | - | - # - | - | - | -
BD.spiegel : done | - | 19 | - | 13 | - | - # - | - | - | -
BD.wm : done | - | 7 | - | 5 | - | - # - | - | - | -
EM.pm : - | - | - | - | 610 | - | - # - | - | - | -
FC.motion : done | - | 6 | - | 294 | - | - # - | - | - | -
FL.AZ.pm : - | - | - | - | 608 | - | - # - | - | - | -
FL.EG.anzeige : done | - | 529 | - | 466 | - | 4 # - | - | - | -
FL.EG.bm : done | - | 74 | - | 378 | - | - # - | - | - | -
FL.EG.gong : done | - | 58 | - | 58 | - | 2 # - | - | - | -
FL.EG.licht : done | - | 2 | - | 2 | - | - # - | - | - | -
FL.OG.licht : done | - | 13 | - | 9 | - | - # - | - | - | -
FL.OG.rm : done | - | 4 | 1 | 2 | - | - # - | - | - | -
FL.UG.bm : - | - | - | - | 350 | - | - # - | - | - | -
FL.UG.hk : done | - | 7 | - | 212 | - | - # - | - | - | -
FL.UG.licht : done | - | 8 | - | 69 | - | - # - | - | - | -
FL.UG.rm : done | - | 4 | 1 | 2 | - | - # - | - | - | -
FL.UG.strahler : done | - | 18 | - | 13 | - | - # - | - | - | -
FL.UG.tk.ke : done | - | 30 | - | 29 | - | - # - | - | - | -
FL.UG.tk.pr : done | - | 23 | - | 23 | - | - # - | - | - | -
FL.ZG.licht : done | - | 13 | - | 9 | - | - # - | - | - | -
GA.codeschloss : done | - | 29 | - | 32 | 5 | - # - | - | - | -
GA.fb : done | - | 31 | - | 15 | - | 1 # - | - | - | -
GA.keymatic : done | - | 31 | 5 | 37 | - | - # - | - | - | -
GA.licht : done | - | 5 | - | 59 | - | - # - | - | - | -
GA.oben.bm : - | - | - | - | 332 | - | - # - | - | - | -
GA.taster : done | - | 13 | 6 | 10 | - | 1 # - | - | - | -
GA.torkontakt : done | - | 27 | - | 22 | - | 2 # 5 | - | 2 | -
GA.tuerkontakt : done | - | 33 | - | 31 | - | 1 # 5 | - | 2 | -
GA.unten.bm : - | - | - | - | 324 | - | - # - | - | - | -
HR.tk : done | - | 19 | - | 15 | - | 1 # 5 | - | 2 | -
HW.bm : - | - | - | - | 434 | - | - # - | - | - | -
HW.gk : done | - | 27 | - | 44 | - | - # - | - | - | -
HW.hk : done | - | 9 | - | 215 | - | 1 # - | - | - | -
HW.licht : done | - | 59 | - | 183 | - | - # - | - | - | -
HW.sw : done | - | 16 | - | 12 | - | - # - | - | - | -
HW.tk : done | - | 64 | - | 62 | - | 1 # 2 | - | 1 | -
HZ.brenner : done | - | 2 | - | 2 | - | - # - | - | - | -
HZ.ctrl : done | - | 4 | - | 4 | - | - # - | - | - | -
HZ.wm : done | - | 7 | - | 5 | - | - # - | - | - | -
KE.licht : done | - | 25 | - | 25 | - | - # - | - | - | -
KE.sw : done | - | 3 | - | 2 | - | 1 # - | - | - | -
KE.wm : done | - | 7 | - | 5 | - | - # - | - | - | -
KG.fk : done | - | 39 | - | 37 | - | - # 2 | - | 1 | -
KG.hk : done | - | 1 | - | 208 | - | - # - | - | - | -
KG.rm : done | - | 4 | 1 | 2 | - | - # - | - | - | -
KK.hk : done | - | 3 | - | 209 | - | - # - | - | - | -
KK.rm : done | - | 4 | 1 | 2 | - | - # - | - | - | -
KU.bm : - | - | - | - | 474 | - | - # - | - | - | -
KU.licht : done | - | 66 | - | 240 | - | - # - | - | - | -
KU.rm : done | - | 5 | 1 | 3 | - | - # - | - | - | -
KU.spuele : done | - | 17 | - | 12 | - | - # - | - | - | -
KU.wm : done | - | 10 | - | 8 | - | 1 # - | - | - | -
PR.bm : - | - | - | - | 379 | - | - # - | - | - | -
PR.hk : done | - | 1 | - | 205 | - | - # - | - | - | -
PR.licht : done | - | 8 | - | 106 | - | 2 # - | - | - | -
Regensensor_Controller : done | - | 12 | - | 9 | - | - # - | - | - | -
SZ.fk : done | - | 16 | - | 14 | - | - # 2 | - | 1 | -
SZ.hk : done | - | 3 | - | 208 | - | - # - | - | - | -
SZ.rm : done | - | 4 | 1 | 2 | - | - # - | - | - | -
Sonnensensor_Sued : - | - | - | - | 605 | - | - # - | - | - | -
Sonnensensor_West : - | - | - | - | 607 | - | - # - | - | - | -
TR.sw : done | - | 3 | - | 2 | - | 1 # - | - | - | -
WC.bm : done | - | 323 | - | 431 | - | 1 # - | - | - | -
WC.hk : done | - | 1 | - | 206 | - | - # - | - | - | -
WC.licht : done | - | 155 | - | 268 | - | - # - | - | - | -
WC.tk : done | - | 4 | - | 4 | - | - # - | - | - | -
WC.ventilator : done | - | 25 | - | 20 | - | - # - | - | - | -
WC.wm : done | - | 7 | - | 5 | - | - # - | - | - | -
WF.codeschloss : done | - | 6 | - | 4 | - | - # - | - | - | -
WF.fb : done | - | 27 | - | 14 | - | - # - | - | - | -
WF.keymatic : done | - | 33 | 5 | 27 | - | - # - | - | - | -
WF.licht : done | - | 19 | - | 14 | - | - # - | - | - | -
WF.tuerkontakt : done | - | 24 | - | 22 | - | - # 2 | - | 1 | -
WZ.hk : done | - | 5 | - | 211 | - | - # - | - | - | -
WZ.rm : done | - | 5 | 1 | 3 | - | - # - | - | - | -
WZ.sw : done | - | 9 | - | 7 | - | 1 # - | - | - | -
Wetterstation : - | - | - | - | 611 | - | - # - | - | - | -
======================================================================================================================================================
sum 0 |0 |2198 |31 |11532 |5 |22 #25 |0 |11 |0
CUL_HM queue length:0
requests pending
----------------
autoReadReg :
recent : HW.licht
status request :
autoReadReg wakeup : GA.fb
status request wakeup:
autoReadTest : FL.ZG.licht FL.OG.licht HW.licht BD.licht
IODevs:HMUART1:ok condition:ok
HMUART2:ok condition:ok
HMUART3:ok condition:ok
Oder was meint ihr ?
die "nack" würde ich mal untersuchen.
da nack eine explizite "verweigerung" ist, wird ja eventuell etwas "falsches" in einer bestimmten situation gesendet.
oder fehler bei aes. eventuell aes reduzieren.
ebenso würde ich mal die tauglichkeit der wlan latenz testen:
zb am io attr logIds=sys setzen und die so erzeugten roundtripdelay einträge in fhem.log plotten.
zum vergleich => https://forum.fhem.de/index.php/topic,101941.msg957270.html#msg957270 (https://forum.fhem.de/index.php/topic,101941.msg957270.html#msg957270)
nach den # stehen die problematischen. Hier wurde etwas nicht übertragen.
Mit
set hm clearG msgErrors
kann man alle Fehler löschen. Mit
set hm clearG msgEvents
alle Zähler.
Aus meiner Sicht macht es Sinn, erst einmal zu löschen und dann die Fehler zu beobachten. Tritt es häufiger auf? Wann und bei welchen Devices? Welche Aktionen?
Diese kann man dann loggen und untersuchen.
Ein Löschen eine Kommandos kann auch durch eine spätere Wiederholung repariert werden... kommt drauf an.
Also eingrenzen.