[gelöst] Bluetooth und Bluetooth Low Energy parallel betreiben?

Begonnen von Christian80, 02 April 2021, 09:46:03

Vorheriges Thema - Nächstes Thema

Christian80

Hallo zusammen,

aktuell benutze ich für meine Anwesenheitserkennung das Modul PRESENCE mit local-bluetooth um mein Smartphone abzufragen.
FHEM läuft dabei in einer VM auf meinem Intel NUC.
Das klappt seit Jahren problemlos und sehr zuverlässig.

Nun möchte ich allerdings für einen anderen Anwendungsfall zusätzlich noch ein Gigaset G-tag benutzen, welcher aber über Bluetooth Low Energy (BLE) läuft.

Ich hatte testweise lepresenced installiert. Daraufhin wurde der G-tag erkannt, aber mein Smartphone nicht mehr. Gibt es eine Möglichkeit beides parallel zu betreiben?

Mir fällt nur ein, eine 2. Fhem Instanz in einer VM bzw. LXC zu installieren. Würde das funktionieren? Gibt es eine einfachere Lösung?

Danke für eure Tips und schöne Ostern
Christian

Otto123

Hallo Christian,

das ist doch keine Frage eine zweiten FHEM Instanz, sondern eher das zwei Prozesse nicht gleichzeitig einen Bluetooth Chip benutzen können?
Entweder kann lepresenced auch normales Bluetooth?
Oder kann man presenced und lepresenced abwechselnd starten?
Oder beide Scripts mit zwei getrennten Bluetooth Schnittstellen betreiben.

Letzteres wird wohl die richtige Lösung sein - ich hab es aber auch noch nicht gelöst, bin aber daran interessiert :)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Jamo

#2
Lepresenced beansprucht den BT auf der hci0 Schnittstelle exclusiv fuer sich. Deswegen kommt Lepresenced sich mit dem Presenced in die quere, und presenced funktioniert dann nicht mehr, oder nur noch sporadisch. Abhilfe schafft nur ein zweiter externer BT dongle, für die Anwesenheitserkennung mit presenced dann auf hci1. Die Wahl welcher daemon dann hci1 oder hci0 benutzt, kann man direkt im Daemon ändern, oder auch über das attribut bluetoothHciDevice im presenced modul.
Ist hier im Forum oft diskutiert.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Christian80

Danke für die Antworten.

Ich habe hier noch einen BT Dongle rumliegen und werde es in diese Richtung mal testen.

Otto123

Was mir jetzt für diese Aufgabenstellung (BLE an FHEM) auch noch einfällt: Einen ESP32 mit OpenMQTTGateway drauf. Das Teil über einen MQTT2_Server an FHEM angebunden lief in wenigen Minuten. Also falls man schon mit MQTT2 unterwegs ist :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Christian80

Meine funktionierende Lösung habe ich nun mit einem zusätzlichen BT Dongle realisiert.
Auf dem BT-Onboard läuft presenced, auf dem BT Dongle läuft lepresenced.

Beide Geräte (Smartphone und G-tag) sind jeweils mit lan-bluetooth und den entsprechenden Ports (5111 und 5333) definiert.

Danke für eure Hilfe.

Schöne Ostern
Christian

Otto123

#6
Moin,

ich weiß Christian hat sein Problem gelöst. Ich habe mir das mal etwas näher angeschaut und sinniere hier mal noch ein bisschen meine Erkenntnisse.

  • Beim PRESENCE Modul ist das hci Gerät über das bluetoothHciDevice Attribute einstellbar.
  • Beim lepresenced Script kann das hci Device über Parameter eingestellt werden. (sudo systemctl edit --full lepresenced)
  • Beim presenced Script kann das hci Device nicht gewählt werden.
Eine Beschreibung für beide Scripte findet man auch in der Hilfe zum PRESENCE Modul.

Die Installation ist für den Laien wahrscheinlich einfacher über das deb Paket - allerdings finde ich die Beschreibung im Wiki nicht so toll.

So werden die Voraussetzungen geschaffen, das derzeit aktuelle Paket heruntergeladen und der Dienst gleich mit installiert
sudo apt update
sudo apt install libreadonly-perl libnet-server-perl bluez bluez-hcidump

wget http://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/lepresenced-0.93-1.deb
sudo dpkg -i lepresenced-0.93-1.deb


Interessanterweise verwenden beide Scripts das hcitool um die Bluetooth Geräte zu ermitteln. Komisch das man es nicht in einem Script und mit einem Device hinbekommen soll.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Jamo

Hallo Otto,
Das hat nichts mit dem Script zu tun. Soweit ich verstanden habe, verlangt der Lepresenced daemon exclusiven zugriff auf ein physikalische BT device (auf eine Schnittstelle). Deswegen der 2-te BT Dongle
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Otto123

naja hcitool name MAC-Adresse macht quasi ein ping. hcitool lescan macht eine Art Dauer-Sniffer auf.
Da versteh ich die Technik dahinter noch zu wenig - offenbar liegt es an der Art wie man die Daten einfangen kann.
Das OpenMQTTGateway mit ESP32 kann ja auch nur LE Bluetooth - obwohl das Gerät ja beides kann.
Mein Smartphone redet auch mit meiner Freisprecheinrichtung und mit meiner Uhr ;D

Man müsste ja den LE-BT Sniffer bloß immer mal für ein BT Ping unterbrechen?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Jamo

Ja, dann muesste man aber evtl den LePresenced und den Presenced in ein Modul giesssen, damit der eine den anderen unterbrechen kann, Du kannst ja mal den Modul Autor anschreiben :-) 
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Otto123

Ich werde mal ein bisschen experimentieren.
Auf alle Fälle sollte man presenced um die Möglichkeit erweitern das hci Device anzugeben. Das sollte einfach machbar sein.
Ich kümmere mich :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

curt

Ich lese ganz gespannt mit: Ich habe mehrere RPI, die Kameras steuern und ansonsten unterbeschäftigt sind. Bt und BLE ist mir theoretisch bekannt, wurde hier aber noch nie umgesetzt. Schon von daher finde ich spannend, dass das vielleicht nur ein Modul wird ...

Zitat von: Otto123 am 03 April 2021, 12:56:20
naja hcitool name MAC-Adresse macht quasi ein ping

Verstehe ich recht, dass ein Ping auf die MAC-Adresse eines Handys geht?

Dann der Hinweis (sofern nicht bekannt), dass die Hersteller dazu übergehen, nach gewisser Zeit die MAC neu zu vergeben. Damit dürfte sich Ping über kurz oder lang erledigt haben.
RPI 4 - Jeelink HomeMatic Z-Wave

Otto123

Zitat von: curt am 07 April 2021, 02:54:05
Verstehe ich recht, dass ein Ping auf die MAC-Adresse eines Handys geht?
Moin,

DIE MAC Adresse eines Handys ist relativ, jeder Netzwerkechip sowohl Wlan als auch BT haben mindestens eine oder mehrere MAC Adressen. Hier ist die BT MAC gemeint.
Der Paranoia Modus ist mir bekannt, ist aber mW derzeit nur bei Wlan aktiv und man kann ihn in bekannten Netzwerken (also zu Hause) deaktivieren :).

Der BT Chip ist normalerweise (wenn Benutzer und Hersteller mitspielen) nicht im "hier bin ich" Modus, deswegen macht hcitool eine Abfrage auf eine bekannte Adresse und das Gerät antwortet. Ein Scan führt normalerweise ins Leere.
Offenbar anders ist es im BLE Modus, dort wird mit einem Dauerscan ermittelt wer in der Nähe ist. Den "BLE Mechanismus" habe ich noch nicht verstanden, weil das eigentlich wieder ein Sicherheitsrückschritt bedeutet.

Insofern müsste der "Presence" Betrieb aus meiner Sicht und Kenntnis mit einem Chip so aussehen: hcitool lescan - nach xx sec stop - hcitool name MAC - hcitool lescan usw.
Ob das machbar ist weiß ich derzeit nicht.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

MadMax-FHEM

Bzgl. Handyerkennung mittels BT teste ich grad das hier: https://forum.fhem.de/index.php/topic,118917.msg1133609.html#msg1133609

Allerdings mit einem BT-Stick.
Das BT im PI war zu schwach für "Handy in der Wohnung"...
...mal sehen.
Stick kam ja erst heute...

Parallel habe ich noch ein gTag mit "norm." lepresenced...
Aber da hatte ich Probleme mit einem PI (Buster Update) auch mit ext. BT-Dongle...

Aktuell laufen 3 Dinge parallel:

- eigentl. "Erfassungs-PI" mit legacymode (lief bis zu irgendeinem Buster update prima/ohne legacymode geht "gar nichts"). Erfassung gTag.

- mein "BT-Extender" (PIZeroW) mit "älterem Buster". Eigentlich für meine BLE-FlowerSense mit PI-BT (läuft seit Jahren prima). Zusätzlicher BT-Stick nun für lepresenced (ohne legacymode) zur gTag Erfassung.

- neu (seit heute mit ext. BT-Dongle) eben Handy-Erfassung mit npresenced... Mal sehen...

fhem-Seitig dann ganz "norm." lan-bt...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)