Anwesenheitserkennung über Bluetooth

[makki]

Wiegesagt, alles nur Sicherheitsfragen.. Ich lass das (den unfertigen blueproximity-hack von mir) jetzt hier einfach mal live durchlaufen..

Makki

P.S.: Am Ende des Tages ist es fast alles SW bis zu dem was der Kernel-Treiber in den BT-Stick schiebt

[2ndsky]

- schick mir doch einfach mal was Du gerade hast (hardcoded oderwas auch immer egal, find ich schon), das Thema kann ich parallel mal antesten.

Naja, nachdem meine Python Skripte immer hängen geblieben sind habe ich es mal für längere Zeit mit dem Code von dir versucht. Also wenn das bei dir 24/7 läuft, dann kann es nicht daran liegen.

- Sicherheitsfrage: WG mit Kernel 2.6.32 ? (der Nummer nach sicher ja, aber ich muss fragen, in den BT-Treibern hat sich einiges getan und wenns irgendwas anderes ist verändert sich die Fragestellung drastisch)

Laut Webmin: Linux 2.6.32-wiregate-1.31 on i586

Wichtigste Frage: USB-Hub dran ? Welchen? Netzteil an diesem? Dem 1-Wire gehts 100% gut?

Kein HUB und auch kein 1-Wire. Falls du damit aber das Wiregate meinst, dem müsste es gut gehen, hab bisher nichts damit gemacht, außer deinen Code drauf kopiert und meine Testskripte.

So wie ich das lese, fliegt da - warum auch immer - der ganze USB ab, das sollte zwar nicht dazu führen das der BT-Stick das Wlan lahmlegt aber es ist eben nur Technik

Also der Stick ist im System mit lsusb noch zu sehen. Solange kein Befehl ausgeführt wird, verhält er sich auch normal (regelmäßiges kurzes blinken). Nur kann keine Verbindung mehr zu egal welchem Gerät aufgebaut werden. hcitool scan zeigt keine Devices mehr an, obwohl es sonst drei Stück findet. Dadurch dauert auch der Connect Versuch in deinem Code 7 Sekunden ohne das er was findet. Und genau bei diesen Versuchen scheint der Stick auf maximale Leistung zu gehen und legt somit das WLAN lahm.

Übrigens, umgekehrt gelingt es mir 100% zuverlässig mit einem 40MHz N-Wlan auf anschlag die BT-Maus nahezu lahmzulegen aber ansonsten geht das eigentlich ganz fein parallel. (aber, richtig, es nutzt dieselben, knappen Mhz)

Das Phänomen kenne ich auch, aber nur während des Transfers, also solange das Netz belastet wird. Sobald wieder Ruhe im WLAN einkehrt geht auch die Maus wieder. Hier hängt sich der Stick komplett auf und reagiert gar nicht mehr, auch nicht wenn ich das WLAN wegnehme.

Danke das du dich des Problems annimmst, weiß echt nicht mehr weiter... Habe ich schon erwähnt das ich als Softwareentwickler Hardware hasse, die ist unberechnebar

[makki]

Zur Stabilität (ich denke du hast denselben Class 1 Stick wie ich hier, den es übrigens leider nur noch in Restbeständen gibt, ich evaluiere gerade einen Ersatz):
-> dem nehme ich mich gerne an, darf nicht sein..
- hab ich hier 0,0, weder beim testen noch 24x7 seit Monaten (ich frage zwar nur meinen Roomba darüber ab aber das ist auch RFCOMM auf, RSSI, zumachen etc.
- schick mir doch einfach mal was Du gerade hast (hardcoded oderwas auch immer egal, find ich schon), das Thema kann ich parallel mal antesten.
- Sicherheitsfrage: WG mit Kernel 2.6.32 ? (der Nummer nach sicher ja, aber ich muss fragen, in den BT-Treibern hat sich einiges getan und wenns irgendwas anderes ist verändert sich die Fragestellung drastisch)

Wichtigste Frage: USB-Hub dran ? Welchen? Netzteil an diesem? Dem 1-Wire gehts 100% gut?
So wie ich das lese, fliegt da - warum auch immer - der ganze USB ab, das sollte zwar nicht dazu führen das der BT-Stick das Wlan lahmlegt aber es ist eben nur Technik

Übrigens, umgekehrt gelingt es mir 100% zuverlässig mit einem 40MHz N-Wlan auf anschlag die BT-Maus nahezu lahmzulegen aber ansonsten geht das eigentlich ganz fein parallel. (aber, richtig, es nutzt dieselben, knappen Mhz)

Makki

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

[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

[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

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

[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]

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.

[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]

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.

[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

[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]

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.

[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