I have set up the OMG on a ESP32C and this is currently reading a BM2 reading both % and voltage correctly and reporting this to Home Assistant. I have also enabled the publishing of HASS presence but have not fully set this up.
The problem I have is that when the OMG connects to the BM2 to read and report the voltage every hour, it erroneously reports that the device is away for a few seconds in HA.
I find this very odd behaviour and a bit annoying. Is there a way to fix this?
What if you do not activate HASS presence …
… but use the auto-discovered BLE device_tracker for the BM2?
With its default 2 minutes presenceawaytimer before being reported as AWAY, the few seconds of connection to fetch the voltage value should not really trigger it.
Could you also post your BTtoMQTT settings, especially for presenceawaytimer, interval and scanduration?
Also, is your ESP32C OMG gateway the only BLE OMG gateway you have?
Hello DigiH
It was getting many more home/away changes before I enabled the HASS presence reporting. I put that down to the more rapid scanning.
It now only happens when connecting to the BM2 to acquire the voltage.
Either on the hourly connection or when clicking force scan.
I tried changing the presenceawaytimer to 3 minutes and it didnt make any difference.
Below is the output on the information screen on the OMG module, you can see its been up for just over 3 days, so it doesn’t look like it is crashing.
It feels like when it reads the voltage it sends away in the MQTT packet with the voltage reading, you can see the MQTT packet at the bottom
### [“WebUI”,“BT”]
## OMG_ESP32C3_BLE_Garage
|uptime|291080|
| — | — |
|version|“417d28”|
|rgbb|0|
|disc|false|
|ohdisc|false|
|env|“esp32c3_lolin_mini_with_serial”|
|freemem|84972|
|mqttp|“1883”|
|mqtts|false|
|mqttv|false|
|msgprc|1203763|
|msgblck|2|
|maxq|1766154780|
|cnt_index|1|
|minmem|24224|
|freestck|3128|
|eth|false|
|rssi|-75|
|ip|“192.168.2.184”|
|mac|“48:CA:43:CC:CB:24”|
|lowpowermode|-1|
|modules|“‘WebUI’, ‘BT’”|
|origin|“/SYStoMQTT”|
|BT||
|bleconnect|true|
|interval|100|
|adaptivescan|false|
|intervalacts|100|
|intervalcnct|3600000|
|scanduration|1000|
|onlysensors|false|
|randommacs|false|
|hasspresence|true|
|prestopic|“presence/”|
|presuseuuid|false|
|minrssi|-100|
|extDecoderEnable|false|
|extDecoderTopic|“undecoded”|
|filterConnectable|false|
|pubadvdata|false|
|pubuuid4topic|false|
|ignoreWBlist|false|
|presenceawaytimer|180000|
|movingtimer|60000|
|forcepscn|false|
|tskstck|1820|
|crstck|2788|
|enabled|true|
|scnct|245606|
|WebUI||
|displayMetric|true|
|webUISecure|true|
|displayQueue|0|
When I look on OMG console below is the MQTT message i see for the voltage reading, it only includes “model”, “id” and “volt”. It is the only message sent to MQTT that does not include “rssi” and “distance”, could that be the reason? Most BM2 packets also have “name” except for this volt packet and the one prior to this.
It is also the only message not to have id first in the MQTT packet which is a bit odd.
N: Send on /BTtoMQTT/50547B80D66F msg {“model”:“BM2 Battery Monitor”,“id”:“50:54:7B:80:D6:6F”,“volt”:13.46}
Do you have any other BLE devices you are receiving data from, which require constant scanning?
If not you should set
|interval|100|
and
|intervalacts|100|
to their default values of 55555, or something more appropriate to your setup.
Also |scanduration|1000| should then be set to 10000.
Then turn off HASS presence, and leave your |presenceawaytimer|180000|, i. e. at 3 minutes.
Could you also try all this by installing the latest development test version, as this is the code I’m currently looking at
And yes, this is how device trackers are defined, by their RSSI key presence. So definitely something we’ll need to look into for the messages of not only the BM2, but all other device tracker compatible devices which do have connection dependant messages without the RSSI key.
ACTUALLY - if you could hold on with installing the development test build for another 90 minutes or so. I am just starting new test build which should also fix the missing rssi key in the voltage message, which should be ready by then.
The new test build will be available under the same link as above, but will have SHA: 7709d0 instead showing at the top of the page.
OK I will try the development version in a bit and let you know.
I was planning on using the HASS presence detection on the OMG and the settings were changed to these values once I enabled it. I just assumed it was scanning as often as possible to detect tracker movement, but I can increase them once I try the development one. I will turn it off while testing if needed.
This is the first OMG I have set up and currently it is only connecting to the one Bluetooth sensor, but I have a few more on order, some more BM2s as well as a few inkbird IBS-TH2, but I know the HA BLE proxy will connect to the latter directly if needed.
The BM2 issues should be fixed with the said test build, but be aware that it will be overwritten by the nightly development builds at around 02:00 hours UTC tonight, which will not have the 7709d0 changes.
The Inkbirds IBS-TH2 will also be recognised and auto-discovered by OMG when you get them.
OK I think I have set it up now with all the setting as orginally posted and it seems to work when clicking force scan. I will leave it to run over night to double check the automatic voltage updates work etc.
I get the following message in the console when clicking force scan, and it is stays in the “home” state now.
N: Send on /BTtoMQTT/50547B80D66F msg {“model”:“BM2 Battery Monitor”,“id”:“50:54:7B:80:D6:6F”,“volt”:13.46,“rssi”:-60}
I assume it just needs the rssi value in the message then?
Correct, and with this voltage message it is just a placeholder rssi value to not trigger an AWAY state.
You should now also have the BT: Presence/Tracker timeout setting correctly auto-discovered for your gateway HA UI.
OK thanks I will update you tomorrow
Jumping in, seeing similar behaviour. Not only but also with BM2. All OMG tracked devices behave like this, some even more crazy.
BM2:
In red box: A fitness tracker while not moving at all, sitting 2 meters and one wall away of an OMG.
Useless 
As these non-BM2 drop-outs are most definitely setup dependant, we’re still missing some useful information from you
• How many different OMG/Theengs Gateway BLE gateways on your system?
• Which firmware versions?
• BTtoMQTT settings for interval, intervalacts, scandurarion and presenceawaytimer for all existing BLE gateways?
Everything has been said already - not yet on every place. So here, once again:
2 OMGs, 1 TG.
OMG #1: v1.7.0
OMG #2: v1.7.0
TG: v1.11.0
Specifically the BM2 is only in reach of OMG #1. Therefore the OMG #1 settings should be sufficient, anyway here’s everything for all gateways as requested (and many more):
OMG #1:
{"bleconnect":true,"interval":60000,"adaptivescan":false,"intervalacts":60000,"intervalcnct":6000000,"scanduration":10000,"onlysensors":false,"randommacs":false,"hasspresence":true,"prestopic":"presence/","presuseuuid":false,"minrssi":-100,"extDecoderEnable":false,"extDecoderTopic":"undecoded","filterConnectable":false,"pubadvdata":false,"pubuuid4topic":false,"ignoreWBlist":false,"presenceawaytimer":360000,"movingtimer":60000,"forcepscn":false,"tskstck":1796,"crstck":3016,"enabled":true,"scnct":9164}
OMG #2:
{"bleconnect":true,"interval":30000,"adaptivescan":false,"intervalacts":30000,"intervalcnct":3600000,"scanduration":1000,"onlysensors":false,"randommacs":false,"hasspresence":true,"prestopic":"presence/","presuseuuid":false,"minrssi":-100,"extDecoderEnable":false,"extDecoderTopic":"undecoded","filterConnectable":false,"pubadvdata":false,"pubuuid4topic":false,"ignoreWBlist":false,"presenceawaytimer":360000,"movingtimer":60000,"forcepscn":false,"tskstck":1828,"crstck":3016,"enabled":true,"scnct":2240}
TheengsGateway:
Not visible (Home Assistant addon), completely different MQTT topic design compared to OMGs.
Not quite, and this is very likely the root problem for you, as OMG #2, as well as Theengs Gateway, must be able to receive the BM2 every now and then briefly, even if it’s a long way away from them. Then whenever it is out of reach of OMG #2 and TG again there will be an offline/Away message issued - in addition to the hourly connection issue addressed above.
The very same will also happen with your fitness tracker. This is documented as current expected behaviour at
with
If you have multiple gateways, your BLE trackers may …
For the BM2 you should have it recognised as is only for the closest OMG #1, but definitely put it on a black-list for OMG #2 and TG (once the Add-on version has been updated with the latest Theengs Gateway version 1.5.0 which allows for white- and black-lists)
Then with OMG #1 also having the above mentioned addressed SHA: 7709d0 fix, you will see a constant HOME for your BM2.
With the Mi Band details being set up the same it should also show up without any unwanted drop outs.
You can easily verify my above theory by having MQTT Explorer run for a while, then whenever you see the next drop out in HA, have a look at the three different gateway’s MQTT messages for the BM2 and Mi Band ID - very likely that either OMG #2 or TG are issuning the offline/AWAY command due to their further distance.
Hello DigH.
Just to confirm it has been working all night.
I was just looking at your github commit and I can see how you fixed it, and as you say looks like all the devices with a connection have the same issue.
I plan to program up a few more OMG nodes in the coming weeks.
So will this fix be pushed into all the development releases or will that wait for a more generic fix?
(The above discussion on multiple nodes made me read how to implement white/blacklisting which I will need for some devices)
Thanks for your help.
Hi @iotola
Thanks for bringing this to our attention and for the confirmation of the fix.
Luckily the BM2 is actually the only connection device which is also discovered as a BLE device tracker.
The PR is up for review, and should hopefully be merged as is, or with slight amendments, into development soon.
You might also want to look into the [esp32dev-ble-mqtt-undecoded] environment/binary working in conjunction with Theengs Gateway (HA Add-on) for any device tracker or other devices which do not require a connection for value retrieval - which are actually most of the compatible BLE devices - for covering a larger area, but without any possible offline status/AWAY tracker issues.
I did look into the Theengs gateway, but I have a bunch of small esp32c3’s which I was planning to use but given they are RISC/V based I didn’t think the [esp32dev-ble-mqtt-undecoded] would work as the processor is the Xtensa LX6.
I could not see an equivalent binary for mqtt-undecoded for the esp32c3.
Am I missing something?
`
The other question I had about the Theengs gateway on HA and using mqtt_decoded nodes was would this work with MQTT room presence?
As the only difference between the standard [env:esp32dev-ble] and [env:esp32dev-ble-mqtt-undecoded] is the additional build_flag
'-DMQTTDecodeTopic="undecoded"'
this can be added to any other environment to have it send undecoded MQTT messages, which are automatically being picked up by any Theengs gateway instance for decoding.
With the existing build_flag MQTTDecodeTopic actually setting UseExtDecoder to true for custom builds …
For extra smooth convenience 
this is also possible to activate or deactivate with MQTT commands during run time.
This is currently the best solution when wanting to use a device tracker with extended range reception through the undecoded ESP32 proxies, when no device connection is required.
For picking up your Inkbirds and other similar sensors this is not really required, and standard decoded ESP32 OMG gateways will be great.
For room presence you will need the standard decoding ESP32 gateways, not undecoded ones, and have Presence turned on for all of then, which is not required for your BM2 white-listed gateway.
Hope this clarifies things a bit more.
How to best combine OpenMQTTGateway, with which binaries/custom environment builds and white-and black-lists, and Theengs Gateway all really depends on the devices one has and how to want to use and integrate them into a controller.
Thanks that was a really helpful explanation. I will play around with the different combinations.
