FHEM Forum

FHEM => Automatisierung => Thema gestartet von: mumpitzstuff am 27 Februar 2017, 21:29:50

Titel: Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 27 Februar 2017, 21:29:50
Mich hat es etwas frustriert, das es keine vernünftige Anzeige des Batteriestandes für BLE Tags gibt. Im Wiki oder Forum habe ich nur irgendwelche Skripte gefunden, die ich mir nur ungern mühsam installieren wollte. Ich habe deshalb ein sehr einfaches Modul geschrieben, das als Endanwender extrem einfach installiert werden kann und danach ohne weitere Konfiguration die BLE Tags absolut automatisch (alle 6h) um das Reading batteryLevel ergänzt.
Momentan werden lediglich die unten angegebenen Tags unterstützt, ich würde aber die Liste gern mit eurer Hilfe erweitern. Dazu benötige ist ein Listing eures Tags und wenn möglich die Information, mit welchem Gatttool Aufruf man bei diesem Tag den Zustand der Batterie auslesen kann.

Falls etwas nicht funktionieren sollte, dann aktiviert im device verbose 5 und schickt mir den relevanten Teil des Logfiles zu.

V0.0.3
BleTagBattery - Update batteryLevel for all BLE tags

This module can be used to update the Reading batteryLevel and battery  for all bluetooth low energy tags registered as PRESENCE devices.

Requirements:


Installation:

Usage:
The module automatically try to reach all BLE tags every 6 hours and to update the reading batteryLevel and battery for each tag directly within the tag device. You can manually trigger the update with: set <name of device> statusRequest.


Supported BLE tags:

GitHub: https://github.com/mumpitzstuff/fhem-BleTagBattery (https://github.com/mumpitzstuff/fhem-BleTagBattery)
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: binford6000 am 02 März 2017, 17:07:45
 
ZitatIm Wiki oder Forum habe ich nur irgendwelche Skripte gefunden, die ich mir nur ungern mühsam installieren wollte.

Hallo mumpitzstuff,
mir geht es genauso. Habe alle Scripts usw. ausprobiert aber leider ohne Erfolg.
Der gtag selbst arbeitet natürlich ohne Probleme!

Also ich habe alles installiert und eingerichtet und werde dann nachher sehen ob Dein Modul funktioniert.
Kann man das Intervall von 6h ändern? Vielleicht über ein attr? Alle 24h würde ja auch gebnügen  ;)

Mit
set <device> StatusRequest
kann ich ja auch ein Update erzwingen...

VG Sebastian
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: knopf_piano am 02 März 2017, 17:31:55
ich hab die response des gatttools per split den battLevel in ein userReading geschrieben.
das ganze erfolgt zyklisch alle 6h bei presence des devices, bzw bei absent->present. is bei mir ne kleine func in 99_myUtils in zusammenspiel mit dem notity/at.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 02 März 2017, 18:13:14
Ich habe den Zyklus 6h bewusst gewählt, ich kann aber auch ein Attribut hinzufügen. Aber Vorsicht bei 24h. Wenn man nicht den Zeitpunkt wählen kann, dann kann es passieren, das die Abfrage immer passiert wenn du auf Arbeit bist und du wirst gar nichts sehen.
Ich muss auch noch ein paar Hinweise geben, was im Zusammenspiel mit lepresenced zu beachten ist. Hier braucht man entweder einen zweiten Dongle ( beste Lösung) oder man bekommt eventuell Probleme ( kann auch gut gehen), da sich lepresenced und gatttool in die Quere kommen. Hier kann es helfen das Sleep im lepresenced deamon von 1 auf z.b. 2-5s zu erhöhen (direkt im Script editieren). 
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 02 März 2017, 18:18:46
Zitat von: knopf_piano am 02 März 2017, 17:31:55
ich hab die response des gatttools per split den battLevel in ein userReading geschrieben.
das ganze erfolgt zyklisch alle 6h bei presence des devices, bzw bei absent->present. is bei mir ne kleine func in 99_myUtils in zusammenspiel mit dem notity/at.

Ich habe keine Ahnung inwieweit solche Skripte blockierend aufgerufen werden oder nicht. Das Modul arbeitet nicht blockierend. Ich hab auch diverse Skripte gefunden, welche mal das und mal das erfordern oder nur mit Aufwand funktionieren (siehe wiki). Ich wollte deshalb mal alles unter einen Hut bringen und als klicki bunti Lösung anbieten.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: knopf_piano am 02 März 2017, 19:51:37
Passt, meins funzt, bin damit zufrieden. Ich schau mir deins mal an.
aber wie geschrieben wird bei mir der level auch bei absent->present eingeholt. Also zusätzlich zum zyklus. Schau mal ob du das auch abdecken kannst. Bin grad auf piste, also mehr oder weniger offline, kann nix anguggn oder probieren ;-)
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: binford6000 am 02 März 2017, 20:43:47
Also bei mir tut es leider nicht...

Hier das BleTagBattery Device:

Internals:
   CFGFN
   NAME       gtag_battery
   NR         812
   STATE      active
   TYPE       BleTagBattery
   VERSION    0.0.2
   Readings:
     2017-03-02 19:37:40   state           active
   Helper:
Attributes:
   alias      Batterie Status BLE-Geräte
   group      Anwesenheit
   icon       measure_battery_75
   room       Hardware
   verbose    5


Und hier der gtag selbst:

Internals:
   ADDRESS    7C:2F:80:98:AC:0F
   DEF        lan-bluetooth 7C:2F:80:98:AC:0F localhost:5333 60
   DeviceName localhost:5333
   FD         31
   MODE       lan-bluetooth
   NAME       Sebastian.gtag.PRE
   NOTIFYDEV  global
   NR         353
   NTFY_ORDER 50-Sebastian.gtag.PRE
   PARTIAL
   STATE      present
   TIMEOUT_NORMAL 60
   TIMEOUT_PRESENT 60
   TYPE       PRESENCE
   Readings:
     2017-03-02 20:33:49   device_name     Gigaset G-tag
     2017-03-02 20:33:49   presence        present
     2017-03-02 20:33:49   state           present
   Helper:
     CURRENT_STATE present
     CURRENT_TIMEOUT normal
Attributes:
   absenceThreshold 3
   alias      Sebastian's gtag
   devStateIcon present:status_available@green absent:control_building_empty@red
   group      Anwesenheit
   icon       gtag1
   room       Hardware


Im Log steht folgendes:

2017.03.02 20:35:08 4: Sub BleTagBattery_Run (gtag_battery) - start blocking call
2017.03.02 20:35:08 5: Sub BleTagBattery_stateRequest (gtag_battery) - state request called
2017.03.02 20:35:08 4: Sub BleTagBattery_BlockingRun (gtag_battery) - device found. device: Sebastian.gtag.PRE
2017.03.02 20:35:08 4: Sub BleTagBattery_BlockingRun (gtag_battery) - device name: Gigaset G-tag
2017.03.02 20:35:08 4: Sub BleTagBattery_BlockingRun (gtag_battery) - device address: 7C:2F:80:98:AC:0F
2017.03.02 20:35:08 4: Sub BleTagBattery_readSensorValue (gtag_battery) - call gatttool char read loop: 0, result: connect: Connection refused (111)
2017.03.02 20:35:08 4: Sub BleTagBattery_readSensorValue (gtag_battery) - call gatttool char read loop: 1, result: connect: Connection refused (111)
2017.03.02 20:35:08 4: Sub BleTagBattery_readSensorValue (gtag_battery) - call gatttool char read loop: 2, result: connect: Connection refused (111)
2017.03.02 20:35:08 4: Sub BleTagBattery_readSensorValue (gtag_battery) - call gatttool char read loop: 3, result: connect: Connection refused (111)
2017.03.02 20:35:08 4: Sub BleTagBattery_readSensorValue (gtag_battery) - call gatttool char read loop: 4, result: connect: Connection refused (111)
2017.03.02 20:35:08 4: Sub BleTagBattery_readSensorValue (gtag_battery) - call gatttool char read loop: 5, result: connect: Connection refused (111)
2017.03.02 20:35:08 4: Sub BleTagBattery_readSensorValue (gtag_battery) - call gatttool char read loop: 6, result: connect: Connection refused (111)
2017.03.02 20:35:08 4: Sub BleTagBattery_readSensorValue (gtag_battery) - call gatttool char read loop: 7, result: connect: Connection refused (111)
2017.03.02 20:35:08 4: Sub BleTagBattery_readSensorValue (gtag_battery) - call gatttool char read loop: 8, result: connect: Connection refused (111)
2017.03.02 20:35:08 4: Sub BleTagBattery_readSensorValue (gtag_battery) - call gatttool char read loop: 9, result: connect: Connection refused (111)
2017.03.02 20:35:08 4: Sub BleTagBattery_readSensorValue (gtag_battery) - invalid gatttool response
2017.03.02 20:35:08 4: Sub BleTagBattery_BlockingRun (gtag_battery) - processing gatttool response for device Sebastian.gtag.PRE. batteryLevel:
2017.03.02 20:35:09 4: Sub BleTagBattery_BlockingDone (gtag_battery) - set reading batteryLevel of device: Sebastian.gtag.PRE
2017.03.02 20:35:09 4: Sub BleTagBattery_BlockingDone (gtag_battery) - done


Ich meine mich erinnern zu können, dass das Script aus dem Anwesenheits-Wiki auch "Connection refused (111)" zurückgegeben hat...  :(

bluez 5.23-2+rpi2 läuft auf einem aktuellen debian jessie und rpi2.

VG Sebastian


Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Mumpitz am 02 März 2017, 22:27:45
Müssen vorgängig die alten Scripte deaktiviert oder etwas deinstalliert werden?
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 03 März 2017, 01:15:26
Es läuft eigentlich alles wunderbar bei dir, aber da scheint irgendwas den Dongle zu blockieren. Ich habe selbst 2 G-Tags und das Modul läuft dort einwandfrei, allerdings verwende ich 2 Bluetooth Dongles. Einen nur für lepresenced und den zweiten für die Abfrage der Batterie der G-Tags und meiner Pflanzensensoren.
Was hast du sonst noch auf deinem Bluetooth Dongle laufen? Zufällig lepresenced oder irgendwelche anderen Skripte die dauerhaft den Bluetooth Dongle blockieren z.b. mit: hcitool lescan?

So in etwa sollte es aussehen:

2017.03.03 01:03:32 4: Sub BleTagBattery_BlockingRun (BLETAG_BATTERY) - device found. device: GTAG_ABC
2017.03.03 01:03:32 4: Sub BleTagBattery_BlockingRun (BLETAG_BATTERY) - device name: Gigaset G-tag
2017.03.03 01:03:32 4: Sub BleTagBattery_BlockingRun (BLETAG_BATTERY) - device address: FF:EE:DD:CC:BB:AA
2017.03.03 01:03:39 4: Sub BleTagBattery_readSensorValue (BLETAG_BATTERY) - call gatttool char read loop: 0, result: connect error: Function not implemented (38)

2017.03.03 01:03:48 4: Sub BleTagBattery_readSensorValue (BLETAG_BATTERY) - call gatttool char read loop: 1, result: Characteristic value/descriptor: 64

2017.03.03 01:03:48 4: Sub BleTagBattery_readSensorValue (BLETAG_BATTERY) - processing gatttool response: 64
2017.03.03 01:03:48 4: Sub BleTagBattery_BlockingRun (BLETAG_BATTERY) - processing gatttool response for device GTAG_ABC. batteryLevel: 100
2017.03.03 01:03:48 4: Sub BleTagBattery_BlockingRun (BLETAG_BATTERY) - device found. device: GTAG_XYZ
2017.03.03 01:03:48 4: Sub BleTagBattery_BlockingRun (BLETAG_BATTERY) - device name: Gigaset G-tag
2017.03.03 01:03:48 4: Sub BleTagBattery_BlockingRun (BLETAG_BATTERY) - device address: AA:BB:CC:DD:EE:FF
2017.03.03 01:03:53 4: Sub BleTagBattery_readSensorValue (BLETAG_BATTERY) - call gatttool char read loop: 0, result: Characteristic value/descriptor: 5e

2017.03.03 01:03:53 4: Sub BleTagBattery_readSensorValue (BLETAG_BATTERY) - processing gatttool response: 5e
2017.03.03 01:03:53 4: Sub BleTagBattery_BlockingRun (BLETAG_BATTERY) - processing gatttool response for device GTAG_XYZ. batteryLevel: 94
2017.03.03 01:03:53 4: Sub BleTagBattery_BlockingDone (BLETAG_BATTERY) - set readings batteryLevel and battery of device: GTAG_ABC
2017.03.03 01:03:53 4: Sub BleTagBattery_BlockingDone (BLETAG_BATTERY) - set readings batteryLevel and battery of device: GTAG_XYZ
2017.03.03 01:03:53 4: Sub BleTagBattery_BlockingDone (BLETAG_BATTERY) - done


Vielleicht hilft dir auch das hier weiter: http://stackoverflow.com/questions/32947807/cannot-connect-to-ble-device-on-raspberry-pi (http://stackoverflow.com/questions/32947807/cannot-connect-to-ble-device-on-raspberry-pi)
Ich habe die hier erwähnten 3 Einträge in meiner main.conf drin stehen, da ich auch am Anfang mal ähnliche Probleme hatte.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 03 März 2017, 01:21:36
Zitat von: Mumpitz am 02 März 2017, 22:27:45
Müssen vorgängig die alten Scripte deaktiviert oder etwas deinstalliert werden?

Nein. Das sollte nicht notwendig sein. Beides sollte nebeneinander existieren können, falls du Skripte meinst die deinen Batteriestatus vorher ausgelesen haben. Wenn das Modul aber funktioniert, dann würde ich es machen, um dein System sauber zu halten.

Wenn du andere Skripte meinst, kommt es drauf an was es ist.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: binford6000 am 03 März 2017, 08:40:00
ZitatWas hast du sonst noch auf deinem Bluetooth Dongle laufen? Zufällig lepresenced oder irgendwelche anderen Skripte die dauerhaft den Bluetooth Dongle blockieren z.b. mit: hcitool lescan?

Genau, nur lepresenced läuft zur Erkennung des gtags.

ZitatVielleicht hilft dir auch das hier weiter: http://stackoverflow.com/questions/32947807/cannot-connect-to-ble-device-on-raspberry-pi
Ich habe die hier erwähnten 3 Einträge in meiner main.conf drin stehen, da ich auch am Anfang mal ähnliche Probleme hatte.

Das habe ich auch gefunden und es hat funktioniert da ich zwischenzeitlich Probleme mit dem gtag hatte.
Auf einem zweiten rpi 1 mit dem selben BT Dongle funktionierte das Ganze...

VG Sebastian
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 03 März 2017, 10:22:53
lepresenced und irgend etwas anderes das Gatttool verwendet ist eigentlich der worst case. Das liegt auch nicht an dem Modul von mir, sondern das ist generell so. Das ist vergleichbar damit, das sich zwei um einen Lolli streiten, aber es ist nur einer da. Beide versuchen sich den Lolli immer gegenseitig weg zu nehmen (in diesem Fall: Lolli = dein Bluetooth Dongle). Man kann dann lediglich folgendes mal versuchen (ohne Erfolgsgarantie), damit andere Module den Lolli länger als 1s von lepresenced klauen können:

1.) lepresenced beenden
2.) das lepresenced skript mit einem Editor aufmachen und den Wert "constant RETRY_SLEEP" anstatt auf 1 auf einen höheren Wert zu setzen (ich würde mal mit 20 starten und gucken obs dann geht und schrittweise runtergehen bis es nicht mehr geht)
3.) speichern und deamon neu starten

Das sorgt dann dafür das lepresenced in der Funktion bluetooth_scan_thread() einen Fehler feststellt, da sich Gatttool den Lolli geklaut hat, dann aber z.B. 20s wartet, bevor es versucht sich den Lolli zurück zu holen... Es führt aber auch dazu, dass lepresenced in dieser Zeit von z.B. 20s keinen aktuellen Status z.B. deiner Tags liefern kann!

Wenn das auch zu nichts führt, hilft nur ein zweiter Bluetooth Dongle oder weitere Änderungen am lepresenced Deamon. In weiter unten liegenden Schichten von Bluez kann man wahrscheinlich auch den parallelen Betrieb eines Scanns und des Auslesens von Werten abbilden, das erfordert aber ein komplett neues Framework. Soweit ich informiert bin, wird an einem solchen Framework bereits gearbeitet, die Zeitschiene ist jedoch unbekannt.

PS: Um überhaupt mal zu prüfen, ob das Modul funktioniert, kannst du lepresenced ja auch mal beenden und dann gucken was passiert. Dann müsste in jedem Fall der Batterielevel ausgelesen werden. Nach dem Abschießen von lepresenced muss man manchmal auch den Bluetooth Dongle resetten oder abzeihen/dranstecken, weil das Interface abgestürzt ist...
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: binford6000 am 03 März 2017, 12:25:45
Hallo,
Zitatdas lepresenced skript mit einem Editor aufmachen und den Wert "constant RETRY_SLEEP" anstatt auf 1 auf einen höheren Wert zu setzen (ich würde mal mit 20 starten und gucken obs dann geht und schrittweise runtergehen bis es nicht mehr geht)

Das wäre ja ein gangbarer Weg. Das PRESENCE-Device schaut auch nur alle 60s ob der gtag da ist. Werde ich auf jeden Fall mal testen!

ZitatPS: Um überhaupt mal zu prüfen, ob das Modul funktioniert, kannst du lepresenced ja auch mal beenden und dann gucken was passiert. Dann müsste in jedem Fall der Batterielevel ausgelesen werden. Nach dem Abschießen von lepresenced muss man manchmal auch den Bluetooth Dongle resetten oder abzeihen/dranstecken, weil das Interface abgestürzt ist...

Das würde mir im Endeffekt sogar auch genügen. Einmal die Woche sogar nur. Mein gtag ist jetzt anderthalb Jahre im Einsatz und noch keine Batterie tauschen müssen. Vielleicht kann ich das alles in ein kleines Script packen und per cronjob wöchentlich ausführen lassen...

Erstmal Danke für die Hilfestellung!
VG Sebastian
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: micky0867 am 03 März 2017, 20:14:23
Hallo,

das unterschiedliche Handling wegen uuid und handle sollte überflüssig sein.
Die entsprechende UUID muss für GATT kompatible Geräte immer 0x2A19 sein, dafür gibt es eine Spezifikation:
https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.battery_level.xml

Diese UUID funktioniert bei mir sowohl mit GTags, als auch mit NUTs und übrigens auch mit meinem Herzfrequenzsensor von BerryKing.

Der Unterschied bei den beiden Tags ist nur das mit dem public/random.
Die NUTs benötigen im Aufruf das "-t random", sonst geht es nicht.
Die GTags hingegen brauchen "-t public", oder gar nichts, was intern aber einem public gleich kommt.

Micky
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 03 März 2017, 23:26:25
Das ist eine super Information. Ich habe da nicht weiter nachgeforscht, sondern lediglich die Quellen im Internet angeschaut und dort war es überall so drin. Dachte das Gigaset hier ein extra Würstchen kocht. Was auch nicht sonderlich verwunderlich gewesen wäre, denn das machen leider viele Hersteller. Ich werde das mal probieren und dann den Code etwas entschlacken wenn es passt.
Im aktuellen devel Branch findet man bereits eine Version, in der probiert wird ob der Tag auf random oder public reagiert und diese Einstellung wird dann gespeichert und beim nächsten Mal erneut verwendet (dann muss nicht probiert werden). Damit sollte das Ding dann relativ kompatibel sein.

Thema lepresenced: Ich hab mir das bei mir noch mal angesehen und das hciDevice so eingestellt, dass das Modul auf dem Dongle läuft, auf dem auch lepresenced läuft. Ich bekomme dann sehr sporadisch die Batterieinformationen vom ersten Tag, für den zweiten reicht die Zeit nicht mehr (default bei lepresenced ist 1s) und das Auslesen schlägt fehl. Ich denke deshalb, dass die Erhöhung von RETRY_SLEEP das Problem an dieser Stelle weitestgehend beheben wird. Je mehr Tags man auslesen möchte, desto höher muss man wahrscheinlich den Wert wählen, um genug Zeit zu haben. Da das nur alle 6h kurz passiert, sollte das aber zu verschmerzen sein. Ich schreib das dann auch so noch mal ins readme rein, vielleicht hilfts dem einen oder anderen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: binford6000 am 04 März 2017, 09:31:09
Moin,
so ich habe mal alles ausprobiert jedoch leider ohne Erfolg...  :(
Ich gebe auf. Hätte mich auch gewundert, wenn es diesmal funktioniert hätte. Ich tippe
mal auf meinen BT-Dongle. Vielleicht geht es ja demnächst nach Umzug auf rpi3 mit
intergiertem BT Device... Trotzdem gute Arbeit und Danke für den Support!

VG Sebastian
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 04 März 2017, 23:34:22
Das sieht irgendwie sehr danach aus, dass du entweder bei deiner Software Installation was falsch gemacht hast (Bluez nicht richtig installiert) oder dein Dongle keinen vernünftigen Bluetooth Low Energie Support bietet. Sollte dem so sein, gibts Ersatz für um die 10€ z.B. von CSL. Die Dinger sind recht vernünftig.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Mumpitz am 05 März 2017, 09:26:32
Zitat von: mumpitzstuff am 04 März 2017, 23:34:22
Das sieht irgendwie sehr danach aus, dass du entweder bei deiner Software Installation was falsch gemacht hast (Bluez nicht richtig installiert) oder dein Dongle keinen vernünftigen Bluetooth Low Energie Support bietet. Sollte dem so sein, gibts Ersatz für um die 10€ z.B. von CSL. Die Dinger sind recht vernünftig.
Kannst Du mal den Typ posten, welchen Du im Einsatz hast und funktionier? Was hast Du für Erfahrungen mit der Reichweite?
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: binford6000 am 05 März 2017, 09:30:18
ZitatKannst Du mal den Typ posten, welchen Du im Einsatz hast und funktionier? Was hast Du für Erfahrungen mit der Reichweite?

Mein BT Donlge ist der hier: Inateck USB nano Bluetooth-Adapter V4.0

Die Reichweite ist sehr gut. Mein gtag wird idR. schon im Auto im Hof erkannt. Wohnung ist im 1. OG. Etwa 10-15m werden es sein.
VG Sebastian
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: knopf_piano am 05 März 2017, 22:56:01
Hab mir damals auch nen neuen zugelegt, set dem klappt hcitool-scan, auch inateck
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 06 März 2017, 12:40:21
Der Scan klappt ja bei ihm auch. Nur der Zugriff über Gatttool auf bestimmte Werte wie z.B. das Batterielevel nicht.
Wenn ich das im Internet richtig sehe, müsste das Ding eigentlich alles unterstützen. Bist du sicher das du bluez installiert hast und nicht nur ein Subset davon? Ist dein System aktuell (sudo apt-get update, sudo apt-get upgrade)? Bist du auf Raspbian Jessie oder irgend was altes? Ansonsten hab ich noch das hier gefunden:

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=133246 (https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=133246)
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=126899 (https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=126899)
https://eclipse.github.io/kura/doc/bluetooth-le-example.html (https://eclipse.github.io/kura/doc/bluetooth-le-example.html)
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: binford6000 am 06 März 2017, 17:59:27
ZitatIst dein System aktuell (sudo apt-get update, sudo apt-get upgrade)? Bist du auf Raspbian Jessie oder irgend was altes?

Ich habe ein aktuelles debian jessie mit bluez 5.23 am Laufen. Woran erkennt man ob bluez richtig instaliert ist?

pi@raspberrypi:~ $ bluetoothd -v
5.23
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: betateilchen am 11 März 2017, 00:51:48
Zitat von: mumpitzstuff am 27 Februar 2017, 21:29:50
Installation:

  • add the new update site: update add

Es gibt übrigens auch FHEM Anwender, die nicht die Standard-Update-Prozedur in ihrer FHEM Installation verwenden...
Gib doch bitte auch eine "normale" git URL an, wo man sich das Modul holen kann.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 11 März 2017, 01:25:05
Zitat von: betateilchen am 11 März 2017, 00:51:48
Es gibt übrigens auch FHEM Anwender, die nicht die Standard-Update-Prozedur in ihrer FHEM Installation verwenden...
Gib doch bitte auch eine "normale" git URL an, wo man sich das Modul holen kann.

Ich habs im ersten Beitrag ganz unten hinzugefügt.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Fixel2012 am 12 März 2017, 13:16:58
Danke für das tolle Modul! Nach dem ich die Zeit im lepresenced-Script von 1 auf 5 Sekunden geändert habe, funktioniert es einwandfrei!



EDIT: Ich habe immer mal wieder Probleme mit der Verbindung zu meinem G-Tag. Nach dem zurück stellen von 5 auf eine Sekunde läuft wieder alles.

Im Moment nutze ich das Interne Bluetooth vom Raspi 3. Einen Stick habe ich hier auch noch rum fliegen, doch leider wird dieser nicht erkannt. Muss ich einen bestimmten Stick haben um ihn einbinden zu können? :o

Bzw. wie läuft der Betrieb von zwei Bluetooth devices an einem Gerät? Wäre jemand so nett und erläutert mir kurz wie ich zwei Geräte in FHEM einbinde  ??? 8)

Danke und Gruß Fixel
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Jojo11 am 25 März 2017, 14:03:05
Hallo,

auch ich habe dieses Modul jetzt mal installiert, scheitere aber genau wie einige Mitstreiter an diversen Fehlermeldungen :-\ Irgendwann habe ich mit gatttool auch mal einen Zustand ausgelesen - es funktioniert theoretisch also schon. Allerdings nur mit einem der zwei dongles, die ich im System habe. Ich habe einen RPI3 im Netz (on board BT) sowie 2 RPI 2 mit je einem dongle und dann noch einen FHEM-Server, der keinen dongle hat.
Da ich ungern für die Batterieüberwachung einen einzelnen dongle "opfern" möchte: Wäre es nicht möglich, die Batterie-Funktionalität in lepresenced zu integrieren? Oder geht das prinzipiell nicht? Ich fände es irgendwie logischer, wenn der Batteriezustand genau wie die Anwesenheit durch jeden BT-Satelliten im System gesammelt und per collectord dann entsprechend weitergegeben werden könnte. Dann müssten sich die unterschiedlichen Skripte auch nicht um den BT-Dongle streiten.

schöne Grüße
Jo
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 26 März 2017, 20:22:18
Zitat von: Fixel2012 am 12 März 2017, 13:16:58
Danke für das tolle Modul! Nach dem ich die Zeit im lepresenced-Script von 1 auf 5 Sekunden geändert habe, funktioniert es einwandfrei!



EDIT: Ich habe immer mal wieder Probleme mit der Verbindung zu meinem G-Tag. Nach dem zurück stellen von 5 auf eine Sekunde läuft wieder alles.

Im Moment nutze ich das Interne Bluetooth vom Raspi 3. Einen Stick habe ich hier auch noch rum fliegen, doch leider wird dieser nicht erkannt. Muss ich einen bestimmten Stick haben um ihn einbinden zu können? :o

Bzw. wie läuft der Betrieb von zwei Bluetooth devices an einem Gerät? Wäre jemand so nett und erläutert mir kurz wie ich zwei Geräte in FHEM einbinde  ??? 8)

Danke und Gruß Fixel

Dann stell doch mal das Modul auf Verbose 5 und schau dir das Resultat im Logfile an. Vielleicht gibt das mehr Aufschluss. Bei Verwendung eines zweiten Dongles kannst du lepresenced z.b. mit hci0 laufen lassen und alles andere wie zum Beispiel dieses Modul auf hci1. Im Modul kannst du dazu das Attribut hciDevice verwenden.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 26 März 2017, 20:30:09
Zitat von: Jojo11 am 25 März 2017, 14:03:05
Hallo,

auch ich habe dieses Modul jetzt mal installiert, scheitere aber genau wie einige Mitstreiter an diversen Fehlermeldungen :-\ Irgendwann habe ich mit gatttool auch mal einen Zustand ausgelesen - es funktioniert theoretisch also schon. Allerdings nur mit einem der zwei dongles, die ich im System habe. Ich habe einen RPI3 im Netz (on board BT) sowie 2 RPI 2 mit je einem dongle und dann noch einen FHEM-Server, der keinen dongle hat.
Da ich ungern für die Batterieüberwachung einen einzelnen dongle "opfern" möchte: Wäre es nicht möglich, die Batterie-Funktionalität in lepresenced zu integrieren? Oder geht das prinzipiell nicht? Ich fände es irgendwie logischer, wenn der Batteriezustand genau wie die Anwesenheit durch jeden BT-Satelliten im System gesammelt und per collectord dann entsprechend weitergegeben werden könnte. Dann müssten sich die unterschiedlichen Skripte auch nicht um den BT-Dongle streiten.

schöne Grüße
Jo

Ich habe lepresenced leider nicht geschrieben, aber das dürfte auch so kaum möglich sein. Lepresenced benötigt hcitool und alles andere gatttool und beide Tools vertragen sich nicht. Es gewinnt immer nur eins der beiden Tools. Um das zu umgehen müsste man sehr tief in die Bluetooth Treiber absteigen...

Darüber hinaus würde mich interessieren was die Fehlermeldungen sind. Kannst du einfach auf verbose 5 gehen und mir dann den Output aus dem Logfile zukommen lassen? Was passiert wenn du versuchst den Status manuell mehrfach hintereinander zu holen? Geht dann die Anfrage durch?
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: SouzA am 13 April 2017, 12:02:06
Hi,

erstmal herzlichen Dank für dieses Modul!

Aber:
ich habe drei GTags über lepresenced eingebunden.
Alle drei haben folgendes Attribut:
Attributes:
   bluetooth_hci_device hci1

Das ist die interne Schnittstelle vom Raspi3.

Das BleTagBattery-Modul schaut in Summe so aus:
Internals:
   NAME       Bat_Gtags
   NR         280
   STATE      active
   TYPE       BleTagBattery
   VERSION    0.0.3
   Readings:
     2017-04-13 11:52:29   state           active
   Helper:
     01_Gtag  public
     02_Gtag  public
Attributes:
   hciDevice  hci0
   room       Residents,Tools

Hier habe ich auf den Bluetooth-Stick gezeigt. (hci0)

Aus irgendeinem Grund findet der den 03_Gtag nicht.
Hat jemand eine Ahnung warum?

Vielen Dank für Antwort.

Bis denn
SouzA

EDIT:
Wenn ich mit set Bat_Gtags statusRequest die aktualisierung force, wird auch nur 01_Gtag zuverlässig aktualisiert.
Dazu auch noch das log:

2017.04.13 12:10:07 4: Sub BleTagBattery_Run (Bat_Gtags) - start blocking call
2017.04.13 12:10:07 5: Sub BleTagBattery_stateRequest (Bat_Gtags) - state request called
2017.04.13 12:10:07 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - device found. device: 01_Gtag
2017.04.13 12:10:07 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - device name: Gigaset G-tag
2017.04.13 12:10:07 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - device address: 7C:2F:80:AD:8D:84
2017.04.13 12:10:07 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - tag already saved in hash
2017.04.13 12:10:10 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - call gatttool char read loop: 0, result: handle: 0x001b value: 55

2017.04.13 12:10:10 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - processing gatttool response: 55
2017.04.13 12:10:10 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - processing gatttool response for device 01_Gtag. batteryLevel: 85
2017.04.13 12:10:10 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - device found. device: 02_Gtag
2017.04.13 12:10:10 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - device name: Gigaset G-tag
2017.04.13 12:10:10 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - device address: 7C:2F:80:AD:AD:4D
2017.04.13 12:10:10 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - tag already saved in hash
2017.04.13 12:10:12 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - call gatttool char read loop: 0, result: handle: 0x001b value: 64

2017.04.13 12:10:12 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - processing gatttool response: 64
2017.04.13 12:10:12 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - processing gatttool response for device 02_Gtag. batteryLevel: 100
2017.04.13 12:10:12 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - device found. device: 03_Gtag
2017.04.13 12:10:12 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - device name: Gigaset G-tag
2017.04.13 12:10:12 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - device address: 7C:2F:80:AD:AD:4E
2017.04.13 12:10:12 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - try to connect with public
2017.04.13 12:10:13 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - call gatttool char read loop: 0, result: connect error: Software caused connection abort (103)

2017.04.13 12:10:13 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - call gatttool char read loop: 1, result: connect: No route to host (113)

2017.04.13 12:10:13 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - call gatttool char read loop: 2, result: connect: No route to host (113)

2017.04.13 12:10:13 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - call gatttool char read loop: 3, result: connect: No route to host (113)

2017.04.13 12:10:13 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - call gatttool char read loop: 4, result: connect: No route to host (113)

2017.04.13 12:10:13 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - invalid gatttool response
2017.04.13 12:10:13 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - try to connect with random
2017.04.13 12:10:13 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - call gatttool char read loop: 0, result: connect: No route to host (113)

2017.04.13 12:10:13 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - call gatttool char read loop: 1, result: connect: No route to host (113)

2017.04.13 12:10:13 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - call gatttool char read loop: 2, result: connect: No route to host (113)

2017.04.13 12:10:13 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - call gatttool char read loop: 3, result: connect: No route to host (113)

2017.04.13 12:10:13 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - call gatttool char read loop: 4, result: connect: No route to host (113)

2017.04.13 12:10:13 4: Sub BleTagBattery_readSensorValue (Bat_Gtags) - invalid gatttool response
2017.04.13 12:10:13 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - tag not supported
2017.04.13 12:10:13 4: Sub BleTagBattery_BlockingRun (Bat_Gtags) - processing gatttool response for device 03_Gtag. batteryLevel:
2017.04.13 12:10:13 4: Sub BleTagBattery_BlockingDone (Bat_Gtags) - set readings batteryLevel and battery of device: 01_Gtag
2017.04.13 12:10:13 4: Sub BleTagBattery_BlockingDone (Bat_Gtags) - set readings batteryLevel and battery of device: 02_Gtag
2017.04.13 12:10:13 4: Sub BleTagBattery_BlockingDone (Bat_Gtags) - done
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 13 April 2017, 15:13:34
Den Fehler "Software caused connection abort (103)" habe ich bei mir noch nie zu Gesicht bekommen. Laut Internet bedeutet dieser Fehler, dass sich der Bluetooth Dongle verabschiedet hat und danach nichts mehr geht. Deshalb wird auch dein dritter G-Tag nicht mehr erkannt. Laut Google kommen 2 Dinge in Betracht:


Das Modul funktioniert auf jeden Fall korrekt. Wenn sich der Dongle ab und zu verabschiedet oder der Bluetooth Stack, dann kann ich da leider vom Modul her nicht viel machen. Falls jemand noch eine Idee hat, wie man das Problem im Modul angehen könnte, dann bin ich für Ratschläge offen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: SouzA am 13 April 2017, 22:59:55
Hi,

Danke für deine Antwort!

Zitat von: mumpitzstuff am 13 April 2017, 15:13:34

  • Dein Bluetooth Dongle ist nicht der Beste. Mögliche Lösung: Versuch mal lepresenced auf hci0 und BleTagBattery auf hci1 zu setzen, also jeweils den anderen Dongle zu verwenden.
  • Du hast ein Bluez installiert, dass nicht richtig funktioniert. Siehe hierzu z.B. folgenden Beitrag. https://bugreports.qt.io/browse/QTBUG-44622 (https://bugreports.qt.io/browse/QTBUG-44622) Die Empfehlung irgendwelche Bluez Versionen manuell zu installieren, möchte ich jetzt aber lieber nicht aussprechen. Versuch erst mal die Dongles zu tauschen.

Punkt Nummer 1 hat schon geholfen. Hätte man auch selbst drauf kommen können... Jetzt bin ich mal gespannt, wie zuverlässig der Stick mit dem lepresence läuft.
Btw. der verwendete Stick ist dieser: Aukru® USB nano Bluetooth-Adapter V4.0.  Scheint also nicht allzu doll zu sein.

Auf jeden Fall noch einmal vielen Dank für dieses Klasse Modul und für den Support.

Bis denn
SouzA
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: stoxx am 26 Mai 2017, 15:10:11
ZitatSupported BLE tags: should work for all BLE tags now

Hi,
super Modul - mit meinen GTags klappts auch hervorragend. Nur der Batterie Wert von den nut Tags wird nicht ausgelesen..
Oder muss ich dafür etwas Bestimmtes einstellen?

2017.05.26 15:13:39 4: Sub BleTagBattery_BlockingRun (BLEBat) - device found. device: NutTag
2017.05.26 15:13:39 4: Sub BleTagBattery_BlockingRun (BLEBat) - device name: nut
2017.05.26 15:13:39 4: Sub BleTagBattery_BlockingRun (BLEBat) - device address: FF:30:43:78:F8:C4
2017.05.26 15:13:39 4: Sub BleTagBattery_BlockingRun (BLEBat) - try to connect with public
2017.05.26 15:14:19 4: Sub BleTagBattery_readSensorValue (BLEBat) - call gatttool char read loop: 0, result: connect error: Connection refused (111)
2017.05.26 15:14:59 4: Sub BleTagBattery_readSensorValue (BLEBat) - call gatttool char read loop: 1, result: connect error: Connection refused (111)
2017.05.26 15:15:39 4: Sub BleTagBattery_readSensorValue (BLEBat) - call gatttool char read loop: 3, result: connect error: Connection refused (111)
2017.05.26 15:16:19 4: Sub BleTagBattery_readSensorValue (BLEBat) - call gatttool char read loop: 4, result: connect error: Connection refused (111)
2017.05.26 15:16:19 4: Sub BleTagBattery_readSensorValue (BLEBat) - invalid gatttool response
2017.05.26 15:16:19 4: Sub BleTagBattery_BlockingRun (BLEBat) - try to connect with random
2017.05.26 15:16:27 4: Sub BleTagBattery_readSensorValue (BLEBat) - call gatttool char read loop: 0, result: connect error: Transport endpoint is not connected (107)
2017.05.26 15:16:31 4: Sub BleTagBattery_readSensorValue (BLEBat) - call gatttool char read loop: 1, result: connect error: Transport endpoint is not connected (107)
2017.05.26 15:16:35 4: Sub BleTagBattery_readSensorValue (BLEBat) - call gatttool char read loop: 2, result: connect error: Transport endpoint is not connected (107)
2017.05.26 15:16:39 4: Sub BleTagBattery_readSensorValue (BLEBat) - call gatttool char read loop: 3, result: connect error: Transport endpoint is not connected (107)
2017.05.26 15:16:47 4: Sub BleTagBattery_readSensorValue (BLEBat) - call gatttool char read loop: 4, result: connect error: Transport endpoint is not connected (107)
2017.05.26 15:16:47 4: Sub BleTagBattery_readSensorValue (BLEBat) - invalid gatttool response
2017.05.26 15:16:47 4: Sub BleTagBattery_BlockingRun (BLEBat) - tag not supported

vg
stoxx
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 27 Mai 2017, 00:23:10
Eigentlich sollte das ohne weiteres möglich sein. Das Modul versucht aber nur den im Bluetooth Standard festgelegten Service abzurufen. Vielleicht ist dein tracker nicht kompatibel in der Hinsicht? Versuch doch mal alternativ den Batteriestatus manuell abzufragen. Ich würde mich wundern, wenn das dann funktionieren sollte. Was für ein nur Tag ist das denn genau? Da gibts glaub mehrere...
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: stoxx am 27 Mai 2017, 10:01:52
Hi,
ich verwende die nut mini. Über einen BLE Scanner am Handy kann der Batteriestand ohne Probleme ausgelesen werden.
Manuell habe ich es über versucht mit
sudo gatttool -i hci1 -b FF:30:43:78:F8:C4 --char-read --handle=0x001b

Das klappt aber auch nicht - nach ca. 30 Sekunden kommt die Meldung:
Zitatconnect error: Connection refused (111)

Im Internet habe ich irgendwo das gefunden, werde aber nicht so richtig schlau draus:
http://www.domoticz.com/forum/viewtopic.php?t=16349#p121802 (http://www.domoticz.com/forum/viewtopic.php?t=16349#p121802)

vg stoxx
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 27 Mai 2017, 11:51:03
Versuch's mal mit -t random bei deinem gatttool aufruf. Die nut devices brauchen das.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: stoxx am 27 Mai 2017, 12:47:24
Ok, jetzt erhalte ich den Fehler, den ich auch mit dem Modul bekomme:
Zitatconnect error: Transport endpoint is not connected (107)
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 27 Mai 2017, 17:25:21
Kannst du in der app auf deinem Handy sehen, ob dort vielleicht ein anderer handle/service verwendet wird? Vielleicht ist der Tag auch mit deinem Handy gepaired und lässt jetzt keine anderen Verbindungen mehr zu? Hast du vielleicht eine nut app oder sowas installiert?
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: stoxx am 27 Mai 2017, 18:43:45
Habe ich mir auch schon gedacht - ist aber auch 2A19 (siehe Anhang).
Mit einer App ist der nut nicht gekoppelt (sonst würde die Abfrage via App wahrscheinlich auch nicht gehen, denke ich)
Ist schon komisch.. hab jetzt langsam auch keine Idee mehr..
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 28 Mai 2017, 00:34:19
Wenn der Tag gepaired wäre, dann käme es zu solchen Erscheinungen. Du must auf jeden Fall manuell den Batteriestatus auslesen können, ansonsten kommt das Modul auch nicht drauf.

1. Mal den Raspberry neu starten oder den Bluetooth Dongle abziehen und wieder dran stecken.
2. Falls vorhanden mit einem anderen Bluetooth Dongle testen obs damit geht.

Vorher jeweils Bluetooth bei deinem Handy/Tablet deaktivieren, damit das nicht dazwischen funkt. Danach etwas warten bis du die Tests machst, denn wenn ich mit mehreren Geräten auf ein Bluetooth Device zugreife, dann erhalte ich ebenfalls solche Fehler, wenn ich das zu schnell versuche. Wahrscheinlich ist das Gerät einige Zeit geblockt, nachdem darauf zugegriffen wurde.

Ansonsten fällt mir leider auch nicht mehr viel ein, das scheint ein sehr spezifisches Problem zu sein.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: stoxx am 28 Mai 2017, 13:17:25
Zitat1. Mal den Raspberry neu starten oder den Bluetooth Dongle abziehen und wieder dran stecken.
2. Falls vorhanden mit einem anderen Bluetooth Dongle testen obs damit geht.

Habe ich beides versucht, leider ohne Erfolg.
Außerdem habe ich bei allen anderen Bluetooth Geräten das Bluetooth deaktiviert - hat auch nichts geholfen.
Ich befürchte, dass es irgendwie an meinem installierten bluez liegt; das lang ich aber vorsichtshalber nicht an, da bisher sonst alles tadellos funktioniert..

Trotzdem vielen Dank für die Hilfe
vg stoxx
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mi.ke am 18 Juni 2017, 00:39:55
Zitat von: mumpitzstuff am 02 März 2017, 18:13:14
Ich habe den Zyklus 6h bewusst gewählt, ich kann aber auch ein Attribut hinzufügen. Aber Vorsicht bei 24h. Wenn man nicht den Zeitpunkt wählen kann, dann kann es passieren, das die Abfrage immer passiert wenn du auf Arbeit bist und du wirst gar nichts sehen.

Moin.

Vielen Dank für das Modul

Nachdem sich das Modul sofort erfolgreich mit meinen iBeacons verstanden hat, bin ich auf die Idee gekommen, andere Bluetooth-Geräte mit lepresenced und BleTagBattery abzufragen . . .
. . . Köpfhörer, Lautsprecher, Fitnessband, Fahrrad . . .

Funktioniert überraschen gut.

Somit meine Bitte; ich könnte ein Attribut für den Abfragezyklus sehr gut gebrauchen, bitte. 8)

Cheers
mi.ke
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 18 Juni 2017, 11:33:05
Das ist eigentlich kein Problem, würde dann aber nur ein Intervall für alles sein. Reicht das aus?

Alternativ kannst du aber auch mit at und einem set command das auslesen der Batterieinfos triggern.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: stoxx am 12 Juli 2017, 18:22:38
Hi,

ich habe gerade gemerkt, dass mein Tag bereits bei 37% batteryLevel nicht mehr richtig mit meinem Raspberry kommuniziert. Leider steht bei dem Tag das reading battery dann noch auf "ok". Wann geht das reading battery denn auf low? Und kann ich das irgendwie anpassen?

vg stoxx
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 12 Juli 2017, 21:58:02
Bei 15% springt die Anzeige um.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 17 Juli 2017, 00:07:20
Ach so auf die Frage wie man das ändern kann habe ich gar nicht geantwortet. Neben ok oder nicht ok wird auch ein batteryLevel erzeugt. Verwende doch einfach das für deinen Batteriewarnungstrigger.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: stoxx am 17 Juli 2017, 18:18:05
ZitatNeben ok oder nicht ok wird auch ein batteryLevel erzeugt. Verwende doch einfach das für deinen Batteriewarnungstrigger.
Habe ich mir auch schon überlegt, aber da ich ein notify für alle Devices habe, welches bei battery readings mit dem Text "low" triggert, wollte ich hier keine Ausnahme machen und habe einfach den Grenzwert im Modul Code geändert.

viele gruesse
stoxx
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Amenophis86 am 19 Juli 2017, 00:49:46
Ich habe aktuell drei GTags im Einsatz und verwende nur das Bluetooth Modul des Pi zum Überwachen der Tags und auslesen der Batterie. Leider kommt bei nur 2 Tags die Batteriewerte an. Den Wert RETRY_SLEEP passe ich doch in der Datei  /opt/fhem/contrib/PRESENCE/lepresenced an, oder? Und reicht es, wenn ich danach den Service einfach stoppe und neustarte, oder muss ich noch mehr machen um den neuen Wert zu nutzen?
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 19 Juli 2017, 01:45:12
Wie schon beschrieben, kann man von der Lösung nicht viel erwarten. Starten/Stoppen sollte aber reichen. Guck doch mal ob du alle drei bekommst wenn du den Service stoppst vorher. Wenn das schon mal geht, dann Beginn mit einer sehr großen Zeit z.b. 5 min und geh dann langsam runter bis es nicht mehr geht und rechne dann wieder 20% Sicherheit drauf.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Amenophis86 am 19 Juli 2017, 09:10:00
Ok, wollte nur sicher gehen, dass es mit Start und stop geht und ich nicht ewig versuche und die Grundvoraussetzung schon falsch ist. Danke :)
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: stiefl am 09 August 2017, 18:09:37
Klasse Modul, funktioniert auf Anhieb. Vielen Dank!!!  8)
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: jschuppe am 25 November 2017, 17:23:26
Hallo,

erst mal danke für das Modul. Mein GTag wird problemlos ausgelesen, mein "TrackR bravo" wird aber wohl nicht unterstützt ( https://secure.thetrackr.com/ (https://secure.thetrackr.com/) ).

Viele Grüße
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 26 November 2017, 02:51:06
Wenn das so ist, dann scheint sich dieser nicht an die Bluetooth Spezifikation zu halten. Wenn du ein Android Handy hast, dann gibts diverse BLE Scanner Tools, die auch die Services und UUIDs eines Gerätes auslesen können. Wenn du da irgendwas findest das nach Batteriestatus aussieht, dann lass es mich wissen und ich baue es ein. Ansonsten kannst du auch mal das Device auf verbose 5 stellen, vielleicht läuft auch in meinem Modul etwas falsch. Falls du sowas wie lepresenced laufen hast, kann es auch daran liegen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: PsychoD am 31 Dezember 2017, 18:23:32
Moin,

auf meinem Raspberry Pi mit OSMC als Distribution habe ich gatttool installiert und kann es eigentlich auch ausführen, bekomme im Log aber immer:
2017.12.31 17:47:50 1: PERL WARNING: Can't exec "gatttool": No such file or directory at ./FHEM/74_BleTagBattery.pm line 279.

Woran kann das liegen?

Guten Rutsch euch allen!

VG
Psy

//edit:
Im Pfad ist es eigentlich und sollte auch so aufgerufen werden können. Merkwürdig!

osmc@wohnzimmer:~$ which gatttool
/usr/local/bin/gatttool
osmc@wohnzimmer:~$ gatttool
Usage:
  gatttool [OPTION...]

Help Options:
  -h, --help                                Show help options
  --help-all                                Show all help options
  --help-gatt                               Show all GATT commands
  --help-params                             Show all Primary Services/Characteristics arguments
  --help-char-read-write                    Show all Characteristics Value/Descriptor Read/Write arguments

Application Options:
  -i, --adapter=hciX                        Specify local adapter interface
  -b, --device=MAC                          Specify remote Bluetooth address
  -t, --addr-type=[public | random]         Set LE address type. Default: public
  -m, --mtu=MTU                             Specify the MTU size
  -p, --psm=PSM                             Specify the PSM for GATT/ATT over BR/EDR
  -l, --sec-level=[low | medium | high]     Set security level. Default: low
  -I, --interactive                         Use interactive mode


osmc@wohnzimmer:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/usr/osmc/bin:/opt/vc/bin

Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: betateilchen am 31 Dezember 2017, 20:42:01
vermutlich liegt gatttool in Deiner Distribution nicht in einem Pfad, der bei der Suche nach ausführbaren Dateien automatisch berücksichtigt wird. Das Modul ruft gatttool ohne Pfadangabe auf und verläßt sich darauf, dass das Programm im Suchpfad gefunden wird.

Folgende Möglichkeiten hast Du:

Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: PsychoD am 01 Januar 2018, 18:17:55
Hallo,

Danke! Ich habe zum Test die dritte Variante genommen, werde aber wohl die zweite nachrüsten. :)

Nun bekomme ich jedoch die folgenden Fehler im log:

2018.01.01 18:01:43 1: PERL WARNING: Argument "ok" isn't numeric in numeric lt (<) at (eval 5210) line 1.
2018.01.01 18:01:43 3: eval: pr_gtag_battery: warning in condition c01


Woran kann das denn wohl liegen?

VG
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Amenophis86 am 01 Januar 2018, 19:05:14
Habe ne Frage zum Modul, löst das setzen des Batteriewerts kein Event des Geräts aus bei welchem der Wert gesetzt wird? Ich habe nämlich folgendes am laufen. Auf meinem zweiten PI läuft lepresenced und BleTagBattery auf einem Bluetoothsender. Da stört es mich nicht, wenn die beiden sich mal in die Quere kommen. Jetzt wollte ich mittels RFHEM und einem Notify den Batteriewert an meine Hauptinstanz senden, wenn der Wert sich ändert. Aber das notify triggert nicht und es sieht aus, als ob der Batteriewert geschrieben wird aber für das GTag Device kein Event auslöst. Wie kann ich dann das Event abgreifen und das Reading an die Hauptinstanz senden? Im Eventmonitor ist

2018-01-01 19:04:19 BleTagBattery AE.GTag.BatteryCheck active das einzige Event welches ich sehe beim Auslösen der Batterieabfrage.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 01 Januar 2018, 22:45:30
Die Werte werden durch diesen Code erzeugt:

readingsBeginUpdate( $targetHash );
readingsBulkUpdate( $targetHash, "batteryLevel", $param[2 + ($i * 3)] );
readingsBulkUpdate( $targetHash, "battery", ($param[2 + ($i * 3)] > 15 ? "ok" : "low") );
readingsEndUpdate( $targetHash, 1 );


Im Wiki finde ich dazu unter readingsBulkUpdate dann:

$changed (optional): Flag, ob ein Event für dieses Update erzeugt werden soll (Wert: 1). Oder ob definitiv kein Event erzeugt werden soll (Wert: 0). Wenn nicht gesetzt, wird aufgrund entsprechender Attribute in der Definition von $hash entschieden, ob ein Event zu erzeugen ist, oder nicht (Attribute: event-on-change-reading, event-on-update-reading, event-min-interval, ...)

Daraus würde ich entnehmen, dass bei dir aufgrund irgend welcher event... Attribute die Events nicht durch kommen. Bei readingsEndUpdate gebe ich ja auch noch explizit an, dass die Events ausgelöst werden sollen. Mehr kann ich eigentlich nicht tun.

Oder liege ich falsch?

Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Amenophis86 am 02 Januar 2018, 18:35:26
Oh man, du hast recht. Ich hab mich schon gewundert, weil ich den Codeteil gesehen hatte und er eigentlich gut war. Hatte wirklich ein event-on-change drinnen und daher kein Event mehr erzeugt. Manchmal sieht man den Wald vor lauter Bäumen nicht. Ich danke dir.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: ReviloEgros am 13 Februar 2018, 03:54:06
Hallo Gemeinde,

nun brauche ich mal euer Schwarmwissen. Nachdem ich gestern im FHEM Log gesehen habe, das das Timeout für den Blocking-Run von BleTagBattery erreicht und der Prozess gekillt wurde, habe ich etwas nachgeforscht. Der letzte Batteriestatus ist von vor 2 Tagen auf allen 5 Tags. Wenn ich gatttool von Hand ausführe, bekomme ich nun immer ein Connection refused, egal was ich versuche. An FHEM oder den Bluetooth einstellungen wurde nichts verändert, habe ich alles doppelt und dreifach gecheckt. Ich verwende die Gigaset G-Tags. Das einzige, was evtl geupdated wurde (kann mich nicht genau erinnern) war raspbian selbst. Auch andere Lösungsansätze wie ,,btmgmt le on" brachten keinen Erfolg. In der main.conf von bluez steht auch nachwievor DisablePlugins=pnat, EnableLE=true und AttributeServer=true. Auch ein kompletter reboot des Pi half nicht. Für presence und BleTagBattery verwende ich zwei unterschiedliche Bluetooth Dongle. Den internen vom Pi, und einen externen damit sich die beiden nicht in die quere kommen. Lief bisher wunderbar... Jetzt stehe ich auf dem Schlauch und weiß nicht mehr weiter, warum es von heut auf morgen ohne zutun nicht mehr geht. Jemand eine Idee?
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: ReviloEgros am 14 Februar 2018, 03:49:54
Nach nochmal ausgiebiegen rumprobieren und auch tauschen der Schnitstellen in FHEM als auch lepresenced ging es nachwievor nicht. Auch auf der Konsole konnte sich gatttool nicht verbinden. Dann habe ich das ganze über bluetoothctl probiert (irgendwo gelesen das gatttool deprecated sei) und siehe da, es konnte sich verbinden. Danach nochmal gatttool probiert, welches sich daraufhin auch verbinden konnte!? Ich habe keinen blassen schimmer wieso, aber nun läuft es wieder. Also falls jemand mal das selbe Problem haben sollte, einfach mal mit bluetoothctl testen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: CoolTux am 14 Februar 2018, 06:16:55
https://stackoverflow.com/questions/40519019/different-connection-result-in-gatttool-and-bluetoothctl-with-raspberry-pi-3-blu

Hätte sicherlich auch geholfen. Und bluetoothctl und gatttool sind zwei paar Schuhe. Denke nicht das da gatttool abgelöst wird.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: ReviloEgros am 14 Februar 2018, 15:17:29
Wenn du damit das -t random meinst, nein. Zumal ich für meine Tags public brauche.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: arthur_dent_2015 am 16 Februar 2018, 18:47:54
Moin zusammen,

ich krieg es nicht gebacken :(
3 G-Tags, 2 Raspi 3 mit 2x Bluetooth, 1 Raspi2 mit 1x Bluetooth, lepresenced, collectord, presenced. Tags werden fast immer auf mindestens 2 Raspis empfangen. Aber BleTagBattery spielt nicht mit  :'(
Im Log finde ich:


2018.02.16 18:29:30 4: Sub BleTagBattery_Run (GTAGBattery) - start blocking call
2018.02.16 18:29:30 5: Sub BleTagBattery_stateRequest (GTAGBattery) - state request called
2018.02.16 18:29:30 4: Sub BleTagBattery_BlockingRun (GTAGBattery) - device found. device: GTag1
2018.02.16 18:29:30 4: Sub BleTagBattery_BlockingRun (GTAGBattery) - device name: Gigaset G-tag
2018.02.16 18:29:30 4: Sub BleTagBattery_BlockingRun (GTAGBattery) - device address: 7C:2F:80:AD:BA:56
2018.02.16 18:29:30 4: Sub BleTagBattery_BlockingRun (GTAGBattery) - try to connect with public
2018.02.16 18:30:10 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 0, result: connect error: Connection refused (111)
2018.02.16 18:30:51 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 1, result: connect error: Connection refused (111)
2018.02.16 18:31:19 1: FreezeMon: myFreezemon possible freeze starting at 18:31:18, delay is 1.165 possibly caused by no bad guy found :-(
2018.02.16 18:31:31 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 2, result: connect error: Connection refused (111)
2018.02.16 18:32:05 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 3, result: connect error: Transport endpoint is not connected (107)

2018.02.16 18:32:06 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 4, result: connect error: Software caused connection abort (103)

2018.02.16 18:32:06 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - invalid gatttool response
2018.02.16 18:32:06 4: Sub BleTagBattery_BlockingRun (GTAGBattery) - try to connect with random
2018.02.16 18:32:06 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 0, result: connect: No route to host (113)

2018.02.16 18:32:06 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 1, result: connect: No route to host (113)

2018.02.16 18:32:06 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 2, result: connect: No route to host (113)

2018.02.16 18:32:06 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 3, result: connect: No route to host (113)

2018.02.16 18:32:06 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 4, result: connect: No route to host (113)

2018.02.16 18:32:06 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - invalid gatttool response
2018.02.16 18:32:06 4: Sub BleTagBattery_BlockingRun (GTAGBattery) - tag not supported
2018.02.16 18:32:06 4: Sub BleTagBattery_BlockingRun (GTAGBattery) - processing gatttool response for device Mustang. batteryLevel:
2018.02.16 18:32:06 4: Sub BleTagBattery_BlockingRun (GTAGBattery) - device found. device: GTag2
2018.02.16 18:32:06 4: Sub BleTagBattery_BlockingRun (GTAGBattery) - device name: Gigaset G-tag
2018.02.16 18:32:06 4: Sub BleTagBattery_BlockingRun (GTAGBattery) - device address: 7C:2F:80:AD:BA:A8
2018.02.16 18:32:06 4: Sub BleTagBattery_BlockingRun (GTAGBattery) - try to connect with public
2018.02.16 18:32:06 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 0, result: connect: No route to host (113)

2018.02.16 18:32:07 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 1, result: connect: No route to host (113)

2018.02.16 18:32:07 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 2, result: connect: No route to host (113)

2018.02.16 18:32:07 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 3, result: connect: No route to host (113)
2018.02.16 18:32:47 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 4, result: connect error: Connection refused (111)

2018.02.16 18:32:47 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - invalid gatttool response
2018.02.16 18:32:47 4: Sub BleTagBattery_BlockingRun (GTAGBattery) - try to connect with random
2018.02.16 18:33:27 4: Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 0, result: connect error: Connection refused (111)

2018.02.16 18:33:30 1: Timeout for BleTagBattery_BlockingRun reached, terminated process 1988
2018.02.16 18:33:30 3: (GTAGBattery) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout


bluetoothctl findet auf jedem Raspi mindesten 2 G-Tags.

Any ideas?

Gruß
Arthur
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 16 Februar 2018, 23:48:47
Versuch mal mit gatttool die Tags zu finden. Wenn du das manuell hinbekommst, dann sollte es auch das Modul schaffen. Das Modul probiert sowohl random als auch Public durch, um so möglichst alle Geräte zu finden. Wenn gatttool aber grundsätzlich nicht funktioniert, dann wird es das Modul auch nicht tun.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: arthur_dent_2015 am 18 Februar 2018, 15:59:26
gatttool sagt:


pi@raspberrypi1:~ $ sudo gatttool -i hci0 -b 7C:2F:80:AD:BA:A8 --char-read --handle=0x001b
Characteristic value/descriptor: 64
pi@raspberrypi1:~ $ sudo gatttool -i hci0 -b 7C:2F:80:AD:BA:56 --char-read --handle=0x001b
Characteristic value/descriptor: 64
pi@raspberrypi1:~ $ sudo gatttool -i hci0 -b 7C:2F:80:AD:BA:72 --char-read --handle=0x001b
Characteristic value/descriptor: 5e




pi@raspberrypi2:~ $ sudo gatttool -i hci0 -b 7C:2F:80:AD:BA:A8 --char-read --handle=0x001b
Characteristic value/descriptor: 64
pi@raspberrypi2:~ $ sudo gatttool -i hci0 -b 7C:2F:80:AD:BA:56 --char-read --handle=0x001b
Characteristic value/descriptor: 64
pi@raspberrypi2:~ $ sudo gatttool -i hci0 -b 7C:2F:80:AD:BA:72 --char-read --handle=0x001b
Characteristic value/descriptor: 5e



pi@raspberrypi3:~ $ sudo gatttool -i hci0 -b 7C:2F:80:AD:BA:A8 --char-read --handle=0x001b
connect error: Function not implemented (38)
pi@raspberrypi3:~ $ sudo gatttool -i hci0 -b 7C:2F:80:AD:BA:56 --char-read --handle=0x001b
connect error: Connection refused (111)
pi@raspberrypi3:~ $ sudo gatttool -i hci0 -b 7C:2F:80:AD:BA:72 --char-read --handle=0x001b
connect error: Connection refused (111)
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 19 Februar 2018, 00:28:24
Funktioniert es auch ohne sudo? Ist sichergestellt, das auf hci0 nur das Modul läuft und nicht gleichzeitig lepresenced? lepresenced sollte dann auf hci1 konfiguriert sein.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: arthur_dent_2015 am 19 Februar 2018, 17:44:24
ja, geht auf allen Rechnern ohne sudo, obwohl auf hci0 lepresenced läuft. Auf hci1 gibt es: connect error: Connection refused (111).
hci1 wird von presenced belegt, so denn überhaupt vorhanden.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 20 Februar 2018, 00:22:43
Dann gehen mir die Ideen aus. Das Modul macht exakt das, was du auf der Kommandozeile gemacht hast. Zur Not schreib dir eine Funktion in der myutils, vielleicht kann das deine Probleme lösen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: arthur_dent_2015 am 20 Februar 2018, 17:02:30
Auf welcher Instanz wird gatttool eigentlich gestartet? Auf der FHEM Instanz oder auch auf allen auf denen lepresenced läuft?
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: CoolTux am 20 Februar 2018, 17:05:08
Was genau meinst Du mit Instanz?
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: arthur_dent_2015 am 20 Februar 2018, 17:08:40
Instanz = Rechner (Raspi, bei mir 3 Stück), Auf der Hauptinstanz läuft FHEM, die beiden anderen sammeln nur Daten, Bluetooth, ser2net oder dienen als TTS Ausgabe.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: CoolTux am 20 Februar 2018, 17:10:42
Gatttool wird auf dem Rechner gestartet auf dem Du das Device in FHEM definiert hast.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: arthur_dent_2015 am 20 Februar 2018, 17:17:43
okay, dachte ich mir fast :( Der hat den schlechtesten Empfang...
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: CoolTux am 20 Februar 2018, 17:20:41
Ich weiß gerade nicht aus dem Kopf ob das Modul ssh Support bietet. Schau Mal bitte unter den Attributen ob Du da was mit ssh findest.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: arthur_dent_2015 am 20 Februar 2018, 18:30:21
Nee, kein ssh Attribut.
Perfekt wäre, wenn lepresenced die Batteriewerte gleich mit liefern würde.... Man kann sich ja mal was wünschen, is ja bald wieder Weihnachten ;)
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 20 Februar 2018, 21:56:11
Wie schon gesagt, das Modul startet immer lokal gatttool und versucht dort über Bluetooth die Daten zu ermitteln. Das Modul selbst verteilt die Daten nicht und hat mit SSH auch nichts am Hut. Leider habe ich mich mit diesem Thema auch noch nicht näher beschäftigt. Vermutlich kommt ein Teil deiner Probleme auch daher, dass das Modul nur alle 6h versucht deine Tags zu finden. Was mich wundert ist halt die Tatsache, dass sie auch nicht gefunden werden sollen, wenn sie direkt daneben liegen. Das dürfte nicht sein, dann funktioniert etwas auf diesem Gerät nicht bzw. mit dem Bluetooth auf diesem Gerät.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: arthur_dent_2015 am 22 Februar 2018, 19:35:30
Da hast Du mich missverstanden. Die Tags werden schon gefunden wenn sie in der Nähe sind, sind sie aber eher selten. Deswegen gibts ja die beiden anderen Rechner mit lepresenced.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 22 Februar 2018, 22:04:16
Das Modul funktioniert so nicht. Ich würde dir empfehlen auf den beiden entfernten Rechnern ein Skript in myutils zu verwenden, das dir die Informationen in ein Dummy schreibt. Das kannst du dann an die Hauptinstanz mit fhem2fhem verteilen. Frag mich aber bitte nicht wie das genau funktioniert, sowas habe ich nie gemacht.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Neuhier am 06 August 2018, 23:16:16
Mir ist da was aufgefallen:

beim Updatecheck heißt das Modul bletagbattery
in FHEM aber 74_BleTagBattery.

D.H., wenn ein Update kommt, wird es nicht da landen, wo es hin soll.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 07 August 2018, 00:46:11
Ich bin mir fast sicher, dass es trotzdem funktionieren würde. Das Modul ist aber auch sehr einfach gestrickt und seit über einem Jahr war hier kein Update notwendig.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Neuhier am 07 August 2018, 07:26:08
Klar, geht.  8)
Ist mir halt aufgefallen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Gasmast3r am 12 August 2018, 13:12:26
Hy Habe hier 2 Zero´s die für meine G-Tag Erkennung zuständig sind, da auf dem FHEM Rechner meine BLUETOOTH Heizungsthermostate laufen.

was mir aufgefallen ist das ein Tag auf einem Zero nicht gefunden wird, aber der andere schon, obwohl beide nebeneinander liegen.

habe mal ein 2´ten BLUETOOTH Stick eingebunden, denke das bringt derzeit nix aber mal abwarten.

Das Atribut Hci Device finde ich gut, sofern das auf dem SYS genutzt wird auf dem lepresenced ( die TAG´s gescannt werden) läuft.

Ich habe alles was mit BLUETOOTH gemacht wird strengstens getrennt, um derartige Probleme auszuschließen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 12 August 2018, 22:39:04
Versuch mal das device auf verbose 5 zu stellen. Vielleicht gibt das ja Aufschluss darüber, was genau beim zweiten schief läuft.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Gasmast3r am 12 August 2018, 22:44:36
Meinst du mich ??
Dein Modul und mein Lepresends stören sich bestimmt, da es nicht auf dem FHEM System läuft sondern extern und so keine trennung möglich ist.
Bevor ich das Modul genutzt habe war alles ok.

Zumindestens kann ich die Möglichkeit nicht erkennen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 13 August 2018, 22:36:17
Ja die beiden stören sich, da die Nutzung von lepresenced exklusiv ist. Wenn du beide gleichzeitig verwendest, dann schliessen sich beide immer gegenseitig ab. Mit Glück geht's dann trotzdem manchmal. Ich habe glaub auch irgendwo beschrieben, wie man die Chancen vielleich verbessern kann.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: stoxx am 06 Oktober 2018, 18:11:03
Hi,
Zitat
Supported BLE tags:

    should work for all BLE tags now

vielen Dank für das Modul, meine G-tags laufen super damit.
Ich habe aber auch ein paar nut minis in Betrieb und die scheinen momentan von Deinem Modul noch nicht unterstützt zu werden:
https://tchgdns.de/nut-mini-bluetooth-tracker-test/ (https://tchgdns.de/nut-mini-bluetooth-tracker-test/)
Was brauchst Du denn für Infos, um diese Tags mit einzubinden?

vg stoxx
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 06 Oktober 2018, 22:09:51
Du müsstest dann versuchen von einer Shell aus die Informationen abzufragen. Ich prüfe lediglich den Dienst, der bei Bluetooth für den Batteriezustand zuständ sein sollte und frage diesen ab. Wenn sich der Nut Mini nicht daran hält, dann müsste man rausfinden wie man das sonst auslesen könnte. Alternativ kannst du mal ins Modul rein schauen und die gatttool Kommandos manuell nachstellen, um zu sehen, ob du damit mehr Erfolg hast. Falls ja, müsste gucken ob ich da was finde.
Wenn du die Nuks mit irgend einer anderen App oder sowas gepaired hast, kann das den Zugriff ebenfalls verhindern.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: stoxx am 10 Oktober 2018, 20:20:26
Hi, dem Modul fehlt aktuell noch die Möglichkeit, per attr selber bestimmen zu können, ab wann der batteriestatus von ok auf low wechselt. Ich habe das jetzt im Quellcode geändert, scheint ja aktuell 15 zu sein.. Toll wäre auch ein attr für das Abfrageintervall. Wird das Modul denn noch weiter entwickelt? vg stoxx
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 10 Oktober 2018, 23:28:58
Das mit dem Batteriestatus könnte ich tatsächlich mal einbauen. Wenn du außerhalb des 6h Intervalls Abfragen machen möchtest, dann kannst du das mit einem at realisieren, um einen statusRequest abzusetzen. Das Credo war: Keep it simple. Den Batteriestatus muss man auch nicht jede Stunde abfragen. Wenn das alle 3-4 Tage mal funktioniert, ist das völlig ausreichend. Alles andere reduziert nur die Lebensdauer deines Tags bzw. der Batterie deines Tags.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: t1me2die am 12 Oktober 2018, 21:35:47
Moin Mumpitz,

habe dein Modul installiert.
Für G-Tag's klappt es auch.

Jedoch habe ich hier noch ein weiteren iBeacon (UFO), welcher leider nicht funktioniert.


2018.10.12 21:30:08 4: Sub BleTagBattery_BlockingRun (iBeacon_Batterie) - device found. device: iBeacon_Mathze
2018.10.12 21:30:08 4: Sub BleTagBattery_BlockingRun (iBeacon_Batterie) - device name: (unknown)
2018.10.12 21:30:08 4: Sub BleTagBattery_BlockingRun (iBeacon_Batterie) - device address: AC:23:3F:26:4A:83
2018.10.12 21:30:08 4: Sub BleTagBattery_BlockingRun (iBeacon_Batterie) - try to connect with public
2018.10.12 21:30:10 4: Sub BleTagBattery_Run (iBeacon_Batterie) - blocking call already running
2018.10.12 21:30:10 5: Sub BleTagBattery_stateRequest (iBeacon_Batterie) - state request called
2018.10.12 21:30:13 4: Sub BleTagBattery_readSensorValue (iBeacon_Batterie) - call gatttool char read loop: 0, result: Read characteristics by UUID failed: No attribute found within the given range

2018.10.12 21:30:13 4: Sub BleTagBattery_readSensorValue (iBeacon_Batterie) - call gatttool char read loop: 1, result: Read characteristics by UUID failed: No attribute found within the given range

2018.10.12 21:30:14 4: Sub BleTagBattery_readSensorValue (iBeacon_Batterie) - call gatttool char read loop: 2, result: Read characteristics by UUID failed: No attribute found within the given range

2018.10.12 21:30:14 4: Sub BleTagBattery_readSensorValue (iBeacon_Batterie) - call gatttool char read loop: 3, result: Read characteristics by UUID failed: No attribute found within the given range

2018.10.12 21:30:14 4: Sub BleTagBattery_readSensorValue (iBeacon_Batterie) - call gatttool char read loop: 4, result: Read characteristics by UUID failed: No attribute found within the given range

2018.10.12 21:30:14 4: Sub BleTagBattery_readSensorValue (iBeacon_Batterie) - invalid gatttool response
2018.10.12 21:30:14 4: Sub BleTagBattery_BlockingRun (iBeacon_Batterie) - try to connect with random
2018.10.12 21:30:14 4: Sub BleTagBattery_readSensorValue (iBeacon_Batterie) - call gatttool char read loop: 0, result: connect error: Software caused connection abort (103)

2018.10.12 21:30:14 4: Sub BleTagBattery_readSensorValue (iBeacon_Batterie) - call gatttool char read loop: 1, result: connect: No route to host (113)


Unter ,,iBeacon Ufo" ist das Teil nein google auch einfach zu finden.

Was für Info's brauchst du noch von mir?

Gruß
Mathze
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 12 Oktober 2018, 23:10:37
Ich frage die Standard Bluetooth UUID für das Batterie Level ab (uuid=0x2a19). Wenn das von deinem Tag nicht unterstützt wird, müsstest du irgendwie rausfinden unter welcher UUID sich das sonst versteckt.

Hier sind 2 Apps beschrieben mit denen du mal danach suchen könntest:

https://support.kontakt.io/hc/en-gb/articles/206294004-How-to-check-the-battery-level-on-your-beacons
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Amenophis86 am 29 Oktober 2018, 21:16:50
Wenn ich alles richtig gemacht habe, dann habe ich dir gerade einen Vorschlag für eine Version mit dem Attr "BleTagBatteryInterval" geschickt. Mittels des Attr kann man selbstständig den Timer in Sekunden setzen. Habe es bei mir getestet und hat funktioniert.

Sage gleich dazu, dass ich kein Programmierer bin, mir alles selbst bei gebracht habe und nach bestem Wissen und Gewissen gearbeitet habe ;)
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 30 Oktober 2018, 00:55:39
Wohin hast du es denn geschickt?

Das einzubauen ist übrigens nicht so schwierig, aber ich will es schlicht gar nicht, weil es komplett unnötig ist. Das bewegt Anwender nur sinnlose 15min Intervalle einzustellen und sich dann zu wundern, weshalb die Batterie nach einem halben Jahr leer ist. Es würde auch reichen den Zustand der Batterie alle 3-4 Tage auszulesen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Amenophis86 am 30 Oktober 2018, 06:33:03
Hatte auf Git einen Pullrequest gestellt meine ich.

Mir ging es genau darum das Intervall zu erhöhen, weil mir 6h zu kurz war. Dann habe ich es mir gleich als attr eingebaut.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: binford6000 am 30 Oktober 2018, 08:34:29
Moin,
ich habe das mit dem Intervall ja auch schon mal angefragt. Bin aber mittlerweile auch der Meinung von mumpitzstuff,
dass viele Anwender ein viel zu kurzes Intervall wählen könnten.

Andererseits bin ich auch bei Amenophis86 - wenn das Intervall dann groß genug wählbar ist.
Etwa nur in ganzen Tagen wählbar?

Ich persönlich prüfe nur alle 4 Tage meine G-Tags. Das reicht völlig aus. Dazwischen wird BleTagBattery sogar
disabled, um das interne 6-Stunden-Intervall zu umgehen.

VG Sebastian
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 30 Oktober 2018, 08:50:51
Die 6h waren mit Bedacht gewählt, denn sie sind etwas kürzer als der normale Schlafzyklus, also genau der Zeit, in der man normalerweise zu Hause ist. Wenn das Intervall zufällig um 9 Uhr zuschlagen würde und das alle drei Tage, dann erwischt man unter Umständen immer einen Wochentag bzw. wenn derjenige auf der Arbeit ist und man bekommt so gut wie nie einen Wert. Meine Tags haben mit dieser Einstellungen rund 1,5 Jahre gehalten, was ich für akzeptabel halte.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: CoolTux am 30 Oktober 2018, 08:54:06
Nur mal so als Idee,
Bei meinen G-Tags habe ich es so gemacht das sie immer dann abgefragt werden wenn derjenige nach Hause kommt. Also anwesend ist.
Und ja das kann auch mal 2-3 mal pro Tag sein.

Im Modul könnte man das aber kompinieren. Letzter Auslesetimestamp älter 6h dann lese definitv aus wenn derjenige nach Hause kommt.
Ist ne Idee
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 30 Oktober 2018, 09:46:52
Der Anwesenheitsstatus wird mit einbezogen bzw. es wird die Abfrage der Einfachheit halber einfach nicht durchgeführt, wenn der Tag abwesend ist und die 6h verstrichen sind. Aber selbst wenn der Tag noch als Anwesend gekennzeichnet ist, muss er das längst nicht mehr sein. Viele Anwender (auch ich) haben eine Verzögerung eingebaut, so das nicht bei jeder kleinen Störung auf Abwesend geschaltet wird, dadurch kann es vorkommen, das der Tag noch als Anwesend im System hängt, aber nicht mehr erreichbar ist, weil ich z.B. vor 20s die Wohnung verlassen habe.

Man könnte jetzt mit einer besseren Logik noch mehr machen z.B. frage alle 3 Tage ab und wenn die Abfrage nicht erfolgen konnte wegen z.B. Abwesenheit senke das Intervall kurzfristig auf 6h, bis die Abfrage einmal erfolgreich war und gehe dann wieder auf 3 Tage. Aber wie bereits gesagt. Manche Dinge sollte man nicht unnötig kompliziert machen. Keep it simple and stupid.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: binford6000 am 30 Oktober 2018, 10:15:25
ZitatManche Dinge sollte man nicht unnötig kompliziert machen. Keep it simple and stupid.
Da ist was dran  :)

Es gibt genügend Möglichkeiten für häufigeres Abfragen mit einem statusRequest als at usw...
Und genauso gut geht's auch seltener abzufragen mit disable, ReadingsAge vom battery Reading etc...
VG Sebastian
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Amenophis86 am 30 Oktober 2018, 12:48:56
Falls doch jemand meine geänderte Version nutzen möchte habe ich sie angehängt. Das Intervall wird in Sekunden gesetzt und das mittels des Attr BleTagBatteryInterval

Edit:
Kann die Argumentation von CoolTux nachvollziehen und habe entfernt
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: CoolTux am 30 Oktober 2018, 13:04:00
Zitat von: Amenophis86 am 30 Oktober 2018, 12:48:56
Falls doch jemand meine geänderte Version nutzen möchte habe ich sie angehängt. Das Intervall wird in Sekunden gesetzt und das mittels des Attr BleTagBatteryInterval

Nicht bös gemeint, aber dazu muß ich was sagen.
Es ist und sollte nicht Ziel sein ein offizielles Modul zu ändern und hier an zu bieten. Wie möchtest Du mit etwaigen Weiterentwicklungen um gehn? Wer soll Support für DEINE Modulversion machen?

Das ist wirklich doof. Gelten lassen kann man sicherlich einen Fork unter anderen Namen und neuem Forumsthread.

Wie gesagt meine persönliche Meinung und nicht böse gemeint.



Grüße
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: stromer-12 am 09 Dezember 2018, 18:08:30
Bei mir gehen mit diesen Modul meine G-Tags auf absent.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: stromer-12 am 09 Dezember 2018, 19:29:08
Zitat von: stromer-12 am 09 Dezember 2018, 18:08:30
Bei mir gehen mit diesen Modul meine G-Tags auf absent.
Lag vermutlich am nicht angegebenen hciDevice.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: valvak am 20 Dezember 2018, 20:39:07
Nabend zusammen,

ich hab eine Frage zum Modul. Welche Bluetooth-Sticks verwendet ihr? Ich habe aktuell 2 externe und das eine interne auf dem Raspberry in Verwendung. Das interne hci2 nutze ich als iBeacon. Auf hci0 läuft lepresenced und hci1 soll eigentlich das Modul laufen, attr ist auch passend gesetzt. Allerdings bekomme ich keine Aktualisierung und im Log ein Timeout-Fehler. Der iBeacon muss auf dem internen laifen, da die Dongle irgendwie nicht senden. Lepresenced scheint es prinzipiell egal zu sein. Die externen Dongle sind beide vom gleichen Typ und können BLE und 4.0

2018.12.20 20:17:28 1: Timeout for BleTagBattery_BlockingRun reached, terminated process 6695
2018.12.20 20:17:28 3: (BleTagBattery) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout


Oder liegt der Fehler woanders? Danke im Vorraus
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 21 Dezember 2018, 03:07:21
Wenn du Verbose auf 5 setzt, dann bekommst du mehr Ausgaben. Dort sollte glaube ich auch irgendwo der gatttool Befehl auftauchen. Denn kannst du spaßeshalber auch mal von der Console aus probieren und siehst dann was passiert. Vermutlich hält sich dein Tag Hersteller nicht an die Bluetooth Norm (wie leider viele andere auch) und stellt deshalb die Batterieinformationen nicht normgerecht zur Verfügung. Da bliebe dir nur noch Bluetooth zu sniffen, um die korrekte uuid zu finden und dir ein eigenes Skript zu schreiben.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: valvak am 21 Dezember 2018, 15:16:23
Ich bekomme ja grundsätzlich die Batterie Info von dann Tags. Aber meistens nur einen und die anderen aktualisieren sich nie, auch nicht in den 6 Stunden obwohl sie alle an einer Position liegen.
Sind auch alles die gleichen Gigaset Tags. Aber ich stelle mal auf verbose 5
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 21 Dezember 2018, 20:38:18
Das sollte eigentlich funktionieren, wenn die Abfragen nicht unterbrochen werden. Lepresenced oder sowas sollte nicht auf dem gleichen Bluetooth Dongle laufen...
Ich habe hier 3 Tags und die laufen einwandfrei.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: valvak am 22 Dezember 2018, 12:06:54
Ne also ich steh da echt auf dem Schlauch. Nochmal zur Erinnerung:
ibeacon - hci2
lepresenced - hci0
Batterie - hci1
Auch alles soweit richtig in den configs bzw attr eingestellt.

pi@raspHOME:~ $ sudo gatttool -i hci1 -b 7C:2F:80:EA:FE:45 --char-read --handle=0x001b
Characteristic value/descriptor: 55
pi@raspHOME:~ $ sudo gatttool -i hci1 -b 7C:2F:80:EA:FE:45 --char-read --handle=0x001b
connect error: Function not implemented (38)
pi@raspHOME:~ $ sudo gatttool -i hci1 -b 7C:2F:80:EA:FE:45 --char-read --handle=0x001b
connect error: Transport endpoint is not connected (107)
pi@raspHOME:~ $ sudo gatttool -i hci1 -b 7C:2F:80:EA:FE:45 --char-read --handle=0x001b
connect error: Function not implemented (38)
pi@raspHOME:~ $ sudo gatttool -i hci1 -b 7C:2F:80:EA:FE:45 --char-read --handle=0x001b
connect error: Function not implemented (38)
pi@raspHOME:~ $ sudo gatttool -i hci1 -b 7C:2F:80:EA:FE:45 --char-read --handle=0x001b
connect error: Function not implemented (38)

Das ist die Abfrage meines Tags in der Konsole.
Nach umstellen auf verbose 5 komm ich aber auch nicht weiter:

2018.12.22 02:40:19 4: Sub BleTagBattery_Run (BleTagBattery) - start blocking call
2018.12.22 02:40:19 5: Sub BleTagBattery_stateRequest (BleTagBattery) - state request called
2018.12.22 02:40:19 4: Sub BleTagBattery_BlockingRun (BleTagBattery) - device found. device: BTag_Leon
2018.12.22 02:40:19 4: Sub BleTagBattery_BlockingRun (BleTagBattery) - device name: Gigaset G-tag
2018.12.22 02:40:19 4: Sub BleTagBattery_BlockingRun (BleTagBattery) - device address: 7C:2F:80:EA:F9:F0
2018.12.22 02:40:19 4: Sub BleTagBattery_BlockingRun (BleTagBattery) - try to connect with public
2018.12.22 02:40:59 4: Sub BleTagBattery_readSensorValue (BleTagBattery) - call gatttool char read loop: 0, result: connect error: Connection refused (111)

2018.12.22 02:41:39 4: Sub BleTagBattery_readSensorValue (BleTagBattery) - call gatttool char read loop: 1, result: connect error: Connection refused (111)

2018.12.22 02:42:20 4: Sub BleTagBattery_readSensorValue (BleTagBattery) - call gatttool char read loop: 2, result: connect error: Connection refused (111)

2018.12.22 02:43:00 4: Sub BleTagBattery_readSensorValue (BleTagBattery) - call gatttool char read loop: 3, result: connect error: Connection refused (111)

2018.12.22 02:43:40 4: Sub BleTagBattery_readSensorValue (BleTagBattery) - call gatttool char read loop: 4, result: connect error: Connection refused (111)

2018.12.22 02:43:40 4: Sub BleTagBattery_readSensorValue (BleTagBattery) - invalid gatttool response
2018.12.22 02:43:40 4: Sub BleTagBattery_BlockingRun (BleTagBattery) - try to connect with random
2018.12.22 02:44:20 1: Timeout for BleTagBattery_BlockingRun reached, terminated process 14601
2018.12.22 02:44:20 3: (BleTagBattery) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout


Ich bin auch nicht der Linux-Profi. Ich verstehe grundsätzlich dass die Dienste nicht auf einem Stick laufen können, was mir die Aussagen oben sagen sollen aber leider nicht.

Achso und eine Umstellung der Devices bringt das gleiche Resultat. Nur der beacon kommt komischerweise nur mit dem Onboard BT zurecht. Wenn ich den auf nen Dongle setze sendet er keine UUID. Sprich mir stehen nur 2 identische Sticks zur Verfügung. Sind beides CSL BT 4.0 Adapter... Chipsatz ist laut Amazon wohl Chipsatz: CSR 8510 A10-Controller.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: valvak am 22 Dezember 2018, 12:19:45
Nach shutdown -r now dann wieder im fhem

2018.12.22 12:14:06 1: Timeout for BleTagBattery_BlockingRun reached, terminated process 1424
2018.12.22 12:14:06 3: (BleTagBattery) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout


Ist halt irgendwie null reproduzierbar
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 23 Dezember 2018, 00:51:30
Hmm solange du nicht mal auf der Console ein reproduzierbares Ergebnis bekommst, wird das Modul leider auch nicht viel machen können. Der Bluetooth Support unter Linux ist gelinde gesagt sch...
Was mir noch einfällt, die Tags sollten nicht mit irgendeiner App auf deinem Handy gekoppelt sein, das kann eventuell auch zu Problemen führen. Ansonsten mach dir das Leben nicht deswegen zur Hölle. Es ist nur ein Batteriereading. Da gibts elementarere Dinge bei der Heimautomatisierung.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: valvak am 23 Dezember 2018, 01:22:26
Ja ist schon richtig. Ist eher sekundär. Aber wenn man sonst alles am laufen hat sucht man sich Baustellen  :P

Es gibt zwar immer was zutun, aber ich arbeite gerne was ab bevor ich neues anfange. Naja ich werd's mal im Auge behalten. Schade um den eine Stick der quasi nix macht
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: t1me2die am 23 Januar 2019, 13:22:06
Ich habe tatsächlich dasselbe Problem wie valvak.


2019.01.19 17:54:58 1: Timeout for BleTagBattery_BlockingRun reached, terminated process 12168
2019.01.19 17:54:58 3: (iBeacon_Batterie) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout
2019.01.20 17:56:02 1: Timeout for BleTagBattery_BlockingRun reached, terminated process 12931
2019.01.20 17:56:02 3: (iBeacon_Batterie) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout
2019.01.21 11:56:51 1: Timeout for BleTagBattery_BlockingRun reached, terminated process 13562
2019.01.21 11:56:51 3: (iBeacon_Batterie) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout
2019.01.22 11:57:17 1: Timeout for BleTagBattery_BlockingRun reached, terminated process 14231
2019.01.22 11:57:17 3: (iBeacon_Batterie) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout
2019.01.22 17:57:42 1: Timeout for BleTagBattery_BlockingRun reached, terminated process 14395
2019.01.22 17:57:42 3: (iBeacon_Batterie) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout
2019.01.23 11:58:24 1: Timeout for BleTagBattery_BlockingRun reached, terminated process 15028
2019.01.23 11:58:24 3: (iBeacon_Batterie) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout


Was mir aufgefallen ist, ca. 1x am Tag schmiert meine lan-bluetooth Presence Erkennung ab.
Anwesende Beacons werden nicht mehr erkannt.

Erst nach einem

hcitool lescan

per SSH läuft die Presence Erkennung wieder.
Warum die Erkennung abschmiert weiß ich nicht.
Ich habe nun erstmal das BleTagBattery Device disabled und schaue, ob es eine Verbesserung die nächsten Tage gibt.

Gruß
Mathze
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 23 Januar 2019, 15:14:39
lepresenced und irgend einen anderen bluetooth service über das selbe Interface laufen zu lassen, ist eine ganz schlechte Idee. Das funktioniert nur mit sehr viel Glück. Wenn dein Bluetooth dauerhaft abschmiert, dann kann das Modul auch nichts mehr machen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: t1me2die am 23 Januar 2019, 15:27:05
Auf dieser VM nutze ich lediglich lepresenced.
Keinen anderen Bluetooth Service.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 23 Januar 2019, 16:15:32
Das Abfragen der Batterieinfos ist doch ein anderer Service.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: t1me2die am 23 Januar 2019, 16:32:03
Ach so meinst du das, ich dachte bei Services an: presence und lepresence, die beide auf dasselbe physische IO zugreifen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 23 Januar 2019, 22:19:53
lepresenced versetzt ein bluetooth Device in einen Zustand, in dem es für alles andere geblockt ist. Man kann dann im Prinzip nichts aber auch gar nichts anderes mit dem Bluetooth Dongle mehr anfangen. Will man batterieinfos zusätzlich haben, dann sollte man sich einen zweiten Bluetooth Dongle anschaffen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: tarum am 15 Mai 2019, 10:18:57
Hallo,

besteht die Möglichkeit die Batterie abfragen auch remote über ssh zu machen wie beim     
XiaomiBTLESens Modul
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 15 Mai 2019, 13:36:39
Wenn ich kurz mal die Kommentare so überfliege und die massenhaft auftretenden Probleme bei diesem Feature sehe, eher nicht.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Gasmast3r am 30 September 2019, 18:09:01
Hallo habe das Modul nach langem mal Aktiviert, habe 2 Zero Pi für die Anwesenheit und meine Heizungssteuerung am laufen, mittlerweile mit je 2 Dongle.

bekomme aber kein Aktuelles Reading in mein Device geschrieben, laut Log(so lese ich das bekommt er die werte)


2019.09.30 17:56:49 4: Sub BleTagBattery_Run (Batterie) - start blocking call
2019.09.30 17:56:49 5: Sub BleTagBattery_stateRequest (Batterie) - state request called
2019.09.30 17:56:49 4: Sub BleTagBattery_BlockingRun (Batterie) - device found. device: Sonja_Cam
2019.09.30 17:56:49 4: Sub BleTagBattery_BlockingRun (Batterie) - device name: Gigaset G-tag
2019.09.30 17:56:49 4: Sub BleTagBattery_BlockingRun (Batterie) - device address: 7C:2F:80:96:3D:CE
2019.09.30 17:56:49 4: Sub BleTagBattery_BlockingRun (Batterie) - try to connect with public
2019.09.30 17:56:54 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 0, result: handle: 0x001b value: 55

2019.09.30 17:56:54 4: Sub BleTagBattery_readSensorValue (Batterie) - processing gatttool response: 55
2019.09.30 17:56:54 4: Sub BleTagBattery_BlockingRun (Batterie) - processing gatttool response for device Sonja_Cam. batteryLevel: 85
2019.09.30 17:56:54 4: Sub BleTagBattery_BlockingRun (Batterie) - device found. device: Sonja_Cam1
2019.09.30 17:56:54 4: Sub BleTagBattery_BlockingRun (Batterie) - device name: Gigaset G-tag
2019.09.30 17:56:54 4: Sub BleTagBattery_BlockingRun (Batterie) - device address: 7C:2F:80:96:3D:CE
2019.09.30 17:56:54 4: Sub BleTagBattery_BlockingRun (Batterie) - try to connect with public
2019.09.30 17:56:54 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 0, result: handle: 0x001b value: 55

2019.09.30 17:56:54 4: Sub BleTagBattery_readSensorValue (Batterie) - processing gatttool response: 55
2019.09.30 17:56:54 4: Sub BleTagBattery_BlockingRun (Batterie) - processing gatttool response for device Sonja_Cam1. batteryLevel: 85
2019.09.30 17:56:54 4: Sub BleTagBattery_BlockingRun (Batterie) - device found. device: Sven_Cam
2019.09.30 17:56:54 4: Sub BleTagBattery_BlockingRun (Batterie) - device name: Gigaset G-tag
2019.09.30 17:56:54 4: Sub BleTagBattery_BlockingRun (Batterie) - device address: 7C:2F:80:AD:C7:ED
2019.09.30 17:56:54 4: Sub BleTagBattery_BlockingRun (Batterie) - try to connect with public
2019.09.30 17:56:56 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 0, result: handle: 0x001b value: 5e

2019.09.30 17:56:56 4: Sub BleTagBattery_readSensorValue (Batterie) - processing gatttool response: 5e
2019.09.30 17:56:56 4: Sub BleTagBattery_BlockingRun (Batterie) - processing gatttool response for device Sven_Cam. batteryLevel: 94
2019.09.30 17:56:56 4: Sub BleTagBattery_BlockingRun (Batterie) - device found. device: Sven_Cam1
2019.09.30 17:56:56 4: Sub BleTagBattery_BlockingRun (Batterie) - device name: Gigaset G-tag
2019.09.30 17:56:56 4: Sub BleTagBattery_BlockingRun (Batterie) - device address: 7C:2F:80:AD:C7:ED
2019.09.30 17:56:56 4: Sub BleTagBattery_BlockingRun (Batterie) - try to connect with public
2019.09.30 17:56:56 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 0, result: handle: 0x001b value: 5e

2019.09.30 17:56:56 4: Sub BleTagBattery_readSensorValue (Batterie) - processing gatttool response: 5e
2019.09.30 17:56:56 4: Sub BleTagBattery_BlockingRun (Batterie) - processing gatttool response for device Sven_Cam1. batteryLevel: 94
2019.09.30 17:56:56 4: Sub BleTagBattery_BlockingRun (Batterie) - device found. device: Test_Cam
2019.09.30 17:56:56 4: Sub BleTagBattery_BlockingRun (Batterie) - device name: iTAG           
2019.09.30 17:56:56 4: Sub BleTagBattery_BlockingRun (Batterie) - device address: FF:FF:C0:17:CB:C6
2019.09.30 17:56:56 4: Sub BleTagBattery_BlockingRun (Batterie) - try to connect with public
2019.09.30 17:57:15 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 0, result: connect error: Transport endpoint is not connected (107)

2019.09.30 17:57:27 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 1, result: connect error: Transport endpoint is not connected (107)

2019.09.30 17:57:30 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 2, result: connect error: Transport endpoint is not connected (107)

2019.09.30 17:57:48 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 3, result: connect error: Transport endpoint is not connected (107)

2019.09.30 17:57:54 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 4, result: connect error: Transport endpoint is not connected (107)

2019.09.30 17:57:54 4: Sub BleTagBattery_readSensorValue (Batterie) - invalid gatttool response
2019.09.30 17:57:54 4: Sub BleTagBattery_BlockingRun (Batterie) - try to connect with random
2019.09.30 17:58:35 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 0, result: connect error: Connection refused (111)

2019.09.30 17:59:16 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 1, result: connect error: Connection refused (111)

2019.09.30 17:59:56 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 2, result: connect error: Connection refused (111)

2019.09.30 18:00:37 4: Sub BleTagBattery_readSensorValue (Batterie) - call gatttool char read loop: 3, result: connect error: Connection refused (111)

2019.09.30 18:00:49 1: Timeout for BleTagBattery_BlockingRun reached, terminated process 11096
2019.09.30 18:00:49 3: (Batterie) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout


jemand ne idee??


Internals:
   CFGFN     
   FUUID      5d8f64be-f33f-ae7c-2687-00c8c07272d1284f
   NAME       Batterie
   NR         43267
   STATE      active
   TYPE       BleTagBattery
   VERSION    0.0.3
   READINGS:
     2019-09-30 17:56:49   state           active
   helper:
Attributes:
   hciDevice  hci0
   room       Anwesenheit
   verbose    5
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 01 Oktober 2019, 00:41:28
Die Readings tauchen bei deinen g-tags auf und nicht im Device bletagbattery, in deinem Fall Sonja_Cam und Sonja_Cam1.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Gasmast3r am 01 Oktober 2019, 09:17:12
Zitat von: mumpitzstuff am 01 Oktober 2019, 00:41:28
Die Readings tauchen bei deinen g-tags auf und nicht im Device bletagbattery, in deinem Fall Sonja_Cam und Sonja_Cam1.
Im log ist alles zu sehen aber er schreibt die readings nicht ins jeweilige Device.

Wie kann ich das ändern?

Gesendet mit Tapatalk
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 01 Oktober 2019, 12:32:11
Setz mal das Attribut disabled aktiv auf 0 bitte und lass es manuell noch einmal laufen. Hattest du das device mal auf disabled stehen und hast dann das Attribut einfach gelöscht? Kann sein, dass es in diesem Fall nicht korrekt zurückgesetzt wird...
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Gasmast3r am 01 Oktober 2019, 12:34:42
Hy habe das jetzt so gelöst,
1 die Batterie Abfrage gelöscht
2 die PM Datei gelöscht
3 Update durchgeführt
4 Batterie Abfrage neu definiert
Und Zack alles geht

Gesendet mit Tapatalk

Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: eispeer am 29 November 2019, 12:48:15
Hallo zusammen.

Ich möchte hier kurz meine Erfahrungen mit dem Modul teilen.

Ich habe 5 GTAGs als Resident Device in FHEM registriert. Ich benutze 2 Bluetooth Dongle am Raspberry.
Der erste (hci0) wird von presenced und lepresenced genutzt um die Resident Devices upzudaten.
Der zweite (hci1), seit heute im Einsatz, wird für dieses Modul BleTagBattery genutzt. Im Attribut hciDevice ist hci1 gesetzt.

Es kam jedoch immer wieder vor, dass bei der Abfrage des Batterie-Status

call gatttool char read loop: X, result: connect error: Transport endpoint is not connected (107)

im Log ausgegeben wurde und kein Batteriestatus ermittelt werden konnte.
Es hat sich herrausgestellt, dass der presenced-Daemon den neuen, zweiten Bluetooth Dongle hci1 einfach benutzt hat, da im Standard dem presenced kein Interface zugewiesen wird.
Das sieht man in der Prozessliste wie folgt:


ps aux
sh -c hcitool name 7C:2F:80:xx:yy:zz 2>/dev/null
hcitool name 7C:2F:80:xx:yy:zz


Dieser Aufruf vom hcitool nimmt sich das erste, verfügbare Interface (hci1) und blockiert es, wenn hci0 vom lepresenced genutzt wird. Somit blockiert auch die BleTagBattery Abfrage.
Leider kann man dem preseced in der Version presenced 10988 2016-03-04 17:27:36Z kein hci Interface per Konfig zuordnen.
Es bleibt einem nur den Aufruf des hcitool anzupassen. Ich habe also

/usr/sbin/presenced

ab der Zeile 364 bis 367:


if( -x "$hcitool")
{
     $return = qx(hcitool name $address 2>/dev/null);
}


wie folgt um das Interface hci0 erweitert.


if( -x "$hcitool")
{
     $return = qx(hcitool -i hci0 name $address 2>/dev/null);
}


Somit bleibt hci1 frei für das BleTagBattery und die Batterieabfrage flutscht problemlos durch.


Mein zweites Problem äusserte sich wie folgt:
Es wurden nur die ersten beiden GTAGs mit einem Batteriestatus versehen. Die übrigen 3 haben nie einen Batteriestatus bekommen.
Die Batterieabfrage wurde immer wieder durch einen Timeout abgebrochen. Scheinbar bevor die letzten 3 Tags abgefragt wurden.
Dies aüßerte sich in den Logs wie folgt:

(GTAGBattery) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout

Es stellte sich heraus, dass ein Timeout immer erfolgte, als eines der ersten beiden Devices abwesend war.
Ein ein Verbose 5 auf dem BleTagBattery Device und ein wenig Logfilerecherche ergab folgendes:


Sub BleTagBattery_Run (GTAGBattery) - start blocking call
Sub BleTagBattery_stateRequest (GTAGBattery) - state request called
Sub BleTagBattery_BlockingRun (GTAGBattery) - device found. device: GTAG_Black1
Sub BleTagBattery_BlockingRun (GTAGBattery) - device name: Gigaset G-tag
Sub BleTagBattery_BlockingRun (GTAGBattery) - device address: 7C:2F:80:xx:yy:zz
Sub BleTagBattery_BlockingRun (GTAGBattery) - tag already saved in hash
Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 0, result: connect error: Connection refused (111)
Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 1, result: connect error: Connection refused (111)
Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 2, result: connect error: Connection refused (111)
Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 3, result: connect error: Connection refused (111)
Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 4, result: connect error: Connection refused (111)
Sub BleTagBattery_readSensorValue (GTAGBattery) - invalid gatttool response
Sub BleTagBattery_BlockingRun (GTAGBattery) - tag not supported
Sub BleTagBattery_BlockingRun (GTAGBattery) - processing gatttool response for device GTAG_Black1. batteryLevel:
Sub BleTagBattery_BlockingRun (GTAGBattery) - device found. device: GTAG_Black2
Sub BleTagBattery_BlockingRun (GTAGBattery) - device name: Gigaset G-tag
Sub BleTagBattery_BlockingRun (GTAGBattery) - device address: 7C:2F:80:aa:bb:cc
Sub BleTagBattery_BlockingRun (GTAGBattery) - tag already saved in hash
Timeout for BleTagBattery_BlockingRun reached, terminated process 15948
(GTAGBattery) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout


Es wurde der erste GTAG abgefragt, obwohl er gar nicht anwesend war. Diese Abfrage (5x) dauert in Summe so lange, dass alle weiteren Abfragen durch einen Timeout abgebrochen werden, wie beim Abfragen des 2. GTAGs zu sehen ist.

Laut Quellcode im Modul dürfte dies nicht vorkommen, da eine Batterieabfrage nur stattfinden soll, wenn der GTAG present ist:

Modul-Code ab Zeile 211:

$deviceList = fhem( "list $device", 1 );

if ( $deviceList =~ m/STATE\s+present/ ) {       


Ein List des Devices erbrachte bei mir folgendes:

list GTAG_Black1:

Internals:
   ADDRESS    7C:2F:80:xx:yy:zz
   CFGFN      FHEM/residents.cfg
   CHANGED   
   DEF        lan-bluetooth 7C:2F:80:xx:yy:zz 127.0.0.1:5222 20
   DeviceName 127.0.0.1:5222
   ...
   STATE      absent
   TYPE       PRESENCE
   Helper:
     DBLOG:
       presence:
         logdb:
           ...
   READINGS:
     2019-11-29 12:00:34   battery         ok
     2019-11-29 12:00:34   batteryLevel    94
     2019-11-28 12:46:48   command_accepted yes
     2019-11-29 12:36:39   device_name     Gigaset G-tag
     2019-11-29 12:29:06   model           lan-bluetooth
     2019-11-29 12:39:39   presence        absent
     2019-11-29 12:36:39   room            HWR LE
     2019-11-29 12:39:39   state           absent
   helper:
     ABSENT_COUNT 5
     CURRENT_STATE present
     CURRENT_TIMEOUT normal
Attributes:
    ...


Vergleicht man die Abfrage aus dem Modulcode und die Ausgabe des Device List wird klar, warum das Battery Modul fälschlich davon ausgeht, dass ein GTAG anwesend ist.
STATE ist einmal absent, nämlich in den Internals und einmal present, nämlich im helper mit CURRENT_STATE present.

Starte ich fhem neu, verschwindet im helper Bereich auch das CURRENT_STATE present. Es kommt aber immer wieder, sobald ein GTAG ein Mal als present erkannt wurde.

Schön ist, dass im helper zwischen dem "CURRENT_STATE" und dem "present" nur ein Leerzeichen ist und in den Internals zwischen "STATE" und "present" mehrere Leerzeichen sind.

Ich habe den Modulcode mal wie folgt angepasst:


$deviceList = fhem( "list $device", 1 );

if ( $deviceList =~ m/STATE\s{2,}present/ ) {


Das Modul soll einen GTAG nur abfragen, wenn mehr als zwei Leerzeichen zwischen STATE und present ist.
Dies funktioniert!
Im Log wird ein nicht anwesender GTAG nun übersprungen und die hinteren GTAGs werden erfolgreich abgefragt:


Sub BleTagBattery_BlockingRun (GTAGBattery) - device found. device: GTAG_Black1
Sub BleTagBattery_BlockingRun (GTAGBattery) - device not present.
Sub BleTagBattery_BlockingRun (GTAGBattery) - device found. device: GTAG_Black2
Sub BleTagBattery_BlockingRun (GTAGBattery) - device not present.
Sub BleTagBattery_BlockingRun (GTAGBattery) - device found. device: GTAG_Green1
Sub BleTagBattery_BlockingRun (GTAGBattery) - device not present.
Sub BleTagBattery_BlockingRun (GTAGBattery) - device found. device: GTAG_Orange1
Sub BleTagBattery_BlockingRun (GTAGBattery) - device name: Gigaset G-tag
Sub BleTagBattery_BlockingRun (GTAGBattery) - device address: 7C:2F:80:aa:bb:cc
Sub BleTagBattery_BlockingRun (GTAGBattery) - tag already saved in hash
Sub BleTagBattery_readSensorValue (GTAGBattery) - call gatttool char read loop: 0, result: handle: 0x001b value: 64
Sub BleTagBattery_readSensorValue (GTAGBattery) - processing gatttool response: 64
Sub BleTagBattery_BlockingRun (GTAGBattery) - processing gatttool response for device GTAG_Orange1. batteryLevel: 100
Sub BleTagBattery_BlockingRun (GTAGBattery) - device found. device: GTAG_Red1
Sub BleTagBattery_BlockingRun (GTAGBattery) - device not present.
Sub BleTagBattery_BlockingRun (GTAGBattery) - device found. device: GTAG_White1
Sub BleTagBattery_BlockingRun (GTAGBattery) - device not present.
Sub BleTagBattery_BlockingDone (GTAGBattery) - set readings batteryLevel and battery of device: GTAG_Orange1
Sub BleTagBattery_BlockingDone (GTAGBattery) - done


Vielleicht helfen meine Erkenntnisse ja irgendjemandem bei der Fehlersuche weiter.
Bin ich vielleicht nicht der einzige, der einen helper Bereich mit fehlerhaftem CURRENT_STATE hat?

Vielleicht kann der Modulautor ja die Anpassung zur Abfrage der Leerzeichen in den Modulcode überführen...

Vielen Dank auf alle Fälle für das Modul.
Peer
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 29 November 2019, 15:16:17
Kann ich tun.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Jamo am 29 November 2019, 15:52:21
Hallo Peer,
super Analyse. Auch ich habe das Problem, das mehrere GTAGs nicht abgefragt werden, und der Batteriestatus nicht aktualisiert wird (oder erst nach mehreren Tagen wo ich dann aber zwischendurch auch FHEM wieder neu starte). Ich habe allerdings nie eine Analyse gemacht, ich dachte das liegt irgendwie an der Bluetooth Verbindung.
Aber ich habe gerade nachgesehen, ich habe auch den helper Bereich mit CURRENT_STATE present.

Den Code habe ich wie von Dir vorgeschlagen schonmal geändert, ich beobachte.

Danke! ! !
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 02 Dezember 2019, 21:18:52
@eispeer: Ich habe mal eine neue Version eingecheckt. Könntest du dir bitte ansehen, ob die bei dir funktioniert? Einfach "update all" und danach "shutdown restart" machen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Jamo am 03 Dezember 2019, 20:32:58
Hallo mumpitzstuff,
ich glaube das funktioniert noch nicht richtig. Ich habe gesehen, das Du den helper auf public gesetzt hast.
Ich habe insgesamt 5 GTAGS, von denen werden nur "Gast"und "Vater"gefunden, hier mal die beiden listings.
Die definitionen sind für alle GTags gleich, alle werden mit collectrord abgeholt.
Die anderen 3 gerden nicht gefunden, obwohl die auch present sind.

Internals:
   FUUID      abcdef-ghij-klmn-1234-af12345e9ecebc14
   NAME       myBleTagBattery
   NR         3812
   STATE      active
   TYPE       BleTagBattery
   VERSION    0.0.4
   READINGS:
     2019-12-03 19:42:36   state           active
   helper:
     Presence_Vater_Orange_collect public
     Presence_Gast_Orange_collect public
Attributes:
   group      SERVER
   room       Energy,Presence,System
   webCmd     statusRequest

Internals:
   ADDRESS    ME:IN:EM:AC:AD:DR
   DEF        lan-bluetooth ME:IN:EM:AC:AD:DR 127.0.0.1:5222 60 60
   DeviceName 127.0.0.1:5222
   FD         37
   FUUID      abcdef-ghij-klmn-1234-af12345e9ecebc14
   INTERVAL_NORMAL 60
   INTERVAL_PRESENT 60
   MODE       lan-bluetooth
   NAME       Presence_Gast_Orange_collect
   NOTIFYDEV  global
   NR         2713
   NTFY_ORDER 50-Presence_Gast_Orange_collect
   PARTIAL   
   STATE      present schlafLE / flurLE,schlafLE,wohnLE
   TYPE       PRESENCE
   READINGS:
     2019-01-28 03:00:00   LastLowBattMailSent 1
     2019-12-03 14:48:01   battery         ok
     2019-12-03 14:48:01   batteryLevel    94
     2019-12-03 08:47:06   command_accepted yes
     2019-12-03 20:28:21   daemon          lepresenced V0.9
     2019-12-03 20:28:21   device_name     Gigaset G-tag
     2019-12-03 20:28:21   model           lan-lepresenced
     2019-12-03 20:28:21   presence        present
     2019-12-03 20:28:21   room            schlafLE
     2019-12-03 20:28:21   rooms           flurLE,schlafLE,wohnLE
     2019-12-03 20:28:21   rssi            -67
     2019-12-03 20:28:21   rssi_flurLE     -71
     2019-12-03 20:28:21   rssi_schlafLE   -67
     2019-12-03 20:28:21   rssi_wohnLE     -73
     2019-12-03 20:21:00   rssi_zeroLE     -75
     2019-12-03 20:28:21   state           present
     2019-12-03 08:47:41   status          present
   helper:
     CURRENT_STATE present
     CURRENT_TIMEOUT normal
     DISABLED   0
     PRESENT_COUNT 0
Attributes:
   absenceThreshold 2
   disable    0
   event-on-change-reading battery,batteryLevel,presence,state
   group      PRESENCE
   room       Presence
   sortby     050
   stateFormat state room / rooms
   verbose    0
   webCmd     statusRequest
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 04 Dezember 2019, 00:13:36
Was meinst du mit helper auf public gesetzt?

Hattest du andere Ergebnisse als du die Änderungen von eispeer übernommen hattest?

Könntest du vielleicht das verbose lvl auf 5 setzen und mir den entsprechenden Logauszug zukommen lassen? Ich würde gern wissen, ob das Modul in einen Timeout rennt oder die anderen Tags nur nicht als anwesend erkennt.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Jamo am 04 Dezember 2019, 09:17:50
Vergiss meinen Kommentar mit helper, das war Unsinn.

Unten der Log. Die devices werden zwar gefunden, aber als 'not present'gemeldet. Also am timeout liegt es nicht.

Zur info: Ich habe 6 GTags, Vater/Mutter/Gast, und RED/White/Black.
Zur Zeit des laufes sind Vater/Gast, und RED/White/Black present.
Alle sind über collectord und lepresenced V0.9 wie folgt eingebunden: lan-bluetooth ME:IN:EM:AC:AD:DR 127.0.0.1:5222 60 60

Ich habe zuerst gedacht es liegt am Stateformat, bei den RED/White/Black hatte ich das stateformat geändert auf "room / rooms" geändert,
damit war das Internal STATE dann auch ohne 'present', also       "STATE      wohnLE / flurLE,schlafLE,wohnLE,zeroLE".
Habe das stateformat jetzt geändert das der Internal STATE jetzt "STATE    present wohnLE / flurLE,schlafLE,wohnLE,zeroLE" ist, aber er findet die trotzdem nicht.

Oder muss der Internal STATE genau 'present' sein?

Danke schonmal falls Du noch eine Idee hast?

PS: Habe jetzt den statformat kompett gelöscht, werden trotzdem nicht als 'present'gefunden. Irgendwie nimmt er immer nur den ersten als present .....


....


2019.12.04 08:16:52 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: handle: 0x001b value: 4b

2019.12.04 08:16:52 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - processing gatttool response: 4b
2019.12.04 08:16:52 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_Vater_Orange_collect. batteryLevel: 75
2019.12.04 08:16:52 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Vater_iPhone_BT
2019.12.04 08:16:52 5: Cmd: >list Presence_Vater_iPhone_BT<
2019.12.04 08:16:52 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: iPhoneXL
2019.12.04 08:16:52 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.04 08:16:52 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public

2019.12.04 08:16:53 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect error: Software caused connection abort (103)

2019.12.04 08:16:53 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with random
2019.12.04 08:16:53 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect: No route to host (113)

2019.12.04 08:16:53 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - tag not supported
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_Vater_iPhone_BT. batteryLevel:
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_GTag_Black_collect
2019.12.04 08:16:53 5: Cmd: >list Presence_GTag_Black_collect<
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_GTag_RED_collect
2019.12.04 08:16:53 5: Cmd: >list Presence_GTag_RED_collect<
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_GTag_White_collect
2019.12.04 08:16:53 5: Cmd: >list Presence_GTag_White_collect<
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Gast_Orange_collect
2019.12.04 08:16:53 5: Cmd: >list Presence_Gast_Orange_collect<
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - tag already saved in hash
2019.12.04 08:16:53 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect: No route to host (113)

2019.12.04 08:16:53 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - tag not supported
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_Gast_Orange_collect. batteryLevel:
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Gast_iBTon_collect
2019.12.04 08:16:53 5: Cmd: >list Presence_Gast_iBTon_collect<
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Mutter_Green_collect
2019.12.04 08:16:53 5: Cmd: >list Presence_Mutter_Green_collect<
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Mutter_iBTon_collect
2019.12.04 08:16:53 5: Cmd: >list Presence_Mutter_iBTon_collect<
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
2019.12.04 08:16:53 5: Cmd: >{BlockingStart('25520')}<
2019.12.04 08:16:53 5: Cmd: >{BleTagBattery_BlockingDone('myBleTagBattery|Presence_Vater_Orange_collect|75|none')}<
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - set readings batteryLevel and battery of device: Presence_Vater_Orange_collect
2019.12.04 08:16:53 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - done
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 04 Dezember 2019, 11:06:15
Kannst du mir bitte ein list vom ersten g-tag (den funktionierenden) zukommen lassen und einen der danach nicht erkannt wird?
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Jamo am 04 Dezember 2019, 11:26:47
Gerne:
Gast + White.

Internals:
   ADDRESS    ME:IN:EI:IP:AD:DR
   DEF        lan-bluetooth ME:IN:EI:IP:AD:DR 127.0.0.1:5222 60 60
   DeviceName 127.0.0.1:5222
   FD         37
   FUUID      tada
   INTERVAL_NORMAL 60
   INTERVAL_PRESENT 60
   MODE       lan-bluetooth
   NAME       Presence_Gast_Orange_collect
   NOTIFYDEV  global
   NR         2713
   NTFY_ORDER 50-Presence_Gast_Orange_collect
   PARTIAL
   STATE      present flurLE / flurLE,schlafLE
   TYPE       PRESENCE
   READINGS:
     2019-01-28 08:55:47   BatterieWechsel 28.01.2019 (7 Monate - last: 16.04.2018 / 07.10.2017)
     2019-01-28 03:00:00   LastLowBattMailSent 1
     2019-04-24 13:33:21   absentSince     2019-04-24 13:33:21
     2019-12-04 08:49:42   battery         ok
     2019-12-04 08:49:42   batteryLevel    94
     2019-12-04 08:59:26   command_accepted yes
     2019-12-04 11:16:38   daemon          lepresenced V0.9
     2019-12-04 11:16:38   device_name     Gigaset G-tag
     2019-12-04 11:16:38   lastabsent      2019-11-17 18:00:39
     2019-12-04 11:16:38   lastpresent     2019-12-04 11:16:38
     2019-12-04 11:16:38   model           lan-lepresenced
     2019-12-04 11:16:38   presence        present
     2019-04-24 13:42:07   presentSince    2019-04-24 13:42:07
     2019-12-04 11:16:38   room            flurLE
     2019-12-04 11:16:38   rooms           flurLE,schlafLE
     2019-12-04 11:16:38   rssi            -70
     2019-12-04 11:16:38   rssi_flurLE     -70
     2019-12-04 11:16:38   rssi_schlafLE   -71
     2019-12-04 09:52:27   rssi_wohnLE     -71
     2019-12-04 09:52:27   rssi_zeroLE     -78
     2019-12-04 11:16:38   state           present
     2019-12-04 08:59:38   status          present
   helper:
     CURRENT_STATE present
     CURRENT_TIMEOUT normal
     DISABLED   0
     PRESENT_COUNT 0
Attributes:
   absenceThreshold 2
   comment    4C:66:41:3C:63:CF
   event-on-change-reading battery,batteryLevel,presence,state
   group      PRESENCE
   room       Presence
   sortby     050
   stateFormat state room / rooms
   userReadings status:(present|absent) { ReadingsVal($name,"state","nA") eq "present" ? "present" : "absent" },
absentSince:status:.absent   {if (ReadingsVal($name,"status","nA") eq "absent")  {ReadingsTimestamp($name,"status","nA")} else {ReadingsVal($name,"absentSince","nA")}},
presentSince:status:.present {if (ReadingsVal($name,"status","nA") eq "present") {ReadingsTimestamp($name,"status","nA")} else {ReadingsVal($name,"presentSince","nA")}},
lastpresent {if (ReadingsVal($name,"state","nA") eq "present") {ReadingsTimestamp($name, "state", "nA")} else {ReadingsVal($name,"lastpresent","nA")}},
lastabsent  {if (ReadingsVal($name,"state","nA") eq "absent")  {ReadingsTimestamp($name, "state", "nA")} else {ReadingsVal($name,"lastabsent","nA")}}
   verbose    0
   webCmd     statusRequest


Internals:
   ADDRESS    ME:IN:EI:IP:AD:DR
   CHANGED
   DEF        lan-bluetooth ME:IN:EI:IP:AD:DR 127.0.0.1:5222 60 60
   DeviceName 127.0.0.1:5222
   FD         36
   FUUID      tada
   INTERVAL_NORMAL 60
   INTERVAL_PRESENT 60
   MODE       lan-bluetooth
   NAME       Presence_GTag_White_collect
   NOTIFYDEV  global
   NR         2671
   NTFY_ORDER 50-Presence_GTag_White_collect
   PARTIAL
   STATE      present flurLE / flurLE,schlafLE
   TYPE       PRESENCE
   READINGS:
     2019-02-26 00:23:53   BatterieWechsel 01.03.2019 (9 Monate - last: 01.06.2018)
     2019-11-27 04:30:56   battery         ok
     2019-11-27 04:30:56   batteryLevel    47
     2019-12-04 08:55:38   command_accepted yes
     2019-12-04 11:15:02   daemon          lepresenced V0.9
     2019-12-04 11:15:02   device_name     Gigaset G-tag
     2019-12-04 11:15:02   model           lan-lepresenced
     2019-12-04 11:15:02   presence        present
     2019-12-04 11:15:02   room            flurLE
     2019-12-04 11:15:02   rooms           flurLE,schlafLE
     2019-12-04 11:15:02   rssi            -72
     2019-12-04 11:15:02   rssi_flurLE     -72
     2019-12-04 11:15:02   rssi_schlafLE   -81
     2019-12-04 09:51:39   rssi_wohnLE     -49
     2019-12-04 09:51:38   rssi_zeroLE     -85
     2019-12-04 11:15:02   state           present
   helper:
     CURRENT_STATE present
     CURRENT_TIMEOUT normal
     PRESENT_COUNT 0
Attributes:
   absenceThreshold 3
   alias      PresenceWhite
   event-on-change-reading battery,batteryLevel,presence,state
   group      PRESENCE,SERVER
   room       Favourites,Presence
   sortby     042
   stateFormat {myPresenceGTagCollectStateFormat($name)}
   verbose    0
   webCmd     statusRequest
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 04 Dezember 2019, 12:49:37
Das ist wirklich mehr als eigenartig. Es wird jeweils das richtige Device abgefragt, allerdings schlägt ab dem 2. diese Abfrage fehl:

if ( $deviceList =~ m/\s+STATE\s+present/ )

Wenn ich jetzt aber beide von dir geposteten Listings bei https://regex101.com/ (https://regex101.com/) eingebe und als regexp:

\s+STATE\s+present

habe ich bei beiden Devices ein Match. Ich kann mir deshalb nur noch vorstellen, das diese Zeile:

$deviceList = fhem( "list $device", 1 );

manchmal Bullshit ausgibt.

Könntest du bitte mal lokal versuchen die Zeile 263 von:

Log3 $name, 4, "Sub BleTagBattery_BlockingRun ($name) - device not present.";

in das hier zu ändern?

Log3 $name, 4, "Sub BleTagBattery_BlockingRun ($name) - device not present.\n".$deviceList;

Danach "shutdown restart" nicht vergessen und bletagsbattery einmal starten und das Logfile ansehen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Jamo am 04 Dezember 2019, 14:15:07
Mach ich gleich heut Abend, Danke!
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Jamo am 04 Dezember 2019, 21:17:28
So, alles gemacht. Es werden alle Devices gefunden, das ist es also nicht. Es gibt aber 2 Sachen:

1) stateformat:. Wenn ich das "attr stateformat room/rooms" setze, ist der Internal STATE "STATE      flurLE / flurLE,schlafLE", damit wird das device als absent erkannt.
    Das kann ich ändern, aber schöner wäre es, wenn der batteryLevel unabhängig vom stateformat gesetz würde.

2) Timing:
    Schau Dir mal im Logfile die Zeilen 2019.12.04 20:59:00" ünd "2019.12.04 20:59:01" unter dem list vom Presence_Vater_iPhone_BT an.
    Man sieht, das der erste Presence_Vater_Orange_collect und der 2-te Presence_GTag_Black_collect gefunden werden, das gatttool liefert für beide "4b" zurück.
    Danach, also 3 Sekunden später, also ab Zeile "2019.12.04 20:59:04", werden die nächsten GTags (RED/White/Gast) gefunden, aber das gattool liefert nur noch "connect error" oder "no route to host" zurück.
    Da stimmt irgendwas mit dem gattool Timing nicht, oder?? Das geht dem gattool wohl zu schnell :-)

2019.12.04 20:59:00 4: Sub BleTagBattery_Run (myBleTagBattery) - start blocking call
2019.12.04 20:59:00 5: Sub BleTagBattery_stateRequest (myBleTagBattery) - state request called
2019.12.04 20:59:00 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Vater_Orange_collect
2019.12.04 20:59:00 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.04 20:59:00 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.04 20:59:00 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - tag already saved in hash
2019.12.04 20:59:01 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: handle: 0x001b value: 4b

2019.12.04 20:59:01 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - processing gatttool response: 4b
2019.12.04 20:59:01 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_Vater_Orange_collect. batteryLevel: 75
2019.12.04 20:59:01 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Vater_iPhone_BT
2019.12.04 20:59:01 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
Internals:
   ADDRESS    ME:IN:EM:AC:AD:DR
   DEF        lan-bluetooth ME:IN:EM:AC:AD:DR 127.0.0.1:5222 60 60
   DeviceName 127.0.0.1:5222
   FUUID      tada
   INTERVAL_NORMAL 60
   INTERVAL_PRESENT 60
   MODE       lan-bluetooth
   NAME       Presence_Vater_iPhone_BT
   NOTIFYDEV  global
   NR         2621
   NTFY_ORDER 50-Presence_Vater_iPhone_BT
   STATE      maybe absent /
   TYPE       PRESENCE
   READINGS:
     2019-12-04 20:48:49   absentSince     2019-12-04 20:48:49
     2019-12-04 20:28:16   command_accepted yes
     2019-12-04 20:57:03   device_name     iPhoneXL
     2019-12-04 20:48:49   lastAbsent      04.12.2019 20:48:49
     2019-12-04 20:57:03   lastPresent     04.12.2019 20:57:03
     2019-12-04 20:58:11   lastabsent      2019-12-04 20:52:01
     2019-12-04 20:58:11   lastpresent     2019-12-04 20:58:11
     2019-12-04 20:28:08   model           lan-bluetooth
     2019-12-04 20:58:11   presence        maybe absent
     2019-12-04 20:53:14   presentSince    2019-12-04 20:53:14
     2019-12-04 20:58:11   room           
     2019-12-04 20:58:11   rooms           
     2019-12-04 20:58:11   rssi           
     2019-12-04 20:58:11   state           maybe absent
     2019-12-04 20:53:14   status          present
   helper:
     ABSENT_COUNT 1
     CURRENT_STATE present
     CURRENT_TIMEOUT normal
Attributes:
   absenceThreshold 3
   alias      iPhoneXL_BT
   event-on-change-reading status,state
   group      PRESENCE,SERVER
   room       Favourites,Presence
   sortby     0390
   stateFormat state / rooms
   timestamp-on-change-reading status
   userReadings status:(present|absent) { ReadingsVal($name,"state","nA") eq "present" ? "present" : "absent" },
absentSince:status:.absent   {if (ReadingsVal($name,"status","nA") eq "absent")  {ReadingsTimestamp($name,"status","nA")} else {ReadingsVal($name,"absentSince","nA")}},
presentSince:status:.present {if (ReadingsVal($name,"status","nA") eq "present") {ReadingsTimestamp($name,"status","nA")} else {ReadingsVal($name,"presentSince","nA")}},
lastpresent {if (ReadingsVal($name,"status","nA") eq "present") {ReadingsTimestamp($name, "state", "nA")} else {ReadingsVal($name,"lastpresent","nA")}},
lastabsent {if (ReadingsVal($name,"status","nA") eq "absent") {ReadingsTimestamp($name, "state", "nA")} else {ReadingsVal($name,"lastabsent","nA")}},
lastPresent:present {ReadingsTimestamp($name,"state","") =~ /^(\d+)-(\d+)-(\d+)\s(\d+:\d+:\d+)$/;; "$3.$2.$1 $4"},
lastAbsent:absent {ReadingsTimestamp($name,"state","") =~ /^(\d+)-(\d+)-(\d+)\s(\d+:\d+:\d+)$/;; "$3.$2.$1 $4"}
   verbose    0
   webCmd     statusRequest

2019.12.04 20:59:01 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_GTag_Black_collect
2019.12.04 20:59:01 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.04 20:59:01 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.04 20:59:01 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
2019.12.04 20:59:04 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: handle: 0x001b value: 4b

2019.12.04 20:59:04 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - processing gatttool response: 4b
2019.12.04 20:59:04 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_GTag_Black_collect. batteryLevel: 75
2019.12.04 20:59:04 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_GTag_RED_collect
2019.12.04 20:59:04 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.04 20:59:04 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.04 20:59:04 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
2019.12.04 20:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect error: Software caused connection abort (103)

2019.12.04 20:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with random
2019.12.04 20:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect: No route to host (113)

2019.12.04 20:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - tag not supported
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_GTag_RED_collect. batteryLevel:
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_GTag_White_collect
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
2019.12.04 20:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect: No route to host (113)

2019.12.04 20:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with random
2019.12.04 20:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect: No route to host (113)

2019.12.04 20:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - tag not supported
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_GTag_White_collect. batteryLevel:
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Gast_Orange_collect
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
2019.12.04 20:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect: No route to host (113)

2019.12.04 20:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with random
2019.12.04 20:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect: No route to host (113)

2019.12.04 20:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - tag not supported
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_Gast_Orange_collect. batteryLevel:
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Gast_iBTon_collect
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
Internals:
   ADDRESS    ME:IN:EM:AC:AD:DR
   DEF        lan-bluetooth ME:IN:EM:AC:AD:DR 127.0.0.1:5222 60 60
   DeviceName 127.0.0.1:5222
   FUUID      tada
   INTERVAL_NORMAL 60
   INTERVAL_PRESENT 60
   MODE       lan-bluetooth
   NAME       Presence_Gast_iBTon_collect
   NOTIFYDEV  global
   NR         2717
   NTFY_ORDER 50-Presence_Gast_iBTon_collect
   STATE      disabled /
   TYPE       PRESENCE
   READINGS:
     2019-06-07 00:20:16   absentSince     2019-06-07 00:20:16
     2019-11-02 18:00:54   command_accepted yes
     2019-08-04 08:55:37   device_name     iPhone
     2019-12-04 20:28:14   lastabsent      2019-12-04 20:28:14
     2019-12-04 20:28:14   lastpresent     2019-08-04 08:56:09
     2019-12-04 20:28:08   model           lan-bluetooth
     2019-08-04 08:57:23   presence        absent
     2019-06-07 00:14:22   presentSince    2019-06-07 00:14:22
     2019-11-02 18:00:02   room           
     2019-11-02 18:00:02   rooms           
     2019-11-02 18:00:02   rssi           
     2019-12-04 20:28:14   state           disabled
     2019-11-02 16:09:31   status          absent
   helper:
     ABSENT_COUNT 1
     DISABLED   1
     PRESENT_COUNT 0
Attributes:
   absenceThreshold 2
   disable    1
   event-on-change-reading presence,state
   group      PRESENCE
   room       Presence
   sortby     049
   stateFormat state / rooms
   timestamp-on-change-reading presence
   userReadings status:(present|absent) { ReadingsVal($name,"state","nA") eq 'present' ? "present" : "absent" },
absentSince:status:.absent   {if (ReadingsVal($name,"status","nA") eq "absent")  {ReadingsTimestamp($name,"status","nA")} else {ReadingsVal($name,"absentSince","nA")}},
presentSince:status:.present {if (ReadingsVal($name,"status","nA") eq "present") {ReadingsTimestamp($name,"status","nA")} else {ReadingsVal($name,"presentSince","nA")}},
lastpresent {if (ReadingsVal($name,"status","nA") eq "present") {ReadingsTimestamp($name, "state", "nA")} else {ReadingsVal($name,"lastpresent","nA")}},
lastabsent {if (ReadingsVal($name,"status","nA") eq "absent") {ReadingsTimestamp($name, "state", "nA")} else {ReadingsVal($name,"lastabsent","nA")}}
   verbose    0
   webCmd     statusRequest

2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Mutter_Green_collect
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
Internals:
   ADDRESS    ME:IN:EM:AC:AD:DR
   DEF        lan-bluetooth ME:IN:EM:AC:AD:DR 127.0.0.1:5222 60 60
   DeviceName 127.0.0.1:5222
   FUUID      tada
   INTERVAL_NORMAL 60
   INTERVAL_PRESENT 60
   MODE       lan-bluetooth
   NAME       Presence_Mutter_Green_collect
   NOTIFYDEV  global
   NR         2687
   NTFY_ORDER 50-Presence_Mutter_Green_collect
   STATE      absent  /
   TYPE       PRESENCE
   READINGS:
     2019-05-24 23:31:11   BatterieWechsel 20.05.2019 (1 Jahr, last 05.05.2018)
     2019-12-02 07:11:35   absentSince     2019-12-02 07:11:35
     2019-12-01 23:22:48   battery         ok
     2019-12-01 23:22:48   batteryLevel    75
     2019-12-04 20:28:16   command_accepted yes
     2019-12-02 07:09:52   daemon          lepresenced V0.9
     2019-12-02 07:09:52   device_name     Gigaset G-tag
     2019-12-04 20:58:38   lastabsent      2019-12-04 20:58:38
     2019-12-04 20:58:38   lastpresent     2019-12-02 07:09:52
     2019-12-04 20:28:08   model           lan-bluetooth
     2019-12-04 20:58:38   presence        absent
     2019-12-01 18:34:42   presentSince    2019-12-01 18:34:42
     2019-12-04 20:58:38   room           
     2019-12-04 20:58:38   rooms           
     2019-12-04 20:58:38   rssi           
     2019-12-02 07:09:52   rssi_flurLE     -89
     2019-12-02 07:09:45   rssi_schlafLE   -75
     2019-12-02 07:09:50   rssi_wohnLE     -82
     2019-12-02 07:09:33   rssi_zeroLE     -73
     2019-12-04 20:58:38   state           absent
     2019-12-02 07:11:35   status          absent
   helper:
     ABSENT_COUNT 1
     CURRENT_TIMEOUT normal
Attributes:
   absenceThreshold 2
   event-on-change-reading battery,batteryLevel,status,state
   group      PRESENCE
   room       Presence
   sortby     063
   stateFormat state room / rooms
   timestamp-on-change-reading status
   userReadings status:(present|absent) { ReadingsVal($name,"state","nA") eq 'present' ? "present" : "absent" },
absentSince:status:.absent   {if (ReadingsVal($name,"status","nA") eq "absent")  {ReadingsTimestamp($name,"status","nA")} else {ReadingsVal($name,"absentSince","nA")}},
presentSince:status:.present {if (ReadingsVal($name,"status","nA") eq "present") {ReadingsTimestamp($name,"status","nA")} else {ReadingsVal($name,"presentSince","nA")}},
lastpresent {if (ReadingsVal($name,"state","nA") eq "present") {ReadingsTimestamp($name, "state", "nA")} else {ReadingsVal($name,"lastpresent","nA")}},
lastabsent  {if (ReadingsVal($name,"state","nA") eq "absent")  {ReadingsTimestamp($name, "state", "nA")} else {ReadingsVal($name,"lastabsent","nA")}}
   verbose    0
   webCmd     statusRequest

2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Mutter_iBTon_collect
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
Internals:
   ADDRESS    ME:IN:EM:AC:AD:DR
   DEF        lan-bluetooth ME:IN:EM:AC:AD:DR 127.0.0.1:5222 60 60
   DeviceName 127.0.0.1:5222
   FUUID      toda
   INTERVAL_NORMAL 60
   INTERVAL_PRESENT 60
   MODE       lan-bluetooth
   NAME       Presence_Mutter_iBTon_collect
   NOTIFYDEV  global
   NR         2684
   NTFY_ORDER 50-Presence_Mutter_iBTon_collect
   STATE      absent /
   TYPE       PRESENCE
   READINGS:
     2019-12-02 07:11:19   absentSince     2019-12-02 07:11:19
     2019-12-04 20:28:16   command_accepted yes
     2019-12-02 07:08:20   device_name     iPhone7
     2019-12-04 20:58:59   lastabsent      2019-12-04 20:58:59
     2019-12-04 20:58:59   lastpresent     2019-12-02 07:10:07
     2019-12-04 20:28:08   model           lan-bluetooth
     2019-12-04 20:58:59   presence        absent
     2019-12-02 06:28:11   presentSince    2019-12-02 06:28:11
     2019-12-04 20:58:59   room           
     2019-12-04 20:58:59   rooms           
     2019-12-04 20:58:59   rssi           
     2019-12-04 20:58:59   state           absent
     2019-12-02 07:11:19   status          absent
   helper:
     ABSENT_COUNT 2
     CURRENT_TIMEOUT normal
Attributes:
   absenceThreshold 3
   event-on-change-reading status,state
   genericDeviceType OccupancySensor
   group      PRESENCE
   room       Presence
   sortby     060
   stateFormat state / rooms
   timestamp-on-change-reading status
   userReadings status:(present|absent) { ReadingsVal($name,"state","nA") eq "present" ? "present" : "absent" },
absentSince:status:.absent   {if (ReadingsVal($name,"status","nA") eq "absent")  {ReadingsTimestamp($name,"status","nA")} else {ReadingsVal($name,"absentSince","nA")}},
presentSince:status:.present {if (ReadingsVal($name,"status","nA") eq "present") {ReadingsTimestamp($name,"status","nA")} else {ReadingsVal($name,"presentSince","nA")}},
lastpresent {if (ReadingsVal($name,"status","nA") eq "present") {ReadingsTimestamp($name, "state", "nA")} else {ReadingsVal($name,"lastpresent","nA")}},
lastabsent {if (ReadingsVal($name,"status","nA") eq "absent") {ReadingsTimestamp($name, "state", "nA")} else {ReadingsVal($name,"lastabsent","nA")}}
   verbose    0
   webCmd     statusRequest

2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - set readings batteryLevel and battery of device: Presence_Vater_Orange_collect
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - setting saved into hash: public
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - set readings batteryLevel and battery of device: Presence_GTag_Black_collect
2019.12.04 20:59:05 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - done
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 05 Dezember 2019, 02:44:14
Ich habe jetzt mal etwas gebastelt. In dieser Version sollte der presence status vom reading und nicht mehr vom internal abhängen. Außerdem habe ich wieder 2 Versuche aktiviert und zusätzlich einen workaround für dieses "no route to host". Ob das jetzt was bringt kann ich nicht sagen.
Dummerweise muss man für den workaround hcitool oder hciconfig aufrufen, beides erfordert jedoch admin Rechte. Deshalb ist folgendes notwendig:

sudo apt-get install libcap2-bin
sudo setcap 'cap_net_raw,cap_net_admin+eip' `which hciconfig`


Danach kann man hciconfig ohne sudo aufrufen bzw. fhem kann es für den workaround aufrufen.

Wenn du das wieder zurück bauen möchtest, dann mach einfach:

sudo setcap -r `which hciconfig`

Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Jamo am 05 Dezember 2019, 09:04:17
Jetzt siehts so aus :-(

2019.12.05 08:54:53 4: Sub BleTagBattery_Run (myBleTagBattery) - start blocking call
2019.12.05 08:54:53 5: Sub BleTagBattery_stateRequest (myBleTagBattery) - state request called
2019.12.05 08:54:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Vater_Orange_collect
2019.12.05 08:54:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.05 08:54:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.05 08:54:53 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
connect error: Transport endpoint is not connected (107)
2019.12.05 08:55:01 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: handle: 0x001b value: 42

2019.12.05 08:55:01 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - processing gatttool response: 42
2019.12.05 08:55:01 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_Vater_Orange_collect. batteryLevel: 66
2019.12.05 08:55:01 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Vater_iPhone_BT
2019.12.05 08:55:01 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: iPhoneXL
2019.12.05 08:55:01 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.05 08:55:01 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
2019.12.05 08:55:02 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect error: Software caused connection abort (103)

2019.12.05 08:55:02 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call hcitool lescan, result: Can't set advertise mode on hci0: Network is down (100)

connect error: Transport endpoint is not connected (107)
connect error: Transport endpoint is not connected (107)
connect error: Function not implemented (38)
2019.12.05 08:55:47 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 1, result: connect error: Connection refused (111)

2019.12.05 08:55:47 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call hcitool lescan, result:
2019.12.05 08:55:50 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.05 08:55:50 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with random
2019.12.05 08:56:32 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect error: Connection refused (111)

2019.12.05 08:56:32 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call hcitool lescan, result:
2019.12.05 08:57:17 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 1, result: connect error: Connection refused (111)

2019.12.05 08:57:17 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call hcitool lescan, result:
2019.12.05 08:57:20 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.05 08:57:20 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - tag not supported
2019.12.05 08:57:20 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_Vater_iPhone_BT. batteryLevel:
2019.12.05 08:57:20 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_GTag_Black_collect
2019.12.05 08:57:20 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.05 08:57:20 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.05 08:57:20 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
2019.12.05 08:57:25 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect error: Transport endpoint is not connected (107)

2019.12.05 08:57:25 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call hcitool lescan, result:
2019.12.05 08:57:34 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 1, result: connect error: Transport endpoint is not connected (107)

2019.12.05 08:57:34 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call hcitool lescan, result:
2019.12.05 08:57:37 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.05 08:57:37 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with random
2019.12.05 08:58:17 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect error: Connection refused (111)

2019.12.05 08:58:17 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call hcitool lescan, result:
2019.12.05 08:59:02 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 1, result: connect error: Connection refused (111)

2019.12.05 08:59:02 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call hcitool lescan, result:
2019.12.05 08:59:05 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.05 08:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - tag not supported
2019.12.05 08:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_GTag_Black_collect. batteryLevel:
2019.12.05 08:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_GTag_RED_collect
2019.12.05 08:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.05 08:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.05 08:59:05 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
2019.12.05 08:59:13 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect error: Function not implemented (38)

2019.12.05 08:59:13 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call hcitool lescan, result:
2019.12.05 08:59:21 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 1, result: connect error: Function not implemented (38)

2019.12.05 08:59:21 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call hcitool lescan, result:
2019.12.05 08:59:24 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.05 08:59:24 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with random
2019.12.05 08:59:53 1: Timeout for BleTagBattery_BlockingRun reached, terminated process 5474
2019.12.05 08:59:53 3: (myBleTagBattery) Sub BleTagBattery_BlockingAborted - BlockingCall process terminated unexpectedly: timeout
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 05 Dezember 2019, 10:39:33
Irgendwie wird der verwendete Bluetooth Adapter von einem anderen Programm verwendet z.b. lepresenced oder das Ding stürzt aus anderen Gründen ab. Bist du sicher, das dieser Adapter Exklusiv genutzt werden kann und niemand sonst darauf zugreift?
Steht irgendwas im syslog bzw. sieht man was wenn man:

dmesg 

in der Shell aufruft?
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Jamo am 05 Dezember 2019, 11:06:59
Mmmh - ich habe noch die 74_XiaomiBTLESens für die Blumen per Bluetooth eingebunden, die benutzen auch hci0 soweit ich weiss.
Die machen alle 4 Stunden einen check der Blumen Sensoren. Das sollte doch nicht mit dem BleTagBattery Aufruf in die Quere kommen, oder?
Dann noch presenced / lepresenced mit collectord für Handy/GTAG presence Erkennung. Insgesamt habe ich 3 Raspberry mit BT/BTLE mit lepresence/presence (Räume flurLE,wohnLE,zeroLE), und der Intel NUC (Raum schlafLE), der das ganze über collectord in fhem einsammelt. 

Aber das versteh ich dann nicht, heisst das, dass z.B. 74_BleTagBattery einen Adapter exclusiv belegt, und das Modul 74_XiaomiBTLESens ebenfalls?
Ich dachte immer, das 'lescan' (oder gattool) nur einen String zurückliefert, der dann vom jeweiligen Modul gelesen wird.
Und dann verstehe ich auch nicht, wieso es bei den ersten beiden Presence_Vater_Orange_collect und Presence_GTag_Black_collect funktioniert (wie in Antwort #135), aber danach nicht mehr. 

Wie kann /muss ich das ändern? Danke!

Eispeer hat ja in Antwort #124  so ein ähnliches Problem gelöst glaube ich...
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 05 Dezember 2019, 12:41:09
lepresenced und vielleicht auch presenced usw. scannen nach USB Geräten und belegen bei diesem Vorgang den Adapter exklusiv! Wenn jetzt mein Modul kommt, dann stiehlt es sich für kurze Zeit den exklusiven Zugriff. Lepresenced merkt das aber nach einigen Sekunden und holt sich den Zugriff dann zurück.

Wenn du mal alle presenced/lepresenced Dinge auf dem Gerät temporär deaktivierst, dann sollten vermutlich auch deine Gtags alle vom Modul gefunden werden. 
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Jamo am 05 Dezember 2019, 21:59:58
DANKE! :-)
Nach einem ''sudo service lepresenced stop'' läuft auch deine originale erste Version 0.0.4 sauber durch. Siehe unten.

Ich habe dann nur noch if ( $deviceList =~ m/\s+\d+-\d+-\d+\s+\d+:\d+:\d+\s+state\s+present/ ) { mit eingebaut, damit die GTags auch mit 'attr stateformat ....' als present gefunden werden.

Die 1) Lösung für mich das ich den lepresenced über ein "at device" stoppe, dann den BleTagBattery statusrequest starte, und danach den lepresenced wieder starte.
Die 2) Lösung ist einen 2-ten Bluetooth dongle anstecken, und BleTagBattery auf hci1 konfigurieren.


2019.12.05 20:42:42 4: Sub BleTagBattery_Run (myBleTagBattery) - start blocking call
2019.12.05 20:42:42 5: Sub BleTagBattery_stateRequest (myBleTagBattery) - state request called
2019.12.05 20:42:42 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Vater_Orange_collect
2019.12.05 20:42:42 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.05 20:42:42 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.05 20:42:42 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
2019.12.05 20:42:46 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: handle: 0x001b value: 4b

2019.12.05 20:42:46 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - processing gatttool response: 4b
2019.12.05 20:42:46 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_Vater_Orange_collect. batteryLevel: 75
2019.12.05 20:42:46 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Vater_iPhone_BT
2019.12.05 20:42:46 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: iPhoneXL
2019.12.05 20:42:46 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.05 20:42:46 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
2019.12.05 20:43:26 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect error: Connection refused (111)

2019.12.05 20:43:26 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.05 20:43:26 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with random
2019.12.05 20:44:07 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect error: Connection refused (111)

2019.12.05 20:44:07 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.05 20:44:07 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - tag not supported
2019.12.05 20:44:07 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_Vater_iPhone_BT. batteryLevel:
2019.12.05 20:44:07 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_GTag_Black_collect
2019.12.05 20:44:07 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.05 20:44:07 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.05 20:44:07 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
2019.12.05 20:44:10 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: handle: 0x001b value: 4b

2019.12.05 20:44:10 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - processing gatttool response: 4b
2019.12.05 20:44:10 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_GTag_Black_collect. batteryLevel: 75
2019.12.05 20:44:10 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_GTag_RED_collect
2019.12.05 20:44:10 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.05 20:44:10 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: 7ME:IN:EM:AC:AD:DR
2019.12.05 20:44:10 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - tag already saved in hash
2019.12.05 20:44:15 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: handle: 0x001b value: 4b

2019.12.05 20:44:15 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - processing gatttool response: 4b
2019.12.05 20:44:15 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_GTag_RED_collect. batteryLevel: 75
2019.12.05 20:44:15 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_GTag_White_collect
2019.12.05 20:44:15 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.05 20:44:15 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.05 20:44:15 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
2019.12.05 20:44:19 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: handle: 0x001b value: 25

2019.12.05 20:44:19 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - processing gatttool response: 25
2019.12.05 20:44:19 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_GTag_White_collect. batteryLevel: 37
2019.12.05 20:44:19 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Gast_Orange_collect
2019.12.05 20:44:19 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device name: Gigaset G-tag
2019.12.05 20:44:19 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device address: ME:IN:EM:AC:AD:DR
2019.12.05 20:44:19 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with public
2019.12.05 20:44:22 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect error: Function not implemented (38)

2019.12.05 20:44:22 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.05 20:44:22 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - try to connect with random
2019.12.05 20:45:03 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - call gatttool char read loop: 0, result: connect error: Connection refused (111)

2019.12.05 20:45:03 4: Sub BleTagBattery_readSensorValue (myBleTagBattery) - invalid gatttool response
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - tag not supported
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - processing gatttool response for device Presence_Gast_Orange_collect. batteryLevel:
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Gast_iBTon_collect
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Mutter_Green_collect
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device found. device: Presence_Mutter_iBTon_collect
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingRun (myBleTagBattery) - device not present.
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - setting saved into hash: public
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - set readings batteryLevel and battery of device: Presence_Vater_Orange_collect
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - setting saved into hash: public
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - set readings batteryLevel and battery of device: Presence_GTag_Black_collect
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - set readings batteryLevel and battery of device: Presence_GTag_RED_collect
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - setting saved into hash: public
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - set readings batteryLevel and battery of device: Presence_GTag_White_collect
2019.12.05 20:45:03 4: Sub BleTagBattery_BlockingDone (myBleTagBattery) - done
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 06 Dezember 2019, 10:02:25
Die Erkennung werde ich ändern und einchecken, dann ist das dauerhaft im Modul enthalten.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Jamo am 06 Dezember 2019, 10:46:59
Danke nochmal für die Hilfe und Geduld. Im übrigen bin ich auch leidenschaftlicher User deines 57_GCALVIEW moduls.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: eispeer am 10 Dezember 2019, 08:19:53
Zitat von: mumpitzstuff am 02 Dezember 2019, 21:18:52
@eispeer: Ich habe mal eine neue Version eingecheckt. Könntest du dir bitte ansehen, ob die bei dir funktioniert? Einfach "update all" und danach "shutdown restart" machen.

Hallo @mumpitzstuff,
ich habe gerade die letzte Version (0.0.5) getestet. Bei mir sieht es gut aus.

Vielen Dank,
Peer
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: SouzA am 29 März 2020, 13:57:48
Hi,
ich habe mich gefragt, warum nur ab und zu meine Gtags aktualisiert werden.
Habe mal Verbose 5 laufen lassen.
Kann mir jemand was zu den Fehlermeldungen sagen?

2020.03.29 13:48:10 4: Sub BleTagBattery_Run (Gtags_Battery) - start blocking call
2020.03.29 13:48:10 5: Sub BleTagBattery_stateRequest (Gtags_Battery) - state request called
2020.03.29 13:48:10 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - device found. device: 1_Gtag
2020.03.29 13:48:10 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - device name: Gigaset G-tag
2020.03.29 13:48:10 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - device address: 7C:XX:XX:XX:8D:84
2020.03.29 13:48:10 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - tag already saved in hash
2020.03.29 13:48:14 4: Sub BleTagBattery_readSensorValue (Gtags_Battery) - call gatttool char read loop: 0, result: connect error: Function not implemented (38)

2020.03.29 13:48:14 4: Sub BleTagBattery_readSensorValue (Gtags_Battery) - invalid gatttool response
2020.03.29 13:48:14 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - tag not supported
2020.03.29 13:48:14 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - processing gatttool response for device 1_Gtag. batteryLevel:
2020.03.29 13:48:14 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - device found. device: 2_Gtag
2020.03.29 13:48:14 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - device name: Gigaset G-tag
2020.03.29 13:48:14 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - device address: 7C:XX:XX:XX:AD:4D
2020.03.29 13:48:14 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - try to connect with public
2020.03.29 13:48:16 4: Sub BleTagBattery_readSensorValue (Gtags_Battery) - call gatttool char read loop: 0, result: connect error: Function not implemented (38)

2020.03.29 13:48:16 4: Sub BleTagBattery_readSensorValue (Gtags_Battery) - invalid gatttool response
2020.03.29 13:48:16 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - try to connect with random
2020.03.29 13:48:57 4: Sub BleTagBattery_readSensorValue (Gtags_Battery) - call gatttool char read loop: 0, result: connect error: Connection refused (111)

2020.03.29 13:48:57 4: Sub BleTagBattery_readSensorValue (Gtags_Battery) - invalid gatttool response
2020.03.29 13:48:57 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - tag not supported
2020.03.29 13:48:57 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - processing gatttool response for device 2_Gtag. batteryLevel:
2020.03.29 13:48:57 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - device found. device: 3_Gtag
2020.03.29 13:48:57 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - device name: Gigaset G-tag
2020.03.29 13:48:57 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - device address: 7C:XX:XX:XX:AD:4E
2020.03.29 13:48:57 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - tag already saved in hash
2020.03.29 13:49:03 4: Sub BleTagBattery_readSensorValue (Gtags_Battery) - call gatttool char read loop: 0, result: handle: 0x001b value: 42

2020.03.29 13:49:03 4: Sub BleTagBattery_readSensorValue (Gtags_Battery) - processing gatttool response: 42
2020.03.29 13:49:03 4: Sub BleTagBattery_BlockingRun (Gtags_Battery) - processing gatttool response for device 3_Gtag. batteryLevel: 66
2020.03.29 13:49:03 4: Sub BleTagBattery_BlockingDone (Gtags_Battery) - set readings batteryLevel and battery of device: 3_Gtag
2020.03.29 13:49:03 4: Sub BleTagBattery_BlockingDone (Gtags_Battery) - done



Internals:
   FUUID      5c50bbf6-f33f-7c83-79f8-d8e0b5a856d12df8
   NAME       Gtags_Battery
   NR         402
   STATE      active
   TYPE       BleTagBattery
   VERSION    0.0.5
   READINGS:
     2020-03-29 13:48:10   state           active
   helper:
     1_Gtag  public
     3_Gtag  public
Attributes:
   hciDevice  hci2
   room       Residents
   verbose    5


Irgendwas läuft da nicht rund, oder?

Vielen Dank und bis denn.
SouzA
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 29 März 2020, 14:19:15
In den meisten Fällen werden diese Art Probleme von lepresenced/presenced oder ähnlichen Services auf dem gleichen Bluetooth Dongle verursacht.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: SouzA am 29 März 2020, 14:51:24
Zitat von: mumpitzstuff am 29 März 2020, 14:19:15
In den meisten Fällen werden diese Art Probleme von lepresenced/presenced oder ähnlichen Services auf dem gleichen Bluetooth Dongle verursacht.
Habe jetzt zwei zusätzliche Dongle am Pi.
Deswegen ist das Device ja auch hci2 gestellt.

Ich habe keinen Plan, wie ich die aufteilen soll.
Bzw. Kann mir einer sagen, wie ich das machen kann?

Der Status Request funktioniert nämlich auch mit mehreren Dongeln nicht reibungslos...
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 29 März 2020, 21:15:47
Ich verstehe nicht was du mir zu sagen versuchst. Wenn du 2 Bluetooth Dongles verwendest, dann kannst du z.b. hci0 mit lepresenced verwenden. Alle anderen Dinge solltest du dann über hci1 laufen lassen, also auch dieses Modul.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: SouzA am 29 März 2020, 22:54:51
Zitat von: mumpitzstuff am 29 März 2020, 21:15:47
Ich verstehe nicht was du mir zu sagen versuchst. Wenn du 2 Bluetooth Dongles verwendest, dann kannst du z.b. hci0 mit lepresenced verwenden. Alle anderen Dinge solltest du dann über hci1 laufen lassen, also auch dieses Modul.
Hi,
das wollte ich damit zum Ausdruck bringen.
Ich nutze das BleTagBattery-Modul auf hci2. (hci0 wird wohl das vom Raspi sein, hci1 der erste Dongle, hci2 der zweite Dongle)

Worüber das lepresenced läuft entzieht sich meiner Kenntnis, und auch wüsste ich nicht, wo ich einen bestimmten Dongle zuweisen kann.
Ich gehe davon aus, dass aber standardmäßig hci0 genutzt wird.
Dementsprechend müsste doch BleTagBattery, da uf hci2 gestellt, ohne Probleme durchlaufen, oder? Tut es aber bei "set BLeTagBattery statusRequest" nicht.
Dann kommt mindestens bei einem von drei Bluetooth-Devices dieser Fehler:
2020.03.29 22:41:27 4: Sub BleTagBattery_readSensorValue (Gtags_Battery) - call gatttool char read loop: 0, result: connect error: Function not implemented (38)

Wenn der Test selbständig von dem Modul durchgeführt wird (alle 6 Stunden), dann kommt kein Fehler... Habe ich jetzt gesehen. Kann aber auch Zufall sein.
Muß ich nochmal beobachten.

Läuft bei dir der Befehl "set BLeTagBattery statusRequest" sauber durch?

Thx und bis denn
SouzA

Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 29 März 2020, 23:32:57
Welches deiner 3 Bluetooth Dongles welche hciX Nummer erhält ist oft reiner Zufall. Das kann sich sogar von reboot zu reboot ändern und ist ein echter Mist. Der besagte Fehler lässt vermuten, das entweder die Tags außerhalb der Reichweite des Dongles sind oder Bluetooth durch irgend etwas gestört wird z.B. WLAN. Insbesondere das intern verbaute Bluetooth Modul im rpi3 macht sehr sehr häufig solche Probleme. Lepresenced müsste hci0 verwenden, wenn du nichts separat in der config geändert hast. Versuch jetzt mal die Tags in die Nähe des PIs zu bringen und dann einmal mit hci1 und einmal mit hci2 den statusRequest durchzuführen. Ist eins davon besser als das andere?
Grundsätzlich sollte sich der automatisch durchgeführte statusRequest nicht vom manuell ausgeführten unterscheiden. Der automatisch ausgeführte schaut allerdings nach, ob sich der Tag in Reichweite befindet.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: Jamo am 30 März 2020, 12:58:48
SouzA:
Zitat(hci0 wird wohl das vom Raspi sein, hci1 der erste Dongle, hci2 der zweite Dongle)

Wie mumpitzstuff schon sagt, ist nicht immer klar welches Dongle welche hciX Nummer erhält. Bei mir war es so, das wenn ich einen externen BT dongle angesteckt habe, dieser die Nummer 0 bekommen hat, und der interne on-board dann die Nummer 1. Kannst Du aber selber mit "hciconfig" überprüfen. Einmal hciconfig anstossen, OHNE externem BT dongle, dann nochmal mit externem BT dongle.
Und ja, soweit ich weiss benutzt lepresenced immer hci0.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: JWRu am 30 März 2020, 14:39:22
ZitatUnd ja, soweit ich weiss benutzt lepresenced immer hci0
Man kann in /etc/default/lepresenced einstellen, welches Bluetooth-Device verwendet wird.
Beispielsweise
BLUETOOTH_DEVICE="hci1"
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: SouzA am 31 März 2020, 23:18:55
Hi,
erst einmal herzlichen Dank an euch für die Antworten. :-*
Ich gehe das mal der Reihe nach durch.

Zitat von: mumpitzstuff am 29 März 2020, 23:32:57
Welches deiner 3 Bluetooth Dongles welche hciX Nummer erhält ist oft reiner Zufall. Das kann sich sogar von reboot zu reboot ändern und ist ein echter Mist. Der besagte Fehler lässt vermuten, das entweder die Tags außerhalb der Reichweite des Dongles sind oder Bluetooth durch irgend etwas gestört wird z.B. WLAN. Insbesondere das intern verbaute Bluetooth Modul im rpi3 macht sehr sehr häufig solche Probleme. Lepresenced müsste hci0 verwenden, wenn du nichts separat in der config geändert hast. Versuch jetzt mal die Tags in die Nähe des PIs zu bringen und dann einmal mit hci1 und einmal mit hci2 den statusRequest durchzuführen. Ist eins davon besser als das andere?
Grundsätzlich sollte sich der automatisch durchgeführte statusRequest nicht vom manuell ausgeführten unterscheiden. Der automatisch ausgeführte schaut allerdings nach, ob sich der Tag in Reichweite befindet.
Habe die gtags in die direkte Nähe zu dem Raspi gelegt.
Bei manueller Statusabfrage ist es egal, welcher hci (hci1 oder hci2) genommen wird. Mal gehen alle durch, mal bleibt einer hängen...
Bei den automatischen Abfragen ist das im übrigen genau so. Habe ich nochmal nachgeschaut.

Zitat von: Jamo am 30 März 2020, 12:58:48
SouzA:
Wie mumpitzstuff schon sagt, ist nicht immer klar welches Dongle welche hciX Nummer erhält. Bei mir war es so, das wenn ich einen externen BT dongle angesteckt habe, dieser die Nummer 0 bekommen hat, und der interne on-board dann die Nummer 1. Kannst Du aber selber mit "hciconfig" überprüfen. Einmal hciconfig anstossen, OHNE externem BT dongle, dann nochmal mit externem BT dongle.
Und ja, soweit ich weiss benutzt lepresenced immer hci0.
Du hast recht, die interne Bluetooth-Stelle bekommt in der Regel den hci2. Is bei mir zumindest so...

Zitat von: JWRu am 30 März 2020, 14:39:22
Man kann in /etc/default/lepresenced einstellen, welches Bluetooth-Device verwendet wird.
Beispielsweise
BLUETOOTH_DEVICE="hci1"
Habe ich nachgeschaut und das Script sieht verdammt jungfräulich aus... hci0 steht darin.
Würde ich auch dabei belassen wollen.

Trotzdem bin ich jetzt nicht weiter...
Woran es liegt, dass das Modul unzuverlässig bei mir arbeitet habe ich so noch nicht herausfinden können.
Habt ihr noch eine Idee, was man prüfen könnte/müsste?

Vielen Dank und bis denn!
SouzA
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 01 April 2020, 23:45:54
Tut mir leid, aber ich habe keine Ahnung, was das dann noch sein könnte. Wenn der Fehler aber nur manchmal auftritt, dann ist es zumindest für ein Batteriereading egal. Es wird dir außerdem das Level angezeigt, so das du teilweise noch Wochen mit einem niedrigen Batteriestand auskommst. Solange alles wenigstens 1x die Woche aktualisiert wird, ist alles gut.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: SouzA am 02 April 2020, 01:35:31
Zitat von: mumpitzstuff am 01 April 2020, 23:45:54
Tut mir leid, aber ich habe keine Ahnung, was das dann noch sein könnte. Wenn der Fehler aber nur manchmal auftritt, dann ist es zumindest für ein Batteriereading egal. Es wird dir außerdem das Level angezeigt, so das du teilweise noch Wochen mit einem niedrigen Batteriestand auskommst. Solange alles wenigstens 1x die Woche aktualisiert wird, ist alles gut.
Prinzipiell gebe ich dir da recht.
Bin aber eher immer so darauf aus, eine Maschine ohne Fehler am laufen zu haben :)

Thx und vielen Dank für eure Beiträge
SouzA
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 02 April 2020, 09:45:36
Du kannst ja mal versuchen das Kommando zum auslesen der Infos in ein Script zu packen und dann hintereinander die 3 Tags mit dem Script im Terminal auszulesen. Wenn das besser klappen sollte als mit dem Modul, dann würde ich versuchen da noch mal ins Detail zu gehen. Vermutlich wirst du aber auf ähnliche Probleme stoßen.
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: MikeR am 20 Oktober 2021, 15:01:01
Hallo,

erstmal: Das Modul an sich funktioniert super. Danke schön dafür. Ich habe nur ein kleines, aber für meine Anwendung essentielles Problem:
Das Modul trägt ja zu den Tags die Batterieinfos als Attribute dazu. Und mein Problem stellt sich so dar, dass ich auf diese Attribute - die ich in der Weboberfläche sehe und die auch aktualisiert werden - nicht zugreifen kann.

Weder wird ein Event, der bei Änderung eines Attributwertes gefeuert, noch kann ich mit ReadingsVal die Werte auslesen.

Hängt das ggf. mit der Art und Weise zusammen, wie diese Pseudo-Attribute in die eigentlichen PRESENCE-Objekte rein injected werden?
Kann ich da was machen? Oder mache ich gar irgendwas falsch?

Im Log ausser einer lapidaren "invalid value" Meldung nix. Wenn ich das ReadingsVal einem Dummy zuweise (egal ob mit "value" im Set oder nicht) steht im Dummy der Name der lokalen Variablen, in der ich das ReadingsVal zwischenpuffere...

Liebe Grüße
Mike

P.S.: Nur der Vollständigkeit halber, ikch will die Batterielevel auslesen und auf den KNX-Bus senden. Daher der Aufriss
Titel: Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
Beitrag von: mumpitzstuff am 20 Oktober 2021, 20:28:03
Das Modul erzeugt Readings in den jeweiligen Tag Devices. Diese kann man ganz normal auslesen und weiter verarbeiten z.b. mittels Notify.