miflora-mqtt-daemon - MQTT Bridge for Xiaomi Mi Flora Plant Sensors

miflora-mqtt-daemon does one job: read a Xiaomi Mi Flora plant sensor over Bluetooth Low Energy and publish moisture, temperature, light and conductivity to MQTT, where a home automation system can pick them up.

Before describing how it works, there is a date you need.

The dates, in order

We cloned the repository and checked. The most recent commit on the default branch is from 3 August 2023, and its subject line is:

“Fix for HA 2023.8 and up”

The Python library it builds on, miflora, last published a release to PyPI on 15 January 2022 — version 0.7.2.

Meanwhile Home Assistant, the system that last fix was written for, is at 2026.10.1, released on 10 October 2026, after 1,633 PyPI releases on a monthly cadence.

So the bridge’s last compatibility fix targeted a Home Assistant release from three years and roughly thirty monthly versions ago, and the library doing the actual Bluetooth work has been untouched for nearly five years. This is not a project that is quiet because it is finished. It is a project that has stopped while everything around it kept moving.

That needs saying plainly, because the sensors themselves still work and are still sold, and people still arrive looking for exactly this.

What to use instead, and why it is better anyway

The good news is that the capability moved into the platforms, and the replacement is verified rather than assumed.

ESPHome ships a first-party component for this exact sensor: xiaomi_hhccjcy01 — HHCCJCY01 being the Mi Flora’s model number. Alongside it are xiaomi_ble, esp32_ble_tracker, ble_client and bluetooth_proxy. We confirmed each of those exists in the current ESPHome source tree.

That combination is not merely a substitute; it solves the problem the daemon always had. The daemon ran on one machine, which had to be physically within Bluetooth range of the plant. An ESP32 running ESPHome costs a few pounds, can sit in the room with the plant, and with bluetooth_proxy forwards BLE traffic over your network — so the sensor’s range problem becomes a WiFi coverage problem instead. You can put several around the house.

The practical migration: flash an ESP32 with ESPHome, add the xiaomi_hhccjcy01 sensor with your plant sensor’s MAC address, and the readings arrive in Home Assistant through ESPHome’s native API rather than through MQTT. One fewer moving part than the daemon, and maintained by a project that shipped this month.

If you specifically need MQTT — because something other than Home Assistant consumes the data — ESPHome can publish to MQTT directly. You still do not need the daemon.

When the daemon is still the right answer

There is one case: you have a Linux box with a working Bluetooth adapter already in range, you do not want to buy or flash hardware, and you need readings on a non-critical basis today.

In that case the daemon is eleven tracked files, it is MIT licensed, and reading it end to end takes ten minutes. It polls each sensor on an interval, publishes to a topic per sensor, and supports Home Assistant’s MQTT discovery so entities appear automatically. The design is sound; that was never the problem.

What to expect if you try it:

Dependency installation is the hard part. A 2022-era Python BLE stack against a 2026 distribution is where this breaks, not in the daemon’s own logic. Pin it inside a virtualenv or a container rather than installing into the system Python.
MQTT discovery may not match current Home Assistant. The last fix targeted the 2023.8 schema. Discovery payload expectations have moved since, so budget for entities appearing wrongly or not at all, and be prepared to configure sensors manually.
BLE polling is flaky by nature. Mi Flora sensors are intermittent even with good software. Missing readings are normal and your automations need to tolerate gaps.

Treat it as a stopgap with an exit plan, not as infrastructure.

The broader lesson, which is the useful part

This project is a good example of a pattern worth recognising in self-hosted software generally: a single-purpose bridge is the most fragile thing in your stack, because its entire value is compatibility with two systems it does not control.

The checks that would have told you this in thirty seconds, and that are worth running on any integration before you depend on it:

git clone --depth=1 <repo> && git log -1 --date=short    # last commit
curl -s https://pypi.org/pypi/<dep>/json | grep -o '"version":"[^"]*"' | head -1

Last commit date on the bridge, last release date on its key dependency, and current version of the platform it targets. When the first two are years behind the third, the bridge is a liability no matter how good the code is. ntfy is worth pointing your alerting at for the same reason — it is maintained, so when something stops reporting you find out.

The finding: miflora-mqtt-daemon’s last fix was for Home Assistant 2023.8 and its Bluetooth library has not seen a release since January 2022, while Home Assistant is now on 2026.10. The sensors are fine — use ESPHome’s xiaomi_hhccjcy01 component on an ESP32 instead, which also removes the Bluetooth range constraint that made this daemon awkward in the first place.