You’ve tried both ideas, re-flashing and moving closer to the receiver? I can see one sensor is called “Frigider” aka Fridge. A fridge is almost a faraday cage, it is difficult to get radio signals through it, particularly 2.4GHz which is what Bluetooth is. My fridge sensor works only when it’s set to maximum power, top of the fridge, and I have a Bluetooth receiver with an antenna.
Yes, I have tried both, even removing the battery in between the re-flashing.
Indeed, it’s a fridge one.
With Xiaomi FW it was working without issues.
Occasionally I get this message:
And you see, I get data into HA when the first discovery after reflashing is made.
And one is like this:
I haven’t used the BTHome integration. I tried it a couple of months back and it wasn’t as good as the Passive BLE Monitor integration - link is to a guide I wrote.
I’m not an expert on either of these things, I just documented what worked for me 
I have bought an ASUS BT dongle and wow, everything works.
I guess the inbuilt RPi BT adapter is slowly dying,…
Interesting. I didn’t know you were trying to use Bluetooth built into the Pi, IMHO that’s only good for very short range.
Hi all, I’m the author of both BLE monitor and the BTHome integration, so if you need help, let me know. I saw some messages about the long time before it asks for the encryption key with stock firmware. Let me explain. The LYWSD03MMC has a broadcasting interval of 10 minutes, so only one message per 10 minutes (while some other Xiaomi sensors have an interval of 1 or 2 seconds). Unfortunately that means that if HA receives a message, it can take 10 minutes before the sensor is created, and another 10 minutes before it asks/checks for the encryption key. And if reception is bad, it can even take longer.
That is why pvvx has created the custom firmware, it will increase the broadcasting range to whatever you want. And it doesn’t really hurt if you miss some messages every now and than, if it broadcasts a lot.
3 Likes
You can read the tutorial and use it if it helps, otherwise I suggest you start a new question / thread with more detail than above - I find your question someone confusing. You’re welcome to tag me in the new question, I’ll help if I can.
From my experience I may be able to help a few people.
Firstly, get a long range Bluetooth Dongle with an external antenna and a USB extension lead to move it away from the computer. There’s a list of chipsets that work in HA, so anything from the list “should” be ok. I didn’t even disable my on-board one, HA just works with them both.
If you have small dropouts you can create an input_number helper entity and an automation to update it from the real one if the reading is valid. Then put the dummy one on the dashboard instead to always get a decent display. Here’s my automation.
alias: Preserve Temperature - Mi-1
description: Preserve Temperature - Mi-1
trigger:
- platform: state
entity_id:
- sensor.mi_1_temp
condition:
- condition: not
conditions:
- condition: state
entity_id: sensor.atc_b69f_temperature
state: unavailable
action:
- service: input_number.set_value
data:
value: "{{ states('sensor.atc_b69f_temperature') }}"
target:
entity_id: input_number.m1_1_temp_storage
mode: single
For an even nicer display, you can create a template sensor that gets its state from that. This makes the UI just show it without all of the editing stuff.
If you’re getting longer dropouts, try changing the advertising interval to avoid nice numbers. Also if you have multiple devices put them all on slightly different intervals. This is purely conjecture, but I think sometimes with two broadcasting in sync, the receiver can’t hear one of them, so randomizing the timings stops them from staying in sync.
Thanks for contributing @Hoagie . I have similar recommendations around Bluetooth adapter in one of my other tutorials that I linked to from the first post, but it’s specific to that adapter. I’ll put the general recommendation of using a USB Bluetooth adapter into the first post.
Hello
Not sure if I have miss anything but I did go to the page (TelinkMiFlasher) and flash my xiaomi sensor.
I did pick same settings as in the picture, just to have something to start with.
But I have problem to make my HA to find it.
I have got the Bluetooth to work in HA but when I trying to add BTHome it say “No devices found on the network”
Does it mean that BTHome can’t find ny BT adapter?
Make sure you’re using a device with bluetooth available. I find my Android phone works better than my PC even though both have bluetooth. This has nothing to do with BTHome, it’s your device talking directly to the temperature sensor.
Do you mean use my Android Phone to flash the temperature sensor?
A little update
Not sure if I did wrong with the firmware update (maybe did not upload the whole firmware) but when I did it again with my Android Phone I know got it to show in Passive BLE monitor.
It show temperature, humidity, battery status signal strength and voltage.
Nice and thanks alot
Great that you worked it out. The key part of the guide above is “Open the TelinkMiFlasher website on a computer or phone that has Bluetooth available”.
Hi Tim,
Just flashed my Xiaomi sensor. That went well.
After that i activated Bluetooth (build in) and added BTHome.
The sensor was recognised right away.
Thanks for you’re effort, very pleased with it.
1 Like
I agree with Hoagie that putting in some ‘random’ advertising intervals if you have multiple sensors seems to help.
I am now using two ESP32 proxies (I want to use them for other purposes too so don’t mind the small extra cost). Originally I set them with half the sensors each as they weren’t totally reliable with all the sensors on one proxy, I thought. However, I have found that any individual sensor will make excellent contact for a while then will randomly not be picked up, then a while later will start working again. My gut feel is that this is due to interference or ‘clashing’ data.
Now I have duplicated them so each proxy can receive all the sensors. This has resulted in all the sensors being picked up by at least one of the proxies all of the time. If one sensor stops reporting temporarily, I can handle the non-changing data in Node-Red using the up to date reading from the other proxy.
Just to report that it worked for me with 2023.03, using BTHome advertising, and few Shelly Plus over the house as BT Proxies
I’ll check the stability.
Thanks a lot for the guide!
I’ve got this working with a few bumps.
The Xiaomi hardware rev reported is LYWSD03MMC B1.6.
I was able to talk to it fine with the RPi4 onboard bluetooth but
added an Orico BTA-403 on the end of a 2m USB extension cable
which also worked well.
I found I did not need to talk to the Xiaomi with a phone app at all.
Flashed pvvx firmware version 4.2 via the TelinkMiFlasher.html page
with Chrome from my Mac laptop (running Monterey).
HA core 2023.4.2 can talk to it via the Xiomi BLE integration,
using the MIJA signalling protocol and ‘AD Flags’ turned on.
I don’t recall if HA detects it before flashing, I don’t think so.
I also was able to pick up the device with the BTHome integration
but I’m not sure if the two are happy talking to the same device.
I ended up disabling the BTHome integration to keep things simple.
The things it added to the Overview dashboard linger there, I am
not sure how to get rid of them as the dashboard is still being
maintained by HA. Is that a bug int he BT integration?
The problems.
With the first device I tried, I had a lot of trouble getting
my laptop (Macbook with Monterey) to find the BT signal and pair
with it via the wifi flashing page.
Even then, after I had flashed the device HA picked it up initially
and then lost signal after about 15 minutes. Quite confusing as they
were all sitting on the same desk; heaps of signal, no known interference.
Also after changing settings and uploading to the device (eg the
Advertising Interval), I often lose connection to HA. There does
seem to be some sensitivity to the Advertising Interval in particular;
on one device I had to lower it from 2500ms to 1500ms to get consistent
connectivity, but this wasn’t required for another device, the pvvx
defaults were ok. Apparently this has something to do with the lack of
a couple of capacitors Xiaomi left off the circuit board to save money;
there is some discussion of this in the pvvx github issues.
One trick I found useful was to power cycle the Xiaomi (pop out the
battery, then reinsert). After this HA picked up the device again
quite rapidly and pairing was easier. HA also maintains contact
properly; without the power cycle, contact may be lost again after
a few minutes. This may be an issue in this revision of the pvvx firmware,
a lot of people seem to have had good success with 3.9 but it has been
substantially reworked between then and 4.2; some of that refactoring
may have introduced some subtle issues.
They are a bit fiddly, but once you get them going they’re usually pretty solid.
“using the MIJA signalling protocol” makes me wonder if you’ve followed the guide. If you haven’t followed the guide, try following the guide precisely to see if it works better.