Hallo zusammen,
nachdem ich am WE zum ersten Mal ein update via MQTT angeschubst habe, und auch bei "geeignete Temperatursensoren (https://forum.fhem.de/index.php/topic,125566.msg1205089.html#msg1205089)" 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
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...
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
:) 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...
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
..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 :) .
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
:) 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.
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
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.
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
:) 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...
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
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
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
Hab's mal mit einem Eintrag in getList probiert. Leider ohne Erfolg:
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
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.
ZitatKann 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.
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:
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:
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:
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:
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}
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
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:
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:
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:
;;;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.
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
Zitat von: Beta-User am 02 März 2022, 14:46:15
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
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:
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
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".
Zitat von: Beta-User am 03 März 2022, 15:12:02
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
Zitat von: DeeSPe am 03 März 2022, 14:55:51
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:
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
Zitat
Soweit ich verstanden habe können die Batteriewerte nur bei einem (kurzzeitigem) Connect übermittelt werden.
Zitat
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
Zitat
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.
Zitat
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:
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:
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" :(
Zitat
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
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
Zitat von: ares am 04 März 2022, 11:52:54
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).
ZitatWas 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.
ZitatWenn 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 ::) .
Bezüglich Gigaset G-Tag wurde mir auf github geholfen.
So funktionierts (doch mit HEX):
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}
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
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 8)
EDIT: meiner hat noch etwas mehr "Saft" ;)
Gruß, Joachim
:) ...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 ::) ...
Mein Espressif ESP32 Dev Kit ist endlich angekommen und nachdem ich den Windows-Treiber (Google) installiert habe wurde er auch mit COM-Port im Geräte-Manager angezeigt.
Die Installation von https://docs.openmqttgateway.com/upload/web-install.html direkt aus dem Browser ohne zusätzliche Software war genauso einfach wie die Konfiguration per Smartphone. Ich habe nur den WiFi-Zugang und MQTT2_SERVER eingetragen und als Gateway-Name "OMG_ESP32_BLE_1" verwendet.
In fhem habe ich nur den Server erstellt:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global
Automatisch angelegt wurde ein MQTT2_DEVICE "MQTT2_OMG_ESP32_BLE_1"mit FileLog. Soweit war das auch für mich noch einfach.
Nun zu meinen Fragen:
(1) Was mir nicht gefällt ist, dass ich nun permanent die config speichern soll oder das nicht mache und damit sicher später irgendwann vergesse zu speichern. Kann das Speichern für das Device irgendwie auf "automatisch" gestellt werden?
(2) Die readingList zeigt nicht nur Einträge mit home/ an, sondern immer mehr Einträge mit homeassistant/ und dort mit diversen MAC-Adressen. Ist das normal?
(3) Wie mache ich weiter?
set QTT2_OMG_ESP32_BLE_1 attrTemplate OpenMQTTGateway_MCU
Oder wo finde ich den Faden wieder zum weiter machen?
Viele Grüße
Manfred
Expressantworten:
ad 1) automatisch speichern sollte man m.E. NIE.
Hier ist das "Problem", dass ständig die readingList erweitert wird, sobald ein neues BT-Gerät in Reichweite kommt.
ad 2) ad homeassistant siehe "ignoreRegexp" beim Wiki zu MQTT2_CLIENT
ad 3) Genau, mit dem "mcu"-attrTemplate. Das fängt dann auch das ständige "autocreate"/save-"Problem" ab.
Für das Vorgehen, auch danach, bitte in den FHEM-Wiki-Artikel zu OMG schauen und ggf. Vorschläge machen, wenn da was unklar sein sollte.
Zitat von: Beta-User am 05 März 2022, 11:20:00
:) ...funktioniert auch ohne "jetzt".
Bei mir nicht. Mit dem binary schon, da AttemptBLECOnnect defaultmäßig auf true steht.
Zitat
Jetzt stellen sich halt eine ganze Reihe von Fragen, wie man das ganze sinnvoll verwertet...
Falls jemand Ideen (=Code) hat: her damit ::) ...
Bevor ich an FHEM rangehe, werde ich mir den OMG selber und die Parameter im source code noch genauer anschauen.
Zitat von: ares am 05 März 2022, 12:46:15
Nun zu meinen Fragen:
Nachdem du das MCU template angewandt hast, sollte sich in der readingList nach ein paar Minuten eigentlich nichts mehr ändern. Hier gibt es bei mir nur 1 MAC Adresse, nämlich die vom ESP selber.
Die unerwünschten MAC Adressen im scanner wirst du mit z.B.
set mqtt2server publish -r home/OMG1/commands/MQTTtoBT/config {"white-list":["AA:AA:AA:AA:AA:AA","BB:BB:BB:BB:BB:BB","CC:CC:CC:CC:CC:CC"]}
los. Durch -r (retain) speichert das der MQTT2 server und verschickt die whitelist nach power off/on des ESPs automatisch wieder an den ESP.
Das ist ohnehin empfehlenswert um auch den ESP zu entlasten.
Zitat von: Beta-User am 05 März 2022, 13:12:51
Für das Vorgehen, auch danach, bitte in den FHEM-Wiki-Artikel zu OMG schauen und ggf. Vorschläge machen, wenn da was unklar sein sollte.
Happy über den ersten Erfolg habe ich erstmal alles vergessen was ich schon gelesen und nicht verstanden habe. Der Hinweis auf den FHEM-Wiki-Artikel hat geholfen und ich habe nochmal mit Gateway-Name OMG1 von vorne angefangen.
(1) Das Device zeigt mir nun grün "Online" und die Version an. Beim Klick auf den grünen Kreis wird versucht, die Website des OMG1 zu öffnen, die aber in meiner Verison v0.9.10 nicht erreichbar ist.
(2) Nach dem Hinweis "BT-scanner-attrTemplate" bei oMQTTgw_BT hab ich dann noch ein Template benutzt, auch wenn das NICHT so schön wie bei der Einführung dabei steht obwohl der Name hier ja vorgegeben wär.
set MQTT2_oMQTTgw_BT attrTemplate OpenMQTTGateway_BT_scanner
Edit: eventuell passt das ja hier schon nicht, da dauerhaft "Last: last" im STATE angezeigt wird.
(3) Danach habe ich meine Waage hinzugefügt:
set MQTT2_OMG1 attrTemplate OpenMQTTGateway_BT_scale 70879E4C3B50Da das nicht funktioniert habe ich das Try&Error nochmal so versucht:
set MQTT2_oMQTTgw_BT attrTemplate OpenMQTTGateway_BT_scale 70879E4C3B50Beides liefert kein Gewicht im Device OMG_70879E4C3B50, im Reading 70879E4C3B50_servicedata von MQTT2_oMQTTgw_BT finde ich aber den korrekten, jedoch nicht dekodierten Inhalt "a26248e60703050e330f".
Wo stelle ich mich derzeit noch zu doof an?
Edit: eventuell war "esp32dev-ble" (BLE gateway with one scan every 55s per default) falsch?
Viele Grüße
Manfred
Also ich hab ja auch versucht whitelist zu setzen...
...aber irgendwie "ignoriert" das mein Scanner (bzw. beide Scanner)... :-\
Da muss ich wohl noch ein wenig "üben", bevor das "produktiv" gehen kann.
Plan (wenn schon nicht mein Smartphone damit und auch nicht mit https://espresense.com/ "erfasst" bekomme): einen Raspberry PI ZeroW weg, der aktuell meine FlowerSense "überwacht"...
...und einen ESP32 für meine Waage.
Ansonsten sollen die nicht so viel "rumscannen"...
Gruß, Joachim
Zitat von: MadMax-FHEM am 05 März 2022, 15:13:13
...und einen ESP32 für meine Waage.
Da bist Du weiter als ich gekommen. Bei mir kommen in MQTT2_oMQTTgw_BT nur die richtigen RAW-Daten an und im Device danach nichts mehr. Ich bin daher kurz davor das selbst aus oOMQTTgw_BT abzugreifen und umzurechnen. Wenn das aber der Fall ist, dann kann ich das aber auch gleich am ESP32 machen und spare mir die Whitelist. Bei OpenMQTT ist mein Frustfaktor nämlich aktuell sehr hoch nachdem ich seit Stunden rate und nicht weiter komme.
Viele Grüße
Manfred
Hast du das Erzeugen per WebCmd selbst eingegeben oder per DropDown beim "Scanner-Device"?
Ich habe auch (erst mal) nichts umbenannt...
Bzw. per attrTemplate habe ich es noch gar nicht versucht.
Kann ich ja mal machen.
Ich war ja noch bevor es ein attrTemplate gab.
Meine Basis war FlowerIrgendwas und dann eben angepasst (siehe zu Beginn des Threads)...
Gruß, Joachim
Zitat von: MadMax-FHEM am 05 März 2022, 16:14:43
Hast du das Erzeugen per WebCmd selbst eingegeben oder per DropDown beim "Scanner-Device"?
Ich habe glaube ich schon beides versucht, das sollte aber aus meiner Sicht keinen Unterschied machen.
Ich kann gerne erneut alles löschen und dann alle Eingaben protokollieren, falls das hilft.
Mir kommt derzeit das "Last: last" im STAT von MQTT2_oMQTTgw_BT merkwürdig vor.
70879E4C3B50_servicedata hab ich manuell dekodiert und der Inhalt ist korrekt. Ich denke, der ESP32 sollte weight schon berechnen und übermitteln, aber wo geht das auf dem Weg verloren?
setstate MQTT2_oMQTTgw_BT 2022-03-05 16:17:50 70879E4C3B50_id 70:87:9E:4C:3B:50
setstate MQTT2_oMQTTgw_BT 2022-03-05 16:17:50 70879E4C3B50_mac_type 0
setstate MQTT2_oMQTTgw_BT 2022-03-05 16:17:50 70879E4C3B50_manufacturerdata 570170879e4c3b50
setstate MQTT2_oMQTTgw_BT 2022-03-05 16:17:50 70879E4C3B50_name MI SCALE2
setstate MQTT2_oMQTTgw_BT 2022-03-05 16:17:50 70879E4C3B50_rssi -59
setstate MQTT2_oMQTTgw_BT 2022-03-05 16:17:50 70879E4C3B50_servicedata a24e48e607030510040aSteht das Gewicht bei Dir leserlich in MQTT2_oMQTTgw_BT?
Wenn Du ein Testsystem hast, kannst Du dann den ESP32 ausstecken, alles in fhem löschen und nochmal starten? Ich denke, das Gewicht sollte schon im MQTT2_oMQTTgw_BT stehen bevor Du die Waage anlegst, da bei anderen Geräte ja auch schon battery zu sehen ist ohne dass ich mit diesen etwas gemacht hätte.
Und ich dachte anfangs, die Waage läuft und ich muss mich nur mit dem Mi Band 6 meiner Tochter ärgern, da sie ihre Schritte in SmartVisu sehen möchte. Da sehe ich dann aber erstmal nur noch Fragezeichen auf mich zukommen.
Viele Grüße
Manfred
Edit: Erreichst Du Deinen ESP32 beim Klick auf den grünen Kreis vor der Vrsionsnummer?
Also meine Schritte sind eingangs im Thread genau beschrieben (oder auch per PM an dich?), hier noch mal kurz.
ESP mit fertigem Image geflasht (esp32dev-ble).
Dann nur WLAN settings und mqttserver-IP und Port (PW usw. habe ich nicht, also beim MQTTServer).
Dann wurde ein Device angelegt -> attrTemplate OpenMQTTGateway_MCU
Dann kam ein weiteres Device -> attrTemplate OpenMQTTGateway_BT_scanner
KEINE NAMEN ANGEPASST usw.
Also heißt mein Gateway-Device: MQTT2_OpenMQTTGateway_ESP32_BLE
Und mein Scanner: MQTT2_oMQTTgw_BT
Dann wie vorne zu lesen...
...bzw. eben Waage gelöscht und neu über den Scanner angelegt: passt.
Ja das Gewicht weight und auch impedance kommen bei mir im Scanner schon entsprechend an inkl. Angabe der Unit (kg).
Noch mal alles löschen etc. muss ich mal sehen, es ist zwar ein Testsystem ja aber das kostet Zeit...
Ich werde wohl erst noch ein wenig rumüben aber sicher noch mal neu von vorne bevor ich das auf mein Hauptsystem kippe.
(wobei ich ja ehrlich gesagt von dem ganzen mqtt Datenflutzeugs noch nicht so überzeugt bin :-\ einmal wo was falsch angepasst oder umbenamst oder was auch immer und das ganze System dreht ab / zumindest momentan mein Gefühl / vielleicht wird das ja noch, wenn ich mal länger damit "rumspiele")
EDIT: aber solange ich das mit whitelist nicht in den Griff bekomme werde ich erst mal nichts auf mein Hauptsystem lassen. Und wenn ich das nicht (sauber) hinkriege, dass ich 2 BTLEGateways sauber "auseinander" kriege (also einen der NUR die Waage macht und einen der NUR meine FlowerSense macht) kommt mir max. die Waage in mein Hauptsystem (zur Not auch ohne whitelist aber schöner wäre mit)...
Hier noch die Daten meiner Waage:
Zitat
model Miscale_v2
model_id XMTZC05HM
Gruß, Joachim
Hmm, also, ein paar kurze Anmerkungen:
- mit white-/blacklist habe ich mich bisher nicht groß befasst;
- der "Datenfluss" ist auch kein großes Geheimnis: im Prinzip wird immer nur in jedem Gerät jeweils der JSON ausgepackt, unterschiedlich ist nur die Methode, wie die "Präfixes" ermittelt werden. Umgerechnet wird bisher gar nicht, der Batterie-Wert wäre dazu eine Art Prototyp.
Wenn also die 2. "Scale" nur Rohdaten liefert, kann man entweder in der Tat den Code für die firmware ergänzen und ggf. einen Patch einreichen, oder man muss eben selbst rechnen (hier vermutlich am einfachsten per userReading).
Der "scanner" war bis vor kurzem mal triggernd, daher wurde dann auch das "last" ermittelt. Wie irgendwo hier geschrieben bin ich im Moment nicht sicher, ob/wie man den scanner eigentlich künftig gestalten soll...
Ich habe dasselbe Image, auf Deinen Rat hin ebenfalls noch kein Passwort und nur den Gateway-Namen im ESP32 auf OMG1 geändert, damit das kürzer ist und erweiterbar ist.
Das Löschen und neu anlegen geht recht fix, habe ich eben nochmal gemacht:
(1) alles zu MQTT außer MQTT2_SERVER bei abgestecktem OMG1 in fhem gelöscht
(2) OMG1 mit Strom versorgt
(3) Template auf automatisch erstelltes Device angewendet
set MQTT2_OMG1 attrTemplate OpenMQTTGateway_MCU
(3) Template auf zweites automatisch erstelltes Device angewendet
set MQTT2_oMQTTgw_BT attrTemplate OpenMQTTGateway_BT_scanner
(5) OMG1 neu gestartet, danach Anzeige Version: v0.9.10
(6) einmal auf der MI SCALE2 gewogen
(7) in MQTT2_oMQTTgw_BT sind die Readings mit Raw-Daten, aber ohne Gewicht
(8) STATE von MQTT2_oMQTTgw_BT ist "Last: last"
(9) Klick auf den grünen Button im State: "Die Website ist nicht erreichbar"
Falls Du nochmal testest... Punkte 7-9 würden mich interessieren.
Zitat von: MadMax-FHEM am 05 März 2022, 16:38:45
...bzw. eben Waage gelöscht und neu über den Scanner angelegt: passt.
Laut wiki https://wiki.fhem.de/wiki/OpenMQTTGateway sollte das über das Gateway-Device und nicht über den Scanner laufen?
Wie legst Du das "Device Waage" genau an und ändert sich dann etwas in Punkt 7-9?
Was ändert die whitelist, wenn die Daten trotzdem erst ankommen und dann genau wie jetzt ignoriert werden?
model_id wird mir in fhem nicht angezeigt. Ich habe aber ebenfalls eine Xiaomi-MiScale2 und die RAW-Daten passen ja.
Meine ersten Gehversuche mit MQTT bzw. mit OMG waren ebenfalls nicht so überzeugend, ich hoffe das ändert sich noch.
Viele Grüße
Manfred
Zitat von: MadMax-FHEM am 05 März 2022, 16:38:45
aber solange ich das mit whitelist nicht in den Griff bekomme
Bei mir geht das problemlos.
Wie publishst du die whitelist?
Falls über den MQTT2 server, dann solltest du mit verbose 5 am MQTT2 server die Nachricht im fhemlog sehen, um mal zu kontrollieren, ob sie denn rausgeht.
Oder du wirfst wireshark an etc.
Zitat von: ares am 05 März 2022, 17:02:36
Was ändert die whitelist, wenn die Daten trotzdem erst ankommen und dann genau wie jetzt ignoriert werden?
Mit der whitelist kommen sie dann eben nicht mehr an.
7: Das scheint an dem abweichenden Modell zu liegen => bei OMG einkippen
8: event-on-Attribut löschen, dann wird "last" erzeugt (s.o.)
9: Das mit dem "grünen Punkt" ist eine Art default (kommend von Tasmota). Da das OMG nach dem Einrichten der Zugangsdaten zum WLAN/MQTT kein Web-Interface mehr hat, ist es halt funktionslos. M.E. kein Beinbruch, vielleicht ändert sich das bei OMG ja mal...
OMG ist eine eher schwierige Ecke, um sich in MQTT2_.* einzuarbeiten; wenn dann noch nicht voll unterstützte Geräte dazukommen, mag das frustrierend sein. Aber mit dieser Modulfamilie bekommt man wenigstens die Option, aus "was auch immer" an Infos verwertbare Readings zu generieren; mit MQTT_DEVICE wäre man an der Stelle jedenfalls noch viel mehr "lost", und JSON-Blobs damit zu versenden, ginge schon gleich gar nicht...
Zitat von: Beta-User am 05 März 2022, 17:17:42
7: Das scheint an dem abweichenden Modell zu liegen => bei OMG einkippen
Ich habe doch gar kein abweichendes Modell, sondern ebenfalls eine XIAOMI MI Smart scale 2.
Zitat von: Beta-User am 05 März 2022, 17:00:29
Wenn also die 2. "Scale" nur Rohdaten liefert, kann man entweder in der Tat den Code für die firmware ergänzen und ggf. einen Patch einreichen, oder man muss eben selbst rechnen (hier vermutlich am einfachsten per userReading).
Das Gewicht sollte bereits ermittelt werden.
https://compatible.openmqttgateway.com/index.php/devices/?383_attr_pa_brand%5B0%5D=39&383_product_cat%5B0%5D=51&383_orderby=option_2&383_device=laptop&383_filtered=true
Es gibt für Android auch eine App "nRF Connect" und die ist sicher universell, da damit alles dekodiert werden kann.
Wiege ich mich, wird mir dort das Gewicht mit 3 Nachkommastellen angezeigt, auch wenn die Waage nur 50g Genauigkeit hat.
Wenn Byte 1 $22 oder $a2 ist, dann wird das Gewicht in Kilogramm übertragen. Dazu sind die Bytes 3+2 nur durch 200 zu teilen.
Viele Grüße
Manfred
@ares: ich lege die Waage über das Scanner-Device an. Allerdings stehen bei mir die Daten ja schon "richtig" im Scanner-Device...
Das mit dem Web-Interface habe ich auch, also dass da nichts kommt. Unschön. Wenn man was ändern will, heißt das neu flashen (oder gibt's da andere Möglichkeiten?)...
EDIT: Scale 2 muss nicht unbedingt Scale 2 sein ;) Es gibt ja viele Scale 2. Ich habe beim Kauf extra auf XMTZC05HM geachtet. Es gab auch eine "neuere" aber da war nicht genannt welches Modell drum hab ich das mal gelassen... (und wohl auch ein älteres Modell)
@kroman: ich habe es über MQTT2Server probiert und direkt per mqtt_pub mittels verschiedener "Varianten" aber egal wie ich das absetze der Scanner scannt einfach munter weiter und liefert weiterhin alles...
Muss aber jetzt auch mal was anderes machen ;)
Gruß und danke, Joachim
Zitat von: MadMax-FHEM am 05 März 2022, 17:23:25
@ares: ich lege die Waage über das Scanner-Device an. Allerdings stehen bei mir die Daten ja schon "richtig" im Scanner-Device...
Jetzt hatte auch ich Glück und EINMAL ein Gewicht empfangen.
2022.03.05 17:36:27 5: in@192.168.0.160:52521 PUBLISH: 0(190)(1)(0)(31)home/OMG1/BTtoMQTT/70879E4C3B50{"id":"70:87:9E:4C:3B:50","mac_type":0,"name":"MI SCALE2","rssi":-74,"brand":"Xiaomi","model":"Miscale_v1","model_id":"XMTZC04HM","unit":"kg","weight":92.25}
2022.03.05 17:36:27 4: MQTT2_FHEM_Server_192.168.0.160_52521 OMG1 PUBLISH home/OMG1/BTtoMQTT/70879E4C3B50:{"id":"70:87:9E:4C:3B:50","mac_type":0,"name":"MI SCALE2","rssi":-74,"brand":"Xiaomi","model":"Miscale_v1","model_id":"XMTZC04HM","unit":"kg","weight":92.25}
2022.03.05 17:36:27 5: MQTT2_FHEM_Server: dispatch autocreate=simple\000OMG1\000home/OMG1/BTtoMQTT/70879E4C3B50\000{"id":"70:87:9E:4C:3B:50","mac_type":0,"name":"MI SCALE2","rssi":-74,"brand":"Xiaomi","model":"Miscale_v1","model_id":"XMTZC04HM","unit":"kg","weight":92.25}Aber eben nur einmal... bedeutet das, dass beim Wiegen nur hin und wieder das Gewicht aktualisiert wird, da das OMG macht was es will?
2022.03.05 17:40:49 5: in@192.168.0.160:52521 PUBLISH: 0(177)(1)(0)(31)home/OMG1/BTtoMQTT/70879E4C3B50{"id":"70:87:9E:4C:3B:50","mac_type":0,"name":"MI SCALE2","manufacturerdata":"570170879e4c3b50","rssi":-65,"servicedata":"a22648e6070305112909"}
2022.03.05 17:40:49 4: MQTT2_FHEM_Server_192.168.0.160_52521 OMG1 PUBLISH home/OMG1/BTtoMQTT/70879E4C3B50:{"id":"70:87:9E:4C:3B:50","mac_type":0,"name":"MI SCALE2","manufacturerdata":"570170879e4c3b50","rssi":-65,"servicedata":"a22648e6070305112909"}
2022.03.05 17:40:49 5: MQTT2_FHEM_Server: dispatch autocreate=simple\000OMG1\000home/OMG1/BTtoMQTT/70879E4C3B50\000{"id":"70:87:9E:4C:3B:50","mac_type":0,"name":"MI SCALE2","manufacturerdata":"570170879e4c3b50","rssi":-65,"servicedata":"a22648e6070305112909"}Anscheinend ist das damit nicht das Problem von fhem und lässt sich nur am OpenMQTTGateway bzw. durch Austausch lösen?
Damit bleibt eigentlich nur die Frage, ob bei Dir das Gewicht tatsächlich aktualisiert wird oder Du der Technik einfach vertraust und hoffst, dass das alte (kleinere) Gewicht noch aktuell ist.
Danke für eure Geduld
Manfred
So ich setzte noch mal neu auf.
Ziel ist ja 2 ESP. Einer für die FlowerSense und einer für meine Waage.
Würde ich nun EINEN Scanner für beides machen (ist ja standard, da ja der Scanner irgendwie zur Bridge-RegExp des Gateway-Devices passen, oder? Also einfach nur ändern ist nicht?)...
...oder je einen Scanner (also 2)?
Und wenn 2: wie müsste ich vorgehen (siehe Frage oben)?
Wenn 1 Scanner (auch ok), dann wird der ja mal von dem einen Gateway versorgt und u.U. mal von dem anderen, je nach Erreichbarkeit der Geräte (oder sehe ich das falsch)?
(und abgesehen davon, ob ich das mit whitelist nun hinkriege oder nicht 8) )
EDIT: aktuell vertraue ich noch gar nix was ;) Ich schaue nach dem Wiegen schon nach, ob das passt. Gewicht wird eigentlich immer aktualisiert. Was nicht immer mitkommt ist impedance. Sieht man aber (bei mir) an der Waage. Sie zeigt Gewicht an, dann kommen unten "Striche". Wenn die nur so bis zur Hälfte gehen, dann gibt es kein impedance, wenn sie durchlaufen, dann schon. (wenn ich mit [dicken] Socken drauf stehe kommt meist/nat. keine impedance)...
EDIT: ich habe aber das Scan-Intervall auf 15 runter gedreht. Vielleicht macht das was. Werde ich testen, sobald ich neu aufgesetzt habe (aktuell habe ich mit den FlowerSens angefangen)...
EDIT: wenn das mit dem kürzeren Intervall "muss", dann überlege ich entweder "selber zu bauen" (da kann man das einstellen?) oder den "Dauerscanner" zu nehmen (unschön)...
Gruß, Joachim
Zitat von: MadMax-FHEM am 05 März 2022, 17:55:28
Und wenn 2: wie müsste ich vorgehen (siehe Frage oben)?
So wie ich das verstehe kannst Du im Reading bridgeRegexp des zweiten OMG jederzeit einen Scanner Deiner Wahl angeben, also z.B. oMQTTgw_BT2
Edit: Ich habe die Version "nur Gewicht" ohne BMI, da mir die besser gefällt. Mir ist aber auch so klar, dass ich kein Sportler bin und benötige keine Bestätigung meiner Selbsteinschätzung von der Waage.
...ich versuch's nochmal:
Das jetzige attrTemplate-Set zu OMG ist mAn. nicht perfekt, sondern halt an der einen oder anderen Stelle "so na wora"!
Gut ist, dass
- autocreate nicht ständig neue Devices anlegt, sondern alles in EINEM scanner-Device landet, egal, ob man jetzt ein oder 10+ GW's im Einsatz hat; (und es macht m.E. keinen großen Sinn, das zu vervielfältigen, notfalls muss man halt den MQTT-Verkehr abhören um zu erkennen, wo was herkommt oder was ähnliches bauen wie bei den gtags, um das GW zu identifizieren; sonst könnte man auch diese Daten einfach erst mal direkt am GW belassen (ohne bridgeRegexp))
- an diesem "scanner"-Gerät erkennbar ist, was überhaupt "irgendwo" rumfleucht und automatisch dekodiert werden konnte. Es werden die Daten so angezeigt, wie OMG die liefert, nur die Reading-Namen sind so gestaltet, dass man sieht, zu welcher BT-Adresse die gehören;
Schlecht ist, dass
- die BT-Befehle an dem scanner angehängt sind. Die sollten an die MCU-Geräte. Das werde ich bei Gelegenheit umstellen (falls nicht jemand einen Vorschlag macht, den ich übernehmen kann).
Unklar ist mir noch, wie man am besten den Topic ermittelt für eine "getList", z.B. am gtag-Template. Das ist so gestaltet, dass man an den Readings erkennen kann, über welches GW das wie gut empfangen wurde. Ob diese Konstruktion "gut" ist, stelle ich ausdrücklich zur Diskussion. War eher mal eine Art Machbarkeitsstudie, eventuell fällt ja jemandem was besseres ein.
Wenn der Empfang grenzwertig ist, kann man übrigens auch eine externe Antenne anlöten; vielleicht verbessert das auch die Dekodierungsquote (wobei mir der Effekt komisch vorkommt).
Zitat von: Beta-User am 05 März 2022, 18:10:20
Wenn der Empfang grenzwertig ist, kann man übrigens auch eine externe Antenne anlöten; vielleicht verbessert das auch die Dekodierungsquote (wobei mir der Effekt komisch vorkommt).
ESP32 und Waage sind während meiner Versuche immer nur knapp 2m ohne Hindernisse entfernt gewesen und das Gewicht wurde nur einmal zufällig gesendet, als ich zum Glück VERBOSE höher eingestellt hatte. Die Daten kommen auch zuverlässig an, nur sendet das Gateway imho die falschen Telegramme an fhem.
Da fhem keinen Einfluss auf die Telegramme hat bleibt also für morgen nur noch der Plan, eine andere Firmware zu versuchen.
PS: Löten kann ich ohnehin nur dicke Kabel und auf keinen Fall auf Platinen!
@Beta-User: also ich bin eigentlich ganz zufrieden! :)
Das mit dem Scanner/Sammler ist doch i.O.! :)
(und ja gut, ein Scanner reicht dann)
Aktuell teste ich mal mit den FlowerSens rum.
Gefühlt brauche ich da aber wohl einen "Dauerscanner" also espdev-bt-con?
(da ist das nicht so wild? die sind nur im Sommer in Betrieb und den ESP kann ich ja auf dem Balkon lassen)
Bei der Waage wollte ich das eigentlich nicht aber mit Interval von 15 hat das prima geklappt, vielleicht kann das auch weg, also alle 55s (Standard).
Einzig das mit whitelist wäre noch prima! :)
Jetzt ist aber erst mal Schluss (für heute)...
EDIT: ok meine FlowerSens kann ich wohl "vergessen". Da ist die FW wohl zu alt... Und extra App installieren und anlernen nur für FW-Update, hmmm, nö. Die laufen ja (noch) prima mit dem RaspberryPI ZeroW und dem FlowerSense-Modul :) Aber die Waage wandert ins Hauptsystem :) Whitelist muss ich halt mal sehen...
EDIT: whitelist geschafft! :) "Fehler" war, dass das fhem Device (also BTGateway) (immer) MQTT2_ vorne dran packt. Das Topic aber nur der Name OHNE MQTT2_ ist... Wie geschrieben: wenn man weiß wie wo was ist es schon "ok" ;) Jetzt aber ab auf das Hauptsystem!! :) DANKE!!
Gruß, Joachim
Zitat
EDIT: whitelist geschafft!
Super! Dafür, dass du schon länger etwas anderes machen wolltest, bist du eh sehr fleißig ;D
Hallo Beta-User,
ich habe in meinem G-Tag device die readingList damit erweitert:
home/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT/7C2F80C390FF:.* { $TOPIC =~ m,home/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT,; {"battery"=>hex(ReadingsVal("$NAME","${1}_read",0))}}
Das könnte man so ins mqtt2.template einbauen:
BASE_ID/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT/BT_ID:.* { $TOPIC =~ m,BASE_ID/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT,; {"battery"=>hex(ReadingsVal("$NAME","${1}_read",0))}}
Wobei ich den reading Namen so gewählt habe, dass ihn die readingsGroup für den Batteriestatus gleich einfängt.
Aber gut, man kann ihn ja bei Bedarf einfach ändern.
Was mir hier nicht gefällt und ich auch nicht weiß ob/wie man das anders machen kann ist, dass sich der Zeitstempel dieses neuen readings immer updated sobald ein anderes Reading in diesem device upgedated wird, was ja je nach scan_interval bei mir alle paar Sekunden der Fall ist. Das passiert obwohl sich der Zeitstempel des initialen Batteriereadings (z.B. OMG1_read) nicht ändert, da ich den Batteriestatus ja auch gerade nicht abfrage.
Gleiches Verhalten ergibt sich bei Verwendung eines userReadings ohne trigger, z.B.:
battery {hex(ReadingsVal("$name","OMG1_read",0))}
Mit diesem userReadings passt der Zeitstempel:
battery:OMG1_read:.* {hex(ReadingsVal("$name","OMG1_read",0))}
Ich denke ich werde den Batteriestatus 1x täglich mit einem at auf das set mqtt2server publish commando abfragen, zumindest fällt mir momentan nichts besseres ein.
Da muss ich aber noch ein bisschen testen und je nach Antwort einen retry einbauen, denn da hab ich am ESP schon Kollisionen gesehen. Bin noch nicht sicher, ob man das am ESP anfangen kann.
Zitat von: kroman am 05 März 2022, 20:36:34
Super! Dafür, dass du schon länger etwas anderes machen wolltest, bist du eh sehr fleißig ;D
Tja...
"Hängengeblieben" ;)
Aber dafür: FERTIG! :)
(inkl. FileLog und Graph)
Jetzt mal sehen, ob ich mich freue mein Gewicht zu "observieren"... :D :D
Danke an alle!
Gruß, Joachim
Hallo Joachim,
im openmqttgateway ist mein Problem wohl auch schon bekannt und wird hoffentlich demnächst behoben.
Auf den Vorschlag hin, ich könnte {"interval":5000} testen, habe ich esp32dev-ble-cont versucht und bekomme damit zuverlässig das Gewicht, leider aber extrem viel Traffic.
Zitat von: MadMax-FHEM am 05 März 2022, 18:36:12
EDIT: whitelist geschafft! :) "Fehler" war, dass das fhem Device (also BTGateway) (immer) MQTT2_ vorne dran packt. Das Topic aber nur der Name OHNE MQTT2_ ist... Wie geschrieben: wenn man weiß wie wo was ist es schon "ok" ;)
Kannst Du morgen vielleicht noch erklären, ob die whitelist den Traffic einschränken kann und wie genau ich das konfiguriere?
So wie ich das in der Doku verstehe kann man die Whitelist schon am OMG setzen, damit in fhem nur das gewünschte ankommt.
Danke und viele Grüße
Manfred
Zitat von: ares am 05 März 2022, 21:41:26
Hallo Joachim,
im openmqttgateway ist mein Problem wohl auch schon bekannt und wird hoffentlich demnächst behoben.
Auf den Vorschlag hin, ich könnte {"interval":5000} testen, habe ich esp32dev-ble-cont versucht und bekomme damit zuverlässig das Gewicht, leider aber extrem viel Traffic.
Aha, was ist das Problem?
Aktuell habe ich den "normalen" BLEGateway laufen mit 55s Zyklus.
Zitat von: ares am 05 März 2022, 21:41:26
Kannst Du morgen vielleicht noch erklären, ob die whitelist den Traffic einschränken kann und wie genau ich das konfiguriere?
So wie ich das in der Doku verstehe kann man die Whitelist schon am OMG setzen, damit in fhem nur das gewünschte ankommt.
Ja, es wird nur noch gesendet, wenn bzgl. der whitelist-MAC was gescannt wird, also schon auf dem Gateway.
Geht so:
set MQTT2ServerName publish -r home/OpenMQTTGateway_MCU-Name/commands/MQTTtoBT/config {"white-list":["A0:A1:A2:A3:A4:A5","B0:B1:B2:B3:B4:B5"]}
Wichtig (und darum hat es bei mir nicht geklappt): der OpenMQTTGateway_MCU-Name ist der in der Weboberfläche beim Konfigurieren des BLE-Gateways vergebene! Der fhem-Name hat noch ein MQTT2_ davor. Das MQTT2_ muss weg...
Ob mit oder ohne retain (also -r) musst du wissen...
Siehe auch: https://docs.openmqttgateway.com/use/ble.html#setting-a-white-or-black-list
Gruß, Joachim
Habe eben bemerkt, dass (nat.) in "model" noch "Quatsch" drin steht, also bezogen auf Waage:
OpenMQTTGateway_BT_temp_hum_sensor
Da wäre wohl besser OpenMQTTGateway_BT_scale oder OpenMQTTGateway_BT_weight_sensor...
Gruß, Joachim
Zitat von: MadMax-FHEM am 05 März 2022, 22:15:53
Ja, es wird nur noch gesendet, wenn bzgl. der whitelist-MAC was gescannt wird, also schon auf dem Gateway.
Geht so:
set MQTT2ServerName publish -r home/OpenMQTTGateway_MCU-Name/commands/MQTTtoBT/config {"white-list":["A0:A1:A2:A3:A4:A5","B0:B1:B2:B3:B4:B5"]}
Danke, jetzt hab auch ich das verstanden, ich hatte nur an der falschen Stelle gesucht:
set MQTT2_oMQTTgw_BT BT_whitelist ??????Mit der whitelist und passenden e-o-c bzw. e-o-u funktioniert die Waage bei mir nun mit der cont-Version und ich bin soweit schon mal glücklich.
Zitat von: MadMax-FHEM am 06 März 2022, 03:10:31
Habe eben bemerkt, dass (nat.) in "model" noch "Quatsch" drin steht, also bezogen auf Waage:
Habe ich geändert.
Verbesserungen gibt's noch einige wie "stateFormat weight unit" oder die "jsonMAP".
Das stateFormat vom OMG-Device mit dem HTTP-Aufruf passe ich auch an, der klappt ja nicht.
Ich verstehe nur immer noch nicht, wie man für MQTT2_oMQTTgw_BT last füllen kann, damit stateFormat funktioniert. Hast Du das gelöst oder kannst mir einen Tip geben?
Jetzt muss ich mir nur noch überlegen, wie das Gewicht (über Gewicht von/bis?) am einfachsten mehreren Personen in mehreren Readings zugeordnet werden kann. Das Problem hast Du aber ja nicht.
Viele Grüße
Manfred
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:
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 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
Zitat von: Beta-User am 06 März 2022, 12:27:32
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:
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
China-Irgendwas, ähnlich denen hier: https://www.ebay.de/itm/172683053179?hash=item2834b6487b:g:msEAAOSwARZXmxXL
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:
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:
set MQTT2_OMG1 attrTemplate OpenMQTTGateway_MCU
Daraufhin wird ein weiteres Device (Scanner) mit Namen MQTT2_oMQTTgw_BT angelegt, das ebenfalls konfiguriert werden muss:
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:
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:
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:
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.
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
Danke für die Zusammenfassung, mal sehen, was/wie man ggf. was ins Wiki übernehmen kann.
Es gibt übrigens bereits wieder eine aktualisierte Firmware :) .
Zitat von: DeeSPe am 06 März 2022, 16:45:48
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.
Zitat
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.
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)
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 20220307Wäre klasse, wenn ihr eure Meinung dazu äußern könntet...
Zitat von: Beta-User am 07 März 2022, 15:18:29
Es gibt übrigens bereits wieder eine aktualisierte Firmware :) .
FW bzgl. ESP?
Ich schaue mal...
Zitat von: Beta-User am 07 März 2022, 15:18:29
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
Zitat von: ares am 06 März 2022, 21:34:10
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 ;) ):
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:
defmod OMG_a1a2a3a4a5a6.N notify OMG_a1a2a3a4a5a6:weight:.*Gruß, Joachim
Zitat von: MadMax-FHEM am 07 März 2022, 16:09:58
FW bzgl. ESP?
Ja. Update für Eilige (hier: esp32dev-ble-firmware.bin) geht von FHEM aus mit:
set <omg> update { "version": "test", "password": "OTAPASSWORD", "url": "https://github.com/1technophile/OpenMQTTGateway/releases/download/v0.9.11/esp32dev-ble-firmware.bin" }
Zitat
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.
Zitat von: Beta-User am 07 März 2022, 15:18:29
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.
Zitat von: MadMax-FHEM am 07 März 2022, 16:12:49
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.
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ß
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!
Zitat von: Beta-User am 08 März 2022, 07:58:08
Dann mal willkommen hier im FHEM-Forum!
Danke :)
Zitat von: Beta-User am 08 März 2022, 07:58:08
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]
Zitat von: Beta-User am 08 März 2022, 07:58:08
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 ...
Zitat von: DigiH am 08 März 2022, 14:05:36
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.
Zitat
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...
Zitat
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...)
ZitatFü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 ;D ...
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...
Zitat
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.
Zitat von: Beta-User am 08 März 2022, 14:37:31
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.
Zitat von: Beta-User am 08 März 2022, 07:58:08
@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?
Zitat von: DigiH am 08 März 2022, 01:13:59
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.
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?
Zitat von: ares am 13 März 2022, 10:59:11
Gibt es inzwischen einen Langzeitplan und ich sollte meine Konfiguration löschen und neu anlegen bzw. überarbeiten?
Nun ja, wichtig ist, dass du mit deiner Konfiguration klarkommst. Ich habe nur noch die aktuelle Fassung im Einsatz (also ohne "scanner"). Zum Umstellen sollte es reichen, das neue MCU-template anzuwenden und dann den "scanner" zu löschen.
Zitat
Bei mir im MQTT2_SERVER ist das Reading RETAIN inzwischen sehr lang.
Ist das normal? Ist das wichtig oder kann man das irgendwie ausblenden?
"Normal" ist relativ. Da landet halt "alles", was von irgendwoher mit retain-flag gesendet wurde. Ob das immer notwendig oder zielführend ist, kannst nur du "wissen".
(Ich sende bisher gar nichts mit dem Flag, v.a. auch deswegen, weil das unbeabsichtigte Nebenwirkungen haben kann - wir hatten schon Rollladenöffnungen bei Neustart von mosquitto u.ä.. Kommt immer auf das Umfeld an).
Bereinigen kann Sinn machen, wenn es sich wirklich um "Altlasten" handelt. Es gibt einen Thread zu "Löschen im Gesamten", einzelne Einträge wird man los, wenn dann ohne -r-Flag gesendet wird.
Zitat
Nach einem Ab- und Anstecken des ESP32 werden ganz kurz einige Geräte zusätzlich übertragen, obwohl es eine white-list gibt.
[...] Wird die white-list am OMG erst verzögert aktiviert und bei Booten wird vorübergehend mehr gesendet?
Die Symptombeschreibung klingt danach. Es wundert mich etwas, dass die white- und blacklist-Infos nicht auf dem ESP gespeichert werden (können), aber die Doku dort meint, man bräuchte "retain".
Was ggf. noch sein kann: Wenn du nur kurz aussteckst, bekommt FHEM/M2S das nicht unbedingt gleich mit, sondern erst nach Ablauf der angekündigten "melde mich wieder"-Frist geht der ESP FHEM-intern auf "offline". Das führt uU. in solchen Situationen dazu, dass FHEM etwas braucht, bis das publish erfolgt. Müßte ggf. mit Rudi geklärt werden, ob/falls (!) das das "Problem" ist. An sich finde ich einen "überflüssigen" Vollscan aber nicht weiter dramatisch.
Zitat von: Beta-User am 14 März 2022, 07:38:28
Bereinigen kann Sinn machen, wenn es sich wirklich um "Altlasten" handelt. Es gibt einen Thread zu "Löschen im Gesamten", einzelne Einträge wird man los, wenn dann ohne -r-Flag gesendet wird.
Ich hatte bereits danach gesucht, aber nichts für mich als MQTT-Anfänger verständliches gefunden.
Gibt es Probleme, wenn ich das Reading einfach lösche und danach alle RETAIN-Anweisungen (bei mir nur die white-list) nochmal sende?
Zitat von: ares am 14 März 2022, 08:11:29
Ich hatte bereits danach gesucht, aber nichts für mich als MQTT-Anfänger verständliches gefunden.
Tipp: Ggf. einfach verlinken, was du gefunden hattest.
Zitat
Gibt es Probleme, wenn ich das Reading einfach lösche und danach alle RETAIN-Anweisungen (bei mir nur die white-list) nochmal sende?
Jein.
Das "Problem": Eingentlich sind die Hauptdaten zu retain im laufenden Betrieb irgendwo in den Internals vergraben, das Reading ist nur eine vereinfachte Darstellung und dient v.a. auch dazu, die Infos auch über einen Neustart hinaus retten zu können. Es wird wieder neu (aus allen intern gespeicherten Infos!) neu erstellt, wenn was dazukommt oder wegfällt.
Löschen+direkter Neustart "hilft" in der Regel (falls dazwischen kein retain- (?) publish erfolgt), weil dann das Reading nicht nochmal neu ermittelt wird. Sonst müßte man jeden Eintrag manuell dadurch löschen, dass man was ohne retain-flag sendet.
Zitat von: Beta-User am 14 März 2022, 09:50:07
Tipp: Ggf. einfach verlinken, was du gefunden hattest.
Zum Löschen hatte ich folgendes gefunden:
Zitat von: rudolfkoenig am 01 Juli 2019, 08:47:29
Das habe ich jetzt im MQTT2_SERVER implementiert :)
Loeschen kann man ein LWT auch mit "set mqtt2_server publish -r LWT_TOPIC"
update ist morgen ab acht Uhr verfuegbar.
Zitat von: rudolfkoenig am 10 Oktober 2020, 09:56:02
Zum Loeschen per set muss ein topic exakt angegeben werden.
Ich habe aber nur ein einziges BLE-Gerät im Betrieb und hätte nur die white-list im Reading vermutet.
Ich bin auf das Reading nur aufmerksam geworden, da ich sehr lange scrollen muss:
{"LWT_TOPIC":"home/","home/OMG1/LWT":"online","home/OMG1/commands/MQTTtoBT/config":"{\u0022white-list\u0022:[\u002270:87:9E:4C:3B:50\u0022]}","home/OMG1/version":"v0.9.11","home/OMG_ESP32_BLE_1/LWT":"offline","home/OMG_ESP32_BLE_1/version":"v0.9.10","homeassistant/binary_sensor/4091519BDF9C-connectivity/config":"{\u0022stat_t\u0022:\u0022home/OMG1/LWT\u0022,\u0022name\u0022:\u0022SYS: Connectivity\u0022,\u0022uniq_id\u0022:\u00224091519BDF9C-connectivity\u0022,\u0022pl_on\u0022:\u0022online\u0022,\u0022pl_off\u0022:\u0022offline\u0022,\u0022pl_avail\u0022:\u0022online\u0022,\u0022pl_not_avail\u0022:\u0022offline\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224091519BDF9C\u0022],\u0022name\u0022:\u0022OMG1\u0022,\u0022model\u0022:\u0022[\u0022BT\u0022]\u0022,\u0022manufacturer\u0022:\u0022OMG_community\u0022,\u0022sw_version\u0022:\u0022v0.9.11\u0022}}","homeassistant/sensor/405D082C7D5C-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/405D082C7D5C\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u0022405D082C7D5C-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022405D082C7D5C\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022405D082C7D5C\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/405D082C7D5C-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/405D082C7D5C\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u0022405D082C7D5C-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022405D082C7D5C\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022405D082C7D5C\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/405D082C7D5C-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/405D082C7D5C\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u0022405D082C7D5C-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022405D082C7D5C\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022405D082C7D5C\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/405D082C7D5C-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/405D082C7D5C\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u0022405D082C7D5C-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022405D082C7D5C\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022405D082C7D5C\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/405D082C7D5C-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/405D082C7D5C\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u0022405D082C7D5C-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022405D082C7D5C\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022405D082C7D5C\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/405D082C7D5C-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/405D082C7D5C\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u0022405D082C7D5C-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022405D082C7D5C\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022405D082C7D5C\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4091519BDF9C-freemem/config":"{\u0022stat_t\u0022:\u0022home/OMG1/SYStoMQTT\u0022,\u0022unit_of_meas\u0022:\u0022B\u0022,\u0022name\u0022:\u0022SYS: Free memory\u0022,\u0022uniq_id\u0022:\u00224091519BDF9C-freemem\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.freemem }}\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224091519BDF9C\u0022],\u0022name\u0022:\u0022OMG1\u0022,\u0022model\u0022:\u0022[\u0022BT\u0022]\u0022,\u0022manufacturer\u0022:\u0022OMG_community\u0022,\u0022sw_version\u0022:\u0022v0.9.11\u0022}}","homeassistant/sensor/4091519BDF9C-interval/config":"{\u0022stat_t\u0022:\u0022home/OMG1/SYStoMQTT\u0022,\u0022unit_of_meas\u0022:\u0022ms\u0022,\u0022name\u0022:\u0022BT: Interval between scans\u0022,\u0022uniq_id\u0022:\u00224091519BDF9C-interval\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.interval }}\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224091519BDF9C\u0022],\u0022name\u0022:\u0022OMG1\u0022,\u0022model\u0022:\u0022[\u0022BT\u0022]\u0022,\u0022manufacturer\u0022:\u0022OMG_community\u0022,\u0022sw_version\u0022:\u0022v0.9.11\u0022}}","homeassistant/sensor/4091519BDF9C-ip/config":"{\u0022stat_t\u0022:\u0022home/OMG1/SYStoMQTT\u0022,\u0022name\u0022:\u0022SYS: IP\u0022,\u0022uniq_id\u0022:\u00224091519BDF9C-ip\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.ip }}\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224091519BDF9C\u0022],\u0022name\u0022:\u0022OMG1\u0022,\u0022model\u0022:\u0022[\u0022BT\u0022]\u0022,\u0022manufacturer\u0022:\u0022OMG_community\u0022,\u0022sw_version\u0022:\u0022v0.9.11\u0022}}","homeassistant/sensor/4091519BDF9C-lowpowermode/config":"{\u0022stat_t\u0022:\u0022home/OMG1/SYStoMQTT\u0022,\u0022name\u0022:\u0022SYS: Low Power Mode\u0022,\u0022uniq_id\u0022:\u00224091519BDF9C-lowpowermode\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.lowpowermode }}\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224091519BDF9C\u0022],\u0022name\u0022:\u0022OMG1\u0022,\u0022model\u0022:\u0022[\u0022BT\u0022]\u0022,\u0022manufacturer\u0022:\u0022OMG_community\u0022,\u0022sw_version\u0022:\u0022v0.9.11\u0022}}","homeassistant/sensor/4091519BDF9C-rssi/config":"{\u0022stat_t\u0022:\u0022home/OMG1/SYStoMQTT\u0022,\u0022unit_of_meas\u0022:\u0022dB\u0022,\u0022name\u0022:\u0022SYS: Rssi\u0022,\u0022uniq_id\u0022:\u00224091519BDF9C-rssi\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.rssi }}\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224091519BDF9C\u0022],\u0022name\u0022:\u0022OMG1\u0022,\u0022model\u0022:\u0022[\u0022BT\u0022]\u0022,\u0022manufacturer\u0022:\u0022OMG_community\u0022,\u0022sw_version\u0022:\u0022v0.9.11\u0022}}","homeassistant/sensor/4091519BDF9C-scanbcnct/config":"{\u0022stat_t\u0022:\u0022home/OMG1/SYStoMQTT\u0022,\u0022name\u0022:\u0022BT: Connnect every X scan(s)\u0022,\u0022uniq_id\u0022:\u00224091519BDF9C-scanbcnct\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.scanbcnct }}\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224091519BDF9C\u0022],\u0022name\u0022:\u0022OMG1\u0022,\u0022model\u0022:\u0022[\u0022BT\u0022]\u0022,\u0022manufacturer\u0022:\u0022OMG_community\u0022,\u0022sw_version\u0022:\u0022v0.9.11\u0022}}","homeassistant/sensor/4091519BDF9C-uptime/config":"{\u0022stat_t\u0022:\u0022home/OMG1/SYStoMQTT\u0022,\u0022unit_of_meas\u0022:\u0022s\u0022,\u0022name\u0022:\u0022SYS: Uptime\u0022,\u0022uniq_id\u0022:\u00224091519BDF9C-uptime\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uptime }}\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224091519BDF9C\u0022],\u0022name\u0022:\u0022OMG1\u0022,\u0022model\u0022:\u0022[\u0022BT\u0022]\u0022,\u0022manufacturer\u0022:\u0022OMG_community\u0022,\u0022sw_version\u0022:\u0022v0.9.11\u0022}}","homeassistant/sensor/41248A04201E-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/41248A04201E\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u002241248A04201E-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002241248A04201E\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002241248A04201E\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/41248A04201E-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/41248A04201E\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u002241248A04201E-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002241248A04201E\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002241248A04201E\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/41248A04201E-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/41248A04201E\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u002241248A04201E-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002241248A04201E\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002241248A04201E\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/41248A04201E-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/41248A04201E\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u002241248A04201E-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002241248A04201E\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002241248A04201E\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/41248A04201E-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/41248A04201E\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u002241248A04201E-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002241248A04201E\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002241248A04201E\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/41248A04201E-volt/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/41248A04201E\u0022,\u0022dev_cla\u0022:\u0022voltage\u0022,\u0022unit_of_meas\u0022:\u0022V\u0022,\u0022name\u0022:\u0022IBEACON-volt\u0022,\u0022uniq_id\u0022:\u002241248A04201E-volt\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.volt | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002241248A04201E\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002241248A04201E\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4195872E545C-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4195872E545C\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u00224195872E545C-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224195872E545C\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224195872E545C\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4195872E545C-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4195872E545C\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u00224195872E545C-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224195872E545C\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224195872E545C\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4195872E545C-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4195872E545C\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u00224195872E545C-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224195872E545C\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224195872E545C\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4195872E545C-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4195872E545C\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u00224195872E545C-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224195872E545C\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224195872E545C\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4195872E545C-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4195872E545C\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u00224195872E545C-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224195872E545C\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224195872E545C\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4195872E545C-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4195872E545C\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u00224195872E545C-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224195872E545C\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224195872E545C\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/41F1459544E8-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/41F1459544E8\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u002241F1459544E8-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002241F1459544E8\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002241F1459544E8\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/41F1459544E8-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/41F1459544E8\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u002241F1459544E8-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002241F1459544E8\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002241F1459544E8\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/41F1459544E8-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/41F1459544E8\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u002241F1459544E8-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002241F1459544E8\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002241F1459544E8\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/41F1459544E8-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/41F1459544E8\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u002241F1459544E8-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002241F1459544E8\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002241F1459544E8\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/41F1459544E8-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/41F1459544E8\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u002241F1459544E8-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002241F1459544E8\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002241F1459544E8\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/41F1459544E8-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/41F1459544E8\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u002241F1459544E8-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002241F1459544E8\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002241F1459544E8\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4230C12A26BA-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4230C12A26BA\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u00224230C12A26BA-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224230C12A26BA\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224230C12A26BA\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4230C12A26BA-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4230C12A26BA\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u00224230C12A26BA-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224230C12A26BA\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224230C12A26BA\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4230C12A26BA-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4230C12A26BA\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u00224230C12A26BA-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224230C12A26BA\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224230C12A26BA\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4230C12A26BA-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4230C12A26BA\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u00224230C12A26BA-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224230C12A26BA\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224230C12A26BA\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4230C12A26BA-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4230C12A26BA\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u00224230C12A26BA-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224230C12A26BA\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224230C12A26BA\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4230C12A26BA-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4230C12A26BA\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u00224230C12A26BA-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224230C12A26BA\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224230C12A26BA\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/425183AF90B3-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/425183AF90B3\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u0022425183AF90B3-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022425183AF90B3\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022425183AF90B3\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG_ESP32_BLE_1\u0022}}","homeassistant/sensor/425183AF90B3-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/425183AF90B3\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u0022425183AF90B3-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022425183AF90B3\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022425183AF90B3\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG_ESP32_BLE_1\u0022}}","homeassistant/sensor/425183AF90B3-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/425183AF90B3\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u0022425183AF90B3-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022425183AF90B3\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022425183AF90B3\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG_ESP32_BLE_1\u0022}}","homeassistant/sensor/425183AF90B3-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/425183AF90B3\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u0022425183AF90B3-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022425183AF90B3\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022425183AF90B3\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG_ESP32_BLE_1\u0022}}","homeassistant/sensor/425183AF90B3-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/425183AF90B3\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u0022425183AF90B3-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022425183AF90B3\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022425183AF90B3\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG_ESP32_BLE_1\u0022}}","homeassistant/sensor/425183AF90B3-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/425183AF90B3\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u0022425183AF90B3-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022425183AF90B3\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022425183AF90B3\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG_ESP32_BLE_1\u0022}}","homeassistant/sensor/4300071B8D7D-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4300071B8D7D\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u00224300071B8D7D-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224300071B8D7D\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224300071B8D7D\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4300071B8D7D-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4300071B8D7D\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u00224300071B8D7D-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224300071B8D7D\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224300071B8D7D\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4300071B8D7D-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4300071B8D7D\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u00224300071B8D7D-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224300071B8D7D\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224300071B8D7D\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4300071B8D7D-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4300071B8D7D\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u00224300071B8D7D-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224300071B8D7D\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224300071B8D7D\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4300071B8D7D-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4300071B8D7D\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u00224300071B8D7D-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224300071B8D7D\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224300071B8D7D\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4300071B8D7D-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4300071B8D7D\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u00224300071B8D7D-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224300071B8D7D\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224300071B8D7D\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/435FDF090B1E-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/435FDF090B1E\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u0022435FDF090B1E-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022435FDF090B1E\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022435FDF090B1E\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/435FDF090B1E-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/435FDF090B1E\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u0022435FDF090B1E-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022435FDF090B1E\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022435FDF090B1E\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/435FDF090B1E-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/435FDF090B1E\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u0022435FDF090B1E-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022435FDF090B1E\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022435FDF090B1E\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/435FDF090B1E-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/435FDF090B1E\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u0022435FDF090B1E-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022435FDF090B1E\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022435FDF090B1E\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/435FDF090B1E-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/435FDF090B1E\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u0022435FDF090B1E-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022435FDF090B1E\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022435FDF090B1E\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/435FDF090B1E-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/435FDF090B1E\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u0022435FDF090B1E-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022435FDF090B1E\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022435FDF090B1E\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/43692842C5D8-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/43692842C5D8\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u002243692842C5D8-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002243692842C5D8\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002243692842C5D8\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG_ESP32_BLE_1\u0022}}","homeassistant/sensor/43692842C5D8-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/43692842C5D8\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u002243692842C5D8-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002243692842C5D8\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002243692842C5D8\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG_ESP32_BLE_1\u0022}}","homeassistant/sensor/43692842C5D8-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/43692842C5D8\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u002243692842C5D8-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002243692842C5D8\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002243692842C5D8\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG_ESP32_BLE_1\u0022}}","homeassistant/sensor/43692842C5D8-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/43692842C5D8\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u002243692842C5D8-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002243692842C5D8\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002243692842C5D8\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG_ESP32_BLE_1\u0022}}","homeassistant/sensor/43692842C5D8-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/43692842C5D8\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u002243692842C5D8-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002243692842C5D8\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002243692842C5D8\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG_ESP32_BLE_1\u0022}}","homeassistant/sensor/43692842C5D8-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/43692842C5D8\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u002243692842C5D8-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002243692842C5D8\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002243692842C5D8\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG_ESP32_BLE_1\u0022}}","homeassistant/sensor/436F8D833493-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/436F8D833493\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u0022436F8D833493-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022436F8D833493\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022436F8D833493\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/436F8D833493-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/436F8D833493\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u0022436F8D833493-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022436F8D833493\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022436F8D833493\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/436F8D833493-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/436F8D833493\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u0022436F8D833493-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022436F8D833493\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022436F8D833493\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/436F8D833493-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/436F8D833493\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u0022436F8D833493-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022436F8D833493\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022436F8D833493\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/436F8D833493-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/436F8D833493\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u0022436F8D833493-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022436F8D833493\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022436F8D833493\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/436F8D833493-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/436F8D833493\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u0022436F8D833493-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022436F8D833493\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022436F8D833493\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/43C0270DEC6F-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/43C0270DEC6F\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u002243C0270DEC6F-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002243C0270DEC6F\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002243C0270DEC6F\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/43C0270DEC6F-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/43C0270DEC6F\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u002243C0270DEC6F-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002243C0270DEC6F\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002243C0270DEC6F\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/43C0270DEC6F-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/43C0270DEC6F\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u002243C0270DEC6F-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002243C0270DEC6F\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002243C0270DEC6F\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/43C0270DEC6F-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/43C0270DEC6F\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u002243C0270DEC6F-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002243C0270DEC6F\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002243C0270DEC6F\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/43C0270DEC6F-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/43C0270DEC6F\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u002243C0270DEC6F-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002243C0270DEC6F\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002243C0270DEC6F\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/43C0270DEC6F-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/43C0270DEC6F\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u002243C0270DEC6F-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002243C0270DEC6F\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002243C0270DEC6F\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/44A536785D72-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/44A536785D72\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u002244A536785D72-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002244A536785D72\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002244A536785D72\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/44A536785D72-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/44A536785D72\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u002244A536785D72-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002244A536785D72\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002244A536785D72\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/44A536785D72-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/44A536785D72\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u002244A536785D72-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002244A536785D72\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002244A536785D72\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/44A536785D72-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/44A536785D72\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u002244A536785D72-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002244A536785D72\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002244A536785D72\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/44A536785D72-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/44A536785D72\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u002244A536785D72-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002244A536785D72\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002244A536785D72\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/44A536785D72-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/44A536785D72\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u002244A536785D72-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002244A536785D72\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002244A536785D72\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/479D901999B9-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/479D901999B9\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u0022479D901999B9-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022479D901999B9\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022479D901999B9\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/479D901999B9-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/479D901999B9\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u0022479D901999B9-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022479D901999B9\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022479D901999B9\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/479D901999B9-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/479D901999B9\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u0022479D901999B9-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022479D901999B9\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022479D901999B9\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/479D901999B9-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/479D901999B9\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u0022479D901999B9-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022479D901999B9\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022479D901999B9\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/479D901999B9-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/479D901999B9\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u0022479D901999B9-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022479D901999B9\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022479D901999B9\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/479D901999B9-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/479D901999B9\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u0022479D901999B9-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u0022479D901999B9\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u0022479D901999B9\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4916293FAB62-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4916293FAB62\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u00224916293FAB62-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224916293FAB62\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224916293FAB62\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4916293FAB62-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4916293FAB62\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u00224916293FAB62-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224916293FAB62\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224916293FAB62\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4916293FAB62-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4916293FAB62\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u00224916293FAB62-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224916293FAB62\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224916293FAB62\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4916293FAB62-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4916293FAB62\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u00224916293FAB62-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224916293FAB62\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224916293FAB62\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4916293FAB62-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4916293FAB62\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u00224916293FAB62-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224916293FAB62\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224916293FAB62\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/4916293FAB62-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/4916293FAB62\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u00224916293FAB62-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u00224916293FAB62\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u00224916293FAB62\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/49804413E1E2-battery/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/49804413E1E2\u0022,\u0022name\u0022:\u0022IBEACON-battery\u0022,\u0022uniq_id\u0022:\u002249804413E1E2-battery\u0022,\u0022dev_cla\u0022:\u0022battery\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.battery | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002249804413E1E2\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002249804413E1E2\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/49804413E1E2-major/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/49804413E1E2\u0022,\u0022name\u0022:\u0022IBEACON-major\u0022,\u0022uniq_id\u0022:\u002249804413E1E2-major\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.major | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002249804413E1E2\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002249804413E1E2\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/49804413E1E2-mfid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/49804413E1E2\u0022,\u0022name\u0022:\u0022IBEACON-mfid\u0022,\u0022uniq_id\u0022:\u002249804413E1E2-mfid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.mfid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002249804413E1E2\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002249804413E1E2\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/49804413E1E2-minor/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/49804413E1E2\u0022,\u0022name\u0022:\u0022IBEACON-minor\u0022,\u0022uniq_id\u0022:\u002249804413E1E2-minor\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.minor | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002249804413E1E2\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002249804413E1E2\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/49804413E1E2-power/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/49804413E1E2\u0022,\u0022name\u0022:\u0022IBEACON-power\u0022,\u0022uniq_id\u0022:\u002249804413E1E2-power\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.power | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002249804413E1E2\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002249804413E1E2\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}","homeassistant/sensor/49804413E1E2-uuid/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/49804413E1E2\u0022,\u0022name\u0022:\u0022IBEACON-uuid\u0022,\u0022uniq_id\u0022:\u002249804413E1E2-uuid\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.uuid | is_defined }}\u0022,\u0022state_class\u0022:\u0022measurement\u0022,\u0022device\u0022:{\u0022identifiers\u0022:[\u002249804413E1E2\u0022],\u0022connections\u0022:[[\u0022mac\u0022,\u002249804413E1E2\u0022]],\u0022manufacturer\u0022:\u0022GENERIC\u0022,\u0022model\u0022:\u0022IBEACON\u0022,\u0022name\u0022:\u0022IBEACON\u0022,\u0022via_device\u0022:\u0022OMG1\u0022}}",...Edit: ich musste das Reading abschneiden, da das für einen Post zu lang ist. :(
Mit der Doku hier habe ich das Reading gelöscht ...
deletereading MQTT2_FHEM_Server RETAIN... und fhem direkt danach neu gestartet.
Soweit ich verstanden habe, muss ich die white-list danach ja wieder neu setzen:
set MQTT2_FHEM_Server publish -r home/OMG1/commands/MQTTtoBT/config {"white-list":["a1:a2:a3:a4:a5:a6"]}Direkt im Anschluss ist das Reading in alter Länge wieder da.
Hmm, ja, stimmt, da steht auch eine lange Latte an "Zeug" drin, was "von außen" an den Server gesendet wurde. Das kommt natürlich wieder, und wird auch "so gebraucht" - was OMG angeht, zumindest soweit die "auto-discovery" von Homeassistant aktiviert ist (die wir für FHEM eigentlich nicht brauchen). Das müßte in der firmware deaktiviert werden, sonst wird das immer wiederkommen.
(Dieser Datenmüll (meine Auffassung) hat mich bisher nie gestört).
Zitat von: Beta-User am 14 März 2022, 10:46:08
(Dieser Datenmüll (meine Auffassung) hat mich bisher nie gestört).
Der Datenmüll steht auch in /opt/fhem/log/fhem.save und resultiert in einer großen Datei und schneller wird fhem damit sicher auch nicht.
Gibt es wenigstens eine Möglichkeit, bestimmte "Datenmüll"-Readings (auch in anderen Device) in der Anzeige (ohne Punkt vor dem Namen) auszublenden?
Na ja, dramatisch sind diese Datenmengen andererseits auch nicht.
Es ist und bleibt unschön, aber es gibt sicher andere Punkte, die die Performance von FHEM nachhaltiger belasten. Ausblenden lassen sich "normale Readings" (wie dieses) jedenfalls nicht.
Zitat von: ares am 13 März 2022, 10:59:11
Nach einem Ab- und Anstecken des ESP32 werden ganz kurz einige Geräte zusätzlich übertragen, obwohl es eine white-list gibt.
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?
RETAINed Messages werden nicht auf dem ESP32 gespeichert, sondern auf dem MQTT Broker, dieser sendet jedem Client seine RETAINed Nachrichten wieder, sobald ein solcher sich neu anmeldet - nach einem Neustart zum Beispiel. Da zwischen dem Hochfahren (und neu Anmelden am MQTT Broker) des ESP32 und dem Senden der RETAINed Nachrichten an diesen eine kurze Zeitspanne ist, in der der ESP32 noch keine White-List vom Broker erhalten hat, werden solange auch alle anderen Geräte erkannt und veröffentlicht.
Ich persönlich benutze keine RETAINed Nachrichten für meine White-Lists, da ich unterschiedliche White-Lists für meine OMG BLE Gateway, je nach Home-Situation, haben möchte. Daher benutze ich den LWT Wechsel von "offline" zu "online" (auch durch erzwunge MQTT Neustarts für genau diese Funktionalität) um dann je nach Presence oder Security Status des Heims unterschiedliche White-Lists zu senden. Vielleicht ist das für manche von euch auch eine Möglichkeit, es hält auf jeden Fall die RETAINed Liste des MQTT Brokers sauber ;) ändert aber an dem kurzeitigen Verhalten ohne White-List auch nichts.
Zitat von: DigiH am 14 März 2022, 11:34:56
RETAINed Messages werden nicht auf dem ESP32 gespeichert, sondern auf dem MQTT Broker, dieser sender jedem Client seine RETAINed Nachrichten wieder, sobald ein solcher sich neu anmeldet - nach einem Neustart zum Beispiel. Da zwischen dem Hochfahren (und neu Anmelden am MQTT Broker) des ESP32 und dem Senden der RETAINed Nachrichten an diesen eine kurze Zeitspanne ist, in der der ESP32 noch keine White-List vom Broker erhalten hat, werden solange auch alle anderen Geräte erkannt und veröffentlicht.
Meine Irritation bezog sich darauf, dass white- und blacklist nicht auf dem ESP direkt gespeichert werden, bis was neues kommt, der Mechanismus ansonsten ist soweit klar - abgesehen davon, dass FHEM* anscheinend relativ lange braucht, bis die betreffende Message rausgeschickt wird.
Zitates hält auf jeden Fall die RETAINed Liste des MQTT Brokers sauber ;)
*FHEM ist bei Verwendung von MQTT2_SERVER selbst "Broker", und die Masse der von ares gezeigten Einträge kommt "von außen" (vom ESP her). Von daher ist es ohne Änderung an der firmware wohl nicht so einfach, die Liste "sauber" zu halten...
ZitatIch persönlich benutze keine RETAINed Nachrichten für meine White-Lists, da ich unterschiedliche White-Lists für meine OMG BLE Gateway, je nach Home-Situation haben möchte. Daher benutze ich den LWT Wechsel von "offline" zu "online" (auch durch erzwunge MQTT Neustarts für genau diese Funktionalität) um dann je nach Presence oder Security Status des Heims unterschiedliche White-Lists zu senden.
Interessehalber: kannst/magst du die Logik etwas näher beschreiben?
Ich habe ja auch genau wie ares die Waage und einen ESP mit derselben FW (fertiges Image)?
(gut ich habe noch kein Update eingespielt, weder FW noch fhem mit neuen attrTemplates)
Ich habe eine retain Whitelist mit genau nur der Waage.
Ich schalte meinen ESP nachts aus und morgens wieder an (eher "Zufall", weil er [noch] an einer USB-Dose hängt die zusammen mit bzw. wegen anderer Dinge nachts ausgeschaltet wird)...
...ich hatte wohl Glück, ich kann bei mir keine anderen Einträge finden und das läuft ja schon ein paar viele Tage jetzt...
Gruß, Joachim
Zitat von: DigiH am 14 März 2022, 12:35:47
So habe ich das schon auch verstande, aber hält MQTT2_SERVER nicht, wie andere MQTT Broker auch, [...]
MQTT2_SERVER implementiert die MQTT-Broker-Funktionalität tendenziell so, wie es für eine "FHEM-only"-Verwendung sinnvoll und effizient ist; es steht da keine Datenbank dahinter, die befüllt werden könnte oder müßte, alles wird im Prinzip im Speicher verwaltet und ggf. durch Wegspeichern dieses "Readings" für den Neustart gesichert. Simpelst, aber funktional...
Wer einen vollwertigen Server (wirklich) braucht, "muss" (z.B.) mosquitto verwenden und FHEM dann z.B. mit MQTT2_CLIENT anbinden. Das ist zu empfehlen, wenn FHEM (bzw. die Instanz, die den Server bereitstellt) nur einen Bruchteil der Daten selbst verarbeiten soll und/oder MQTT für irgendwas "absonderliches" als Transportweg genutzt werden soll (wie z.B. Audiodaten für/in Rhasspy).
Zitat von: MadMax-FHEM am 14 März 2022, 12:42:58
Ich habe ja auch genau wie ares die Waage und einen ESP mit derselben FW (fertiges Image)?
(gut ich habe noch kein Update eingespielt, weder FW noch fhem mit neuen attrTemplates)
Ich habe eine retain Whitelist mit genau nur der Waage.
Ich schalte meinen ESP nachts aus und morgens wieder an (eher "Zufall", weil er [noch] an einer USB-Dose hängt die zusammen mit bzw. wegen anderer Dinge nachts ausgeschaltet wird)...
...ich hatte wohl Glück, ich kann bei mir keine anderen Einträge finden und das läuft ja schon ein paar viele Tage jetzt...
Die "externen" retain-Einträge kommen vom ESP, und es kann durchaus sein, dass man - je nach dem gewählten firmware-Image - eben Einträge bekommt oder eben nicht. Ich habe auch einige...
Das hat aber nichts mit der Verarbeitung in FHEM/MQTT2_DEVICE (und damit attrTemplate) zu tun.
Zitat von: Beta-User am 14 März 2022, 12:55:49
Die "externen" retain-Einträge kommen vom ESP, und es kann durchaus sein, dass man - je nach dem gewählten firmware-Image - eben Einträge bekommt oder eben nicht. Ich habe auch einige...
Das hat aber nichts mit der Verarbeitung in FHEM/MQTT2_DEVICE (und damit attrTemplate) zu tun.
Jep, ist klar.
Neues attrTemplate -> kein Scanner mehr ;)
Ich wollte nur mitteilen, dass ich das/die Problem/e nicht hab :)
(aber auch [nich] nicht die neueste FW geflasht habe / Habe [noch] v0.9.10 und folgendes Image geflasht: esp32dev-ble-firmware.bin)
Gruß, Joachim
Zitat von: Beta-User am 14 März 2022, 11:54:24
*FHEM ist bei Verwendung von MQTT2_SERVER selbst "Broker", und die Masse der von ares gezeigten Einträge kommt "von außen" (vom ESP her). Von daher ist es ohne Änderung an der firmware wohl nicht so einfach, die Liste "sauber" zu halten...
So habe ich das auch schon verstanden, kenne mich leider aber mit MQTT2_SERVER nicht aus. Hält er aber nicht, wie andere MQTT Broker auch, die Datenbank periodisch sauber, besonders wenn wohl die meisten/alle Nachrichten mit Qos0 verarbeitet werden, oder hat auch die Möglichkeit nur RETAINed Nachrichten in die Datenbank zu speichern und alle andere nur in RAM zu halten bis sie verarbeitet wurden?
Zitat von: Beta-User am 14 März 2022, 11:54:24
Interessehalber: kannst/magst du die Logik etwas näher beschreiben?
Ein Beispiel: der BT-Beacon an den Schlüsselbunden für Gäste. Sind keine Gäste da sind die Gästeschlüsselbunde natürlich konstant zuhause. In diesem Fall sollen sie natürlich nicht für die Alarmanlage, automatische Heizungssteuerung/Lichtabschaltung bei Abwesenheit aller mit einbezogen werden. Sobald ich den Schalter für "Gäste (da)" aktiviere sendet mein Backend eine Neustart Nachricht an meine OMG BLE Gateway. Dabei sendet der Broker erst eine "offline", gleich danach eine "online" LWT Nachricht. Kommt dieser LWT Wechsel und der "Gäste (da)" ist ON wird eine White-List mit den MAC Adresse des Gästeschlüsselbunde gesendet - die Gäste BT-Beacons sind aktiv für alle Automatisierungen. Sind die Gäste weg, und der "Gäste (da)" Schalter kommt auf OFF gibt es wieder eine neue White-List ohne die Gäste Beacons, die daher dann alle als 'außer Haus' registriert werden.
Oder auch bei Urlaub, wenn das Mi Band der Verwandtschaft die Alarmanlage deaktiviert damit sie Blumen gießen können, aber bei nicht-Urlaub das Mi Band beim Verwandschaftsbesuch nicht mit der Alarmanlage interagieren soll ;)
Habe da einige Konstellationen in den ich je nach Situationslage verschiedene White-Liste anwende.
TUT MIR LEID für die mehrfachen Posts. Die Alt+S Beitrag schreiben Funktion hier im Forum macht mich ganz verrückt ;) Auf meinem englischen Keyboard habe ich Alt+s/u/a/o für ß/ü/ä/ö programmiert - jedes mal wenn ich dann ß schreiben will, wurde schon gepostet :(
Zitat von: DigiH am 14 März 2022, 13:02:53
So habe ich das auch schon verstanden, kenne mich leider aber mit MQTT2_SERVER nicht aus. Hält er aber nicht, wie andere MQTT Broker auch, die Datenbank periodisch sauber, besonders wenn wohl die meisten/alle Nachrichten mit Qos0 verarbeitet werden, oder hat auch die Möglichkeit nur RETAINed Nachrichten in die Datenbank zu speichern und alle andere nur in RAM zu halten bis sie verarbeitet wurden?
Siehe meinen vorherigen Post - summary: MQTT2_SERVER ist keine vollwertige High-performance-optimierte Implementierung...
Zitat
Ein Beispiel: der BT-Beacon an den Schlüsselbunden für Gäste. Sind keine Gäste da sind die Gästeschlüsselbunde natürlich konstant zuhause. In diesem Fall sollen sie natürlich nicht für die Alarmanlage, automatische Heizungssteuerung/Lichtabschaltung bei Abwesenheit aller mit einbezogen werden. Sobald ich den Schalter für "Gäste (da)" aktiviere sendet mein Backend eine Neustart Nachricht an meine OMG BLE Gateway. Dabei sendet der Broker erst eine "offline", gleich danach eine "online" LWT Nachricht. Kommt dieser LWT Wechsel und der "Gäste (da)" ist ON wird eine White-List mit den MAC Adresse des Gästeschlüsselbunde gesendet - die Gäste BT-Beacons sind aktiv für alle Automatisierungen. Sind die Gäste weg, und der "Gäste (da)" Schalter kommt auf OFF gibt es wieder eine neue White-List ohne die Gäste Beacons, die daher dann alle als 'außer Haus' registriert werden.
Oder auch bei Urlaub, wenn das Mi Band der Verwandtschaft die Alarmanlage deaktiviert damit sie Blumen gießen können, aber bei nicht-Urlaub das Mi Band beim Verwandschaftsbesuch nicht mit der Alarmanlage interagieren soll ;)
Habe da einige Konstellationen in den ich je nach Situationslage verschiedene White-Liste anwende.
THX, macht Sinn, wobei mir da manches nicht ganz klar ist:
- ein retain-Flag würde wohl in dieser Konstellation auch nicht schaden, es könnte nur dazu kommen, dass erst der Broker was sendet und dann deine Automatisierung was anderes (und das ganze ggf. Neustart-fester wäre - vorausgesetzt, dass der Start von ESP/WLAN und Broker schneller vonstatten geht wie der der eigentlichen Automatisierung).
- an sich wäre ich nach der Beschreibung in https://docs.openmqttgateway.com/use/ble.html#setting-a-white-or-black-list davon ausgegangen, dass die Listen immer komplett zu schreiben sind, so dass der Neustart an sich gar nicht erforderlich wäre. Das scheint demnach nicht der Fall zu sein?
(Ich muss wohl auch mit diesen features etwas spielen...).
ZitatHält er aber nicht, wie andere MQTT Broker auch, die Datenbank periodisch sauber [...]
Was ist damit gemeint? Hast Du ein Link fuer mich?
Zitat von: Beta-User am 14 März 2022, 13:13:47
- an sich wäre ich nach der Beschreibung in https://docs.openmqttgateway.com/use/ble.html#setting-a-white-or-black-list davon ausgegangen, dass die Listen immer komplett zu schreiben sind, so dass der Neustart an sich gar nicht erforderlich wäre. Das scheint demnach nicht der Fall zu sein?
(Ich muss wohl auch mit diesen features etwas spielen...).
Zum hinzufügen von MAC Adressen schon, aber beim entfernen von MAC Adressen funktioniert das nicht - siehe unten.
Zitat von: Beta-User am 14 März 2022, 11:54:24
Meine Irritation bezog sich darauf, dass white- und blacklist nicht auf dem ESP direkt gespeichert werden, bis was neues kommt...
Werden nicht auf dem ESP32 direkt gespeichert, da ein Neustart momentan auch die einzige Möglichkeit ist eine white/black-list ganz zu löschen/entfernen.
Zum ganzen white/black-list Thema auch mal mein OMG Forum Post, wo ich ähnliche Fragen und Überlegungen bei meinem OMG Einstieg hatte
https://community.openmqttgateway.com/t/query-about-white-list-black-list-specifically-how-to-remove-devices-from-the-lists-or-to-fully-clear-the-lists/1151
Zitat von: rudolfkoenig am 14 März 2022, 13:18:14
Was ist damit gemeint? Hast Du ein Link fuer mich?
Link jetzt direkt nicht, ich benutze Mosquitto, der verschiedene Konfigurationsmöglichkeiten für die mosquitto.db bietet. Auch bei 50+ Messages die Minute und den kurzen unerwünschten Geräteerkennung bei Neustarts steigt diese Datenbank nie groß, oder nimmt auch mal bisschen ab. Daher nehme ich stark an, dass alle QoS0 Nachrichten (was auch alle der unerwünschten Neustart-Erkennungen sein sollten) überhaupt nicht in die Datenbank geschrieben werden.
Kurz Link zur conf gesucht ...
https://mosquitto.org/man/mosquitto-conf-5.html
Wie angenommen steh da
If true, mosquitto will count the number of subscription changes, retained messages received and queued messages and if the total exceeds autosave_interval then the in-memory database will be saved to disk.
Also nur retained und queued Nachrichten, wobei die queued (nicht bei QoS0) dann auch wieder gelöscht werden nach erfolgter Bestätigung.
Da mein Backend aber nie etwas von unerwünschten Geräten mitbekommt, da ich dort nur erwünschte Topics abonniere, sind meine White-Lists für die oben genannte Funktionalität da, um den MQTT Broker nicht zu fluten und einen sauberen Überblick zu haben wenn ich den Broker Output direkt inspiziere.
OT @Rudi: interessant, was da zum Thema "persistence" in der manpage zu finden ist. Mir war z.B. nicht bewußt, dass mosquitto per default gar nichts speichert...
Vielleicht sollte man sowas wie einen "clear_retained"-setter in M2S einbauen?
ZitatVielleicht sollte man sowas wie einen "clear_retained"-setter in M2S einbauen?
Ich habe ein hideRetain Attribut und ein clearRetain set-Befehl eingebaut.
Zitat von: rudolfkoenig am 16 März 2022, 16:52:34
Ich habe ein hideRetain Attribut und ein clearRetain set-Befehl eingebaut.
(Stellvertretend): DANKE!
Zitat von: DeeSPe am 06 März 2022, 16:45:48
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.
Schade, dass da keine Antwort kam. Hat inzwischen zufällig jemand eine Erklärung für das Verhalten und eine Lösung, wie der wieder automatisch anfängt zu scannen?
Zitat von: drhirn am 04 Juli 2022, 14:45:47
Schade, dass da keine Antwort kam. Hat inzwischen zufällig jemand eine Erklärung für das Verhalten und eine Lösung, wie der wieder automatisch anfängt zu scannen?
Nun ja, die dortige Frage meine ich beantwortet zu haben (bzw. die automatisch erkennbare Kennung wäre "iTAG").
Wenn der Weiterscannen soll, wäre es vermutlich am einfachsten, ein sleep zu bauen, das entweder auf die Rückgabe des Batteriewerts lauscht und dann den config-Befehl raushaut, wenn der kommt, oder eben einfach eine entsprechende Zeit zu warten.
Alternative wäre, ein periodicCmd zu basteln, mit dem das "immer mal wieder" ausgeführt wird.
Oder ein notify, dass auf das Batterie-Reading hört. Danke für den Denkanstoß! Schöner wär's natürlich, wenn der automatisch weitermachen würde ;)
Zitat von: drhirn am 04 Juli 2022, 15:32:17
Oder ein notify, dass auf das Batterie-Reading hört. Danke für den Denkanstoß! Schöner wär's natürlich, wenn der automatisch weitermachen würde ;)
Na ja, das mit dem sleep war so gemeint gewesen, dass das bei der Abfrage erstellt wird und dann eben einmalig auf das Batterie-Reading reagiert. Damit hätte man kein zusätzliches Device. Das Problem dabei ist und bleibt aber: Wenn kein Wert gelesen wird, kommt die Schleife nicht wieder in Gang (falls bereits der Leseversuch dazu führt, dass das scannen beendet wird).
Da ich aber zum einen einen "Piepser" habe, und zum anderen eine andere Variante der firmware, ist das alles graue Theorie. Ist das denn bereits als Bug in OMG-github gemeldet?
Stimmt natürlich. Kein Wert, kein Trigger.
Ich muss gestehen, ich hab das heute schnell hin gebastelt und mich noch nicht genauer damit beschäftigt. Insofern auch keine GitHub-Issues und -Diskussionen gelesen. Und das OMG Forum auch nicht.
Zitat von: rudolfkoenig am 16 März 2022, 16:52:34
Ich habe ein hideRetain Attribut und ein clearRetain set-Befehl eingebaut.
Wie funktioniert "clearRetain"? Wenn ich es setze, sind alle "RETAIN" weg, nach einem Neustart aber alle wieder da. ??? "Save config" ändert daran nichts.
Ich frage, weil ich viele "RETAIN" habe, die (glaube ich) Fehleinträge sind, ein paar Beispiel-Einträge (nicht komplett, circa 1-2 %):
,"homeassistant/binary_sensor/083AF2A8EF8Cconnectivity/config":"{\u0022stat_t\u0022:\u0022home/OMG_Kueche/LWT\u0022,\u0022name\u0022:\u0022SYS: Connectivity\u0022,\u0022uniq_id\u0022:\u0022083AF2A8EF8Cconnectivity\u0022,\u0022dev_cla\u0022:\u0022connectivity\u0022,\u0022pl_on\u0022:\u0022online\u0022,\u0022pl_off\u0022:\u0022offline\u0022,\u0022pl_avail\u0022:\u0022online\u0022,\u0022pl_not_avail\u0022:\u0022offline\u0022,\u0022device\u0022:{\u0022name\u0022:\u0022OMG_Kueche\u0022,\u0022model\u0022:\u0022[\u0022BME280\u0022,\u0022BH1750\u0022,\u0022RF\u0022,\u0022BT\u0022,\u0022HCSR501\u0022,\u0022GPIOInput\u0022,\u0022DS1820\u0022]\u0022,\u0022manufacturer\u0022:\u0022OMG_community\u0022,\u0022sw_version\u0022:\u00220.9.8.1\u0022,\u0022identifiers\u0022:[\u0022083AF2A8EF8C\u0022]}}","homeassistant/binary_sensor/083AF2A8EF8Chcsr501/config":"{\u0022stat_t\u0022:\u0022home/OMG_Kueche/HCSR501toMQTT\u0022,\u0022name\u0022:\u0022hcsr501\u0022,\u0022uniq_id\u0022:\u0022083AF2A8EF8Chcsr501\u0022,\u0022val_tpl\u0022:\u0022{{ value_json.presence | is_defined }}\u0022,\u0022pl_on\u0022:\u0022true\u0022,\u0022pl_off\u0022:\u0022false\u0022,\u0022device\u0022:{\u0022name\u0022:\u0022OMG_Kueche\u0022,\u0022model\u0022:\u0022[\u0022BME280\u0022,\u0022BH1750\u0022,\u0022RF\u0022,\u0022BT\u0022,\u0022HCSR501\u0022,\u0022GPIOInput\u0022,\u0022DS1820\u0022]\u0022,\u0022manufacturer\u0022:\u0022OMG_community\u0022,\u0022sw_version\u0022:\u00220.9.8.1\u0022,\u0022identifiers\u0022:[\u0022083AF2A8EF8C\u0022]}}","homeassistant/binary_sensor/12FD68CA1DCB-CLEARGRASSCGH1-open/config":"{\u0022stat_t\u0022:\u0022+/+/BTtoMQTT/12FD68CA1DC
Edit: OMG sendet den ... Nach einem reboot vom ESP32 ist RETAIN wieder voll der Einträge.
So wie es ausschaut muss dieses Problem auf der anderen (OMG) Seite geloest werden.
Zitat von: rudolfkoenig am 05 Juli 2022, 08:05:37
So wie es ausschaut muss dieses Problem auf der anderen (OMG) Seite geloest werden.
...und/oder durch ignoreRegexp am IO...
Weiß irgendwer, wo das her kommt?
PERL WARNING: Use of uninitialized value $1 in concatenation (.) or string at (eval 3272) line 1.
eval: my $CID= $evalSpecials->{'%CID'};my $DEVICETOPIC= $evalSpecials->{'%DEVICETOPIC'};my $EVENT= $evalSpecials->{'%EVENT'};my $EVTPART0= $evalSpecials->{'%EVTPART0'};my $EVTPART1= $evalSpecials->{'%EVTPART1'};my $JSONMAP= $evalSpecials->{'%JSONMAP'};my $NAME= $evalSpecials->{'%NAME'};my $TOPIC= $evalSpecials->{'%TOPIC'};{ $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}
Danke!
Würde mal darauf tippen, dass deine Benennung des OpenMQTTGateways nicht dem vorgesehenen Namensschema entspricht (O.*M.*G.*) und daher die regex auf den Topic nichts liefert?
Hab ich mir auch gedacht. Aber auch eine Umbenennungs- und Lösch/Neuerstell-Orgie hat nichts gebracht.
defmod MQTT2_OpenMQTTGateway_ESP32_BLE MQTT2_DEVICE Mosquitto
attr MQTT2_OpenMQTTGateway_ESP32_BLE bridgeRegexp $DEVICETOPIC/433toMQTT[:/].* 'oMQTTgw_433'\
$DEVICETOPIC/IRtoMQTT[:/].* 'oMQTTgw_IR'\
$DEVICETOPIC/CLIMAtoMQTT/([a-zA-Z0-9]+)[:/].* "OMGoffice_$1"
attr MQTT2_OpenMQTTGateway_ESP32_BLE comment For syntax wrt. update and BT commands see https://github.com/1technophile/OpenMQTTGateway/releases/tag/v0.9.7
attr MQTT2_OpenMQTTGateway_ESP32_BLE devStateIcon online:10px-kreis-gruen offline.*:10px-kreis-rot
attr MQTT2_OpenMQTTGateway_ESP32_BLE devicetopic OMG/OMGoffice
attr MQTT2_OpenMQTTGateway_ESP32_BLE event-on-change-reading last,LWT,version,Sys_.*
attr MQTT2_OpenMQTTGateway_ESP32_BLE icon mqtt
attr MQTT2_OpenMQTTGateway_ESP32_BLE model OpenMQTTGateway_MCU
attr MQTT2_OpenMQTTGateway_ESP32_BLE periodicCmd deleteReadings:1440
attr MQTT2_OpenMQTTGateway_ESP32_BLE 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 }}\
OMG/home_presence/OMGoffice:.* { return if $EVENT !~ m,(..):(..):(..):(..):(..):(..),;; {last => uc($1.$2.$3.$4.$5.$6)}}\
homeassistant/.+?/config:.* {}
attr MQTT2_OpenMQTTGateway_ESP32_BLE room MQTT2_DEVICE
attr MQTT2_OpenMQTTGateway_ESP32_BLE 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 MQTT2_OpenMQTTGateway_ESP32_BLE stateFormat <a href="http://Sys_ip" target="_blank">\
LWT\
</a>Version: version
defmod OMG_7C2F80AF1AF5 MQTT2_DEVICE 7C2F80AF1AF5
attr OMG_7C2F80AF1AF5 autocreate 0
attr OMG_7C2F80AF1AF5 devicetopic OMG/OMGoffice
attr OMG_7C2F80AF1AF5 event-min-interval .*:300
attr OMG_7C2F80AF1AF5 event-on-change-reading .*
attr OMG_7C2F80AF1AF5 getList batteryPercent:noArg batteryPercent { my $id = ReadingsVal($NAME,'id','7C2F80AF1AF5');; qq($DEVICETOPIC/commands/MQTTtoBT/config {"ble_read_address":"$id","ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX"}) }
attr OMG_7C2F80AF1AF5 icon mqtt
attr OMG_7C2F80AF1AF5 model OpenMQTTGateway_BT_gtag
attr OMG_7C2F80AF1AF5 readingList OMG/(O[^/]*M[^/]*G[^/]*)/BTtoMQTT/7C2F80AF1AF5:.* { $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_7C2F80AF1AF5 room MQTT2_DEVICE
attr OMG_7C2F80AF1AF5 setList beep:noArg { my $id = ReadingsVal($NAME,'id','7C2F80AF1AF5');; qq($DEVICETOPIC/commands/MQTTtoBT/config {"ble_read_address":"$id","ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX","immediate":true}) }
attr OMG_7C2F80AF1AF5 stateFormat Last IO: last_IO
Zitat von: drhirn am 05 Juli 2022, 13:53:40
Hab ich mir auch gedacht. Aber auch eine Umbenennungs- und Lösch/Neuerstell-Orgie hat nichts gebracht.
;D Dann solltest du vielleicht auch den "präfix" auch noch entsprechend anpassen: "OMG" statt "home" (in der Auswertung in der readingList). Das dürfte ursprünglich mal anders gewesen sein, zumindest war das meine Schlussfolgerung nach dem Blick auf die aktuellen attrTemplate-Sätze zu OMG.
Gut gesehen! Danke! Irgendwie unpraktisch, dass das "home" im Template hart-kodiert ist.
Mein Problem von gestern mit den ausbleibenden Scans nach einem Batterie-Check hat sich auf magische Art gelöst. Keine Ahnung, warum das heute geht. Was mir aber aufgefallen ist: Wenn ich ein get ... batteryPercent mache, wie's das Template vorsieht, meldet mir FHEM ein "Timeout reading answer..." zurück. Ergänze ich aber die getList um ,"immediate":true funktioniert das.
Zitat von: drhirn am 05 Juli 2022, 14:35:35
Irgendwie unpraktisch, dass das "home" im Template hart-kodiert ist.
update kommt bei Gelegenheit...
Zitat
Mein Problem von gestern mit den ausbleibenden Scans nach einem Batterie-Check hat sich auf magische Art gelöst. Keine Ahnung, warum das heute geht. Was mir aber aufgefallen ist: Wenn ich ein get ... batteryPercent mache, wie's das Template vorsieht, meldet mir FHEM ein "Timeout reading answer..." zurück. Ergänze ich aber die getList um ,"immediate":true funktioniert das.
Na ja, der timeout besagt nur, dass bei Aufruf des "get" über FHEMWEB nicht innerhalb der dafür vorgesehenen Frist eine Rückmeldung kam, nicht, dass nicht irgendwann eine gekommen ist...
Zitat von: Beta-User am 05 Juli 2022, 15:26:16
Na ja, der timeout besagt nur, dass bei Aufruf des "get" über FHEMWEB nicht innerhalb der dafür vorgesehenen Frist eine Rückmeldung kam, nicht, dass nicht irgendwann eine gekommen ist...
Ja. Da wir aber wissen, dass es ja unter Umständen länger dauern kann, könnte man das ja eigentlich weg lassen, oder?
Zitat von: drhirn am 05 Juli 2022, 15:32:41
Ja. Da wir aber wissen, dass es ja unter Umständen länger dauern kann, könnte man das ja eigentlich weg lassen, oder?
Hmm, der asyncOutput-Mechanismus ist ein allgemeiner, und der timeout kommt (afaik unveränderlich) aus dem Modul, ändern würde hier auch keinen Sinn machen, da es "ewig" (mehrere Minuten+) dauern kann, bis eine Rückmeldung kommt. Ein User, der per FHEMWEB anfragt, wird nicht solange warten wollen, und bei Anfragen aus der Automatisierung selbst (at & Co) ist es egal...
Per default auf "mach's sofort" umstellen kommt mir auch nicht optimal vor. In die getList das Doppel von "beep" aufnehmen? Hmmm,...
Zitat von: Beta-User am 05 Juli 2022, 15:51:16
Per default auf "mach's sofort" umstellen kommt mir auch nicht optimal vor.
Weil? Hab das jetzt nicht auf Herz und Nieren getestet. Aber Probleme konnte ich auch keine feststellen.
Ansonsten hätte ich aber gesagt, statt der Timeout-Meldung einfach ein Hinweis, dass der Befehl abgesetzt wurde, das Ergebnis aber dauern kann.
Zitat von: drhirn am 05 Juli 2022, 16:02:40
Weil?
Nach meinem Verständnis wird der laufende scan (oder besser: der reguläre Ablauf in der firmware) dadurch unterbrochen.
Ich empfinde das einfach als "unschön", wenn man "eigentlich" (im Normalfall) genausogut warten könnte, bis es in den Ablauf paßt (und ggf. das Device nicht extra geweckt werden muss)...
Ich komme von CUL_HM, und da vermeide ich "burst", wo es geht. Ist zwar vermutlich nicht 1:1 vergleichbar, aber "was Hänschen ...".
Zitat
Ansonsten hätte ich aber gesagt, statt der Timeout-Meldung einfach ein Hinweis, dass der Befehl abgesetzt wurde, das Ergebnis aber dauern kann.
Was kommt, steht afaik hier: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_MQTT2_DEVICE.pm#L378
Kann man sicher auch was anderes hinschreiben, aber ich finde es eigentlich ausreichend...
ZitatAnsonsten hätte ich aber gesagt, statt der Timeout-Meldung einfach ein Hinweis, dass der Befehl abgesetzt wurde, das Ergebnis aber dauern kann.
"get batteryPercent" nach "set requestBatteryPercent" umbauen?
Zitat von: rudolfkoenig am 05 Juli 2022, 16:15:22
"get batteryPercent" nach "set requestBatteryPercent" umbauen?
Gibt es "im Prinzip" schon im attrTemplate, heißt dort nur "set ... beep" ;) , was auch Sinn ergibt, wenn man ein Gadget hat, das auf die Batterie-Abfrage tatsächlich anfängt zu piepsen.
Könnte man sicher auch irgendwie umdrehen, aber so herum kommt es mir weiter (für mein Gadget) sinnvoll vor...
Hallo zusammen,
ich habe mir diesen Thread komplett durchgelesen - hui - das ist sehr komplex für mich als User.
Es geht um die Presence Erkennung mit den G-Tags (ohne Piepser).
Ich habe den ESP32 (installiert über Web ist die OMG Firmware 1.7.0, Typ esp32dev-ble-mqtt-undecoded) am Laufen.
Mit der hervorragenden Doku im Wiki, vielen dank dafür, konnte ich OMG in FHEM installieren. Die G-Tags werden erkannt und melden RSSI Werte.
Kleine Abweichung: Im verwendeten template OpenMQTTGateway_MCU wird ein Reading "Sys_version" erzeugt, im "stateFormat" des Templates jedoch "version" verwendet. Das habe ich manuell geändert.
a) Batterie-Readings kommen nicht FHEM an. Info: Mit einem BLE Scanner (u-Blox BLE) am iPhone werden die Batteriewerte der G-Tags erst nach "Connect" angezeigt. Ansonsten nur RSSI.
Timeout Meldung:
get OMG_7C2F80ADBCDC battery_Percent
Timeout reading answer for DEV_TPC/commands/MQTTtoBT/config {"ble_read_address":"7C:2F:80:AD:BC:DC","ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX"}
b) Das "present" Device "OMG_7C2F80ADBCDC_presence" macht alle 30 Sekunden ein Update vom STATE.
Der State bleibt aber unbestimmte Zeit auf "absent" oder "present", auch wenn der G-TAG abgeschirmt/erreichbar ist.
Kann man das Verhalten in FHEM einstellen?
Info: Parallel meldet mein lepresence Device (model lan-lepresenced) "absent" oder "present" nach 30 Sekunden.
VG Helmut
Hallo Helmut,
ich hatte mir zwar mal ein G-Tag für den Zweck geholt, aber nie in Betrieb genommen. Aktuell nutze ich Mi Bands in verschiedenen Versionen dafür. Grundsätzlich dürfte das kein großer Unterschied sein.
In der Funktion des Presence-Geräts steht der Standardwert von 300 Sekunden für die Prüfung auf Abwesenheit. Das kann man man über das Attribut maxPresenceAge im MQTT-Device anpassen.
Laut einem älteren Issue auf github sollte der Batteriestand mittlerweile gelesen werden können. Ich weiß aber nicht, ob das manuell per Get ausgelöst werden kann. Bei anderen Geräten (beispielsweise den Xiaomi Flower Sensoren) wird auch kein Batteriestand im Advertisement übertragen, der muss von OMG aktiv beim Gerät abgefragt werden. Das passiert dann in einem größeren Intervall als die anderen Werte übertragen werden. Aber automatisch, ohne dass man was machen müsste.
Viele Grüße
Thomas
Viele Grüße
Thomas
Hallo Thomas,
vielen Dank für's Antworten.
Das Attribut maxPresenceAge gibt es bei mir über Dropdown nicht.
Ich habe den Wert direkt in der Def geändert:
defmod OMG_7C2F80ADBCDC_presence PRESENCE function { my $maxage = AttrVal("OMG_7C2F80ADBCDC","maxPresenceAge","32");;;; ReadingsAge("OMG_7C2F80ADBCDC","last_IO","100000") < $maxage ? 1 : 0 }
P.S. bei maxPresenceAge "30" geht das Teil dauernd auf absent, bei "82" leider auch.
Versuche mal 40 Sekunden.
Weißt du, was die "100000" bei ReadingsAge bedeutet?
Das Batterie Reading ist mir nicht so wichtig. Dafür nutze ich bislang (das alte lepresence Script konnte das nicht) ab und zu die u-Blox App.
Viele Grüße,
Helmut
Da muss es also noch weitere Timing Zusammenhänge geben.
Eventuell im MQTT2_OMG_ESP32_BLE Device?
Ich habe mal so drauflos (Doku irgendwo?) das BT_scan-Interval auf 30 gesetzt.
Mal abwarten......
Die "100000" sind ein Default-Wert, falls der Wert nicht gelesen werden kann. Genauso wie die 300 bei maxage. Dort halt, falls maxPresenceAge im Device nicht gesetzt ist. Dann wird nichts gelesen und 300 genommen.
Ob Du mit dem Scan-Interval was änderst, weiß ich nicht. Generell ist es bei den Beacons ja so, dass die in regelmäßigen Abständen von sich aus das Advertisement schicken. Ein kürzeres Intervall könntest Du dann nur erreichen, wen Du diese Einstellung im G-Tag ändern könntest (ginge dann aber auch auf die Batterie). Die "Abwesenheitserkennung" (in Anführungszeichen, weil nur die Anwesenheit aktiv erkannt wird) funktioniert dann so, das geprüft wird, ob in einem Intervall, das größer ist als das Sendeintervall, noch etwas empfangen wurde. Falls das Tag auch mal außerhalb der Reichweite sein kann oder etwas dazwischen der Empfang unterbrochen werden kann, muss da dann noch Puffer eingebaut werden. Ich fahre mit den 5 Minuten eigentlich ganz gut. Hängt halt davon ab, was Du bei Abwesenheit auslösen willst. Bei Licht, Heizung usw. dürften die 5 Minuten kein Problem sein.
Moin Thomas,
ich steuere u.a. meine "Offene Fenster" etc. Hinweise damit. Daher muss ich so mit 30 Sekunden oder auch 60 Sekunden zurechtkommen. Wenn ich mit dem Auto schon weg bin und die Meldung kommt, ist es oft unbequem, wieder nach Hause zu fahren. Deswegen habe ich die notwendigen Infos zu offenen Fenstern von Mail (bis zu 20 Minuten Latenz) auf NTFY umgestellt. Das läuft super, Latenz nur im Sekundenbereich für alle Endgeräte.
Mit BT_scan-Interval auf 30 und maxPresenceAge auf 30 komme ich jetzt recht gut zurecht.
Zum Testen habe ich ein temporäres Logfile angelegt, da kommen aktuell von 2 Tags alle 30 Sekunden Presence Meldungen ohne Aussetzer an.
Leider werden die Settings im MCU Device nicht gespeichert. nach Stromausfall muss ich die Parameter für BT_scan-Interval auf 30 usw. neu setzen.
Das Ganze ist somit in der aktuellen Form nicht wirklich so zuverlässig wie mit lepresenced.
Die G-Tags feuern permanent (im Prinzip) oder im Sekundentakt (u-Blox findet die beim Scan sofort), solange sie nicht gepaired sind.
VG Helmut
Hi Helmut,
prima, wenn Du eine Lösung gefunden hast. Wie setzt Du das Interval? Per MQTT? Funktioniert das dann nicht dauerhaft mit Retain-Flag? So mache ich das mit der White-List (um nur meine eigenen Geräte auszuwerten), die übersteht einen Neustart. Je nach Lage ist die Whitelist übrigens eine generelle Empfehlung. Ich hatte Anfangs Probleme mit der Stabilität wegen der vielen vorbeikommenden Sender.
Zitat von: isy am 15 März 2024, 11:12:42ich steuere u.a. meine "Offene Fenster" etc. Hinweise damit.
Das mache ich über einen Türkontakt an der Haustür und einen alten FS20-SIG in der Steckdose direkt daneben ;-) Klar, nicht jedes Öffnen der Tür ist ein Weggehen, aber wir kommen ganz gut damit klar.
Viele Grüße
Thomas
Zitat von: isy am 15 März 2024, 11:12:42Leider werden die Settings im MCU Device nicht gespeichert. nach Stromausfall muss ich die Parameter für BT_scan-Interval auf 30 usw. neu setzen.
Das Ganze ist somit in der aktuellen Form nicht wirklich so zuverlässig wie mit lepresenced.
Hallo @isy
Meinst du hier die OpenMQTTGateway BT_scan-Interval etc. Parameter?
Falls ja, dann können alle OpenMQTTGateway Parameter auch im Flash abgespeichert werden, damit sie bei einem Neustart (Stromausfall) auch wieder geladen werden.
https://docs.openmqttgateway.com/use/ble.html#store-ble-configuration-into-the-gateway
Würde für FHEM bei OpenMQTTGateway auch eine
general_presence Implementation helfen, wie wir zusammen mit @Jamos Hilfe für Theengs Gateways eingeführt haben, mit
"presence":"present" und
"presence":"absent" nach einem definierten
timeout?
Zitat von: tomcat.x am 15 März 2024, 11:35:55Hi Helmut,
prima, wenn Du eine Lösung gefunden hast. Wie setzt Du das Interval? Per MQTT? Funktioniert das dann nicht dauerhaft mit Retain-Flag? So mache ich das mit der White-List (um nur meine eigenen Geräte auszuwerten), die übersteht einen Neustart. Je nach Lage ist die Whitelist übrigens eine generelle Empfehlung. Ich hatte Anfangs Probleme mit der Stabilität wegen der vielen vorbeikommenden Sender.
Zitat von: isy am 15 März 2024, 11:12:42ich steuere u.a. meine "Offene Fenster" etc. Hinweise damit.
Das mache ich über einen Türkontakt an der Haustür und einen alten FS20-SIG in der Steckdose direkt daneben ;-) Klar, nicht jedes Öffnen der Tür ist ein Weggehen, aber wir kommen ganz gut damit klar.
Viele Grüße
Thomas
Hi Thomas, ich setze das Timing über MQTT. Das mit dem Retain Flag schaue ich mir an, das kannte ich bislang nicht. Auch eine Whitelist wäre interessant.
Wie setzt man das Retain Flag?
VG Helmut
Zitat von: DigiH am 15 März 2024, 11:43:19OpenMQTTGateway BT_scan-Interval etc. Parameter?
Moin DigiH,
--> Ja genau.
Parameter im Flash speichern, das schaue ich mir an.
Würde für FHEM bei OpenMQTTGateway auch eine general_presence helfenUser hier im Forum suchen nach einer stabilen und vor allem räumlich flexiblen Lösung. Da ist OpenMQTTGateway auf einem ESP eine sehr interessante Option.
Aktuell geht eine Presence Funktion mit den im Wiki vorliegenden Templates bis auf meine Timing Anforderungen ja super. Die Lösung ist also vorhanden, für User ohne Programmier-Hintergrund allerdings nicht so einfach zu implementieren. Wenn es dazu eine einfachere Implementierung gäbe, wäre das für alle nicht schlecht.
VG Helmut
Ich habe erst einmal einen Decoder für die G-Tags erstellt und gemerged, damit sie in Zukunft auch automatisch als Device Tracker erkannt werden.
https://github.com/theengs/decoder/pull/524
Alle OpenMQTTGateway Einstellungen können über direkte MQTT Befehle geändert werden und mit der
"save":true Funktion (load, init, erase) auch über Neustarts im Flash gesichert werden. Eine Ausnahme hier ist eine white- oder black-list, welche über eine retained MQTT Message nach jedem Neustart wieder an OpenMQTTGateway gesendet wird.
ZitatUser hier im Forum suchen nach einer stabilen und vor allem räumlich flexiblen Lösung. Da ist OpenMQTTGateway auf einem ESP eine sehr interessante Option.
Da wir an OpenMQTTGateway und Theengs Gateway mehr oder weniger parallel arbeiten sind viele Funktionen identisch, aber auch unterschiedlich, wie mit den Encrypted Decoding und Identity MAC/IRK Funktionen von Theengs Gateway. Und da OpenMQTTGateway auch als Proxy für Theengs Gateway arbeiten kann, wollte ich es nur erwähnt haben, da diese neuen Funktionen noch wenigen bekannt sein dürften :)
Zitat von: isy am 15 März 2024, 12:21:52Whitelist
Habe ich gefunden:
set MQTT2_OMG_ESP32_BLE BT_whitelist "XX:YY:AA:BB:CC","DD:FF:EE:AA:00:03"
Noch eine Frage an die Spezialisten, für mich ist das direkte Senden von MQTT Befehlen Neuland.
Ich möchte die drei nachfolgenden Parameter "retained" im Gateway ablegen.
Im Forum hier habe ich ein Beispiel für die Whitelist (funktioniert) gefunden, die anderen Befehle haben ich analog aufgebaut.
Geht das so? Bzw. Kann ich nachlesen, wie der Syntax aussieht?
"Whitelist"
set MyMQTT publish -r home/OMG_ESP32_BLE/commands/MQTTtoBT/config {"white-list":["7C:2F:80:AD:BB:45","7C:2F:80:AD:BC:DC"]}
"Alle 30 Sekunden Scan"
set MyMQTT publish -r home/OMG_ESP32_BLE/commands/MQTTtoBT/config {"interval":30}
"min RSSI"
set MyMQTT publish -r home/OMG_ESP32_BLE/commands/MQTTtoBT/config {"minrssi":-95}
ZitatIch möchte die drei nachfolgenden Parameter "retained" im Gateway ablegen.
Nur die white-list muss als retained Message im Broker gespeichert werden, korrekt mit
set MyMQTT publish -r home/OMG_ESP32_BLE/commands/MQTTtoBT/config {"white-list":["7C:2F:80:AD:BB:45","7C:2F:80:AD:BC:DC"]}Alle anderen Config Commands müssen direkt an die Gateway gesendet werden und können dann im Flash abgespeichert werden, damit sie beim nächsten Neustart geladen werden. Dies kann auch alles in Kombination gesendet werden, aber ohne retained halt, und die Intervalle ("interval" - passives Scaninterval / "intervalacts" - aktives Scaninterval) werden in Millisekunden angegeben.
set MyMQTT publish home/OMG_ESP32_BLE/commands/MQTTtoBT/config {"interval":30000, "minrssi":-95, "save":true}
Danke für den Tipp!
Der Einstig ist nicht so ganz easy. Hi!
Dank eurer Tipps habe ich jetzt das OMG mit meinen Timing Anforderungen in Betrieb.
- Whitelist am mqtt2 eingetragen:
set MyMQTT publish -r home/OMG_ESP32_BLE/commands/MQTTtoBT/config {"white-list":["00:11:22:33:44:45","AA:AB:AC:AD:AE:AF"]}
- "Alle 30 Sekunden Scan" und "minrssi -95" im OMG Flash gespeichert. Überprüfung zum Erfolg über "Information" am WebUI des ESP32:
set MyMQTT publish home/OMG_ESP32_BLE/commands/MQTTtoBT/config {"interval":30000, "minrssi":-95, "save":true}
- Presence laut Wiki Eintrag eingerichtet:
defmod OMG_AABBCCDDFF_presence PRESENCE function { my $maxage = AttrVal("OMG_AABBCCDDFF","maxPresenceAge","45");;;; ReadingsAge("OMG_AABBCCDDFF","last_IO","100000") < $maxage ? 1 : 0 }
Über ein Logfile schaue ich mir an, ob das Konstrukt stabil funktioniert.
Hier das Ergebnis von meinem Test, wie FHEM/OMG reagieren, wenn ein BT-Tag außer Reichweite kommt:
--> Beim Erreichen meines Grenzwertes geht FHEM auf "absent", denn lt. OMG Console kommt kein "Send" String mehr.
Meinen bisherigen minrssi Wert von -95 habe ich daher wieder auf -110 runtergesetzt, das erhöht die Reichweite um das Haus herum.
Ich überlege, ob ich eine "Presence" Info per DOIF über das Reading der rssi Werte vom MQTT2_OMG_ESP32_BLE Device direkt realisiere. Mal sehen.
Beste Grüße,
Helmut