Anwesenheitserkennung Bluetooth PebbleBee

[PatrickR]

Hey Holger,

danke für das Update!

Kannst Du vielleicht eine externe Festplatte oder einen alten USB-Stick anschließen und auf den loggen? Ich gehe mal nicht davon aus, dass Du einen syslog-Server hast.

Zu Deinem Cronjob: Ich bin mir nicht sicher, welches Resultat Deine Notation hat. Eine Kombination mehrerer /-Notationen habe ich ehrlich gesagt noch nicht gesehen. Ich würde unabhängig davon auch davon abraten, das Skript so oft auszuführen. Mein erster G-Tag ist seit April 2015, also nach 17 Monaten, im Dauerbetrieb (also ungekoppelt, d. h. er sendet am laufenden Band) und läuft immer noch. Man sollte davon ausgehen, dass der Stromverbrauch konstant ist - zumindest sofern man ihn nicht mit periodischen Batteriefragen malträtiert. Insofern sollte eine Abfrage am Tag mehr als genug sein, z. B.:

Code Auswählen Erweitern


0 1 * * * /opt/fhem/script/Holger_GtAG_Batterie.sh >/dev/null 2>&1 ; /opt/fhem/script/Mirjam_GtAG_Batterie.sh >/dev/null 2>&1

Damit stellst Du auch gleich sicher, dass die beiden Skripte garantiert nicht zeitgleich laufen, was möglicherweise auch ein Problem ist. Das sehen wir aber gut wenn das Logging klappt.

Für den Test, ob es Wechselwirkungen zwischen lepresenced und den Batterieskripten gibt, ist diese häufige Ausführung aber gar nicht so schlecht.

@Alle, die das gleiche Problem haben:
Setzt Ihr auch RPi3s mit dem internen Bluetooth-Chip ein?


Grüße
Patrick

[DeeSPe]

Ich benutze auch das Skript, lasse es aber durch ein notify bei erkanntem present ausführen.
Das sichert dass der G-Tag wirklich zur Ausführungszeit auch anwesend ist.
Und mehr als 2-3x mal komme ich für gewöhnlich nicht nach Hause pro Tag.

Gruß
Dan

[CoolTux]

Ich benutze auch das Skript, lasse es aber durch ein notify bei erkanntem present ausführen.
Das sichert dass der G-Tag wirklich zur Ausführungszeit auch anwesend ist.
Und mehr als 2-3x mal komme ich für gewöhnlich nicht nach Hause pro Tag.

Gruß
Dan

Mache ich gaaanz genau so.

[SouzA]

Dürfte ich mal fragen, wie eure Anweisung dazu aussieht?
Bin auf der Suche nach einem Fehler...

https://forum.fhem.de/index.php/topic,58727.0.html


Thx
SouzA

[CoolTux]

Ist einfach ein Notify. Wenn presenceDevice present dann triggert das Notify und in meinem Fall wird eine Perl Sub ausgeführt damit die Abfrage NonBlocking passiert.

[forum-merlin]

Hey Holger,

danke für das Update!

Kannst Du vielleicht eine externe Festplatte oder einen alten USB-Stick anschließen und auf den loggen? Ich gehe mal nicht davon aus, dass Du einen syslog-Server hast.

Zu Deinem Cronjob: Ich bin mir nicht sicher, welches Resultat Deine Notation hat. Eine Kombination mehrerer /-Notationen habe ich ehrlich gesagt noch nicht gesehen. Ich würde unabhängig davon auch davon abraten, das Skript so oft auszuführen. Mein erster G-Tag ist seit April 2015, also nach 17 Monaten, im Dauerbetrieb (also ungekoppelt, d. h. er sendet am laufenden Band) und läuft immer noch. Man sollte davon ausgehen, dass der Stromverbrauch konstant ist - zumindest sofern man ihn nicht mit periodischen Batteriefragen malträtiert. Insofern sollte eine Abfrage am Tag mehr als genug sein, z. B.:

Code Auswählen Erweitern


0 1 * * * /opt/fhem/script/Holger_GtAG_Batterie.sh >/dev/null 2>&1 ; /opt/fhem/script/Mirjam_GtAG_Batterie.sh >/dev/null 2>&1

Damit stellst Du auch gleich sicher, dass die beiden Skripte garantiert nicht zeitgleich laufen, was möglicherweise auch ein Problem ist. Das sehen wir aber gut wenn das Logging klappt.

Für den Test, ob es Wechselwirkungen zwischen lepresenced und den Batterieskripten gibt, ist diese häufige Ausführung aber gar nicht so schlecht.

@Alle, die das gleiche Problem haben:
Setzt Ihr auch RPi3s mit dem internen Bluetooth-Chip ein?


Grüße
Patrick

Hi Patrick,

also ich habe mal deinen Vorschlag bzgl. der CRON Ausführung übernommen und bei mir so eingetragen.
Meine Werte habe ich einfach auskommentiert.
Danach noch ein cmd>service cron reload und gut is.

Dann hab ich noch drüber nachgedacht ob ich auf meiner Synology nen SYSLOG Server einrichte, und dachte mir, cool wäre es schon, aber dann lag direkt vor mir ein alter USB2.0 16GB Stick, und den hab ich mir nun als /var/log MountPoint per UUID in die fstab eingetragen.
Ein reboot, und schon hab ich ein 16GB Logfiles Device.
Nebeneffekt ist dass dadurch die CRON 100%ig geladen wurde.

So, jetzt mach ich grad ein tail auf das syslog und sehe da sehr stabil ein max age von 0, von 1, und hin und wieder mal ein age von 2

Worauf zielt Deine Frage ab ob wir einen Pi3 nutzen?
Willst Du Dein "lepresenced" umstricken so dass es konfigurierbar wird und man hci0, oder was anderes definieren kann? oder vll auch ein Logfiles Dir angeben?

Ich kenn mich damit ja nicht aus. Aber ich fände es genial wenn dieses Modul, oder Script Bestandteil von FHEM würde das per Modul eingerichtet werden könnte.

Für mich wird es immer schwerer den Überblick zu behalten was ich alles an Scripten am Laufen habe.

LG
Holger

[Devender]

Worauf zielt Deine Frage ab ob wir einen Pi3 nutzen?
Willst Du Dein "lepresenced" umstricken so dass es konfigurierbar wird und man hci0, oder was anderes definieren kann?

Hi Holger,
Du kannst bereits mit dem Attribute

Code Auswählen Erweitern

bluetooth_hci_device definieren welches hci Device angesprochen werden soll. Das kannst du beim jeweiligen G-tag z.B hinterlegen.

Ich nutze eine Pi2. Wenn ich so drüber nachdenken habe ich auch einen gTag, der eigentlich irgendwie immer abwesend ist.
Der liegt im Auto und das steht in der Einfahrt. Aktuell in der Garage. Er ist meist abwesend. Auto zwei ist aber egal wo es steht korrekt Anwesend oder Abwesend.
Ich deaktiviere jetzt auch mal das Batteriescript welches per Cron gesteuert wird.
Mal sehen was sich verändert...

Gruesse,
Dirk

[forum-merlin]

Hi Holger,
Du kannst bereits mit dem Attribute

Code Auswählen Erweitern

bluetooth_hci_device definieren welches hci Device angesprochen werden soll. Das kannst du beim jeweiligen G-tag z.B hinterlegen.

Ich nutze eine Pi2. Wenn ich so drüber nachdenken habe ich auch einen gTag, der eigentlich irgendwie immer abwesend ist.
Der liegt im Auto und das steht in der Einfahrt. Aktuell in der Garage. Er ist meist abwesend. Auto zwei ist aber egal wo es steht korrekt Anwesend oder Abwesend.
Ich deaktiviere jetzt auch mal das Batteriescript welches per Cron gesteuert wird.
Mal sehen was sich verändert...

Gruesse,
Dirk

Und vielleicht hilft bei Dir auch ein Kernel-Update!
Seit dem ich das gemacht habe läuft das alles wie geschmiert. Also ich empfinde es wirklich so.
Die heutigen Änderungen habe ich eigentlich proaktiv gemacht, da sie grundsätzlich Sinn machen.

Ich habe auch gerade noch die Anpassung mit der Blacklist für Kernel und Syslog Messages gemacht.
Auch wenn ich jetzt auf einen USB Stick schreibe, muss ich ja nicht andauernd diese Meldungen haben die Schreibzugriffe bedeuten. Auch ein Stick lebt nicht ewig.

[Devender]

Ein rpi-update wäre mir aktuell zu unsicher.
Du nutzt ja einen Pi3. Aus deinem Link weiter oben geht nicht hervor mit welcher Hardware der Threadersteller arbeitet.
Mein externer BT-Stick läuft ja einwandfrei und schreibt keine Fehler ins Log.

Vielleicht liegt es auch an der Entfernung bzw. irgendwelchen "Umwelteinflüssen"...
Ich weiß auch nicht, in wie fern das Metall eines Autodaches oder bedampfte Scheiben die Sendeleistung eines Tags beeinflussen.
Ich hole den Tag morgen mal ins Haus. Wenn er dann wieder erkannt wird kann es ja nur an der Sendeleistung liegen.

Ich werde berichten 

[PatrickR]

Hallo Holger!

So, jetzt mach ich grad ein tail auf das syslog und sehe da sehr stabil ein max age von 0, von 1, und hin und wieder mal ein age von 2

Auch wenn das Batterieskript läuft?

Worauf zielt Deine Frage ab ob wir einen Pi3 nutzen?
Willst Du Dein "lepresenced" umstricken so dass es konfigurierbar wird und man hci0, oder was anderes definieren kann? oder vll auch ein Logfiles Dir angeben?

Nein. Das Device ist schon konfigurierbar und ich sehe keinen Grund, anderes Logging als Syslog einzubauen. Das Flash-Problem würde es nicht besser lösen als die Dinge, die Du jetzt schon umgesetzt hast. Mit der Frage nach dem Pi3 ging es mir lediglich darum, ob vielleicht der Bluetooth-Chip das Problem ist.

Patrick

[forum-merlin]

Hallo Holger!
Auch wenn das Batterieskript läuft?
Nein. Das Device ist schon konfigurierbar und ich sehe keinen Grund, anderes Logging als Syslog einzubauen. Das Flash-Problem würde es nicht besser lösen als die Dinge, die Du jetzt schon umgesetzt hast. Mit der Frage nach dem Pi3 ging es mir lediglich darum, ob vielleicht der Bluetooth-Chip das Problem ist.

Patrick

Hi Patrick,
ja, ich habe das Batt-Script einfach mal manuell MEHRFACH (3x) getriggert während ich ein tail auf mein syslog gemacht habe...
Siehe Log Auszug:

Code Auswählen Erweitern


Oct 14 23:58:31 fhempi3 lepresenced[1184]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 14 23:58:39 fhempi3 lepresenced[1184]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 2, max age: 30, result: present.
Oct 14 23:58:39 fhempi3 rsyslogd-2007: action 'action 19' suspended, next retry is Fri Oct 14 23:59:39 2016 [try http://www.rsyslog.com/e/2007 ]
Oct 14 23:58:40 fhempi3 gtagbattery: Hole Batteriewert für Holger_GtAG
Oct 14 23:58:42 fhempi3 lepresenced[1184]: [tid:1] main::bluetooth_thread: Received unknown output: 'Disable scan failed: Input/output error'!
Oct 14 23:58:42 fhempi3 lepresenced[1184]: [tid:1] main::bluetooth_thread: hcitool exited, retrying...
Oct 14 23:58:43 fhempi3 gtagbattery: Fertig
Oct 14 23:58:43 fhempi3 lepresenced[1184]: [tid:1] main::bluetooth_thread: Received 'LE Scan ...'.
Oct 14 23:59:01 fhempi3 lepresenced[1184]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 14 23:59:01 fhempi3 CRON[2802]: (root) CMD (/SCRIPTE/send-ip-mail-evening.sh)
Oct 14 23:59:01 fhempi3 CRON[2798]: (CRON) info (No MTA installed, discarding output)
Oct 14 23:59:09 fhempi3 lepresenced[1184]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 14 23:59:21 fhempi3 gtagbattery: Hole Batteriewert für Holger_GtAG
Oct 14 23:59:22 fhempi3 lepresenced[1184]: [tid:1] main::bluetooth_thread: Received unknown output: 'Disable scan failed: Input/output error'!
Oct 14 23:59:22 fhempi3 lepresenced[1184]: [tid:1] main::bluetooth_thread: hcitool exited, retrying...
Oct 14 23:59:23 fhempi3 gtagbattery: Fertig
Oct 14 23:59:23 fhempi3 lepresenced[1184]: [tid:1] main::bluetooth_thread: Received 'LE Scan ...'.
Oct 14 23:59:31 fhempi3 lepresenced[1184]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 2, max age: 30, result: present.
Oct 14 23:59:34 fhempi3 gtagbattery: Hole Batteriewert für Holger_GtAG
Oct 14 23:59:35 fhempi3 lepresenced[1184]: [tid:1] main::bluetooth_thread: Received unknown output: 'Disable scan failed: Input/output error'!
Oct 14 23:59:35 fhempi3 lepresenced[1184]: [tid:1] main::bluetooth_thread: hcitool exited, retrying...
Oct 14 23:59:36 fhempi3 lepresenced[1184]: [tid:1] main::bluetooth_thread: Received 'LE Scan ...'.
Oct 14 23:59:36 fhempi3 gtagbattery: Fertig
Oct 14 23:59:39 fhempi3 lepresenced[1184]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 14 23:59:39 fhempi3 rsyslogd-2007: action 'action 19' suspended, next retry is Sat Oct 15 00:00:39 2016 [try http://www.rsyslog.com/e/2007 ]


Gruß
Holger

[PsychoD]

OK, Danke! Werde ich machen, ich bekomme in ca. 3 Tagen hoffentlich mein iPhone zurück, dann kann ich das Pairing löschen und werde berichten.

Ich habe nun rausgefunden, dass der Tag bei einem "sudo hcitool lescan" auch gefunden wird, und anschließend auch wieder im FHEM auftaucht.

Es wirkt auf mich alles, als würde das Bluetooth Modul am RPI irgendwie schlafen gehen oder so - finde aber keine Infos dazu, dass sowas möglich wäre...

Bleibe dran und freue mich über Tipps!
Viele Grüße
Psy

Ich habe Neuigkeiten! Zunächst habe ich das Pairing im iPhone aufgehoben, ohne Erfolg.

Ich habe heute Morgen jedoch dann mal das Battery-Skript aus dem Cron rausgenommen, und den Pi neugestartet. Als ich heute Abend nach Hause kam, ist der Tag gefunden worden!!!! Meine aktuelle Theorie ist, dass das Battery-Skript, welches ich sonst zu jeder vollen Stunde aufrufe, abschmiert wenn der Tag nicht in Reichweite ist. Erst beim nächsten Scan, bei dem auch der Tag wieder in Reichweite ist, stabilisiert sich der Zustand wieder. Soweit meine Theorie - wenn dem so ist, ist der einzige Weg den Batteriestatus zu prüfen wirklich an Presence gekoppelt.

Ich hoffe es bleibt so, werde berichten. 

Viele Grüße
Psy

[PatrickR]

Hey Holger!

Code Auswählen Erweitern


Oct 14 23:58:40 fhempi3 gtagbattery: Hole Batteriewert für Holger_GtAG
Oct 14 23:58:42 fhempi3 lepresenced[1184]: [tid:1] main::bluetooth_thread: Received unknown output: 'Disable scan failed: Input/output error'!
Oct 14 23:58:42 fhempi3 lepresenced[1184]: [tid:1] main::bluetooth_thread: hcitool exited, retrying...
Oct 14 23:58:43 fhempi3 gtagbattery: Fertig
Oct 14 23:58:43 fhempi3 lepresenced[1184]: [tid:1] main::bluetooth_thread: Received 'LE Scan ...'.


Da sieht man gut, dass das Batterieskript den Scan zerschießt. Glücklicherweise ist das in dem Fall nicht dramatisch, da lepresenced das detektiert.

Patrick

[forum-merlin]

Aber so oder so ist das Batterie Script dann kontraproduktiv und bringt auch dann nichts wenn man es zusammen mit presence koppelt. Aber ich muss auch sagen dass es sich mit dem reconnect besser seit dem neuen Kernel verhält. Ich kann mich aber auch irren.


Gesendet von meinem SM-G920F mit Tapatalk

[PatrickR]

Hi!

Aber so oder so ist das Batterie Script dann kontraproduktiv und bringt auch dann nichts wenn man es zusammen mit presence koppelt. Aber ich muss auch sagen dass es sich mit dem reconnect besser seit dem neuen Kernel verhält. Ich kann mich aber auch irren.

Ich hatte bei der Entwicklung von blescan.pl (dem Vorgänger von lepresenced) generell riesigie Probleme mit der Bluetooth-Implementierung. blescan hat ja für jeden Check einen neuen Scanprozess auf und nach der eingestellten Zeit (z. B. 30 Sekunden) wieder zugemacht. Dabei kam es oft vor, dass sich der Scan nicht starten ließ, so dass nur noch hciconfig reset half. Das ist alles in lepresenced auch noch drin, greift aber sehr selten, da der Scan nur noch selten gestartet wird.

Was ich damit sagen will: Die Bluetooth-Implementierung unter Linux (vermutlich tatsächlich der Kernel-Part) ist nicht gerade bugfrei. Daher könnte Deine Beobachtung passen.

Patrick