OpenMQTTGateway support thread - im Speziellen: BT/BTLE

[DeeSPe]

Hab's mal mit einem Eintrag in getList probiert. Leider ohne Erfolg:

Code Auswählen Erweitern

battery:noArg battery home/OpenMQTTGateway_ESP32_BLE_C/commands/MQTTtoBT/config {"ble_read_address":"XX:XX:XX:XX:XX:XX","ble_read_service":"00002a19-0000-1000-8000-00805f9b34fb","ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb","value_type":"INT","mac_type":0,"ttl":2}
Es kommt zu einem Timeout.
Ich habe bei ble_read_service und ble_read_service beides Mal die selbe UID angegeben. Das ist sicherlich nicht richtig, aber ich weiß es nicht besser.

Gruß
Dan

[Beta-User]

Hmm, an sich sieht mir das (mit meinen begrenzten Kenntnissen) plausibel aus.

Der timeout war zu erwarten, weil die Antwort "zu lange" auf sich warten läßt (das ist im M2D-Modul hart vercoded, wenn via FHEMWEB aufgerufen), den würde ich daher nicht als Fehler ansehen.

Kann durchaus sein, dass das "irgendwann" erfolgreich ausgeführt wird (oder eben kein Ergebnis liefert).

Notfalls müßte jemand eben eine Frage auf OMG-github stellen, wie man das "richtig" macht. Nachdem ich kurz mal die (meist geschlossenen) issues auf github durchgescannt habe, drängt sich die Vermutung auf, dass das Auslesen der battery-Werte per default nicht gemacht wird, weil es eben (Batterie-) Kapazität kostet wegen der zusätzlichen Daten.

[rudolfkoenig]

Kann durchaus sein, dass das "irgendwann" erfolgreich ausgeführt wird (oder eben kein Ergebnis liefert).

Wenn es irgendwannmal ausgefuehrt wurde, dann sollte das Reading aktualisiert sein.

[kroman]

Hallo zusammen,

genau damit spiele ich auch gerade herum.
2xESP32 mit OpenMQTTGateway v0.9.10 und G-Tags.
Anwesenheitserkennung läuft seit ca. 2 Wochen stabil und das Batteriethema ist auch bei mir noch ein offenes.

Ich denke auch, dass das Dan keine Antwort bekommt nichts mit FHEM zu tun hat.

Ich habe im Netzwerk getraced und auch auf der seriellen console am ESP geschaut, folgende Erkenntnisse gibt es daraus:

Wenn ich ihm das schicke, ignoriert er die Nachricht, keine Reaktion:

Code Auswählen Erweitern


set mqtt2server publish home/OMG1/commands/MQTTtoBT/config {"ble_read_address":"7C:2F:80:C3:90:FF","ble_read_service":"00002a19-0000-1000-8000-00805f9b34fb"}


Das ignoriert er auch:

Code Auswählen Erweitern


set mqtt2server publish home/OMG1/commands/MQTTtoBT/config {"ble_read_address":"7C:2F:80:C3:90:FF","ble_read_service":"00002a19-0000-1000-8000-00805f9b34fb","immediate": true}


Und das genauso:

Code Auswählen Erweitern


set mqtt2server publish home/OMG1/commands/MQTTtoBT/config {"ble_read_address":"7C:2F:80:C3:90:FF","ble_read_service":"00002a19-0000-1000-8000-00805f9b34fb","ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb"}


Damit gibt es nun aber eine Anwort:

Code Auswählen Erweitern


set mqtt2server publish home/OMG1/commands/MQTTtoBT/config {"ble_read_address":"7C:2F:80:C3:90:FF","ble_read_service":"00002a19-0000-1000-8000-00805f9b34fb","ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb","immediate": true}


Code Auswählen Erweitern


N: [ MQTT->OMG ]: {"ble_read_address":"7C:2F:80:C3:90:FF","ble_read_service":"00002a19-0000-1000-8000-00805f9b34fb","ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb","immediate":true}
N: Found 3 devices, scan number 70 end
N: BLE Connect begin
N: Failed to find service UUID: 00002a19-0000-1000-8000-00805f9b34fb
N: BLE Connect end
N: Send on /BTtoMQTT/7C2F80C390FF msg {"id":"7C:2F:80:C3:90:FF","service":"00002a19-0000-1000-8000-00805f9b34fb","characteristic":"00002a19-0000-1000-8000-00805f9b34fb","success":false}


Danach ist er aber beleidigt und hört auf zu scannen, schickt nur noch MQTTtoSYS topics, also Infos zum OMG selber.

Das ganze mit "mac_type": 0 ergibt gleiches Ergebnis, 0 soll ja auch der default Wert ist wie hier steht, außerdem sehe ich das in den scan-Antworten.

https://docs.openmqttgateway.com/use/ble.html#read-write-ble-characteristics-over-mqtt-esp32-only

Code Auswählen Erweitern


set mqtt2server publish home/OMG1/commands/MQTTtoBT/config {"ble_read_address":"7C:2F:80:C3:90:FF","ble_read_service":"00002a19-0000-1000-8000-00805f9b34fb","ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb","immediate": true,"mac_type": 0}


Jetzt noch mit "value_type":"INT", was bei einem Wert von 0-100 ja stimmen sollte (default = STRING), jedoch auch mit gleichem Ergebnis:

Code Auswählen Erweitern


set mqtt2server publish home/OMG1/commands/MQTTtoBT/config {"ble_rad_address":"7C:2F:80:C3:90:FF","ble_read_service":"00002a19-0000-1000-8000-00805f9b34fb","ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb","immediate": true,"mac_type": 0, "value_type":"INT"}


Machmal passiert auch das:

Code Auswählen Erweitern


N: Send on /BTtoMQTT/7C2F80C390FF msg {"id":"7C:2F:80:C3:90:FF","mac_type":0,"manufacturerdata":"80010215123480c390ffbbc5","rssi":-83}
N: [ MQTT->OMG ]: {"ble_read_address":"7C:2F:80:C3:90:FF","ble_read_service":"00002a19-0000-1000-8000-00805f9b34fb","ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb","immediate":true,"mac_type":0,"value_type":"INT"}
N: Found 0 devices, scan number 10 end
N: BLE Connect begin
lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
E NimBLEClient: "Connection failed; status=574 "
E: Connect to: 7c:2f:80:c3:90:ff failed
N: BLE Connect end
N: Send on /BTtoMQTT/7C2F80C390FF msg {"id":"7C:2F:80:C3:90:FF","service":"00002a19-0000-1000-8000-00805f9b34fb","characteristic":"00002a19-0000-1000-8000-00805f9b34fb","success":false}


Dazu gibt es ein paar issues auf github.

Das ganze war mit folgenden Parametern in der *_env.ini:

Code Auswählen Erweitern


;;;BT
  '-DAttemptBLECOnnect=false'     ; do we by default attempt a BLE connection to sensors with ESP32
  '-DScanBeforeConnect=1'         ; define number of scans before connecting to BLE devices (ESP32 only, minimum 1)
  '-DActiveBLEScan=false'         ; Set active scanning, this will get more data from the advertiser

  ; OpenMQTTGateway v0.9.6: the gateway can now be configured for the continuous scan (TimeBtwRead:0, Scan_duration:1000)
  '-DTimeBtwRead=0'             ; define default time between 2 scan, default=55555
  '-DScan_duration=5000'          ; define the time for a scan, default=10000
  '-DBLEScanInterval=5000'        ; How often the scan occurs / switches channels, in milliseconds, default=52
  '-DBLEScanWindow=5000'          ; How long to scan during the interval, in milliseconds, default=30


Mit diesen Parameter lief mein Anwesenheitserkennung wie gesagt stabil und zeitnah, ich wollte so rasch wie möglich feststellen können wenn jemand nach Hause kommt.

Code Auswählen Erweitern


2022-03-03_11:40:16 MQTT2_OMG_BT_scanner 7C2F80C390FF_id: 7C:2F:80:C3:90:FF
2022-03-03_11:40:18 MQTT2_OMG_BT_scanner 7C2F80C390FF_id: 7C:2F:80:C3:90:FF
2022-03-03_11:40:18 MQTT2_OMG_BT_scanner 7C2F80C390FF_id: 7C:2F:80:C3:90:FF
2022-03-03_11:40:19 MQTT2_OMG_BT_scanner 7C2F80C390FF_id: 7C:2F:80:C3:90:FF
2022-03-03_11:40:19 MQTT2_OMG_BT_scanner 7C2F80C390FF_id: 7C:2F:80:C3:90:FF
2022-03-03_11:40:21 MQTT2_OMG_BT_scanner 7C2F80C390FF_id: 7C:2F:80:C3:90:FF
2022-03-03_11:40:21 MQTT2_OMG_BT_scanner 7C2F80C390FF_id: 7C:2F:80:C3:90:FF
2022-03-03_11:40:22 MQTT2_OMG_BT_scanner 7C2F80C390FF_id: 7C:2F:80:C3:90:FF


Der empirische Test wie lange dabei die Batterie hält läuft noch.

Es gilt wohl an den Parameter vor dem kompilieren zu drehen. Ob damit auch "Failed to find service UUID: 00002a19-0000-1000-8000-00805f9b34fb" behoben werden kann, weiß ich nicht.
Dass in meinem Fall "immediate": true nötig ist, liegt denke ich an DAttemptBLECOnnect=false'.
Ich werde ein anderes Mal weiterdoktern.

Gruß,
kroman

[MadMax-FHEM]

Betr. die "nutzlosen" Einstellungen: Bin mir nicht sicher, ob nicht "irgendwann" ein Batteriewert (oder weitere Info) kommt, also ist es vorsichtshalber drin. "impedance" war in deinem raw-list drin.

Würde das also eher drin lassen, ist kaum mehr Last in der Verarbeitung...

Stimmt: impedance kommt sogar von der Waage

Ist wohl das hier: https://de.wikipedia.org/wiki/Bioelektrische_Impedanzanalyse
(allerdings hab ich noch nicht raus was der Wert denn nun bedeutet   )

Danke noch mal, Joachim

[DeeSPe]

Soweit ich verstanden habe können die Batteriewerte nur bei einem (kurzzeitigem) Connect übermittelt werden.
Ich benutze die Version vom Gateway die dauerhaft scannt. Evtl. geht das "connecten" mit dieser Version gar nicht?
Bekomme es jedenfalls nicht hin ein "success" zurück zu bekommen.
Habe bei einer Suche noch eine UID für den Batterie Service gefunden.
So sieht das jetzt bei mir aus, aber leider nicht funktionell:

Code Auswählen Erweitern

set .... publish home/OpenMQTTGateway_ESP32_BLE_C/commands/MQTTtoBT/config {"ble_read_address":"XX:XX:XX:XX:XX:XX","ble_read_service":"0000180f-0000-1000-8000-00805f9b34fb","ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb","value_type":"INT","immediate":true,"mac_type":0,"ttl":2}


Gruß
DAn

[Beta-User]

Nach den sehr guten Ausführungen von @kroman habe ich Zweifel, ob das im Moment überhaupt geht mit der Batterie usw.. Aber der "richtige" Datenpunkt wäre schon mal wichtig...

Prinzipiell _meine_ ich das mit den "config"-Befehlen so zu verstehen, dass das beim nächsten "connect" (der auch im Rahmen eines scans sein kann) gequeued werden sollte und dann eben "abgefeuert" wird. (Danke auch an Rudi für den Hinweis, dass (erst) dann ggf. das Reading erzeugt/aktualisiert wird. Ergänzend: das sieht man dann auch nur (erstmalig), wenn man den Detail-View des Gerätes refresht).

Grundsätzlich ist es vielleicht besser, "unnützes" erst mal wegzulassen, also v.a. "mac_type" und vielleicht auch "value_type".

[DeeSPe]

Grundsätzlich ist es vielleicht besser, "unnützes" erst mal wegzulassen, also v.a. "mac_type" und vielleicht auch "value_type".

Das hatte ich auch schon erfolglos getestet.

Gruß
Dan

[MadMax-FHEM]

Soweit ich verstanden habe können die Batteriewerte nur bei einem (kurzzeitigem) Connect übermittelt werden.
Ich benutze die Version vom Gateway die dauerhaft scannt. Evtl. geht das "connecten" mit dieser Version gar nicht?
Bekomme es jedenfalls nicht hin ein "success" zurück zu bekommen.
Habe bei einer Suche noch eine UID für den Batterie Service gefunden.
So sieht das jetzt bei mir aus, aber leider nicht funktionell:

Code Auswählen Erweitern

set .... publish home/OpenMQTTGateway_ESP32_BLE_C/commands/MQTTtoBT/config {"ble_read_address":"XX:XX:XX:XX:XX:XX","ble_read_service":"0000180f-0000-1000-8000-00805f9b34fb","ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb","value_type":"INT","immediate":true,"mac_type":0,"ttl":2}


Gruß
DAn

Also ich habe ja wohl keinen Dauerscanner?
Bzw. steht neben meinem Binary: scans every 55s (ich hab's mal wegen der Waage auf 15s runter gedreht per fhem [sofern das tatsächlich wirkt] / ohne immer noch nicht zu wissen, ob das Not tut   )
EDIT: siehe auch hier https://forum.fhem.de/index.php/topic,126366.msg1211309.html#msg1211309
EDIT: bzw. kann ich was anderes flashen? Ich hätte noch einen ESP32 über Wenn ich da was an der Source ändern muss usw. ginge auch, dauert halt nur, wegen Zeitmangel...

Ich hab das dem mal bzgl. meines gTag "vor die Füße geworfen"...
Allerdings keine Batteriewerte, sondern (stattdessen) neue Readings OpenMQTTGateway_ESP32_BLE_characteristic und OpenMQTTGateway_ESP32_BLE_service mit den versandten Werten...

Ich sehe das doch richtig, dass ich das "einfach" in den MQTT2_Server werfe (vorher nat. die MAC anpasse)?

Oder muss ich da was anderes tun?
(Wenn Batterie vom gTag und mein Handy mit dem MQTTGateway tun würden, dann würde ich meinen PI ZeroW in Rente schicken können/wollen)

Gruß, Joachim

[kroman]

Soweit ich verstanden habe können die Batteriewerte nur bei einem (kurzzeitigem) Connect übermittelt werden.

Prinzipiell _meine_ ich das mit den "config"-Befehlen so zu verstehen, dass das beim nächsten "connect" (der auch im Rahmen eines scans sein kann) gequeued werden sollte und dann eben "abgefeuert" wird

Ich denke das stimmt, aber man kann es mit "immediate": true umgehen, siehe:

https://docs.openmqttgateway.com/use/ble.html#setting-the-minimum-rssi-accepted-to-publish-device-data

These actions will be taken on the next BLE connection, which occurs after scanning and after the scan count is reached, see above to set this.
This can be overridden by providing an (optional) parameter "immediate": true within the command. This will cause the BLE scan to stop if currently in progress, allowing the command to be immediately processed.

Man sieht auch in meinem consolen log unten, dass er connected.

Habe bei einer Suche noch eine UID für den Batterie Service gefunden.

Super, sieht besser aus würde ich sagen. Jetzt beklagt er sich nicht mehr über die service UUID, sondern characteristic UUID:

Code Auswählen Erweitern


N: [ MQTT->OMG ]: {"ble_read_address":"7C:2F:80:C3:90:FF","ble_read_service":"0000180f-0000-1000-8000-00805f9b34fb","ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb","immediate":true,"value_type":"INT"}
N: Found 2 devices, scan number 2 end
N: BLE Connect begin
N: Failed to find characteristic UUID: 00002a19-0000-1000-8000-00805f9b34fb
N: BLE Connect end
N: Send on /BTtoMQTT/7C2F80C390FF msg {"id":"7C:2F:80:C3:90:FF","service":"0000180f-0000-1000-8000-00805f9b34fb","characteristic":"00002a19-0000-1000-8000-00805f9b34fb","success":false}



Ich denke 0000180f-0000-1000-8000-00805f9b34fb passt für den service und 00002a19-0000-1000-8000-00805f9b34fb sollte auch für die characteristic passen.

Mein G-Tag meint auch beides zu unterstützen:

Code Auswählen Erweitern


kro@dell2:~$ sudo gatttool -b 7C:2F:80:C3:90:FF --primary
attr handle = 0x0001, end grp handle = 0x0009 uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle = 0x000c, end grp handle = 0x000f uuid: 00001801-0000-1000-8000-00805f9b34fb
attr handle = 0x0010, end grp handle = 0x0018 uuid: 0000180a-0000-1000-8000-00805f9b34fb
attr handle = 0x0019, end grp handle = 0x001c uuid: 0000180f-0000-1000-8000-00805f9b34fb

kro@dell2:~$ sudo gatttool -b 7C:2F:80:C3:90:FF --characteristics
handle = 0x0002, char properties = 0x02, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb
handle = 0x0006, char properties = 0x0a, char value handle = 0x0007, uuid = 00002a02-0000-1000-8000-00805f9b34fb
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002a04-0000-1000-8000-00805f9b34fb
handle = 0x000d, char properties = 0x22, char value handle = 0x000e, uuid = 00002a05-0000-1000-8000-00805f9b34fb
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a29-0000-1000-8000-00805f9b34fb
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a24-0000-1000-8000-00805f9b34fb
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a26-0000-1000-8000-00805f9b34fb
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a28-0000-1000-8000-00805f9b34fb
handle = 0x001a, char properties = 0x12, char value handle = 0x001b, uuid = 00002a19-0000-1000-8000-00805f9b34fb


Dennoch "Failed to find characteristic UUID"

EDIT: bzw. kann ich was anderes flashen?

Du kannst selber den source code bauen, siehe hier:

https://docs.openmqttgateway.com/upload/builds.html#option-3-upload-your-configurations

[ares]

Mit MQTT habe ich leider noch überhaupt keine Erfahrungen und daher stell ich nun trotz viel Lesen in den letzten Tagen wahrscheinlich sehr doofe Fragen... bitte verzeiht.
Morgen kommt hoffentlich mein erster ESP32. Den flashe ich und trage den Zugang zum WLAN und MQTT-Server ein. Soweit ist mir das noch klar.

Fragen vor der Inbetriebnahme meines ersten ESP32:

• Was trage ich am ESP32 bei "gateway name" und "mqtt base topic" ein, damit es später keine Probleme mit zwei oder mehr ESP32 gibt? Beide ESP mit denselben Namen?
• Wenn zwei ESP32 in Reichweite eines BLE-Geräts sind, da sich der Empfangsbereich überlappt, dann sammeln beide die Information ein und schicken diese redundant an fhem weiter. Das ja nicht automatisch schlecht, da beim Ausfall eines ESP32 weiterhin Daten in fhem ankommen. Soweit so gut, aber die Daten sollten dann in fhem auch zusammengeführt werde und Trigger für weitere Änderungen nur einmal anstoßen und die Daten nur einmal in der Datenbank landen. Wie stelle ich das am einfachsten an?

Viele Grüße
Manfred

[Beta-User]

Mit MQTT habe ich leider noch überhaupt keine Erfahrungen und daher stell ich nun trotz viel Lesen in den letzten Tagen wahrscheinlich sehr doofe Fragen... bitte verzeiht.

Kein Anlass, um Verzeihung zu bitten: Diese ganzen Dinge sind nicht unbedingt selbsterklärend, und ich würde mich freuen, wenn entsprechende Ergänzungsvorschläge für den (OMG-) Wiki-Artikel kämen - auch und gerade von "Einsteigern" in das Thema. Die Basis hat übrigens damals auch ein "Einsteiger" verfasst, ich hab's nur etwas angepaßt und übernommen. (Es müßte im Wiki-Bereich einen Thread dazu geben, da steht auch, wie das Format in etwa sein sollte).

Was trage ich am ESP32 bei "gateway name" und "mqtt base topic" ein, damit es später keine Probleme mit zwei oder mehr ESP32 gibt? Beide ESP mit denselben Namen?

Der Topic insgesamt sollte unterscheidbar sein, ich würde nur "name" anpassen. Wichtig: der Name sollte die Großbuchstaben O, M und G in dieser Reihenfolge enthalten, sonst hat attrTemplate Probleme bei der Ermittlung der Parameter für die Subdevices.

Wenn zwei ESP32 in Reichweite eines BLE-Geräts sind

Korrekt, es wird dann von beiden ESP's gemeldet, was man z.B. bei den G-Tags auch dazu nutzen kann rauszufinden, wo in etwa sich der gerade befindet.
NACHTRAG zur Klarstellung: Die Daten landen unabhängig vom empfangenden GW jeweils in demselben "Sub-Device", weil die per bridgeRegexp ermittelte "Pseudo-CID" identisch ist. (Vermutlich ist das unverständlicher technischer Kauderwelsch, aber das Ergebnis zählt...).
Trotzdem macht es z.B. wenig Sinn, die Temperaturen usw. doppelt zu loggen. Von daher sind diese attrTemplate bisher die einzigen, die e-o-c-r-Attribute direkt setzen.

Generell: Das mit mehreren GW's ist im attrTemplate-Satz noch nicht optimiert. Eigentlich sollten die BT-Spezifischen Kommandos aus dem "scanner" raus und jeweils direkt an die MCU-Einheiten. Also falls da jemand Vorschläge macht, wäre ich nicht unglücklich (bisher war das verlautbarte Interesse an dieser BT-Lösung noch so verhalten, dass ich das noch nicht angegangen war).

PS: Das Interesse freut mich sehr, das doch an der Sache vorhanden zu sein scheint. Bisher kam ich mir damit immer irgendwie "exotisch" vor .

[kroman]

Bezüglich Gigaset G-Tag wurde mir auf github geholfen.

So funktionierts (doch mit HEX):

Code Auswählen Erweitern


set mqtt2server publish home/OMG1/commands/MQTTtoBT/config {"ble_read_address":"7C:2F:80:C3:90:FF","ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX","immediate":true}


Code Auswählen Erweitern


   READINGS:
     2022-02-28 12:16:29   IODev           mqtt2server
     2022-03-05 08:29:19   OMG1_characteristic 0x2a19
     2022-03-05 08:37:57   OMG1_id         7C:2F:80:C3:90:FF
     2022-03-05 08:37:57   OMG1_mac_type   0
     2022-03-05 08:37:57   OMG1_manufacturerdata 80010215123480c390ffbbc5
->   2022-03-05 08:29:19   OMG1_read       42
     2022-03-05 08:37:57   OMG1_rssi       -83
     2022-03-05 08:29:19   OMG1_service    0x180f
     2022-03-05 08:29:19   OMG1_success    true


[MadMax-FHEM]

Nach ein wenig hin und her probieren (und v.a. näher dran bringen des gTag) hat es auch geklappt

Und der Wert (gut noch in HEX) stimmt (sogar) mit meiner bisherigen Angabe per leprecensed überein

EDIT: meiner hat noch etwas mehr "Saft"

Gruß, Joachim

[Beta-User]

  ...funktioniert auch ohne "jetzt".
Jetzt stellen sich halt eine ganze Reihe von Fragen, wie man das ganze sinnvoll verwertet...

Falls jemand Ideen (=Code) hat: her damit ...