OpenMQTTGateway support thread - im Speziellen: BT/BTLE

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

Vorheriges Thema - Nächstes Thema

drhirn

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

Beta-User

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

drhirn

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.

Beta-User

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

drhirn

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?

Beta-User

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

drhirn

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.

Beta-User

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

rudolfkoenig

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?

Beta-User

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

isy

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

tomcat.x

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
FHEM: 6.1 auf Raspi 3, 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

isy

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

isy

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

tomcat.x

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.
FHEM: 6.1 auf Raspi 3, 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