Fensterkontakt mit "trigDst_"

[awe]

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"):

Code Auswählen Erweitern


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

[frank]

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"?

[awe]

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):

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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"?

[frank]

nun 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.

[awe]

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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!

Code Auswählen Erweitern

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?!)

Code Auswählen Erweitern

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

ist 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?

Code Auswählen Erweitern

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.

[martinp876]

Das kommando set clear trigger hat noch keiner gefunden?

[frank]

Das kommando set clear trigger hat noch keiner gefunden?

dann wären ja alle trigger verschwunden.