Skip to content

Conversation

@patman15
Copy link
Contributor

@patman15 patman15 commented Dec 21, 2025

Proposed change

This is the PR add support for integrating over 30 different battery management systems (even more battery brands/models). The new integration bms_ble Bluetooth Low Energy (BLE) battery management systems (BMS) that is currently available as HACS integration. The sensors follow a consistent schema, while the BMS themself have a big variance in published data points. I oriented my self on the principles that the NUT integration uses, i.e. consistent data over a wide variety of devices.

  • The data is received via local polling over Bluetooth Low Energy with the library aiobmsble with the changelog.
  • The manifest of the integration is kept as short as possible, but due to high number of supported devices it's still quite long. Selection of supported devices is done in a second step in the library. Test data ensures the consistency between the two steps.
  • If desired, virtual integrations could be added for the most popular devices

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Deprecation (breaking change to happen in the future)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

Checklist

  • I understand the code I am submitting and can explain how it works.
  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • I have followed the perfect PR recommendations
  • The code has been formatted using Ruff (ruff format homeassistant tests)
  • Tests have been added to verify that the new code works.
  • Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

@patman15 patman15 marked this pull request as ready for review December 21, 2025 19:58
await coordinator.async_config_entry_first_refresh()

# Insert the coordinator in the global registry
hass.data.setdefault(DOMAIN, {})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
hass.data.setdefault(DOMAIN, {})

Is it needed?

Copy link
Contributor Author

@patman15 patman15 Dec 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a left-over from the pre-config-entry-runtime-data-era, https://developers.home-assistant.io/blog/2024/04/30/store-runtime-data-inside-config-entry
fixed in 10425b5

"""Set up BT Battery Management System from a config entry."""
LOGGER.debug("Setup of %s", repr(entry))

if entry.unique_id is None:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it needed? When can such entries be created?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, I'm not sure. In theory it could happen if there is an issue with Bluetooth and the discovery info is incomplete. I have seen strange things happen also with wrong data via proxies, so I would see it as part of defensive programming. Nevertheless, I have no strong feelings about it if you suggest to remove it.

return unload_ok


async def async_migrate_entry(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new integration should not have migrations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was unsure about this, due to the fact that there are a lot of users of the HACS integration. Will it cause issues if I remove this migration function? I'm not sure about the switch-over, but other than that, I can remove it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After discussion on Discord, removed. Thanks! Fixed in b7c2e4f

return True


def migrate_sensor_entities(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new integration should not have migrations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed. Thanks! Fixed in b7c2e4f

)

if user_input is not None:
address: str = str(user_input[CONF_ADDRESS])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should normalize the MAC address because the user may enter the address in the wrong format, e.g., lowercase/uppercase, etc. Generally, it is a good idea to do this in any case when saving data, including when the mac address comes from discovery info. See: #157879

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed in b18eff2

@patman15 patman15 requested a review from mik-laj December 29, 2025 09:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants