Anwesenheitserkennung Bluetooth PebbleBee

[gero]

Meiner Meinung nach findet das Buffering im hcitool Prozess statt und kann nicht so einfach umgangen werden. Daher wird in den Scripten der hcitool Prozess regelmäßig gekillt und wieder neu gestartet.
Aber vielleicht findet Andre ja eine elegantere Lösung. Mich wundert nur, das es bei einigen zu funtkionieren scheint.

[justme1968]

ich glaube nicht das die ausgabe vom hcitool gebuffert ist (dann würde es beim aufruf von hand ja auch nur häppchenweise ankommen) sondern die eingabe auf fhem seite. obwohl hier eigentlich auf nonblocking gestellt wird. warum das hier schief geht und bei anderen funktioniert verstehe ich gerade noch nicht.

gruss
  andre

[Steffen]

Hallo!

Vielleicht könnte ja jeder hier der es im Betrieb hat und auch "@Mitch" mal seine Timestamp und sein log(verbose5) hier freundlicher weise posten,
dann könnte man vergleichen und vielleicht etwas erkennen?!

Ich nutze es ja gerade zum Testen auf einen Ubuntu Server, aber teste es heute Nachmittag nochmal auf meinem Cubitruck wie es sich da verhält!

Mfg Steffen

[justme1968]

ich habe noch  mal etwas nachgeforscht. das sysread das ich zum lesen verwende ist lat perl dokumentation nicht gebuffert. d.h. ich verstehe es noch weniger...

[gero]

ich glaube nicht das die ausgabe vom hcitool gebuffert ist (dann würde es beim aufruf von hand ja auch nur häppchenweise ankommen) sondern die eingabe auf fhem seite. obwohl hier eigentlich auf nonblocking gestellt wird. warum das hier schief geht und bei anderen funktioniert verstehe ich gerade noch nicht.

gruss
  andre

Was durch ein printf im hcitool auf der Konsole ausgegeben wird, wird noch lange nicht durch eine stdout pipe weitergeleitet.
Deshalb gibt ein

Code Auswählen Erweitern

hcitool lescan --duplicates | grep .
auch erst eine Ausgabe, wenn der Inputbuffer der Pipe voll ist.

Das Problem läßt sich umgehen, wenn man den Output von hcitool explizit auf linebufferd umstellt:

Code Auswählen Erweitern

stdbuf -oL -eL hcitool lescan --duplicates | grep .
Achtung! Für den Befehl muß auch stdbuf als root ausgeführt werden.

@Steffen:
D.h. es solte funktionieren, wenn du den Befehl im PRESENCED wie folgt abänderst:

Code Auswählen Erweitern

sudo stdbuf -oL -eL hcitool lescan --duplicates
Jetzt mußt du nur dafür sorgen, dass der sudo Aufruf ohne Passwort möglich ist.

Gruß,
Gero

[justme1968]

stdout ist unter linux normalerweise line buffered. d.h. jede komplette zeile kommt sofort auf der konsole an. für das hcitool ist es normalerweise völlig transparent ob es eine 'echte' konsole oder eine pipe in einen anderen prozess ist. stdout durch die shell aufgerufen ist letzen endes auch nichts anderes. der buffer auf der senden seite sollte durch die libs in beiden fällen gleich initialisiert werden.

Code Auswählen Erweitern

hcitool lescan --duplicates | grep .auch erst eine Ausgabe, wenn der Inputbuffer der Pipe voll ist.

wo hast du dieses verhalten gesehen? das ist auf keinem system das ich kenne so. hier wird direkt eine zeile ausgegeben wenn eine komplette zeile gefunden wurde.

das

Code Auswählen Erweitern

| grep 00am ende des befehls im PRESENCED ist nicht nötig.

gruss
  andre

[gero]

stdout ist unter linux normalerweise line buffered. d.h. jede komplette zeile kommt sofort auf der konsole an. für das hcitool ist es normalerweise völlig transparent ob es eine 'echte' konsole oder eine pipe in einen anderen prozess ist. stdout durch die shell aufgerufen ist letzen endes auch nichts anderes. der buffer auf der senden seite sollte durch die libs in beiden fällen gleich initialisiert werden.
wo hast du dieses verhalten gesehen? das ist auf keinem system das ich kenne so. hier wird direkt eine zeile ausgegeben wenn eine komplette zeile gefunden wurde.

Ich habe es soeben auf einem Linuxrechner ausprobiert. Warum hcitool lescan ein anderes Ouputbuffer-Handling hat, weiß ich nicht. Es verwendet jedenfalls ein normales printf zur Ausgabe. Um das Problem genau zu verstehen müßte ich tiefer in den Code schauen.

das

Code Auswählen Erweitern

| grep 00am ende des befehls im PRESENCED ist nicht nötig.

Copy and Paste Fehler. Sorry! Ich habe es geändert.

Gruß,
Gero

[gero]

Hier noch ein paar andere Ansätze und die Erklärung der Hintergründe:

http://unix.stackexchange.com/questions/25372/turn-off-buffering-in-pipe

Gruß,
Gero

[justme1968]

die erklärung würde tatsächlich für den aufruf aus PRESENCED greifen. aber nicht die unterschiede zwischen den systemen erklären. das die systeme bei denen es funktioniert so viel output liefern das der buffer immer voll läuft mag ich nicht glauben.

warum du das mit deinem | grep beispiel nachstellen kannst verstehe ich auch noch nicht. das kann ich hier nämlich nicht. versuch mal das folgende in ein test.sh script zu stecken

Code Auswählen Erweitern

echo 1;
sleep 1;
echo 2;
sleep 1;
echo 1;
sleep 1;
echo 2;
und dann mit

Code Auswählen Erweitern

sh test.sh | grep 1aufzurufen. du solltest die zeilen mit der 1 jeweils sofort sehen so wie es bei line buffered sein sollte.

gruss
  andre

ps: noch ein ganz anderer ansatz der zumindest erst mal das symptom behebt ist das intervall des PRESENCE devices gross genug zu machen. als > als die 4 minuten. für eine abwesenheit erkennung ist das eventuell noch gut genug. für anwesenheit nicht.

[Steffen]

Hallo!

Bis jetzt sieht es wirklich sehr gut aus mit dieser config:

Code Auswählen Erweitern

sudo stdbuf -oL -eL hcitool lescan --duplicates
Endlich ...ich teste es gerade auch auf meinem Cubi und auch da bis jetzt alles wie es sein soll!
Ich werde es die Nacht noch beobachten aber hoffe das es endlich ein Ende der Geschichte ist.

Vielen dank nochmal an alle für eure Geduld und eure Hilfe!

Mfg Steffen

[gero]

warum du das mit deinem | grep beispiel nachstellen kannst verstehe ich auch noch nicht. das kann ich hier nämlich nicht. versuch mal das folgende in ein test.sh script zu stecken

Code Auswählen Erweitern

echo 1;
sleep 1;
echo 2;
sleep 1;
echo 1;
sleep 1;
echo 2;
und dann mit

Code Auswählen Erweitern

sh test.sh | grep 1aufzurufen. du solltest die zeilen mit der 1 jeweils sofort sehen so wie es bei line buffered sein sollte.

Hier ersteinmal die offizielle Seite zur libc, die das Verhalten bestätigt:
http://www.gnu.org/software/libc/manual/html_node/Buffering-Concepts.html

Ein Sleep scheint eine ähnliche Wirkung wie ein flush zu haben. Dazu habe ich noch keine genaue Erklärung gefunden.

Wenn du aber einen Prozess nimmst, der ein blocking read auf ein Device ausführt, kannst du das Verhalten bei dir bestimmt auch nachstellen.
Z.B.

Code Auswählen Erweitern

od /dev/random | grep .
(Maus bewegen nicht vergessen)

Im Vergleich dazu:

Code Auswählen Erweitern

stdbuf -oL od /dev/random | grep .

@Steffen: Schön dass es jetzt funktioniert.

Gruß,
Gero

[lukasbastelpeter]

So, bei mir läuft es jetzt so lalala, eigentlich also ganz gut 

Das Problem ist, dass der hcitool lescan ein Prozess ist, und kein terminierter Befehl, richtig?
Wenn man diesen nun "unendlich" laufen lässt kann man nicht weiter auf das Bluetooth-Interface des Systems zugreifen, da Bluetooth seriell implementiert ist?
Wird nicht langfristig alles was nun irgendwie noch kein LE unterstützt LE unterstützen? Also alles was mit dem Presence-Modul überwacht wird? Handys, Laptops usw?! Von daher wäre eine Zukunftsorientierte Lösung PRO "Einfach laufen lassen" akzeptabel oder? Für alle anderen kann man doch eine Lösung finden mit einem weiteren USB-Stick o.Ä.?

[Steffen]

Hallo!

So wollte mich nochmal melden und mich bedanken für die Hilfe und eure Geduld .

Es läuft jetzt alles wie es soll und bis jetzt keine Probleme,
sogar mit meinem Kensington Bluetag klappt es jetzt super.

Das einzige was mir aufgefallen ist das bei einem restart von Fhem Presenced "disconect" bleibt,
aber damit kann ich leben!

Mfg Steffen

[gero]

So, bei mir läuft es jetzt so lalala, eigentlich also ganz gut 

Das Problem ist, dass der hcitool lescan ein Prozess ist, und kein terminierter Befehl, richtig?
Wenn man diesen nun "unendlich" laufen lässt kann man nicht weiter auf das Bluetooth-Interface des Systems zugreifen, da Bluetooth seriell implementiert ist?
Wird nicht langfristig alles was nun irgendwie noch kein LE unterstützt LE unterstützen? Also alles was mit dem Presence-Modul überwacht wird? Handys, Laptops usw?! Von daher wäre eine Zukunftsorientierte Lösung PRO "Einfach laufen lassen" akzeptabel oder? Für alle anderen kann man doch eine Lösung finden mit einem weiteren USB-Stick o.Ä.?

Nahezu alle Handys und Laptops unterstützen schon BLE. Aber sie haben keinen Grund zu advertisen wie ein Bluetooth Tag. Sie spielen eher die Central Rolle bei BLE. D.h. sie sind von der Software darauf ausgelegt, Bluetooth Tags aufzuspüren. Um sie z.B. für PRESENCED zu verwenden, benötigt man spezielle Programme oder Apps auf diesen Geräten und das wird auch voraussichtlich so bleiben.
Gruß,
Gero

[gero]

Das einzige was mir aufgefallen ist das bei einem restart von Fhem Presenced "disconect" bleibt,
aber damit kann ich leben!

Schön, dass es jetzt bei dir läuft!
Wie sieht deine Lösung aus, das System wieder zum Laufen zu bringen, falls bei einem Neustart Presenced auf disconnect bleibt? Startest du das komplette System neu?
Es wäre schon interessant die Ursache für das Problem zu finden. Führ mal im Fehlerfall ein hciconfig -a aus. Oder kontrollier, ob noch ein hcitool läuft. Ich tippe darauf, dass der Bluetooth Adapter im Zustand down ist.

Gruß,
Gero