Anwesenheitserkennung über Bluetooth

[2ndsky]

Hab mal unter Windows mit der 32feet.NET Lib getestet (hab noch kein Linux aufgesetzt), dann dauert eine Serviceabfrage etwa eine Sekunde im Schnitt und ein Connect sogar zwei Sekunden. Der Connect müsste dann aber auf jeden Fall sicher sein, jedoch sind mir zwei Sekunden zu lang. Ich will an der Tür nen Taster/Katzenklingel betätigen und die Tür soll aufgehen. Müsste mit l2ping schneller gehen, aber ist das dann sicherer als rssi? Das Akku Problem wäre mir dann sogar egal, weil ich den Ping nur bei Tasterbetätigung ausführe.

[makki]

@Niko: nun, wenn ich es perfekt&fertig hätte, würde ich es machen&sagen - wirklich

Es gibt da halt noch ein paar Details, ich versuchte nur die Punkte hervorzuheben die IMHO noch "spannend" werden könnten..
Mit blueprox & RSSI hab ich eben nochmal nachgeschaut, sorry, stimmte nicht: das macht auch ne connection und frägt dann die RSSI ab. Soweit ich das beurteilen kann: security ok: haken dran!
aber ja, es dauert etwas, das stimmt, ich habe mir 1-2sek notiert (meine letzten versuche sind monate her..)
-> ist IMHO ok, der class1-stick sieht Dich ja lange vor der Haustür, 2sek delay wäre insgesamt IMHO schon fast traumhaft. Ich stehe oft 5 sek. auf der Trittmatte (=mein taster) bis die sch*** Tür endlich aufgeht

Die Krux mit der Connection ist: ist sie offen lutscht sie den Akku leer, also müsste man einen Mittelweg finden: Mac in Reichweite->Connection->RSSI aber dann in Ruhe lassen solange sie nicht verschwindet reichte ein l2ping o.ä.
Ich hab das blueproximity schonmal in dumm soweit abgespeckt das es ohne GUI läuft und das Webif 30% (WG-typisch halt "leider" Webmin), schick mir deine email per PN/eMail, dann gibts halbgaren code

Makki

[2ndsky]

@Niko: nun, wenn ich es perfekt&fertig hätte, würde ich es machen&sagen - wirklich

Es gibt da halt noch ein paar Details, ich versuchte nur die Punkte hervorzuheben die IMHO noch "spannend" werden könnten..

Ich wollte damit auch nur sagen, dass man an den Problemen ja gemeinsam knobbeln könnte. Oft reicht es auch schon aus, seine Probleme zu formulieren

Mit blueprox & RSSI hab ich eben nochmal nachgeschaut, sorry, stimmte nicht: das macht auch ne connection und frägt dann die RSSI ab. Soweit ich das beurteilen kann: security ok: haken dran!
aber ja, es dauert etwas, das stimmt, ich habe mir 1-2sek notiert (meine letzten versuche sind monate her..)
-> ist IMHO ok, der class1-stick sieht Dich ja lange vor der Haustür, 2sek delay wäre insgesamt IMHO schon fast traumhaft. Ich stehe oft 5 sek. auf der Trittmatte (=mein taster) bis die sch*** Tür endlich aufgeht

okay, dann sind 2 sek. natürlich besser als 5
Aber in dem Fall kann ich meine erste Idee, das BT Phone nur abzufragen wenn man auf einen Schalter drückt, vergessen. Hätte halt beträchtliche Vorteile für den Akku gehabt.

Die Krux mit der Connection ist: ist sie offen lutscht sie den Akku leer, also müsste man einen Mittelweg finden: Mac in Reichweite->Connection->RSSI aber dann in Ruhe lassen solange sie nicht verschwindet reichte ein l2ping o.ä.

Jetzt wo du es sagst fällt es mir wie Schuppen von den Haaren... jede FSE im Auto (zumindest in meinem) macht es ja nach dem Prinzip: das Handy wird gesucht und wenn in der Nähe wird eine Verbindung aufgebaut. Diese bleibt während der Fahrt immer bestehen. Dennoch merkt man das am Akku nicht. Also müsste man nur jede Sekunde prüfen, ob das Handy in der Nähe ist (stellt für den Akku ja kein Problem dar wenn es nicht in der Nähe ist) und wenn in Reichweite dann eine Verbindung aufbauen. Anschließend muss man nur den Verbindungsabbruch sauber abfangen. Idealerweise müsste der BT Stack Events für in Range und Disconnect senden. Von der Microsoft API weiß ich, dass sie solche Events auf Win CE Geräten schickt, jedoch nicht auf Win 32
Beim kurzen überfliegen des BlueZ Codes meine ich aber zumindest eine Art Disconnect Event gesehen zu haben. Würde hier eigentlich schon reichen und die Überprüfung ob das Handy in Reichweite wenn es nicht in Reichweite ist dann halt jede Sekunde. Für die Anwesenheitsgeschichte wäre es dann klasse, wenn man eine Bluetoothverbindung über mehrere BT Sticks weiterreichen könnte, dann wäre auch die Überprüfung der Anwesenheit kein Problem und anhand der RSSI der jeweiligen Empfänger könnte der Standort errechnet werden (ähnlich wie beim Mobilfunk).

Ich hab das blueproximity schonmal in dumm soweit abgespeckt das es ohne GUI läuft und das Webif 30% (WG-typisch halt "leider" Webmin), schick mir deine email per PN/eMail, dann gibts halbgaren code

Hab dir ne PN geschickt. Jedoch hab ich noch keine Linux Kiste hier. Da evtl. eh ein Wiregate her soll die Frage, kann ich das einfach an ne Steckdose und LAN hängen und mit dem Testen beginnen oder wäre hierfür weitere Dinge notwendig? Und welchen BT Stick brauche ich fürs Wiregate?

EDIT: Vergiss den letzten Teil, ich hab mir jetzt einfach mal n Wiregate rausgelassen und nach anfänglichen Schwierigkeiten auch gesehen das es im Shop nen Bluetooth Stick gibt.

[henfri]

Skypt doch mal miteinander.
So wie es sich anhört, ist 2ndsky doch sehr aktiv und scheint auch das nötige Wissen zu haben.

Gruß,
Hendrik

[2ndsky]

Skypt doch mal miteinander.
So wie es sich anhört, ist 2ndsky doch sehr aktiv und scheint auch das nötige Wissen zu haben.

Wenn alles klappt müssten wir auf dem Münchner Stammtisch fachsimpeln können... außerdem muss ich mich zunächst nochmal ein wenig in Linux und Python einarbeiten. Hab es jetzt am Wochenende mit makki's Code (Danke dafür) zum Laufen gebracht und verstehe den Code auch, allerdings muss ich noch ein wenig rumprobieren um Erweiterungen daran vornehmen zu können.

Jedoch denke ich einen theoretisch guten Ansatz zumindest für das Keyless In gefunden zu haben, nur ob das auch in der Praxis funktioniert wird sich zeigen. Makki's Code ist ja von blueproximity abgeleitet. Blueproximity baut sekündlich ne Verbindung zum Handy auf und feuert eine RSSI Anfrage. Danach wird die Verbindung gleich wieder getrennt. Wenn die Verbindung nicht besteht lässt sich auch die RSSI nicht abfragen. Wenn man nun nen Daemon hätte, der sekündlich versucht eine Verbindung zu einem konfigurierten Gerät (in mehreren Threads natürlich auch mehrere Geräte möglich) aufzubauen und diese Verbindung dann einfach offen hält müsste es möglich sein die RSSI abzufragen. Somit könnte man bei einem Druck auf einen Taster vor der Tür/Tritt auf Katzenklingel die RSSI abfragen und wenn die Entfernung unter einer bestimmten Schwelle ist, geht die Tür auf.

Der Vorteil daran, eine offene Verbindung braucht kaum Strom und die Abfrage der RSSI ist super schnell, da die Verbindung nicht mehr extra geöffnet werden muss.

Für die Anwesenheitserkennung bräuchte man eine Daemon je HCI Device (also je USB Stick). Laut Spezifikation müssten mehrere BT Verbindungen gleichzeitig möglich sein, daher versuchen alle Sticks sich auf ein Handy zu verbinden. Die Abfrage der RSSI könnte dann in längeren Zeitabständen automatisch passieren. Sekündlich ist hier IMHO nicht notwendig, soll ja nicht dazu verwendet werden Licht zu schalten, dafür gibts PMs.

Da diese Woche bei mir relativ voll ist werd ich wohl nicht viele Erfolge verzeichnen können, aber da ich sonst derzeit nichts zum "Spielen" habe, ist das auf höchster Prio derzeit.

[makki]

Kannst mich auch gerne mal anrufen, mehr wie das es gerade nicht passt oder mir meine humanoide Firewall danach ein eMail schreibt, kann nicht passieren
(ja, ich hätte es wirklich auch gerne endlich gescheit!! dem Author würde ich mein jetziges Bluetooth-Kasterl gerne schenken aber der will es ja garnicht, weil er dann ja was gescheites hat )

Ein Py-Thread pro Gerät sollte gut passen, hardcore-pollen ist IMHO notwendig (auf events zu warten ist jahrhunderte zu langsam).. Ist schon der richtige Weg..
(Py-Threading da wurde kürzlich nicht ganz zu unrecht als Taschenspielertrick gemarkt) stimmt auch - funktioniert im Gegensatz zu den Gaunereien von Perl etc aber halt absolut zufriedenstellend. Soweit zumindest meine geringe Erfahrung..
Klar ist p(osix)thread oder pth(sem) nochmal ne andere Liga, Männertechnik - aber eben auch kein Quickhack-script.. (wiegesagt, wenn Zeit&Know-How endlos wären würde ich aus bluez/hcitool einen C-deamon ableiten aber.. wäre in Py schon sicherlich cool genug) Wegen mir auch in Cobol (das "durfte" ich auch mal lernen, ok, war ein Scherz) - Hauptsache es lüppt..

Wenn das ganze irgendwie unter einer (L)GPL landet bin ich jedenfalls - wo ich kann unterstützend dabei - 5 Testhandys warten auf meinem Schreibtisch seit ewig; mir fehlt nur die Zeit und die echte Prio dafür..

Makki

[2ndsky]

Kannst mich auch gerne mal anrufen, mehr wie das es gerade nicht passt oder mir meine humanoide Firewall danach ein eMail schreibt, kann nicht passieren
(ja, ich hätte es wirklich auch gerne endlich gescheit!! dem Author würde ich mein jetziges Bluetooth-Kasterl gerne schenken aber der will es ja garnicht, weil er dann ja was gescheites hat )

wie gesagt, hab jetzt erstmal so weit, das es prinzipiell mal mein iPhone überhaupt erkennt. War auch ein kleiner Kampf, Gott sei Dank war meine bessere Hälfte mit DSDS beschäftigt, daher hatte ich etwas Zeit
Denke werde am Wochenende oder Anfang nächster Woche die Zeit finden, meine Theorie mal zu testen. Danach können wir uns schon mal telefonisch austauschen, aber bevor ich mich nicht noch etwas eingearbeitet habe macht das IMHO keinen Sinn.

Ein Py-Thread pro Gerät sollte gut passen, hardcore-pollen ist IMHO notwendig (auf events zu warten ist jahrhunderte zu langsam).. Ist schon der richtige Weg..
(Py-Threading da wurde kürzlich nicht ganz zu unrecht als Taschenspielertrick gemarkt) stimmt auch - funktioniert im Gegensatz zu den Gaunereien von Perl etc aber halt absolut zufriedenstellend. Soweit zumindest meine geringe Erfahrung..
Klar ist p(osix)thread oder pth(sem) nochmal ne andere Liga, Männertechnik - aber eben auch kein Quickhack-script.. (wiegesagt, wenn Zeit&Know-How endlos wären würde ich aus bluez/hcitool einen C-deamon ableiten aber.. wäre in Py schon sicherlich cool genug) Wegen mir auch in Cobol (das "durfte" ich auch mal lernen, ok, war ein Scherz) - Hauptsache es lüppt..

Denke das würde so schon passen. Arbeite lieber in Hochsprachen bevor ich mir das alloc Zeugs in C antue... So kann man sich wenigstens um das wesentliche kümmern
Außerdem muss man so kein Bugs fixen die derzeit irgendwo tief im BlueZ Code verborgen liegen (die man dann brav mit kopiert), da sollen sich die Jungs und Mädels von BlueZ drum kümmern.

Wenn das ganze irgendwie unter einer (L)GPL landet bin ich jedenfalls - wo ich kann unterstützend dabei - 5 Testhandys warten auf meinem Schreibtisch seit ewig; mir fehlt nur die Zeit und die echte Prio dafür..

bei (L)GPL sehe ich keine Problem, das bekommen wir hin

[2ndsky]

also, möchte mal nen aktuellen Stand abgeben. Hab gestern wieder ein wenig getestet, komm aber noch nicht wirklich auf nen grünen Zweig.

Mit

hcitool cc <btaddr>

kann ich mich garnicht verbinden, es kommt auch keine Fehlermeldung. Wenn ich mit

rfcomm connect <btaddr>

die Verbindung aufbaue, kann ich in ner zweiten Session wenigstens ein

hcitool rssi <btaddr>

ausführen, ansonsten kommt das keine Verbindung besteht. In dem blueproximity Code wird ebenfalls ein RFCOMM Socket geöffnet, anders als beim Befehl in der Console bleibt dabei die Verbindung aber nur für wenige Sekunden geöffnet, gerade so lange um ein hcitool rssi auszuführen. Wenn ich versuche org.bluez.rfcomm über den DBus zu holen und mich damit zu connecten kommt eine Meldung, dass das Interface keine Methode connect besitzt. Laut Recherche im Internet muss man hcid mit -x starten, da die Funktionen wohl nur im experimental Mode funktionieren. Leider konnte ich keinen hcid finden und nen experimental Mode finde ich für ein System, das später produktiv laufen soll eh nicht so prickelnd.

Ein einfacher Workaround wäre natürlich einen Daemon zu schreiben, der rfcomm connect aufruft. Da dieser Aufruf erst zurückkehrt, wenn die Verbindung wieder unterbrochen wurde bzw. wenn sie gar nicht zu stande kommt müsste der Daemon nach dem Befehl nur direkt versuchen, diesen wieder auszuführen. Nur irgendwie bin ich damit nicht wirklich glücklich.

Mich nervt ein wenig, das der Ablaufplan für das ganze total simple ist, mir jedoch an einigen Stellen noch das Wissen fehlt um das ganze umzusetzen bzw. Sachen die eigentlich laufen müssen nicht gehen (was in der SW Entwicklung irgendwie ständig der Fall ist).

Soweit mal zum aktuellen Stand, evtl. komm ich heut Nachmittag nochmal zum Testen, mal sehen.

[makki]

Wiegesagt, wenn ich die finale AW hätte, würde ich sie preisgeben
rfcomm hat den Vorteil, das es wirklich fast alle Handys auch können, also der Weg ist IMHO der richtige. Aber es gibt leider ne Menge Stolpersteine..
->irgendeine Verbindung muss man aufbauen, sonst gibts a) keine security und b) keine RSSI

Was Dich nervt kann ich gut nachvollziehen, es ist sicher machbar aber leider nicht ganz "easy". Als Hinweis: das mit dem DBus+bluez geht so ab Stand Ubuntu 10.10 wenigstens halbwegs, Backports der packerl für andere Debians mach ich ggfs. gerne, da hab ich übung

Makki

[2ndsky]

Sodele, bin wieder etwas weiter gekommen. Jetzt hab ich langsam auch verstanden, das viele Bluetooth Tutorials mit Bluez4 nicht kompatibel sind, da ab Version 4 vieles über DBus gemacht wird.

Habs gestern mal Quick and Dirty versucht und einfach n Python Progrämmchen geschrieben, das mittels psopen und rfcomm connect eine Verbindung zum Handy aufbaut. Da der Aufruf erst zurückkehrt, wenn die Verbindung wieder beendet wurde, rufe ich das einfach in ner Endlosschleife auf, also sobald die Verbindung (warum auch immer) wieder beendet wurde versucht das Script sofort wieder eine Verbindung aufzubauen. In ner anderen Session habe ich dann mittels hcitool rssi die Entfernung manuell abgefragt. Funktioniert hat das zunächst ganz passabel, jedoch zeigten erste Tests, dass die Entfernungsberechnung zu träge ist. Also sprich, wenn ich zum Wiregate hinlaufe habe ich sobald ich dort ankomme eine RSSI von -16 welche sekündlich geringer wird. Es dauert aber gut 10 Sekunden bis diese auf 0 ist. Dieses Verhalten ist IMHO nicht tragbar, da ich entweder die Entfernung zu groß einstellen muss, was die Tür bei uns auch öffnen würde wenn ich in der Küche stehe oder ich ewig vor der Tür warten muss, bis festgestellt wird, dass ich direkt davor stehe. Jedoch funkt mein blöder WLAN AP auf'm Schreibtisch auch ständig dazwischen. Werde das Verhalten mal noch versuchen auf "freiem Feld" zu testen, ob es dann besser wird.

Problematischer bewerte ich da schon die Zuverlässigkeit der Geschichte, weil sich gestern ebenso wie vorgestern Abend irgendwann der Bluetooth Stick oder der Stack verabschiedet und keine Verbindung mehr aufbauen möchte, egal zu welchem Gerät. Es kommt dann immer nur "host is down". Neues Pairing geht ebensowenig wie ein Inquiry oder ein einfacher scan. Nichtmal andere BT Devices werden noch angezeigt. Auch ein restart des bluetoothd bringen dann zunächst nichts. Bin mir auch nicht mehr sicher was ich gestern getan habe, das es dann plötzlich wieder funktioniert hat. Also noch sehr seltsam.

Zusätzlich ein Problem bei der RFCOMM Geschichte ist die Auswahl des richtigen Ports. Hab mal mit dem sdptool die Services des iPhones angesehen. Bei mir ist Kanal 1 für WLAN iAP, Kanal 8 für Handsfree und Kanal 13 für Phonebook belegt. Verbindungen auf Kanal 13 werden aber innerhalb von 10 sek. vom iPhone beendet, ebenso wie die auf Kanal 1. Nur Kanal 8 bleibt länger offen. Wenn man das weiß ist es zwar prinzipiell kein Problem, jedoch für die einfache Einrichtung eines Devices durch einen Ottonormalverbraucher schon ein KO Kriterium.

Werde das ganze heute mal noch mit direkten Verbindungen auf einen Service testen, vielleicht wird die Verbindung dann auch zuverlässiger. Mal sehen.

[2ndsky]

Ein weiterer Testtag später konnte ich das Problem etwas eingrenzen. Nun weiß ich zumindest, wie ich es wieder ans Laufen bekomme wenn sich der Stick aufhängt. Befehle wie hcitool scan zeigen zwar noch deutliche Aktivität der LED des Sticks, jedoch wird nichts mehr gefunden. Dann hilft es nur noch den Stick abzuziehen und neu einzustecken und alles läuft wieder. Da sich das Ding nun aber bereits fünf mal in unregelmäßigen Zeitabständen aufhängt bin ich etwas ratlos.

Heute Morgen hing er auch wieder, hatte die ganze Nacht das Python Script von dir (makki) laufen. Stick aus und wieder eingesteckt, siehe da, die Verbindung lüpt wieder und dir RSSI wird richtig angezeigt. Anschließend mit dem iPhone während das Script lief Internet Radio gehört. WLAN AP und BT Stick sind 50 cm voneinander entfernt (bin mir nicht sicher ob das ne Rolle spielt). So nach 2 min. fängt der AP an zu blinken, weil er keine WLAN Verbindung zum WLAN Router in der Garage bekommt (ist als Repeater konfiguriert). Zu der Zeit ist auch der Stick wieder ausgestiegen. Denn jedes mal wenn der Stick sich aufhängt, fängt die LED dauerhaft an zu leuchten, genau wie beim Scannen nach Devices. Außerdem schafft das Python Script nur noch alle 7 Sekunden eine Abfrage und nicht mehr jede Sekunde. Bei einem Scan mit hcitool scan bricht mir auch regelmäßig die WLAN Verbindung ab. Alles sehr strange. Jedenfalls das üblich aus und einsteckprozedere durchgeführt, doch diesmal nahm der Stick seine Arbeit nicht gleich wieder auf. Erst ein restart des bluetoothd hat schlussendlich geholfen.

Ich hab dir einen Auszug aus dem syslog mal angehängt, vielleicht kannst du was damit anfangen. Der Auszug beginn mit dem ersten Aus- und wieder Einstecken des Sticks. Dann läuft alles normal bis 6:49Uhr wo sich der Daemon aufgehängt hat. Anschließend zweimal das Abziehen des Sticks ohne das der Daemon das HCI Device hochfährt. Erst beim Neustart des Daemon klappt wieder alles. Weiß langsam nicht mehr, ob der Stick n Schuss hat oder an was das liegen kann.

[2ndsky]

Nochmal ich... heute Nachmittag hat mich meine bessere Hälfte verzweifelt im Büro angerufen, sie kommt nicht ins Internet. Ich ihr erklärt wo sich der BT Stick befindet und das sie den abziehen soll, danach gings wieder. Wieder selbes Problem: Stick hängt sich auf und blockiert beim scannen das WLAN. Der WAF ist gerade sehr im Keller und es war noch nicht mal Baubeginn
Was meinst du, mal anderen Stick testen? Welcher sollte da gut sein? Weil das Wiregate ist ja so ziemlich in Auslieferzustand, da ich sonst noch keine Hardware etc. habe.

[henfri]

Hi,

ich hab noch einen Conceptronics Stick.
Kann ich dir gerne ausleihen. Und wenn du eine funktionierende Lösung erschaffst, darfst du ihn dafür behalten ;-)
(was blöd ist, denn dann bräuchte ich ihn. Aber Belohnung muss sein)

Gruß,
Hendrik

[callidomus]

WLAN AP und BT Stick sind 50 cm voneinander entfernt (bin mir nicht sicher ob das ne Rolle spielt).

Ja, die können sich stören. Google mal.

Hth

Marcus

[2ndsky]

ich hab noch einen Conceptronics Stick.
Kann ich dir gerne ausleihen. Und wenn du eine funktionierende Lösung erschaffst, darfst du ihn dafür behalten ;-)

Hallo Hendrik, komme gerne auf das Angebot zurück. Ich schick dir Morgen mal ne PN. Würds nur gerne mal Testen, wenn es mit deinem Stick zuverlässig funktionieren sollte bekommst du ihn natürlich wieder.

Ja, die können sich stören. Google mal.

Hallo Marcus, das die sich generell beeinflussen ist mir schon klar... doch darf das nie zu einem kompletten Ausfall führen. Wie gesagt, es hilft nur den BT Stick ab zu ziehen und nach kurzer Wartezeit wieder einzustecken. Auch wenn ich den AP vom Netz nehme bekommt es der Stick nicht mehr geregelt. Das darf nicht sein. Mein iPhone schafft es ja auch, bei mir im Auto eine GSM Telefonat aufzubauen, das ich per BT FSE führe während es gleichzeitig als Wifi AP die UMTS Verbindung meiner Freundin zur Verfügung stellt, die keinen Datenvertrag hat... es wird zwar warm dabei, aber es hängt sich nicht auf.