Reduce Latency for Beacon Button Press and PIR

1

I have a Blue Charm BC021 beacon with a programmable button. Also a Switchbot Smart Motion/Door Sensor. When I use KBeacon on my phone to watch the output of the Blue Charm beacon button press, the response is estimated to be less than 100ms. The output from OpenMQTTBridge to my MQTT broker being monitored with MQTT Explorer and a bespoke python script takes anywhere from about 1.5 to 8 seconds to respond with quite a bit of variation.

My use case is that I would like to turn a light ON/OFF with the beacon button going through the MQTT broker and controlling a Tasmota socket with Node-Red or a bespoke script. When someone clicks a button to turn ON/OFF a light, they expect a response in a second or less. Anything other than that is very confusing for the user.

I have set a whitelist for the three BLE devices I have locally. There is also a Govee Temp/Humidity sensor that is working fine and is not fussy about latency. I have tried turning AdaptiveScan ON and OFF, but it does not seem to affect the latency for a beacon switch press.

I set interval and intervalacts to 1ms, but as soon as I set AdaptiveScan True they are both set to 100ms by the firmware. I am also monitoring the serial output of the OpenMQTTGateway and see that even though there is a whitelist for the three devices in my location, it is scanning for and picking up other devices. It is not publishing them to MQTT, but it is taking the time to scan for them.

The interval between the N: Scan Begin messages is 10 seconds.

Here are my current settings copied from MQTT Explorer:
{“bleconnect”:false,“interval”:1,“adaptivescan”:false,“intervalacts”:1,“intervalcnct”:3600000,“onlysensors”:false,“hasspresence”:false,“presenceTopic”:“presence/”,“presenceUseBeaconUuid”:false,“minrssi”:-100,“extDecoderEnable”:false,“extDecoderTopic”:“undecoded”,“filterConnectable”:false,“pubadvdata”:false,“pubBeaconUuidForTopic”:false,“ignoreWBlist”:false,“btqblck”:3,“btqsum”:94023,“btqsnd”:92812,“btqavg”:1.013048}

Is there any way to improve the latency for button presses and PIR events? I am using the latest version 1.4 of the esp32dev-ble image.

Many thanks for the very useful suite of gateways. I’m also using the 433Mhz version on a LilyGo board with display and it is working well.

2

Hi @dennyfmn,

I set interval and intervalacts to 1ms, but as soon as I set AdaptiveScan True they are both set to 100ms by the firmware.

Adaptive scanning is to automatically detect the devices you have and adjust interval and intervalacts accordingly. If you have set these two manually AdaptiveScan should be set to false.

In addition to interval and intervalacts there is also the setting Scan_duration, which defaults to 10 seconds, which is what you are seeing. So setting this to anywhere between 500 and 1000 ms would fit your desired max. 1 sec reaction time.

Unfortunately this setting is currently only settable when doing a custom build with Platformio and not available through MQTT commands for pre-built binaries at runtime.

We are working on a solution though which should be available within the next days, so bear with us. :wink:

3

Wonderful! I’ll wait for the update. Thanks!

4

Hi @dennyfmn,

The runtime scanduration functionality has been merged and will be included in the nightly test build of OpenMQTTGateway.

You can do a web upload of the esp32dev-ble binary at

after around 8 pm your time. If you leave the Erase Flash check box unticked your settings should be kept with the new upload.

Setting your scanduration to 1000 (ms) will give you a 1 second latency at the most.

Would you mind sharing which protocol you use for your Blue Charm BC021 beacon, and how the button press is detected differently to it’s other regular ‘beacon’ broadcasts?

As we already have the Blue Charm BC08 included in Theengs Decoder, it might be interesting to add a new decoder for the BC021 as well, especially also for its button press recognition.

5

Very Cool! I will try this tomorrow and let you know what happens.
I’ll be happy to share anything I can on the Blue Charm BC021. The beacon seems to work quite well. Blue Charm recommends that you use KBeacon on your phone to set it up. He was very helpful when I first received it and painted myself into a corner. I think the beacon and button presses are working properly now. If we can get the OpenMQTTGateway latency down, that will e great!
Thanks!

6

Just some quick feedback. Once I figured out that I had to use the link to the development upload site, thinks started working. I did have to reflash the ESP32 and erase the memory. Somehow the whitelist was not working quite right. There was an extra BLE device being published. After starting from scratch and reloading all my settings I have a 1000ms scanduration. I haven’t had a change to tweak it let; I will do that later.
I will also follow up on details for the BC021. In short I’m using the default IBeacon protocol. I have the regular advertisements turned off, and only sending when the button is pushed. You can set it to advertise continuously if you wish. It can do single, double, tripple, and long press. I have single and double enabled. It identifies which press by adding a fixed number to the end of the UUID. More details later.
Thanks for your great and timely support!

1 Like
7

While I was more expecting a similar non-iBeacon protocol to the one we have implemented for the BC08, with it’s servicedata and serviceuuid, it would still be interesting to see what iBaocon messages your BC021sends out in MQTTExplorer. The fixed number to the end of the UUID is likely the major and minor sections changing, so that with these changes major/minor values the different button presses can be detected.

Looking forward to possibly seeing some of these MQTT Explorer messages.

Thanks

8

I have been running dev version c75470 for several days now and have some feedback.

If I set scanduration to anything less then 1000ms things stop working. It does not output anything on the serial except the status every two minutes and does not report any BLE activity.

If I leave scanduration at 1000ms I still get erratic response to button presses on the BC-021 beacon. I’m trying to sort out what the beacon is actually sending with what I am seeing on OpenMQTTGateway serial output. I have a whitelist with only three IDs, but the scan is still reporting IDs not on the whitelist. It is not publishing them to MQTT but it is spending time scanning and detecting them.

Also, {“save”:true} does save the gateway parameters, but does not save the whitelist. Every time I do a reset or power up, I have to renter the whitelist.

Blue Charm has an extensive getting started page for the BC-021 at:

Here is a message captured from MQTT Express for a single button press on the beacon. The UUID has had 6 added to what would normally be advertised. A double press would add 7. I have the regular advertisements turned off. It only advertises the button press with the modified UUID when the button is pressed. Nothing is advertised until the button is pressed. I am only sending the iBeacon advertisement on a button press, none of the other optional protocols. Major and minor are not changed on a button press, only the UUID is affected.

{“id”:“DD:34:02:06:76:41”,“rssi”:-63,“brand”:“GENERIC”,“model”:“iBeacon”,“model_id”:“IBEACON”,“mfid”:“4c00”,“uuid”:“426c7565436861726d426561636f6e78”,“major”:3838,“minor”:4949,“txpower”:-59}

Here are all the gateway settings reported in MQTT Express:
{“bleconnect”:false,“interval”:1,“adaptivescan”:false,“intervalacts”:1,“intervalcnct”:3600000,“scanduration”:1000,“onlysensors”:false,“randommacs”:false,“hasspresence”:false,“presenceTopic”:“presence/”,“presenceUseBeaconUuid”:false,“minrssi”:-100,“extDecoderEnable”:false,“extDecoderTopic”:“undecoded”,“filterConnectable”:false,“pubadvdata”:false,“pubBeaconUuidForTopic”:false,“ignoreWBlist”:false,“btqblck”:1,“btqsum”:955,“btqsnd”:834,“btqavg”:1.145084}

Thanks for your help!

9

Hi @dennyfmn

Correct, white-/black-lists are not saved on the gateway, but if you publish the white-list command with a retain flag, the broker will keep it and resend it any time the gateway restarts.

Unfortunately there is no way to not ‘hear’ the ID broadcasts from other sensors, even if they are not being decoded and published to MQTT messages, due to the white-list. It’s a bit like people talking loudly in a bar, you might only be interested in a what a few of your friends are saying, but you will still hear all the others as well, and there is not much you can do about the noise :wink:

It is not recommended, and apparently not even working properly, to set the scan duration to less than 1000 ms. It should still catch all the beacon’s broadcasts.

As your iBeacon forma doesn’t really require active scanning you could also try the following

"interval”:0
“intervalacts”:55000 (dedault) or 0 as well as interval above

with the existing
“scanduration”:1000

Also have a look in nRFConnect app on your mobile phone to see what the beacon’s broadcast interval is, especially as you have turned off general broadcasts and only have a broadcast for a button press, so it’ll be good to see if this really only creates one singular broadcast per press, or possibly several with very short ms intervals for each button press.

As you had the development version c75470 from a few days ago installed it might be a good idea to also update to the latest nightly development build version - the development branch is being constancy updated with additions, changes, fixes and optimisations.

Let us know how you get on with the above.