ble_monitor: forty BLE brands in Home Assistant, and a stated plan to end

The README says this project will probably be deprecated

The most important thing in this repository is a section headed Important announcement about the future of BLE monitor, and it is not hedged.

The sequence is roughly this. Home Assistant 2022.8 has improved support for passive BLE devices directly in Home Assistant. For each brand, a core BLE integration will be developed, such that maintenance can be divided over more people, using the latest Bluetooth packages, bleak. The author is working together with the Home Assistant devs to move sensors from BLE Monitor to Home Assistant core integrations.

Then the transitional warning. During the transition BLE monitor will still be available, but it is possible that the core HA Bluetooth integrations will not work nicely parallel to BLE monitor. The common symptom is that core integrations stop updating after a while, and the stated fix is to try to enable active scan in the BLE Monitor.

Then the recommendation and the endpoint. The advice is that when all your sensors are available in Home Assistant, make the move. The aim is to have all sensors moved into Home Assistant as core integration. After the move, BLE monitor will probably be deprecated.

That is a maintainer telling you the project has an end date and that the end date is when your last sensor is upstreamed. It is a rarer and more useful thing to find than a deprecation notice in a changelog, because it comes with the reason and with the specific symptom to watch for.

The reason is also the interesting part. A single custom component decoding forty brands of proprietary BLE advertisements is a maintenance bottleneck with one owner. Home Assistant's own integrations are many small components with many owners, each using the current bleak stack rather than a fork of an older one. So the migration is not a deprecation in the sense of abandonment; it is a division of labour, and this repository's job is to keep working until the division is complete.

The author's framing of the remaining work is a request rather than a roadmap: if you want to help moving sensors from BLE monitor, feel free to help. That is the clearest signal available about where effort is wanted, and it is the opposite of what a deprecation usually looks like.

Nineteen of the brands are already upstream, and the rest have a destination

The README carries two lists, and comparing them is the fastest way to work out whether you need this component at all.

The supported brands list runs to about forty entries: Acconeer, Air Mentor, Amazfit, ATC custom firmware for Xiaomi and Qingping sensors, Beckett, BlueMaestro, Blustream, BTHome, b-parasite, Chef iQ, Ela, Govee, Grundfos, HolyIOT, an automatic door brand, HHCC, Inkbird, iNode, Jaalee, Jinou, Kegtron, KKM, Mikrotik, Moat, Oras, Oral-B, Qingping, Relsib, Ruuvitag, Sensirion, SensorPush, Senssun scales, SmartDry, Switchbot, Teltonika, Thermobeacon with Thermoplus, Brifit and Oria, Thermopro, Tilt, Xiaogui scales, and three separate Xiaomi entries for MiBand, MiBeacon sensors and MiScale.

The official Home Assistant integrations list is shorter and already covers: BlueMaestro, b-parasite, BTHome, Govee, HHCC, iBeacon, Inkbird, Kegtron, Moat, Oral-B, Qingping, RuuviTag, SensorPush, Sensirion for the MyCO2 gadget, Thermobeacon, Thermopro and Sensorpro, Tilt, Xiaomi in two parts, and device tracking based on MAC address through the Bluetooth LE tracker integration.

That is nineteen entries against forty, and the overlap is not partial. Every one of the official entries corresponds to a brand the custom component also supports, with one exception worth noting: b-parasite is listed as will be using BTHome with new firmware, so that device is expected to leave the proprietary-decoding path altogether.

So the pattern is: the brands with the most users and the most stable protocols got upstreamed first. Govee, Qingping, Inkbird, Xiaomi and Tilt are the devices every BLE enthusiast already owned, and they are the ones now handled by core.

What remains in the custom component is the long tail: Air Mentor, Beckett, Chef iQ, Ela, Jinou, KKM, Moat, Oras, Relsib, SmartDry, Teltonika, Xiaogui, and the automatic door brand. Those are devices with small user bases, and small user bases are precisely why nobody had written a core integration for them. That is also why they are the ones a custom component is genuinely needed for, and why the migration will take longer for them than for the popular brands.

The practical read for a new user is short. Check the official list first. If your device is there, use the core integration and this component is irrelevant to you. If it is not, this component is the only practical option, and you should expect to move it later.

One gap in the lists is worth flagging. Release 14.3.0 is titled Mocreo and holyiot sensor update. HolyIOT is in the brand list. Mocreo is not, so the README's supported list was not updated when that release landed.

The parsing is moving to the Bluetooth-Devices organisation

The architectural consequence of the migration is stated in one line, and it is the part that matters if you build anything on top of this.

The README says that most pypi packages for the BLE parsing will be developed and collected at github.com/Bluetooth-Devices.

So the work is being split along a line that has nothing to do with Home Assistant. Right now this repository contains both the brand-specific decoding logic and the Home Assistant integration glue, and a user who wants a temperature reading has to install the whole custom component through HACS. After the split, the decoding becomes standalone pypi packages, one per protocol or per brand family, and the Home Assistant integrations become thin consumers of them.

That is a strictly better arrangement and it is worth being clear about why. Decoding a proprietary advertisement format has nothing to do with Home Assistant. It needs the BLE stack, a parser, and tests against captured frames. None of that is HA-specific, and all of it is more useful outside HA. A researcher analysing a Govee advertisement, or a script reading a kitchen scale, wants the parser and not the integration.

It also solves the version-skew problem that a single repository cannot. Right now a bug fix for one device means a release of the whole component, which means every user of all forty brands gets a new version for a change in one parser. With per-protocol packages, a device fix is a patch release of one small package.

For a user, the practical consequence is that your dependency graph is about to get deeper. Today you install one custom component. After the migration, the official integration for your brand will pull in one or more packages from the Bluetooth-Devices organisation, and those packages will have their own version histories. That is a better design and it is also a supply-chain surface you will need to know about, since a Home Assistant installation pulling BLE parsers from a second GitHub organisation is a topology your security review has not seen before.

The other detail in the announcement is the library the migration targets: bleak, described as the latest Bluetooth packages. bleak is the asynchronous Bluetooth stack Home Assistant uses, and the implication is that core integrations will be built on the maintained stack rather than on whatever the custom component grew. That is the specific technical debt being retired.

Passive by default, active when it has to be, and the interference that causes

The component's name and its default behaviour are both about passivity, and understanding what that means explains both its value and its one documented conflict with Home Assistant core.

Passive means the component listens to advertisements the devices broadcast on their own schedule, rather than connecting to them. Most of these sensors, kitchen scales, thermometers, hydrometers, leak sensors, are designed to broadcast a small payload containing their current reading several times a minute so that a phone app can find them. They do not expect a connection and mostly cannot hold one. So a passive listener picks up the reading with no pairing, no polling and no battery cost, because the device is transmitting whether or not anyone is listening.

That is why this component exists at all. There is no API to call, no local network protocol, and for most of these brands no documented format. The advertisement payload is the entire interface, and it is undocumented by the manufacturer. Decoding it is the work, and doing it for forty brands is a large volunteer effort.

The component can also be used as a device tracker for BLE devices with a static MAC address or with a UUID, which is the same passive mechanism applied to presence rather than to telemetry.

Now the conflict. The README's advice for core integrations that stop updating is to enable active scan in the BLE Monitor. That means the component is not purely passive by default, and switching it to active changes the behaviour of the Bluetooth adapter. Active scanning sends scan requests and solicits responses, which is how you discover devices that are not advertising, and the cost is that it changes what the adapter is doing on the radio.

In a Home Assistant installation where core integrations are also listening, that change can affect what they see. The documented symptom is that a core integration stops updating after a while rather than failing immediately, which is a much harder bug to diagnose than a startup error, and it is why the README frames the answer as a thing to try rather than as a clean rule.

So the two cannot safely run in parallel indefinitely, and the transitional guidance is to enable active scan as a diagnostic and then move your sensors to core as soon as they are available. Passive scanning is the right default and is what you want in a stable installation. Active scanning is a compatibility tool for a transitional one.

A release every few days, each naming one device that decoded wrong

The three most recent releases describe, in their titles, the maintenance loop this project actually runs.

14.2.0, tagged 2026-09-11, is titled More small changes. 14.2.1, tagged 2026-09-20, is titled iNode Care Sensor decoding fix. 14.3.0, tagged 2026-09-26, is titled Mocreo and holyiot sensor update.

Three releases in fifteen days, two of which name a specific device, and both of those name it as the thing that was broken. An iNode Care Sensor decoded wrong, so there is a fix. A Mocreo and a HolyIOT sensor were added or corrected, so there is a minor bump rather than a patch.

That is a healthy pattern for this kind of project and it explains the version number. Fourteen minor versions is a lot for a component that does one thing, and it is the direct consequence of the one-thing being forty brands of undocumented protocol. Each brand's manufacturer ships a firmware update, or a user buys a new model revision, or a device is found in a house that has been sitting there for three years, and the payload changes in a way nobody anticipated.

The last push was on 2026-09-26, matching the 14.3.0 release, so the default branch is at the newest tag. The release titles use a bare version number with no v prefix, which is the convention of the Home Assistant custom component ecosystem and is what HACS reads.

The distribution mechanism explains the rest of the repository listing. There is a hacs.json, which is the manifest for the Home Assistant Community Store, and an info.md, which is the description file HACS renders on its integration page. So installation is through HACS rather than pip, which means the integration is copied into a config/custom_components directory on the user's Home Assistant instance and is updated by HACS pulling a new tag.

Alongside those are the files of a maintained project: a .pre-commit-config.yaml so formatting and linting happen before a commit lands, an .ignore_words.txt that is a spellchecker allowlist for brand names and protocol terms nobody wants to hyphenate, a requirements_test.txt holding test-only dependencies separate from the runtime ones, a tools directory for the scripts that generate the device documentation, and a docs directory that gets published to the custom-components.github.io site.

The docs site is where the real documentation lives. The README is a list of links to it: introduction, installation, configuration parameters, supported devices, forwarding data from ESPhome, DIY sensors, FAQ, a new sensor request form, and developer documentation. The presence of a sensor request form and a developer documentation page, both linked from the README, is the clearest signal that the project is designed around third-party contributions rather than around a single maintainer's bandwidth.

BTHome is the answer to forty parsers, and DIY builders are pointed at it

The project has a design decision in it that is worth separating out, because it is the reason the long tail is not a permanent burden.

The README's link list includes a page titled DIY sensors, and the URL for it is the BTHome documentation. BTHome is also listed as a supported brand, and it is in the list of integrations already available as official Home Assistant integrations, with a note that b-parasite will be using BTHome with new firmware.

Read together, those three facts describe a deliberate strategy. Instead of recruiting a contributor to write a parser for every new sensor, the project points anyone building their own hardware at BTHome, an open protocol, and then has Home Assistant support BTHome natively. A DIY sensor that speaks BTHome needs no parser in this repository at all.

That is the escape valve for a project whose core problem is unbounded parser demand. Every proprietary brand is a one-off cost that someone has to pay. BTHome is a one-time cost that makes all future DIY sensors free, and it does so by moving the specification out of any single vendor's protocol and into something a firmware developer can implement from a document.

The b-parasite note is the proof that it works. b-parasite is an existing device, a soil and plant monitor, and it was supported by BLE Monitor as a proprietary target. The plan is that with new firmware it uses BTHome, at which point it is supported by the core integration rather than by a parser in this repository. That is a device being migrated out of the custom component's responsibility, and it is the model for the other thirty-nine.

The alternative strategy, which the project also has to support, is the sensor request form. Someone with a device nobody supports fills in a form, and a maintainer or contributor writes a parser. That path is necessary for the existing long tail of devices that cannot change their firmware, and it is the reason the version number is at fourteen. Both paths exist, and the mix between them is a judgement the maintainer makes per device.

For an evaluator, the practical question is which category your device is in. If it is a device whose manufacturer might ship new firmware, and it is one of the popular brands, wait for the core integration. If it is a device with fixed firmware and a small user base, this component is the only option and the sensor request form is the way to accelerate it. If you are building the sensor, use BTHome and you will never need this repository.

The documentation is nine pages off-repository, and the ESPHome section is a warning

Two structural facts about this project that are easy to miss and that shape how you evaluate it.

The first is that the README is an index. The actual documentation lives on a separate site, custom-components.github.io/ble_monitor, and the README is a list of ten links: introduction, installation instructions, configuration parameters, supported devices, forwarding data from ESPhome, DIY sensors under the BTHome URL, an FAQ, a new sensor request form, developer documentation, and a forum thread. The homepage of the repository is not the documentation site at all, it is the Home Assistant community forum thread for the integration, which is a useful signal about where support happens.

So the repository's own documentation is thin by design, and the device list, the configuration options and the FAQ are all somewhere else. That is a reasonable division for a project with this many devices, since the supported-devices page is generated rather than hand-written, but it does mean the repository cannot be evaluated in isolation. The tools/ directory at the root is presumably the generator.

The second is a whole README section devoted to something that does not work. It is headed Why isn't ESPHome Bluetooth Proxy not working with BLE monitor, and the answer is one sentence: ESPHome Bluetooth Proxies cannot forward data to BLE monitor, with a link to a page of alternative solutions.

The double negative in that heading is a small sign of how the question actually arrives, which is as a support thread. And the reason it is a permanent incompatibility rather than a bug is architectural. An ESPHome Bluetooth proxy relays advertisements it observes to Home Assistant's own Bluetooth stack, and BLE Monitor needs the raw advertisement frames, including ones the proxy may filter, deduplicate or reshape as it relays them. BLE Monitor is a listener of the adapter; an ESPHome proxy is a filter in front of a listener. The two are at different layers, so there is no configuration that makes them compose, which is why the README says cannot rather than does not by default.

That is a genuinely useful thing to have written down. A user who has an ESPHome Bluetooth Proxy installed for other reasons will spend an afternoon discovering this, and the README saves them the afternoon by saying it plainly and pointing somewhere else.

The pattern across the whole README is the same one. Transient states get documented as transient: the parallel-installation interference with core integrations, the ESPHome incompatibility, the deprecation timeline. Stable facts get delegated to the docs site. For a project at version fourteen, migrating its brands to core, that is a well-judged division of a limited amount of attention.

Editorial conclusion

Adopt ble_monitor if you have a BLE sensor whose brand is not in the list of official Home Assistant integrations, because passive advertisement listening is the only way to get a reading out of a device that has no open protocol and no local API, and the component already handles forty brands. Do not adopt it as a long-term foundation, because the author says in the README that it will probably be deprecated once your sensors are available in Home Assistant core, and that statement is the project's own position rather than a rumour. Do not run it alongside core integrations indefinitely, because the documented common symptom is that core integrations stop updating after a while. Verify five things. Check the list of integrations already available as official Home Assistant integrations first, because a third of this project's brand list is already upstream and you may not need the custom component at all. If you do need it, confirm your brand appears in the README's supported list, and note that release 14.3.0 added Mocreo and HolyIOT support while the README's list still omits Mocreo. If your sensors are DIY, build them on BTHome rather than contributing a parser, because that is the route the project is steering people toward and the one that will still work after the migration. Read the configuration parameters page, since passive and active scanning behave differently and the active-scan workaround in the README has side effects. And plan the move: the parsing libraries are being collected at the Bluetooth-Devices organisation, so a future version of your stack depends on a separate set of pypi packages rather than on this repository.

Frequently asked questions

Official sources

1. custom-components/ble_monitor on GitHub
2. License: MIT
3. Project website
4. README
5. Releases