ha-bambulab: a Home Assistant custom integration for Bambu Lab printers

A thin README pointing at real documentation

The README for this integration is almost entirely badges and links, and reading it as a limitation rather than a failure is the right approach. There is a one line description, a link to a Discord server, a link to the documentation, a contribution link, and a licence statement.

The substance is elsewhere. Full documentation is hosted on a separate documentation platform at a docs.page address, the project has a `hacs.json` file at the root declaring it as a HACS integration, and there is a `docs/` directory in the tree plus a `docs.json` file. Installation instructions live on the documentation site under an installation page, and contribution guidance has its own page there.

So the repository is the integration plus its packaging metadata, and the documentation platform is the manual. That is a common arrangement for Home Assistant custom integrations, where the documentation often has to be readable outside a code hosting site, but it means you cannot evaluate supported hardware or configuration options from the repository alone.

What a custom component is and why the installation path matters

The topics tag this project as a HACS integration and a Home Assistant custom component, and that classification explains its whole shape. Home Assistant has a core integration system with reviewed contributions, and it also supports custom components that users install themselves from outside the core tree.

HACS is the community tool for that second path. The README's setup section is a single badge linking to the Home Assistant Community Store repository page for this integration, which is the flow: add the repository in HACS, install the integration from it, and then configure it. The repository contains a `hacs.json` file, which is the metadata HACS reads to know what the integration is and how it should be presented.

The reason this matters for an evaluation is durability rather than convenience. A core integration ships with Home Assistant and is maintained under Home Assistant's own review and release process. A custom component depends on Home Assistant continuing to support custom component loading, and on this repository continuing to track Home Assistant releases. Both have held so far, and the integration has a release cadence that suggests active work, but the risk profile is different from a core integration and worth naming rather than glossing over.

Release cadence: frequent, and often pre-release

The release history explains what to expect from upgrades. Version v2.2.26 was published on 2026-09-12, and the releases before it are v2.2.26-beta5 on 2026-09-06 and v2.2.26-beta4 on 2026-08-29. Both badges at the top of the README distinguish the latest beta release from the latest stable release, and the stable badge uses the GitHub pre-release aware version query.

That pattern says the maintainer iterates publicly on a single version number before tagging it stable, shipping a new beta every week or so. It is a healthy sign for responsiveness and a mild annoyance for automation, because an update job that tracks pre-releases will pull a beta rather than a stable tag.

The repository also keeps a `release_notes.md` at the root, so change information is available in the repository even though the feature documentation is not. The last push was on 2026-09-21, which is recent, and the repository is not archived. The language is Python, the licence is MIT, and the default branch is `main`.

The tree tells you what the integration actually does

Without documentation in the repository, the file tree is the best evidence available, and it is more informative than it first appears. The root holds `custom_components/` where the Home Assistant component code lives, `tests/` for the test suite, `scripts/` for helper scripts, and `docs/` alongside `docs.json` for the documentation source. There is a `CONTRIBUTING.md` and a `.github/` directory for workflows.

A `custom_components/` directory means this is not a Home Assistant integration authored against the core integration API but a component loaded at runtime, which is the structural consequence of the HACS distribution model described earlier.

The presence of a `tests/` directory is the detail worth noting. Custom integrations in this ecosystem are often shipped with no automated tests, because the maintainer is a user solving their own problem rather than a team with review requirements. A test directory suggests the maintainer is treating this as software rather than as a personal script, and it also means a failure you hit may already have a reproduction nearby.

The `scripts/` directory is presumably for development and release automation rather than runtime behaviour, which fits the pattern of a project that publishes through HACS releases rather than through Home Assistant's own build system.

Choosing between this and the vendor path

The honest comparison here is between a Home Assistant integration and what the printer's own software offers. Bambu Lab printers ship with their own application, and that application is the authoritative source for the full detail of a print: layer progress, nozzle and bed temperatures, filament usage, and the queue of pending jobs.

A Home Assistant integration offers something different. It puts printer state into a system that is already on your wall dashboard and your notification path, so a failed print can raise a Home Assistant automation alongside your other alerts. That is the value, and it is a real value for people who already invested in Home Assistant automations.

What it does not offer is depth. An entity exposing temperature or status is not a replacement for a print management interface, and anyone who needs to intervene mid print will still reach for the vendor app. The integration also inherits Home Assistant's restart behaviour: if Home Assistant restarts, entities go unavailable briefly, and the printer itself is unaffected because the integration observes rather than controls.

The question to ask before installing is whether you want alerting on the printer or control of it. If alerting, this fits. If control, it is a supplement and not a replacement, and the documentation on the external platform is where to check what is exposed.

Editorial conclusion

ha-bambulab is worth trying if you already run Home Assistant and want printer status, progress and temperature as entities rather than opening a vendor app. It is a custom component rather than a core integration, so it depends on Home Assistant continuing to support that installation path, and its documentation lives on an external documentation platform rather than in the repository. The practical check before installing is whether your printer model appears in the integration's documentation, because the README itself says nothing about supported hardware. Releases are frequent and often pre-release: v2.2.26 shipped on 2026-09-12 after several beta builds of the same version.

Frequently asked questions

Official sources

1. greghesp/ha-bambulab on GitHub
2. Issues
3. License: MIT
4. README
5. Releases