Hallo,
ich habe schon seit einigen Monaten einen Fensterkontakt mit einem Thermostat gepeered, um die Temperatur abzusenken.
In rund 5%-10% der Fälle erkennt der Thermostat leider nicht den Close-Trigger und bleibt im "Fenster geöffnet" Modus auf 5° C. Der Kontakt selber ist jedoch im richtigen Status, das habe ich bereits mehrfach überprüft.
Nun habe ich eben zufällig ein Reading mit "trigDst_" gefunden, also ohne Destination. Wie bekomme ich das wieder weg?
Hier ein Auszug aus dem List (ein paar Details mit "xxx"):
Internals:
DEF 348xxx
HMLAN1_MSGCNT 65
HMLAN1_RAWMSG xxxxx
HMLAN1_RSSI -81
HMLAN1_TIME 2018-10-28 17:18:57
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 65
NAME WZ_Kontakt_Terrassentuer
NOTIFYDEV global
NR 101
NTFY_ORDER 50-WZ_Kontakt_Terrassentuer
STATE closed
TYPE CUL_HM
lastMsg No:D1 - t:41 s:348xxx d:2BAxxx 01Cxxx
peerList WZ_Heizung_WindowRec,
protCmdPend 3 CMDs_pending
protLastRcv 2018-10-28 17:18:57
protSnd 97 last_at:2018-10-28 17:18:57
protState CMDs_pending
rssi_at_HMLAN1 avg:-81.32 cnt:65 min:-89 lst:-81 max:-76
READINGS:
2018-10-25 21:51:06 Activity alive
2018-02-15 17:38:09 CommandAccepted yes
2018-02-15 17:38:07 D-firmware 2.4
2018-02-15 17:38:07 D-serialNr LEQ1xxxxxx
2018-02-15 18:09:21 PairedTo 0x2BAxxx
2018-02-15 17:38:11 R-WZ_Heizung_WindowRec-expectAES off
2018-02-15 17:38:11 R-WZ_Heizung_WindowRec-peerNeedsBurst on
2015-08-31 14:45:07 R-cyclicInfoMsg on
2015-08-31 14:45:07 R-eventDlyTime 2 s
2015-08-31 14:45:07 R-pairCentral 0x2BAxxx
2015-08-31 14:45:07 R-sabotageMsg on
2015-08-31 14:45:07 R-sign on
2018-02-15 17:38:09 aesCommToDev ok
2018-02-15 17:38:09 aesKeyNbr 00
2018-10-26 16:39:52 alive yes
2018-10-28 17:18:57 battery ok
2018-10-28 17:18:57 contact closed (to HMLAN1)
2018-10-25 21:51:06 peerList WZ_Heizung_WindowRec,
2018-02-14 14:51:07 powerOn 2018-02-14 14:51:07
2018-10-26 16:39:52 recentStateType info
2018-10-26 16:39:52 sabotageError off
2018-10-28 17:18:57 state closed
2018-02-24 11:15:19 trigDst_ noConfig
2018-10-28 17:18:57 trigDst_2BAxxx noConfig
2018-10-28 17:18:57 trigger_cnt 205
Wie man sieht, ist da am Ende eine Zeile mit "trigDst_ noConfig" vom Februar 2018. Wie bekomme ich die wieder weg?
Hat jemand eine Idee?
Danke & Gruß,
Axel
fhem cmd "deletereading"
hat aber nichts mit deinem problem zu tun.
mit einem "halben und sinnlos verstümmelten" list ist es auch schwer, zu helfen.
was sagt "get hminfo configCheck"?
Aha! Danke Frank für die schnelle Antwort. :) Mit deletereading habe ich es tatsächlich sofort wegbekommen. (wenn man weiß, wonach man suchen muss, klingt es natürlich einfach)
Hm, dass es nichts mit meinem Problem zu tun hat, hatte ich schon befürchtet.
Das mit dem "halben und sinnlos verstümmelten" List ... nun ja, ich weiß nicht genau, welche Details sollte man lieber nicht öffentlich zitieren? Ich dachte, ich x'e ein paar IDs und S/N lieber weg ... ? Zu "paranoid"? Ist das Blödsinn?
Bin diesbezüglich nicht so erfahren, hab das bisher fast alles ohne solche Postings hinbekommen.
Hier das List von dem Türkontakt (WZ_Kontakt_Terrassentuer):
Internals:
DEF 348Exx
HMLAN1_MSGCNT 65
HMLAN1_RAWMSG xxxxx
HMLAN1_RSSI -81
HMLAN1_TIME 2018-10-28 17:18:57
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 65
NAME WZ_Kontakt_Terrassentuer
NOTIFYDEV global
NR 101
NTFY_ORDER 50-WZ_Kontakt_Terrassentuer
STATE closed
TYPE CUL_HM
lastMsg No:D1 - t:41 s:348xxx d:2BAxxx 01Cxxx
peerList WZ_Heizung_WindowRec,
protCmdPend 3 CMDs_pending
protLastRcv 2018-10-28 17:18:57
protSnd 97 last_at:2018-10-28 17:18:57
protState CMDs_pending
rssi_at_HMLAN1 avg:-81.32 cnt:65 min:-89 lst:-81 max:-76
READINGS:
2018-10-25 21:51:06 Activity alive
2018-02-15 17:38:09 CommandAccepted yes
2018-02-15 17:38:07 D-firmware 2.4
2018-02-15 17:38:07 D-serialNr LEQ1xxxxxx
2018-02-15 18:09:21 PairedTo 0x2BAxxx
2018-02-15 17:38:11 R-WZ_Heizung_WindowRec-expectAES off
2018-02-15 17:38:11 R-WZ_Heizung_WindowRec-peerNeedsBurst on
2015-08-31 14:45:07 R-cyclicInfoMsg on
2015-08-31 14:45:07 R-eventDlyTime 2 s
2015-08-31 14:45:07 R-pairCentral 0x2BAxxx
2015-08-31 14:45:07 R-sabotageMsg on
2015-08-31 14:45:07 R-sign on
2018-02-15 17:38:09 aesCommToDev ok
2018-02-15 17:38:09 aesKeyNbr 00
2018-10-26 16:39:52 alive yes
2018-10-28 17:18:57 battery ok
2018-10-28 17:18:57 contact closed (to HMLAN1)
2018-10-25 21:51:06 peerList WZ_Heizung_WindowRec,
2018-02-14 14:51:07 powerOn 2018-02-14 14:51:07
2018-10-26 16:39:52 recentStateType info
2018-10-26 16:39:52 sabotageError off
2018-10-28 17:18:57 state closed
2018-10-28 17:18:57 trigDst_2BAxxx noConfig
2018-10-28 17:18:57 trigger_cnt 205
cmdStack:
++A0012BAxxx348xxx00040000000000
++A0012BAxxx348xxx01040000000001
++A0012BAxxx348xxx0103
helper:
HM_CMDNR 209
getCfgList all
getCfgListNo ,4
mId 00B1
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +348xxx,02,00,00
nextSend 1540743537.05342
prefIO
rxt 2
vccu
p:
348xxx
00
00
00
mRssi:
mNo D1
io:
HMLAN1 -79
prt:
bErr 0
sProc 2
sleeping 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO HMLAN1
flg A
ts 1540743537.02056
ack:
HASH(0x1d21e00)
D18xxx2BAxxx348xxx00
HASH(0x1d21e00)
D18xxx2BAxxx348xxx0101Cxxx
rssi:
at_HMLAN1:
avg -81.3230769230769
cnt 65
lst -81
max -76
min -89
shadowReg:
tmpl:
Attributes:
IODev HMLAN1
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 2.4
icon fts_door_right_open
model HM-SEC-SC-2
peerIDs 00000000,3156xxxx,
room 06_Wohnzimmer,Homebridge
serialNr LEQ1xxxxxx
subType threeStateSensor
Soll ich das List des WindowRec auch noch zitieren?
Here we go:
Internals:
DEF 3156xxxx
NAME WZ_Heizung_WindowRec
NOTIFYDEV global
NR 51
NTFY_ORDER 50-WZ_Heizung_WindowRec
STATE last:WZ_Kontakt_Terrassentuer:closed
TYPE CUL_HM
chanNo 03
device WZ_Heizung
peerList WZ_Kontakt_Terrassentuer,
READINGS:
2015-08-31 00:29:41 R-sign off
2018-02-15 17:54:16 RegL_01. 08:00 00:00
2018-02-15 17:54:16 RegL_03.WZ_Kontakt_Terrassentuer_chn-01 04:32 00:00
2018-02-15 17:54:17 RegL_07.WZ_Kontakt_Terrassentuer_chn-01 05:0A 00:00
2018-10-25 21:51:06 peerList WZ_Kontakt_Terrassentuer,
2018-10-25 21:51:06 state unknown
2018-10-28 17:18:56 trigLast WZ_Kontakt_Terrassentuer:closed
2018-10-28 17:18:56 trig_WZ_Kontakt_Terrassentuer Closed_205
helper:
cfgChkResult No regs found for:
WZ_Heizung_WindowRec type:thermostat -
list:peer register :value
1: sign :off
7:WZ_Kontakt_Terrassentuer_chn-01 winOpnTemp :5 C
7:WZ_Kontakt_Terrassentuer_chn-01 winOpnTemp :5 C
WZ_Kontakt_Terrassentuer_chn-01
sh
CtValLo 50 50
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
shadowReg:
tmpl:
nb:
cnt 2
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,348Exxxx,
room 06_Wohnzimmer
stateFormat last:trigLast
HMinfo gibt folgendes:
configCheck done:
missing register list
WZ_Kontakt_Terrassentuer: RegL_00.,RegL_01.,RegL_04.WZ_Heizung_WindowRec
trigger sent to unpeered device
triggerUnpeered: WZ_Kontakt_Terrassentuer:2BAxxx
trigger sent to undefined device
triggerUndefined: WZ_Kontakt_Terrassentuer:2BAxxx
Hängen die letzten beiden Punkte mit dem peerIDs "00000000" und damit, dass ich keine VCCU habe, zusammen?
Die missing register list irritiert mich, da ich die Kopplung ja eigentlich nach Anleitung gemacht hatte...
Was mich wundert: in >90% aller Fälle funktioniert alles bestens!
Wenn ich wüsste, dass ein Reset des Fensterkontakts das Problem lösen würde, würde ich auch diesen Weg gehen... aber so ein "Wackelkontakt"?
Zitatnun ja, ich weiß nicht genau, welche Details sollte man lieber nicht öffentlich zitieren?
keys und email adressen zb. wenn man sehr ängstlich ist eventuell auch SN.
auf jeden fall wäre es effektiver, in deinem system einen eigenen key zu vergeben, anstatt ein list zu verfälschen. die infos gehen alle durch die luft.
configcheck:
fhem fehlen daten vom fk (missing), also "get configCheck". allerdings steht der befehl schon im cmdstack (pending cmds), also knöpfchen drücken am fk. eventuell wiederholen, bis configcheck sauber ist.
die triggermeldungen verschwinden, wenn du eine vccu definierst.
sollte aber immer noch nicht dein eigentliches problem lösen. es sei denn, dass fhem wegen den fehlenden infos dazwischen funkt, wenn der fk aufwacht. der funk zu fhem ist auch grenzwertig (rssi).
ist die funkstrecke zwischen fk und rt ok? rt vielleicht in mauerniesche oder vorhang davor, ....
am rt ist nach dem schliessen dann immer noch das fenster offen symbol im display zu sehen?
ich würde den fk mal sniffen, siehe wiki hm sniffen.
ein list vom rt hauptdevice wäre noch interessant.
auf jeden fall wäre es effektiver, in deinem system einen eigenen key zu vergeben, anstatt ein list zu verfälschen. die infos gehen alle durch die luft.
Ich weiß gar nicht mehr, warum ich das damals nicht gemacht habe. Aufgesetzt hab ich das System mit den ersten HM Komponenten vor ca. 5 Jahren... vielleicht ging das damals noch nicht mit fhem und AES? An meinem HMLAN kann's ja eigentlich nicht liegen, der kann AES ja... mmmh
configcheck:
fhem fehlen daten vom fk (missing), also "get configCheck". allerdings steht der befehl schon im cmdstack (pending cmds), also knöpfchen drücken am fk. eventuell wiederholen, bis configcheck sauber ist.
Danke, das werde ich nachher mal machen!
die triggermeldungen verschwinden, wenn du eine vccu definierst. Das steht schon sooo lange auf meiner virtuellen ToDo-List... aber irgendwie hab ich sie noch nicht wirklich vermisst. (oder doch und ich weiß es nur nicht?!)
der funk zu fhem ist auch grenzwertig (rssi).HMLAN hängt im Keller an der Wand. Noch hat's immer für's ganze Haus gereicht (trotz Stein/Beton/Stahl). Aber ich gebe zu, die Position des HMLAN könnte ich ggf. noch etwas verbessern in dem Raum (zumal die FritzBox auch nur einweit davon hängt, was sicher nicht förderlich ist). -> ToDo ;)
Zitatist die funkstrecke zwischen fk und rt ok?
FK hängt oben an der Terrassentür, der RT ca. 1.6m direkt unterhalb. Jetzt, wo du das mit dem rssi erwähnst, da würde ich eher schon anders herum denken: zu dicht beieinander? Manchmal liest man ja auch von Mindestabständen (gerade beim Koppeln). Könnte das sein?
am rt ist nach dem schliessen dann immer noch das fenster offen symbol im display zu sehen?Ja, genau das ist mein Problem. Der fk hat den Vorgang aber definitiv richtig erkannt und zumindest das Device in fhem zeigt alles richtig (State etc.) - nur der direkte Weg an den rt geht halt manchmal nicht.
Das kommando set clear trigger hat noch keiner gefunden?
Zitat von: martinp876 am 29 Oktober 2018, 21:16:25
Das kommando set clear trigger hat noch keiner gefunden?
dann wären ja alle trigger verschwunden.