Anwesenheitserkennung Bluetooth PebbleBee

[PatrickR]

Hey Steffen!

Was sagt denn
grep blescan.pl /var/log/syslog

Patrick

[Steffen]

Hey Steffen!

Was sagt denn
grep blescan.pl /var/log/syslog

Patrick

Habe es mal in eine Text Datei geschrieben und wegen der Größe in zip datei wenn ok?!

Mfg Steffen

[PatrickR]

Hi!

Uff, das ist ja richtig Lesestoff.

Eine Info vorweg:
Es kann immer nur ein Scan gleichzeitig laufen. Daher war das mit den 3 G-Tags, 60 Sekunden Scanzeit und ca. 2 Minuten Scanintervall am Anfang etwas ungünstig.

Zum Hauptproblem mal exemplarisch ein Durchlauf:

Code Auswählen Erweitern


May  3 13:20:33 localhost blescan.pl[11024]: Version 0.4 started (mac address: 7C:2F:80:8F:9B:F7, duration: 10).
May  3 13:20:33 localhost blescan.pl[11024]: Acquired lock, Scanning...
May  3 13:20:33 localhost blescan.pl[11024]: Received 'Set scan parameters failed: Input/output error', resetting...
(Noch 89x 'Set scan parameters failed.)
May  3 13:20:51 localhost blescan.pl[11024]: Received 'Set scan parameters failed: Input/output error', resetting...
May  3 13:21:01 localhost blescan.pl[11024]: hcitool exited before scanning for bluetooth mac address '7C:2F:80:8F:9B:F7'.


Wenn man sich das mal anschaut hast Du 522 Aufrufe, die zu dem o. g. Fehler führen. Der Reset war scheinbar nur in zwei Fällen (pid 3100, 3120) erfolgreich.

Hast Du parallel auch per Hand resettet oder was anderes getan (bluetooth restartet, Dongle gezogen usw.)?
Ist hci0 Dein Bluetooth-Device?

Patrick

[Steffen]

Hallo!

Erstmal ein danke für deine mühe und geduld bei der Hilfe...

Ja ich hatte zwischen durch mal neu gestartet aber dann den ganzen Cubi und danach kam das gleiche ergebniss!

Welche Einstellungen zum Scanintervall und Scanzeit würdest du bei 3 G-tag empfehlen?

Mfg Steffen

[PatrickR]

Hi!

Habe bei 3 G-Tags aktuell 15s Scanintervall und 60s/60s Intervall in FHEM.

Hast Du mal geschaut, ob hci0 Dein Bluetooth-Device ist? Falls nein könnte das erklären, warum bei Dir das Resetten so rein garnichts bringt.

Patrick

[v.i.p.e.r]

mal ein Update vo mir:
Pi2 mit Logiink -> getauscht auf Asus BT-400

Es passiert genau das gleiche - egal ob bluetoothd läuft oder nicht, egal ob am Hub oder nicht. Langsam glaube ich, das es einfach am Pi und seinem "kernel" liegt.
Ärgert mich, dass ich da nicht weiter komme.

eventuell könnte jemand ohne pi mal den Output seiner Datei /etc/bluetooth/main.conf posten?

Code Auswählen Erweitern

grep -v "^#" /etc/bluetooth/main.conf

VG
Tim

[gero]

Falls es am Kernel liegt, könnte man noch die verschiedenen USB Kernelmodule ehci, ohci, uhci oder xhci durchprobieren. Ich habe gerade keinen Raspi am Laufen und kann daher nicht genau sagen, was im aktuellen Kernel verfügbar ist. (Achtung: Der Ethernetcontroller hängt mit am USB. D.h. wenn man nicht weiß, was man tut, sperrt man sich leicht aus.)

Interessant wäre natürlich auch ein Bluetooth- und USB-Sniff.

Ansonsten gibt es auch bei den ROM Varianten der CSR-Chips die Möglichkeit Patches per Pskeys einzuspielen. Dazu benötigt man aber die exakte Chip-Revision und einen guten Kontakt zum CSR-Support, um die passenden Patches zu erhalten.
Ich bin mir ziemlich sicher, dass CSR der Fehler bekannt ist.

Gruß,
Gero

[PatrickR]

eventuell könnte jemand ohne pi mal den Output seiner Datei /etc/bluetooth/main.conf posten?

Code Auswählen Erweitern

grep -v "^#" /etc/bluetooth/main.conf

Code Auswählen Erweitern


# uname -a
Linux laforge 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux
# grep -v "^#" /etc/bluetooth/main.conf|grep -v '^$'
[General]
Name = %h-%d
Class = 0x000100
DiscoverableTimeout = 0
PairableTimeout = 0
PageTimeout = 8192
DiscoverSchedulerInterval = 30
AutoConnectTimeout = 60
InitiallyPowered = true
RememberPowered = true
ReverseServiceDiscovery = true
NameResolving = true
DebugKeys = false
AttributeServer = false


Patrick

[Atze]

Ich hab jetzt mehrere Dongles ausprobiert. Auch unterschiedliche Hub's. Keine besserung. mal nach 5 min. ein reset, mal nach einer Stunde.
Aber immer nach spätestens 20 Stunden ist das System tot und nichts geht mehr.
Habe 2 gdata mit 60 60 60 versucht. Lasse jetzt über nacht mal einen mit 15 60 60 laufen.

Linux raspi 3.18.11-v7+ #777 SMP PREEMPT Sat Apr 11 17:30:37 BST 2015 armv7l GNU/Linux
root@raspi:/home/pi# grep -v "^#" /etc/bluetooth/main.conf
[General]
Name = %h-%d
Class = 0x000100
DiscoverableTimeout = 0
PairableTimeout = 0
PageTimeout = 8192
DiscoverSchedulerInterval = 30
AutoConnectTimeout = 60
InitiallyPowered = true
RememberPowered = true
ReverseServiceDiscovery = true
NameResolving = true
DebugKeys = false
AttributeServer = false


syslog: im anhang

[PatrickR]

@Atze:
Sieht aber so aus als würden bei Dir die Resets durchaus funktionieren. Wenn die Resets dauerhaft erfolglos sind kommt

Code Auswählen Erweitern


hcitool exited before scanning for bluetooth mac address

nicht aber

Code Auswählen Erweitern


Did NOT receive an advertisement from bluetooth mac address


Wenn ich was übersehen habe bitte kurze Info mit Zeitstempel.

/Edit:
Was mir gerade auffällt ist das Problem mit der 60/60/60-Einstellung. Du hast 39148(!) Einträge mit "blescan.pl is already running..." im Log, die nach der Umstellung auf 15/60/60 fast vollständig weg sind.

Patrick

[Atze]

Moin,
so nach ca. 6 Stunden mit einem Gdata 15 60 60 ... ist FHEM wieder tot. Kein schalten mehr möglich. "Affengriff" auf der Tastatur ist aber diesmal noch möglich.
Meistens sind alle USB Geräte blockiert. 

[PatrickR]

@Atze:
Ok, ich hatte wohl "System tot" falsch interpretiert. Also der RPi steht. Hast Du mal versucht einzugrenzen, wo das Problem ist? Also hängt FHEM oder das Betriebssystem (funktioniert ssh noch)? Was steht denn vor dem Reboot im Syslog?

Patrick

[gero]

Probiert mal

Code Auswählen Erweitern

dwc_otg.speed=1  dwc_otg.lpm_enable=0

in die /boot/cmdline.txt mit aufzunehmen.

Gruß,
Gero

[v.i.p.e.r]

Danke PatrickR und gero

Ich habe heute mal ein neues PI2 mit Wheezy installiert und auf Jessie geupdatet. Danach FHEM installiert und Bluetooth soweit installiert.(Logilink Dongle) Läuft seit mehreren Stunden ohne aufhängen des Bluetooth Geräts - sprich keine logeinträge mit resetting.

Mein Produktives Pi läuft mit dem Asus Stick auch seit mehreren Stunden aktiv - allerdings wird hier der Stick alle 3-5 Minuten resetet - das schein da nun auch richtig zu klappen. Nur ist mir das ehrlich gesagt zu oft.

Es scheint also tatsächlich mit dem "alten" Wheezy zu tun zu haben. Jetzt müsste man nur noch raus finden was sich geändert hat und eventuell kann man dann aus backports die benötigten Sachen in sein Wheezy nachinstallieren.

Probiert mal

Code Auswählen Erweitern

dwc_otg.speed=1  dwc_otg.lpm_enable=0

in die /boot/cmdline.txt mit aufzunehmen.

Gruß,
Gero

Damit sollte man aber aufpassen oder? Kann sein, dass dan WLAN, LAN und andere Sachen am USB nicht mehr richtig klappen oder?

[gero]

Es scheint also tatsächlich mit dem "alten" Wheezy zu tun zu haben. Jetzt müsste man nur noch raus finden was sich geändert hat und eventuell kann man dann aus backports die benötigten Sachen in sein Wheezy nachinstallieren.

Nun, an dem Verhalten von hcitool sind nicht soviele Komponenten beteiligt: Da bleibt nur der Kernel und die Kernelmodule und das hcitool und dessen Abhängigkeiten in Bluez selbst.

Code Auswählen Erweitern

dwc_otg.speed=1  dwc_otg.lpm_enable=0
Damit sollte man aber aufpassen oder? Kann sein, dass dan WLAN, LAN und andere Sachen am USB nicht mehr richtig klappen oder?

Code Auswählen Erweitern

dwc_otg.speed=1
beschränkt die USB Geschwindigkeit auf 12Mbit

Code Auswählen Erweitern

dwc_otg.lpm_enable=0
schalten das LPM (Link Power Management) vom USB ab.

Den zweiten Punkt wirst du vermutlich kaum merken. Und wieviel Geschwindigkeit du bei der USB-Übertragung brauchst, ist die Frage.
Aber um das Problem einzugrenzen ist es ein wichtiger Schritt. Falls dieser Schritt erfolgreich ist, kann man evtl. über das sysfs die einzelnen Features auch nur für das BTDongle abschalten.

Gruß,
Gero