Tasmota32 + BLE + MI Sensors = Reduce / disable MQTT sending of "duplicate" / "already sent" data?

[anonymous-one]

I just finished migrating all of my 30+ shelly devices from mgos to tasmota and refactoring my mqtt handler script.

Many of my devices are esp32 based so I have opted to take advantage of the ble stack tasmota can provide.

Yes, I am aware that tasmota32-solo1-bluetooth, which I am using on many of these devices, is an unofficial build... That being said, the question below is not device specific so it shouldn't really matter. On top of that about 6 of of these devices are non-solo1 based esp32 devices so theres that ;)

I have about 10 LYWSD03MMC sensors flashed with the ATC firmware, plus a couple of iBeacons, so this setup really upped my ble game. Thanks tasmota!

I have noticed the following behavior:

Tasmota will, at MI32Period, broadcast via mqtt the sensor data even if it has not changed in the last MI32Period cycle. I mean, the temp / humidity / battery data doesn't change, the rssi does, so maybe this is why?

With 10 devices and about 30 ble enabled tasmota relays, this is quite a bit of unnecessary mqtt traffic.

I have tried fiddling with some of the MI32Option to no avail.

So, to summarize:

Is there a way to enforce tasmota only sends out mqtt packets containing ble mi sensor data when ble mi sensor data actually changes (eg: temp goes up / down, humidity goes up / down, battery level goes up / down), rather than on every MI32Period cycle?

[barbudor]

You need to dig more in the Mi32Options

Such as limiting each Tasmota to publish only for BLE sensors that have a BleAlias on that tasmota device (to avoid too many duplicates when a BLE sensor is picked by more than 1 tasmota)
=> Mi32Option5 1

Sending BLE as they are received (instead of aggregating and using bleperiod)
=> experiment around Mi32Option0 / Mi32Option1 / Mi32Option2
I'm not using that but there should be a combination that works for you

[anonymous-one]

Thank you for the reply.

I am aware of the ble filters yes... Although yes this is a way to reduce the traffic... One of the upsides of having 'so many' ble gateways is that if one misses the sensor reading, another one is sure to pick it up. I would much prefer to leave the ble filters empty.

Looks like implementing a "only send on change" type of filter will require I dig into the code and add this myself. Unfortunately, like many, I just don't have the time to do this at the moment :(