Exploring BLE Functionality and Data Forwarding Via MQTT with ESP32s and Openbeken DS-101

Hi,
I have a couple of ESP32s with TASMOTA BLE around my house. They do other stuff, too, but I also use their BLE functionality to forward sensor data from BLE devices. However, there are blind spots that I'd like to cover now.
In the meantime, I got many more openbeken flashed devices, and after replacing almost all of my light switches with the DS-101 (which on the backside says WIFI+Bluetooth), I have one in almost every room. So, they would offer great coverage of my house if their Bluetooth functionality could be used. It would be perfect if they could forward received BLE data via MQTT the same way the ESP32s do. Is this possible? Is there any new knowledge on whether the chips are actually able to do this? I just found old posts and no definite answer or info on how to potentially do this. Thanks for any info on this!

It is possible and we've got a substantial progress on that recently:
[BK7231T] A simple BLE device project using WB2L. Comments and help welcome.
The only issue is that would take a bit more of work to get running than other issues/feature requests and because of that it has a relatively low priority on our TODO list. We can try to give it more priority, if you think, it also depends on how many other users are interested.

DS-101 are great, I've also got some of them recently: https://www.elektroda.com/rtvforum/topic3988310.html

However, I also have to mention that I don't have big experience with ESP32 BT. Can you explain more in depth here how your BT forwarding works and how would you like it to work on Beken? It would certainly help me to get up to speed quickly.

Hi!
Thanks for your quick answer, and great to hear there was some progress and there might soon be even more! Also fun to hear you also got some of those switches, hope you also like them.
I'd say the way it works in Tasmota gives a nice starting point, but as with other things, you might find a nicer spin to how it works there https://tasmota.github.io/docs/Bluetooth_ESP32

So the basic functionality could look comparable to this:
- you "activate" listening to a specific type of sensor (this could be a flag in openbeken or a startup command)
- different devices send the data differently, and their data might need to be interpreted differently. I have set up Mijia thermometers (with custom ATC firmware) that send temperature, humidity, and battery level, and other sensors that basically send just an "I'm here" signal, and the receiver registers the signal strength, like iTags and Mi Bands. Examples for devices are also listed on the page pasted above.
- the data of the activated sensors is listed on the overview page - here I think is a great chance to improve how it's done in Tasmota, maybe with a dedicated page. I find it clutters the main page a lot in Tasmota, and even worse, sometimes something changes, and suddenly the button you wanted to click jumps up or down
- pretty important: there should be some possibility to filter which MACs to include/exclude. I think a whitelist would be nice. Important to know about this part is that there are some devices that often change the MAC address (mainly Apple products like iBeacons, Apple Watches/Phones...)
--- For this whitelist, there is yet another chance for improving things compared to Tasmota with a nice overview where you can just add/edit/remove entries. I start thinking that maybe a dedicated BLE submenu for all this stuff would be great. In Tasmota, most things need to be done via the console, which can get frustrating with all other output rushing by.
- last but not least and not quite that important: there could be some way to reformat data, e.g. MAC xyz = MiBand-Peter. This option would also be cool on a dedicated page.
- Eventually, the information gets published as an MQTT message, in Tasmota that looks like this:
15:39:36.240 MQT: tele/ESP_NAME/SENSOR = {"Time":"2023-08-14T15:39:36","IBEACON":{"MAC":"MACADDRESS","RSSI":-90,"STATE":"ON","PERSEC":0}}
- In my setup, I reformat a lot of data with Node-RED, which also works fine, and then add it as MQTT sensors via the configuration.yaml in HA

Hope all this helps, and I'd be totally in for testing and giving feedback!

Just as a disclaimer: I really do not want to bash on Tasmota, I have the greatest respect for that project and use it a lot. But you can also see that since it already exists for quite some time, they cannot just radically change things. Here I think lies a great chance for openbeken where you would start from scratch.

I am also interested. I have one DS-101 installed and another one handy.

Wall switches are getting interesting as well. I recently discovered some interesting ESP8285 wall switches also. One particular device had some extra provision in the PCB for a buzzer circuit. I managed to solder the buzzer components and hookup to a free IO. I am testing the MQTT controlled buzzer in the wall switch these days. I want to use it as a status indicator for my Solar Inverter data ie. when it switches to battery mode etc.
Since most wall switches have pluggable DC PCBs there is plenty of modificatons that can be done as long as you stick to the current supply capacity of the main PCB.

The board you have shown is a WiFi + RF combo. The buzzer is used to indicate the pairing. The RF is seamlessly connected with buttons controller so ESP (Tasmota) is not "aware" about RF presence. The MCU simulates button presses when you touch a button on RF remote.

p.kaczmarek2 wrote:

The board you have shown is a WiFi + RF combo. The buzzer is used to indicate the pairing. The RF is seamlessly connected with buttons controller so ESP (Tasmota) is not "aware" about RF presence. The MCU simulates button presses when you touch a button on RF remote.

Yes but the device that I got (or rather I ordered few more after this discovery) had the RF circuitry and the RF chip but not the buzzer. The buzzer circuit has an open collector transistor driver which is connected to the button controller on the right hand side. The transistor driver circuit and the buzzer were missing from the PCB. The picture shows a single gang switch so tracks provisioned for the other two touch switches were available closely. The green wire is going to the other side of the PCB as I added two Pixel LEDs as additional indicators.

>>20694369
Interesting, I guess that answers why the only additional feature you get with the RF functionality in some devices is ghost switching