I’ve started my HA journey using Xiaomi Mijia (LYWSD03MMC) temperature sensors with ESP32 to feed back to HA. The intent is to trigger heaters on/off in my kids rooms based on temperature overnight.
One issue i’m experiencing is the frequency to which the Xiaomi devices relay data back to HA. Some devices are feeding back temperature, humidity and battery data every 10~ mins which is acceptable however others can take anywhere from 1-7 hrs. Not ideal when you’re trying to trigger heaters on/off if there’s a 1+ hr lag between data.
Would anyone have any suggestions to how I might be able to improve the reliability of the Xiaomi devices polling back to HA?
I’ve had same problems. Using third-party FW solved them all.
Other FW solution (beside the one from lordzid) is THIS ONE. It has even more options, among others you can set BT transmission power, change name… It’s based on atc1441, but with some “add-ons”.
If they are all the same (LYWSD03MMC) I expect that they are just to far away (or wall/objects degrading the reception heavily).
I have around 8 of this devices in use together with esp32’s (running esphome obvisouly) and the maximum reliable distance to receive data (in a 10 minute interval) with the esp32’s is around 10 meters with no obstacles. One wall might work when the distance is only ~5 meters but with two walls already only occasional ble packets are received (like hourly or less). Another thing which happily “eats” ble packets are human bodys!
I also made some short experiments with (no name) external antennas on a esp32 but it didn’t improve the situation at all compared to a esp32 with onboard antenna.
I have 4 of them currently (additional 4 waiting to come) and they all work perfect on 2 pcs. of ESP32 (one in each floor, 2 modules per ESP). After EPS32 reboot i wait max. 1 minute for all data to show up. More than good enough. All of them have pvvx FW. With original FW i’ve had to wait up to half an hour for data to show up.
@orange-assistant : what would be alternative instead ESP32 on ESPHome and HA? And, i’ve read somewhere that latest generation of ESP32 has beter BT…?
Good question. For my use case the 10 minute interval I receive (stock fw on the mija’s) is totally fine. Alternatives are mentioned in the issue tracker from pvvx (like using a raspberry pi for example).
Not sure if this will improve the quality. I think the problem is more with the bluetooth stack of the esp32 or the bluetooth tracker integration and not really a hardware issue itself.
We might see major improvements of the situation if we get code updates upstream or from esphome itself.
ESP32 is known for high loss mostly because it uses the same radio module for BLE and WiFi in a shared way. There are many Bluetooth implementations for ESP at various qualities of handling this.
You can still get good BLE performance on ESP32 if you’re not using WiFi at all, but use an Ethernet module instead. Look for Olimex ESP-32-POE, WirelessTag WT32-ETH01, TTGO T-Internet-POE ESP32 or similars.
It will disable wifi completely and radio will only do BLE. It will not catch all the messages but will be perfectly usable for room temperature control in everyday life, multiple messages per minute will surely arrive into the system from each sensor advertising. Place it in a central location at relatively similar distance from most of them.
Avoid placing the ESP node in racks, too close to switches or other network equipment as EMI interference may degrade signal reception!!
Run ESPHome with Ethernet configuration and use esp32_ble_tracker with pvvx_mithermometer.
interval: 5s # try with 300ms if you don't have LAN module
window: 5s # try with 300ms if you don't have LAN module
If you need to stick with WIFI nodes, another option worth to try is: power_save_mode: none
in the wifi configuration.
However, a node with LAN connection will always give better results!
Full config example at:
If you run many BLE advertising sensors you may consume quite a lot of memory which can make OTA update of the ESP node harder (connection may break during OTA and node reboots). To overcome this, make sure to add the Safe Mode button to your configuration (see example above). When you press this button in HA, the node will reboot in Safe Mode which means it’s only running the network connection and OTA functionality, so you can upgrade firmware safely. It will reboot back to normal after OTA finishes. (if you forgot to add this press reset/EN button on your node 10 times, with 5 seconds delay between presses).
Do not add web server or any other component which is not absultely necessary as esp32_ble_tracker is a bit memory intensive. It’s recommended to dedicate this node only for BLE message reception. Using HA API with encryption leaves me with about 75k of free heap memory:
10 pieces of Xiaomi LYWSD03MMC, pvvx fw through one single WirelessTag WT32-ETH01 running ESPHome 2022.3, feeding HA server at a different location:
Since HA 2022.9 there’s BTHome and Bluetooth Proxy which allows to forward BLE data straight into HA and creates the sensors there.
Same trick with interval = window can still be applied with Bluetooth Proxy to gain high density.
The biggest advantage is that this way fault tolerance is achieved: you can place multiple ESPHome nodes running Bluetooth Proxy around the house, thus increasing coverage, plus, data is being catched by multiple nodes at once so even if one node fails or “misses” the packet, you can still get the data through the other nodes, and they feed the same sensor.
Further advantage is that you can use pvvx firmware with BTHome and encryption with bindkey.
Disadvantage that this way you don’t get the native ESPHome sensors anymore and can’t use ESPHome’s own filters - the sensors are implemented natively in HA by the BTHome integration, but they are automatically discovered.
How are you powering up the WT32-ETH01? And how difficult is it to get the same level of proxy functionality as on the devices programmed through ESPHome Bluetooth Proxy (aside from having to hook up a serial port using wires)?