search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.22k stars 4.81k forks source link

SetOption89 equivalent for Bluetooth #8902

Closed OppiM closed 4 years ago

OppiM commented 4 years ago

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 commented 4 years ago

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

Elix-g commented 4 years ago

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 commented 4 years ago

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)?

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

Ideas are welcome.

arendst commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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[bot] commented 4 years ago

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 commented 4 years ago

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

Staars commented 4 years ago

Bridge mode is the default since: https://github.com/arendst/Tasmota/pull/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[bot] commented 4 years ago

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[bot] commented 4 years ago

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.