Problem mit BLE Adapater

[moses123]

Hallo Zusammen,

ich verwendet aktuell den BLE Adapter, da ich neben der Anwesend- Erkennung auch noch ein paar Xiaomi Thermometer auslese.

Für die Anwesend- Erkennung werden Gigaset GTags (Bluetoothbeacons) genutzt. Diese werden erkannt und es gibt auch rssi- Werte.

Über die rssi Werte läuft die Erkennung, wenn der Timestamp des rssi-Wertes sich über einen definierten Zeitraum nicht ändert, wird davon ausgegangen, dass dieses Beacon nicht mehr in Reichweite ist, also der Besitzer weg ist.

Leider gab es bei der letzten Version wohl eine Änderung, so dass der rssi-Wert nur neu in den State geschrieben wird, wenn sich dieser geändert hat. Bei einem am Schlüsselbund hängenden und in der Ecke liegenden GTag ein Problem, da der rssi-Wert dann auch mal gleich bleiben kann. Mit dem Ergebnis, dass dieser auch mal als Abwesend erkannt wird, weil sich der Timestamp nicht ändert. Und im Haus die Lichter ausgehen und der Alarm scharf geschaltet wird...

Ich könnte die Zeile im Adapter ändern, aber vielleicht hat ja jemand eine Idee, welche Infos ich statt des Timestamps nutzen könnte.
Radar2 geht leider nicht, da ich mit diesem die Xiaomi Thermometer nicht auslesen kann und beide Zusammen stören sich...

Gruß,
Moses123

[AlCalzone]

@moses123 Kannste mir mal ein Debug-Log machen? Eigentlich sollte sich da nichts geändert haben.

[moses123]

Hallo,

ich bin gerade dabei, das Problem nachzustellen. Ich hatte ja eine Zeile im Verdacht, die verhindern soll, dass zu oft ein Update vom rssi durchgeführt wird.

Ich lasse mal den History mitlaufen, um zu sehen, ob da eine zu große Lücke entsteht. Seit meiner ersten Meldung ist es ruhig geblieben, der PI wurde aber auch mal neu gestartet...

[moses123]

So, heute Nacht ist es dann drei mal aufgetreten, im History sieht man Lücken für den rssi-Update.

Debug habe ich jetzt mal noch nicht mitlaufen lassen, da ich gestern keine Zeit hatte, das so einzurichten, dass der SD-Karte nicht voll läuft.

Die History sieht dann so aus:

-71	true		2020-12-28 00:07:29.582	00:07:29.582
-81	true		2020-12-28 00:07:18.536	00:07:18.536
-82	true		2020-12-28 00:07:08.486	00:07:08.486
-77	true		2020-12-28 00:06:57.406	00:06:57.406
-82	true		2020-12-28 00:06:39.331	00:06:39.331
-71	true		2020-12-28 00:04:22.591	00:04:22.591*
-81	true		2020-12-28 00:04:02.489	00:04:02.489
-71	true		2020-12-28 00:01:34.679	00:01:34.679*
-81	true		2020-12-28 00:01:19.609	00:01:19.609
-71	true		2020-12-28 00:01:08.552	00:01:08.552
-81	true		2020-12-28 00:00:58.490	00:00:58.490
-71	true		2020-12-28 00:00:40.414	00:00:40.414
-81	true		2020-12-28 00:00:29.341	00:00:29.341
-82	true		2020-12-28 00:00:19.284	00:00:19.284
-71	true		2020-12-28 00:00:02.197	00:00:02.197

In der Regel erfolgt das Update innerhalb von ca. 20 Sekunden (ist im Adapter so eingestellt), so dass mein Skript dann nicht reagiert, aber es gibt dort auch Lücken (00:01:34 und 00:04:22), da sind die Abstände>2 Min.

Ich vermute, da keinerlei doppelten rssi-Werte in der Reihe auftauchen, dass hier die Filterung in Zeile 387 eine Rolle spielt:

(rssiState.val !== peripheral.rssi && // only save changes

Diese Zeile ist vor 2 Monaten bei der 0.12 dazu gekommen. Eigentlich macht diese Zeile keinen Sinn, denn es können ja auch mal gleiche rssi- Werte gelesen werden, wenn auch recht selten...

[moses123]

Nachtrag: Geändert habe ich die Zeilen an der Stelle im Main.ts so, also SaveChanges raus, und Prüfung auf TS nicht LC:

if (rssiState == null ||
        //(rssiState.val !== peripheral.rssi && // only save changes
           ( rssiState.ts + rssiUpdateInterval < Date.now()) // and dont update too frequently
    ) {

Und nun sieht das Historylog so aus, es wird jetzt schön regelmäßig ein Wert geschrieben, auch wenn der dem vorigen entspricht:

-81	true		2020-12-28 08:22:56.761	
-71	true		2020-12-28 08:22:46.722	
-77	true		2020-12-28 08:22:35.664	
-77	true		2020-12-28 08:22:24.587	
-81	true		2020-12-28 08:22:14.547	
-71	true		2020-12-28 08:22:03.495	
-81	true		2020-12-28 08:21:53.434	
-81	true		2020-12-28 08:21:43.378	
-81	true		2020-12-28 08:21:33.329	
-71	true		2020-12-28 08:21:22.271	
-81	true		2020-12-28 08:21:12.207	
-81	true		2020-12-28 08:21:02.163	
-71	true		2020-12-28 08:20:51.103	
-81	true		2020-12-28 08:20:41.039	
-71	true		2020-12-28 08:20:30.994	
-81	true		2020-12-28 08:20:20.945	
-81	true		2020-12-28 08:20:09.871	
-71	true		2020-12-28 08:19:59.830	
-77	true		2020-12-28 08:19:48.766

[AlCalzone]

@moses123 sagte in Problem mit BLE Adapater:

Eigentlich macht diese Zeile keinen Sinn, denn es können ja auch mal gleiche rssi- Werte gelesen werden, wenn auch recht selten...

Joar, das hängt vom Anwendungsfall ab, ob das Sinn macht. Wenn man die RSSI nicht betrachtet, dann reduziert diese Prüfung die Anzahl der Updates massiv. Kann ich aber gerne konfigurierbar machen.