Viele Wege führen nach Rom ...

Ich habe das Ganze für das Ein- und Ausschalten der HMIP Alarmfunktion mit den GTags und dem BLE- Adapter gemacht.

Der BLE Adapter schreibt alle paar Sekunden die Signalstärke der GTags in einen State pro GTAG.

Jedes mal, wenn die Signalstärke geschrieben wird, dann setzte ich eine Variable auf TRUE, das der entsprechende GTag da ist.

Nur wenn die Variable auf TRUE geändert wird, dann deaktiviere ich die Alarmanlage. Im Fall hier könnte dann das Licht im Carport eingeschaltet werden.

Auf FALSE wird die Variable gesetzt, wenn der Zeitstempel der letzten Änderung der Signalstärke > 60 Sekunden ist. Und nur bei der Änderung der Variable auf FALSE wird die Alarmanlage aktiviert.

Gruß,
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

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

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

@UncleSam said in Anwesenheitserkennung:

Wie wäre es mit BLE Tags? Je einer an Autoschlüssel oder sogar im Auto.

Ich habe noch nie sowas gemacht, wäre für mich auch interessant zu wissen, ob das geht.

Grundsätzlich geht das, habe ich mit dem BLE- Adapter und Gigaset GTags realisiert. War bisher recht zuverlässig, nur eine Änderung im Adapter hat da zuletzt ein wenig die Funktion eingeschränkt. Alternativ geht auch der Adapter radar2

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

@Bluefox

redis-cli -v
redis-cli 5.0.3

redis-server -v
Redis server v=5.0.3 sha=00000000:0 malloc=jemalloc-5.1.0 bits=32 build=1b271fe49834c463

Das war der Fehler im Log:

2020-12-25 09:48:57.552  - error: host.raspberrypi Caught by controller[0]: Error scan NOT SUPPORTED
2020-12-25 09:48:57.553  - error: host.raspberrypi Caught by controller[0]: ReplyError: Error scan NOT SUPPORTED
2020-12-25 09:48:57.553  - error: host.raspberrypi Caught by controller[0]:     at parseError (/opt/iobroker/node_modules/redis-parser/lib/parser.js:179:12)
2020-12-25 09:48:57.553  - error: host.raspberrypi Caught by controller[0]:     at parseType (/opt/iobroker/node_modules/redis-parser/lib/parser.js:302:14)

Hallo,

ich bin vor kurzen von Hue Bridge auf einen Echo Plus umgestiegen. Ich habe bisher alle Leuchten usw. an der Bridge im Echo Plus anlernen können.
Doch es gibt zwei Tradfri Leuchten, die sich standhaft weigern, am Echo Plus anzubinden, sie tauchen in der Alexa-App einfach nicht auf, egal was ich mache (6 x An/Aus, zurücksetzen mit Hue Dimmer).
An die Tradfribridge lassen sich die Lampen ohne Probleme anlernen, nur nicht am Echo.

Gibt es irgendwie noch eine anderen Weg, die Lampen da dran zu bekommen?

Ich habe es auch mal mit dem Umweg über den Ikea Bewegungsmelder gemacht, geht auch nicht.

Gruß,
Moses1234

Sony Xperia XA2 mit Browser geht auch ohne Probleme. Super, dass es jetzt was gibt, um die neuen Versionen ohne gepatchte App einzubinden. Läuft bisher super. Binde gerade den dritten Sensor ein...

Ähnliches Problem bei mir,
nutze Chromium in Kioskmode mit HapPanel auf Raspi3 mit 7" Display. Auch hier wird nach einer gewissen Zeit keine Aktualisierung von States mehr durchgeführt (Schalter, Temperaturen usw).

Die Anzeige sagt dann 18.5°C, aber im State dazu stehen 11 Grad.

Hat eigentlich eine ganze Zeit funktioniert, irgendwann ist das dann aufgetreten, aber leider kann ich nicht mehr nachvollziehen, ab wann.

Gruß,
Moses123