lepresenced und G-Tags - nach einiger Zeit nur noch absent/unreachable

Begonnen von stiefl, 18 August 2017, 13:00:51

Vorheriges Thema - Nächstes Thema

stiefl

Hallo zusammen,

ich verwende lepresenced (bis gestern Version 0.81-1, nun  Version 0.82-1) auf einem Rasperry Pi 3 mit integriertem BT-Modul zur Anwesenheitserkennung mittels G-Tags. Bis vor ein paar Tagen hat das einwandfrei funktioniert. Seither werden meine G-Tags immer als abwesend gezeigt. Nach einem Systemneustart funktioniert wieder alles einwandfrei bis zu dem Zeitpunkt wo ich das Haus verlasse und ein paar Stunden später wieder betrete. Dann hilft nur ein Neustart. Es scheint so, als würde eine zu lange Abwesenheit den Fehler auslösen.

Die G-Tags sind folgendermaßen definiert:

define gtag_orange PRESENCE lan-bluetooth 7C:2F:80:97:38:42 127.0.0.1:5333 25 60
attr gtag_orange alias Stefan
attr gtag_orange verbose 5


Im Log kommt bei Verbose 5 folgende Meldung bei jedem Prüfintervall:

2017.08.18 12:46:14 5: PRESENCE (gtag_orange) - received data: absence;rssi=unreachable;model=lan-lepresenced;daemon=lepresenced V0.82

ein manueller Scan liefert folgendes Ergebnis:

pi@raspberrypi:~ $ sudo hcitool lescan
LE Scan ...
7C:2F:80:97:38:42 (unknown)
7C:2F:80:97:38:42 Gigaset G-tag


Der Tag wird also eigentlich gefunden.

Wie kann ich den Fehler eingrenzen??

PatrickR

Standardfrage: Greifen andere Dienste/Module auf Bluetooth zu? (z. B. Batterieskripte)


Von unterwegs gesendet.
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

arthur_dent_2015

Moin Stiefl,
ich hatte das selbe Problem, läuft einen Tag, dann plötzlich nur noch absent Meldungen, hcitool findet die G-Tags aber. Mit 0.82 wurde lepresenced wohl auf hcidump umgestellt und der scheint ein Problem zu haben. Ich habs gelöst in dem ich lepresenced mit --legacymode starte. Dann sind zwar die RSSI Werte nicht mehr aber absent und present wird wieder sauber gemeldet.
Gruß
Arthur

stiefl

Danke für eure Antworten!

@Patrick: Ja ich verwende noch "BleTagBattery" (Version 0.0.3) in der Standarddefinition für den Batteriestatus der beiden G-Tags:
define gtagBatt BleTagBattery
Ansonsten wird Bluetooth nicht verwendet. Kanns damit zusammenhängen? Reichts, wenn ich zum Test einfach die Definition lösche?

@Arthur:
Danke für den Tipp. Es hat aber auch mit 0.81 bereits nicht mehr geklappt, da ich erst deshalb auf die Version 0.82 upgedatet habe - in der Hoffnung, dass der Fehler dann nicht mehr auftritt. Nichtsdestotrotz würd ich deinen Lösungansatz gerne versuchen. Wie genau has du den Legacymode gestartet?

PatrickR

#4
@Stiefl: Probiere doch mal testweise, ob das Problem ohne bletagbattery noch auftritt.

@Arthur: Der hcidump-Patch ist wesentlich älter. Die mir bislang bekannten Probleme waren allesamt auf ein nicht installiertes hcidump zurückzuführen, daher hatte ich eigentlich vor, den legacymode rauszunehmen. Helfen würde mir ein Log mit LOG_DEBUG zum Zeitpunkt, an dem der Fehler auftritt.


Von unterwegs gesendet.
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

stiefl

Momentan funktionierts spannenderweise wieder. Wenns das nächste Mal aussetzt, werde ich das BleTagBattery entfernen und weiter testen.

arthur_dent_2015

@Patrick: Ich vermute dass es mit dem RPI3 zusammenhängt. Ich habe 3 RPI's laufen, davon einer RPI2 mit USB BT Stick. Bei dem lief leprenence zuverlässig. Die beiden 3er lieferten immer nur absent. Ich hab dann mal rpi-update und dist-upgrade gemacht. Siehe da, Bluetooth funktionierte besser aber immer noch absent  :( Dann lepresence 0.82 drauf und schon lieferten beide present :). Jedenfalls bis zum ersten FHEM restart :( hcitool fand die G-Tags aber. Google bemüht, nix :( --legacymode getestet und schon waren die G-Tags da. Ich muss mal gucken ob das SYSLOG noch da ist, allerdings hab ich nur mit LOG-INFO getestet. Würde das weiter helfen?

@Stiefl: einfach im Startscript vom lepresence --legacymode an den Aufruf anhängen.

stiefl

Gerade heimgekommen, funktioniert wieder nicht. Ich versuch mal den Tipp mit dem legacymode, vielleicht können wir dann was ausschließen  ;)

Noch was aus dem Syslog:

Aug 22 17:24:45 raspberrypi systemd[1]: Starting LSB: lepresenced - presenced for Bluetooth LE devices....
Aug 22 17:24:45 raspberrypi lepresenced[1001]: [tid:0] main: Version 0.82 started (device: hci0, listen addr: 0.0.0.0, listen port: 5333, daemonize: 0, legacy mode: 0, rssi threshold: 10, log level: 7, debug: 1).
Aug 22 17:24:45 raspberrypi lepresenced[998]: Starting the process: lepresenced[tid:0] main: Version 0.82 started (device: hci0, listen addr: 0.0.0.0, listen port: 5333, daemonize: 0, legacy mode: 0, rssi threshold: 10, log level: 7, debug: 1).
Aug 22 17:24:45 raspberrypi lepresenced[1001]: [tid:0] main::sanity_check: hciconfig found at '/bin/hciconfig'.
Aug 22 17:24:45 raspberrypi lepresenced[998]: [tid:0] main::sanity_check: hciconfig found at '/bin/hciconfig'.
Aug 22 17:24:45 raspberrypi lepresenced[1001]: [tid:0] main::sanity_check: hcitool found at '/usr/bin/hcitool'.
Aug 22 17:24:45 raspberrypi lepresenced[998]: [tid:0] main::sanity_check: hcitool found at '/usr/bin/hcitool'.
Aug 22 17:24:45 raspberrypi lepresenced[1001]: [tid:0] main::sanity_check: hcidump found at '/usr/bin/hcidump'.
Aug 22 17:24:45 raspberrypi lepresenced[998]: [tid:0] main::sanity_check: hcidump found at '/usr/bin/hcidump'.
Aug 22 17:24:45 raspberrypi lepresenced[1001]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', resetting...
Aug 22 17:24:45 raspberrypi lepresenced[998]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', resetting...
Aug 22 17:24:45 raspberrypi lepresenced[1001]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
Aug 22 17:24:46 raspberrypi lepresenced[998]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
Aug 22 17:24:46 raspberrypi lepresenced[1001]: [tid:1] main::bluetooth_scan_thread: Received 'LE Scan ...'.
Aug 22 17:24:47 raspberrypi kernel: [  606.236214] Bluetooth: hci0 advertising data length corrected
Aug 22 17:24:48 raspberrypi kernel: [  607.242394] Bluetooth: hci0 advertising data length corrected
Aug 22 17:24:49 raspberrypi kernel: [  608.245473] Bluetooth: hci0 advertising data length corrected
Aug 22 17:24:51 raspberrypi kernel: [  610.250589] Bluetooth: hci0 advertising data length corrected
Aug 22 17:24:53 raspberrypi kernel: [  612.262476] Bluetooth: hci0 advertising data length corrected
Aug 22 17:24:54 raspberrypi kernel: [  613.266321] Bluetooth: hci0 advertising data length corrected
Aug 22 17:24:56 raspberrypi lepresenced[998]: Known devices (1):
Aug 22 17:24:56 raspberrypi lepresenced[998]: mac: 7c:2f:80:97:38:42, ages:  2/ 2, rssi: -83, name: Gigaset G-tag
[color=red]Aug 22 17:24:56 raspberrypi kernel: [  615.276402] Bluetooth: hci0 advertising data length corrected
Aug 22 17:24:57 raspberrypi kernel: [  616.283718] Bluetooth: hci0 advertising data length corrected
Aug 22 17:24:58 raspberrypi kernel: [  617.286727] Bluetooth: hci0 advertising data length corrected
Aug 22 17:24:59 raspberrypi kernel: [  618.294507] Bluetooth: hci0 advertising data length corrected
Aug 22 17:25:01 raspberrypi kernel: [  620.301195] Bluetooth: hci0 advertising data length corrected
Aug 22 17:25:02 raspberrypi kernel: [  621.302521] Bluetooth: hci0 advertising data length corrected
Aug 22 17:25:03 raspberrypi kernel: [  622.302311] Bluetooth: hci0 advertising data length corrected
Aug 22 17:25:04 raspberrypi kernel: [  623.306211] Bluetooth: hci0 advertising data length corrected
Aug 22 17:25:05 raspberrypi kernel: [  624.311705] Bluetooth: hci0 advertising data length corrected
Aug 22 17:25:06 raspberrypi kernel: [  625.323639] Bluetooth: hci0 advertising data length corrected[/color]
Aug 22 17:25:07 raspberrypi lepresenced[998]: Known devices (1):
Aug 22 17:25:07 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Tue Aug 22 17:25:37 2017 [try http://www.rsyslog.com/e/2007 ]
Aug 22 17:25:07 raspberrypi lepresenced[998]: mac: 7c:2f:80:97:38:42, ages:  1/ 2, rssi: -80, name: Gigaset G-tag


dieses sekündliche "hci0 advertising data length corrected"... soll das so sein???
ok, hab die "Lösung" hier gefunden: https://forum.fhem.de/index.php/topic,28753.msg499184/topicseen.html#msg499184

PatrickR

#8
@stiefl: In dem Log ist alles ok, zumindest für einen G-Tag.

Was ich aber wirklich für die Fehlersuche brauche ist ein Log mit LOG_DEBUG, vom Start von lepresenced bis nach dem Auftreten des Problems. Dann wissen wir mehr.

Habe selbst zwei lepresenced 0.82 sowohl auf einer Debian-VM als auch auf einem RPi3 (mit Onboard-Bluetooth) und 3 G-Tags dauerhaft im Einsatz und bis auf leere Batterien keine Probleme. Daher ist das schwer ohne Logs zu debuggen.

Da die Probleme scheinbar nach zufälligen Zeiten auftreten, ist ein Vergleich mit dem legacymode auch nur bedingt aussagekräftig.

Für ganz harte Fälle kann man den aktuellen lepresenced übrigens im Vordergrund starten und noch mehr erfahren. Es gibt also Hoffnung.

Patrick


Von unterwegs gesendet.
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

stiefl

@Patrick: hab den Debug-Mode bereits aktiviert und am laufen. Ich meld mich, sobald der Fehler auftritt  8)

stiefl

@Patrick:

Hier nun der Syslog (syslog-lepresenced.txt). Wir haben um 6:54 Uhr das Haus verlassen. Als ich heute gegen 17:00 Uhr nach Hause gekommen bin, ist nichts mehr passiert.

Mir ist aufgefallen, dass neben den G-Tags auch noch ein weiterer Bluetooth-Tag von itrack (Schlüsselfinder meiner Freundin) und meine Gear S3 gefunden wird. Keine Ahnung, ob das hier Probleme verursachen kann!?

Nun is gerade meine Freudin nach Hause gekommen. Kurz darauf wurden alle G-Tags als present gefunden.... Siehe syslog-lepresenced-2.txt

PatrickR

@stiefl:
Vernünftige Logs, so lässt sich arbeiten.

zuallererst:

Aug 22 17:52:16 raspberrypi lepresenced[520]: [tid:0] main: Version 0.82 started (device: hci0, listen addr: 0.0.0.0, listen port: 5333, daemonize: 0, legacy mode: 0, rssi threshold: 10, log level: 7, debug: 1).
Aug 22 17:52:16 raspberrypi lepresenced[504]: Starting the process: lepresenced[tid:0] main: Version 0.82 started (device: hci0, listen addr: 0.0.0.0, listen port: 5333, daemonize: 0, legacy mode: 0, rssi threshold: 10, log level: 7, debug: 1).
Aug 22 18:14:08 raspberrypi lepresenced[505]: [tid:0] main: Version 0.82 started (device: hci0, listen addr: 0.0.0.0, listen port: 5333, daemonize: 0, legacy mode: 0, rssi threshold: 10, log level: 7, debug: 1).
Aug 22 18:14:09 raspberrypi lepresenced[495]: Starting the process: lepresenced[tid:0] main: Version 0.82 started (device: hci0, listen addr: 0.0.0.0, listen port: 5333, daemonize: 0, legacy mode: 0, rssi threshold: 10, log level: 7, debug: 1).

Es laufen zwei lepresenced parallel, ggf. mehr. Zwei Highlander sind nicht gut. Entweder Du hattest Dich irgendwann mal selbst um den automatischen Start von lepresenced (z. B. über /etc/rc.local) gekümmert und dann das Paket installiert oder es liegt daran, dass --daemonize nicht gesetzt ist. In Deinem Fall liegt das vermutlich daran, dass --debug bzw. -d gesetzt ist.

Wenn Du --debug rausgenommen hast bitte mal den pi durchstarten und Folgendes ausführen:
ps aux|grep lepresenced

Das sollte dann so aussehen:

root@rpi-test:~# ps aux|grep lepresenced
root     22733  1.1  1.3  35692 13156 ?        Ssl  Aug05 315:05 /usr/bin/perl /usr/sbin/lepresenced --daemon --device hci0 --listenaddress 0.0.0.0 --listenport 5333 --loglevel LOG_DEBUG
root     31584  0.0  0.2   4296  1976 pts/0    S+   21:18   0:00 grep lepresenced

Wenn Du mehr oder weniger Zeilen hast, müssen wir wieder ran.

Führe bitte zur Sicherheit nochmal Folgendes aus und poste die Ausgabe:

dpkg -l|egrep -i '(blue|hci)'


Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

stiefl

Servus Patrick

ich hab lediglich für den gestrigen syslog den Debug aktiviert:
BLUETOOTH_DEVICE="hci0"
LISTEN_ADDRESS="0.0.0.0"
LISTEN_PORT="5333"
#SYSLOG_LEVEL="LOG_WARNING"
SYSLOG_LEVEL="LOG_DEBUG"


Ansonsten hab ich in der etc/init.d/lepresenced keine Änderungen vorgenommen.

Die Installation hab ich einmalig laut Wiki (Variante 2) gemacht.

so schauts gerade aus:
pi@raspberrypi:~ $ ps aux|grep lepresenced
root       510  0.2  1.2  33024 11608 ?        Sl   Aug23   2:55 /usr/bin/perl /usr/sbin/lepresenced --daemon --device hci0 --listenaddress 0.0.0.0 --listenport 5333 --loglevel LOG_DEBUG
pi        1869  0.0  0.2   4276  2016 pts/0    S+   17:10   0:00 grep --color=auto lepresenced


--debug entfernt und neu gestartet:
pi@raspberrypi:~ $ ps aux|grep lepresenced
root       504  0.0  0.1   1908  1136 ?        Ss   17:12   0:00 /bin/sh /etc/init.d/lepresenced start
root       517  0.7  1.2  32940 11632 ?        Sl   17:12   0:00 /usr/bin/perl /usr/sbin/lepresenced --daemon --device hci0 --listenaddress 0.0.0.0 --listenport 5333 --loglevel LOG_WARNING
pi         834  0.0  0.1   4272  1848 pts/0    S+   17:13   0:00 grep --color=auto lepresenced


pi@raspberrypi:~ $ dpkg -l|egrep -i '(blue|hci)'
ii  bluez                          5.23-2+rpi2                      armhf        Bluetooth tools and daemons
ii  bluez-firmware                 1.2-3+rpi1                       all          Firmware for Bluetooth devices
ii  bluez-hcidump                  5.23-2+rpi2                      armhf        Analyses Bluetooth HCI packets
ii  lepresenced                    0.82-1                           all          lepresenced to detect the presence of Bluetooth LE devices
ii  pi-bluetooth                   0.1.3                            armhf        Raspberry Pi 3 bluetooth



Ich hab gestern auch nochmal das BleTagBattery-Device entfernt und neu hinzugefügt. Scheint ganz so, als würds damit tatsächlich Probleme geben. Gestern wurde der Batteriestatus erfolgreich ermittelt (auch nicht auf Anhieb) und jetzt funktionierts wieder nicht mehr. Ich werd das Device nun nochmal entfernen und das ganze dann weiter beobachten. Bin leider übers Wochenende nicht zuhause und werds erst Sonntag merken....

2017.08.24 17:12:51 4: Sub BleTagBattery_Run (bleTagBatt) - start blocking call
2017.08.24 17:12:51 5: Sub BleTagBattery_stateRequestTimer (bleTagBatt) - state request timer called
2017.08.24 17:12:51 4: Sub BleTagBattery_BlockingRun (bleTagBatt) - device found. device: gtag_orange
2017.08.24 17:12:51 4: Sub BleTagBattery_BlockingRun (bleTagBatt) - device name: Gigaset G-tag
2017.08.24 17:12:51 4: Sub BleTagBattery_BlockingRun (bleTagBatt) - device address: 7C:2F:80:97:38:42
2017.08.24 17:12:51 4: Sub BleTagBattery_BlockingRun (bleTagBatt) - try to connect with public
2017.08.24 17:12:54 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 0, result: connect error: Transport endpoint is not connected (107)

2017.08.24 17:12:56 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 1, result: connect error: Function not implemented (38)

2017.08.24 17:12:56 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 2, result: connect: Cannot allocate memory (12)

2017.08.24 17:12:57 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 3, result: connect error: Software caused connection abort (103)

2017.08.24 17:12:57 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 4, result: connect: No route to host (113)

2017.08.24 17:12:57 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - invalid gatttool response
2017.08.24 17:12:57 4: Sub BleTagBattery_BlockingRun (bleTagBatt) - try to connect with random
2017.08.24 17:12:57 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 0, result: connect: No route to host (113)

2017.08.24 17:12:57 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 1, result: connect: No route to host (113)

2017.08.24 17:12:57 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 2, result: connect: No route to host (113)

2017.08.24 17:12:57 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 3, result: connect: No route to host (113)

2017.08.24 17:12:57 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 4, result: connect: No route to host (113)

2017.08.24 17:12:57 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - invalid gatttool response
2017.08.24 17:12:57 4: Sub BleTagBattery_BlockingRun (bleTagBatt) - tag not supported
2017.08.24 17:12:57 4: Sub BleTagBattery_BlockingRun (bleTagBatt) - processing gatttool response for device gtag_orange. batteryLevel:
2017.08.24 17:12:57 4: Sub BleTagBattery_BlockingRun (bleTagBatt) - device found. device: gtag_rot
2017.08.24 17:12:57 4: Sub BleTagBattery_BlockingRun (bleTagBatt) - device not present.
2017.08.24 17:12:57 4: Sub BleTagBattery_BlockingDone (bleTagBatt) - done

arthur_dent_2015

Moin Patrick,
nachdem gestern auch der legacymode bei mir versagt hat hab ich wieder auf den standardmode gewechselt und LOG_DEBUG eingeschaltet. Lief ne Weile ganz gut, dann sporadische Aussetzer bis zum Totalausfall, auch nach reboot nur noch absent  :( Nach manuellem Stop und Start wieder sporadisch present. Die 3 G-Tags sind maximal 3 Meter vom Raspi entfernt, auch wenn die RSSI Werte was anderes vermuten lassen. Im Anhang Auszüge aus dem SYSLOG.
Gruß
Arthur

PatrickR

Mahlzeit!

Zitat von: stiefl am 24 August 2017, 17:18:48
--debug entfernt und neu gestartet:
pi@raspberrypi:~ $ ps aux|grep lepresenced
root       504  0.0  0.1   1908  1136 ?        Ss   17:12   0:00 /bin/sh /etc/init.d/lepresenced start
root       517  0.7  1.2  32940 11632 ?        Sl   17:12   0:00 /usr/bin/perl /usr/sbin/lepresenced --daemon --device hci0 --listenaddress 0.0.0.0 --listenport 5333 --loglevel LOG_WARNING
pi         834  0.0  0.1   4272  1848 pts/0    S+   17:13   0:00 grep --color=auto lepresenced

Hmpf. Aus irgendeinem Grund ist der Loglevel LOG_WARNING. Stelle den mal bitte auf LOG_DEBUG. Der einzig richtige Ort hierfür ist /etc/default/lepresenced. Dazu kommt noch, dass mysteriöserweise das init-Skript noch läuft. Das ist zwar wahrscheinlich nicht schädlich aber auch nicht im Sinne des Erfinders.

Zitat von: stiefl am 24 August 2017, 17:18:48
pi@raspberrypi:~ $ dpkg -l|egrep -i '(blue|hci)'
ii  bluez                          5.23-2+rpi2                      armhf        Bluetooth tools and daemons
ii  bluez-firmware                 1.2-3+rpi1                       all          Firmware for Bluetooth devices
ii  bluez-hcidump                  5.23-2+rpi2                      armhf        Analyses Bluetooth HCI packets
ii  lepresenced                    0.82-1                           all          lepresenced to detect the presence of Bluetooth LE devices
ii  pi-bluetooth                   0.1.3                            armhf        Raspberry Pi 3 bluetooth

Ok, das sieht gut aus. Ich hatte schon befürchtet, dass wieder irgendein bunter GUI-Bluetooth-Manager reinfunkt.

Zitat von: stiefl am 24 August 2017, 17:18:48
Ich hab gestern auch nochmal das BleTagBattery-Device entfernt und neu hinzugefügt. Scheint ganz so, als würds damit tatsächlich Probleme geben. Gestern wurde der Batteriestatus erfolgreich ermittelt (auch nicht auf Anhieb) und jetzt funktionierts wieder nicht mehr. Ich werd das Device nun nochmal entfernen und das ganze dann weiter beobachten. Bin leider übers Wochenende nicht zuhause und werds erst Sonntag merken....


2017.08.24 17:12:54 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 0, result: connect error: Transport endpoint is not connected (107)

2017.08.24 17:12:56 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 1, result: connect error: Function not implemented (38)

2017.08.24 17:12:56 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 2, result: connect: Cannot allocate memory (12)

2017.08.24 17:12:57 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 3, result: connect error: Software caused connection abort (103)

2017.08.24 17:12:57 4: Sub BleTagBattery_readSensorValue (bleTagBatt) - call gatttool char read loop: 4, result: connect: No route to host (113)

Ach Du großer Gott. Ohne BleTagBattery zu kennen würde ich sagen, dass da was im Eimer ist. Leider ist die Bluetooth-Implementierung unter Linux nach meinen Erfahrungen nicht wirklich stabil. Die muss man immer pfleglich behandeln und nicht zu sehr stressen. Daher scannt lepresenced im Gegensatz zu blescan.pl dauerhaft.
Bitte lass mal das Batteriezeug aus bis klar ist, ob das Problem noch auftritt.

Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook