Autor Thema: Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags  (Gelesen 11477 mal)

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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:
  • Gattool is required to use this module. Be sure that bluez is installed (sudo apt-get install bluez).
  • BLE tags must be registered as PRESENCE devices of type lan-bluetooth.


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:
  • should work for all BLE tags now

GitHub: https://github.com/mumpitzstuff/fhem-BleTagBattery
« Letzte Änderung: 11 März 2017, 01:23:51 von mumpitzstuff »

Offline binford6000

  • Full Member
  • ***
  • Beiträge: 471
  • 🏠⚙️🛠📱
 
Zitat
Im 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> StatusRequestkann ich ja auch ein Update erzwingen...

VG Sebastian
FHEM 5.8 auf RPi3, IOserver für alle CULs mit ser2net, Testumgebung: docker pull fhem/fhem
Homematic, EnOcean, IT, HUE + Nanoleaf Aurora,  SONOS, alexa-fhem, homebridge, TelegramBot mit msgDialog, livetracking

Offline knopf_piano

  • Full Member
  • ***
  • Beiträge: 337
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.
zotac nano, Bananapi-R1, fhem-trunk, hmlan, jeelink, zwave, tablet-ui,  ESPeasy, pywws, raspi, yamaha-671, ufs910-titan

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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). 

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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.

Offline knopf_piano

  • Full Member
  • ***
  • Beiträge: 337
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 ;-)
zotac nano, Bananapi-R1, fhem-trunk, hmlan, jeelink, zwave, tablet-ui,  ESPeasy, pywws, raspi, yamaha-671, ufs910-titan

Offline binford6000

  • Full Member
  • ***
  • Beiträge: 471
  • 🏠⚙️🛠📱
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


FHEM 5.8 auf RPi3, IOserver für alle CULs mit ser2net, Testumgebung: docker pull fhem/fhem
Homematic, EnOcean, IT, HUE + Nanoleaf Aurora,  SONOS, alexa-fhem, homebridge, TelegramBot mit msgDialog, livetracking

Offline Mumpitz

  • Full Member
  • ***
  • Beiträge: 231
Müssen vorgängig die alten Scripte deaktiviert oder etwas deinstalliert werden?

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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
Ich habe die hier erwähnten 3 Einträge in meiner main.conf drin stehen, da ich auch am Anfang mal ähnliche Probleme hatte.
« Letzte Änderung: 03 März 2017, 01:36:22 von mumpitzstuff »

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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.

Offline binford6000

  • Full Member
  • ***
  • Beiträge: 471
  • 🏠⚙️🛠📱
Zitat
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?

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

Zitat
Vielleicht 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
FHEM 5.8 auf RPi3, IOserver für alle CULs mit ser2net, Testumgebung: docker pull fhem/fhem
Homematic, EnOcean, IT, HUE + Nanoleaf Aurora,  SONOS, alexa-fhem, homebridge, TelegramBot mit msgDialog, livetracking

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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...

Offline binford6000

  • Full Member
  • ***
  • Beiträge: 471
  • 🏠⚙️🛠📱
Hallo,
Zitat
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)

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!

Zitat
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...

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
FHEM 5.8 auf RPi3, IOserver für alle CULs mit ser2net, Testumgebung: docker pull fhem/fhem
Homematic, EnOcean, IT, HUE + Nanoleaf Aurora,  SONOS, alexa-fhem, homebridge, TelegramBot mit msgDialog, livetracking

Offline micky0867

  • Full Member
  • ***
  • Beiträge: 211
  • Welcome to the Unixverse!
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
Zustimmung Zustimmung x 1 Liste anzeigen

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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.

Offline binford6000

  • Full Member
  • ***
  • Beiträge: 471
  • 🏠⚙️🛠📱
Moin,
so ich habe mal alles ausprobiert jedoch leider ohne Erfolg...  :(
  • lepresenced beendet und BT Dongle ab- und angesteckt --> Connection refused (111)
  • lepresenced beendet und hciconfig down/up/reset --> Connection refused (111)
  • lepresenced bearbeitet mit constant RETRY_SLEEP = 20 und restart --> Connection refused (111)
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
FHEM 5.8 auf RPi3, IOserver für alle CULs mit ser2net, Testumgebung: docker pull fhem/fhem
Homematic, EnOcean, IT, HUE + Nanoleaf Aurora,  SONOS, alexa-fhem, homebridge, TelegramBot mit msgDialog, livetracking

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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.

Offline Mumpitz

  • Full Member
  • ***
  • Beiträge: 231
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?

Offline binford6000

  • Full Member
  • ***
  • Beiträge: 471
  • 🏠⚙️🛠📱
Zitat
Kannst 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
FHEM 5.8 auf RPi3, IOserver für alle CULs mit ser2net, Testumgebung: docker pull fhem/fhem
Homematic, EnOcean, IT, HUE + Nanoleaf Aurora,  SONOS, alexa-fhem, homebridge, TelegramBot mit msgDialog, livetracking

Offline knopf_piano

  • Full Member
  • ***
  • Beiträge: 337
Hab mir damals auch nen neuen zugelegt, set dem klappt hcitool-scan, auch inateck
zotac nano, Bananapi-R1, fhem-trunk, hmlan, jeelink, zwave, tablet-ui,  ESPeasy, pywws, raspi, yamaha-671, ufs910-titan

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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=126899
https://eclipse.github.io/kura/doc/bluetooth-le-example.html

Offline binford6000

  • Full Member
  • ***
  • Beiträge: 471
  • 🏠⚙️🛠📱
Zitat
Ist 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
FHEM 5.8 auf RPi3, IOserver für alle CULs mit ser2net, Testumgebung: docker pull fhem/fhem
Homematic, EnOcean, IT, HUE + Nanoleaf Aurora,  SONOS, alexa-fhem, homebridge, TelegramBot mit msgDialog, livetracking

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15089
  • s/fhem\.cfg/configDB/g
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.
« Letzte Änderung: 11 März 2017, 00:53:56 von betateilchen »
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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.

Offline Fixel2012

  • Hero Member
  • *****
  • Beiträge: 1218
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
« Letzte Änderung: 14 März 2017, 19:55:31 von Fixel2012 »
Fhem 5.8 auf Raspi 3, HMLAN und 868MHz CUL mit einigen Komponenten, Z-Wave Rollladenaktoren, Tablet UI, 433 MHz CUL mit Baumarktsteckdosen und Temp Sensoren, Amazon Echo, Echo Dot, 2x SONOS  play1, 1x SONOS Connect AMP,  presence, HUE, Lightify

Offline Jojo11

  • Sr. Member
  • ****
  • Beiträge: 988
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
Zustimmung Zustimmung x 1 Liste anzeigen

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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.

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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?

Offline SouzA

  • Full Member
  • ***
  • Beiträge: 249
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
« Letzte Änderung: 13 April 2017, 12:16:45 von SouzA »
Raspi 3, EnOcean TCM310 USB, HM-MOD-UART-USB, Jeelink, WifiLight, AMAD, FRITZBOX, TelegramBot, VIERA, Presence BT/Mac
Fhem 5.9

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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:

  • 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 Die Empfehlung irgendwelche Bluez Versionen manuell zu installieren, möchte ich jetzt aber lieber nicht aussprechen. Versuch erst mal die Dongles zu tauschen.

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.

Offline SouzA

  • Full Member
  • ***
  • Beiträge: 249
Hi,

Danke für deine Antwort!

  • 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 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
Raspi 3, EnOcean TCM310 USB, HM-MOD-UART-USB, Jeelink, WifiLight, AMAD, FRITZBOX, TelegramBot, VIERA, Presence BT/Mac
Fhem 5.9

Offline stoxx

  • Full Member
  • ***
  • Beiträge: 206
Zitat
Supported 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
« Letzte Änderung: 26 Mai 2017, 16:48:44 von stoxx »
FHEM 5.8 auf Raspberry mit CUL, FS20, FHT, HMS, BLE, Z-Wave ..

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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...

Offline stoxx

  • Full Member
  • ***
  • Beiträge: 206
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:
Zitat
connect 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

vg stoxx
FHEM 5.8 auf Raspberry mit CUL, FS20, FHT, HMS, BLE, Z-Wave ..

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Versuch's mal mit -t random bei deinem gatttool aufruf. Die nut devices brauchen das.

Offline stoxx

  • Full Member
  • ***
  • Beiträge: 206
Ok, jetzt erhalte ich den Fehler, den ich auch mit dem Modul bekomme:
Zitat
connect error: Transport endpoint is not connected (107)
FHEM 5.8 auf Raspberry mit CUL, FS20, FHT, HMS, BLE, Z-Wave ..

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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?

Offline stoxx

  • Full Member
  • ***
  • Beiträge: 206
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..
FHEM 5.8 auf Raspberry mit CUL, FS20, FHT, HMS, BLE, Z-Wave ..

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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.

Offline stoxx

  • Full Member
  • ***
  • Beiträge: 206
Zitat
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.

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
FHEM 5.8 auf Raspberry mit CUL, FS20, FHT, HMS, BLE, Z-Wave ..

Offline mi.ke

  • Full Member
  • ***
  • Beiträge: 481
  • Nice Boys don't play Rock'n'Roll
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
 
« Letzte Änderung: 18 Juni 2017, 00:41:28 von mi.ke »
FHEM 5.8 | Cubietruck + 8 x RPi(Z) + FB 7590 + FB 6842 LTE über LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX433(e) + 2 x HMLan + Ardunio433 + 3 x LGW + CO2 +++
FS20, FHT, FMS, Elro(mod)AB440/R/S/D, OWL-CM160, Revolt-5461, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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.
« Letzte Änderung: 18 Juni 2017, 11:35:55 von mumpitzstuff »

Offline stoxx

  • Full Member
  • ***
  • Beiträge: 206
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
FHEM 5.8 auf Raspberry mit CUL, FS20, FHT, HMS, BLE, Z-Wave ..

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Bei 15% springt die Anzeige um.

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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.

Offline stoxx

  • Full Member
  • ***
  • Beiträge: 206
Zitat
Neben 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
FHEM 5.8 auf Raspberry mit CUL, FS20, FHT, HMS, BLE, Z-Wave ..

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2465
  • Anti-Statement befreite Zone ;)
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?
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System
Hilfreich Hilfreich x 1 Liste anzeigen

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
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.

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2465
  • Anti-Statement befreite Zone ;)
Ok, wollte nur sicher gehen, dass es mit Start und stop geht und ich nicht ewig versuche und die Grundvoraussetzung schon falsch ist. Danke :)
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline stiefl

  • New Member
  • *
  • Beiträge: 19
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #49 am: 09 August 2017, 18:09:37 »
Klasse Modul, funktioniert auf Anhieb. Vielen Dank!!!  8)

Offline jschuppe

  • New Member
  • *
  • Beiträge: 5
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #50 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/ ).

Viele Grüße

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #51 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.

Offline PsychoD

  • Full Member
  • ***
  • Beiträge: 202
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #52 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

« Letzte Änderung: 31 Dezember 2017, 20:42:09 von PsychoD »

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15089
  • s/fhem\.cfg/configDB/g
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #53 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:

  • ändere die Pfad-Variable in Deiner Systemumgebung
  • verlinke bzw. kopiere das Programm gatttool in ein Programmverzeichnis, das bereits im Pfad enthalten ist
  • ändere die Zeile 279 in der Moduldatei und gib dort den gesamten Pfad zur Datei gatttool mit an
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

Offline PsychoD

  • Full Member
  • ***
  • Beiträge: 202
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #54 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

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2465
  • Anti-Statement befreite Zone ;)
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #55 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.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #56 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?


Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2465
  • Anti-Statement befreite Zone ;)
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #57 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.
FHEM auf Raspberry3, Betriebssystem Jessy, HMLan, HM Komponenten, LD382A, H801, Sonoff, Harmony Hub und vieles mehr. Einfach ein tolles universelles System

Offline ReviloEgros

  • New Member
  • *
  • Beiträge: 5
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #58 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?
« Letzte Änderung: 13 Februar 2018, 03:59:13 von ReviloEgros »

Offline ReviloEgros

  • New Member
  • *
  • Beiträge: 5
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #59 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.

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16124
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #60 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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer

Offline ReviloEgros

  • New Member
  • *
  • Beiträge: 5
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #61 am: 14 Februar 2018, 15:17:29 »
Wenn du damit das -t random meinst, nein. Zumal ich für meine Tags public brauche.

Offline arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 155
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #62 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

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #63 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.

Offline arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 155
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #64 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)

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #65 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.

Offline arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 155
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #66 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.

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #67 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.

Offline arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 155
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #68 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?

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16124
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #69 am: 20 Februar 2018, 17:05:08 »
Was genau meinst Du mit Instanz?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer

Offline arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 155
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #70 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.

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16124
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #71 am: 20 Februar 2018, 17:10:42 »
Gatttool wird auf dem Rechner gestartet auf dem Du das Device in FHEM definiert hast.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer

Offline arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 155
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #72 am: 20 Februar 2018, 17:17:43 »
okay, dachte ich mir fast :( Der hat den schlechtesten Empfang...

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16124
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #73 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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.me/MOldenburg
Mein GitHub: https://github.com/LeonGaultier
kein Support für cfg Editierer

Offline arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 155
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #74 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 ;)

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #75 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.

Offline arthur_dent_2015

  • Full Member
  • ***
  • Beiträge: 155
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #76 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.

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #77 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.

Offline Neuhier

  • Full Member
  • ***
  • Beiträge: 180
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #78 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.

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #79 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.

Offline Neuhier

  • Full Member
  • ***
  • Beiträge: 180
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #80 am: 07 August 2018, 07:26:08 »
Klar, geht.  8)
Ist mir halt aufgefallen.

Online Gasmast3r

  • Full Member
  • ***
  • Beiträge: 406
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #81 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.

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #82 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.

Online Gasmast3r

  • Full Member
  • ***
  • Beiträge: 406
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #83 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.

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #84 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.

Offline stoxx

  • Full Member
  • ***
  • Beiträge: 206
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #85 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/
Was brauchst Du denn für Infos, um diese Tags mit einzubinden?

vg stoxx
FHEM 5.8 auf Raspberry mit CUL, FS20, FHT, HMS, BLE, Z-Wave ..

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #86 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.

Offline stoxx

  • Full Member
  • ***
  • Beiträge: 206
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #87 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
FHEM 5.8 auf Raspberry mit CUL, FS20, FHT, HMS, BLE, Z-Wave ..

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #88 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.

Offline t1me2die

  • Full Member
  • ***
  • Beiträge: 247
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #89 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

Offline mumpitzstuff

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1081
Antw:Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags
« Antwort #90 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