OpenMQTTGateway support thread - im Speziellen: BT/BTLE

[MadMax-FHEM]

@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

[ares]

@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.

Code Auswählen Erweitern

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?

Code Auswählen Erweitern

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

[MadMax-FHEM]

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   )

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

[ares]

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.

[Beta-User]

...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).

[ares]

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!

[MadMax-FHEM]

@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

[kroman]

EDIT: whitelist geschafft!

Super! Dafür, dass du schon länger etwas anderes machen wolltest, bist du eh sehr fleißig 

[kroman]

Hallo Beta-User,

ich habe in meinem G-Tag device die readingList damit erweitert:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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.:

Code Auswählen Erweitern


battery {hex(ReadingsVal("$name","OMG1_read",0))}


Mit diesem userReadings passt der Zeitstempel:

Code Auswählen Erweitern


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.

[MadMax-FHEM]

Super! Dafür, dass du schon länger etwas anderes machen wolltest, bist du eh sehr fleißig 

Tja...
"Hängengeblieben"

Aber dafür: FERTIG!
(inkl. FileLog und Graph)

Jetzt mal sehen, ob ich mich freue mein Gewicht zu "observieren"...

Danke an alle!

Gruß, Joachim

[ares]

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.

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

[MadMax-FHEM]

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.

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:

Code Auswählen Erweitern


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

[MadMax-FHEM]

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

[ares]

Ja, es wird nur noch gesendet, wenn bzgl. der whitelist-MAC was gescannt wird, also schon auf dem Gateway.

Geht so:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern

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.

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

[Beta-User]

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

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

Code Auswählen Erweitern

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

Muss nur überlegen, wie ich das vertemplated bekomme.

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