OpenMQTTGateway support thread - im Speziellen: BT/BTLE

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

Vorheriges Thema - Nächstes Thema

isy

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
Ein Weg wird erst zu einem Weg, wenn man ihn geht

tomcat.x

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
FHEM: 6.3 auf Raspi 3B+, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 7.57), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

DigiH

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?


isy

#123
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
Ein Weg wird erst zu einem Weg, wenn man ihn geht

isy

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 helfen
User 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


Ein Weg wird erst zu einem Weg, wenn man ihn geht

DigiH

#125
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 :)

isy

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"
Ein Weg wird erst zu einem Weg, wenn man ihn geht

isy

#127
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}
Ein Weg wird erst zu einem Weg, wenn man ihn geht

DigiH

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}

isy

Danke für den Tipp!
Der Einstig ist nicht so ganz easy. Hi!
Ein Weg wird erst zu einem Weg, wenn man ihn geht

isy

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
Ein Weg wird erst zu einem Weg, wenn man ihn geht

rspecht

Moin zusammen,

ich hab mir gestern mal ein ESP32 mit esp32dev-ble in der Version v1.7.0 per Web geflashed - das ist echt simpel. Dann wie gewohnt bei ESP Projekten mit dem Handy auf die 192.168.4.1 und alles eingestellt. Danach war schon ein Device auf FHEM (Autocreate) und es rasselten BLE readings rein.

Soweit so toll - ein großes Lob an die Erbauer dieser ganzen Softwarekomponenten. Auch die Doku ist echt gut.
Ich hab nun so BLE Batterie Monitore in die Fahrzeuge gebaut und will die nun einbinden, dazu hole ich mir u.a. Infos aus dem YT Video von Tobias Schrämper: https://www.youtube.com/watch?v=uyMceIZLs5s

Er arbeitet auf einem Raspi und sucht sich erstmal die IDs mit hcitool. Den Teil kann ich überspringen da ich die IDs kenne und mein Testgerät hier auf dem Schreibtisch ist auch schon von dem ESP daneben gescant worden.
Dort erscheint er auch als BM6 Tracker und hat seit heute nacht ein neues Reading: battery Percent: 100. Das ist auch real da ich 13.2V dran anliegen habe.

Bis hier her ging alles recht flüssig.
Dann wird im Video mit gatttool eine Anfrage abgesetzt: -b ID --char-read -a 0x0025 - worauf der Batteriemonitor eigentlich einen Report auswefen sollte.

Das hab ich mir wie folgt (auch mit den Posts hier und dem Wiki) umgemünzt:
query:noArg { my $id = ReadingsVal($NAME,'id','383Bblubb');; qq(home/OMG_ESP32_BLE/commands/MQTTtoBT/config {"ble_read_address":"$id","ble_read_service":"180f","ble_read_char":"0025","value_type":"HEX","immediate":true, "ttl":2}) }
Darauf hin kommen 2 neue Zeilen ins LOG des ESP32 (abgefragt per Website):
N: [ MQTT->OMG ]: {"ble_read_address":"meine BT ID :)","ble_read_service":"180f","ble_read_char":"0025","value_type":"HEX","immediate":true,"ttl":2}
N: Send on /BTtoMQTT msg {"bleconnect":true,"interval":55555,"adaptivescan":true,"intervalacts":55555,"intervalcnct":3600000,"scanduration":10000,"onlysensors":false,"randommacs":false,"hasspresence":false,"prestopic":"presence/","presuseuuid":false,"minrssi":-100,"extDecoderEnable":false,"extDecoderTopic":"undecoded","filterConnectable":false,"pubadvdata":false,"pubuuid4topic":false,"ignoreWBlist":false,"presenceawaytimer":120000,"movingtimer":60000,"forcepscn":false,"tskstck":2592,"crstck":3012,"enabled":true,"scnct":616}

Ich vermisse nun aber irgendwelche Connect Zeilen im Log oder Updates in FHEM.

Bin ich hier irgendwo falsch abgebogen? Oder stehe ich kurz vorm Ziel und sehe selbiges nicht?
Bitte helft mir einen Schritt in die richtige Richtung.

Danke :)

Beta-User

Nach der Doku (https://docs.openmqttgateway.com/use/ble.html#example-write-command) geht das nicht an den "config"-Endtopic, sondern "nur" an (angepaßt)
home/OMG_ESP32_BLE/commands/MQTTtoBT
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rspecht

Zitat von: Beta-User am 10 Juni 2024, 12:39:34Nach der Doku (https://docs.openmqttgateway.com/use/ble.html#example-write-command) geht das nicht an den "config"-Endtopic, sondern "nur" an (angepaßt)
home/OMG_ESP32_BLE/commands/MQTTtoBT

Wie war das mit dem Wald und den Bäumen... Danke :)
Jetzt springt der ESP direkt an:
N: [ MQTT->OMG ]: {"ble_read_address":"38:blubb","ble_read_service":"0025","ble_read_char":"0025","value_type":"HEX","immediate":true,"ttl":2}
N: BLE Connect begin
N: Failed to find service UUID: 0x0025
N: Failed to find service UUID: 0x0025
N: Send on /BTtoMQTT/38blubb msg {"id":"38:blubb","service":"0x0025","characteristic":"0x0025","success":false}
N: BLE Connect end

Jetzt muss ich nur noch die richtige service und characteristic finden...
Der Battery Guard meldet sich sowieso alle 10 Minuten mit dem Batteriestand - das passt auch soweit. 46% meldet er aktuell bei 12,3V - deckungsgleich zur App. Die Spannung und Temperatur Versuche ich ihm aber noch zu entlocken.

Beta-User

Zitat von: rspecht am 10 Juni 2024, 15:09:03Wie war das mit dem Wald und den Bäumen... Danke :)
Gerne!

Dass man sich in so einem "komischen" Umfeld auch mal verheddern kann, finde ich völlig ok!

PS: Danke für die Rückmeldung zum Wiki etc.. Nach meinem Eindruck ist das alles alles andere als einfach zu verstehen, von daher: Hut ab, dass du alleine bis dahin gekommen bist!

Falls das irgendein Device ist, das von "allgemeinem Interesse" ist: her damit! Wir haben für OMG mAn. noch etwas wenig Beispiele, was man damit alles anfangen kann...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files