Bluetooth - BTHome & ATC MiThermometer : Decimal Places

Thanks! really appreciated!

1 Like

btw have u tried similar procedure on a host with no bluetooth BUT with a bunch of esp32 that have bluetooth proxy enabled?
since I recently migrated to home assistant yellow and my cm4 does not come with bluetooth. I followed the same procedure as u mentioned, but nothing automatically showed up after I restart…
Just wondering if blue tooth proxy can pickup new device(means something is wrong with my setting) or I just need a bluetooth dongle to do it.
thanks

I haven’t tested that as my host has Bluetooth.

Mabe try getting a ZEXMTE BT-505 adapter with -63 RSSI and a USB extension cable. I haven used one but I have seen it mentioned on this form. You can also add one directly inside your yellow but they say it is better outside your yellow. see YouTube below at 1:59:30

If you add one to your host, could you let us know how you go?

I am only using bluetooth proxies with my installation and most if not all of my stock Xiaomi temp/humid sensors were discovered. The one I flashed with custom firmware and am using the bthome adv type I had to add manually. When I switched a second sensor to custom firmware and used the Mijia adv type, I added it manually as well. I do not think anything is wrong, likely a timing issue of discovery and advertisement.

I noticed the sensor set to bthome with default timing is consuming battery quite a bit like others have observed. This surprised me because I would think the only difference between the different adv formats is how the data is structured.

Right now I am testing 3 variations on my desk

  1. stock,
  2. custom v3.8 with bthome and default settings,
  3. custom v3.8 with mijia and tuned down adv intervals (7500ms, and 25x measure interval multiplier).

I have 4th unit I may test with custom+mijia+defaults to compare against bthome with defaults.

Also my ble proxies are passive, active scan is set to false.

I wanted to test the ATC and PVVX adv formats but these have not made it from passive ble monitor into this new integration yet it seems. There’s a ton of info at the pvvx github so I will try to spend some time there to see if the bthome adv settings is doing something more/different.

Hi @paperclip

Thanks for confirming that :grinning:

I noticed the same thing. Will be nice to hear from your final testing. Please let us know. :facepunch:

if you find anything could you let us know :+1:

The only thing I’ve found is the thread which I think is between you and Victor. There was one comment about the bthome format and value changes trigger advertisement, and since bthome reports to the hundredths, changes in this digit place would trigger an advertisement. Is this confirmed? It was not clear to me in the subsequent replies.

Another thread https://github.com/pvvx/ATC_MiThermometer/issues/108 seems to talk about temp change driven advertisements but I think his reply is saying the interval is defined and not dynamic based on temp changes.

I do not see how the use of the battery entity in ha would affect the sensor’s battery life. The default bluetooth proxy does active scanning but its going to scan at a regular interval for the device, not each entity. Whether or not battery is enabled in HA should not affect the battery. At least that is my understanding. All of my devices report what I need from them without an active scan so I have turned off active scanning to further improve battery life.

I also didnt understand his concerns with bthome in another thread, he mentions he has concerns with esp32s, etc but bthome would work just as well to a bluetooth adapter. In other threads he’s clearly does not like esp32s for wifi+ble! I wonder if an esp32 with ethernet has the same poor adv %.

also, v2 of bthome was just released - https://bthome.io/

Yes it was me in the thread with Victor. Yea I found using BTHome I could see more inputs because of the format they use… Temp '20.22" rather than “MIJIA” temp “20.2”. Now I don’t know if that was causing my batteries to drain fast or not but when I changed from “BTHome” back to “MIJIA” the batteries were stable again. I prefer the format of “MIJIA” so I just use that and moved on. If it not broken don’t fix it was my thinking. That is why I look forward to your tests results.

Me to that why I asked Victor to maybe have an option in his firmware to turn this OFF or ON, as it makes cense if you send lest data then battery works less. Not having a full understanding like Victor has I will just have to take his word that this is not the case, but it would be nice to have so HA isn’t storing all this useless data.

I also turned OFF active scan and agree with you.

Yep he is also not a fan of BTHome Request: Change number of digits · Issue #248 · pvvx/ATC_MiThermometer · GitHub

looks like the same format. I think I will stick with “MIJIA”

I’m with you and have come to the same conclusion. I wanted to use bthome, but not at this level of drain.

Seems silly that bthome is using the 2nd digit when other formats do not, especially given the impact we think we’re seeing as a result. I say that as someone that is not an expert in c,esp32s,etc.

I want to clear out some misunderstandings. BTHome is a data format, it can’t be that BTHome is consuming much more battery than another format. BTHome integration is working the same as the xiaomi-ble integration, they both use the Bluetooth integration to collect the data.

What can make a difference is that the sensor is broadcasting more often in one format than in another (the broadcasting interval). Default Xiaomi firmware sends one advertisement per 10 minutes, with custom firmware, you can change this, but the defaults are quite often (every 2.5 seconds).

The number of digits is something that is processed as it is broadcasted. So every change of the state is a HA update. I agree that 2 digits will change more often than 1, so more HA updates will be the result. It should possible to change things to one digit, by adding an extra temperature object in the BTHome format that broadcasts temperature in one digit. I can add that in BTHome, but it will also need to be implemented in the pvvx firmware.

Regarding the findings of victor of bad experience with ESP, I guess that is a limitation of ESP32’s. I don’t see how this is related to BTHome. Bluetooth proxy on ESP’s is just forwarding all BLE data to your Home Assistant Machine, it isn’t doing anything with BTHome. You HA machine is receiving this data (with the Bluetooth integration) and is than forwarded to the BTHome integration, which translates it to a temperature, humidity etc. But this is all done on your HA machine, not on the ESP.

3 Likes

This is my understanding.

“BTHome” or “MIJIA” both do the same thing and send advertising data in a time frame.

This is a quote from Victor

Quote: “BLE advertising is transmitted with a period of up to 10 seconds - a limitation of the standard. Most operating systems start to misbehave if BLE advertisements are transmitted with a period of more than 2.5 seconds.”

Because BTHome has the format of 2 decimal places HA collects that small data (more data stored into HA) where MIJIA has 1 decimal place so HA collects less data than BTHome. That is why it is random with MIJIA and more frequent with BTHome.

MIJIA data = sometimes it’s every 10 minutes and sometimes every 2.5 seconds depending on your sensor and if the data has changed. Data still being sent and received every 2.5 seconds though just not collected.

BTHome data = more frequent heaps of data because for every 0.01 change in temp HA will collect data.

So Battery should not be affected but crazy things happen and I was waiting for your tests.

It would be nice to have pvvx firmware have a option to send the data or not. That is, send Temp and battery level not Humidity, volts and signal strength and only the decimal places you select. It may reduce battery but Victor says it will not (I will take his word on that) and will just add to his firmware with no real benefit. So the work around for me is to use MIJIA as I like the format. I then just disable the entities I don’t want HA to collect reducing the extra data HA stores. same / same. It would be nice if HA also thought about an option for BTHome and what decimal places HA will store reducing the data storage in HA, but again MIJIA works for me.

It is just his option (free speech right :grinning:) I think HA has done a fantastic job with Bluetooth and using ESP32. It works / fits well with ESPHome :heart: Maybe one day Victor will change his mind.

I agree with what you have said :grinning:

Hi I end up with a tplink bluetooth dongle and everything works!
Though I think probably I don’t need the dongle afterwards, as I found out since I was using custom advertising type (neither MIJIA nor BTHome), that’s why I don’t see anything auto-added. after I changed to MIJIA, it starts to pop up in hass.

yeah turns out my advertising type was wrong… after change it to MIJIA they pop up in hass one after another.

@kerbal Yep you must set the advertising to ether MIJIA or BTHome

That is totally correct. In theory, this

  • Option 1, add a temperature object id with only 1 digit in BTHome and change the pvvx firmware to use that (or better, make it optional).
  • Option 2, make an option in pvvx firmware to only send 21.00, 21.10, 21,20, 21.30 etc. This would achieve the same, less data points in HA
  • Option 3, Reduce the broadcasting frequency, just send out one advertisement per minute would be enough for most people, Should also result in less data points in HA. I was under the impression that this is already possible by adjusting the broadcasting interval, isn’t it?

Either way, I have no objection adding temperature with 1 digit to BTHome, but changes will have to be made to pvvx firmware as well, at least for option 1 and 2.

It may reduce battery but Victor says it will not (I will take his word on that)

pvvx firmware sends several measurements (e.g. temperature + humidity + battery) in one payload. The only difference it would make to leave out battery is that the payload is 2 bytes shorter, but it would still need to process and send the advertisement. I can imagine that this doesn’t make much difference in battery usage.

One option can be to disable the entities you don’t want to see in HA. In that way, they won’t be updated. There is an option to disable entities in HA.

Last thing, I don’t use these ESP32 for BLE, only for other ESPHome things not related to BLE. So I can’t give any advise on that. But I do hear some people that like ESPHome proxy a lot.

Yep, HA BLE integrations are only supporting MIJIA (xiaomi-ble integration) or BTHome (bthome integration). The other two are only supported in BLE monitor (I’m also the developer of that). I’m not sure I will move these to a core HA BLE integration, as the other two should fit everyone’s needs, I guess. It isn’t high on my priority list, at least.

1 Like

Don’t really need to change the pvvx firmware Victor thinks not as there are more cons than pros, hey I just happy it is available. Just if HA had a option for BTHome to select the decimal places in the settings like you can change unit of measurements just have decimal places as well. HA owns BTHome so they have full control to add this option.

You can’t. This is a quote from Victor

Quote: “BLE advertising is transmitted with a period of up to 10 seconds - a limitation of the standard. Most operating systems start to misbehave if BLE advertisements are transmitted with a period of more than 2.5 seconds.”

yep sending an extra 2 digits isn’t going to save battery. Victor has confirmed this. I thought it would be in BTHome inside the pvvx firmware. Are you still running a test?

yep and that is why I do that. No data colection well I think there is no data colection I haven’t look to see if that is the case. Maybe somone can confirm this.

yep I use it and it works well … very happy… the ESP is a bit warm but one would expect that.

Minor detail, but HA doesn’t own BTHome, BTHome isn’t a company. It’s just a format and its available for anyone who wants to use it. It’s just that I, as BTHome dev, use HA as my home automation system, but it’s free to use in any other home automation software.

The problem with adding options for the number of decimals is, how to define it. Setting it on a device level doesn’t make much sense, as devices can send different measurements, each with different precision. Setting it on object level (e.g. temperature) makes more sense, but there are already a lot of sensor types, and each one would need its own configuration option. To my opinion, the best solution would be that this can be changed on entity level ( for all integrations) in Home Assistant itself. But that would be a more general HA feature request (which probably already exists).

Agree with you.

I have just read

BTHome uses bluez and active scanning.
Due to the active mode, the batteries in the devices run out faster and there is a lot of writing to the disk.
Switch to passive mode.

I will stick with MIJIA as for these sensors I am happy with the format and the battery usage. It was exactly what I thought was happening.

No, that is not correct. The HA Bluetooth integration is using bluez, and both BTHome as well as the xiaomi-ble integration use the data gathered by the Bluetooth integration. So, it works exactly the same for the xiaomi-ble integration and the BTHome integration. In the beginning, the bluez (and thus theBluetooth integration) was only capable of doing active scanning, but in one of the latest releases, they added passive scanning to the Bluetooth integration, if your firmware is up to date.

One note, in the custom firmware, you will have to enable to include “flags” in the advertisements. It’s a checkmark next to where you select the advertisement format.

See also the last post in the link you gave

Switch to the passive scanning mode, and on the thermometers, enable the transmission of Flags.

Yea i saw that and also read this

I thought Victor was involved / had input with HA Bluetooth. So when he is saying batteries run out faster and it is a temporary solution and it for BTHome I thought it is easer to stick with MIJIA. Firmware is always up to date in HA but because last time I looked the PVVX was 3.9 beta so I though “it not broken don’t fix it type of attitude” so I am on 3.8.

So should I use the “flags” option for MIJIA and switch to passive? Or because I am on MIJIA just stick with what I got?

I use active so the flags are not considered?

Do you mean at first they had passive and then release active?