SetOption89 equivalent for Bluetooth

[OppiM]

Have you looked for this feature in other issues and in the docs? Yes

Is your feature request related to a problem? Please describe.
Using Tasmota + Bluetooth adds all found sensors into one MQTT-Update like this:
14:37:04 MQT: tele/ESP32_02/SENSOR = {"Time":"2020-07-14T14:37:04","Flora-66b356":{"Temperature":31.4,"Illuminance":9955,"Moisture":58.000000,"Fertility":221.000000},"Flora-66ace7":{"Temperature":26.5,"Illuminance":3325,"Moisture":39.000000,"Fertility":236.000000},"Flora-666c1a":{"Temperature":30.2,"Illuminance":15649,"Moisture":0.000000,"Fertility":464.000000},"Flora-66b302":{"Temperature":26.4,"Illuminance":16,"Moisture":0.000000,"Fertility":0.000000},"TempUnit":"C"}

That makes it difficult to seperate the individual sensors.

Describe the solution you'd like
For Zigbee SetOption89 exists so that each device has a topic on it's own. A similar option for Bluetooth would be great. The above example should then look something like:
14:37:04 MQT: tele/Bluetooth/Flora-66b356/SENSOR = {"Time":"2020-07-14T14:37:04","Temperature":31.4,"Illuminance":9955,"Moisture":58.000000,"Fertility":221.000000,"TempUnit":"C"}
14:37:04 MQT: tele/Bluetooth/Flora-66ace7/SENSOR = {"Time":"2020-07-14T14:37:04","Temperature":26.5,"Illuminance":3325,"Moisture":39.000000,"Fertility":236.000000,"TempUnit":"C"}
14:37:04 MQT: tele/Bluetooth/Flora-666c1a/SENSOR = {"Time":"2020-07-14T14:37:04","Temperature":30.2,"Illuminance":15649,"Moisture":0.000000,"Fertility":464.000000},"TempUnit":"C"}
14:37:04 MQT: tele/Bluetooth/Flora-66b302/SENSOR = {"Time":"2020-07-14T14:37:04","Temperature":26.4,"Illuminance":16,"Moisture":0.000000,"Fertility":0.000000,"TempUnit":"C"}

Describe alternatives you've considered
Parsing the original SENSOR-transmition

Additional context

(Please, remember to close the issue when the problem has been addressed)

[Staars]

We are about to rework the BLE-part and will consider this.

[Elix-g]

The possibility to separate outputs is interesting not just for BLE but for all sensor outputs. Currently, some work-around using rules is fine for me:

ON tele-time DO var5 %value% ENDON ON tele-bh1750#illuminance DO publish tele/%topic%/SENSOR1 {\"Time\":\"%var5%\",\"BH1750\":{\"Illuminance\":%value%}} ENDON

That produces some overhead of course but works reliably.

[Staars]

I am in the middle of rewriting the MQTT part of the driver and the real-time-bridge is already working pretty well. Without any additional format changes this is short console log of a few seconds:

14:46:27 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:27","LYWSD02-c1cc7a":{"Humidity":58.0,"RSSI":-83}}
14:46:28 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:28","MJ_HT_V1-3108be":{"Humidity":54.7,"RSSI":-74}}
14:46:30 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:30","MJ_HT_V1-3108be":{"Temperature":23.6,"Humidity":54.7,"DewPoint":13.9,"RSSI":-82},"TempUnit":"C"}
14:46:30 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:30","LYWSD02-c1cc7a":{"Temperature":23.8,"RSSI":-77},"TempUnit":"C"}
14:46:31 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:31","CGD1-508af6":{"Temperature":23.7,"Humidity":52.5,"RSSI":-63},"TempUnit":"C"}
14:46:32 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:32","LYWSD02-c1cc7a":{"Temperature":23.8,"RSSI":-82},"TempUnit":"C"}
14:46:33 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:33","LYWSD02-c1cc7a":{"Humidity":58.0,"RSSI":-75}}
14:46:34 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:34","MJ_HT_V1-3108be":{"Temperature":23.6,"Humidity":54.6,"DewPoint":13.9,"RSSI":-82},"TempUnit":"C"}
14:46:35 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:35","LYWSD02-c1cc7a":{"Humidity":58.0,"RSSI":-76}}
14:46:36 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:36","MJ_HT_V1-3108be":{"Temperature":23.6,"Humidity":54.7,"DewPoint":13.9,"RSSI":-81},"TempUnit":"C"}
14:46:36 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:36","LYWSD02-c1cc7a":{"Temperature":23.8,"RSSI":-82},"TempUnit":"C"}
14:46:37 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:37","LYWSD02-c1cc7a":{"Humidity":58.0,"RSSI":-76}}
14:46:37 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:37","CGD1-508af6":{"Temperature":23.7,"Humidity":52.5,"RSSI":-64},"TempUnit":"C"}
14:46:38 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:38","LYWSD02-c1cc7a":{"Temperature":23.8,"RSSI":-75},"TempUnit":"C"}
14:46:39 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:39","Flora-6ab577":{"Illuminance":186,"Moisture":0,"Fertility":0,"RSSI":-68}}
14:46:41 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:41","YEERC-e7d1a0":{"Btn":1,"RSSI":-77}}
14:46:41 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:41","CGD1-508af6":{"Temperature":23.7,"Humidity":52.6,"RSSI":-68},"TempUnit":"C"}
14:46:42 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:42","MJ_HT_V1-3108be":{"Temperature":23.6,"Humidity":54.6,"DewPoint":13.9,"RSSI":-72},"TempUnit":"C"}
14:46:42 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:42","LYWSD02-c1cc7a":{"Temperature":23.8,"RSSI":-73},"TempUnit":"C"}
14:46:43 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:43","CGD1-508af6":{"Temperature":23.7,"Humidity":52.6,"RSSI":-68},"TempUnit":"C"}
14:46:44 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:44","LYWSD02-c1cc7a":{"Temperature":23.8,"RSSI":-73},"TempUnit":"C"}
14:46:46 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:46","MJ_HT_V1-3108be":{"Temperature":23.6,"Humidity":54.5,"DewPoint":13.9,"RSSI":-74},"TempUnit":"C"}
14:46:46 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:46","Flora-6ab577":{"Moisture":0,"Fertility":0,"RSSI":-68}}
14:46:46 MQT: tele/tasmota_26E728/SENSOR = {"Time":"2020-07-17T14:46:46","LYWSD02-c1cc7a":{"Temperature":23.8,"RSSI":-85},"TempUnit":"C"}

To get the things done for me in a real-life-scenario this would probably be enough, as I can gather the infos on a server and do the rest there.
Some sensors send very frequently, some only every 10 minutes.
The messages above do only contain the very last info with a latency of roughly 50msec (except Flora, which I did not refactor yet).

So the question is:
Do we need an additional concatenation of all values of one sensor at TELEPERIOD (like before)?

• if yes, I would invalidate (=delete) the values at that time.
• we could also show always all last sensor values together with last received value (and invalidate everything at TELEPERIOD)

Is there something else, that is really needed as summary at TELEPERIOD?

Ideas are welcome.

[arendst]

I'm in favour of sending individual sensors when they come along. If frequently coming along only send them once a minute or so.

This way rules is able to better service any trigger when a sensor change comes along.

Concatenation is bound to fail if many sensors are reporting as the string lenght is not enough.

[s-hadinger]

I'm doing a light concatenation in Zigbee. Sensors are not published immediately, I have a window of 350ms to aggregate all readings from the same device.
I'd some readings are redundant are incompatible, I immediately publish the previous readings and store the next reading for 350ms. Zigbee2Mqtt has a similar behavior.

Still it's one Mqtt message per device. Aggregating more would generate lots of problems.

[Elix-g]

How about an implementation as equivalent to the possibility to show/hide sensor output on the main page? Like keeping the the output in one message like it's now as default and introduce an option to exclude particular sensors from TelePeriod message and generate an individual one instead.

SetOptionX Sensor# 0|1|2

0 = Default
1 = Individual message for all values of given sensor
2 = Individual messages for each value of given sensor

[Staars]

Thanks for all answers.
I think this driver will need some „setoption“-stuff, maybe in the form of a „mi32option“-command which can be saved as rule.
Alternatively it would be technically easy to use some „setoptions“ from Zigbee, as I do not believe, that someone uses Zigbee and Bluetooth on the same (Tasmota-)device. This could only be a little bit confusing.
ATM I tend to set the following default:
Report every sensor including the last valid data, that is not in the recent Bluetooth-message. Delete and invalidate this data at TELEPERIOD and only show few things here, like firmware and last battery.

Options could be:
(You can add „personal preference“ to every Pro/Con)

Only „pure“ bridge mode, never send saved sensor data.
Pro: Never send old data
Con: Nearly never get the dew point, as combined temp/hum messages are rare.

Show all sensors at TELEPERIOD
Pro: Compatibility to the old style
Con: Will get scrambled with many sensors

Show RSSI
Pro: Shorter messages, can show more sensors aggregated
Con: No debug info

Never invalidate sensor data
Pro: Constant showings in the WebUI
Con: Old data can stay forever

The list is probably longer. I did not check yet, how costly this is to implement.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[DonStefano]

I would also opt for a bridge mode. Collecting sensor data and combining them can be done in HA software.

[Staars]

Bridge mode is the default since: #8941

As this introduces a problem with HASS auto discovery, because the the (HASS)-driver does not expect these single messages, the driver UI is not finalized yet and the user has to play with some options in the driver code.
We are still working on it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem.