NEWS
Problem mit BLE Adapater
-
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 -
@moses123 Kannste mir mal ein Debug-Log machen? Eigentlich sollte sich da nichts geändert haben.
-
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...
-
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...
-
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
-
@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.