Neues Modul: 74_BleTagBattery - Batterie Informationen für BLE Tags

Begonnen von mumpitzstuff, 27 Februar 2017, 21:29:50

Vorheriges Thema - Nächstes Thema

mumpitzstuff

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

Amenophis86

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 ;)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

mumpitzstuff

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.

Amenophis86

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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

binford6000

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

mumpitzstuff

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.

CoolTux

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

mumpitzstuff

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.

binford6000

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

Amenophis86

#99
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
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

CoolTux

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
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

stromer-12

FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

stromer-12

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.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

valvak

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

mumpitzstuff

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.