FHEM Forum

Mahlzeit!

Für die Mutigen unter Euch gibt es jetzt eine neue Vorabversion zu testen: lepresenced0.93dev13.

Neues Feature: Batterieabfrage.

Neues Kommandozeilenargument: --batteryinterval  - Intervall in Stunden, in denen die anwesenden Geräte nach ihrem Batteriestand gefragt werden.

Der Batteriestand landet dann im Reading battery_level. In battery_level_age steht dann das Alter der Messung in Stunden.

Wichtig: Beim Upgrade einer Version 0.92 oder niedriger bitte das Paket

libreadonly-perl

installieren.

Grüße
Patrick

Zur besseren räumlichen Abdeckung laufen bei mir zwei lepresenced-Instanzen, die dann mit collectored von der FHEM-Instanz "eingesammelt" werden.

Ich stehe gerade auf dem Schlauch: wie kann ich hier das neue "--batteryinterval" integrieren...?

Hi!

Zitat von: dkreutz am 17 August 2020, 12:11:52
Ich stehe gerade auf dem Schlauch: wie kann ich hier das neue "--batteryinterval" integrieren...?

Den Parameter musst Du beim Aufruf angeben. Das geht leichter, wenn ich das Paket aktualisiert habe. Aber Du kannst ihn auch komplett weglassen, dann wird nach zwei Minuten und dann alle 6 Stunden abgefragt. Collectord setze ich nicht selbst ein. Daher wäre interessant, ob der die Batteriewerte durchreicht.

Patrick

lepresenced0.93dev13 installiert... battery_level wird über collectored übertragen!

Langzeittest steht aus.

p.s. es wird anscheinend jetzt Readonly.pm als Abhängigkeit benötigt?

Hi!

Zitat von: dkreutz am 17 August 2020, 20:08:17
p.s. es wird anscheinend jetzt Readonly.pm als Abhängigkeit benötigt?

Stimmt. Ich war mit dem großen Besen durch den Code gegangen und hatte bei der Gelegenheit ein paar PBPs umgesetzt.

Patrick

Neue Version im Startposting.

Hallo Patrick,
doofe frage, aber muss ich dann nur den alten lepresenced unter /usr/sbin/lepresenced durch den neuen lepresenced aus diesem Startpost ersetzen? Und dann den service neu starten? Oder ist sonst noch was zu machen?

Dann würde ich deine Version gerne ausprobieren wollen. Ich habe acht (8) lepresence devices (Siemens G-Tags) die ich auf 4 verschiedenen Raspi / NUC abfrage, und dann alle über einen collectord aufsammele. Im moment mache ich die Batterieabfrage getrennt über das BLETagBattery modul, das könnte ich mir dann sparen.

Danke!

Hi!

Zitat von: Jamo am 18 August 2020, 11:42:53
doofe frage, aber muss ich dann nur den alten lepresenced unter /usr/sbin/lepresenced durch den neuen lepresenced aus diesem Startpost ersetzen? Und dann den service neu starten? Oder ist sonst noch was zu machen?

Ja, so sollte es sein. Ggf. musst Du noch libreadonly-perl nachinstallieren (danke dkreutz für die Info).

Dass Du collectord benutzt ist auf jeden Fall auch gut, da ich ihn nicht benutze. Ich könnte mir vorstellen, dass es hier zu Phänomenen kommt, dass der der zuletzt übermittelte battery_level angezeigt wird (z. B. lepresenced1 fragt erfolgreich die Batterie ab und übermittelt 100%, lepresenced2 aktualisiert etwas später, kennt aber die Batterie nicht und schickt dann unknown.)

/Edit:
Es ist eigentlich noch schlimmer:

• lepresenced1 fragt erfolgreich die Batterie des Tags ab, meldet 100% aber erreicht den Tag über Wochen nicht zur Batterieabfrage
• lepresenced2 fragt den Tag mehrfach erfolgreich ab und der Batteriestand wird immer weniger 99%, 95% usw.

Die Folge wäre, dass in FHEM abwechselnd 100% und 95% erscheint.
Workaround: lepresenced-Instanzen zusätzlich direkt in FHEM anlegen.

Patrick

Gut, mach ich heute Abend und beobachte dann das Verhalten.

Aber das ist doch alles ok so wie von Dir beschrieben, das Verhalten mit 100%/unknown/etc lässt sich alles über die sub abfangen, wo man den batterie-level über ein notify checked. Solange ein lepresenced den sinkenden richtigen batterie-level reported, weiss man das die Batterie ge-wechselt werden muss.

OK, wenn man dann nachguckt, denkt die Batterie ist leer und der level ist dann wieder auf 100%, das wäre komisch.
In dem Fall, wenn ein lepresenced den G-Tag über Tage gar nicht mehr erreicht (oder auch nur einmal nicht erreicht), kann man das dann nicht so implementieren, das der batterie-level erst gar nicht zum collectord durchgereicht wird (also quasi altes Verhalten des lepresenced ohne batterie-level)? Damit würden nur gültige batterielevel an den collectord durchgereicht.

Im Moment ist es ja so, das das BLETagModule auf einem Raspberry irgendwo in der Ecke sitzt, und ich Glueck habe wenn der einmal pro Woche bei allen GTags die batterieabfrage hinkriegt. Deswegen ist die verteilte batterieabfrage mit collectord/le-presenced ein echter Gewinn. Danke!

Hi!

Zitat von: Jamo am 18 August 2020, 13:59:20
OK, wenn man dann nachguckt, denkt die Batterie ist leer und der level ist dann wieder auf 100%, das wäre komisch.
In dem Fall, wenn ein lepresenced den G-Tag über Tage gar nicht mehr erreicht (oder auch nur einmal nicht erreicht), kann man das dann nicht so implementieren, das der batterie-level erst gar nicht zum collectord durchgereicht wird (also quasi altes Verhalten des lepresenced ohne batterie-level)? Damit würden nur gültige batterielevel an den collectord durchgereicht.

Man könnte natürlich ein Maximalalter angeben, bei dessen Überschreibung der lepresenced die Klappe hält. Das ist natürlich eine Krücke.

Was Du übrigens jetzt schon tun kannst: Neben dem Reading battery_level wird auch battery_level_age gesetzt, das das Alter des Levels in Stunden angibt. D. h. Du könntest in Deinem notify filtern.

Patrick

Kurzes Feedback:
V0.93dev13 hat nicht so richtig funktioniert, immer wieder absent obwohl die Tags an der gleichen Stelle liegen wie sonst auch. Battery_level war immer "unknown"

Gerade eben V0.93dev14 installiert: bisher ähnliches Verhalten wie dev13, d.h. immer wieder "absent", immerhin wurde jetzt der battery_level übertragen. Ob der Wert "100" stimmt ist fraglich, BLEtagbattery hat zuletzt "95" ermittelt.

Werde das weiter beobachten und berichten...

Hi!

Zitat von: dkreutz am 18 August 2020, 15:28:00
Kurzes Feedback:
V0.93dev13 hat nicht so richtig funktioniert, immer wieder absent obwohl die Tags an der gleichen Stelle liegen wie sonst auch. Battery_level war immer "unknown"

Gerade eben V0.93dev14 installiert: bisher ähnliches Verhalten wie dev13, d.h. immer wieder "absent", immerhin wurde jetzt der battery_level übertragen. Ob der Wert "100" stimmt ist fraglich, BLEtagbattery hat zuletzt "95" ermittelt.

Werde das weiter beobachten und berichten...

Welche Version hast Du vorher eingesetzt, also die, die funktionierte?

Schick mir mal bitte ein log mit LOG_DEBUG.
Welche BLE-Tags setzt Du ein?
Wie hoch ist das check-interval der PRESENCE-Instanzen in FHEM? (Hintergrund: Bei der aktuellen Implementierung ist lepresenced für den Zeitpunkt der Batteriechecks blind, d. h. die Timer laufen potenziell ab. Da die Abfragen aber sehr schnell gehen und ich nur - Ungenauigkeiten ausgenommen - erreichbare Geräte scanne, sollte das aber eigentlich vernachlässigbar sein.)

Patrick

/Edit:
Mumpitz benutzt in bletagbattery im Grunde das gleiche Verfahren wie ich, sowohl beim Abholen der Werte als auch beim Umrechnen. Er hat noch Zusatzfunktionalität, um auch bei Geräten mit random Adressschema eine Antwort zu bekommen. Unterschiedliche Werte sollten also nicht angezeigt werden.

Hallo Patrick,
Gerade eben V0.93dev14 auf 2 meiner 4 Einplatinenrechner (1xIntel NUC - Schlafzimmer, 1x Raspi - Wohnzimmer) installiert
Hier das gleiche Verhalten wie beim Vorredner.
- battery_level wird übertragen (bei Mumpitz heisst es aber "batteryLevel")
- der battery_level stimmt mit dem vom Mumpitz überein also das neue battery_level = dem alten batteryLevel
- battery_level_age sehe ich auch, ist überall '0'

Aber die 2 Räume mit dem neuen lepresenced (Schlaf/Wohn) die der Collectord abholt, sind ständig absent. Die anderen beiden Räume mit dem alten lepresenced (Flur/Kueche) waren weiterhin immer present. Ich habe sogar einmal ein ''disconnect'' für den collectord bekommen.

- Siemens G-Tags
- Intervall 60 60 (also defmod Presence_GTag_collect PRESENCE lan-bluetooth AA:BB:CC:DD:EE:FF 127.0.0.1:5222 60 60)
   ja der collectord läuft auf Port 5222, lepresenced auf 5333
- die funktionierende Version ist 0.92, also lepresenced-0.92-1.deb


Ich habe jetzt erstmal zurückgeswitched.

Hi!

Zitat von: Jamo am 18 August 2020, 21:38:07
Ich habe jetzt erstmal zurückgeswitched.

Danke für die Fehlerbeschreibung. Das Zurückswitchen kommt für meinen Geschmack aber 5 Minuten zu früh. Ich brauche dringend ein Log mit LOG_DEBUG zum Zeitpunkt des absent.

Patrick

@Jamo:
Das Syslog bekommst Du am besten mit folgendem Befehl:
grep lepresenced /var/log/syslog

Patrick

Ja, danke. Hab alles gemacht, Log in deiner privaten e-mail.

Hi!

Zitat von: Jamo am 18 August 2020, 23:32:18
Ja, danke. Hab alles gemacht, Log in deiner privaten e-mail.

Interessant. Es sieht so aus als würden nach der Batterieabfrage und dem Neustart des Scans keine Beacons mehr empfangen. Habe im Startposting die Version lepresenced0.93dev15 angehängt, die kleinere Probleme behebt aber vor allem etwas mehr loggt. Kannst Du das mal ausführen, mindestens 5 Minuten laufen lassen und mir wieder das Log schicken?

Danke!

Patrick

Erstmal Danke für den neuen LePresenced, Du hast eine neue PN.

Hi!

Danke für das Log.

Zitat von: Jamo am 19 August 2020, 18:24:58
Erstmal Danke für den neuen LePresenced, Du hast eine neue PN.


Aug 19 18:08:08 wohny lepresenced[27754]: [tid:0] main::stats_task: Active clients: 9, known devices: 35 (min/max age: 93/195), received beacons (hcitool/hcidump/difference): 3735/0/3735

Auch das ist interessant. Ab dem Zeitpunkt des Neustarts der Prozesse nach der Batterieabfrage empfängt hcidump keinen einzigen Beacon mehr, hcitool aber schon. Werde Dir heute oder morgen nochmal eine weitere Version mit mehr Logging schicken, um der Sache auf den Grund zu gehen.

Noch eine Frage: Von den 5 zum Zeitpunkt des Logs erreichbaren Geräten hat nur eins auf die Batteriaabfrage geantwortet, 4 geben "Function not implemented" zurück. Hast Du für die mit Deiner alten Batteriemethode einen Wert bekommen?

Patrick

Hallo Patrick,
ja, ich habe für alle einen BatterieLevel (Mumpitz) bekommen, aber auch nur sporadisch, also 1 x pro Woche oder so was. Mit dem Modul von Mumitz läuft die batterieabrage ja auch nur auf einem raspi, aber die GTags sind im ganzen Haus verteilt.
Der eine GTag, der im Syslog auf die Batterieanfrage in den 5 Minuten reagiert hat, hängt direkt neben dem "wohny" Raspi, auf dem der neue dev15 lepresenced läuft. Bei den anderen 4 GTags sind mindestens 1 oder 2 Wände dazwischen, deswegen hat der eine Raspi "wohny" die anderen 4 GTags in den 5 Minuten wahrscheinlich ncht empfangen (Und ich habe den neuen dev15 lepresenced ja nur auf einem (dem wohnzimmer raspi) von meinen 4 Raspis/inuc installiert)
Sobald ich überall den neuen lepresenced installieren würde, würde das ja dann über den collectord kommen.
Danke!

Zitat von: PatrickR am 18 August 2020, 15:59:57
Welche Version hast Du vorher eingesetzt, also die, die funktionierte?

lepresenced.0.91dev - funktionierte bisher am besten und lief wochenlang ohne Neustart des Service.

Zitat von: PatrickR am 18 August 2020, 15:59:57
Welche BLE-Tags setzt Du ein?

Gigaset G-Tag

Zitat von: PatrickR am 18 August 2020, 15:59:57
Wie hoch ist das check-interval der PRESENCE-Instanzen in FHEM? (

INTERVAL_NORMAL 30
INTERVAL_PRESENT 120

Hi!

Zitat von: Jamo am 19 August 2020, 19:16:27
Der eine GTag, der im Syslog auf die Batterieanfrage in den 5 Minuten reagiert hat, hängt direkt neben dem "wohny" Raspi, auf dem der neue dev15 lepresenced läuft. Bei den anderen 4 GTags sind mindestens 1 oder 2 Wände dazwischen, deswegen hat der eine Raspi "wohny" die anderen 4 GTags in den 5 Minuten wahrscheinlich ncht empfangen

Interessante Theorie. Aber das kriegen wir leichter in den Griff, wenn der Dump erstmal wieder funktioniert und Du die gefixte Version in Deiner Monsterinfrastruktur ausrollen kannst ;)

Bitte erstelle nochmal mit der angehängten Version ein Log wie gehabt.

@all: Die angehängte Version erzeugt nur mehr Logs, d. h. sie dient nur zur Eingrenzung des Fehlers.

Gruß
Patrick

Zitat... in Deiner Monsterinfrastruktur ausrollen kannst

Wer kann der kann und wer hat der hat :-)

ZitatAber das kriegen wir leichter in den Griff, wenn der Dump erstmal wieder funktioniert

So machen wir das!
Du hast eine neue PN.

Moin!

Wollte mich nur mal einklinken und anmerken, dass ich diesen Thread mit Spannung verfolge und gern auch bei der Fehlersuche mithelfen könnte, wenn gewünscht. Ich habe ein ähnliche Konfiguration wie dkreutz, 5 Gigaset G-tags die ich überwache und einen Zusatzadapter am Raspi.
Die von Patrick beschriebenen Phänomene habe ich ganz genauso beobachtet: Nach dem Neustart des lepresenced funktioniert es kurz, alle G-tags sind present, dann kommt die Batterieabfrage (die scheinbar auch funktioniert), und danach kommen dann keine Daten beim lepresenced mehr an und die G-tags werden als absent gemeldet.

Was mir auffällt: Wenn ich gleich nach dem Stoppen des lepresenced versuche, das hcitool auf der Commandline direkt zu benutzen, gibt es folgende Fehlermeldungen:
hcitool -i hci0 lescan
Set scan parameters failed: Input/output error
bzw.
hcitool -i hci0 leinfo 7C:2F:80:xx:xx:xx
Requesting information ...
Could not create connection: Input/output error

Nach so 1-2 Minuten funktioniert es dann wieder. Beobachtet ihr das auch?

Hallo Patrick,
dann ist es wahrscheinlich so, das der lepresenced exclusiven Zugriff auf den hci0 benötigt. Für die Batterieabfrage bräuchte man dann einen extra BT-Dongle, z.B. hci1 oder hci2. Das ist bei dem Modul von Mumpitz auch so, das läuft nur zuverlässig wenn das Modul Zugriff auf einen anderes BT interface hat.
Bei mir läufts so:
- hci0: LEprecenced
- hci1: presenced
- hci2: myBleTagBattery (Mumpitz)

Siehe auch https://forum.fhem.de/index.php/topic,68104.msg999363.html#msg999363

Zitat von Mumiptz:

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

Oder kannst Du das Interface zwischendurch für die Batterieabfrage freigeben, also abwechselnd batterieabfrage/lepresence check machen?

Hallo zusammen!
Erstmal Danke für die Resonanz!

Zitat von: TL am 20 August 2020, 00:36:26
Wollte mich nur mal einklinken und anmerken, dass ich diesen Thread mit Spannung verfolge und gern auch bei der Fehlersuche mithelfen könnte, wenn gewünscht.

Bislang bleiben durch die Logs von Jamo wirklich keine Wünsche offen. Wenn das soweit im Griff ist, können wir glaube ich im größeren Stil testen. Ich habe ärgerlicherweise bei mir das Problem, dass es bei mir einwandfrei funktioniert, bei Euch aber nicht. Das ist praktisch der Worst Case für die Fehlersuche.

Zitat von: TL am 20 August 2020, 00:36:26
Was mir auffällt: Wenn ich gleich nach dem Stoppen des lepresenced versuche, das hcitool auf der Commandline direkt zu benutzen, gibt es folgende Fehlermeldungen:

Code Auswählen Erweitern

hcitool -i hci0 lescan
Set scan parameters failed: Input/output error

Ärgerlicherweise treten immer mal wieder Fehler beim Zugriff auf das Bluetooth-Gerät auf. Daher trackt lepresenced sie und schickt ggf. ein hciconfig reset los.

Zitat von: Jamo am 20 August 2020, 08:10:48
dann ist es wahrscheinlich so, das der lepresenced exclusiven Zugriff auf den hci0 benötigt. Für die Batterieabfrage bräuchte man dann einen extra BT-Dongle, z.B. hci1 oder hci2. Das ist bei dem Modul von Mumpitz auch so, das läuft nur zuverlässig wenn das Modul Zugriff auf einen anderes BT interface hat.

Mein Ansatz war, auch eine Variante mit einem Interface zu unterstützen, was bei mir auch funktioniert. Aktuell ist es so, dass das auf der Kommandozeile übergebene Gerät für Scan _und_ Batteriecheck genommen wird. Das könnte man natürlich ändern. Ich hoffe noch, dass das nicht nötig sein wird.

Zitat von: Jamo am 20 August 2020, 08:10:48
Oder kannst Du das Interface zwischendurch für die Batterieabfrage freigeben, also abwechselnd batterieabfrage/lepresence check machen?

Genau das macht der lepresenced. Er beendet den Scan- und den Dump-Prozess, fragt die Batterien ab, startet die Prozesse wieder und korrigiert die Abfrage der Geräte um die "Blindflugzeit". Das ist auch der Haupt-Mehrwert von einer Integration in lepresenced direkt.

Danke übrigens für die letzten Logs. Die sind sehr aufschlussreich.

Patrick

Hi!

@Jamo:
Habe wieder eine neue Version fertig gemacht, die noch etwas mehr loggt und zwei kleine, leider für das Problem nicht relevante Fehler behebt.

Kannst Du das mal testen, 1x im Originalzustand und 1x wenn Du in Zeile 55 von lepresenced $BATTERY_TASK_SETTLE_SLEEP von 2 auf 30 umstellst?

Gruß
Patrick

Gerne, alles schon in deiner Inbox!

Hi!

Zitat von: Jamo am 20 August 2020, 18:56:13
Gerne, alles schon in deiner Inbox!

Nochmal vielen Dank für Deine Tests und Logs.

Ärgerlicherweise komme ich langsam zu dem Schluss, dass ich das Problem nur sinnvoll eingrenzen kann, wenn es bei mir auch auftritt. Mein Ziel ist es also, meine Installation kaputt zu machen. :)

Daher benötige ich Eure Hilfe:
Wenn bei Euch das Problem auftritt, dass ca. 2 Minuten nach dem Start (also beim Batteriecheck) alle Tags auf absent wechseln und dort bleiben (und auch nur dann), interessieren mich folgende Infos:

-Hardware (RPi1, Rpi2, Rpi3, NUC, VM etc.):
-Welche Bluetooth-Geräte (Sticks, intern bei Rpi) etc. sind angeschlossen/aktiv:
-Mit welchem Bluetooth-Gerät wird lepresenced verwendet:
-Die Ausgabe von
cat /etc/issue;uname -a;dpkg -l|grep -iE '(blue|firmware)';lsusb|grep -iE '(hci|blue)';/opt/vc/bin/vcgencmd version
-Welche Bluetooth-relevanten Programme/Dienste laufen noch (presenced, Batterieskripte, FHEM-Module mit BLE wie XiaomiBTLESens):

Ich hoffe, wir sehen dann eine Gemeinsamkeit, die ich bei mir nachrüsten kann.

Parallel probiere ich gerade, mein System durch Anstecken weiterer BLE-Sticks kaputt zu bekommen.

Grüße
Patrick

Hallo Patrick,
Info per PN geschickt. Zusätzliche habe ich gerade nochmal folgendes gemacht (grundconfig ist Raspberry mit internem BT + 1 x externer BT Dongle:
- den externe BT-dongle abgezogen, damit nur der interne Raspi-BT läuft, dann dev17 lepresenced auf hci0 gestartet
- einen weiteren 2-ten externen BT-dongle an den Raspberry gesteckt, und den dev17 lepresenced dann auf hci2 gestartet, weil ich wissen wollte es ob es am internen raspberry BT liegt.
- den raspberry sshhost für den XiaomiBTLESens abgeschaltet, damit XiaomiBTLESens keine Abfrage auf dem raspberry bezüglich der Blumen-Sensoren starten kann. Aber eigentlich ist das XiaomiBTLESens  intervall schon auf 14400 und sollte nicht stoeren.

Alle 3 Versuche haben keine Verbesserungen gebracht.
Bist Du Dir sicher das es bei Dir läuft und auch funktioniert? :)

Beste Grüsse!

Hi!

Erstmal @Jamo, dkreutz: Besten Dank für die ausführlichen Infos.

Zitat von: Jamo am 21 August 2020, 16:20:39
Bist Du Dir sicher das es bei Dir läuft und auch funktioniert? :)

Langsam frage ich mich auch, ob ich sie noch alle habe. Sollte ich mal auf Arbeitsunfähigkeit klagen wollen bräuchte ich Euch als Zeugen.

Interessant ist, dass Jamo's wohny nahezu exakt aussieht wie mein funktionierendes System. Du hast ein Paket mehr installiert, das aber dkreutz nicht drauf hat. Ansonsten ist Distri, Patchstand und sogar Firmwarestand absolut identisch. Die USB-IDs sind abei uns Dreien auch exakt gleich. Das ist ziemlich überraschend, da mein UD100 (ein ziemlich teurer Stick) die gleichen USB IDs hat wie mein bzw. Eure noname Sticks.

Was mir jetzt noch einfällt:

• Meinen UD100 abziehen und exklusiv mit dem Billigdongle testen.
• Irgendeine Art von gemeinsamem Remote-Debugging (shared screen Session oder vielleicht besser Teamviewer)

evtl. auch so lange mit dem Hammer auf meinen Pi dreschen, bis der Fehler auftritt.

Patrick

Moin!

Zitat von: PatrickR am 21 August 2020, 14:04:21Daher benötige ich Eure Hilfe:
Wenn bei Euch das Problem auftritt, dass ca. 2 Minuten nach dem Start (also beim Batteriecheck) alle Tags auf absent wechseln und dort bleiben (und auch nur dann), interessieren mich folgende Infos:

per PM geschickt.

Gruß
TL

Hallo Patrick,
ja vielleicht tauscht Du mal den high-tech Industrie SENA Parani-UD100 gegen einen CSL Bluetooth adapter. Ich habe mal gegoogled und die Spec/Beschreibung unter folgender Seite gelesen:

https://www.bressner.de/shop/connectivity-iot/serial-adapter/sena-parani-ud100/
SENA Parani-UD100 - Unterstützt Bluetooth  v4.0, 7 gleichzeitige unabhängige Verbindungen - mit Antenne bis zu 1000 Metern

Vielleicht liegt es wirklich an den vielen Verbindungen die der UD100 gleichzeitig kann.

Ich habe das einfache Modell hier, https://www.amazon.de/CSL-Bluetooth-verbesserte-Energieeffizienz-Technologie/dp/B01N0368AY
CSL - Bluetooth 4.0 USB Adapter - V4.0 verbesserte Energieeffizienz

Das ist ja wie David gegen Goliath.

Zitat von: Jamo am 21 August 2020, 22:29:37
ja vielleicht tauscht Du mal den high-tech Industrie SENA Parani-UD100 gegen einen CSL Bluetooth adapter.

So high-tech ist der garnicht, sieht nur gut aus und ist teuer. Ich komme nichtmal ein Stockwerk weit...
Habe ihn mal gerade gegen den hier getauscht:
https://www.amazon.de/gp/product/B00D757YZ4/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
Und siehe da: Immer noch alles super.

Zitat von: Jamo am 21 August 2020, 22:29:37
CSL - Bluetooth 4.0 USB Adapter - V4.0 verbesserte Energieeffizienz

Habe den mal bestellt auch wenn ich nicht dran glaube.

Experimentiere gerade mit ner Race Condition beim Neustart des Adapters und mit einem schlecht erreichbaren G-Tag.

Grüße
Patrick

Hallo Patrick,
also dann liegt es wohl nicht am Stick, und den CSL hätte ich Dir auch gerne für alle deine Mühen bei der Modulentwicklung zur Verfügung gestellt - ich glaube nicht, das es daran liegt.
Was ist denn sonst noch anders, zwischen deinem setup und unserem setup?
- Die Anzahl der G-Tags / erreichbarkeit der G-Tags?
- Collectord (der bei mir auf einem anderen Rechner / der FHEM Hauptinstanz läuft) <- Du hast gesagt den hast Du nicht installiert. Kann es daran liegen?
  Ich weiss ja nicht wie der lepresenecd und der collectord zusammenarbeiten.

Gruss, Jamo

Moin!

Ich war gestern im Zshg. mit unserem Problem auf folgenden Thread gestoßen:
https://www.raspberrypi.org/forums/viewtopic.php?t=201992 (https://www.raspberrypi.org/forums/viewtopic.php?t=201992)

Darin gibt es den Vorschlag, das btusb-Modul zu entladen und wieder neu zu laden:
modprobe -r btusb && sleep 1 && modprobe btusb

Gesagt, getan - seitdem funktionieren die Dongles wieder wie gewohnt, also An- und Abwesenheit werden wieder erkannt. Dafür funktioniert jetzt offenbar die Batterieabfrage nicht mehr.  :( Hier der entsprechende Auszug aus dem Syslog:
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:0] main::battery_task: Starting battery task, 5 reachable device(s) to query...
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:0] main::battery_task: Battery level for mac 7c:2f:80:... is unknown.
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:0] main::battery_task: Battery level for mac 7c:2f:80:...is unknown.
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:1] main::bluetooth_scan_thread: hcitool was stopped.
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:2] main::bluetooth_dump_thread: hcidump was stopped.
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:0] main::battery_task: Battery level for mac 7c:2f:80:... is unknown.
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:0] main::battery_task: Battery level for mac 7c:2f:80:... is unknown.
Aug 22 12:34:49 fhem lepresenced[13469]: [tid:0] main::battery_task: Battery level for mac 7c:2f:80:... is unknown.
Aug 22 12:34:51 fhem lepresenced[13469]: [tid:0] main::battery_task: Battery task completed.
Aug 22 12:34:52 fhem lepresenced[13469]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', resetting...
Aug 22 12:34:52 fhem lepresenced[13469]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
Aug 22 12:34:53 fhem lepresenced[13469]: [tid:1] main::bluetooth_scan_thread: Received 'LE Scan ...'.
Aug 22 12:36:16 fhem lepresenced[13469]: [tid:0] main::cleanup_task: Cleanup finished, deleted 6 devices in 0 seconds.

Viele Grüße
   TL

Hi!

Zitat von: Jamo am 22 August 2020, 13:09:37
lso dann liegt es wohl nicht am Stick, und den CSL hätte ich Dir auch gerne für alle deine Mühen bei der Modulentwicklung zur Verfügung gestellt - ich glaube nicht, das es daran liegt.

Das ist garnicht nötig. Habe die Bestellung schon wieder storniert.

Es gibt nämlich gute Nachrichten. Ich habe gestern noch einmal die Logs gewälzt und endlich die Ursache gefunden. lepresenced beendet vor der Batterieabfrage hcitool und hcidump. Hcidump interessiert das aber nicht. Es läuft einfach weiter, aber nur genau dann, wenn lepresenced vom wundervollen Systemd gestartet wird, d. h. wenn mein deb-Paket benutzt wird. Das müsste man mal im Detail erforschen aber ich unterdrücke den Drang einfach mal.

Ich baue gerade an einer aktualisierten Version.

Grüße
Patrick

ZitatEs gibt nämlich gute Nachrichten.

TADA!!! Glückwunsch!! Das freut mich wenn es das gewesen sein sollte!

Mahlzeit!

So, im Startposting hängt die neue Version lepresenced0.93dev18.

Änderungen:

• hcidump wird nun beim Batteriecheck mit Gewalt beendet. Dadurch startet es danach sauber.
• Die Batteriewerte werden nur gesendet, wenn sie vorliegen (also nicht unknown sind) und nicht älter als das 4-fache des Batterie-Intervalls sind, d. h. im Standardfall nicht älter als 24 Stunden. Das sollte die oben beschriebene collectord-Problematik abmildern.

Viel Spaß beim Testen!

Grüße
Patrick

Läuft! Er hat die ersten 5 Minuten anstandslos überstanden.

[UPDATE] Läuft immer noch, habe den dev18 jetzt auf allen 3 Raspi + FHEM Hauptinstanz iNUC am laufen.
Der collectord zeigt jetzt auch im Reading daemon den lepresenced V0.93dev18 an
Das battery_level ist bei 3 von 5 GTags aktualisiert.

!.Glückwunsch.! und Danke!

Hi Patrick,
das battery_level wird jetzt auch jede Minute aktualisiert. Da Du geschrieben hast, das der hcidump im Intervall mit Gewalt beendet wird (und er wird ja auch dann wieder gestartet) - Bei mir ist das Intervall 60 Sekunden - Macht das nicht Sinn, den battery_level e.g. nur alle 4-6 Stunden abzufragen, und auch nur dann, wenn das BT device present ist? Alle 60 sekunden einen prozess zu killen und dann wieder neu zu starten hoert sich komisch an.

Hi!

Zitat von: Jamo am 22 August 2020, 15:18:06
Das battery_level wird jetzt auch jede Minute aktualisiert. Da Du geschrieben hast, das der hcidump im Intervall mit Gewalt beendet wird (und er wird ja auch dann wieder gestartet) - Bei mir ist das Intervall 60 Sekunden - Macht das nicht Sinn, den battery_level e.g. nur alle 4-6 Stunden abzufragen, und auch nur dann, wenn das BT device present ist? Alle 60 sekunden einen prozess zu killen und dann wieder neu zu starten hoert sich komisch an.

Oh, da habe ich mich unklar ausgedrückt. Also: Das battery_level wird standardmäßig alle 6 Stunden bei den GTags abgefragt, aber bei jeder Aktualisierung (z. B. weil 60 Sekunden um sind oder sich die rssi stark geändert hat) mit übertragen (Ausnahme: Es ist älter als 24 Stunden). Das siehst Du auch nach einer Stunde sehr gut, wenn battery_level_age von 0 auf 1 springt. Die 6 Stunden kannst Du unabhängig ändern mit --batteryinterval.

Schön, dass es funktioniert. Danke auf jeden Fall für Deine tatkräftige Hilfe. @all: Das gilt auch für Euch.

Das kannst Du übrigens schön im Syslog sehen, wenn der Log Level auf DEBUG steht. Da solltest Du ihn aber beim Raspberry nicht stehen lassen, da die SD-Karte das dauerhaft nicht gut findet.

Grüße
Patrick

Super, dann schau ich bei den beiden GTags, mit den noch nicht aktualisiertem battery_level, in 6h wieder vorbei. Danke nochmal, bei mir läufts perfekt. Die BTLEBattery Instanz ist schon dem delete Knopf zum Opfer gefallen :-) 

Jo, läuft bei mir jetzt auch. Batterieabfrage muss ich noch weiter beobachten, aber der status ist auf jeden Fall jetzt wieder brauchbar. Vielen Dank, Patrick!

Die dev18 läuft bei mir seit ca. 10h, presence funktinioniert, battery_level wurde aber bisher nicht aktualisert (reading timestamp ist immer noch von gestern).

Zitat von: dkreutz am 22 August 2020, 21:40:58
Die dev18 läuft bei mir seit ca. 10h, presence funktinioniert, battery_level wurde aber bisher nicht aktualisert (reading timestamp ist immer noch von gestern).

War der GTag durchgehend gut erreichbar? Kannst auch tesweise mal einen StatusRequest abschicken, dann sollte 3 Minuten später der Wert kommen. Ansonsten Loglevel hochsetzen und lepresenced durchstarten.

Patrick

Hi Patrick, kann es sein, das der batteriecheck nur beim ersten mal, nach dem neu-starten des lepresenced funktioniert?
Meine beiden GTags, die noch kein update bekommen haben, sind sehr gut erreichbar (ich habe ja die verteilte installation mit einem Raspi/lepresenced in jedem Zimmer), und z.B. der GTag "black" hat jetzt nach 8 h noch kein batterie_level update bekommen. Auch mehrmaliges "statusrequest" hat kein battery_level generiert. Dann habe ich gerade mal den lepresenced bei dem rechner wo der 'black' daneben liegt, mit 'sudo service lepresenced restart' neu gestartet, und da ist das battery_level sofort gekommen.

Ich habe noch einen G-Tag 'orange', der ist auch sehr gut erreichbar, der hat auch noch kein battery_level bekommen, auch nach mehrmaligem 'statusrequest'. Kann ja eigentlich nicht sein, egal in welchem Zimmer, da ist ja immer ein Raspi mit lepresenced daneben. Ausserdem ist da auch, wie bei den anderen GTags, die Batterie neu gewechselt (hatte ich extra für unsere lepresenced Tests noch gemacht). Da mache ich jetzt mal nix und sag morgen früh nach weiteren 12h nochmal Bescheid.

PS: Nach dem G-Tag 'orange' statusrequest sehe ich dass das reading 'command_accepted' auf 'yes' updated, die rssi werden erneuert, aber kein battery_level :-( 
Und er liegt jetzt direkt daneben. Ich berichte morgen um 12:00 nochmal :)

Hi!

Vielleicht nochmal eine Erläuterung, wie die Batterieabfrage organisiert ist:
2 Minuten nach dem Start und dann (Default) alle 6 Stunden erfolgt eine Batterieabfrage.
Es werden alle Tags abgefragt, die alle der folgenden Voraussetzungen erfüllen:

• Mindestens ein Client (FHEM/collectord) ist mit lepresenced verbunden und interessiert sich für die Mac-Adresse des Tags
• Der Tag ist exakt zum Zeitpunkt der Abfrage present.

Auch dann kann die Batterieabfrage noch fehlschlagen, wenn zwar die Beacons ankommen, aber keine stabile Verbindung möglich ist.

Wenn es immer noch nicht funktioniert den Log Level auf LOG_DEBUG setzen. Eine erfolgreiche Batterieabfrage sieht dann so aus:

Aug 22 14:10:18 rpi-flur lepresenced[5068]: [tid:0] main: Version 0.93dev18 started (device: hci0, listen addr: 0.0.0.0, listen port: 5333, daemonize: 1, legacy mode: 0, rssi threshold: 10, battery interval: 6, log level: 7, debug: 0).
Aug 22 14:12:19 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Starting battery task, 3 reachable device(s) to query...
Aug 22 14:12:22 rpi-flur lepresenced[5077]: [tid:0] main::get_battery_level: gatttool (mac: 11:11:11:11:11:11, address type: 'public'): 'handle: 0x0028 #011 value: 64 '
Aug 22 14:12:22 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Battery level for mac 11:11:11:11:11:11 is 100.
Aug 22 14:12:24 rpi-flur lepresenced[5077]: [tid:0] main::get_battery_level: gatttool (mac: 22:22:22:22:22:22, address type: 'public'): 'handle: 0x001b #011 value: 64 '
Aug 22 14:12:24 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Battery level for mac 22:22:22:22:22:22 is 100.
Aug 22 14:12:27 rpi-flur lepresenced[5077]: [tid:0] main::get_battery_level: gatttool (mac: 33:33:33:33:33:33, address type: 'public'): 'handle: 0x001b #011 value: 64 '
Aug 22 14:12:27 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Battery level for mac 33:33:33:33:33:33 is 100.
Aug 22 14:12:29 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Battery task completed.
Aug 22 20:12:30 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Starting battery task, 1 reachable device(s) to query...
Aug 22 20:12:32 rpi-flur lepresenced[5077]: [tid:0] main::get_battery_level: gatttool (mac: 11:11:11:11:11:11, address type: 'public'): 'handle: 0x0028 #011 value: 64 '
Aug 22 20:12:32 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Battery level for mac 11:11:11:11:11:11 is 100.
Aug 22 20:12:34 rpi-flur lepresenced[5077]: [tid:0] main::battery_task: Battery task completed.

Man sieht Folgendes:

• Um 14:10 wird lepresenced gestartet
• 2 Minuten später wird das erste Mal der battery_task gestartet, dann 6 Stunden später.
• Beim ersten Aufruf des battery_tasks sind drei Geräte in FHEM definiert und present. Die Abfragen sind jeweils erfolgreich und ergeben 100%
• Beim zweiten Aufruf nach 6 Stunden ist nur ein Gerät definiert und present. Die Abfrage ergibt wieder 100%

Patrick

Hallo Patrick, battery_level läuft!! Hammer! Ein RIESEN Danke nochmal von mir und auch von allen!

Ich verfolge den Thread nun schon seit ein paar Tagen und habe die letzten vier Version auch immer eingespielt.
Irgendwie läuft das nicht so ganz verlässig. Mit der 0.92 werden mir die Mac-Adressen direkt angezeigt. Mit der 0.93dev18 kommt nichts an.


Starte lepresenced

[tid:0] main: Version 0.93dev18 started (device: hci0, listen addr: 0.0.0.0, listen port: 5333, daemonize: 0, legacy mode: 0, rssi threshold: 10, battery interval: 6, log level: 7, debug: 0).
[tid:0] main::sanity_check: md5 digest of '/opt/lepresenced' is: '5d73a534650340199bd0de9381a48f3b'.
[tid:0] main::sanity_check: hciconfig found at '/bin/hciconfig'.
[tid:0] main::sanity_check: hcitool found at '/usr/bin/hcitool'.
[tid:0] main::sanity_check: gatttool found at '/usr/bin/gatttool'.
[tid:0] main::sanity_check: hcidump found at '/usr/bin/hcidump'.
[tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', resetting...
[tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
[tid:0] main::stats_task: Active clients: 0, known devices: 7 (min/max age: 0/1), received beacons (hcitool/hcidump/difference): 1664/1664/0
[tid:0] main::battery_task: Skipping battery task, no devices to query.
[tid:0] main::stats_task: Active clients: 0, known devices: 8 (min/max age: 0/5), received beacons (hcitool/hcidump/difference): 3479/3479/0


Ich habe aber definitiv schon einmal die Geräte mit den 0.93er-Versionen gesehen. Ich habe aber Probleme, dies zu rekonstruieren.

Ich beobachte weiter.

Nachtrag 1:
10 Minuten später wurde ein Device gefunden. Das war bei der 0.92 direkt nach dem Start.
Ein zweites Device weigert sich vehement in 0.93. Und ich weiß nicht wieso.

Nachtrag 2:
Ich kann das reproduzieren. Ich hatte schon das Vertrauen in meinem eigenen GTag verloren.
Tatsächlich wird dieser in 0.92 direkt angezeigt. In 0.93 gar nicht mehr. Dies war in den Betas vorher aber auch schon einmal anders.

Nachtrag 3:
Ich lasse gerade den Debug-Modus laufen. In der Liste der "Known Devices" sind alle Mac-Adressen enthalten. Ist diese Info wichtig?

Hallo,

habe nun auch mal lepresenced V0.93dev18 "installiert" :)
("sicherheitshalber" auch mal libreadonly-perl)

SUPER!

Also Anwesenheit (bislang) "ohne Befund"...
...und Batteriewert endlich auch!! :)

Hatte ich bislang weggelassen, weil mir das "zu kompliziert" war...
...ich merke ja, wenn die Abwesenheit "zickt" und dann wäre das Erste gewesen mal nach den Batterien zu schauen...

So ist das nat. VIEL BESSER!

Also: vielen Dank!

Gruß, Joachim

Hi!

Zitat von: MadMax-FHEM am 23 August 2020, 14:39:26
Hatte ich bislang weggelassen, weil mir das "zu kompliziert" war...
...ich merke ja, wenn die Abwesenheit "zickt" und dann wäre das Erste gewesen mal nach den Batterien zu schauen...

Ich hatte mich aus den gleichen Gründen und weil die Bluetooth-Implementierung immer noch sehr launisch ist immer dagegen gewehrt, bis ich mich dann mal über einen überraschend leeren G-Tag geärgert habe ;)

Grüße
Patrick

Hi!

Zitat von: FunkOdyssey am 23 August 2020, 14:38:33
Ich verfolge den Thread nun schon seit ein paar Tagen und habe die letzten vier Version auch immer eingespielt.
Irgendwie läuft das nicht so ganz verlässig. Mit der 0.92 werden mir die Mac-Adressen direkt angezeigt. Mit der 0.93dev18 kommt nichts an.

Eigentlich habe ich an dem Scan an sich nichts Dramatisches geändert. Bis zum ersten Batteriescan, d. h. bis 2 Minuten nach dem Start sollte alles wie vorher sein. Da ich aber den Code etwas umstrukturiert habe, könnte es evtl. doch ein Problem geben. Das halte ich aber nicht für sehr wahrscheinlich.

Zitat von: FunkOdyssey am 23 August 2020, 14:38:33
Nachtrag 3:
Ich lasse gerade den Debug-Modus laufen. In der Liste der "Known Devices" sind alle Mac-Adressen enthalten. Ist diese Info wichtig?

Der Debug-Modus ist definitiv hilfreich, und noch mehr die Known Devices.

Da sind aber die Details wichtig. Hinter jedem Gerät werden zwei "ages" angegeben: Die Zeit in Sekunden seit dem letzten und vorletzten empfangenen Beacon. Beide Zeiten müssen unterhalb der in FHEM eingestellten Schwelle sein (z. B. 60s). Bei meinen G-Tags sind die immer beide unter 5s. Wenn Du die Ausgabe mal postest, kann ich es mir mal ansehen.

Was steht denn in den PRESENCE-Instanzen in FHEM wenn das Problem auftritt? absent oder disconnected?

Patrick

Irgendetwas passt bei mir nicht.
Ich bin mir nicht mehr sicher, ob du meine Worte oben Glauben schenken kannst.
Auch mit 0.92 hatte ich gerade das Problem, dass die Gtags nicht mehr online gingen.

Die Presence-Devices stehen dann immer auf DISCONNECTED.



Known devices (27):
...
mac: 7c:2f:80:c3:xx:xx, ages:  2/ 4, rssi: -67, name: Gigaset G-tag, battery: unknown
mac: 7c:2f:80:c3:xx:xx, ages:  0/ 0, rssi: -76, name: Gigaset G-tag, battery: unknown

Received beacons (hcitool/hcidump): 67931/67795, difference: 136


Hi!

Zitat von: FunkOdyssey am 23 August 2020, 16:13:53
Irgendetwas passt bei mir nicht.
Ich bin mir nicht mehr sicher, ob du meine Worte oben Glauben schenken kannst.

Warum sollte ich Dir nicht glauben. Das hätte sich weiter oben viel mehr gelohnt, wo es bei keinem funktioniert hat außer bei mir ;)

Zitat von: FunkOdyssey am 23 August 2020, 16:13:53
Auch mit 0.92 hatte ich gerade das Problem, dass die Gtags nicht mehr online gingen.
Die Presence-Devices stehen dann immer auf DISCONNECTED.

Aha!
DISCONNECTED bedeutet, dass die PRESENCE-Instanz in FHEM nicht mit lepresenced verbunden ist. Das erklärt auch, warum die Geräte bei lepresenced bekannt sind. Wenn Du lepresenced neu startest bricht die Verbindung von FHEM ab, erholt sich aber irgendwann(!) wieder - je nach Timing früher oder später. Wenn Du darauf nicht warten willst einfach in der PRESENCE-Instanz in FHEM auf "DEF" klicken und dann auf direkt auf den "modify $GERÄTENAME" Button. Dann baut er sofort eine neue Verbindung auf. Wenn das passiert ist, geht der Status in FHEM entweder auf present oder absent.

Zitat von: FunkOdyssey am 23 August 2020, 16:13:53

Code Auswählen Erweitern


Known devices (27):
...
mac: 7c:2f:80:c3:xx:xx, ages:  2/ 4, rssi: -67, name: Gigaset G-tag, battery: unknown
mac: 7c:2f:80:c3:xx:xx, ages:  0/ 0, rssi: -76, name: Gigaset G-tag, battery: unknown

Received beacons (hcitool/hcidump): 67931/67795, difference: 136


Besser gehts nicht. Alles prima. Die Batteriewerte kommen dann auch wenn Du direkt nach dem Start die Verbindung aus FHEM herstellst (s. o.).

Grüße
Patrick

Zitat von: PatrickR am 23 August 2020, 16:20:37
DISCONNECTED bedeutet, dass die PRESENCE-Instanz in FHEM nicht mit lepresenced verbunden ist. Das erklärt auch, warum die Geräte bei lepresenced bekannt sind. Wenn Du lepresenced neu startest bricht die Verbindung von FHEM ab, erholt sich aber irgendwann(!) wieder - je nach Timing früher oder später. Wenn Du darauf nicht warten willst einfach in der PRESENCE-Instanz in FHEM auf "DEF" klicken und dann auf direkt auf den "modify $GERÄTENAME" Button. Dann baut er sofort eine neue Verbindung auf. Wenn das passiert ist, geht der Status in FHEM entweder auf present oder absent.

Ab und zu kann ich mit dem DEF-Button die Geräte in FHEM zum Leben erwecken. Aber es scheint, als könnte ich immer nur ein Gerät anzeigen lassen.

Ich habe in FHEM zwei PRESENCE-Devices, die seit Jahren fehlerfrei gearbeitet haben.

Gerade habe ich auf der Bash einen LEScan gemacht. Ich musste aber zuvor, das HCI-Device freischalten.

hciconfig hci0 down
hciconfig hci0 up

Im LEScan werden mir natürlich auch alle Geräte angezeigt.

Nur bekomme ich scheinbar nie beide PRESENCE-Geräte online.

Nachtrag: Es ist wirklich so. Ich habe gerade die Mac-Adressen in FHEM gefälscht und direkt danach kam das zweite Geräte online (nach DEF-Button). Aber immer nur eines. :-)

STOP. Kommando zurück für alles.

Ich habe ein DNS-Problem in meinem Netzwerk.
Ich habe die PRESENCE-Devices auf IP umgestellt und schon ist alles wieder wie zuvor.

Es tut mir leid, dass ich dich damit beschäftigt habe.

Version dev18 nach 24h:
1. Reboot tut gut ;-)
2. ein Tag funktioniert prima inkl. battery_level
3. beim anderen Tag funktioniert zwar presence, battery_level wird aber nicht aktualisiert, Reading Timestamp von vorgestern

Zitat von: dkreutz am 23 August 2020, 21:13:35
Version dev18 nach 24h:
1. Reboot tut gut ;-)
2. ein Tag funktioniert prima inkl. battery_level
3. beim anderen Tag funktioniert zwar presence, battery_level wird aber nicht aktualisiert, Reading Timestamp von vorgestern

Ihre Stimme wurde gezählt. :)
Im Ernst: Ohne Log mit LOG_DEBUG kommen wir nicht weiter.

Patrick

Hallo dkreutz,
mach mal probehalber einen Batteriewechsel bei deinem G-Tag, und warte mal 24h. Ich hatte das gleiche bei einem meiner G-Tags (presence erkannt, battery_level nicht), Nach dem Batteriewechsel war alles gut.

Hallo Patrick,
nochmal zur Rückmeldung, läuft erste Sahne!
Ich sehe jetzt das battery_level_age schön hochzählen, dann sind es auch schonmal 11 oder 13 Stunden, aber dann wird doch wieder ein neues battery_level geliefert, wie Du geschrieben hast. Alle G-Tags werden regelmässig ge-updated. Also alles prima, Danke nochmal und gerne wieder!

Das hätte ich auch vielleicht erwähnen können. Die Batterieerkennung funktioniert bei mir auch einwandfrei.

Mahlzeit!

Erstmal danke für die positiven Rückmeldungen. Die scheinbar noch vorhandenen Probleme würden mich natürlich interessieren.

Vielleicht noch eine Anmerkung: Da die Batterien von den G-Tags relativ lange halten, hatte ich angenommen, dass eine erfolgreiche Abfrage am Tag genügt. Mit dem Sicherheitsfaktor 4 sind wir bei Abfragen alle 6 Stunden. Wem das zu ungenau ist, der kann es mit --batteryinterval auf bis zu 1 Stunde runterstellen.

Grüße
Patrick

Hallo Patrick,

bei mir funktioniert die Batterieabfrage leider gar nicht. Mein Log habe ich dir per PM geschickt. Wenn wir das jetzt bei mir auch noch hinbekommen würden, ware das das I-Tüpfelchen.

Viele Grüße
   TL

Dann von mir noch ein Update: presence funktioniert weiter stabil, der Batterie-Status funktioniert seit gestern auf beiden G-Tags (ohne weitere Eingriffe von mir, also kein Reboot oder Batteriewechsel).

Hi!

Zitat von: dkreutz am 25 August 2020, 08:22:29
Dann von mir noch ein Update: presence funktioniert weiter stabil, der Batterie-Status funktioniert seit gestern auf beiden G-Tags (ohne weitere Eingriffe von mir, also kein Reboot oder Batteriewechsel).

Gut zu hören. Wenn Dir die Zahl der erfolgreichen Abfragen zu niedrig ist kannst Du das Intervall auch mit --batteryinterval 3 auf 3 Stunden setzen. Das geht z. B. in der letzten Zeile von /etc/default/lepresenced wenn Du das DEB-Paket verwendest.

Patrick

Hi!

Zitat von: TL am 24 August 2020, 23:39:40
bei mir funktioniert die Batterieabfrage leider gar nicht. Mein Log habe ich dir per PM geschickt. Wenn wir das jetzt bei mir auch noch hinbekommen würden, ware das das I-Tüpfelchen.

Hmm.

Aug 24 23:07:03 fhem lepresenced[32521]: [tid:0] main::get_battery_level: gatttool (mac: aa:aa:aa:aa:aa:aa, address type: 'public'): 'connect: Connection refused (111)'

Was sind das für Tags, die Du verwendest? Hattest Du mit anderen Batteerietools/-modulen Erfolg?

/Edit: Bitte auf jeden Fall auch auf 0.93dev19 updaten.

Patrick

Neue Version 0.93dev19:
-Workaround für Race Condition, die zu fehlerhaften Batterieabfragen und zu Problemen mit der Anwesenheitserkennung führen kann.

Patrick

Nabend :)

Nur mal für mein Verständnis: was genau muss ich tun, um Batteriewerte zu bekommen, ausser den lepresenced in /usr/sbin/ zu ersetzen?
Dieses Ersetzen hat erstmal problemlos funktioniert wie im zugehörigen reading zu sehen.

daemon lepresenced V0.93dev19 2020-08-25 19:17:05

Wenn ich es richtig interpretiert habe, ist der Einsatz der bisher in FHEM "üblichen" Verfahren zur Batterieüberwachung durch die neue Version von lepresenced doch obsolet geworden, oder?

Hi!

Zitat von: betateilchen am 25 August 2020, 19:23:13
Nur mal für mein Verständnis: was genau muss ich tun, um Batteriewerte zu bekommen, ausser den lepresenced in /usr/sbin/ zu ersetzen?
Dieses Ersetzen hat erstmal problemlos funktioniert wie im zugehörigen reading zu sehen.

Das war's eigentlich schon. Wenn die Tags erreichbar sind solltest Du nach ca. 3 Minuten die Batteriereadings sehen. Danach werden dann alle 6 Stunden die erreichbaren(!) Tags befragt. Ich würde allerdings (noch) nicht meine Hand dafür ins Feuer legen, dass das schon 100% rund läuft. BleTagBattery z. B. benutzt einen Trial-And-Error-Ansatz zur Ermittlung der Verbindungsmethode zu den Tags, ich hole mir die Information aus dem Scan. Mit GTags sollte es aber keine Probleme geben.

Zitat von: betateilchen am 25 August 2020, 19:23:13
Wenn ich es richtig interpretiert habe, ist der Einsatz der bisher in FHEM "üblichen" Verfahren zur Batterieüberwachung durch die neue Version von lepresenced doch obsolet geworden, oder?

Ja, das war der Gedanke. Vorteil ist vor allem, dass lepresenced sich selbst immer den Staffelstab übergeben kann, d. h. Scannen beenden, Batterien abfragen, Scannen starten.

Grüße
Patrick

Funktioniert plötzlich, nachdem ich testweise den lepresenced auf der Konsole im debug Modus gestartet habe.

Zitat von: betateilchen am 25 August 2020, 20:26:20
Funktioniert plötzlich, nachdem ich testweise den lepresenced auf der Konsole im debug Modus gestartet habe.

Die Batterien werden nur abgefragt, wenn zum Zeitpunkt des Batterie-Tasks (also 2 Minuten nach dem Start) eine zugehörige PRESENCE-Instanz in FHEM verbunden ist. Vielleicht ist das der Grund. Wollte bei Gelegenheit mal nachsehen, wann DevIO den Reconnect durchführt.

Patrick

Dann werde ich mal beobachten, ob sich der Wert in 6 Stunden aktualisiert.

Allerdings frage ich mich gerade, ob ein Wert von 100% bei einer 8 Monate alten Batterie (ich habe an Weihnachten die Batterie gewechselt) tatsächlich plausibel ist.

Hi!

Zitat von: betateilchen am 25 August 2020, 20:32:16
Dann werde ich mal beobachten, ob sich der Wert in 6 Stunden aktualisiert.

Allerdings frage ich mich gerade, ob ein Wert von 100% bei einer 8 Monate alten Batterie (ich habe an Weihnachten die Batterie gewechselt) tatsächlich plausibel ist.

Das macht mich auch nachdenklich. Wenn ich mit gatttool abfrage, kommt 0x64 zurück. Da gibt es eigentlich keinen Interpretationsspielraum.

Grüße
Patrick

ja, den Wert sehe ich auch in der Debug Ausgabe aus dem battery task.
Meine Frage bezog sich auch weniger auf lepresenced sondern auf den Wert an sich.

Hi!

Zitat von: betateilchen am 25 August 2020, 20:35:52
Meine Frage bezog sich auch weniger auf lepresenced sondern auf den Wert an sich.

Das hatte ich auch so verstanden. Habe gerade mal einen G-Tag ans Labornetzteil gehängt. Bis 3,1V meldet der Tag 100% (Auch in einer iOS-App), bei 3,0V springt der Wert dann auf 94%, was lepresenced auch richtig anzeigen würde, wenn ich nicht einen dämlichen Fehler gemacht hätte.

Neue Version im Startposting:
lepresenced0.93dev20: Unter bestimmten Umständen wurden Werte nicht angezeigt.

Grüße
Patrick

Hi Patrick, runtergeladen und installiert. Läuft bisher problemlos! Alle battery_level readings wurden schon aktualisiert, alles prima. Danke!

Moin!

Bei mir geht die Batterieabfrage jetzt auch. Was habe ich geändert? Bei meinem telnet-Device habe ich im Attribut allowfrom die Adresse 127.0.0.1 zusätzlich mit eingetragen. Kann es daran gelegen haben?

Viele Grüße
   TL

Zitat von: TL am 26 August 2020, 00:16:22
Kann es daran gelegen haben?

da die readings per Telnet gesetzt werden, gibt es eine hohe Wahrscheinlichkeit dafür.

Interessant... mit dev20 werden Batteriewerte schneller geliefert, dafür wird das G-Tag selbst nicht mehr als "present" erkannt.

Das heißt, ich bekomme für ein "absent" device immerhin einen Batteriewert Das war ein Irrtum meinerseits.

Genaugenommen: es wird keines meiner drei Tags (2 * Gtag 1*iTag) mehr als present gemeldet.

Dummerweise habe ich dev19 bereits gelöscht und kann die Verifizierung der Versionsabhängigkeit nicht weiter durchführen.

---

Edit:

Vermutlich bin ich wieder daran gescheitert, dass keine PRESENCE Instanz mit lepresenced verbunden war.
Offenbar ist also gar nicht lepresenced die Ursache für das Problem mit den Verzögerungen (im debug Modus werden alle Werte korrekt ermittelt), sondern PRESENCE selbst.

Interessant das Du das sagst - Ich habe auch den Eindruck das die Batteriewerte mit dev20 wesentlich schneller kommen. Prima!

Zitat von: betateilchen am 26 August 2020, 08:10:53
da die readings per Telnet gesetzt werden, gibt es eine hohe Wahrscheinlichkeit dafür.

Eigentlich nicht. Das war bei den Batterieskripten so. Aber bei lepresenced kommen die Batteriewerte auf dem gleichen Weg wie present/absent, d. h. über ausgehende Verbindungen.

@betateilchen:
Was ist denn der letzte Stand mit dev20? Klappt present/absent? Die Änderung auf dev20 ist wirklich minimal.

Es funktioniert "teilweise".

ich habe zwei Gtag - eines davon liefert presence und battery Werte. Das zweite, heute später zum laufenden FHEM hinzugekommen (also schon länger definiert, aber heute zum ersten Mal wieder "present") liefert nur presence, aber keine Batterie. Meine Vermutung: Ein Gtag, das später als 3 Minuten nach lepresenced-Start erstmalig present wird, fällt in das 6-Stunden-Raster. Die 6 Stunden sind aber noch nicht um, um das genau verifizieren zu könne.

Auch interessant: ausgerechnet das Gtag, das seit Jahren problemlos in FHEM funktionierte, wird aktuell gar nicht mehr present gefunden, obwohl es sich an der gleichen Stelle befindet wie vorher. Diesem Phänomen muss ich noch nachgehen.


[tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:..., address type: 'public'): 'connect error: Function not implemented (38)'
[tid:0] main::battery_task: Battery level for mac 7c:2f:80:... is unknown.
[tid:0] main::get_battery_level: gatttool (mac: ff:ff:60:..., address type: 'public'): 'connect error: Connection refused (111)'
[tid:0] main::battery_task: Battery level for mac ff:ff:60:... is unknown (timeout).
[tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:..., address type: 'public'): 'connect error: Function not implemented (38)'
[tid:0] main::battery_task: Battery level for mac 7c:2f:80... is unknown.


Offenbar liefern beide gtags (7c:2f...) gar keine Batteriewerte mehr?
(Das ff:ff:... ist ein iTag, das ist normal.)

---

Edit: ich habe mal die Aktualisierung der Batteriewerte auf 300 Sekunden eingestellt.

Ergebnis: zwischendurch funktioniert der Abruf der Werte, meistens aber nicht.


[tid:0] main::battery_task: Starting battery task, 2 reachable device(s) to query...
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_dump_thread' to 'THREAD_COMMAND_STOP'.
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_scan_thread' to 'THREAD_COMMAND_STOP'.
[tid:2] main::bluetooth_dump_thread: hcidump was stopped.
[tid:1] main::bluetooth_scan_thread: hcitool was stopped.
[tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:ad:...., address type: 'public'): 'connect error: Function not implemented (38)'
[tid:0] main::battery_task: Battery level for mac 7c:2f:80:ad:....3 is unknown.
[tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:a1:...., address type: 'public'): 'connect error: Transport endpoint is not connected (107)'
[tid:0] main::battery_task: Battery level for mac 7c:2f:80:a1:.... is unknown.
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_scan_thread' to 'THREAD_COMMAND_RUN'.
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_dump_thread' to 'THREAD_COMMAND_RUN'.
[tid:0] main::battery_task: Battery task completed.



tid:0] main::battery_task: Starting battery task, 2 reachable device(s) to query...
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_dump_thread' to 'THREAD_COMMAND_STOP'.
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_scan_thread' to 'THREAD_COMMAND_STOP'.
[tid:2] main::bluetooth_dump_thread: hcidump was stopped.
[tid:1] main::bluetooth_scan_thread: hcitool was stopped.
[tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:ad, address type: 'public'): 'connect error: Function not implemented (38)'
[tid:0] main::battery_task: Battery level for mac 7c:2f:80:ad is unknown.
[tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:a1, address type: 'public'): 'handle: 0x001b      value: 64 '
[tid:0] main::battery_task: Battery level for mac 7c:2f:80:a1 is 100.
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_scan_thread' to 'THREAD_COMMAND_RUN'.
[tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_dump_thread' to 'THREAD_COMMAND_RUN'.
[tid:0] main::battery_task: Battery task completed.
[tid:0] main: Sending update for mac address 7c:2f:80:ad, ages: 39/39, max age: 60, rssi: -90, battery level: 94 (age: 0), result: present.
[tid:0] main: Sending update for mac address ff:ff:60:05, max age: 10, result: absence.
Known devices (8):
        mac: , ages: 805/806, rssi: -92, name: (unknown), battery: unknown
        mac: , ages: 712/713, rssi: -94, name: (unknown), battery: unknown
        mac: , ages: 41/45, rssi: -96, name: (unknown), battery: unknown
        mac: , ages: 40/40, rssi: -95, name: (unknown), battery: unknown
        mac: 7c:2f:80:a1, ages: 51/51, rssi: -94, name: Gigaset G-tag, battery: 100 (age: 2s)
        mac: 7c:2f:80:ad, ages: 39/39, rssi: -90, name: Gigaset G-tag, battery: 94 (age: 662s)
        mac: , ages: 41/41, rssi: -93, name: (unknown), battery: unknown
        mac: , ages: 807/890, rssi: -95, name: iTAG            , battery: unknown


@betateilchen:
Siehst Du im Log irgendwelche Gemeinsamkeiten der Gruppen ,,funktioniert" und ,,funktioniert nicht". Interessant könnten z. B. Fälle sein, in denen die Batteriechecks gestartet werden bevor scan/dump gestoppt wurden. Du kannst auch testweise mal die zwei SETTLE_SLEEPS oben im Code hochsetzen.

Nein, es gibt keine erkennbaren Systematiken.
Die Batteriechecks erfolgen immer, nachdem scan/dum gestoppt wurden.

Irgendwann sind die Batteriewerte in beiden Gtags vorhanden, aber es ist im Moment noch nicht vorhersehbar, wann das der Fall ist.
Da diese Werte aber für mich auch nicht zeitkritisch sind, sehe ich das Ganze nicht als dramatisches Problem an, das Verhalten ist einfach nur "merkwürdig".

Hast Du mal einen Batteriewechsel probiert? Ich weiss das die ein Jahr halten, aber man weiss halt nicht wie gut die noch sind. Das kann auch ein Grund sein.

Hi!

Zitat von: betateilchen am 26 August 2020, 18:04:25
Da diese Werte aber für mich auch nicht zeitkritisch sind, sehe ich das Ganze nicht als dramatisches Problem an, das Verhalten ist einfach nur "merkwürdig".

Merkwürdig mag ich irgendwie nicht. Ich fürchte dann immer, dass da noch was dahinter ist. Vielleicht hast du ja irgendwann mal Zeit, mit den SETTLE_SLEEPS zu experimentieren.

Grüße
Patrick

Hi!

Zitat von: Jamo am 26 August 2020, 18:08:34
Hast Du mal einen Batteriewechsel probiert? Ich weiss das die ein Jahr halten, aber man weiss halt nicht wie gut die noch sind. Das kann auch ein Grund sein.

Das mit dem Batteriewechsel könnte vielleicht *räusper* gar nicht nötig gewesen sein. Das war evtl. ein Bug, der mit dev20 gefixt wurde.

Patrick

Zitat von: PatrickR am 26 August 2020, 18:45:20
Vielleicht hast du ja irgendwann mal Zeit, mit den SETTLE_SLEEPS zu experimentieren.

achso, das hatte ich vergessen zu schreiben: Damit hatte ich schon experimentiert, das hatte keine Auswirkungen auf das beschriebene Verhalten.

ZitatDas mit dem Batteriewechsel könnte vielleicht *räusper* gar nicht nötig gewesen sein. Das war evtl. ein Bug, der mit dev20 gefixt wurde.
Patrick

Jetzt nicht im Ernst, oder? Ich fass es nicht. Und ich habe extra 5 neue CR2032 für 7,99 das Stück gekauft und gewechselt, und jetzt höre ich, dass es ein Bug war? Unglaublich. Wenn ich das meinen Kindern erzähle, die lachen sich schlapp. :)

Beste Grüsse und dank an Dich Patrick für das lepresenced!!!

noch mal eine etwas speziellere Frage:

Ich hab neben dem Haupt-PI mit FHEM und lepresenced auch ZeroWs im Einsatz ohne FHEM aber mit lepresenced drauf. Das ganze wird über Collectord gesammelt. Reich es jetzt lepresenced auf dem Haupt-PI zu aktualisieren oder muss an allen drei Geräten die gleiche Version installiert sein? Kann Colletord die Batterie-Daten überhaupt sammeln?

- lepresenced muss auf allen instanzen installiert werden, also den alten lepresenced in /usr/sbin/lepresenced durch den neuen lepresenced ersetzten, gucken ob der owner und die rechte stimmen, und dann mit 'sudo service lepresenced restart' den Dienst neu starten.
- collectord sammelt den batteriestand in 2 readings battery_level und battery_level_age.
Ist auch alles im ersten Post beschrieben.

Zitat von: Jamo am 26 August 2020, 20:23:46
neue CR2032 für 7,99 das Stück

??? wo um alles in der Welt kaufst Du denn Deine Batterien?

 :) 7,99 wegen der grösseren Reichweite!

Hallo Pattrick,

Vielen Dank für die neue Version.
Gleich ausprobiert und funktioniert bis dato ohne Probleme.
Auch der Zustand der Batterie wurde gleich ausgelesen.

Eine Bitte aber: wäre es möglich in den Log- und Debug-Ausgaben einen Zeitstempel auszugeben.
Oder geht das irgendwie schon und ich habe es nur noch nicht gerafft.

Damit wäre - zumindest für mich - die Nachvollziehbarkeit von Fehlern besser.

Danke im Voraus
Lg, Gerhard

Hallo,

ich habe gerade gelernt, dass die log-Einträge im syslog (/var/log/messages) eh mit Zeitstempel versehen sind, nur bei stdout nicht.

Die Einträge im syslog sollten reichen. Danke!
lg, Gerhard

Hallo,

ich habe da ein seltsames Phänomen mit der neuen V20, die auf 2 Systemen über collectord läuft.

Ein Rechner hat fhem mit collectord und einem lepresenced, ein zweiter ist im Vorzimmer nur mit lepresenced.
Wenn man die services startet funktioniert mal alles.
Collectord erkennt die GTags, der Batterielevel wird ausgelesen und in fhem stehen die richtigen Zimmer in den Readings room und rooms.
Auch die rssi-Werte werden richtig gesetzt.
Der GTag hat die MAC-Adresse: 58:9e:c6:0e:ec:ad

Irgendwann meldet dann lepresenced aus dem Vorzimmer, dass der GTag abwesend ist, obwohl ihn der im Wohnzimmer noch als anwesend erkennt.
Folgendes steht im syslog, wenn ich nach der MAC-Adresse filtere (tail -f /var/log/syslog | grep "58:9e:c6:0e:ec:ad"):
Aug 28 16:25:04 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2674/2674, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12288s)
Aug 28 16:25:15 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2685/2685, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12299s)
Aug 28 16:25:26 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2696/2696, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12310s)
Aug 28 16:25:37 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2707/2707, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12321s)
Aug 28 16:25:48 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2718/2718, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12332s)
Aug 28 16:25:59 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2729/2729, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12343s)
Aug 28 16:26:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:26:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:26:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:26:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:26:10 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2740/2740, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12354s)
Aug 28 16:26:21 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2751/2751, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12365s)
Aug 28 16:26:32 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2762/2762, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12376s)
Aug 28 16:26:43 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2773/2773, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12387s)
Aug 28 16:26:54 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2784/2784, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12398s)
Aug 28 16:27:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:27:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:27:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:27:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.


Mein GTag wird also gefunden, sonst würde er wohl nicht im Bereich #011mac: mit richtigem Namen angezeicht werden.
Oder bedeutet das etwas anders?

Zumindest meldet lepresenced den GTag als abwesend, obwohl er da ist.
Der Prozess lepresenced läuft mit folgenden Parametern auf einem eigenen Bluetooth-Dongle:
/usr/bin/perl /usr/sbin/lepresenced --device hci0 --listenaddress 0.0.0.0 --listenport 5333 --loglevel LOG_DEBUG --debug

Wie könnte ich das weiter debuggen?

Danke, lg, Gerhard

Hi!

Zitat von: gestein am 28 August 2020, 16:31:18

Irgendwann meldet dann lepresenced aus dem Vorzimmer, dass der GTag abwesend ist, obwohl ihn der im Wohnzimmer noch als anwesend erkennt.
Folgendes steht im syslog, wenn ich nach der MAC-Adresse filtere (tail -f /var/log/syslog | grep "58:9e:c6:0e:ec:ad"):

Code Auswählen Erweitern

Aug 28 16:25:04 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2674/2674, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12288s)
Aug 28 16:25:15 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2685/2685, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12299s)
Aug 28 16:25:26 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2696/2696, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12310s)
Aug 28 16:25:37 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2707/2707, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12321s)
Aug 28 16:25:48 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2718/2718, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12332s)
Aug 28 16:25:59 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2729/2729, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12343s)
Aug 28 16:26:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:26:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:26:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:26:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:26:10 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2740/2740, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12354s)
Aug 28 16:26:21 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2751/2751, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12365s)
Aug 28 16:26:32 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2762/2762, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12376s)
Aug 28 16:26:43 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2773/2773, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12387s)
Aug 28 16:26:54 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2784/2784, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12398s)
Aug 28 16:27:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:27:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:27:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.
Aug 28 16:27:03 Sepia-Client-WZ lepresenced[441]: [tid:0] main: Sending update for mac address 58:9e:c6:0e:ec:ad, max age: 60, result: absence.


Mein GTag wird also gefunden, sonst würde er wohl nicht im Bereich #011mac: mit richtigem Namen angezeicht werden.
Oder bedeutet das etwas anders?

Zumindest meldet lepresenced den GTag als abwesend, obwohl er da ist.

Bist Du sicher, dass der GTag da ist also nicht z. B. bewegt wurde?


Aug 28 16:26:54 Sepia-Client-WZ lepresenced[441]: #011mac: 58:9e:c6:0e:ec:ad, ages: 2784/2784, rssi: -83, name: Gigaset G-tag, battery: 100 (age: 12398s)

Die Zeile ist so zu interpretieren: lepresenced hat mal den GTag mit der MAC-Adresse 58:9e:c6:0e:ec:ad und dem Namen Gigaset G-tag gesehen. Und zwar das letzte Mal vor genau 2784 Sekunden. Um anwesend zu sein, dürfte der Zeitpunkt aber maximal 60 Sekunden zurückliegen. Daher sendet lepresenced korrekterweise absent.

Wenn Du der Meinung bist, dass der Tag erreichbar war, kannst Du mal schauen, ob 2784 Sekunden vorher ein Batteriecheck stattgefunden hat.

Patrick

Hallo Patrick,

Danke für die Erklärung, das hilft mir mal schon weiter.

Ja, ich bin mir sicher, dass der GTag noch da ist.
1) Weil er ja vom zweiten lepresenced erkannt und als present gemeldet wird
2) Weil er an meinem Schlüssel hängt und der im Vorzimmer am Schlüsselboard hängt.

Zu dem genannten Zeitpunkt ist "leider" nichts besonderes passiert (auch kein Batteriecheck).
Damit kann ich mir das mal genauer anschauen.

lg, Gerhard

Hier mal meine Beobachtung zum Bluetooth. Hardware: Raspi 3B+, internes BT, externer BT-dongle. presenced (hci1) und lepresenced (hci0) laufen auf dem Raspi. lepresenced für G-Tag, presenced für Handy-BT erkennung.

- 'hciconfig' auf der linux console liefert beide hci0, hci1 (also beide BT-Adapter erreichbar)

Manchmal meldet der presenced dann lange Zeit ein 'absent'. Wenn ich dann ein 'hciconfig' neu starte, sehe ich auf einmal nur noch hci0, und ich bin mir sicher das es nur noch der externe Adapter ist. Neustart /sudo hciconfig hci1 down/ sudo hciconfig hci1 up/ etc bringt manchmal gar nichts, das zweite BT interface lässt sich erstmal nicht wiederbeleben.

Das einzige was zuverlässig funktioniert, sind 2 externe BT dongles. Das habe ich jetzt für allem meine Raspis gemacht, und seitdem ist Ruhe.

Das gehörte zwar nicht zu diesem lepresenced thread, aber gefühlt läuft auch der lepresenecd mit der 2 x externem BT-dongle Lösung irgendwie runder/stabiler. Hat das schon mal jemand auch so beobachtet?

Moin,

habe zur Zeit die lepresenced V0.92 und läuft mit GTAG einwandfrei. Wollte nun mal die lepresenced0.93dev20 wege nder Batterieanzeige probieren. Habe dazu in /usr/sbin/lepresenced gegen die dev20 ausgetauscht, Rechte angepasst und per "sudo service lepresened restart" neu gestartet.
Ich bekomme aber keine Connection. Es wird auch weiterhin in FHEM als daemon die Version V0.92 angezeigt.
Per sudo hcitool lescan werden die GTAG auch gefunden. Gehe ich zurück auf V0.92 und läuft es ohne Probleme.

Im Logfile kann ich nichts entdecken.

Hat jemand eine Idee oder kann mir auf die Sprünge helfen?

Gruß und schönes Restwochenende
eurofinder

Hi!

Schau mal, ob das Paket
libreadonly-perl
installiert ist.

Patrick

Jau, das Paket hat gefehlt. Danke. Als Version wird korrekt lepresenced V0.93dev20 angezeigt.

Dann werde ich das jetzt mal mit der Batterieanzeige im Auge behalten.-)

Gruß
eurofinder

Auch von mir positive Rückmeldung für die V0.93dev20 inklusive korrekter Batteriemeldung.
Seit ein paar Tagen sehr stabil im Einsatz.

Super wäre es noch, als Batterie-Stand das Reading "batteryPercent" zu verwenden (wie in den DeveloperGuidelines (https://wiki.fhem.de/wiki/DevelopmentGuidelines#BatteryReadings) angeregt).

Vielen Dank,
Andreas

Das würde ich auch bevorzugen.

Hi!

Zitat von: scooty am 06 September 2020, 14:33:30
Super wäre es noch, als Batterie-Stand das Reading "batteryPercent" zu verwenden (wie in den DeveloperGuidelines (https://wiki.fhem.de/wiki/DevelopmentGuidelines#BatteryReadings) angeregt).

Das kollidiert zwar mit den restlichen Readings in PRESENCE aber erledigt. dev21 im Startposting.

Grüße
Patrick

Hallo, ich bin gerade auf diesen Thread aufmerksam gemacht worden, da ich nach dem Umstieg auf Buster auf dem RasPi Zero W mit Bluetooth-Probleme kämpfe - siehe hier:
https://forum.fhem.de/index.php/topic,114337.msg1086260.html#msg1086260
Meine Frage: Wird es irgendwann mal eine "offizielle" Version von lepresenced 0.93 in contrib geben?

Hi!

Zitat von: JWRu am 20 September 2020, 16:05:18
Meine Frage: Wird es irgendwann mal eine "offizielle" Version von lepresenced 0.93 in contrib geben?

Klar inkl. Paket, falls das Dein Anliegen ist.

@all:
Bitte mal kurze Rückmeldung von allen Nutzern, ob es mit dev21 funktioniert oder wer den Pi wütend in die Ecke gepfeffert hat.

Patrick

Also ich hatte jetzt ne ganze Weile die lepresenced_0.93dev20 laufen ohne Probleme.

Plattform: PI3 Buster (up-to-date) inkl. deCONZ und BT vom PI selbst (also nix Dongle)

Habe eben die lepresenced_0.93dev21 eingespielt: mal sehen.

Bin allerdings jetzt erst mal ne Weile weg, also "absent" ;)

EDIT: also Anwesenheit (bin grad [noch] da) geht weiterhin... :)  Batteriewert(e) kommen halt erst mal keine... Sind ja noch "aktuell"... ;) (kamen aber auch mit der 093dev20 schon regelmässig)

EDIT: bzw. ist was "komisch" bzgl. Batteriewerten (oder hab ich irgendeine Änderung/Anpassung übersehen/überlesen)?

   READINGS:
     2020-09-20 18:21:27   batteryPercent  100
     2020-09-20 18:21:27   batteryPercentAge 0
     2020-09-19 12:23:10   battery_level   94
     2020-09-19 12:23:10   battery_level_age 2
     2020-09-20 18:16:06   command_accepted yes
     2020-09-20 18:21:27   daemon          lepresenced V0.93dev21
     2020-09-20 18:21:27   device_name     Gigaset G-tag
     2020-09-20 18:21:27   model           lan-lepresenced
     2020-09-20 18:21:27   presence        present
     2020-09-20 18:21:27   rssi            -62
     2020-09-20 18:21:27   state           present

Die battery_level und battery_level_age sind "alt" (und waren bislang ok) die batteryPercent und batteryPercentAge sind neu. An sich i.O. (ich weiß: Einheitlichkeit / muss ich nur meine Batterie-Sub anpassen ;)  ). Allerdings finde ich komisch, dass der GTag jetzt wieder 100% hat und vorher "nur" 94% (gut ist nat. schön, wenn dem so ist, wenn der Wert aber nicht stimmt: nicht schön ;)  )...

Gruß, Joachim

Bei mir funktioniert alles bestens, danke Patrick.

@Joachim: zwischen dev20 und dev21 hat Patrick einzig und allein das battery reading umbenannt, sonst sind die lepresenced identisch.

Ok, dacht ich mir schon... ;)

Ist schon alles angepasst...
...gut, wenn sonst alles gleich geblieben ist...

Daher: auch bei mir alles ok! :)

Gruß, Joachim

Guten Morgen

Bei mir läuft's auch perfekt. (3x Pi3, 2xPi4, 1xTinkerBoard)
Werte werden via collectord ohne Probleme gesammelt.

Hi!

Danke für das Feedback bislang. Mehr ist natürlich immer erwünscht.

Es gibt übrigens noch ein Problem(chen) mit der neuen Version: batteryPercentAge wird nur bei present aktualisiert. D. h. wenn die letzte Aktualisierung 2 Stunden her ist und dann geht der Tag absent bleibt die Zahl stehen auch wenn die Aktualisierung natürlich länger her ist. Mir fehlt momentan noch die Idee, wie man das sauber und elegant fixen kann, aber für mich kommt es erstmal in die Kategorie nicht kriegsentscheidend.

Patrick

Das ist wirklich nur ein kosmetisches Problem.

Hi!

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

Grüße
Patrick

Zitat von: PatrickR am 22 September 2020, 22:27:38
Hi!

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

Grüße
Patrick

Läuft auf meiner ZBox (Stretch) und meinem RasPi Zero W (Buster) bestens!

Zitat von: JWRu am 23 September 2020, 19:26:23
Läuft auf meiner ZBox (Stretch) und meinem RasPi Zero W (Buster) bestens!

Das Einzige, was ich festgestellt habe, sind 2..3 mal am Tag solche Meldungen (hatte ich früher nicht):
2020.09.26 13:25:08 3: PRESENCE (Jochen_GTag) - collectord lost connection to room ZBox_BTLE
2020.09.26 13:25:08 3: PRESENCE (Jochen_GTag) - collectord reconnected to room ZBox_BTLE
2020.09.26 13:31:13 3: PRESENCE (Jochen_GTag) - collectord lost connection to room RasPi-Zero_BTLE
2020.09.26 13:31:13 3: PRESENCE (Jochen_GTag) - collectord reconnected to room RasPi-Zero_BTLE

Zur Info - meine collectord.conf sieht so aus:

# room definition
#[room-name]           # name of the room
#address=192.168.0.10   # ip-address or hostname
#port=5111                # tcp port which should be used (5111 is default)
#presence_timeout=120     # timeout in seconds for each check when devices are present
#absence_timeout=20       # timeout in secondsfor each check when devices are absent

[ZBox_BTLE]
address=127.0.0.1
port=5333
presence_timeout=180
absence_timeout=180

[ZBox_BT]
address=127.0.0.1
port=5111
presence_timeout=180
absence_timeout=180

[RasPi-Zero_BTLE]
address=192.168.178.86
port=5333
presence_timeout=180
absence_timeout=180

[RasPi-Zero_BT]
address=192.168.178.86
port=5111
presence_timeout=180
absence_timeout=180

Hallo,

nachdem sich im Laufe der Zeit einige Readings für die Batterien angesammelt hatten, wollte ich ein bisschen aufräumen und habe die Readings gelöscht, die mit den Batterien zu tun hatten.
Nun wurden nur mehr die folgenden 2 Readings angelegt:
* batteryPercent  100
* batteryPercentAge 3

Gibt es nur mehr die beiden?
Oder wie komme ich nun zu den anderen?
Da habe ich etwas den Überblick verloren.

Danke, lg, Gerhard

Ja nur mehr die beiden...

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

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

Gruß, Joachim

Moin!

Zitat von: PatrickR am 22 September 2020, 22:27:38Hi!

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

Grüße
Patrick

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

Hallo,

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

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

Lg, Gerhard

Hallo,

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

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

syslog-Einträge für die Gtags, bei denen der Batterie-Level zu stimmen scheint:
Oct  7 10:12:34 fhem2 lepresenced[560]: [tid:0] main::get_battery_level: gatttool (mac: 7c:2f:80:99:d9:a8, address type: 'public'): 'handle: 0x001b #011 value: 1a '
Oct  7 10:12:34 fhem2 lepresenced[560]: [tid:0] main::battery_task: Battery level for mac 7c:2f:80:99:d9:a8 is 26.


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

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

Danke im Voraus
lg, Gerhard

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

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

Gruß, Joachim

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

Kommando zurück...

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

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

Gruß, Joachim

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

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

lg, Gerhard

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

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

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

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

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

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

Gruß, Joachim

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

Super Sache !!!

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

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

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

Wegen Problemen mit Bluetooth auf dem RasPi-Zero-W (siehe hier: https://forum.fhem.de/index.php/topic,115563.msg1098179.html#msg1098179 (https://forum.fhem.de/index.php/topic,115563.msg1098179.html#msg1098179))
habe ich den RasPi-Syslog durchforstet. Dabei finde ich in kurzen Abständen solche Meldungen:
Nov  4 00:00:12 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:00:12 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:00:18 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:00:50 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:00:50 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:00:55 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:02:54 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:02:54 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:02:59 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:03:10 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:03:10 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:03:10 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:03:18 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:03:18 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:03:25 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:03:55 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:03:55 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:03:55 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:03:59 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:03:59 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:04:04 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:04:06 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  4 00:04:06 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:04:12 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:04:53 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2', telling hcidump and hcitool to restart...
Nov  4 00:04:53 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  4 00:04:53 WeRu-RasPi-Z lepresenced[343]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  4 00:04:56 WeRu-RasPi-Z lepresenced[343]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2', telling hcidump and hcitool to restart...

Was hat das zu bedeuten?

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

Zunächst mal: es läuft.

ABER:

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


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


dmesg sieht auch "übel" aus:


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


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

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

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

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

Danke, Joachim

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

Genau - das war bei mir auch so. Ich habe es aus dem Log gefiltert.

Zitat von: JWRu am 24 November 2020, 13:37:55
Genau - das war bei mir auch so. Ich habe es aus dem Log gefiltert.

Ja, habe ich jetzt auch mal "eingebaut"...
https://forum.fhem.de/index.php/topic,107865.msg1018420.html#msg1018420

Aber schöner wäre anders...

dmesg ist von dem Filter (nat.) unbeeindruckt...

Gruß, Joachim

ZitatAber schöner wäre anders...

Das stimmt.
Es scheint wohl ein Debian-Problem zu sein.
Ich hatte die Meldungen in ähnlicher Form mit Raspbian Stretch, Raspbian Buster und Debian Stretch auf der ZBox.

Hallo zusammen,

ich bin jetzt mit meinem "kleinem" Latein am Ende.

Ich bin von RPi2 wheezy auf RPi3 Buster umgestiegen. Ich hatte die Presence Erkennung der Gigaset Keeper ewig zuverlässig laufen.

Die letzten Tage habe ich zig Sachen ausprobiert bzgl lepresenced und RPi3 Bluetooth Probleme. Es läuft einfach nicht stabil.
Nach einem reboot oder hciconfig hci0 reset läuft es kurz. Danach "absent".

Internes BT ist in /boot/config.txt mit dtoverlay=pi3-disable-bt deaktiviert.

lepresenced 0.93-1 ist installiert und läuft (?):
ps -ef | grep lepresenced
root       585     1  1 06:15 ?        00:04:21 /usr/bin/perl /usr/sbin/lepresenced --device hci0 --listenaddress 0.0.0.0 --listenport 5333 --loglevel LOG_WARNING
root      9919   808  0 11:16 pts/0    00:00:00 grep lepresenced

BT Dongle ist dran:
hciconfig hci0 -a                                           hci0:   Type: Primary  Bus: USB
        BD Address: 00:19:86:00:2B:2E  ACL MTU: 1021:8  SCO MTU: 64:1
        UP RUNNING
        RX bytes:3136840 acl:7 sco:0 events:127175 errors:0
        TX bytes:7161 acl:7 sco:0 commands:357 errors:0
        Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH SNIFF
        Link mode: SLAVE ACCEPT
        Name: 'raspberrypi'
        Class: 0x000000
        Service Classes: Unspecified
        Device Class: Miscellaneous,
        HCI Version: 4.0 (0x6)  Revision: 0x1000
        LMP Version: 4.0 (0x6)  Subversion: 0x220e
        Manufacturer: Broadcom Corporation (15)

BT läuft:
sudo systemctl status bluetooth                             ● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset
   Active: active (running) since Fri 2021-05-07 06:15:31 CEST; 5h 2min ago
     Docs: man:bluetoothd(8)
Main PID: 358 (bluetoothd)
   Status: "Running"
    Tasks: 1 (limit: 2062)
   CGroup: /system.slice/bluetooth.service
           └─358 /usr/lib/bluetooth/bluetoothd

May 07 06:15:31 raspberrypi systemd[1]: Starting Bluetooth service...
May 07 06:15:31 raspberrypi bluetoothd[358]: Bluetooth daemon 5.50
May 07 06:15:31 raspberrypi bluetoothd[358]: Starting SDP server
May 07 06:15:31 raspberrypi systemd[1]: Started Bluetooth service.
May 07 06:15:31 raspberrypi bluetoothd[358]: Bluetooth management interface 1.18
May 07 06:15:31 raspberrypi bluetoothd[358]: Sap driver initialization failed.
May 07 06:15:31 raspberrypi bluetoothd[358]: sap-server: Operation not permitted
lines 1-17/17 (END)

BTMON:
sudo btmon                                                  Bluetooth monitor ver 5.50
= Note: Linux version 5.10.17-v7+ (armv7l)                             0.008783
= Note: Bluetooth subsystem version 2.22                               0.008795
= New Index: 00:19:86:00:2B:2E (Primary,USB,hci0)               [hci0] 0.008799
= Open Index: 00:19:86:00:2B:2E                                 [hci0] 0.008804
= Index Info: 00:19:86:00:2B:2E (Broadcom Corporation)          [hci0] 0.008810
@ RAW Open: hcidump (privileged) version 2.22          {0x0002} [hci0] 0.008816
@ RAW Open: hcitool (privileged) version 2.22          {0x0003} [hci0] 0.008886
@ MGMT Open: bluetoothd (privileged) version 1.18             {0x0001} 0.008897
@ MGMT Open: btmon (privileged) version 1.18                  {0x0004} 0.009295

list des keepers:
Internals:
   ADDRESS    7C:2F:80:C8:13:41
   DEF        lan-bluetooth 7C:2F:80:C8:13:41 127.0.0.1:5333 130
   DeviceName 127.0.0.1:5333
   FD         4
   FUUID      5c6c270b-f33f-ce30-993f-0bbbf64721968dd6
   INTERVAL_NORMAL 130
   INTERVAL_PRESENT 130
   MODE       lan-bluetooth
   NAME       BTJo
   NOTIFYDEV  global
   NR         304
   NTFY_ORDER 50-BTJo
   PARTIAL   
   STATE      present
   TYPE       PRESENCE
   READINGS:
     2021-05-07 11:21:58   batteryPercent  85
     2021-05-07 11:21:58   batteryPercentAge 5
     2021-05-06 11:03:32   command_accepted yes
     2021-05-07 11:21:58   daemon          lepresenced V0.93
     2021-05-07 11:21:58   device_name     Gigaset keeper
     2021-05-07 11:21:58   model           lan-lepresenced
     2021-05-07 11:21:58   presence        present
     2021-05-07 11:21:58   rssi            -88
     2021-05-07 11:21:58   state           present
   helper:
     CURRENT_STATE present
     CURRENT_TIMEOUT normal
     DISABLED   0
Attributes:
   absenceThreshold 2
   disable    0
   home_structure HomeStatus
   room       Anwesenheit
   userattr   home_structure home_structure_map structexclude
   verbose    5

Und dann isser wieder weg:
Internals:
   ADDRESS    7C:2F:80:C8:13:41
   DEF        lan-bluetooth 7C:2F:80:C8:13:41 127.0.0.1:5333 130
   DeviceName 127.0.0.1:5333
   FD         4
   FUUID      5c6c270b-f33f-ce30-993f-0bbbf64721968dd6
   INTERVAL_NORMAL 130
   INTERVAL_PRESENT 130
   MODE       lan-bluetooth
   NAME       BTJo
   NOTIFYDEV  global
   NR         304
   NTFY_ORDER 50-BTJo
   PARTIAL   
   STATE      absent
   TYPE       PRESENCE
   READINGS:
     2021-05-07 11:21:58   batteryPercent  85
     2021-05-07 11:21:58   batteryPercentAge 5
     2021-05-06 11:03:32   command_accepted yes
     2021-05-07 11:26:18   daemon          lepresenced V0.93
     2021-05-07 11:21:58   device_name     Gigaset keeper
     2021-05-07 11:26:18   model           lan-lepresenced
     2021-05-07 11:26:18   presence        absent
     2021-05-07 11:26:18   rssi            unreachable
     2021-05-07 11:26:18   state           absent
   helper:
     ABSENT_COUNT 1
     CURRENT_STATE present
     CURRENT_TIMEOUT normal
     DISABLED   0
Attributes:
   absenceThreshold 2
   disable    0
   home_structure HomeStatus
   room       Anwesenheit
   userattr   home_structure home_structure_map structexclude
   verbose    5

Wie man sicherlich jetzt schon gemerkt hat, habe ich keine Ahnung, ich kann ein Tutorial befolgen und hoffen das es geht. Teilweise gehts auch ein Stück tiefer... ;-)

Kann mir jemand helfen, was ich jetzt noch versuchen kann?? Vielen Dank im Voraus. Falls noch irgendwelche Informationen fehlen...immer sagen was ich noch liefern soll ( und wie). ;-)

Gruss
Jo

Ich habe/hatte ja in diesem Thread auch meine "liebe Not" mit einem Update von Buster (also Buster lief aber irgendein Update [zumindest mit meinen "Versuchen" scheint das der Grund zu sein/gewesen zu sein]): https://forum.fhem.de/index.php/topic,75559.msg673697.html#msg673697

Ab hier so: https://forum.fhem.de/index.php/topic,75559.msg1130556.html#msg1130556

Dann lief es eine zeitlang mit legacy-mode halbwegs brauchbar.

Aktuell habe ich 2 Dinge (gut eigentlich 3 ;) ):

- npresenced ("clon" von lepresenced) auf einem Raspberry PI ZeroW wo ich mein Handy abfrage und da einen BT-Dongle dran

- lepresenced auf dem Raspberry PI aus dem Thread, ebenfalls mit BT Dongle (wobei zuvor lief es auch ohne gut und bis auf geringere Reichweite auch jetzt ohne gut [nur kurz getestet]). Inzwischen sogar ohne legacy-mode (ab irgendeinem Raspberry Update ging es dann wohl wieder!?)

- structure beider Presence -> die erzeugt dann das tatsächliche Presence

Das läuft jetzt seit einigen Wochen/Monaten wieder so gut wie zuvor nur das lepresenced...

Gruß, Joachim

Nachdem ich lediglich ein update von lepresenced von der Version 0.9 auf 0.93 durchgeführt habe und danach den service restarted habe, erscheint immer diesr Fehler und es geht nichts mehr:

lkcc@LKCC-LENOVO:/usr/sbin$ sudo systemctl status lepresenced
● lepresenced.service - lepresenced
   Loaded: loaded (/etc/systemd/system/lepresenced.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2021-11-06 13:46:24 CET; 8min ago
  Process: 22435 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 22438 (lepresenced)
    Tasks: 5 (limit: 4915)
   Memory: 16.6M
   CGroup: /system.slice/lepresenced.service
           ├─22438 /usr/bin/perl /usr/sbin/lepresenced --device hci1 --listenaddress 0.0.0.0 --listenport 5333 --loglevel L
           ├─22526 hcidump -i hci1
           └─22527 hcitool -i hci1 lescan --duplicates

Nov 06 13:46:14 LKCC-LENOVO systemd[1]: Starting lepresenced...
Nov 06 13:46:24 LKCC-LENOVO systemd[1]: Started lepresenced.
Nov 06 13:46:24 LKCC-LENOVO lepresenced[22438]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed:
Nov 06 13:46:24 LKCC-LENOVO lepresenced[22438]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
Nov 06 13:48:25 LKCC-LENOVO lepresenced[22438]: [tid:2] main::bluetooth_dump_thread: hcidump was stopped.
Nov 06 13:48:25 LKCC-LENOVO lepresenced[22438]: [tid:1] main::bluetooth_scan_thread: hcitool was stopped.

Ich habe das Update auf 3 Geräten durchgeführt und es ist überall der selbe Fehler. Vor dem Update lief alles einwandfrei.

Hmm eigenartig. Auch die alten Versionen bringen diese Meldungen. Nachdem ich jetzt eine Weile gewartet habe, wird anscheinend auch die Anwesenheit wieder mit der aktuellsten Version erfasst. Ist immer etwas sehr labil der Bluetooth Mist unter Linux.

Hi!

Zitat von: mumpitzstuff am 06 November 2021, 16:37:39
Ist immer etwas sehr labil der Bluetooth Mist unter Linux.

Das kannst du laut sagen. Was ich in lepresenced an Codeblöcken habe, die das Interface automatisch resetten geht auf keine Kuhhaut. Dafür hat lepresenced immer gegen die vielen Batterieskripte gewonnen ;)

Falls der Fehler wieder auftritt mache gerne mal ein Log mit LOG_DEBUG. Den Level danach wieder runterstellen, damit die SD-Karte nicht so lange malträtiert wird.

Patrick

Ist diese Version lepresenced 22908 2020-10-04 15:23:07Z PatrickR $ schon mit der Battery_Level Ausgabe?
Das ist die aus dem contrib.

Danke und Grüße
mi.ke

Zitat von: mi.ke am 08 November 2021, 17:12:45
Ist diese Version

Code Auswählen Erweitern

lepresenced 22908 2020-10-04 15:23:07Z PatrickR $ schon mit der Battery_Level Ausgabe?

Ja, ist drin!

Patrick

Zitat von: PatrickR am 08 November 2021, 17:27:26
Ja, ist drin!

wie ruft man das den auf wenn alle 24 Stunden die Batterielevel abgefragt werden sollen?

so?
defmod <NAME> PRESENCE lan-bluetooth <MAC-Adresse> 127.0.0.1:5333 60 60 24

In der commandref hab ich nix gefunden

Zitat von: mi.ke am 08 November 2021, 17:50:04
wie ruft man das den auf wenn alle 24 Stunden die Batterielevel abgefragt werden sollen?

Das musst Du beim Aufruf von lepresenced tun:
--batteryinterval 24
Wenn Du das DEB-Paket nutzt, dann geht das gut in /etc/default/lepresenced

24 Stunden ist aber problematisch, da das u. U. die Batterie wiederholt zu einem Zeitpunkt abfragt, wo der G-Tag nicht zu Hause ist. Standardmäßig - und dafür musst Du nichts tun - wird alle 6 Stunden abgefragt.

Patrick

default ist 6 Stunden:
/usr/sbin$ grep DEFAULT_BATTERY_INTERVAL_H /usr/sbin/lepresenced
lepresenced:Readonly my $DEFAULT_BATTERY_INTERVAL_H =>  6;
Das Reading selber heisst dann aber "batteryPercent".

Zitat von: PatrickR am 08 November 2021, 18:12:46
Standardmäßig - und dafür musst Du nichts tun ...

Danke Ihr Beiden,

jetzt hab ich's auch verstanden.
Da bei meinen Minew Beacons keine neuen Readings kamen, dachte ich manuell nachhelfen zu müssen.

Hi!

Zitat von: mi.ke am 09 November 2021, 11:02:43
Da bei meinen Minew Beacons keine neuen Readings kamen, dachte ich manuell nachhelfen zu müssen.

Habe gerade mal den Code durchgesehen. Die neuen Readings müssen auf jeden Fall gesetzt werden, schlimmstenfalls mit unknown. Die Abfrage ist nicht G-Tag-spezifisch, daher sollte das prinzipiell auch bei anderen Tags funktionieren, auch wenn ich das nicht testen kann. Klappt es denn jetzt bei Dir?

/Edit: Sehe gerade, dass ich falsch lag und der Batteriewert doch nicht immer gesendet wird. Wenn es nicht klappt sollte ein Log mit LOG_DEBUG Aufschluss geben.

Patrick

Zitat von: PatrickR am 09 November 2021, 12:24:34
Wenn es nicht klappt sollte ein Log mit LOG_DEBUG Aufschluss geben.

Habs hinbekommen und den LOG_DEBUG gesetzt.

Nov  9 14:11:14 fhem-Keller lepresenced[577]: [tid:0] main: Sending update for mac address ac:23:3f:xx:xx:xx, ages: 1/1, max age: 60, rssi: -71, battery level: unknown (age: unknown) (ignored), result: present.

wie befürchtet:
battery level: unknown

Readings werden aber keine erzeugt

Zitat von: mi.ke am 09 November 2021, 14:30:56
Habs hinbekommen und den LOG_DEBUG gesetzt.

Wenn die Abfrage stattfindet müsstest Du eine Logmeldung wie die Folgende bekommen:

Battery level for mac %s is %s.

Interessant wäre mal, ob Deine Tags - ich habe das nur mit G-Tags getestet - die Battery-Level-Charakteristik (00002a19-0000-1000-8000-00805f9b34fb) unterstützen.

Zitat von: mi.ke am 09 November 2021, 14:30:56
Readings werden aber keine erzeugt

Ja, das passiert - wie ich nun festgestellt habe - bei unknown auch nicht.

Patrick

Zitat von: PatrickR am 09 November 2021, 15:59:12
Interessant wäre mal, ob Deine Tags - ich habe das nur mit G-Tags getestet - die Battery-Level-Charakteristik (00002a19-0000-1000-8000-00805f9b34fb) unterstützen.

wie/wo kann man das auslesen?

Zitat von: PatrickR am 09 November 2021, 15:59:12
Ja, das passiert - wie ich nun festgestellt habe - bei unknown auch nicht.

Bei "device_name" aber schon, der steht nämlich auf (unknown) inkl. Kammern

LG
mi.ke

Hi!

Zitat von: mi.ke am 09 November 2021, 17:02:37
wie/wo kann man das auslesen?

Bpsw. mit einer entsprechenden Bluetooth LE Software, z. B. LightBlue für iOS. Gibt es aber auch für andere Betriebssysteme. Alternativ könnte man auch den Hersteller fragen.
Spannender wäre aber erst einmal, die entsprechende Logzeile ("Battery level for mac %s is %s.") zu sehen. Wenn Du das erzwingen willst kannst Du über FHEM statusRequest schicken, dann werden 120s später alle erreichbaren Tags gefragt.

Zitat von: mi.ke am 09 November 2021, 17:02:37
Bei "device_name" aber schon, der steht nämlich auf (unknown) inkl. Kammern

Ja, der ist aber auch anders implementiert und wird immer geschickt.

Patrick

Zitat von: PatrickR am 09 November 2021, 17:39:20
Spannender wäre aber erst einmal, die entsprechende Logzeile ("Battery level for mac %s is %s.") zu sehen.

okay, ja, die Zeilen gibt es:

Nov  9 19:55:47 fhem-Keller lepresenced[577]: [tid:0] main::battery_task: Battery level for mac ac:23:3f:xx:xx:xx is unknown.

cheers
Mike

Hi!
Bitte ruhig etwas Kontext, z. B. die 20 Zeilen außenherum, vor allem die mit ,,gatttool".

Patrick

Zitat von: PatrickR am 10 November 2021, 07:35:37
Bitte ruhig etwas Kontext, z. B. die 20 Zeilen außenherum, vor allem die mit ,,gatttool".

Moin,

klar, gerne,
wenn das nicht reicht schick ich Dir gerne den gesamten Log per PM

cheers
Mike



Nov  9 13:55:38 fhem-Keller lepresenced[577]: [tid:0] main::get_battery_level: gatttool (mac: 04:52:c7:xx:xx:xx, address type: 'public'): 'connect error: Function not implemented (38)'
Nov  9 13:55:38 fhem-Keller kernel: [  132.376351] NET: Registered protocol family 38
Nov  9 13:55:38 fhem-Keller kernel: [  132.421444] cryptd: max_cpu_qlen set to 1000
Nov  9 13:55:38 fhem-Keller lepresenced[577]: [tid:0] main::battery_task: Battery level for mac 04:52:c7:xx:xx:xx is unknown.
Nov  9 13:55:40 fhem-Keller lepresenced[577]: [tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_scan_thread' to 'THREAD_COMMAND_RUN'.
Nov  9 13:55:40 fhem-Keller lepresenced[577]: [tid:0] main::set_thread_command: Setting thread command of thread 'bluetooth_dump_thread' to 'THREAD_COMMAND_RUN'.
Nov  9 13:55:40 fhem-Keller lepresenced[577]: [tid:0] main::battery_task: Battery task completed.
Nov  9 13:55:40 fhem-Keller lepresenced[577]: [tid:0] main::stats_task: Active clients: 3, known devices: 14 (min/max age: 123/124), received beacons (hcitool/hcidump/difference): 0/0/0
Nov  9 13:55:41 fhem-Keller lepresenced[577]: [tid:2] main::bluetooth_dump_thread: Received 'HCI sniffer - Bluetooth packet analyzer ver 5.50'.
Nov  9 13:55:41 fhem-Keller lepresenced[577]: [tid:2] main::bluetooth_dump_thread: Received 'device: hci0 snap_len: 1500 filter: 0xffffffff'.
Nov  9 13:55:41 fhem-Keller lepresenced[577]: [tid:1] main::bluetooth_scan_thread: Received 'LE Scan ...'.
Nov  9 13:56:09 fhem-Keller lepresenced[577]: [tid:0] main: Sending update for mac address ac:23:3f:xx:xx:yy, max age: 60, result: absence.
Nov  9 13:56:14 fhem-Keller lepresenced[577]: [tid:0] main: Sending update for mac address ac:23:3f:xx:xx:xx, ages: 0/1, max age: 60, rssi: -73, battery level: unknown (age: unknown) (ignored), result: present.
Nov  9 13:56:15 fhem-Keller lepresenced[577]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...
Nov  9 13:56:15 fhem-Keller lepresenced[577]: [tid:2] main::set_thread_command: Setting thread command of thread 'bluetooth_scan_thread' to 'THREAD_COMMAND_RESTART'.
Nov  9 13:56:15 fhem-Keller lepresenced[577]: [tid:2] main::set_thread_command: Setting thread command of thread 'bluetooth_dump_thread' to 'THREAD_COMMAND_RESTART'.
Nov  9 13:56:15 fhem-Keller lepresenced[577]: [tid:2] main::bluetooth_dump_thread: restarting hcidump...
Nov  9 13:56:15 fhem-Keller lepresenced[577]: [tid:2] main::set_thread_command: Setting thread command of thread 'bluetooth_dump_thread' to 'THREAD_COMMAND_RUN'.
Nov  9 13:56:15 fhem-Keller lepresenced[577]: [tid:1] main::bluetooth_scan_thread: restarting hcitool...
Nov  9 13:56:15 fhem-Keller lepresenced[577]: [tid:1] main::set_thread_command: Setting thread command of thread 'bluetooth_scan_thread' to 'THREAD_COMMAND_RUN'.
Nov  9 13:56:16 fhem-Keller lepresenced[577]: [tid:2] main::bluetooth_dump_thread: Received 'HCI sniffer - Bluetooth packet analyzer ver 5.50'.
Nov  9 13:56:16 fhem-Keller lepresenced[577]: [tid:2] main::bluetooth_dump_thread: Received 'device: hci0 snap_len: 1500 filter: 0xffffffff'.
Nov  9 13:56:16 fhem-Keller lepresenced[577]: [tid:1] main::bluetooth_scan_thread: Received 'LE Scan ...'.
Nov  9 13:56:41 fhem-Keller lepresenced[577]: [tid:0] main::stats_task: Active clients: 3, known devices: 16 (min/max age: 0/19), received beacons (hcitool/hcidump/difference): 659/659/0
Nov  9 13:57:09 fhem-Keller lepresenced[577]: [tid:0] main: Sending update for mac address ac:23:3f:xx:xx:yy, max age: 60, result: absence.
Nov  9 13:57:14 fhem-Keller lepresenced[577]: [tid:0] main: Sending update for mac address ac:23:3f:xx:xx:xx, ages: 1/1, max age: 60, rssi: -74, battery level: unknown (age: unknown) (ignored), result: present.
Nov  9 13:57:15 fhem-Keller lepresenced[577]: [tid:2] main::bluetooth_dump_thread: Received '< HCI Command: Remote Name Request (0x01|0x0019) plen 10', telling hcidump and hcitool to restart...



Hi!

Zitat von: mi.ke am 10 November 2021, 08:50:56

Code Auswählen Erweitern


Nov  9 13:55:38 fhem-Keller lepresenced[577]: [tid:0] main::get_battery_level: gatttool (mac: 04:52:c7:xx:xx:xx, address type: 'public'): 'connect error: Function not implemented (38)'


Ich bin kein Bluetooth-Experte aber ich würde das erst einmal so deuten, dass keine Verbindung möglich ist. Mir fiele dazu nur ein, den Hersteller anzuschreiben und zu fragen, ob generell eine Abfrage des Batteriewerts möglich ist und ob er zufällig exemplarisch einen gatttool-Aufruf spendieren kann. Teilweise kann man die Tags des Herstellers wohl auch konfigurieren, ggf. geht da auch etwas.

Patrick

Falls du Android hast, kannst du dir den BLE Scanner von Bluepixel laden. Dort kannst du genau sehen, welche Services dein Tag unterstützt (auf den grünen Connect Button klicken).

Hallo,

es wäre toll, wenn mal jemand den lepresence.d auf einen aktuellen Stand bringt.

"hcitool lescan" wird ja mittlerweile nicht mehr unterstützt (deprecated). Getestet mit debian 12.

neu wird ja "bluetoothctl scan le" verwendet.

mfg Dirk

Zitat von: sysmek am 14 März 2024, 12:01:06es wäre toll, wenn mal jemand den lepresence.d auf einen aktuellen Stand bringt.

"hcitool lescan" wird ja mittlerweile nicht mehr unterstützt (deprecated). Getestet mit debian 12.

neu wird ja "bluetoothctl scan le" verwendet.

Hi!

Nachfolger ist ble2mqttd. Ist aber kein Drop-In-Ersatz sondern verwendet mqtt, was eine Reihe von Vorteilen hat.

https://forum.fhem.de/index.php?topic=127173.0

Patrick

ZitatNachfolger ist ble2mqttd. Ist aber kein Drop-In-Ersatz sondern verwendet mqtt, was eine Reihe von Vorteilen hat.

Das kann man aber nicht mit PRESENCE verwenden - oder?

Hi!

Zitat von: JWRu am 14 März 2024, 12:59:06Das kann man aber nicht mit PRESENCE verwenden - oder?

Ich benutze es ohne Presence, was auch einer der Vorteile ist. Wenn Du ein Presence-Device willst oder z. B. für ROOMMATE benötigst kannst Du sicherlich ein PRESENCE-Device mit den Modus function oder event anlegen.

Patrick