Anwesenheitserkennung Bluetooth PebbleBee

[PatrickR]

--debug gibt alle regulären Log Level auf STDOUT aus und etwas mehr, konkret: Eine regelmäßige Übersicht der bekannten Geräte. Ist es das, was Du möchtest oder weniger?


Gesendet von iPhone mit Tapatalk Pro

[FunkOdyssey]

Das war das, was ich bereits wusste.
Wird jedoch die Log-Stufe LOG_INFO, LOG_DEBUG, LOG_WARNING, etc. dabei berücksichtigt?
Erhalte ich bei --debug und LOG_WARNING auch wirklich nur die Warnungen im STDOUT?
Ich erkenne irgendwie keinen Unterschied.

Wenn nun regelmäßig eine Übersicht der bekannten Geräte hinzukommt, dann ist das okay. Ich habe nur Angst, dass beim --debug mir die Docker-Console zugemüllt wird.

[PatrickR]

Wie gesagt, —loglevel hat keinen Einfluss auf STDOUT und um ehrlich zu sein war Deine Anwendung auch nicht der Anlass für den Parameter. Werde es mir aber mal ansehen, wenn ich etwas Zeit finde.


Von unterwegs gesendet.

[FunkOdyssey]

Alles gut. Ich bin froh, dass es diesen Parameter überhaupt gibt, so dass ich ein wenig Ouput sehe. Ich finde es schon sehr geil, dass lepresenced überhaupt in einem Docker-Container läuft. 😁

[PatrickR]

Oooch. lepresenced ist doch relativ genügsam, jedenfalls verglichen mit den Java-Ungetümen, die man üblicherweise - zu Recht - in Container einsperrt


Von unterwegs gesendet.

[FunkOdyssey]

Das stimmt. Homebridge und HA-Bridge belegen mehrere hundert Megabyte und erfüllen einen viel geringeren Zweck als lepresenced. Wenigstens bei mir.

[PatrickR]

Mahlzeit!

Das stimmt. Homebridge und HA-Bridge belegen mehrere hundert Megabyte und erfüllen einen viel geringeren Zweck als lepresenced. Wenigstens bei mir.

Da ich auch gerade mit Docker experimentiere, habe ich lepresenced mal stdout-fähig gemacht. Konnte es nur kurz testen, daher bitte als Beta ansehen

Code Auswählen Erweitern


usage:
lepresenced --bluetoothdevice <bluetooth device> --listenaddress <listen address> --listenport <listen port> --loglevel <log level> --logtarget <log target> --daemon
lepresenced -b <bluetooth device> -a <listen address> -p <listen port> -l <log level> -t <log target> -d
valid log levels:
LOG_CRIT, LOG_ERR, LOG_WARNING, LOG_NOTICE, LOG_INFO, LOG_DEBUG. Default: LOG_INFO
valid log targets:
syslog, stdout. Default: syslog
optional arguments:
--debug - print extensive debug output to stdout (mutually exclusive with --daemon).
--legacymode - legacy mode without rssi detection. Use if you do not have hcidump installed.
--rssithreshold - rssi deviation to trigger an update. Minimum value: 5, default: 10
examples:
lepresenced --bluetoothdevice hci0 --listenaddress 127.0.0.1 --listenport 5333 --daemon
lepresenced --loglevel LOG_DEBUG --daemon


Neu ist --logtarget, das Du auf stdout stellen kannst. --loglevel wird berücksichtigt.

Grüße
Patrick

[FunkOdyssey]

Sehr geil. Vielen Dank.
Ich probiere das die Tage aus.

Am Rande mein Dockerfile. Ein schmales Baseimage oder Alpine hatte nicht funktioniert, da mir die Bluetooth-Pakete fehlten bzw. nicht verfügbar waren.

Code Auswählen Erweitern


FROM debian:stretch

ENV DEBIAN_FRONTEND noninteractive
ENV TERM xterm

RUN apt-get update && apt-get -y install \
    perl \
    libnet-server-perl \
    libusb-1.0-0-dev \
    bluetooth \
    bluez \
    blueman \
    tzdata \
    bluez-hcidump \
    wget && \
    apt-get clean && cd / && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

# Zeitzone einstellen
RUN echo "Europe/Berlin" > /etc/timezone && dpkg-reconfigure tzdata

WORKDIR "/opt"

RUN wget https://github.com/mhop/fhem-mirror/raw/master/fhem/contrib/PRESENCE/lepresenced && \
    chmod +x lepresenced && \
    chgrp -cR dialout lepresenced

EXPOSE 5333

COPY entrypoint.sh /entrypoint.sh
CMD bash /entrypoint.sh


Und ich muss den Container im Host-Modus laufen lassen, da die BT-Geräte sonst nicht weitergereicht wurden.

[FunkOdyssey]

@Patrick: Test deiner Datei:

Ich starte das Skript wie folgt ...

Code Auswählen Erweitern

/usr/bin/perl /opt/lepresenced --device "hci0" --listenaddress "0.0.0.0" --listenport 5333 --loglevel "LOG_WARNING" --logtarget stdout

... und erhalte folgende Fehlermeldungen:

Code Auswählen Erweitern

[tid:1] main::bluetooth_scan_thread: Received unknown output: 'Invalid device: No such device'!
[tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
[tid:2] main::bluetooth_dump_thread: hcidump exited, retrying...
[tid:1] main::bluetooth_scan_thread: Received unknown output: 'Invalid device: No such device'!
[tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
[tid:2] main::bluetooth_dump_thread: hcidump exited, retrying...
[tid:1] main::bluetooth_scan_thread: Received unknown output: 'Invalid device: No such device'!
[tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...
[tid:2] main::bluetooth_dump_thread: hcidump exited, retrying...
[tid:1] main::bluetooth_scan_thread: Received unknown output: 'Invalid device: No such device'!
[tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...

Code Auswählen Erweitern

Use of uninitialized value $beacons_hcidump in subtraction (-) at /opt/lepresenced line 357.
Use of uninitialized value $beacons_hcitool in subtraction (-) at /opt/lepresenced line 357.
Use of uninitialized value $args[4] in sprintf at /opt/lepresenced line 88.
Use of uninitialized value $args[5] in sprintf at /opt/lepresenced line 88.

[PatrickR]

Hi! Die Fehlermeldungen im 2. Block sehe ich mir an.

Warum hci0 nicht existiert müsstest Du aber rausfinden...

Patrick


Von unterwegs gesendet.

[FunkOdyssey]

Boah, bin ich blöd. Sorry. Der Dongle steckte nicht im Testsystem.
Wie war das ,,Wald vor lauter Bäumen"? Quellcode gecheckt, aber Dongle nicht.

[PatrickR]

Mahlzeit!

Boah, bin ich blöd. Sorry. Der Dongle steckte nicht im Testsystem.
Wie war das ,,Wald vor lauter Bäumen"? Quellcode gecheckt, aber Dongle nicht.

Unabhängig davon war da noch ein Bug drin. 0.841 im Anhang zum Testen.

Patrick

[Taasba]

Hallo in die Runde der An- und Abwesenheitsfreunde,

ich möchte mal zur Abwechslung keine Frage sondern nur einen kurzen Erfahrungsbericht und ein Lob aussprechen:

- vor gut 1,5 Jahren habe ich mir 6 G-Tags gekauf und entsprechend diesem Thread in fhem eingebaut (lepresence derzeit läuft bei mir V 0.83) läuft seither ohne Probleme
- RasPi 3 internes BT im Keller - G-Tags liegen in der Küche, Abstand inkl. mit Kellerdecke ca. 4m
- Batterielebensdauer ca. 1 Jahr + 1-3 Monate
- Batteriecheck gem. Thread bei 16% = ca. 2,68V war Schluss ( habe ich bewusst ausporbiert, bis nichts mehr ging ) - Meine Empfehlung bei ca. 25% austauschen
- Batteriecheck läuft bei mir per Crontab in der Nacht - Manchmal werden zwar keine Werte übermittelt, stört mich aber nicht. I.d.R. wurden die Werte spätestens nach 3 Tagen wieder gefunden und übermittelt. (hängt evtl. auch mit der Batterieleistung zusammen !?)

Code Auswählen Erweitern

define ZE.BatterieGTag readingsGroup .*:[Bb]atterie.*\
.*:[Bb]atterieLevel\
attr ZE.BatterieGTag notime 1
attr ZE.BatterieGTag alias Batteriestatus_GTAG
attr ZE.BatterieGTag room Zentral
attr ZE.BatterieGTag valueFormat {return "25" if( $VALUE < 25 );; return "50" if( $VALUE < 40 );; return "75" if( $VALUE < 85 );; return "100"}
attr ZE.BatterieGTag valueIcon {\
'Batterie01.25' => 'measure_battery_25@red','Batterie01.50' => 'measure_battery_50@orange','Batterie01.75' => 'measure_battery_75@green','Batterie01.100' => 'measure_battery_100@green',\
'Batterie02.25' => 'measure_battery_25@red','Batterie02.50' => 'measure_battery_50@orange','Batterie02.75' => 'measure_battery_75@green','Batterie02.100' => 'measure_battery_100@green',\
'Batterie03.25' => 'measure_battery_25@red','Batterie03.50' => 'measure_battery_50@orange','Batterie03.75' => 'measure_battery_75@green','Batterie03.100' => 'measure_battery_100@green',\
'Batterie04.25' => 'measure_battery_25@red','Batterie04.50' => 'measure_battery_50@orange','Batterie04.75' => 'measure_battery_75@green','Batterie04.100' => 'measure_battery_100@green',\
'Batterie05.25' => 'measure_battery_25@red','Batterie05.50' => 'measure_battery_50@orange','Batterie05.75' => 'measure_battery_75@green','Batterie05.100' => 'measure_battery_100@green',\
'Batterie09.25' => 'measure_battery_25@red','Batterie09.50' => 'measure_battery_50@orange','Batterie09.75' => 'measure_battery_75@green','Batterie09.100' => 'measure_battery_100@green',\
}

Abfrage läuft mittel DOIF.

Folgende Funktionen werden mit Abwesenheit gesteuert:
- Heizung
- Thermostate
- Briefkasten (Post ist da )
- Alarmanlage
- Begrüßung der Kinder mit von den Kindern eigens erstelltem MP3

DANKE an die Entwickler und Fragesteller und einen guten automatisierten Start ins neue Jahr.

LG Taasba

[micky0867]

Der ESP32 ist erstmal außen vor. Da hat noch keiner was getestet oder eine Ahnung, ob es überhaupt geht.
Ich habe auch keinen Hinweis gefunden, dass ESPEasy bereits auf den ESP32 portiert wurde.

Da mich das Thema nicht losgelassen hat, habe ich mich in den letzten Wochen verstärkt mit dem ESP32s (WROOM-32) auseinander gesetzt.
ESPEasy könnte irgendwann mal gehen, aber im Moment gibt es nur eine Beta-Version.

Deshalb habe ich in eine andere Richtung gearbeitet.
Nach einigen Versuchen mit Scannen und auch Batteriestatus lesen habe ich mich zunächst für eine Version entschieden, die das Verhalten von lepresenced simuliert.
Damit kann ein ESP32s in's Wlan gehangen werden und dann per FHEM  direkt oder über den collectord benutzt werden, also genau so, als hätte man es mit einem lepresenced Prozess zu tun.

Die Sourcen sind hier:
https://github.com/micky0867/BLEScanner

Micky

Die HW habe ich übrigens von hier:
https://www.ebay.de/itm/272589218228

[PatrickR]

Hui nett.

Andreas Spiess hatte auf seinem Youtubechannel auch über den ESP32 BLE gescannt und dort fesgestellt, dass WLAN und BLE nicht gleichzeitig funktionieren.
Das ist aber für die "stehende" Verbindung mit dem Presence-Protokoll m. E. nötig. Wie hast Du das gelöst?

Patrick


Von unterwegs gesendet.