lepresenced: Neue Testversion (lepresenced0.93dev21)

[MadMax-FHEM]

Ja nur mehr die beiden...

https://forum.fhem.de/index.php/topic,113620.msg1086494.html#msg1086494

Gab mal nen Thread bzgl. Einheitlichkeit und da wurde angeglichen...

Gruß, Joachim

[TL]

Moin!

Hi!

Hat jemand Lust, das neue Package zu testen? (0.93 ist identisch zur 0.93dev21).

Grüße
Patrick

Läuft bei mir jetzt auch seit ein paar Tagen einwandfrei.
Grüße  TL

[gestein]

Hallo,

ich habe mir gestern einen neuen Raspberry Zero W komplett neu aufgesetzt und lepresenced (0.93dev21) installiert.
Nach dem Einbinden mittels collectord funktioniert zusammen mit meinen Gtags seit 3 Tagen alles perfekt - auch keine rätselhaften "absence" nach einer Stunde mehr und das mit dem internen Bluetooth-Modul.
Danke!

Einzig, dass mein Gtag immer einen BatteryLevel von 100% meldet, ist eigenartig.
Immerhin habe ich den schon seit einem Jahr.
Das muss ich mir also noch anschauen.

Lg, Gerhard

[gestein]

Hallo,

meine Konfiguration mit lepresenced und collectord läuft nun seit ein paar Tagen und die Gtags werden wirklich toll als present oder absent angezeigt.
Keine Fehler mehr.

Allerdings funktioniert die Batterieabfrage nicht zuverlässlich.
Manche Gtags melden immer 100%, manche realistische Werte (bis runter auf 26%).

syslog-Einträge für die Gtags, bei denen der Batterie-Level zu stimmen scheint:

Code Auswählen Erweitern

Oct  7 10:12:34 fhem2 lepresenced[560]: [tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:99:d9:a8, address type: 'public'): 'handle: 0x001b #011 value: 1a '
Oct  7 10:12:34 fhem2 lepresenced[560]: [tid:0] main::battery_task: Battery level for mac 7c:2f:80:99:d9:a8 is 26.


Und bei einem der immer 100% zeigt:

Code Auswählen Erweitern

Oct  7 04:12:20 fhem2 lepresenced[560]: [tid:0] main::get_battery_level: gatttool (mac: 58:9e:c6:0e:ec:ad, address type: 'public'): 'handle: 0x001b #011 value: 64 '
Oct  7 04:12:20 fhem2 lepresenced[560]: [tid:0] main::battery_task: Battery level for mac 58:9e:c6:0e:ec:ad is 100.
Oct  7 10:12:30 fhem2 lepresenced[560]: [tid:0] main::get_battery_level: gatttool (mac: 58:9e:c6:0e:ec:ad, address type: 'public'): 'connect error: Function not implemented (38)'
Oct  7 10:12:30 fhem2 lepresenced[560]: [tid:0] main::battery_task: Battery level for mac 58:9e:c6:0e:ec:ad is unknown.

D.h., einmal liefert der Gtag anscheinend 100% zurück, bei der nächsten Abfrage kommt eigenartigerweise ein Fehler.
Heißt das, dass mein Gtag kaputt ist oder muss ich den irgendwie anlernen (oder so was)?

Danke im Voraus
lg, Gerhard

[MadMax-FHEM]

Hmmm, seit "Umstieg" auf die aktuelle Version mit den "angepassten" (bzgl. "Einheitlichkeit") Batterie-Readings habe ich auch 100%...
...zuvor (im "alten" Reading nur noch 94%): https://forum.fhem.de/index.php/topic,113620.msg1086494.html#msg1086494

Bzgl. Fehler habe ich noch nicht geschaut...
...mal sehen.

Gruß, Joachim

[JWRu]

Bei mir stimmen die Batteriewerte mit den alten Werten von BleTagBattery überein (17 bzw. 28%).

[MadMax-FHEM]

Kommando zurück...

Habe eben nachgesehen: bei mir hat es sich der neue Wert auch anders überlegt und zeigt nun ebenso wie der alte Wert an: 94

SORRY!
(aber ich kucke ja nicht täglich auf den Batteriewert   )

Gruß, Joachim

[gestein]

Ich habe gerade meinen Gtag händisch nach dieser Anleitung hier abgefragt:
http://blog.firszt.eu/index.php?post/2015/09/13/bt

Und leider meldet der Gtag auch hier 100%.
Da scheint also der Gtag was zu haben 

lg, Gerhard

[StephanFHEM]

Hab das neue Modul auf meinen paar PIs jetzt auch installiert und läuft super. Damit ist endlich kein extra Modul mehr erforderlich. Eine Bitte hätte ich noch:
Kannst du neben BatteryPercent auch BatteryState mit den Zuständen "low" und "ok" noch einführen? Zur Not kann ich mir die auch als UserReading basteln. Aber schöner wäre es über das Modul direkt. Das Reading wird so auch von anderen Modulen genutzt.

[MadMax-FHEM]

Hab das neue Modul auf meinen paar PIs jetzt auch installiert und läuft super. Damit ist endlich kein extra Modul mehr erforderlich. Eine Bitte hätte ich noch:
Kannst du neben BatteryPercent auch BatteryState mit den Zuständen "low" und "ok" noch einführen? Zur Not kann ich mir die auch als UserReading basteln. Aber schöner wäre es über das Modul direkt. Das Reading wird so auch von anderen Modulen genutzt.

Und ab wieviel Prozent wäre dann für dich low!?

Und: passt das für jeden (Typ von BLETag)?

Also mich würde es nicht stören, denke aber (Grund siehe "Einführung") ein userreading wäre "besser", dann kann jeder der es braucht (ich z.B. nicht) es anlegen und auch die Schwelle für low individuell festlegen...

Aber ich bin ja nicht der Developer, vielleicht sieht er das anders...

Gruß, Joachim

[hubiuwe]

Hallo
Ich hatte bis jetzt ein BLE-Script mit PRESENCE.
Seit 2 Wochen nutze ich die devel von lepresenced, bis jetzt ohne Probleme.
Zufällig kam der Umstieg mit einer schwächelnden G-TAG Batterie zusammen. .
Der G-TAG tat es zum Schluss gar nicht mehr "batteryPercent" =2 
Heute Batterie getauscht und jetzt "batteryPercent" =100.

Super Sache !!!

Mein System:
Linux PC, Fhem im DockerContainer, lepresenced läft auf Docker Host unter Ubuntu 2004.
Gruß

[FunkOdyssey]

Andere Projekte wie das monitor-Skript https://github.com/andrewjfreyer/monitor verlangen ein Pairing, um die RSSI-Werte anzuzeigen.

Du schaffst es, über lepresenced die RSSI-Werte auszulesen.
Und es ist doch richtig, dass die Beacons KEIN Pairing durchgeführt werden muss, oder?

[JWRu]

Wegen Problemen mit Bluetooth auf dem RasPi-Zero-W (siehe hier: https://forum.fhem.de/index.php/topic,115563.msg1098179.html#msg1098179)
habe ich den RasPi-Syslog durchforstet. Dabei finde ich in kurzen Abständen solche Meldungen:

Code Auswählen Erweitern

Nov  4 00:00:12 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:00:12 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:00:18 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:00:50 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:00:50 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:00:55 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:02:54 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:02:54 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:02:59 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:03:10 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:03:10 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:03:10 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:03:18 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:03:18 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:03:25 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:03:55 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:03:55 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:03:55 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:03:59 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:03:59 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:04:04 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:04:06 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:04:06 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:04:12 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:04:53 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2', telling hcidump and hcitool to restart...
Nov  4 00:04:53 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:04:53 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:04:56 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2', telling hcidump and hcitool to restart...

Was hat das zu bedeuten?

[JWRu]

Update
Ich habe das Problem nach einigem Rechercheaufwand wohl lösen können:
lepresenced braucht exklusiven Zugriff auf den Bluetooth-Adapter. Sowohl ein auf demselben Adapter laufendes presenced als auch XiaomiBTLESens-Devices
führen zu den im letzten Post beschriebenen Meldungen.
Ich habe jetzt den on-Board BT-Adapter aktiviert (glücklicherweise gibt es einen ganz frischen Bugfix für pi-bluetooth) und lasse presenced und die XiaomiBTLESens-Devices
auf diesem laufen. Die Meldungen sind jetzt verschwunden.

[MadMax-FHEM]

Zunächst mal: es läuft.

ABER:

wegen anderer Dinge hab ich mal das syslog durchsucht und dabei ist mir aufgefallen, dass dort alle (paar) Sekunde(n) folgendes geloggt wird

Code Auswählen Erweitern


Nov 24 13:23:03 raspi kernel: [146695.929516] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:04 raspi kernel: [146696.936607] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:06 raspi kernel: [146698.951956] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:08 raspi kernel: [146700.961915] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:09 raspi kernel: [146701.969413] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:10 raspi kernel: [146702.979829] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:11 raspi kernel: [146703.981950] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:12 raspi kernel: [146704.992591] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:13 raspi kernel: [146705.996961] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:14 raspi kernel: [146707.001346] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:15 raspi kernel: [146708.002074] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:16 raspi kernel: [146709.005158] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:17 raspi kernel: [146710.010025] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:18 raspi kernel: [146711.016461] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:20 raspi kernel: [146713.024206] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:22 raspi kernel: [146715.039571] Bluetooth: hci0: advertising data len corrected
Nov 24 13:23:24 raspi kernel: [146717.049721] Bluetooth: hci0: advertising data len corrected


dmesg sieht auch "übel" aus:

Code Auswählen Erweitern


[146910.021009] Bluetooth: hci0: advertising data len corrected
[146911.026049] Bluetooth: hci0: advertising data len corrected
[146913.027251] Bluetooth: hci0: advertising data len corrected
[146914.032800] Bluetooth: hci0: advertising data len corrected
[146915.032356] Bluetooth: hci0: advertising data len corrected
[146916.041719] Bluetooth: hci0: advertising data len corrected
[146917.047897] Bluetooth: hci0: advertising data len corrected
[146918.057288] Bluetooth: hci0: advertising data len corrected
[146919.055519] Bluetooth: hci0: advertising data len corrected
[146920.057201] Bluetooth: hci0: advertising data len corrected
[146921.063559] Bluetooth: hci0: advertising data len corrected
[146922.076883] Bluetooth: hci0: advertising data len corrected
[146923.085464] Bluetooth: hci0: advertising data len corrected
[146925.095493] Bluetooth: hci0: advertising data len corrected
[146927.108125] Bluetooth: hci0: advertising data len corrected
[146928.114214] Bluetooth: hci0: advertising data len corrected
[146929.122578] Bluetooth: hci0: advertising data len corrected
[146930.127001] Bluetooth: hci0: advertising data len corrected
[146931.137672] Bluetooth: hci0: advertising data len corrected
[146932.136041] Bluetooth: hci0: advertising data len corrected


Ich hab schon ein paar Threads dazu gefunden.
https://forum.fhem.de/index.php/topic,60163.0.html
bzw. dann weiter zu https://forum.fhem.de/index.php/topic,28753.msg499184/topicseen.html#msg499184

Da heißt es leider, dass da nichts dagegen gemacht werden kann...
...außer Log filtern.

Da der/die Threads schon recht alt sind wolte ich wissen, ob das immer noch der Stand ist (dass man außer filtern nichts tun kann) oder ob es sich beheben lässt...

Wie geschrieben: es tut (ist aber unschön)

Danke, Joachim