Anwesenheitserkennung Bluetooth PebbleBee

Begonnen von tomster, 06 November 2014, 10:01:16

Vorheriges Thema - Nächstes Thema

DeeSPe

#705
Habe auch mehrere Tags probiert und der G-Tag ist eindeutig bisher der Beste.
Sowohl Batterielaufzeit als auch Empfang sind sehr gut.

Allerdings haben auch die (für mich) Nachteile:

  • lassen sich nicht ausschalten und sind somit für einen optionalen Gäste-Tag, der nur ab und zu benutzt werden soll, nicht geeignet
  • sind nicht gerade klein (aber auch nicht zu groß, es gibt aber kleinere (schlechtere))
  • nicht wasserdicht, also nicht unbedingt für den Hund geeignet

Gruß
Dan

EDIT: Im 3er-Pack gibt es die gerade bei A.... für 38,60€, also nicht einmal 13€ pro Stück.
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

SouzA

Habe auch seit ca. 2 Wochen drei Gtags hier.
Musste allerdings schon bei zweien die Batterien wechseln!
Wurden vom Pi und von der App nicht mehr erkannt.

Also aus meiner Erfahrung bis jetzt, sind die nicht so toll...

Bis denn
SouzA
Raspi 4, EnOcean TCM310 USB, HM-MOD-UART-USB, Jeelink, hue, AMAD, fully, FRITZBOX, Signalbot, VIERA, Presence BT/Mac, TPLink, Gassistant, Shelly, fhempy, ZigBee

forum-merlin

Hallo in die Runde!

ich habe auch seit einigen Wochen 2 G-Tags hier und betreibe diese am BT des Rasperry Pi 3

Anfangs war das auch alles echt zuverlässig.
Ich habe mir dazu ein FileLog gemacht, und einen Plot eingerichtet um es schnell grafisch darzustellen ob es Ausfälle gab. Anfangs war wie gesagt alles OK.
Irgendwann später (ich weiss aber nicht wieviel später, Tage oder Wochen) habe ich noch das mit dem BatterieStatus irgendwo gelesen und eingerichtet.
Ich kann aber nicht sagen, dass sich das negativ ausgewirkt hätte.

Jetzt allerdings hat sich das geändert und ich weiss nicht wieso.
Ich habe seitdem ich das mit den G-Tags mache keine Änderungen am OS des Pi unternommen, habe lediglich ein paar Dummys und Notify´s definiert, aber am G-Tag Szenario habe ich nichts geändert.

Hier das Problem...
Ich bin ja aktuell daheim, der G-Tag liegt auf dem Tisch, und FHEM meint, ich bin abwesend.

Ich habe es wiefolgt in FHEM eingebunden:

define Holger_GtAG PRESENCE lan-bluetooth 7C:2F:XX:XX:XX:XX 127.0.0.1:5333 30
attr Holger_GtAG absenceThreshold 2
attr Holger_GtAG alarmDevice Sensor
attr Holger_GtAG alarmSettings alarm0,alarm2,alarm3,alarm4,alarm5,alarm6,alarm7,|Holger_GtAG:present|Holger GtAG anwesend|off
attr Holger_GtAG devStateIcon present:rc_GREEN absent:rc_RED maybe.*:rc_YELLOW
attr Holger_GtAG event-on-change-reading presence,state
attr Holger_GtAG group HolgerScript
attr Holger_GtAG presenceThreshold 1
attr Holger_GtAG room Anwesenheit
attr Holger_GtAG sortby 1
attr Holger_GtAG verbose 5


Auch habe ich ein Batterie Script im Hintergrund per CRON.

Die Tags  sind NIE mit einer App gekoppelt gewesen.

Immer wieder geht mein G-Tag Status auf absent.
>>> Sobald ich aber dann das BatterieScript von Hand auf CMD starte kommt auch der present Status wieder.

Ich habe auch schon einige Beiträge hier gelesen, aber ich sehe keinen möglichen Grund für dieses Verhalten meiner Anwesenheitserkennung. Oder habe ich was überlesen?

Ich habe heute bei der Untersuchung der Problematik aber mal was anders gesehen...
hcitool lescan
Set scan parameters failed: Input/output error

Danach musste ich ein
hciconfig hci0 down
hciconfig hci0 up

machen, und dann hat auch der lescan wieder funktioniert.
Aber trotzdem geht der Status das immer absent, present.

Und jetzt noch eins oben drauf...
Wenn ich in FHEM absent bin, kann ich den lescan auf CMD ausführen und er finden den G-Tag. Und erst wenn ich per ctrl+c abbreche, geht auch der Status in FHEM auf present.

Bedeutet, batterie und manuelles hcitool lescan triggern irgendwas das den G-Tag findet.


Kann mir jemand helfen?
Ich suche nach einer nahezu 100%ig zuverlässigen Methode per g_tag die Anwesenheit zu prüfen. Das ist deshalb wichtig weil das auch Auswirkung auf meine Alarmanlage hat.
Daher wäre es mir wirklich sehr wichtig.

Danke Euch
FHEM 5.8 auf RasPi3; CULv3-868; RFXtrx433; HM-Sec-SC-2; HM-CFG-LAN; HM-LC-Bl1-FM; HM-CC-RT-DN; HM-ES-PMSw1-Pl; HM-LC-Sw4-DR; Hunter Ventile; 8ch Relais; ENIGMA2; ONKYO_AVR; SONOS; Harmony; telegram; HM-PB-6-WM55; GPIO; HM-Sen-MDIR-O; HM-SEC-SD; HM-LC-Dim1L-Pl-3;

PatrickR

#708
Mach mal nen Log mit LOG_DEBUG.

/Edit: Werde das Gefühl nicht los, dass die Batterieskripte sich irgendwie mit lepresenced ins Gehege kommen. lepresenced merkt zwar, wenn es Probleme mit dem Scan gibt und startet den Scan neu bzw. resetted das Bluetooth-Interface aber ggf. reicht das bei kurzen Intervallen nicht...

Gesendet von iPad mit Tapatalk
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

forum-merlin

Ja, das läuft: (nicht wunder, aber ich habe vorhin mal durchgestartet)
root@fhempi3:/var/log# ps -ef | grep lepresenced
root       760     1  0 20:54 ?        00:00:03 /usr/bin/perl /opt/fhem/script/lepresenced --loglevel LOG_EMERG -d
root      1255   888  0 21:26 pts/0    00:00:00 grep lepresenced
root@fhempi3:/var/log#

Ich habe das in der rc.local stehen:
# Start lepresenced
/opt/fhem/script/lepresenced --loglevel LOG_EMERG -d

Ich habe den Prozess gekillt, und dann manuell auf CMD so gestartet:

/opt/fhem/script/lepresenced --loglevel LOG_DEBUG

Ausgaben kommen nicht, ein Logfile habe ich auch nicht gefunden, und das was ich im syslog sehe ist:

root@fhempi3:~tail -f /var/log/syslognt
Oct 12 21:40:50 fhempi3 kernel: [ 2815.523704] Bluetooth: hci0 advertising data length corrected
Oct 12 21:40:50 fhempi3 kernel: [ 2815.533175] Bluetooth: hci0 advertising data length corrected
Oct 12 21:40:51 fhempi3 kernel: [ 2816.534250] Bluetooth: hci0 advertising data length corrected
Oct 12 21:40:52 fhempi3 kernel: [ 2817.536176] Bluetooth: hci0 advertising data length corrected
Oct 12 21:40:52 fhempi3 kernel: [ 2817.548744] Bluetooth: hci0 advertising data length corrected
Oct 12 21:40:53 fhempi3 kernel: [ 2818.546527] Bluetooth: hci0 advertising data length corrected
Oct 12 21:41:01 fhempi3 lepresenced[1472]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 8, max age: 30, result: present.
Oct 12 21:41:01 fhempi3 lepresenced[1472]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 9, max age: 30, result: present.
Oct 12 21:41:05 fhempi3 kernel: [ 2830.598494] Bluetooth: hci0 advertising data length corrected
Oct 12 21:41:06 fhempi3 kernel: [ 2831.605690] Bluetooth: hci0 advertising data length corrected
Oct 12 21:41:31 fhempi3 lepresenced[1472]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 25, max age: 30, result: present.
Oct 12 21:41:31 fhempi3 lepresenced[1472]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 26, max age: 30, result: present.
Oct 12 21:41:31 fhempi3 rsyslogd-2007: action 'action 17' suspended, next retry is Wed Oct 12 21:43:01 2016 [try http://www.rsyslog.com/e/2007 ]
Oct 12 21:42:01 fhempi3 lepresenced[1472]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, max age: 30, result: absence.
Oct 12 21:42:01 fhempi3 lepresenced[1472]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, max age: 30, result: absence.
Oct 12 21:42:31 fhempi3 lepresenced[1472]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, max age: 30, result: absence.
Oct 12 21:42:31 fhempi3 lepresenced[1472]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, max age: 30, result: absence.
Oct 12 21:43:01 fhempi3 lepresenced[1472]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, max age: 30, result: absence.
Oct 12 21:43:01 fhempi3 lepresenced[1472]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, max age: 30, result: absence.


Gibt es da noch irgendwo ein Logfile das ich nicht finde??

FHEM 5.8 auf RasPi3; CULv3-868; RFXtrx433; HM-Sec-SC-2; HM-CFG-LAN; HM-LC-Bl1-FM; HM-CC-RT-DN; HM-ES-PMSw1-Pl; HM-LC-Sw4-DR; Hunter Ventile; 8ch Relais; ENIGMA2; ONKYO_AVR; SONOS; Harmony; telegram; HM-PB-6-WM55; GPIO; HM-Sen-MDIR-O; HM-SEC-SD; HM-LC-Dim1L-Pl-3;

PatrickR

Hi!

lepresenced loggt ins syslog, wie sich das gehört. Du bist also richtig.

Im Log sieht man ganz gut, dass keine Beacons mehr ankommen.

Für den 'ff'-Tag wird um 21:41Uhr das letzte Update gesendet. Da ist es schon kurz vor 12, sprich 25 Sekunden ist das letzte Beacon schon her, 30 wären erlaubt. Um 21:42 Uhr ist es dann soweit und das G-Tag-Sterben geht los.

Kannst Du mal mitloggen, wann das Batterieskript aufgerufen wird. Das geht bspw. mit:

logger -t gtagbattery Hole Batteriewerte.
*hier dann die Werte holen*
logger -t gtagbattery Fertig.

logger muss natürlich installiert sein.

Dann könnte man im Log gut sehen, ob der Massentod zeitlich in Zusammenhang mit dem Skript steht.

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

forum-merlin

sorry, ich check grad nicht wie das mit dem "logger" gehen soll.
Muss ich das in mein BatterieScript reinpacken?

Da steht aktuell das drinnen.

#!/bin/bash
mytelnetPW="mypassword"
stringZ=$(sudo gatttool -b 7C:2F:YY:XX:XX:XX--char-read --handle=0x001b)
stringZ=${stringZ:33:2}
stringZ=$(echo "$stringZ" | tr a-f A-F)
decimal=$(echo "ibase=16; $stringZ" | bc)
perl /opt/fhem/fhem.pl 7072 $mytelnetPW "setreading Holger_GtAG Batterie $decimal"


Logger ist scheinbar auf dem System

root@fhempi3:~# logger --help

Usage:
logger [options] [<message>]

Options:
-T, --tcp             use TCP only
-d, --udp             use UDP only
-i, --id              log the process ID too
-f, --file <file>     log the contents of this file
-n, --server <name>   write to this remote syslog server
-P, --port <number>   use this UDP port
-p, --priority <prio> mark given message with this priority
     --prio-prefix     look for a prefix on every line read from stdin
-s, --stderr          output message to standard error as well
-t, --tag <tag>       mark every line with this tag
-u, --socket <socket> write to this Unix socket
     --journald[=<file>]  write journald entry

-h, --help     display this help and exit
-V, --version  output version information and exit

For more details see logger(1).

FHEM 5.8 auf RasPi3; CULv3-868; RFXtrx433; HM-Sec-SC-2; HM-CFG-LAN; HM-LC-Bl1-FM; HM-CC-RT-DN; HM-ES-PMSw1-Pl; HM-LC-Sw4-DR; Hunter Ventile; 8ch Relais; ENIGMA2; ONKYO_AVR; SONOS; Harmony; telegram; HM-PB-6-WM55; GPIO; HM-Sen-MDIR-O; HM-SEC-SD; HM-LC-Dim1L-Pl-3;

PatrickR


#!/bin/bash
mytelnetPW="mypassword"
logger -t gtagbattery Hole Batteriewert für Holger_GtAG.
stringZ=$(sudo gatttool -b 7C:2F:YY:XX:XX:XX--char-read --handle=0x001b)
stringZ=${stringZ:33:2}
stringZ=$(echo "$stringZ" | tr a-f A-F)
decimal=$(echo "ibase=16; $stringZ" | bc)
perl /opt/fhem/fhem.pl 7072 $mytelnetPW "setreading Holger_GtAG Batterie $decimal"
logger -t gtagbattery Fertig.


Wie oft rufst Du das Skript eigentlich auf?

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

uelly

Ich habe bisher bei mir mit RPi 3 und 2 G-Tag die Erfahrung gemacht, dass das presence mit Batterie Skript nicht funktioniert... soll heißen, ohne Batterieskript laufen die G-Tag prima, Status wird immer richtig erkannt, startet das battierskript mit dann beginnen auch die Probleme, trotz Anwesenheit werden die G-Tag dann wahllos als Abschnitt gemeldet oder aber das presence Modul bekommt gar keine Verbindung zum G-Tag... weiß nun nicht ob es an meiner Blödheit liegt oder tatsächlich an der Hardware oder oder...

CoolTux

Habe die selbe Beobachtung gemacht. Bei mir kam es immer dann vor wenn mehrere G-Tags zeitgleich abgefragt werden und gatttool doppelt aufgerufen wurde.

Ich arbeite gerade an einem Modul zum abfragen der G-Tags. BTLE_Sensor. Die Frage die sich mir stellt ist, ist es ok wenn die Readings in dem Moduldevice stecken oder sollen sie lieber ins presence Device.
Patrick arbeitet auch an einer Batterie Lösung direkt in lepresenced. Ich mache meine Lösung nicht als Konkurrents sondern um was zum testen bei mir zu haben. Das BTLE_Sensor Modul wird auch einen Pflanzensensor unterstützen.



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

micky0867



Zitat von: DeeSPe am 12 Oktober 2016, 11:23:25
Allerdings haben auch die (für mich) Nachteile:

  • lassen sich nicht ausschalten und sind somit für einen optionalen Gäste-Tag, der nur ab und zu benutzt werden soll, nicht geeignet

Ich benutze dafür in fhem das Attribut disable=1

Micky

Gesendet von meinem Toaster.


Ellert

Zitat von: uelly am 13 Oktober 2016, 06:44:07
Ich habe bisher bei mir mit RPi 3 und 2 G-Tag die Erfahrung gemacht, dass das presence mit Batterie Skript nicht funktioniert... soll heißen, ohne Batterieskript laufen die G-Tag prima, Status wird immer richtig erkannt, startet das battierskript mit dann beginnen auch die Probleme, trotz Anwesenheit werden die G-Tag dann wahllos als Abschnitt gemeldet oder aber das presence Modul bekommt gar keine Verbindung zum G-Tag... weiß nun nicht ob es an meiner Blödheit liegt oder tatsächlich an der Hardware oder oder...

Bei mir ist der Batterielevel seit Monaten konstant, deshalb frage ich den Level nur einmal Nachts ab, falls ich anwesend bin, dann stört es nicht.

uelly

Zitat von: CoolTux am 13 Oktober 2016, 07:00:58
Habe die selbe Beobachtung gemacht. Bei mir kam es immer dann vor wenn mehrere G-Tags zeitgleich abgefragt werden und gatttool doppelt aufgerufen wurde.

Ich arbeite gerade an einem Modul zum abfragen der G-Tags. BTLE_Sensor. Die Frage die sich mir stellt ist, ist es ok wenn die Readings in dem Moduldevice stecken oder sollen sie lieber ins presence Device.
Patrick arbeitet auch an einer Batterie Lösung direkt in lepresenced. Ich mache meine Lösung nicht als Konkurrents sondern um was zum testen bei mir zu haben. Das BTLE_Sensor Modul wird auch einen Pflanzensensor unterstützen.



Grüße

Mit wären sie im presence Modul lieber... ich hab das batteriescript erstmal ausgeschaltet und prüfe den Batteriestatus immermal auf Arbeit mit dem Handy (wenn ich das Zuhause tue würde der Tag auf absence gehen)

CoolTux

Hier mal die 2 Module in der Übersicht. Einmal das IODev Modul 10_BTLE.pm und einmal das Sensor Modul 42_BTLESensor.pm mit eingerichtet für den GTag zum Batterie auslesen

Erstmal nur mit dem battery Reading im Device selber. Später kann man über Attribut noch das presence Device einstellen wo dann auch reingeschrieben wird.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

forum-merlin

#719
Zitat von: PatrickR am 12 Oktober 2016, 22:57:10

#!/bin/bash
mytelnetPW="mypassword"
logger -t gtagbattery Hole Batteriewert für Holger_GtAG.
stringZ=$(sudo gatttool -b 7C:2F:YY:XX:XX:XX--char-read --handle=0x001b)
stringZ=${stringZ:33:2}
stringZ=$(echo "$stringZ" | tr a-f A-F)
decimal=$(echo "ibase=16; $stringZ" | bc)
perl /opt/fhem/fhem.pl 7072 $mytelnetPW "setreading Holger_GtAG Batterie $decimal"
logger -t gtagbattery Fertig.


Wie oft rufst Du das Skript eigentlich auf?

Patrick

Hallo Patrick,
Ich rufe die Batterie-Checks so gescheduled durch CRON auf:

*/30 */2 * * * /opt/fhem/script/Holger_GtAG_Batterie.sh >/dev/null 2>&1
*/30 1-23/2 * * * /opt/fhem/script/Mirjam_GtAG_Batterie.sh >/dev/null 2>&1


Ich weiss nicht genau was ich sagen soll. Aber es läuft jetzt derzeit ziemlich zuverlässig. Also heute!

Was habe ich gestern noch gemacht?!
1)
ich habe mein /var/log in eine RAM Disk verschoben. und zwar so:
cmd>vi /etc/fstab
und diesen Eintrag hinzugefügt:

none        /var/log        tmpfs   size=5M,noatime         00


2)
Ergebnis nach Reboot:

root@fhempi3:~# df -h
Dateisystem              Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root                  30G    5,2G   23G   19% /
devtmpfs                  483M       0  483M    0% /dev
tmpfs                     487M       0  487M    0% /dev/shm
tmpfs                     487M     56M  432M   12% /run
tmpfs                     5,0M    4,0K  5,0M    1% /run/lock
tmpfs                     487M       0  487M    0% /sys/fs/cgroup
none                      5,0M    2,8M  2,3M   55% /var/log
/dev/mmcblk0p1             63M     21M   43M   33% /boot
tmpfs                      98M       0   98M    0% /run/user/0


3) Nachteil:
Ich kann natürlich nichts nachverfolgen sollte ich mal Probleme haben.
Die Logs sind dann entweder schon voll, oder nach nem Reboot weg! Aber dafür entlaste ich meine SD Karte!

4)
Dann habe ich noch ein RasPi Update gemacht.
cmd>sudo apt-get install rpi-update
und dann natürlich
cmd>sudo rpi-update

5)
Sofort danach hatte sich das BT Device besser verhalten. Ich hatte die I/O Error nicht mehr, die G-Tags waren stabil da, und ich habe ein cmd>tail -f auf das syslog gemacht und konnte da die folgenden Messages sehen:
(Ok, das ist von jetzt aktuell)

root@fhempi3:~# tail -f /var/log/syslog | grep lepresenced
Oct 13 20:13:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 2, max age: 30, result: present.
Oct 13 20:13:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:14:09 fhempi3 lepresenced[1036]: [tid:0] main::stats_task: Active clients: 2, known devices: 2 (min/max age: 1/1)
Oct 13 20:14:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 2, max age: 30, result: present.
Oct 13 20:14:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 2, max age: 30, result: present.
Oct 13 20:14:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:14:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:15:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:15:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:15:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:15:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:16:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:16:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:16:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 2, max age: 30, result: present.
Oct 13 20:16:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:17:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 2, max age: 30, result: present.
Oct 13 20:17:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:17:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 2, max age: 30, result: present.
Oct 13 20:17:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 0, max age: 30, result: present.
Oct 13 20:18:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:18:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:18:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:18:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:19:10 fhempi3 lepresenced[1036]: [tid:0] main::stats_task: Active clients: 2, known devices: 2 (min/max age: 1/1)
Oct 13 20:19:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 2, max age: 30, result: present.
Oct 13 20:19:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:19:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:19:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:20:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:20:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:20:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:20:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:21:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:21:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 0, max age: 30, result: present.
Oct 13 20:21:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 2, max age: 30, result: present.
Oct 13 20:21:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:22:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:22:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:22:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:22:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.


Ich habe das Update deshalb gemacht, weil ich noch ein Paar Forenbeiträge über Google gefunden habe die sagten, dass es bei den BT Problemen mit dem Pi hilfreich sein kann und einer das so gelöst hatte.
Siehe hier:
https://urbanjack.wordpress.com/2014/04/17/fix-bluez-keeps-crashing/
Ich habe allerdings keine Änderungen an der "/boot/cmdline.txt" vorgenommen.

Jetzt habe ich

root@fhempi3:~# cat /proc/version
Linux version 4.4.23-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #913 SMP Tue Oct 4 14:16:19 BST 2016
root@fhempi3:~#




Fazit:
Aktuell läuft es wieder. Und ich kann es nicht rekonstruieren.
Ich melde mich also hier wieder wenn ich was melden kann.

Danke aber trotzdem, dass Du so schnell reagiert hast!

Beste Grüße

Holger

Update a few minutes later


Oct 13 20:29:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:29:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:30:02 fhempi3 lepresenced[1036]: [tid:1] main::bluetooth_thread: Received unknown output: 'Disable scan failed: Input/output error'!
Oct 13 20:30:02 fhempi3 lepresenced[1036]: [tid:1] main::bluetooth_thread: hcitool exited, retrying...
Oct 13 20:30:03 fhempi3 lepresenced[1036]: [tid:1] main::bluetooth_thread: Received 'LE Scan ...'.
Oct 13 20:30:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:30:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:30:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:30:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:31:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:31:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:31:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:31:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:32:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 2, max age: 30, result: present.
Oct 13 20:32:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 2, max age: 30, result: present.
Oct 13 20:32:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 3, max age: 30, result: present.
Oct 13 20:32:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:33:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:33:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:33:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:33:49 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.
Oct 13 20:34:13 fhempi3 lepresenced[1036]: [tid:0] main::stats_task: Active clients: 2, known devices: 2 (min/max age: 1/1)
Oct 13 20:34:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:aa, age: 1, max age: 30, result: present.
Oct 13 20:34:19 fhempi3 lepresenced[1036]: [tid:0] main: Sending update for mac address 7C:2f:xx:xx:xx:ff, age: 1, max age: 30, result: present.


Es gibt also doch noch irgendwelche I/O Error, haben aber scheinbar keinen Einfluss auf die Sache
FHEM 5.8 auf RasPi3; CULv3-868; RFXtrx433; HM-Sec-SC-2; HM-CFG-LAN; HM-LC-Bl1-FM; HM-CC-RT-DN; HM-ES-PMSw1-Pl; HM-LC-Sw4-DR; Hunter Ventile; 8ch Relais; ENIGMA2; ONKYO_AVR; SONOS; Harmony; telegram; HM-PB-6-WM55; GPIO; HM-Sen-MDIR-O; HM-SEC-SD; HM-LC-Dim1L-Pl-3;