Replies: 19 comments 24 replies
-
|
@altserg I'm looking into this but I am not sure that this is even possible. You can try the attached tasmota32-bluetooth-test-discovery1.zip 2022-03-23 23:31:57: tasmota/discovery/A4CF1204BFD0/sensors {"sn":{"ATC92d36d":{"alias":"chbre_coline","mac":"a4c13892d36d","Temperature":18.4,"Humidity":51.2,"DewPoint":8.1,"Btn":1,"Battery":84,"RSSI":-95},"TempUnit":"C"},"ver":1} |
Beta Was this translation helpful? Give feedback.
-
|
I have used my spare ESP32 module, I see no MQTT messages for BLE sensors, see below. All BLE keys are OK Console output is OK for all sensors: 19:01:08.690 MQT: tele/ESP32-LilyGo/BLE = {"Time":"2022-03-24T19:01:08","BLEDevices":{"total":5,"A4C138969B08":{"i":0,"r":-63,"a":"WorkRoomTest"},"A4C138064916":{"i":1,"r":-84,"a":"MainBedroomTest"},"A4C1389224D1":{"i":2,"r":-68,"a":"VeronicaBedroomTest"},"A4C138FEE8E4":{"i":3,"r":-85},"A4C13803BC36":{"i":4,"r":-56,"a":"AndrewBedroomTest"}}}
19:01:08.725 MQT: tele/ESP32-LilyGo/BLE = {"Time":"2022-03-24T19:01:08","BLE":{"scans":1069,"adverts":81326,"devices":5,"resets":0}}
19:02:00.639 MQT: tele/ESP32-LilyGo/SENSOR = {"Time":"2022-03-24T19:02:00","LYWSD03969b08":{"alias":"WorkRoomTest","mac":"a4c138969b08","Temperature":22.4,"Humidity":33.7,"DewPoint":5.6,"RSSI":-63},"LYWSD03064916":{"alias":"MainBedroomTest","mac":"a4c138064916","Temperature":22.7,"Humidity":31.8,"DewPoint":5.0,"Battery":56,"RSSI":-88},"TempUnit":"C"}
19:02:01.663 MQT: tele/ESP32-LilyGo/SENSOR = {"Time":"2022-03-24T19:02:01","LYWSD039224d1":{"alias":"VeronicaBedroomTest","mac":"a4c1389224d1","Temperature":22.9,"Humidity":31.0,"DewPoint":4.8,"Battery":42,"RSSI":-69},"LYWSD0303bc36":{"alias":"AndrewBedroomTest","mac":"a4c13803bc36","Temperature":22.6,"Humidity":32.1,"DewPoint":5.1,"Battery":100,"RSSI":-57},"TempUnit":"C"}
19:03:00.659 MQT: tele/ESP32-LilyGo/SENSOR = {"Time":"2022-03-24T19:03:00","LYWSD03969b08":{"alias":"WorkRoomTest","mac":"a4c138969b08","Temperature":22.4,"Humidity":33.7,"DewPoint":5.6,"RSSI":-67},"LYWSD03064916":{"alias":"MainBedroomTest","mac":"a4c138064916","Temperature":22.7,"Humidity":32.9,"DewPoint":5.5,"Battery":56,"RSSI":-93},"TempUnit":"C"}
19:03:01.621 MQT: tele/ESP32-LilyGo/SENSOR = {"Time":"2022-03-24T19:03:01","LYWSD039224d1":{"alias":"VeronicaBedroomTest","mac":"a4c1389224d1","Temperature":22.9,"Humidity":31.0,"DewPoint":4.8,"Battery":42,"RSSI":-60},"LYWSD0303bc36":{"alias":"AndrewBedroomTest","mac":"a4c13803bc36","Temperature":22.6,"Humidity":34.2,"DewPoint":6.0,"Battery":100,"RSSI":-64},"TempUnit":"C"}
19:04:00.618 MQT: tele/ESP32-LilyGo/SENSOR = {"Time":"2022-03-24T19:04:00","LYWSD03969b08":{"alias":"WorkRoomTest","mac":"a4c138969b08","Temperature":22.4,"Humidity":33.7,"DewPoint":5.6,"RSSI":-70},"LYWSD03064916":{"alias":"MainBedroomTest","mac":"a4c138064916","Temperature":22.6,"Humidity":32.9,"DewPoint":5.4,"Battery":56,"RSSI":-87},"TempUnit":"C"}
19:04:01.618 MQT: tele/ESP32-LilyGo/SENSOR = {"Time":"2022-03-24T19:04:01","LYWSD039224d1":{"alias":"VeronicaBedroomTest","mac":"a4c1389224d1","Temperature":22.9,"Humidity":31.0,"DewPoint":4.8,"Battery":42,"RSSI":-74},"LYWSD0303bc36":{"alias":"AndrewBedroomTest","mac":"a4c13803bc36","Temperature":22.8,"Humidity":34.2,"DewPoint":6.2,"Battery":100,"RSSI":-68},"TempUnit":"C"}
19:05:00.617 MQT: tele/ESP32-LilyGo/SENSOR = {"Time":"2022-03-24T19:05:00","LYWSD03969b08":{"alias":"WorkRoomTest","mac":"a4c138969b08","Temperature":22.4,"Humidity":33.7,"DewPoint":5.6,"RSSI":-61},"LYWSD03064916":{"alias":"MainBedroomTest","mac":"a4c138064916","Temperature":22.6,"Humidity":32.9,"DewPoint":5.4,"Battery":56,"RSSI":-86},"TempUnit":"C"}
19:05:01.632 MQT: tele/ESP32-LilyGo/SENSOR = {"Time":"2022-03-24T19:05:01","LYWSD039224d1":{"alias":"VeronicaBedroomTest","mac":"a4c1389224d1","Temperature":22.9,"Humidity":31.0,"DewPoint":4.8,"Battery":42,"RSSI":-69},"LYWSD0303bc36":{"alias":"AndrewBedroomTest","mac":"a4c13803bc36","Temperature":22.8,"Humidity":34.2,"DewPoint":6.2,"Battery":100,"RSSI":-61},"TempUnit":"C"}
19:06:00.625 MQT: tele/ESP32-LilyGo/SENSOR = {"Time":"2022-03-24T19:06:00","LYWSD03969b08":{"alias":"WorkRoomTest","mac":"a4c138969b08","Temperature":22.4,"Humidity":33.7,"DewPoint":5.6,"RSSI":-62},"LYWSD03064916":{"alias":"MainBedroomTest","mac":"a4c138064916","Temperature":22.6,"Humidity":32.9,"DewPoint":5.4,"Battery":56,"RSSI":-84},"TempUnit":"C"}
19:06:01.637 MQT: tele/ESP32-LilyGo/SENSOR = {"Time":"2022-03-24T19:06:01","LYWSD039224d1":{"alias":"VeronicaBedroomTest","mac":"a4c1389224d1","Temperature":22.9,"Humidity":31.0,"DewPoint":4.8,"Battery":42,"RSSI":-58},"LYWSD0303bc36":{"alias":"AndrewBedroomTest","mac":"a4c13803bc36","Temperature":22.8,"Humidity":34.2,"DewPoint":6.2,"Battery":100,"RSSI":-71},"TempUnit":"C"}
19:06:08.623 MQT: tele/ESP32-LilyGo/STATE = {"Time":"2022-03-24T19:06:08","Uptime":"0T06:00:10","UptimeSec":21610,"Heap":94,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Berry":{"HeapUsed":3,"Objects":41},"Wifi":{"AP":1,"SSId":"Bailar_N","BSSId":"74:DA:38:B8:71:C5","Channel":1,"Mode":"11n","RSSI":100,"Signal":-46,"LinkCount":1,"Downtime":"0T00:00:04"}}
19:06:08.672 MQT: tele/ESP32-LilyGo/SENSOR = {"Time":"2022-03-24T19:06:08","ESP32":{"Temperature":60.0},"TempUnit":"C"} |
Beta Was this translation helpful? Give feedback.
-
|
@altserg Hi, I think you're experiencing the same issue as I described some time ago: The stale bot closed the issue and I didn't want to nag the developers any more, as I found a work around that works fine for me, even though it prevents me automatically updating the firmware, as I need to recompile with specific flags enabed / disabled: |
Beta Was this translation helpful? Give feedback.
-
I also see the same behavior. But the issue is different as I do not want to use legacy HASS discovery but native Tasmota discovery. Legacy HASS discovery is not supported anymore. Tasmota 9.x seems to support both Legacy HASS and native Tasmota discosvery via setoption19, but never version 11.x only supports one at a time. mi32option6 1 does not publish legacy homeassistant discovery messages |
Beta Was this translation helpful? Give feedback.
-
|
@altserg I totally agree with you. I was just coming from a use case, where I had already a working Home Assistant setup with a Tasmotized ESP32 used as BLE bridge to extend the range of remote and outside Xiaomi sensors. I was surprised that the HASS discovery was dropped with no equivalent support with native Tasmota discovery, that's why my immediate goal was to have my working setup back again, although with deprecated functionality. So I'm actually in the same boat as you - I'd like to have the dynamically discovered BLE sensors autoconfigured in HA using the native Tasmota discovery mechanism. Let's hope this is doable after all. |
Beta Was this translation helpful? Give feedback.
-
|
I have 7 Xiaomi T&H sensors and I get discovery publications with the above firmware |
Beta Was this translation helpful? Give feedback.
-
|
So apprently you are using |
Beta Was this translation helpful? Give feedback.
-
|
Hi @emontnemery |
Beta Was this translation helpful? Give feedback.
-
|
The expected behavior right now is that a new complete sensor discovery message, with all known sensors, is published when a sensor is added or removed. The way the code works now, IIRC, is that 10 seconds after Tasmota boot or so we loop over all available sensors to generate a message. |
Beta Was this translation helpful? Give feedback.
-
|
(message copied downstream) |
Beta Was this translation helpful? Give feedback.
-
|
I tried with MI32Ooption6 1, and indeed, I can see one sensor, that is detected in HASS. See below. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @altserg What I mean is that Tasmota action should be limited to declare new sensors coming in and the back office should automatically adapt. |
Beta Was this translation helpful? Give feedback.
-
Hi @barbudor, It's not about managing the database, it's about aligning legacy HomeAssistant discovery behavior and new Tasmota native discovery. Currently those 2 protocols have different behavior - HASS discover does publish BLE sensor info, but Tasmota discovery does not. |
Beta Was this translation helpful? Give feedback.
-
|
The new discovery is different how it works, we have to discuss with HA. It is NOT just mimic the old way in the new discovery. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @emontnemery However, for BLE and Zigbee, the number of sensors as well as when they can come up or down is drastically different. So I believe this logic has to be reconsidered for BLE and Zigbee sensors.
|
Beta Was this translation helpful? Give feedback.
-
|
Not really In the examples below, I have 2 ADC inputs (dummy, nothing connected) and ESP32's internal temp sensors that are published normally by the standard Tasmota mecanism (and actually announced with the Tasmota Discovery) and 7 BLE sensors published directly by the driver in different modes.
Another mode is to have each BLE sensor to be published as an indivisual SENSOR message as soon as data is received fomr the sensor. So it is published at the sensor's own rate This generates a lot of message Both of the above modes are not very friendly with the usage of SensorRetain to have retained sensor messages as all those messages are published on the same topic. The 3rd mode is the Gateway mode where sensors are published on a individual topic but not on the Tasmota device's %topic% but on a hard-coded "tasmota_ble" topic: See the "alias" being used. If no alias is given it is the MAC that is used. I don't think all 3 modes needs to be supported with HA. Also, It would be best to align the BLE sensors behavior and Zigbee sensors |
Beta Was this translation helpful? Give feedback.
-
|
Is there, in any of these 3 modes, a way to interrogate the Tasmota device to list currently paired (if that's the correct term?) BLE sensors? wrt zigbee sensors, wouldn't Tasmota be better off exposing them to something zigbee specialized to allow zigbee management than to expose them as dumb sensors? |
Beta Was this translation helpful? Give feedback.
-
|
There isn't an interrogation command. In any case, the answer may not fit into a single MQTT message if it has to be ~155 chars per sensor. I don't get the meaning of your sentence about Zigbee but as said before, I'm not versed at all in Zigbee. |
Beta Was this translation helpful? Give feedback.
-
|
When it comes to things like Zigbee or BLE temperature/humidity sensors, it would make sense to be able to integrate the values on similar terms as sensors with other types of connections, as the value is more relevant to the backend than the transmission technology. The issue here is that when booting, Tasmota cannot know what sensor will pop up next hours. |
Beta Was this translation helpful? Give feedback.
-
|
The main difference is that physically attached sensors are always limited in numbers while when acting as a gateway, they can be counted by tenth. |
Beta Was this translation helpful? Give feedback.
-
|
You can limit the # of reported sensors using m32option5
…Sent from my iPhone
On 29 Mar 2022, at 21:24, Barbudor ***@***.***> wrote:
The main difference is that physically attached sensors are always limited in numbers while when acting as a gateway, they can be counted by tenth.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
|
@altserg Why would I limit the number of sensors ? |
Beta Was this translation helpful? Give feedback.
-
|
I can only see much of a point in limiting the number in case of only wanting each sensor on one of multiple gateways... |
Beta Was this translation helpful? Give feedback.
-
|
Indeed if you have couple of tasmota devices with bluetooth enabled, one sensor can pop up on different devices multiple times
I use mi32option5 to avoid this
…Sent from my iPhone
On 29 Mar 2022, at 22:28, sfromis ***@***.***> wrote:
I can only see much of a point in limiting the number in case of only wanting each sensor on one of multiple BLE gateways...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
|
Indeed @altserg when you need to have multiple ESP32 to cover a large site, that's fine. |
Beta Was this translation helpful? Give feedback.
-
|
Also, while BLE is in the title, the ability to have non-wired sensors integrate in the backend on the same terms as "classic" Tasmota sensors applies at least as much to Zigbee, where devices can form a potentially large mesh of devices going to the same coordinator. |
Beta Was this translation helpful? Give feedback.
-
|
The question may be if the "best" solution is to keep all the sensors under the umbrella of the hub Tasmota device, or if it would be preferable to have each BLE/Zigbee device treated as a separate |
Beta Was this translation helpful? Give feedback.
-
|
Hi @sfromis , I agree that the problem is not only for BLE but Zigbee as well. However, I only use BLE, so I'm speaking mainly from the BLE position. An (but probably somewhat ugly) alternative for BLE might be to enable legacy HASS discovery for BLE when MI32Option6 = 1. Mi32Option6 enables the same BLE sensor reporting as setoption19 1. It might be ok to mimic also setoption19 1 HASS discovery behavior. Moreover, the code for it is already there |
Beta Was this translation helpful? Give feedback.
-
|
Well, if you want As native discovery is not designed to only work with HA, reverting to old style does not get around the weak spot of fuller discovery than what can work if the backend simply reacts when it sees a new sensor appearing, and is able to deal with this. What I do in my setup is not to assume the device to provide details of how it is to appear in dashboard/whatever, and then I have easily updateable metadata if I want to additional structure data. This works without additional discovery data, as the only useful thing for dynamically appearing sensors is the alias, which already appears in the regular payloads. To me, this makes more sense than sticking to a concept of a device having to tell a lot of details about other devices (sensors in this case). Of course, I'm not going to push HA to work better for such devices, as I'm not using it anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Setoption 19 1 does not enable legacy hass discovery anymore. So it does not work. I would appreciate if you share an example of your setup
…Sent from my iPhone
On 1 Apr 2022, at 13:05, sfromis ***@***.***> wrote:
Well, if you want SetOption19 1 for BLE, just do it. No code change needed. Of course, that does not answer the issue as posted by you. Any solution for native discovery to integrate dynamically appearing sensors should IMO apply as much to Zigbee.
As native discovery is not designed to only work with HA, reverting to old style does not get around the weak spot of fuller discovery than what can work if the backend simply reacts when it sees a new sensor appearing, and is able to deal with this.
What I do in my setup is not to assume the device to provide details of how it is to appear in dashboard/whatever, and then I have easily updateable metadata if I want to additional structure data. This works without additional discovery data, as the only useful thing for dynamically appearing sensors is the alias, which already appears in the regular payloads. To me, this makes more sense that sticking to a concept of a device having to tell a lot of details about other devices (sensors in this case). Of course, I'm not going to push HA to work better for such devices, as I'm not using it anyway.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
|
You can still compile your code with old HA but this code is not maintained and will not solve the problem with BLE |
Beta Was this translation helpful? Give feedback.
-
|
One potential workaround to avoid changing HaTasmota could be to publish each BLE sensor as a separate Tasmota device (plausibly done with Berry code), including constructing the discovery messages triggering HaTasmota to recognize and automatically configure sensors. This allows dynamic discovery by "hiding" the circumstance that multiple sensors are managed from a single Tasmota instance. |
Beta Was this translation helpful? Give feedback.
-
|
Interresting idea as usual @sfromis |
Beta Was this translation helpful? Give feedback.
-
|
So with a new The 3 first lines are unchanged and standard messages published on the device's %topic%, independant of Mi32Option. The last 2 lines are 2 Mija sensors published on their own topic made from Mi32Topic / sensor-alias @emontnemery Thanks |
Beta Was this translation helpful? Give feedback.
-
|
Hey, Any chance to get this prioritized? Would like autodiscovery for BLE in Home Assistant via ESP32 Tasmota devices |
Beta Was this translation helpful? Give feedback.
-
|
@emontnemery Can you answer the question from @barbudor ? Thx! |
Beta Was this translation helpful? Give feedback.
-
|
Any progress on this one? Is the option still to manually input sensors in HA? or using Blerry ? Following. Thank you |
Beta Was this translation helpful? Give feedback.
-
|
Any progress?) |
Beta Was this translation helpful? Give feedback.
-
|
The solution is to use Blerry |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for reply! |
Beta Was this translation helpful? Give feedback.
-
If this can help, I use Tasmota extensively and really like the work and support from developers. It is my main platform. But if you want more control over BLE devices I would suggest having a look at OpenMQTTgateway, the project is BLE centric so it supports a large number of BLE devices and HA discovery is native: https://docs.openmqttgateway.com/integrate/home_assistant.html#auto-discovery Cheers. |
Beta Was this translation helpful? Give feedback.
-
Thank you) |
Beta Was this translation helpful? Give feedback.
-
PROBLEM DESCRIPTION
BLE sensors are not reported in Tasmota native discovery. They are not visible in HASS GUI. The behavior is the same regardless of MI32Option6 setting.
The issue was found while migrating from Domotiz/HASS MQTT discovery plugin to HASS/Tasmota integration
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255:Backlog Rule1; Rule2; Rule3:Status 0:weblogto 4 and then, when you experience your issue, provide the output of the Console log:TO REPRODUCE
Steps to reproduce the behavior:
Add any (Xiaomi) BLE temperature/humidity sensor to Tasmota. The sensor data are correctly reported using both "mi32option6 0" and "mi32option6 1". However, the sensor is not reported via Tasmota native discovery to homeassistant. Legacy Home Assistant discovery via MQTT integration works fine.
There is a thread about it in hass community with possible workaround: https://community.home-assistant.io/t/tasmota-xaomi-ble-temp-sensors/311314/4
However, I think that the behavior of legacy HASS discovery and new Tasmota native discovery should be the same
EXPECTED BEHAVIOUR
A clear and concise description of what you expected to happen.
Native Tasmota discovery should report BLE sensors, and they should be visible in HASS. The same as legacy Home Assistant discovery
SCREENSHOTS
If applicable, add screenshots to help explain your problem.
ADDITIONAL CONTEXT
Add any other context about the problem here.
(Please, remember to close the issue when the problem has been addressed)
Beta Was this translation helpful? Give feedback.
All reactions