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.
CUL0_RSSI
-85.5
rssi_at_CUL0
avg:-89.63 min:-104 max:-79 lst:-85.5 cnt:22
Hier mal ein Logauszug:
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
Wie sind die RSSI Werte, ein list vom Sensor wäre auch hilfreich, ist das Pairing OK?
VG
Frank
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?
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
ZitatDa 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.
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.
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?
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.
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.
Hi,
Zitat von: Deudi am 03 Dezember 2014, 06:57:29
Hat der Sensor das Pairing abgeschlossen?
Nein, wird es wohl nicht sein, denn:
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
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
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
Zitat von: Rohan am 04 Dezember 2014, 08:37:05Aber 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.. :-\
Hi,
sorry, aber
Zitat von: derron am 04 Dezember 2014, 13:30:04...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
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?
Zitat von: Rohan am 04 Dezember 2014, 13:39:54
Es ist bei RSSI nicht so, dass hier höhere Werte = bessere Werte sind.
Doch, schon ... wenn man das Vorzeichen beachtet ;)
Hi,
@ph1959de: Jupp, wird aber gerne übersehen, dass da ein Minus vorsteht (spreche ich mich nicht von frei in der Anfangszeit)
@derron: Ich weiß nicht, ob deine Probleme sich (hier und im andern Thread bzgl. CUL) durch die Anschaffung eines HM-LAN ändern (im Sinne von verbessern) würden, ich glaube es aber.
Ein Missing Ack per Konfiguration verhindern? Ich glaube nicht, dass das geht bzw. macht das keinen Sinn, denn dann würde man ja gerade auf die durch bidirektonale Kommunikation (gegenüber z.B. FS20) erhaltenen Vorteile verzichten.
Gruß
Thomas
Da ich die Sensoren als Überwachung nutzen möchte, wäre es schon sinnvoll zu wissen, in welcher Richtung es klemmt. Wenn es auf dem Rückeg von der Zentrale zum Sensor hakt, wäre mir das nicht so wichtig.
Ich will nur nicht, dass ein Sensor "open" nicht von der Zentral registriert wird.
Kann ich der Sache irgendwie weiter auf den Grund gehen?
Das billigste ist vermutlich, erst mal die interne Antenne zu tauschen. Auslöten, doppelt so langen Draht zurechtschneiden und den anlöten.
Mit etwas Glück hilft das ja schon?