MISSING ACK - Wie vorgehen?

[FHEMAN]

Hallo zusammen,

ich habe bei meinen optischen Türfensterkontakten immer mal wieder MISSING ACK .

Wie kann ich dieses Fehlverhalten analysieren und schließlich abstellen?
Wo in der Kommunikationskette hakt es, wenn ein MISSING ACK im Status auftaucht?

Da dieses Verhalten meine open/close Auswertung torpediert und sich ein Sicherheitsleck damit auftut, möchte ich das bereinigen. Es erscheint mir nicht sinnvoll, bei einer Überwachungsfunktion nur die Zustände open/close zu berücksichtigen, da beim Öffnen eines Fensters evtl. der Status von "closed" auf "MISSING ACK" umschaltet.

Code Auswählen Erweitern

CUL0_RSSI
-85.5
rssi_at_CUL0
avg:-89.63 min:-104 max:-79 lst:-85.5 cnt:22

Hier mal ein Logauszug:

Code Auswählen Erweitern

2014-12-01_21:08:20 TuerFensterKontakt.Bad alive: yes
2014-12-01_21:08:20 TuerFensterKontakt.Bad battery: ok
2014-12-01_21:08:20 TuerFensterKontakt.Bad sabotageError: off
2014-12-01_21:08:20 TuerFensterKontakt.Bad closed
2014-12-01_21:08:20 TuerFensterKontakt.Bad contact: closed (to broadcast)
2014-12-01_22:01:11 TuerFensterKontakt.Bad Activity: dead
2014-12-01_22:05:21 TuerFensterKontakt.Bad alive: yes
2014-12-01_22:05:21 TuerFensterKontakt.Bad battery: ok
2014-12-01_22:05:21 TuerFensterKontakt.Bad sabotageError: off
2014-12-01_22:05:21 TuerFensterKontakt.Bad closed
2014-12-01_22:05:21 TuerFensterKontakt.Bad contact: closed (to broadcast)
2014-12-01_22:11:11 TuerFensterKontakt.Bad Activity: alive
2014-12-01_22:58:30 TuerFensterKontakt.Bad alive: yes
2014-12-01_22:58:30 TuerFensterKontakt.Bad battery: ok
2014-12-01_22:58:30 TuerFensterKontakt.Bad sabotageError: off
2014-12-01_22:58:30 TuerFensterKontakt.Bad closed
2014-12-01_22:58:30 TuerFensterKontakt.Bad contact: closed (to broadcast)
2014-12-01_22:58:32 TuerFensterKontakt.Bad ResndFail
2014-12-01_22:58:32 TuerFensterKontakt.Bad MISSING ACK
2014-12-01_23:51:12 TuerFensterKontakt.Bad Activity: dead
2014-12-01_23:56:06 TuerFensterKontakt.Bad alive: yes
2014-12-01_23:56:06 TuerFensterKontakt.Bad battery: ok
2014-12-01_23:56:06 TuerFensterKontakt.Bad sabotageError: off
2014-12-01_23:56:06 TuerFensterKontakt.Bad closed
2014-12-01_23:56:06 TuerFensterKontakt.Bad contact: closed (to broadcast)
2014-12-02_00:01:12 TuerFensterKontakt.Bad Activity: alive
2014-12-02_00:51:13 TuerFensterKontakt.Bad Activity: dead
2014-12-02_00:52:16 TuerFensterKontakt.Bad alive: yes
2014-12-02_00:52:16 TuerFensterKontakt.Bad battery: ok
2014-12-02_00:52:16 TuerFensterKontakt.Bad sabotageError: off
2014-12-02_00:52:16 TuerFensterKontakt.Bad closed
2014-12-02_00:52:16 TuerFensterKontakt.Bad contact: closed (to broadcast)
2014-12-02_01:01:13 TuerFensterKontakt.Bad Activity: alive
2014-12-02_01:51:13 TuerFensterKontakt.Bad Activity: dead
2014-12-02_02:43:40 TuerFensterKontakt.Bad alive: yes
2014-12-02_02:43:40 TuerFensterKontakt.Bad battery: ok
2014-12-02_02:43:40 TuerFensterKontakt.Bad sabotageError: off
2014-12-02_02:43:40 TuerFensterKontakt.Bad closed
2014-12-02_02:43:40 TuerFensterKontakt.Bad contact: closed (to broadcast)
2014-12-02_02:51:14 TuerFensterKontakt.Bad Activity: alive
2014-12-02_03:36:10 TuerFensterKontakt.Bad alive: yes
2014-12-02_03:36:10 TuerFensterKontakt.Bad battery: ok
2014-12-02_03:36:10 TuerFensterKontakt.Bad sabotageError: off
2014-12-02_03:36:10 TuerFensterKontakt.Bad closed
2014-12-02_03:36:10 TuerFensterKontakt.Bad contact: closed (to broadcast)
2014-12-02_03:36:15 TuerFensterKontakt.Bad ResndFail
2014-12-02_03:36:15 TuerFensterKontakt.Bad MISSING ACK
2014-12-02_04:31:14 TuerFensterKontakt.Bad Activity: dead
2014-12-02_05:23:31 TuerFensterKontakt.Bad alive: yes
2014-12-02_05:23:31 TuerFensterKontakt.Bad battery: ok
2014-12-02_05:23:31 TuerFensterKontakt.Bad sabotageError: off
2014-12-02_05:23:31 TuerFensterKontakt.Bad closed
2014-12-02_05:23:31 TuerFensterKontakt.Bad contact: closed (to broadcast)

Gruß
Ron

[franky08]

Wie sind die RSSI Werte, ein list vom Sensor wäre auch hilfreich, ist das Pairing OK?

VG
Frank

[FHEMAN]

Ich habe die RSSI Werte und einen Logauszug oben eingefügt.
Verzeih mir meine Unwissenheit - wie ermittle ich ein list des Sensors und überprüfe das Pairing?

Code Auswählen Erweitern

Internals:
   CUL0_MSGCNT 23
   CUL0_RAWMSG A0D6C861030B4A900000006010000::-85:CUL0
   CUL0_RSSI  -85
   CUL0_TIME  2014-12-02 16:39:01
   DEF        30B4A9
   IODev      CUL0
   LASTInputDev CUL0
   MSGCNT     23
   NAME       TuerFensterKontakt.Bad
   NR         151
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:6C - t:10 s:30B4A9 d:000000 06010000
   protCmdDel 8
   protLastRcv 2014-12-02 16:39:01
   protResnd  6 last_at:2014-12-02 02:43:42
   protResndFail 2 last_at:2014-12-02 03:36:15
   protSnd    8 last_at:2014-12-02 03:36:10
   protState  CMDs_done_Errors:1
   rssi_at_CUL0 avg:-89.43 min:-104 max:-79 lst:-85 cnt:23
   Readings:
     2014-12-02 15:51:20   Activity        alive
     2014-11-23 00:19:17   D-firmware      1.0
     2014-11-23 00:19:17   D-serialNr      LEQ1173422
     2014-11-22 01:58:46   R-pairCentral   set_0xF10703
     2014-11-22 01:58:46   aesKeyNbr       00
     2014-12-02 16:39:01   alive           yes
     2014-12-02 16:39:01   battery         ok
     2014-12-02 16:39:01   contact         closed (to broadcast)
     2014-12-02 16:39:01   recentStateType info
     2014-12-02 16:39:01   sabotageError   off
     2014-12-02 16:39:01   state           closed
     2014-12-02 08:43:07   trigDst_broadcast noConfig
   Helper:
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     rxType     28
     Io:
       newChn     +30B4A9,00,01,1E
       nextSend   1417534741.38072
       prefIO
       rxt        2
       vccu
       p:
         30B4A9
         00
         01
         1E
     Mrssi:
       mNo        6C
       Io:
         CUL0       -83
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_cul0:
         avg        -89.4347826086957
         cnt        23
         lst        -85
         max        -79
         min        -104
Attributes:
   IODev      CUL0
   actCycle   000:50
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon closed:fts_door_right open:fts_door_right_open
   expert     2_full
   firmware   1.0
   model      HM-SEC-SCo
   room       Fenster
   serialNr   LEQ1173422
   subType    threeStateSensor

[frank]

Da dieses Verhalten meine open/close Auswertung torpediert

das kann nicht passieren, wenn du ein anderes reading auswertest, wahrscheinlich "contact", oder die auswertung des state verbessern.

edit: ausserdem rssi verbessern.

[franky08]

Hallo, mit angrenzender Wahrscheinlichkeit liegt es am Empfang. Rssi Werte über -80 dB sind schlecht, d.h. Dein IO device empfängt deinen Sensor sogut wie nie, dasshalb missingAck.

[FHEMAN]

OK, das Contact Reading werde ich zukünftig auswerten. Danke für den Hinweise. Obwohl ich dann sicherlich nicht mitbekomme, wenn das Fenster öffnet und ein Missing ACK "sendet"?

Was den Empfang angeht, das habe ich bei mehreren TFK Modulen, selbst welchen im selben oder Nebenraum (rssi_at_CUL0 avg:-63.06 min:-64.5 max:-59 lst:-62 cnt:23).

Gibt es vielleicht noch eine andere Ursache?

[franky08]

Das sind auch gute Werte, die nicht über -80 db liegen. Mit den -85 vom Sensor, wirst du nicht glücklich werden. Du könntest dein IO device näher an den Sensor bringen oder die Antenne vom Sensor nach aussen legen. Den rssi solltest du auf jeden Fall verbessern.

[Deudi]

Code Auswählen Erweitern

     2014-11-22 01:58:46   R-pairCentral   set_0xF10703

Hat der Sensor das Pairing abgeschlossen? Mache mal ein getConfig. Dann muss das "set_" weg sein. Ich habe den Sensor selbst nicht, vielleicht sendet der dann auch nicht mehr nach broadcast.

[Rohan]

Hi,

Hat der Sensor das Pairing abgeschlossen?

Nein, wird es wohl nicht sein, denn:

Code Auswählen Erweitern

2014-12-02 16:39:01   contact         closed (to broadcast)

Der Sender weiß also nicht, an wen er die Nachricht schicken soll, also geht es an alle (eben broadcast).

Gruß
Thomas

[FHEMAN]

Ihr habt recht - das Pairing fand nicht statt. Schlimmer noch: es findet nicht statt.
Es liegt wohl am AES.
Kann ich die Sensoren jetzt nur eingeschränkt verwenden? Ich meine, ist das Pairing denn so wichtig? Hat das was mit dem Bidcos Rückkanal zu tun?
//Edit: gelöscht

[Rohan]

Hi,

mit BidCos hat das mM nichts zu tun. Aber Sendungen an Broadcast führt z.B. zum Aufwachen aller HM-Geräte, was zu Lasten der Batterielaufzeit gehen kann. Und das Peeren (direkte Kommunikation mit anderen HM-Geräten) per Fhem-Befehl klappt auch nicht. Sauber ist anders (also mit Pairing ist besser).

Benutzt du HM-LAN, HM-USB oder CUL? Manchmal reicht schon eine kleine Lageänderung um die Empfangsqualität zu steigern.

Gruß
Thomas

[FHEMAN]

Aber Sendungen an Broadcast führt z.B. zum Aufwachen aller HM-Geräte

Das ist interessant. Wie läuft überhaupt die Kommunikation ab und wo entsteht dabei ein Missing ACK?
Ich stelle mir das einfach formuliert so vor:

• Sender sendet (bspw. "open" oder "open (Broadcast)")
• Empfänger Zentrale und ggf. gepairter oder gepeerter Empfänger horcht, empfängt und sendet "Message empfangen"
• Sender horcht, empfängt und sendet "Message insgesamt erfolgreich gesendet und empfangen"
• Empfänger Zentrale empfängt, loggt Message bzw. Status

Verstehe ich es richtig, dass bei Ausbleiben von 3 ein Missing ACK entsteht?
Ich habe an der Antenne schon rumgespielt, aber bei Sichtkontakt erwarte ich eigentlich eine Verbindung, was ja auch der relativ gute RSSI zeigt. Wieso also Missing ACK.. 

[Rohan]

Hi,

sorry, aber

...was ja auch der relativ gute RSSI zeigt.

Sofern es bei den weiter oben belegten RSSI-Werten von über 80 geblieben ist, hat das Gerät schlechten Empfang. Ein Wert von 70 bedeutet besseren Empfang. Es ist bei RSSI nicht so, dass hier höhere Werte = bessere Werte sind.

Und zum Missing Ack .. vereinfacht: es wird eine Antwort vermisst (wegen Timeout, schlechter Empfang oder, oder, oder).

Gruß
Thomas

[FHEMAN]

Hi Thomas,

natürlich meine ich den Sensor in Sichtnähe mit rssi_at_CUL0 avg:-63.06 min:-64.5 max:-59 lst:-62 cnt:23
(Ich hatte meine ausführlichere Antwort letztens gelöscht, als ich festellte, dass AES das Pairing verhindert.)

D.h. ich kann ein Missing ACK nicht alleine durch Konfiguration verhindern?

[ph1959de]

Es ist bei RSSI nicht so, dass hier höhere Werte = bessere Werte sind.

Doch, schon ... wenn man das Vorzeichen beachtet