G-Tag lt. lepresenced plötzlich present, obwohl meilenweit entfernt

FunkOdyssey · 28 März 2017, 14:30:18

Kann mir jemand einen Tipp geben?

Ich habe ein Gigaset G-Tag mit lepresenced in Betrieb.
Meine Ankunft funktioniert auch immer einwandfrei. Aber wenn ich das Haus verlasse, dann bin ich problemlos absent, aber nach einem undefinierten Zeitabstand wieder kurze Zeit "present". Das G-Tag befindet sich (hier um 10:51:23 Uhr) aber meilenweit vom Haus entfernt.

Ich habe die auslösende Zeile im Syslog (Log-Stufe LOG_DEBUG aktiv) im größeren Code-Tag ein wenig hervorgehoben.

FHEM-Device-Log

Code Auswählen

2017-03-28_08:44:07 gtag1 rssi: -58
2017-03-28_08:46:07 gtag1 rssi: -57
2017-03-28_08:52:07 gtag1 rssi: -58
2017-03-28_08:53:09 gtag1 rssi: -69
2017-03-28_08:53:23 gtag1 rssi: -80
2017-03-28_08:55:23 gtag1 rssi: -85
2017-03-28_08:57:23 gtag1 rssi: -86
2017-03-28_08:59:23 gtag1 absent
2017-03-28_08:59:23 gtag1 presence: absent
2017-03-28_08:59:23 gtag1 rssi: unreachable
2017-03-28_10:51:23 gtag1 present
2017-03-28_10:51:23 gtag1 presence: present
2017-03-28_10:51:23 gtag1 rssi: -86
2017-03-28_10:53:23 gtag1 absent
2017-03-28_10:53:23 gtag1 presence: absent
2017-03-28_10:53:23 gtag1 rssi: unreachable

Syslog (LOG_DEBUG)

Code Auswählen

Mar 28 08:52:46 FHEM kernel: [132757.630796] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:47 FHEM kernel: [132758.629936] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:48 FHEM kernel: [132759.638056] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:49 FHEM kernel: [132760.640193] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:50 FHEM kernel: [132761.651344] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:51 FHEM kernel: [132762.649541] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:52 FHEM kernel: [132763.661624] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:53 FHEM kernel: [132764.661741] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:54 FHEM kernel: [132765.665868] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:54 FHEM kernel: [132765.668845] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:56 FHEM kernel: [132767.668137] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:57 FHEM kernel: [132768.672269] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:58 FHEM kernel: [132769.676401] Bluetooth: hci0 advertising data length corrected
Mar 28 08:52:58 FHEM kernel: [132769.679380] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:00 FHEM kernel: [132771.692726] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:01 FHEM kernel: [132772.694797] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:02 FHEM kernel: [132773.691935] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:03 FHEM kernel: [132774.702076] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:04 FHEM kernel: [132775.711209] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:05 FHEM kernel: [132776.719340] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:06 FHEM kernel: [132777.724476] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:07 FHEM kernel: [132778.729607] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:08 FHEM kernel: [132779.734742] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:09 FHEM kernel: [132780.741883] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:09 FHEM lepresenced[10518]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -58/-69, difference: 11, affected clients: 1.
Mar 28 08:53:09 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, age: 0, max age: 120, rssi: -69, result: present.
Mar 28 08:53:10 FHEM kernel: [132781.752061] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:11 FHEM kernel: [132782.754152] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:12 FHEM kernel: [132783.764278] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:13 FHEM kernel: [132784.770409] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:14 FHEM kernel: [132785.773540] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:15 FHEM kernel: [132786.773678] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:16 FHEM kernel: [132787.775813] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:16 FHEM kernel: [132787.778790] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:18 FHEM kernel: [132789.789086] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:23 FHEM kernel: [132794.807742] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:23 FHEM lepresenced[10518]: [tid:0] main: Mac address xx:xx:xx:xx:xx:xx needs update due to changed rssi. Old/new rssi: -69/-80, difference: 11, affected clients: 1.
Mar 28 08:53:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, age: 0, max age: 120, rssi: -80, result: present.
Mar 28 08:53:24 FHEM kernel: [132795.818876] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:26 FHEM kernel: [132797.824133] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:27 FHEM kernel: [132798.827280] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:28 FHEM kernel: [132799.827424] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:29 FHEM kernel: [132800.830537] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:32 FHEM kernel: [132803.849947] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:33 FHEM kernel: [132804.853069] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:35 FHEM kernel: [132806.861366] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:36 FHEM kernel: [132807.869541] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:38 FHEM kernel: [132809.883798] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:40 FHEM kernel: [132811.893029] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:42 FHEM kernel: [132813.910291] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:44 FHEM kernel: [132815.922553] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:45 FHEM kernel: [132816.928687] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:46 FHEM kernel: [132817.930816] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:48 FHEM kernel: [132819.935245] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:50 FHEM kernel: [132821.945366] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:52 FHEM kernel: [132823.953623] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:56 FHEM kernel: [132827.976154] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:56 FHEM kernel: [132827.979133] Bluetooth: hci0 advertising data length corrected
Mar 28 08:53:59 FHEM kernel: [132830.984559] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:00 FHEM kernel: [132831.983694] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:01 FHEM kernel: [132832.988841] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:03 FHEM kernel: [132835.003109] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:04 FHEM kernel: [132836.007234] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:04 FHEM kernel: [132836.010210] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:05 FHEM kernel: [132837.011364] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:06 FHEM kernel: [132838.007493] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:07 FHEM kernel: [132839.018636] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:08 FHEM kernel: [132840.025804] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:10 FHEM kernel: [132842.041072] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:15 FHEM kernel: [132847.070720] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:39 FHEM kernel: [132871.175914] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:42 FHEM kernel: [132874.199375] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:43 FHEM kernel: [132875.206478] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:44 FHEM kernel: [132876.207628] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:44 FHEM kernel: [132876.210572] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:46 FHEM kernel: [132878.224866] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:51 FHEM kernel: [132882.247400] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:51 FHEM kernel: [132882.250383] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:52 FHEM kernel: [132883.248541] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:53 FHEM kernel: [132884.251677] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:55 FHEM kernel: [132886.263037] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:56 FHEM kernel: [132887.267083] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:57 FHEM kernel: [132888.270235] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:58 FHEM kernel: [132889.276349] Bluetooth: hci0 advertising data length corrected
Mar 28 08:54:59 FHEM kernel: [132890.283507] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:01 FHEM kernel: [132892.293742] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:03 FHEM kernel: [132894.299013] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:04 FHEM kernel: [132895.301152] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:05 FHEM kernel: [132896.300310] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:07 FHEM kernel: [132898.308535] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:08 FHEM kernel: [132899.320684] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:11 FHEM kernel: [132902.327098] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:12 FHEM kernel: [132903.333219] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:14 FHEM kernel: [132905.355479] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:17 FHEM kernel: [132908.365879] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:19 FHEM kernel: [132910.383184] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:21 FHEM kernel: [132912.396457] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:23 FHEM kernel: [132914.404691] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, age: 0, max age: 120, rssi: -85, result: present.
Mar 28 08:55:25 FHEM kernel: [132916.408962] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:26 FHEM kernel: [132917.417092] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:27 FHEM kernel: [132918.421232] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:28 FHEM kernel: [132919.424372] Bluetooth: hci0 advertising data length corrected
Mar 28 08:55:32 FHEM kernel: [132923.444901] Bluetooth: hci0 advertising data length corrected
Mar 28 08:57:11 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 2 (min/max age: 99/149)
Mar 28 08:57:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, age: 111, max age: 120, rssi: -86, result: present.
Mar 28 08:59:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 08:59:56 FHEM lepresenced[10518]: [tid:0] main::cleanup_task: Cleanup finished, deleted 0 devices in 0 seconds.
Mar 28 09:01:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:02:12 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 2 (min/max age: 400/450)
Mar 28 09:03:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:05:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:07:13 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 2 (min/max age: 701/751)
Mar 28 09:07:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:09:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:11:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:12:14 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 2 (min/max age: 1002/1052)
Mar 28 09:13:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:14:57 FHEM lepresenced[10518]: [tid:0] main::cleanup_task: Cleanup finished, deleted 0 devices in 0 seconds.
Mar 28 09:15:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:17:15 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 2 (min/max age: 1303/1353)
Mar 28 09:17:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:19:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:21:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:22:16 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 2 (min/max age: 1604/1654)
Mar 28 09:23:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:25:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:27:17 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 2 (min/max age: 1905/1955)
Mar 28 09:27:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:29:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:29:58 FHEM lepresenced[10518]: [tid:0] main::cleanup_task: Deleting device 5f:f8:4c:52:ec:d9.
Mar 28 09:29:58 FHEM lepresenced[10518]: [tid:0] main::cleanup_task: Deleting device xx:xx:xx:xx:xx:xx.
Mar 28 09:29:58 FHEM lepresenced[10518]: [tid:0] main::cleanup_task: Cleanup finished, deleted 2 devices in 0 seconds.
Mar 28 09:31:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:32:18 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 09:33:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:35:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:37:19 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 09:37:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:39:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:41:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:42:20 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 09:43:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:44:59 FHEM lepresenced[10518]: [tid:0] main::cleanup_task: Cleanup finished, deleted 0 devices in 0 seconds.
Mar 28 09:45:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:47:21 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 09:47:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:49:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:51:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:52:22 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 09:53:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:55:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:57:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 09:57:23 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 09:59:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:00:00 FHEM lepresenced[10518]: [tid:0] main::cleanup_task: Cleanup finished, deleted 0 devices in 0 seconds.
Mar 28 10:01:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:02:24 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 10:03:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:05:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:07:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:07:25 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 10:09:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:11:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:12:26 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 10:13:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:15:01 FHEM lepresenced[10518]: [tid:0] main::cleanup_task: Cleanup finished, deleted 0 devices in 0 seconds.
Mar 28 10:15:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:17:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:17:27 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 10:19:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:21:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:22:28 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 10:23:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:25:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:27:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:27:29 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 10:29:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:30:02 FHEM lepresenced[10518]: [tid:0] main::cleanup_task: Cleanup finished, deleted 0 devices in 0 seconds.
Mar 28 10:31:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:32:30 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 10:33:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:35:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:37:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:37:31 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 10:39:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:41:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:42:32 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 10:43:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:45:03 FHEM lepresenced[10518]: [tid:0] main::cleanup_task: Cleanup finished, deleted 0 devices in 0 seconds.
Mar 28 10:45:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:47:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:47:33 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 28 10:49:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.

Mar 28 10:51:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, age: 117, max age: 120, rssi: -86, result: present.

Mar 28 10:52:34 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 2 (min/max age: 188/188)
Mar 28 10:53:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:55:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:57:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 10:57:35 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 2 (min/max age: 489/489)
Mar 28 10:59:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 11:00:04 FHEM lepresenced[10518]: [tid:0] main::cleanup_task: Cleanup finished, deleted 0 devices in 0 seconds.
Mar 28 11:01:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 11:02:36 FHEM lepresenced[10518]: [tid:0] main::stats_task: Active clients: 1, known devices: 3 (min/max age: 23/790)
Mar 28 11:03:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 11:05:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 28 11:07:23 FHEM lepresenced[10518]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.

CoolTux · 28 März 2017, 15:53:41

Interessant. Du bist schon der zweite mit dieser Beobachtung. Desweiteren fällt auf das der rssi Wert der selbe ist wie beim absent.

FunkOdyssey · 28 März 2017, 18:02:25

Hmm. Irgendwie beruhigend, aber andererseits auch total Mist.

Ich habe übrigens folgenden Dongle: Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

CoolTux · 28 März 2017, 18:31:24

Hast Du noch etwas anderes ausser lepresenced am laufen?

isy · 28 März 2017, 18:36:33

Zitat von: CoolTux am 28 März 2017, 18:31:24
Hast Du noch etwas anderes ausser lepresenced am laufen?

......vor allem einen weiteren Dienst über den selben Bluetooth Dongle am Fhem Server

Gruß Helmut

CoolTux · 28 März 2017, 19:09:58

Ich gehe davon aus das eventuell noch dieser collectored oder wie der heißt läuft

PatrickR · 28 März 2017, 20:58:39

Mahlzeit!

Das ist ja mysteriös. Wie oft tritt das auf? Wenn es regelmäßiger aufträte könntest Du zum Vergleich mal den Legacy-Modus (der nutzt hcitool lescan und nicht hcidump) testen und schauen, ob es noch passiert.

/Edit:
Der Collectord kann übrigens nicht schuld sein. lepresenced outet sich ja im Syslog.

Patrick

FunkOdyssey · 28 März 2017, 21:31:31

Im Zuge der Inbetriebnahme habe ich folgende Pakete auf meinen Raspberry Pi 2 installiert:

Code Auswählen


apt-get install bluetooth bluez blueman
apt-get install pi-bluetooth
apt-get install libnet-server-coro-perl
apt-get install bc
dpkg -i lepresenced-0.8-1.deb

"pi-blueooth" und "bc" habe ich jetzt gerade wieder runtergeschmissen.
Ansonsten ist mir nicht bekannt, dass ich andere Dienste einsetze. Hat jemand eine Idee wie ich das sicherstellen kann?
collectord läuft bei mir nicht.
Der Fehler tritt täglich nach dem "absent" auf. Aber die Zeitabstände sind unterschiedlich.

Ich habe außerdem noch die Datei /lib/systemd/system/bluetooth.service modifiziert:

Code Auswählen

ExecStart=/usr/lib/bluetooth/bluetoothd --noplugin=sap

FunkOdyssey · 29 März 2017, 14:22:29

Kurzer Zwischenstand:

Zitat von: FunkOdyssey am 28 März 2017, 21:31:31

"pi-blueooth" und "bc" habe ich jetzt gerade wieder runtergeschmissen.

Ich zitiere mich mal selbst. Ich bin noch ein wenig vorsichtig mit der Euphorie, aber heute ist mein G-Tag nicht plötzlich wieder anwesend gewesen. Ob das nun nur eine Ausnahme war oder durch die Deinstallation der beiden Pakete erzeugt wurde, ist mir noch nicht bekannt.

Ich warte mal die nächsten Tage ab und halte euch auf dem laufenden.

Jojo11 · 29 März 2017, 17:33:08

Hallo,

dann bin ich wohl der Zweite mit diesem Problem

Kurz zu meinem System:
1) Raspberry Pi 3 mit onboard BT und lepresenced und collectord
2) Raspberry Pi 2 mit BT dongle (CSL) und lepresenced
3) Raspberry Pi 2 mit BT dongle (Inateck) und lepresenced
3x G-TAG
Ansonsten keine BT-Anwendung.

Das zufällige anwesend-Detektieren ist bei mir erst 2x aufgetreten. Detaillierte Log-Nachrichten habe ich noch nicht. Im sys-log des RPi3 findet sich nur

Code Auswählen


kernel: [1353807.813177] Bluetooth: hci0 advertising data length corrected

...was ich seit gestern mit dem hier irgendwo beschriebenen "Trick" unterdrücke.

Ich bin mir unsicher, aber evtl. könnte mein zweites "Problem" damit zu tun haben:
Fast immer wenn nach Abwesenheit aller Tags einer wieder nach Hause kommt, werden die anderen (manchmal keiner, manchmal einer, manchmal beide) ebenfalls kurz als anwesend erkannt, obwohl sie nicht in der Nähe sind.

Jetzt schaue ich mir mal LOG_DEBUG an.

schöne Grüße
Jo

PatrickR · 29 März 2017, 21:58:35

Hi!

Zitat von: FunkOdyssey am 28 März 2017, 14:30:18
Syslog (LOG_DEBUG)

Kann das sein, dass mehrere Geräte im Log sind? Falls ja kannst Du das nochmal so anonymisieren, dass man die macs unterscheiden kann?

Danke!

Patrick

FunkOdyssey · 29 März 2017, 22:12:36

Hallo, im Log ist und war nur ein Gerät vorhanden.

FunkOdyssey · 30 März 2017, 14:23:45

Ach, schade. Doch zu früh gefreut. Der Fehler ist mittlerweile wieder aufgetreten:

Code Auswählen


2017-03-30_09:05:59 gtag1 rssi: -63
2017-03-30_09:07:25 gtag1 rssi: -74
2017-03-30_09:08:12 gtag1 rssi: -86
2017-03-30_09:12:12 gtag1 absent
2017-03-30_09:12:12 gtag1 presence: absent
2017-03-30_09:12:12 gtag1 rssi: unreachable
2017-03-30_11:16:12 gtag1 present
2017-03-30_11:16:12 gtag1 presence: present
2017-03-30_11:16:12 gtag1 rssi: -87
2017-03-30_11:18:12 gtag1 absent
2017-03-30_11:18:12 gtag1 presence: absent
2017-03-30_11:18:12 gtag1 rssi: unreachable

Code Auswählen

Mar 30 11:04:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 30 11:04:16 FHEM lepresenced[419]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 30 11:06:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 30 11:08:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 30 11:09:17 FHEM lepresenced[419]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)
Mar 30 11:10:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 30 11:12:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 30 11:14:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 30 11:14:18 FHEM lepresenced[419]: [tid:0] main::stats_task: Active clients: 1, known devices: 0 (min/max age: %/%)

Mar 30 11:16:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, age: 91, max age: 120, rssi: -87, result: present.

Mar 30 11:17:01 FHEM CRON[6525]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Mar 30 11:17:47 FHEM lepresenced[419]: [tid:0] main::cleanup_task: Cleanup finished, deleted 0 devices in 0 seconds.
Mar 30 11:18:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 30 11:19:19 FHEM lepresenced[419]: [tid:0] main::stats_task: Active clients: 1, known devices: 2 (min/max age: 278/278)
Mar 30 11:20:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 30 11:22:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 30 11:24:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 30 11:24:20 FHEM lepresenced[419]: [tid:0] main::stats_task: Active clients: 1, known devices: 2 (min/max age: 579/579)
Mar 30 11:26:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.
Mar 30 11:28:12 FHEM lepresenced[419]: [tid:0] main: Sending update for mac address xx:xx:xx:xx:xx:xx, max age: 120, result: absence.

PatrickR · 30 März 2017, 17:25:42

Mahlzeit!

Nachdem ich mir nochmal den Code angesehen habe, gehe ich davon aus, dass - aus welchem Grund auch immer - tatsächlich ein derartiges Beacon empfangen wird. Meine Hoffnung, dass ich die faulen Beacons irgendwie an Hand der Ausgabe von hcidump identifizieren und ausfiltern könnte, hat sich nicht bewahrheitet. Etwaige Prüfsummen (diverse Dokumente verweisen auf CRC) finde ich weder in der (aufbereiteten) Ausgabe von hcidump noch in Wireshark.

Wenn man sich die Logs von Euch so ansieht, fällt auf, dass das Alter bei den unerwünschten "presents" eher hoch ist (91 Sekunden, 117 Sekunden). Da die G-Tags im Normalbetrieb in sehr kurzen Abständen senden, spricht das dafür, dass die unerwünschten Beacons nur einzeln auftreten. Wenn sich nicht noch ein Bluetooth-Experte mit dem rettenden Tipp findet würde ich lepresenced so anpassen, dass Einzelbeacons verworfen werden.

@CoolTux hattest Du nicht einen Bluetooth-Gott an der Hand?

Patrick

CoolTux · 30 März 2017, 18:21:23

Hallo Patrick,

Sagen wir der Kollege hat sich intensiv mit dem Thema beschäftigt und sich durch diverse Dokumente gewühlt.
Kann ja mal schauen ob ich Jörg ins Themenboot bekomme.

Grüße

FunkOdyssey · 30 März 2017, 18:24:43

Zitat von: PatrickR am 30 März 2017, 17:25:42
Nachdem ich mir nochmal den Code angesehen habe, gehe ich davon aus, dass - aus welchem Grund auch immer - tatsächlich ein derartiges Beacon empfangen wird. Meine Hoffnung, dass ich die faulen Beacons irgendwie an Hand der Ausgabe von hcidump identifizieren und ausfiltern könnte, hat sich nicht bewahrheitet. Etwaige Prüfsummen (diverse Dokumente verweisen auf CRC) finde ich weder in der (aufbereiteten) Ausgabe von hcidump noch in Wireshark.

Wenn man sich die Logs von Euch so ansieht, fällt auf, dass das Alter bei den unerwünschten "presents" eher hoch ist (91 Sekunden, 117 Sekunden). Da die G-Tags im Normalbetrieb in sehr kurzen Abständen senden, spricht das dafür, dass die unerwünschten Beacons nur einzeln auftreten. Wenn sich nicht noch ein Bluetooth-Experte mit dem rettenden Tipp findet würde ich lepresenced so anpassen, dass Einzelbeacons verworfen werden.

Danke, dass du dich darum kümmerst. Kann ich bzgl. der maxAge-Parameters denn irgendwie Einfluss auf die Fehlerkennung nehmen? Im Define den Intervall erhöhen oder besser noch reduzieren auf 60 Sekunden?

Ich verstehe nicht woher das "Beacon" herkommen soll. Das kann doch nur am Dongle, im Treiber oder ähnliches liegen, oder?

Ich hätte kein Problem damit, mir einen anderen Dongle zu kaufen.

Ich könnte auch die Installation von lepresenced auf einem autarkem Raspberry B+ vornehmen. Ich kann ja in FHEM die IP entsprechend angeben.

(Auf meine Rasperry B 2 habe derzeit das aktuellste Jessie.)

PatrickR · 30 März 2017, 18:52:02

Zitat von: FunkOdyssey am 30 März 2017, 18:24:43
Danke, dass du dich darum kümmerst. Kann ich bzgl. der maxAge-Parameters denn irgendwie Einfluss auf die Fehlerkennung nehmen? Im Define den Intervall erhöhen oder besser noch reduzieren auf 60 Sekunden?

Nee das bringt nichts solange ein Beacon ausreicht... Mit einem kürzeren Intervall hättest Du nur den Vorteil, dass das erlösende "absent" schneller kommt.

Zitat von: FunkOdyssey am 30 März 2017, 18:24:43
Ich verstehe nicht woher das "Beacon" herkommen soll. Das kann doch nur am Dongle, im Treiber oder ähnliches liegen, oder?

Oder es fliegt durch die Luft. Wir sind ja im ISM-Band nicht allein mit unseren brüllenden G-Tags. Dafür würde auch sprechen, dass das Problem so selten auftritt, bei mir mit 3 Tags über mehrere Monate z. B. noch garnicht.

Zitat von: FunkOdyssey am 30 März 2017, 18:24:43
Ich hätte kein Problem damit, mir einen anderen Dongle zu kaufen.

Ich könnte auch die Installation von lepresenced auf einem autarkem Raspberry B+ vornehmen. Ich kann ja in FHEM die IP entsprechend angeben.

(Auf meine Rasperry B 2 habe derzeit das aktuellste Jessie.)

Interessant wäre natürlich mal eine Testreihe mit mehren nebeneinanderstehenden Pis mit jeweils anderen Bluetooth-Sticks. Aber kaufen würde ich jetzt nichts.

Wie gesagt als letzte Lösung kann ich immer noch lepresenced filtern lassen. Aber spannender wäre natürlich, zu erfahren, woran es wirklich liegt.

Patrick

Brause · 30 März 2017, 19:17:07

Eventuell kenne ich eine solche Störquelle persönlich.

Aus welchem Grund auch immer sendet mein LG G4 (US-Version) einen LE-Beacon mit sich in unterschiedlichen Intervallen willkürlich ändernder MAC-Adressen.
Bisher habe ich kein System hinter den Änderungen gefunden. Beobachte es auch nicht aktiv.
Hatte es mir ehrlich gesagt nur mal knapp eine Stunde angeschaut, in der Hoffnung, ich kann es als Anwesenheitskontrolle nutzen.

Laut Heise MAC-Datenbank sind die MAC-Adressen auch nicht zwingend LG zugeordnet.

DeeSPe · 30 März 2017, 19:21:51

Zitat von: Brause am 30 März 2017, 19:17:07
Eventuell kenne ich eine solche Störquelle persönlich.

Aus welchem Grund auch immer sendet mein LG G4 (US-Version) einen LE-Beacon mit sich in unterschiedlichen Intervallen willkürlich ändernder MAC-Adressen.
Bisher habe ich kein System hinter den Änderungen gefunden. Beobachte es auch nicht aktiv.
Hatte es mir ehrlich gesagt nur mal knapp eine Stunde angeschaut, in der Hoffnung, ich kann es als Anwesenheitskontrolle nutzen.

Laut Heise MAC-Datenbank sind die MAC-Adressen auch nicht zwingend LG zugeordnet.

Ich glaube das ist nicht nur LG spezifisch.
Gab es da nicht mal was dass einige Geräte random BT Beacons senden damit die nicht von z.B. Reklametafeln getrackt werden können!?

Das iPhone macht das meines Wissens auch. Wenn man aber die echte Adresse kennt, ist das kein Problem bei der Erkennung.
Bei einer Anwesenheitserkennung kann es aber tatsächlich zum Problem werden.

Gruß
Dan

KernSani · 30 März 2017, 20:36:10

Beobachte seit gestern das selbe Verhalten... einer meiner 4 Gtags ist immer mal wieder present, obwohl eigentlich weg. Bei den anderen Dreien (die schon älter sind) ist alles normal...

PatrickR · 01 April 2017, 15:41:14

Mahlzeit!

Hier mal Version 0.81 zum Testen.

lepresenced merkt sich jetzt nicht nur den Timestamp des letzten Beacons sondern auch den des vorletzten. Für Present müssen beide innerhalb des eingestellten Intervalls liegen.

Patrick

Jojo11 · 02 April 2017, 07:42:25

Danke! Werde ich die kommenden Tage mal testen.

Schöne Grüße
Jo

FunkOdyssey · 05 April 2017, 10:35:20

Ich habe die Änderungen erst Montag Abend aktiviert und konnte erst zwei/drei längerfristige Abwesenheiten testen.
Bisher aber erfolgreich. Ich konnte noch keine Fehlerkennung feststellen. Ich behalte das weiter im Auge.

Zitat von: PatrickR am 01 April 2017, 15:41:14
Mahlzeit!

Hier mal Version 0.81 zum Testen.

lepresenced merkt sich jetzt nicht nur den Timestamp des letzten Beacons sondern auch den des vorletzten. Für Present müssen beide innerhalb des eingestellten Intervalls liegen.

Patrick

Wenn nun also zwei Erkennung innerhalb des Intervalls liegen müssen (also eine Art presenceThreshold?), wie oft findet dann die Abfrage statt?

Mein Intervall liegt nun bei 60 Sekunden. Also muss in dieser Zeit zweimal das G-Tag gefunden werden. Wie oft wird denn geprüft? Das habe ich noch irgendwie nicht verstanden.

Danke für dein Fix.

PatrickR · 05 April 2017, 11:01:05

Hi!

Zitat von: FunkOdyssey am 05 April 2017, 10:35:20
Wenn nun also zwei Erkennung innerhalb des Intervalls liegen müssen (also eine Art presenceThreshold?), wie oft findet dann die Abfrage statt?
Mein Intervall liegt nun bei 60 Sekunden. Also muss in dieser Zeit zweimal das G-Tag gefunden werden. Wie oft wird denn geprüft? Das habe ich noch irgendwie nicht verstanden.

lepresenced prüft nicht aktiv sondern lauscht dauerhaft mit. Meine G-Tags senden etwa 1x pro Sekunde, d. h. mein Fix könnte allenfalls problematisch werden, wenn Du sehr kurz scannst, z. B. 2 Sekunden

Wenn Du den Log level auf LOG_DEBUG hochschraubst kannst Du sehen, wie alt das letzte und vorletzte Beacon ist, bei mir i. d. R. 0-2 Sekunden.

Patrick

FunkOdyssey · 05 April 2017, 12:07:22

Danke für die Erläuterung. Das wir neu. Wobei das eigentlich sogar logisch sein sollte.

Jamo · 05 April 2017, 12:50:43

Hi Patrick,
ich habe die letzte Version mit dem Fix auch installiert, und bei mir läufts bisher auch problemlos seit 3 Tagen. Danke!

Jojo11 · 05 April 2017, 21:39:35

Hallo,

auch ich habe den Fix jetzt auf den 3 PIs installiert und habe seitdem keine Fehlauslösungen mehr. Vielen Dank schon mal dafür!
Ich werde auch weiter beobachten

schöne Grüße
Jo

PatrickR · 05 April 2017, 22:57:37

Freut mich zu hören! Wobei mich doch interessieren würde, wo die Geisterbeacons herkommen.

Von unterwegs gesendet.

Jojo11 · 21 April 2017, 20:06:27

Eine Sache ist mir noch aufgefallen. Passt evtl nicht 100% hier hin. Wenn der Status auf absent springt, bleibt im reading rooms noch ein Raum (ich denke der letzte, in dem der tag gesehen wurde) stehen. Könnte man das reading bei absent nicht löschen? Würde bei der Visualisierung erheblich helfen

Schöne Grüße
Jo

peterk_de · 21 April 2017, 20:31:18

@JoJo ich wäre auch dafür, das Reading room in dem Fall dann auf "none" o.ä. zu setzen, denn aktuell ist es nicht konsistent, da das Reading nicht den aktuellen Raum anzeigt, sondern den, in dem der Beacon zuletzt emofangen wurde (müsste aktuell also eher "lastRoom" oder so heißen) Aber ich bin nicht dafür, das gabze Reading zu löschen das gibt wieder ganz andere Probleme

Jojo11 · 21 April 2017, 21:09:04

"none" wäre für mich auch ok. Kann man mit arbeiten

Schöne Grüße
Jo

PatrickR · 21 April 2017, 22:00:21

Sorry, aber das ist wirklich off-topic. Collectord-Themen wird Markus hier auch nicht finden...

Von unterwegs gesendet.

PatrickR · 22 April 2017, 00:55:36

Guten Abend!

Habe Version 0.81 inkl. DEB-Paket eingecheckt.

Patrick

Jojo11 · 22 April 2017, 20:02:05

Zitat von: PatrickR am 21 April 2017, 22:00:21
Sorry, aber das ist wirklich off-topic. Collectord-Themen wird Markus hier auch nicht finden...

Von unterwegs gesendet.

Ok, hier gehts weiter: https://forum.fhem.de/index.php/topic,70954.0.html

schöne Grüße
Jo

forum-merlin · 09 September 2017, 09:30:04

Hallo Zusammen,

ich habe das Problem auch, dass lepresenced mit G-Tags immer mal wieder "present" sind, obwohl das nicht möglich ist.

Hintergrund:
Ich mache mit den G-Tags logischer Weise Anwesenheitsprüfung. Dies verwende ich auch für die Alarmanlage.
Ich lasse mir und meiner Frau per Telegram den Anwesenheitsstatus, und den Alarmstatus aufs Handy schicken.

Es kommt immer mal wieder vor, (mindestens 2x / Woche) dass scheinbar eine presence erkannt wird, obwohl niemand Daheim ist.
Da meine Frau und ich zusammen arbeiten saßen wir schon gemeinsam am Tisch, und auf einmal bekamen wir beide die Telegram Message dass jemand daheim sei.
Die AL wurde ausgeschaltet, und nach ca. 4 minuten (das liegt am pinginterval und dem absenceThresholdCounter) war wieder NIEMAND present, und die AL wurde wieder eingschaltet.
Ich habe schon echt viel versucht zu loggen aber ich komme nicht drauf was das sein kann.

Ich kenne mich aber auch nicht aus wie lange so ein signal eines G-Tags so rumschwirren kann.
Ich würde ja sagen, dass das nur solange rumschwirren kann wie der G-Tag in rechweite ist, aber nicht über Stunden wie eine SMS die vom Server geschickt wird und erst als zugestellt zählt wenn der client es empfangen hat.
Es ist ja uni-direktionaler Funk und nicht bidirektional mit Rückkanal/Rückmeldung oder?

Infrastructure Konstellation:
RasPi3 (on Board BT) lepresenced 0.83-3 (seit heute, vorher 0.6)
RasPi1 (BT Stick) lepresenced 0.8
RasPi2 (BT Stick) lepresenced 0.82-1
KEIN COLLECTORD

Ich lese auf allen drei Pi den Status, und schreibe per DOIF den Status in einen DUMMY und der DUMMY wird dann wiederum durch andere DOIF für die Telegram Messages und AL Status-Schaltung ausgewertet.

Kann mir jemand helfen?
Hat jemand eine Idee was das sein kann?

Danke und Gruß

Holger

PatrickR · 09 September 2017, 11:25:37

@Holger: Gehe ich richtig in der Annahme, dass ein present von einem Deiner Geräte ausreicht, um die Alarmanlage zu deaktivieren?
Falls ja: Update mal alle lepresenceds mindestens auf 0.81 - Nach Deiner Aufstellung oben sollte das den RasPi1 betreffen. Seit 0.81 sind mindestens zwei Beacons (statt einem) im Intervall nötig, um auf present zu springen. (siehe weiter oben in diesem Thread).

Patrick

Von unterwegs gesendet.