OpenMQTTGateway support thread - im Speziellen: BT/BTLE

[MadMax-FHEM]

Was stört dich an Last: last?

Ich beachte das Scanner-Device gar nicht (mehr)...
Ich schaue auch generell nicht (mehr) so viel in meinen MQTT2Server

[OT]
Aktuell habe ich nur ein paar Tasmota laufen (eine "USB-Steckdose" und ein 4-fach Relais [meine sonst nicht so smarte Markise kann ich so steuern: Taster schalten   ])...

Bei Shelly bin ich noch am Überlegen.
Also generell (versuche) ich die mit dem Shelly-Modul einzubinden aber die RGBW2 sind (gefühlt) mit mqtt "besser" eingebunden
Mal sehen: (Vergleichs-)Test läuft noch...
[/OT]

Aktuell habe ich (wieder) den "standard-BLE" mit Scan alle 55s laufen...

e-o-c-r und e-o-u-r habe ich rausgenommen.
Seit dem Setzen der whitelist (auf nur die Waage) bekomme ich nach dem Wiegen ca. 10min Daten von der Waage (klar alle Minute), danach ist Ruhe.

Gruß, Joachim

[DeeSPe]

stateFormat "last" beim scanner ist einfach immer noch unnötig, das fliegt im attrTemplate wieder raus.

Hier mal noch ein update-Vorschlag für den gtag:

Code Auswählen Erweitern

attr OMG_FFFFC427426B getList batteryPercent:noArg batteryPercent home/OpenMQTTGateway_ESP32_1/commands/MQTTtoBT/config {"ble_read_address":"FF:FF:C4:27:42:6B","ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX"}\
beep:noArg batteryPercent home/OpenMQTTGateway_ESP32_1/commands/MQTTtoBT/config {"ble_read_address":"FF:FF:C4:27:42:6B","ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX","immediate":true}
attr OMG_FFFFC427426B readingList home/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT/FFFFC427426B:.* { $EVENT =~ m,characteristic...0x2a19.*read[^\d]+([\d]+), ? return { batteryPercent => hex($1) } : $TOPIC =~ m,home/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT,;; my $rets = json2nameValue($EVENT, "${1}_");; $rets->{last_IO} = $1;; return $rets}

Muss nur überlegen, wie ich das vertemplated bekomme.

Da mein gtag anfängt zu pipsen, wenn man den Batteriewert holt, kommt das m.E. für periodicCmd nicht in Frage...

Was hast du denn für G-Tags?
Meine Piepsen nicht und könnten das auch gar nicht da es keinen Piepser auf dem Board gibt.

Ich benutze ja den Dauerscanner (esp32dev-ble-cont), nach einem Abfragen der Batteriewerte wird allerdings nicht mehr gescannt. Erst "set ... publish home/OpenMQTTGateway_ESP32_BLE_C/commands/MQTTtoBT/config '{"interval":1}'" aktiviert das Scannen wieder.

Gruß
Dan

[Beta-User]

China-Irgendwas, ähnlich denen hier: https://www.ebay.de/itm/172683053179?hash=item2834b6487b:g:msEAAOSwARZXmxXL

[ares]

Ich fasse die inwzischen erfoglreiche Einbindung meiner Mi Smart Scale 2 (Model XMTZC04HM) nochmal zusammen, falls jemand sowas zu Hause rum stehen hat und günstig an fhem anbinden möchte.

Ein "(Espressif) ESP32 WLAN Dev Kit Board" mit Gehäuse gibt's für 10 Euro und kann ohne Bastelarbeiten (Löten) mit einem alten Handy-Netzteil in Betrieb genommen werden. Nach dem Anstecken am PC sollte im Geräte-Manager kontrolliert werden, ob noch ein Treiber für die Bereitstellung eines COM-Ports benötigt wird und dieser (Google ist Dein Freund) installiert werden.

Danach kann direkt aus dem Browser (https://docs.openmqttgateway.com/upload/web-install.html) ohne Installation von Zusatzsoftware die Firmware esp32dev-ble geflasht werden. Der ESP32 stellt daraufhin einen WLAN-Zugang "OpenMQTTGateway_ESP32_BLE" (Kennwort: "your_password") zur Verfügung, damit z.B. mit dem Smartphone die WLAN-Daten und die IP des MQTT2_SERVERs (fhem) konfiguriert werden können. Als Gateway-Name habe ich OMG1 verwendet, vielleicht kommt ja später noch ein OMG2. Die Reichweite ist aber deutlich größer als ursprünglich angenommen.

In fhem wird ein MQTT2 Server (früher ,,Broker") benötigt, der z.B. wie folgt angelegt werden kann:

Code Auswählen Erweitern

define MQTT2_FHEM_Server MQTT2_SERVER 1883 global

Sobald der ESP32 sendet wird automatisch ein Device MQTT2_OMG1 angelegt, das mit einem Template konfiguriert werden kann:

Code Auswählen Erweitern

set MQTT2_OMG1 attrTemplate OpenMQTTGateway_MCU

Daraufhin wird ein weiteres Device (Scanner) mit Namen MQTT2_oMQTTgw_BT angelegt, das ebenfalls konfiguriert werden muss:

Code Auswählen Erweitern

set MQTT2_oMQTTgw_BT attrTemplate OpenMQTTGateway_BT_scanner

Dort tauchen dann unzählige BLE-Geräte auf und es empfieht sich, nur die gewünschten Geräte am ESP32 freizugeben. Für die Waage a1:a2:a3:a4:a5:a6 wird das z.B. wie folgt eingeschränkt:

Code Auswählen Erweitern

set MQTT2_FHEM_Server publish -r home/OMG1/commands/MQTTtoBT/config {"white-list":["a1:a2:a3:a4:a5:a6"]}

Danach muss noch ein Device für die Waage angelegt werden:

Code Auswählen Erweitern

set MQTT2_oMQTTgw_BT attrTemplate OpenMQTTGateway_BT_scale

Damit das Gewicht noch verschiedenen Personen zugeordnet wird, kann das Gewicht über ein zusätzliches Notify über Gewicht von/bis (Gewicht anpassen ich hoffe, euer Partner oder die Kinder wiegen nicht alle gleich viel) mehreren Personen (Namen anpassen) zugeordnet werden:

Code Auswählen Erweitern

defmod OMG_70879E4C3B50.N notify (OMG_70879E4C3B50:weight:.*) {\
my $mode = ReadingsVal($NAME, "weighing_mode", "-");;\
my $w = $EVTPART1;;\
if ($mode eq "person") {\
if    ($w >= 30 && $w <  60) { fhem("setreading $NAME weight_person1 $w");;}\
elsif ($w >= 60 && $w <  85) { fhem("setreading $NAME weight_person2 $w");;}\
elsif ($w >= 85 && $w < 100) { fhem("setreading $NAME weight_person3 $w");;}\
else { fhem("setreading $NAME weight_unknown_person $w");;}\
}}

Damit das Gewicht auch für 2 Personen übertragen wird, die sich kurz hintereinander wiegen, kann das Intervall z.B. auf 5 Sekunden verkürzt werden.

Code Auswählen Erweitern

set MQTT2_FHEM_Server publish -r home/OMG1/commands/MQTTtoBT/config {"interval":5000}

Es bleibt dann nur noch, ein paar Kleinigkeiten wie e-o-u-r, Logs usw. anzupassen, damit das ganze langfristig in einem schönen Plot Gewicht/BMI/... angezeigt werden kann.

Ich möchte mich and dieser Stelle auch nochmal ausdrücklich bei MadMax-FHEM für seine Geduld und Unterstützung bedanken.
Manfred

[Beta-User]

Danke für die Zusammenfassung, mal sehen, was/wie man ggf. was ins Wiki übernehmen kann.

Es gibt übrigens bereits wieder eine aktualisierte Firmware .

Meine Piepsen nicht und könnten das auch gar nicht da es keinen Piepser auf dem Board gibt.

Meine Piepsen, das GW hat auch diese als "gtag" benannt, und auch das mit der Batterie klappt ja... Werde daraus also einen setter machen, wer die Funktion nicht hat, kann den dann ja löschen.

Ich benutze ja den Dauerscanner (esp32dev-ble-cont), nach einem Abfragen der Batteriewerte wird allerdings nicht mehr gescannt. Erst "set ... publish home/OpenMQTTGateway_ESP32_BLE_C/commands/MQTTtoBT/config '{"interval":1}'" aktiviert das Scannen wieder.

Bei mir läuft "schon immer" diese hier: esp32dev-ble-firmware.bin. Vermutlich würde es Sinn machen, wenn wir uns auf eine Art Standard verständigen könnten (zumindest, was die Empfehlung an Einsteiger angeht). Die kommt nach meinen bisherigen Beobachtungen weder durch einen getimerten noch durch einen "immediate"-Aufruf durcheinander (es kann aber ein paar Durchläufe/Minuten dauern, bis der asynchrone Batterie-Auslesewert dann da ist).

Nochmal ein paar prinzipielle Anmerkungen: Dieser attrTemplate-Satz ist irgendwann "in der Steinzeit" entstanden und wurde nie grundlegend überarbeitet. Zwischenzeitlich gibt es einige Möglichkeiten mehr, den Ablauf innerhalb eines attrTemplate-Aufrufs zu steuern. Mein damaliges "Hauptproblem" war, dass der BT-Teil zunächst nur empfangend war, und erst im Lauf der Zeit überhaupt die Option dazu kam, groß irgendwas an das GW zu senden. Da war aber der BT-Teil bereits aus dem GW-attrTemplate draußen, und ein alternatives BT-GW wollte ich mangels Bedarf auch nicht basteln.

Da jetzt aber scheinbar doch ein paar Nutzer da sind, hier mal der Versuch, das mit einer Auswahl-Option zu versehen, so dass alle "BT-Readings" direkt im GW "eingefangen" werden, da aber nicht triggern, und v.a. auch alle BT-Kommandos direkt im jeweiligen GW separat verfügbar sind, so dass die direkten publishes nicht mehr erforderlich sein sollten.

Code Auswählen Erweitern

name:OpenMQTTGateway_MCU
filter:TYPE=MQTT2_DEVICE
desc:Use this with an OpenMQTTGateway. This template is meant to configure a bridge device showing some basic info about the microcontroller (mcu) itself. For further details visit https://github.com/1technophile/OpenMQTTGateway/wiki<br>Recommended structure of the topic pattern home/OpenMQTTGateway/.*.<br>NOTE: Early user version, not yet fully tested, just build according to https://forum.fhem.de/index.php/topic,103737.0.html<br>Adopt it to your needs!
order:X_02
par:BASE_ID;BASE_ID typically is home;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m<([^:]+)/O[^/]*M[^/]*G[^/]*> ? $1 : undef }
par:DEVNAME;DEVNAME typically contains OpenMQTTGateway;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m<[^:]+/(O[^/]*M[^/]*G[^/]*)> ? $1 : undef }
par:DEV_TPC;base and device name in the topic;{ my $dt =  AttrVal('DEVICE','devicetopic',undef); defined $dt ? $dt : AttrVal('DEVICE','readingList','') =~ m<([^:]+/O[^/]*M[^/]*G[^/]*)/LWT> ? $1 : undef }
par:RADIO_HASBT;MCU uses a BT interface;{ undef }
par:RADIO_NOBT;MCU does not use any BT interface;{ undef }
par:ICON;ICON as set, defaults to MQTT;{ AttrVal('DEVICE','icon','mqtt') }
deletereading -q DEVICE (?!associatedWith|IODev).*
attr DEVICE devicetopic DEV_TPC
option:{ RADIO_HASBT }
attr DEVICE bridgeRegexp\
  $\DEVICETOPIC/433toMQTT[:/].* 'oMQTTgw_433'\
  $\DEVICETOPIC/IRtoMQTT[:/].* 'oMQTTgw_IR'\
  $\DEVICETOPIC/CLIMAtoMQTT/([a-zA-Z0-9]+)[:/].* "DEVNAME_$1"
attr DEVICE readingList\
  $\DEVICETOPIC/LWT:.* LWT\
  $\DEVICETOPIC/version:.* version\
  $\DEVICETOPIC/SYStoMQTT[:/].* { json2nameValue($EVENT,'Sys_')}\
  $\DEVICETOPIC/BTtoMQTT/([0-9A-Z]+):.* { $TOPIC =~ m,BTtoMQTT/([0-9A-Z]+),; json2nameValue($EVENT,"${1}_") }\
  $\DEVICETOPIC/BTtoMQTT/([0-9A-Z]+)/[^:]+:.* { $TOPIC =~ m,BTtoMQTT/([0-9A-Z]+)/([^:]+),; { "${1}_$2"=>$EVENT }}\
  BASE_ID/home_presence/DEVNAME:.* { return if $EVENT !~ m,(..):(..):(..):(..):(..):(..),; {last => uc($1.$2.$3.$4.$5.$6)}}\
  homeassistant/.+?/config:.* {}
attr DEVICE setList\
  restart:noArg $\DEVICETOPIC/commands/MQTTtoSYS/config {"cmd":"restart"}\
  update { my $payload = $EVENT; $payload =~ s/$EVTPART0 //; qq($\DEVICETOPIC/commands/firmware_update $payload) }\
  BT_config { my $payload = $EVENT; $payload =~ s/$EVTPART0 //; qq($\DEVICETOPIC/commands/MQTTtoBT/config $payload) }\
  BT_scan_now:noArg $\DEVICETOPIC/commands/MQTTtoBT/config {"interval":0}\
  BT_scan_interval:textField $\DEVICETOPIC/commands/MQTTtoBT/config {"interval":$EVTPART1}\
  BT_blacklist:textField $\DEVICETOPIC/commands/MQTTtoBT/config {"black-list":[$EVTPART1]}\
  BT_whitelist:textField $\DEVICETOPIC/commands/MQTTtoBT/config {"white-list":[$EVTPART1]}\
  BT_minrssi:slider,-110,1,0 $\DEVICETOPIC/commands/MQTTtoBT/config {"minrssi":$EVTPART1}}\
  deleteReadings:noArg {fhem "deletereading -q $NAME (?!associatedWith|attrTemplateVersion|last|LWT|version|Sys_).* 86400"}
attr DEVICE periodicCmd deleteReadings:1440
attr DEVICE comment For syntax wrt. update and BT commands see https://github.com/1technophile/OpenMQTTGateway/releases/tag/v0.9.7
attr DEVICE event-on-change-reading last,LWT,version,Sys_.*
option:{ RADIO_NOBT }
attr DEVICE bridgeRegexp\
  $\DEVICETOPIC/BTtoMQTT/([0-9A-Z]+)[:/].* "oMQTTgw_BT"\
  $\DEVICETOPIC/433toMQTT[:/].* "oMQTTgw_433"\
  $\DEVICETOPIC/IRtoMQTT[:/].* "oMQTTgw_IR"\
  $\DEVICETOPIC/CLIMAtoMQTT/([a-zA-Z0-9]+)[:/].* "DEVNAME_$1"
attr DEVICE readingList\
  $\DEVICETOPIC/LWT:.* LWT\
  $\DEVICETOPIC/version:.* version\
  $\DEVICETOPIC/SYStoMQTT[:/].* { json2nameValue($EVENT,'Sys_')}\
  BASE_ID/home_presence/.* {}\
  homeassistant/.+?/config:.* {}
attr DEVICE setList\
  restart:noArg $\DEVICETOPIC/commands/MQTTtoSYS/config {"cmd":"restart"}\
  update { my $payload = $EVENT; $payload =~ s/$EVTPART0 //; qq($\DEVICETOPIC/commands/firmware_update $payload) }
option:global
attr DEVICE stateFormat <a href="http://Sys_ip" target="_blank">\
LWT\
</a>Version: version
attr DEVICE icon ICON
attr DEVICE comment For syntax wrt. update and BT commands see https://github.com/1technophile/OpenMQTTGateway/releases/tag/v0.9.7
attr DEVICE devStateIcon online:10px-kreis-gruen offline.*:10px-kreis-rot
attr DEVICE model OpenMQTTGateway_MCU
setreading DEVICE attrTemplateVersion 20220307
{ AttrTemplate_Initialize() }
Damit sollte der "Bedarf" für das "scanner"-Device eigentlich entfallen?

Und hier noch der ungetestete Versuch für den gtag. Die Readings sind vereinfacht, eigentlich interessiert einen ja nur, wo das letzte Mal was empfangen wurde und wie die unterschiedlichen RSSI-Werte pro GW so sind... (ungetestet)

Code Auswählen Erweitern

name:OpenMQTTGateway_BT_gtag
prereq:{my @devices=devspec2array("model=OpenMQTTGateway_MCU");return 1 if $devices[0];return 0}
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*/O[^/]*M[^/]*G[^/]*/.*
desc:For detection of a bluetooth precence dongle like the gtag via OpenMQTTGateway. 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 gtag. Best start with looking at what "OpenMQTTGateway_MCU" 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_02a1
par:ICON;ICON as set, defaults to rfid_tag;{ AttrVal('DEVICE','icon','rfid_tag') }
par:BT_ID;Pls. enter your bluetooth device ID; {return}
par:BASE_ID;BASE_ID typically is home;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m<([^:]+)/O[^/]*M[^/]*G[^/]*> ? $1 : undef }
par:DEV_TPC;base and device name in the topic;{ my $dt =  AttrVal('DEVICE','devicetopic',undef); defined $dt ? $dt : AttrVal('DEVICE','readingList','') =~ m<([^:]+/O[^/]*M[^/]*G[^/]*)/LWT> ? $1 : undef }
par:NEWDEVROOM;Room of the calling device; {AttrVal('DEVICE','room','MQTT2_\DEVICE')}
defmod OMG_BT_ID MQTT2_\DEVICE BT_ID
#attr OMG_BT_ID readingList READINGLISTOLD
deletereading -q OMG_BT_ID (?!associatedWith|IODev).*
attr OMG_BT_ID devicetopic DEV_TPC
attr OMG_BT_ID autocreate 0
attr OMG_BT_ID readingList\
  BASE_ID/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT/BT_ID:.* { $EVENT =~ m,characteristic...0x2a19.*read[^\d]+([\d]+), ? return { batteryPercent => hex($1) } : $TOPIC =~ m,home/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT,; my $rets = json2nameValue($EVENT); $rets->{last_IO} = $1, $rets->{"rssi_$1"} = $rets->{rssi}; return $rets}
attr OMG_BT_ID getList batteryPercent:noArg batteryPercent { my $id = ReadingsVal($NAME,'id','BT_ID'); qq($\DEVICETOPIC/commands/MQTTtoBT/config {"ble_read_address":"$id","ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX"}) }
attr OMG_BT_ID setList beep:noArg { my $id = ReadingsVal($NAME,'id','BT_ID'); qq($\DEVICETOPIC/commands/MQTTtoBT/config {"ble_read_address":"$id","ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX","immediate":true}) }
attr OMG_BT_ID event-on-change-reading .*
attr OMG_BT_ID event-min-interval .*:300
attr OMG_BT_ID icon ICON
attr OMG_BT_ID stateFormat Last IO: last_IO
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_gtag
set DEVICE attrTemplate set_IODev_in_channels SUBCHANNELS=OMG_BT_ID
setreading OMG_BT_ID attrTemplateVersion 20220307

Wäre klasse, wenn ihr eure Meinung dazu äußern könntet...

[MadMax-FHEM]

Es gibt übrigens bereits wieder eine aktualisierte Firmware .

FW bzgl. ESP?
Ich schaue mal...

Da jetzt aber scheinbar doch ein paar Nutzer da sind, hier mal der Versuch, das mit einer Auswahl-Option zu versehen, so dass alle "BT-Readings" direkt im GW "eingefangen" werden, da aber nicht triggern, und v.a. auch alle BT-Kommandos direkt im jeweiligen GW separat verfügbar sind, so dass die direkten publishes nicht mehr erforderlich sein sollten.

...

Damit sollte der "Bedarf" für das "scanner"-Device eigentlich entfallen?

...

Wäre klasse, wenn ihr eure Meinung dazu äußern könntet...

Ok, dann packe ich meinen noch rumliegenden ESP noch mal aus...
...und spiele das/die attrTemplate mal auf meinem Testsystem ein...

Kann aber etwas dauern...

Gruß, Joachim

[MadMax-FHEM]

Code Auswählen Erweitern

defmod OMG_a1a2a3a4a5a6.N notify (OMG_a1a2a3a4a5a6:weight:.*) {\
my $w = $EVTPART1;;\
if    ($w >= 30 && $w <  60) { fhem("setreading $NAME weight_person1 $w");;}\
elsif ($w >= 60 && $w <  85) { fhem("setreading $NAME weight_person2 $w");;}\
elsif ($w >= 85 && $w < 100) { fhem("setreading $NAME weight_person3 $w");;}\
else { fhem("setreading $NAME weight_unknown_person  $w");;}\
}

Das sollte auch so gehen (eine Zeile gespart   ):

Code Auswählen Erweitern

defmod OMG_a1a2a3a4a5a6.N notify (OMG_a1a2a3a4a5a6:weight:.*) {\
if    ($EVTPART1 >= 30 && $EVTPART1 <  60) { fhem("setreading $NAME weight_person1 $EVTPART1");;}\
elsif ($EVTPART1 >= 60 && $EVTPART1 <  85) { fhem("setreading $NAME weight_person2 $EVTPART1");;}\
elsif ($EVTPART1 >= 85 && $EVTPART1 < 100) { fhem("setreading $NAME weight_person3 $EVTPART1");;}\
else { fhem("setreading $NAME weight_unknown_person  $EVTPART1");;}\
}

Und eigentlich auch ohne die runden Klammern:

Code Auswählen Erweitern

defmod OMG_a1a2a3a4a5a6.N notify OMG_a1a2a3a4a5a6:weight:.*

Gruß, Joachim

[Beta-User]

FW bzgl. ESP?

Ja. Update für Eilige (hier: esp32dev-ble-firmware.bin) geht von FHEM aus mit:

Code Auswählen Erweitern

set <omg> update { "version": "test", "password": "OTAPASSWORD", "url": "https://github.com/1technophile/OpenMQTTGateway/releases/download/v0.9.11/esp32dev-ble-firmware.bin" }


Ok, dann packe ich meinen noch rumliegenden ESP noch mal aus...

Du kannst auch einfach dein vorhandenes GW "clonen" (einfach einen anderen Namen geben), und dann darauf das attrTemplate anwenden.

Entsprechendes gilt für den gtag etc.. Da das Namensschema "hartcodiert" ist, einfach die vorhandenen Devices umbenennen, dann kann man gefahrlos neue M2D-Instanzen anlegen.



Was das notify angeht: Falls das bei jemand nicht ganz so akkurat paßt, könnte man hergehen und schauen, zu welcher "Person" denn eine Messung die geringste Differenz hat und das dann da zuordnen... Dann noch Initialwerte setzen.

[ares]

Danke für die Zusammenfassung, mal sehen, was/wie man ggf. was ins Wiki übernehmen kann.

Es gibt übrigens bereits wieder eine aktualisierte Firmware .
Bei mir läuft "schon immer" diese hier: esp32dev-ble-firmware.bin. Vermutlich würde es Sinn machen, wenn wir uns auf eine Art Standard verständigen könnten (zumindest, was die Empfehlung an Einsteiger angeht).

Wäre klasse, wenn ihr eure Meinung dazu äußern könntet...

Die neue Firmware hat alle meine Probleme gelöst und ich kann nun auch die normale Version nutzen.
Die Zusammenfassung habe ich daher angepasst.

Das sollte auch so gehen (eine Zeile gespart   ):

Stimmt, aber für mich war die Version mit der zusätzlichen Variable leserlicher. Ich habe den Notify oben auch nochmal angepasst, da jetzt zusätzlich übertragen wird ob überhaupt eine Person gewogen wurde.

[DigiH]

Hallo zusammen,

bin hier über den Thread gestolpert und habe mich dann gleich mal angemeldet, da sich hier ein paar Bekannte aus den letzten Tagen tummeln - Hallo @kroman von github und Hallo @ares vom OMG Forum 

Ich habe zwar von FHEM (noch) überhaupt keine Ahnung, bin aber ein sehr passionierter OpenMQTTGateway User und auch für die neuen Xiaomi Mi Scale Decoder verantwortlich.

Falls ich also diesbezüglich irgendwelche offenen Fragen klären kann, sehr gerne. Und wie das ganze dann auf der FHEM Seite von euch realisiert wird ist für mich auch sehr spannend.

Gruß

[Beta-User]

Dann mal willkommen hier im FHEM-Forum!

Vorab mal: Hut ab, was die Integration der BT-Geschichten angeht, ich nutze v.a. die "eckigen" Xiaomis, aber es gibt ja eine unglaublich schnell wachsende Zahl von Gadgets, die über BT auch gesteuert werden können. Bin ziemlich sicher, dass hier bald der eine oder andere nachfragt, wie das z.B. mit den SwitchBot oder den Ledvance-BT-Leuchten geht, und die BT-Thermostate von eQ-3 sind sicher auch interessant wegen der Wochenprofil-Option (sowas kann man von FHEM aus auch zentral in gemischten Umgebungen verteilen, wenn man (für die equiva) denn wüßte, wie das Format für OpenMQTTGateway sein müßte).

FHEM selbst ist recht flexibel in der Auswertung dessen, was geliefert wird - falls du dich in FHEM Einarbeiten willst, ist diese Ecke allerdings eher eine der schwierigeren...

@all: Der überarbeitete attrTemplate-Satz ist im svn und kommt ab heute per update, die Beschreibungen muss ich mir allerdings ggf. nochmal ansehen... Viel Spaß damit!

[DigiH]

Dann mal willkommen hier im FHEM-Forum!

Danke

Bin ziemlich sicher, dass hier bald der eine oder andere nachfragt, wie das z.B. mit den SwitchBot oder den Ledvance-BT-Leuchten geht, und die BT-Thermostate von eQ-3 sind sicher auch interessant wegen der Wochenprofil-Option, ... wenn man denn wüßte, wie das Format für OpenMQTTGateway sein müßte.

Bei OpenMQTTGateway ist es wichtig zu unterscheiden, ob Geräteinformationen über regelmäßig gesendete manufacturerdata und/oder servicedata ausgelesen werden können, oder ob eine READ/WRITE Verbindung zu einem Gerät hergestellt werden muss, um Werte auszulesen, bzw. zu schreiben.

Bei der ersten Option - wie zum Beispiel bei den Xiaomi Mi Waagen, den eckigen Thermometern oder allen anderen Geräten für die bis jetzt ein Device Decoder in OpenMQTTGateway implementiert wurde (https://theengs.github.io/decoder/) - ist es nicht zu schwierig neue Decoder zu erstellen, soweit man Benutzer dieser Geräte findet, die einem manufacturerdata/servicedata zusammen mit Vergleichswerten des Gerätes geben können.

Habt ihr solche BT Geräte, für die noch kein Decoder implementiert ist, nur her mit den Informationen

Braucht es jedoch einen READ oder WRITE Vorgang, um einen Grätestatus abzufragen oder neue Werte zu schreiben, wird es etwas involvierter. Ein erster Anfang ist hier mal in den Standard uuid Werten der Bluetooth SIG nachzuschauen (https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf). Durchsucht man z. B. das PDF nach 'Battery' findet man schnell den Service und die Characteristic um für jedes BT Gerät, das sich an den Standard hält und nicht eigene uuid Belegungen implementiert, den Batteriestaus abzufragen.

{"ble_read_address":"AA:BB:CC:DD:EE:FF","ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX","immediate":true}

Sind gerätespezifische READ/WRITE Aktionen nötig ist dann oft gatttool, BLE scanning Apps, Wireshark sniffing oder eine Web-Suche nach schon vorhandenen Reverse-Engineering Funden gefragt.

So z.B auch für den von dir genannten SwitchBot. Habe ich selbst nicht, aber funktioniert wohl mit

{"ble_write_address": "AA:BB:CC:DD:EE:FF", "ble_write_service": "0d00", "ble_write_char": "0002", "ble_write_value": "570100", "value_type": "HEX", "ttl": 4, "mac_type":1, "immediate": true}

Für die eQ-3 BT-Thermostate scheint es auf Github auch schon alle Informationen zu geben.

Benötigt ein Gerät dabei ein vorheriges Pairing oder ist die Kommunikation verschlüsselt sind solche READ/WRITE Verbindungen in OpenMQTTGateway (bis jetzt) noch nicht möglich.
[/quote]

FHEM selbst ist recht flexibel in der Auswertung dessen, was geliefert wird - falls du dich in FHEM Einarbeiten willst, ist diese Ecke allerdings eher eine der schwierigeren...

Da ich ein anderes Backend hier benutze, und über die Jahre zig-tausende Zeile Code dafür geschrieben habe, damit das Heim so funktioniert wie es soll, ist ein Umstieg in näherer Zukunft erstmal unwahrscheinlich aber man weiß ja nie ...

[Beta-User]

Bei OpenMQTTGateway ist es wichtig zu unterscheiden, ob Geräteinformationen über regelmäßig gesendete manufacturerdata und/oder servicedata ausgelesen werden können, oder ob eine READ/WRITE Verbindung zu einem Gerät hergestellt werden muss, um Werte auszulesen, bzw. zu schreiben.

Danke für die ausführliche Antwort, zwischenzeitlich habe ich in etwa ein Bild, wie das funktioniert.

Habt ihr solche BT Geräte, für die noch kein Decoder implementiert ist, nur her mit den Informationen

Bin mal gespannt, was da zusammenkommt . Mein eigener Bedarf ist erst mal gedeckt...

So z.B auch für den von dir genannten SwitchBot. Habe ich selbst nicht, aber funktioniert wohl mit

{"ble_write_address": "AA:BB:CC:DD:EE:FF", "ble_write_service": "0d00", "ble_write_char": "0002", "ble_write_value": "570100", "value_type": "HEX", "ttl": 4, "mac_type":1, "immediate": true}

Auf https://github.com/1technophile/OpenMQTTGateway/releases/tag/v0.9.9 ist noch eine etwas andere Schreibweise zu lesen, vermutlich war das mit ein Grund, warum wir wegen der Batterie-Geschichte erst mal gerätselt haben...

Aber das sollte beinahe ausreichen, um mal "pro forma" auch dafür ein attrTemplate bereitzustellen (wobei es sinnvoll wäre, vorab wenigstens einen "Rückmelde-JSON" und einen "Status-JSON" zu haben, damit das in "FHEM-kompatible" Readingnamen und -werte übersetzt werden kann...)

Für die eQ-3 BT-Thermostate scheint es auf Github auch schon alle Informationen zu geben.

Sehe ich ähnlich, wobei es für mich immer wieder eine größere Herausforderung ist, sowas dann strukturiert in eine Form zu bringen, die allgemein nutzbar ist. Erfahrungsgemäß versuchen die unerfahrensten User die kompliziertesten Dinge und erwarten dann Hilfe auf Hellseher-Niveau ...
Von den eher erfahreneren scheinen viele das separate Modul (für "normale" BT-Dongles) zu benutzen, und der dortige Maintainer hat sich bisher nicht für die "OMG-Variante" begeistern können...

Da ich ein anderes Backend hier benutze, und über die Jahre zig-tausende Zeile Code dafür geschrieben habe, damit das Heim so funktioniert wie es soll, ist ein Umstieg in näherer Zukunft erstmal unwahrscheinlich aber man weiß ja nie ...

Geht mir andersrum auch nicht viel anders, vollstes Verständnis . Es klang erst mal nur so, als wolltest du ggf. "sehen", was FHEM mit den empfangenen Daten macht.

[DigiH]

Auf https://github.com/1technophile/OpenMQTTGateway/releases/tag/v0.9.9 ist noch eine etwas andere Schreibweise zu lesen, vermutlich war das mit ein Grund, warum wir wegen der Batterie-Geschichte erst mal gerätselt haben...

Beide Schreibweisen, 16 bit oder 128 bit uuids sollten eigentlich korrekt funktionieren. Ob die Tatsache, dass bei manchen Geräten für manche Service/Characteristic Kombinationen nur die 16 bit Varianten funktionieren an den Geräten liegt, oder noch ein kleiner Bug in der NimBLE Library steckt ist abzuwarten Bei dem SwitchBot Beispiel sollte es auch wunderbar mit den 128 bit uuids klappen.

[ares]

@all: Der überarbeitete attrTemplate-Satz ist im svn und kommt ab heute per update, die Beschreibungen muss ich mir allerdings ggf. nochmal ansehen... Viel Spaß damit!

Gibt es inzwischen einen Langzeitplan und ich sollte meine Konfiguration löschen und neu anlegen bzw. überarbeiten?

Bei mir im MQTT2_SERVER ist das Reading RETAIN inzwischen sehr lang.
Ist das normal? Ist das wichtig oder kann man das irgendwie ausblenden?

Falls ich also diesbezüglich irgendwelche offenen Fragen klären kann, sehr gerne.

Nach einem Ab- und Anstecken des ESP32 werden ganz kurz einige Geräte zusätzlich übertragen, obwohl es eine white-list gibt.

Code Auswählen Erweitern

set MQTT2_FHEM_Server publish -r home/OMG1/commands/MQTTtoBT/config {"white-list":["a1:a2:a3:a4:a5:a6"]}
Wird die white-list am OMG erst verzögert aktiviert und bei Booten wird vorübergehend mehr gesendet?