OpenMQTTGateway support thread - im Speziellen: BT/BTLE

Begonnen von Beta-User, 21 Februar 2022, 17:13:56

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

nachdem ich am WE zum ersten Mal ein update via MQTT angeschubst habe, und auch bei "geeignete Temperatursensoren" das eine oder andere an Fragen aufgetaucht ist, ist es vielleicht an der Zeit, nochmal einen seperaten Support-Thread zum OpenMQTTGateway anfangen.

Wer OpenMQTTGateway nicht kennt: Es ist eine firmware, ursprünglich für ESP8266, die schon lange v.a. für 433MHz-Gadgets im Umlauf ist, aber bisher in FHEM nicht die große Rolle gespielt hat, weil es dafür andere sehr gute Lösungen gibt. Seit ESP32 verfügbar sind, wird darin auch einiges empfangen, was BLE "spricht", ich habe wegen der Temperatursensoren damit angefangen. Am Anfang hing die firmware noch manchmal aber seit vielen Monaten ist das kein Thema mehr, und seit wenigen Wochen ist jetzt V 0.9.9 bzw. 0.9.10 im Umlauf.

Hier das changelog:
ZitatAmong new devices and boards this release brings some exciting features like the capability to connect and control a BLE device immediately like a switchbot, here is a sample command for the SWITCHBOT S1:
{ "ble_write_address": "FF:AA:BB:FF:DD:EE", "ble_write_service": "cba20d00-224d-11e6-9fb8-0002a5d5c51b", "ble_write_char": "cba20002-224d-11e6-9fb8-0002a5d5c51b", "ble_write_value": "570100", "value_type": "HEX", "ttl": 4, "mac_type":1, "immediate": true }

Doku ist hier zu finden: https://docs.openmqttgateway.com/, die unterstützten Devices finden sich in https://compatible.openmqttgateway.com/index.php/devices/.

Wegen der schon länger bestehenden Option, BLE-Kommandos (zeitverzögert) rauszuhauen, sollte man damit z.B. auch equiva-Thermostate steuern können, und vermutlich geht damit auch das BT-Zeug von Ledvance, vielleicht kann man die neuen BT-Fernbedienungen (von irgendeiner Firma, deren Namen ich grade nicht parat habe) damit nutzbar machen, etc. pp...

Vorausgesetzt, man kennt die Befehle... Und das ist der Grund für diesen Thread: Sammeln, was wir dazu kennen und überlegen, wie man es ggf. nutzbar machen kann :) . Wie üblich habe ich die Hardware nicht und kann nur anbieten, das irgendwie in allgemeine "MQTT2-Form" zu pressen, wenn und soweit wir was rausfinden ;D .

Und ja: Es gibt speziell für die switchbot eine eigene firmware für ESP32 und es kann durchaus auch sein, dass es mit Tasmota@ESP32 auch schon geht, wenn klar ist, was wohin zu schreiben ist, kann man voneinander abschreiben und ich will auch nicht behaupten, dass der eine oder der andere Weg besser ist...

Grüße, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Vielleicht aus gegebenem Anlass noch ein paar Hinweise:
- Es gibt einen Wiki-Artikel dazu: https://wiki.fhem.de/wiki/OpenMQTTGateway. Da ist zumindest mal zu finden, wie man dazu kommt, über den "scanner" (attrTemplate: "OpenMQTTGateway_BT_scanner") erst mal einen Überblick zu bekommen, was da so alles Infos per BT preisgibt.
Dieses Device ist bewußt als "Einsammler" konzipiert, weil z.B. mittlerweile ziemlich viele Mobiltelefone ihre BT-Adresse regelmäßig wechseln und ein "autocreate" für solche Konstellationen wenig Sinn machen würde.

- Weil nicht automatisch vereinzelt wird, muss man alle weiteren Geräte "händisch" anlegen, also den aus der MAC-Adresse gebildeten passenden Topic abonnieren. Das geht am einfachsten, wenn man ein passendes (im Prinzip aber: beliebiges) attrTemplate für ein Einzeldevice auswählt und dann die MAC-Adresse (ohne Doppelpunkte) in das Dialogfeld einträgt (im "scanner" sollte gut zu erkennen sein, wie die in etwa aussehen muss, und jedes attrTemplate enthält auch nochmal eine Anleitung dazu...).
Da das nicht immer paßt (z.B. gibt es aktuell für die Mi Scale noch kein attrTemlate), kann man auch irgendein anderes nehmen, dann paßt ggf. das icon nicht und man muss die Attribute event-on-change-reading (etc.) bzw. jsonMap ggf. anpassen (oder erst mal löschen), aber die Readings sollten dann erst mal da sein...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

#2
Hallo,

so ich habe mir "angeregt" hierdurch: https://forum.fhem.de/index.php/topic,82572.msg1210713.html#msg1210713

eine Xiaomi Scale 2 besorgt und einen ESP32 (den ich noch rumliegen hatte) mit OpenMQTTGateway geflasht.

Ich habe es auch geschafft den ESP an einen MQTT2_SERVER in fhem "anzubinden" (und autocreate auf simple [ja ist nicht nötig, weil "Standard" aber es ist auch nicht gleich was passiert ;)  ]) und dann hatte ich ein MQTT2_DEVICE.
Da habe ich dann attrTemplate OpenMQTTGateway ausgeführt (fand das "intuitiv" eine gute Idee ;)  ).

Dann kam (nach einem "Reboot" des ESP? oder "einfach so?) ein weiteres MQTT2_Device...
Nachdem da auch nichts passiert ist, also "Richtung Waage", (oder ich zu ungeduldig war) habe ich das attrTemplate OpenMQTTGateway_BT_scanner angewandt (klang "intuitiv" nach einer guten Idee ;)  )...

Nun habe ich (neben den Werten vieler anderer BT-Geräte auch) die Werte der Waage in fhem :)
EDIT: leider (noch) nicht mein Handy (das habe ich aktuell mittels dem hier https://forum.fhem.de/index.php/topic,118917.msg1133609.html#msg1133609 über einen PI ZeroW angebunden / den könnte/würde ich gerne in "Rente schicken") und auch (noch) nicht meine "Smart Watch" (wäre nicht so wichtig)
EDIT: dafür könnte ich u.U. meinen GTag darüber (zusätzlich) einbinden. Aktuell wird der von einem PI (mit)erfasst, der eh "da ist" (deCONZ-Gateway)...

Dann wie hier und im Wiki beschrieben ein MQTT2_DEVICE angelegt und das attrTemplate OpenMQTTGateway_BT_mi_flora_sensor genommen und angepasst, die Waage liefert ja "nur" das Gewicht (zumindest bei mir ohne weitere Einrichtung mittels App etc.), die "Anpassungen" waren also einfach.

Gut ein schönes icon fehlt noch aber das ist (mir) nicht so wichtig.

Hier mal ein rawDef (nicht wundern über MQTT2_SERVER2: ist ein eigens aufgesetzter "Test-Server" auf Port 1884):

defmod OMG_D03E7D103CDB MQTT2_DEVICE D03E7D103CDB
attr OMG_D03E7D103CDB autocreate 0
attr OMG_D03E7D103CDB event-min-interval 300
attr OMG_D03E7D103CDB event-on-change-reading weight
attr OMG_D03E7D103CDB icon checkbox_unchecked
attr OMG_D03E7D103CDB jsonMap weight:weight
attr OMG_D03E7D103CDB model OpenMQTTGateway_BT_mi_flora_sensor
attr OMG_D03E7D103CDB readingList home/O[^/]*M[^/]*G[^/]*/BTtoMQTT/D03E7D103CDB:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr OMG_D03E7D103CDB room MQTT2_DEVICE
attr OMG_D03E7D103CDB stateFormat weight kg

setstate OMG_D03E7D103CDB 75.85 kg
setstate OMG_D03E7D103CDB 2022-03-02 10:05:29 IODev MQTT2_Server2
setstate OMG_D03E7D103CDB 2022-03-02 10:05:29 attrTemplateVersion 20211011
setstate OMG_D03E7D103CDB 2022-03-02 10:21:53 brand Xiaomi
setstate OMG_D03E7D103CDB 2022-03-02 10:21:53 id D0:3E:7D:10:3C:DB
setstate OMG_D03E7D103CDB 2022-03-02 10:21:53 impedance 627
setstate OMG_D03E7D103CDB 2022-03-02 10:21:53 mac_type 0
setstate OMG_D03E7D103CDB 2022-03-02 10:21:53 model Miscale_v2
setstate OMG_D03E7D103CDB 2022-03-02 10:21:53 model_id XMTZC05HM
setstate OMG_D03E7D103CDB 2022-03-02 10:21:53 name MIBFS
setstate OMG_D03E7D103CDB 2022-03-02 10:21:53 rssi -76
setstate OMG_D03E7D103CDB 2022-03-02 10:21:53 unit kg
setstate OMG_D03E7D103CDB 2022-03-02 10:21:53 weight 75.85


Wenn weitere Daten notwendig sind oder ich was ändern soll: einfach "sagen"...
EDIT: gut das event-min-interval kann sicher weg? Oder eben "größer"...

Ansonsten hätte ich noch ein paar Fragen:

Das MQTT-Zeugs ist ja (häufig) sehr "geschwätzig" und auch die beteiligten Devices (MQTT2_DEVICE...) erzeugen ja viele Events.
Ich versuche das ja generell soweit möglich "einzudämmen", daher ist MQTT auch noch nicht wirklich (viel) in mein Hauptsystem eingezogen...

Ja klar: event-on-change-reading...
Aber wenn ich ein Template anwende, dann sind da ja schon einige Dinge gesetzt, ändere ich diese und wende ein Update des Templates an, sind ja meine Änderungen wieder weg?

Und klar das geht dann für einzelne MQTT_DEVICE "einfach", also für die "End-Devices" aber wie würde ich denn das bei z.B. dem/den Gateway/s "eindämmen"?

Auch weiß ich noch nicht genau, wie das Zusammenspiel von MQTT2_Scanner und dem ESP32 ist.
Bei dem Binary was ich geflasht habe heißt es, dass im Rhytmus von 55s (by default) gescannt wird:

Zitat von: https://docs.openmqttgateway.com/upload/web-install.html
esp32dev-ble    ESP32 dev board    BLE gateway with one scan every 55s per default

Wird das dann durch das Intervall beim MQTT2_SCANNER beeinflusst?
Bzw. wie hängt das zusammen?

Aktuell habe ich beim Scanner 15s eingestellt ([noch] ohne zu wissen, ob das Not tut oder etwas "bewirkt"), weil ja die Waage (gefühlt, habe ja [noch] keine Ahnung) die Messung nicht ewig "bereit hält"...

Danke, 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)

Beta-User

 :) Schön, dass das soweit geklappt hat.

Vielleicht ein paar Antwort-Versuche auf die (teils impliziten) Fragen:
- neue Devices werden bei MQTT2_.* nur angelegt, wenn
-- die "autocreate"-Einstellungen auf allen Ebenen passen, also ein TYPE=autocreate vorhanden ist, das IO (implizit oder explizit) auf einem "autocreate" steht, was nicht "no" ist und
-- Infos über das MQTT2-IO reinkommen, die nicht zugeordnet werden können (oder per bridgeRegexp dem "eigentlichen Zieldevice" nicht zugeordnet werden sollen).

Da das (BT-) Gateway recht viel Zeug "einfängt", passiert das Anlegen des "Sammeldevices" für die BT-Signale in der Regel ziemlich schnell, es muss aber was passendes eingehen.
Je nach Umfeld ist das auch recht "geschwätzig", und da ich z.B. die Infos aus diesem Gerät gar nicht für irgendwelche Eventhandler brauche, steht es bei mit auch auf "e-o-c-r none" (es triggert also effektiv gar nicht, man muss halt die Seite refreshen, falls man nach irgenwas bestimmtem aktualisiertem sucht). Da bei mir auch die Infos von beiden Gateways in diesem Sammeldevice landen, gibt es übrigens auch "Doppelmessages".

Generell gibt es Devices, die von sich aus (teilweise) was preisgeben, andere tun das nicht. Alles, was was preisgibt, landet früher oder später auch im "Scanner", alles, was man aktiv abholen muss, landet nur dort, wenn die firmware das kann...
Nach meinem Verständnis ist "interval" nur für diese letztere Art Gerät maßgeblich, der Setter kann afaik dieses default-Intervall ändern.

Was Events betrifft:
- event-min-interval war falsch, ist im attrTemplate zwischenzeitlich auch geändert, und kann hier in der Tat weg.
- Jeder JSON-Blob erzeugt nur eine Event-Loop, die Last ist also kaum höher, wie wenn nur ein Reading triggernd aktualisiert würde. Tendenziell finde ich in der Hinsicht die OpenMQTTGateway-Lösung zum großen Teil unproblematisch, da gibt es anderswo viel "komischere" Sachen...

Die Waage werde ich bei Gelegenheit mal vertemplaten (und vielleicht auch ein "unknown" bauen), dann darfst du gerne Testen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

Jep, lief prima/einfach (selbst ohne noch das Wiki zu kennen ;)  )...

Danke für die Antworten, ich werde einfach auf meinem Testsystem noch ein wenig "rumspielen".

Klar, wenn du was hast, einfach her damit :)
(solange das auf meinem Testsystem ist kein Problem / bzw. habe ich ja noch einen ESP32 [der Waage wird es egal sein, wer da alles "mithört" ;) ] und hätte sogar einen ESP8266 mit BT-Modul also noch nicht dran bzw. verm. eh "zu alt" [hatte ich mir vor Jahren schon mal zugelegt: komm halt zu nix :-\  ])

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)

Beta-User

..here you are...
name:OpenMQTTGateway_BT_scale
prereq:{my @devices=devspec2array("model=OpenMQTTGateway_MCU");return 1 if $devices[0];return 0}
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*/O[^/]*M[^/]*G[^/]*/.*
desc:use this with an OpenMQTTGateway for scales like Xiaomi Mi Scale. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki<br>Recommended structure of the topic pattern home/OpenMQTTGateway/.*.<br>NOTE: You'll be asked to provide the HEX address of your scale. Best start with looking at what "OpenMQTTGateway_BT_scanner" povides, e.g. if you have a reading name like "6C697244245E_id", "6C697244245E" (without quotes) is what you want to enter...<br>NOTE: this will create a new device!
order:X_02e
par:BT_ID;Pls. enter your bluetooth device ID; {undef}
par:BASE_ID;BASE_ID typically is home;{ AttrVal('DEVICE','readingList','') =~ m,([^:]+)[/]O[^/]*M[^/]*G[^/]*[/].*:, ? $1 : undef }
par:NEWDEVROOM;Room of the calling device; {AttrVal('DEVICE','room','MQTT2_\DEVICE')}
defmod OMG_BT_ID MQTT2_\DEVICE BT_ID
deletereading -q OMG_BT_ID (?!associatedWith|IODev).*
attr OMG_BT_ID autocreate 0
attr OMG_BT_ID readingList\
  BASE_ID/O[^/]*M[^/]*G[^/]*/BTtoMQTT/BT_ID:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr OMG_BT_ID event-min-interval batteryPercent:7200,weight:1800
attr OMG_BT_ID event-on-change-reading batteryPercent,weight:0.1,distance:5,impedance
attr OMG_BT_ID icon message_medicine
attr OMG_BT_ID jsonMap batt:batteryPercent tempc:temperature tem:0 tempf:0 hum:humidity servicedatauuid:0 servicedata:0
attr OMG_BT_ID stateFormat weight kg
attr OMG_BT_ID room NEWDEVROOM
{ fhem "trigger $FW_wname JS:location.href='$FW_ME?detail=OMG_BT_ID'" if($cl && $cl->{TYPE} eq "FHEMWEB") }
attr OMG_BT_ID model OpenMQTTGateway_BT_temp_hum_sensor
set DEVICE attrTemplate set_IODev_in_channels SUBCHANNELS=OMG_BT_ID
setreading OMG_BT_ID attrTemplateVersion 20220302

name:OpenMQTTGateway_BT_unknown_gadget
prereq:{my @devices=devspec2array("model=OpenMQTTGateway_MCU");return 1 if $devices[0];return 0}
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*/O[^/]*M[^/]*G[^/]*/.*
desc:use this with an OpenMQTTGateway to get an "empty" device for further adoptions to your needs. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki<br>NOTE: You'll be asked to provide the HEX address of your gadget. Best start with looking at what "OpenMQTTGateway_BT_scanner" povides, e.g. if you have a reading name like "6C697244245E_id", "6C697244245E" (without quotes) is what you want to enter...<br>NOTE: this will create a new device!
order:X_02x
par:BT_ID;Pls. enter your bluetooth device ID; {undef}
par:BASE_ID;BASE_ID typically is home;{ AttrVal('DEVICE','readingList','') =~ m,([^:]+)[/]O[^/]*M[^/]*G[^/]*[/].*:, ? $1 : undef }
par:NEWDEVROOM;Room of the calling device; {AttrVal('DEVICE','room','MQTT2_\DEVICE')}
defmod OMG_BT_ID MQTT2_\DEVICE BT_ID
deletereading -q OMG_BT_ID (?!associatedWith|IODev).*
attr OMG_BT_ID autocreate 0
attr OMG_BT_ID readingList\
  BASE_ID/O[^/]*M[^/]*G[^/]*/BTtoMQTT/BT_ID:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr OMG_BT_ID icon bluetooth
attr OMG_BT_ID jsonMap batt:batteryPercent tempc:temperature tem:0 tempf:0 hum:humidity servicedatauuid:0 servicedata:0
attr OMG_BT_ID room NEWDEVROOM
{ fhem "trigger $FW_wname JS:location.href='$FW_ME?detail=OMG_BT_ID'" if($cl && $cl->{TYPE} eq "FHEMWEB") }
attr OMG_BT_ID model OpenMQTTGateway_BT_temp_hum_sensor
set DEVICE attrTemplate set_IODev_in_channels SUBCHANNELS=OMG_BT_ID
setreading OMG_BT_ID attrTemplateVersion 20220302

Einfach (am besten nach einem update) in die mqtt2.template einbauen und dann {AttrTemplate_Initialize()} aufrufen, dann sollten die zwei verwendbar sein :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

Ok, ich wollte es ja so haben ;)

Update läuft...
...wo finde ich die attrTemplate?
(Also damit ich das "einbauen" kann)

Ich habe außer sie anzuwenden noch nicht wirklich was damit gemacht  :-[

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)

Beta-User

 :) Die attrTemplate liegen alle in einem speziellen Unterverzeichnis unter ./FHEM/lib.

Siehe dazu und zur Syntax (falls es interessiert): https://wiki.fhem.de/wiki/AttrTemplate.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

Hmm, also ich hatte (noch) keine Zeit zu lesen...
...ich habe mal den Code genommen (ohne zu kucken) und in folgende Datei eingefügt (ganz ans Ende):

/opt/fhem/FHEM/lib/AttrTemplate/mqtt2.template

Dann habe ich {AttrTemplate_Initialize()} ausgeführt.
(sogar shutdown restart)

Hätte jetzt erwartet, dass ich unter attrTemplate nun die 2 neuen Templates finde?
(also ich bin zu "meinem" Device und dann eben attrTemplate)

Konnte die aber nicht finden...

Im Log nicht wirklich auffällige Infos...

2022.03.02 14:15:17 2: AttrTemplates: got 255 entries

Wobei ich nicht weiß, wie viele es ohne die beiden neuen Templates sind/sein sollten... ;)

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)

Beta-User

Das Vorgehen war prinzipiell ok so, und die Zahl der in einem System vorhandenen attrTemplate kann schwanken, weil es teilweise davon abhängig ist, was man an Modulen hat und welche "prereqs" gegeben sind...

Vermutlich liegt es an "filter" oder "prereq": Diese attrTemplate setzen bestimmte Vorbedingungen voraus, bevor sie angezeigt (filter) oder überhaupt geladen (prereq) werden. Eigentlich sollten sie auf der Detailansicht des OpenMQTTGateway-MCU-Devices sichtbar sein. Falls nicht, einfach mal diese beiden Zeilen jeweils deaktivieren, danach wieder "initialize" ausführen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

Ja, ne, so macht das Sinn ;)

Also ich bin bei dem Scanner auf attrTemplate und dann waren sie da.
Dann Scale und die ID, dann wurde aber "mein" Device einfach geändert (auch ok ;)  )...
(also zumindest kam mir das so vor / gut 1 Device pro ID reicht ja)

Dann noch schnell gewogen, damit auch was ankommt: klappt :)

Allerdings sind diese Einstellungen "nutzlos":
Zitat
attr OMG_D03E7D103CDB event-min-interval batteryPercent:7200,weight:1800
attr OMG_D03E7D103CDB event-on-change-reading batteryPercent,weight:0.1,distance:5,impedance

Weil außer weight kommt (bei mir) nichts an?
(wo kann ich nachvollziehen, ob da nicht doch mehr kommt?)

Danke, 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)

Beta-User

 :) Das mit dem "Ändern" hat damit zu tun, dass ein Devicename "gefunden" werden muss, und da wird halt herangezogen, was (halbwegs eindeutig) da ist - die BT-Adresse. Wenn du die "alten Devices" umbenannt gehabt hättest, wären es zwei (oder drei) geworden...

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DeeSPe

Hallo Leute,

ich habe mich auch mal dran gewagt und einen ESP32 geflasht.
Hat gleich funktioniert wie im Wiki beschrieben und ich kann nun meine G-Tags damit erkennen. Vielen Dank für die wirklich gute Dokumentation im Wiki und natürlich auch die passenden AttrTemplates.
Nun wäre mein Traum den bisher (über collectord) angebundenen RPi damit abzulösen, nur leider fehlt mir dazu noch der Batteriestand des G-Tags. Gibt es eine Möglichkeit diesen Wert auch über das Gateway zu bekommen?

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Beta-User

#13
Danke vorab mal für die Rückmeldung!

Was Batterie-Werte angeht, sehe ich die im Moment nur bei meinen Xiaomi-Raumsensoren.

ABER: Seit der vorletzten Version oder so gibt es die Möglichkeit, im Prinzip beliebige BT-"Kommandos" zu versenden. Von daher würde ich stark darauf tippen, dass es grundsätzlich möglich ist, neben allem möglichen anderen auch die Batterie-Werte auszulesen - vorausgesetzt, man kennt das passende Kommando. Das ist aber afaik im Prinzip jeweils auch nur eine Anweisung, die auch an ein "normales" BT-Dongle gehen könnte.

Muss aber zugeben, dass ich da auch alles andere als "Experte" bin...
Also falls du da nähere Infos hast, könnten wir versuchen, was zusammenzuknödeln ::) . Das könnte dann in einen getter münden, der per periodicCmd aufgerufen wird.

Nachtrag: Prinzipielle Doku ist hier zu finden: https://docs.openmqttgateway.com/use/ble.html#read-write-ble-characteristics-over-mqtt-esp32-only
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DeeSPe

Danke, das habe ich auch schon gelesen. Weiß allerdings noch nicht richtig wie ich das damit umsetzen kann.
Habe mal im lepresenced nachgesehen und dort wird "BATTERY_LEVEL_CHARACTERISTIC_UUID" => "00002a19-0000-1000-8000-00805f9b34fb" verwendet um die Batteriewerte zu holen.
Ich schaue mir das später nochmal an, muss erst mal den Hund ausführen.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe