Energyid integration

[Molier]

Breaking change

Proposed change

Introducing the EnergyID integration! EnergyID is an online energy monitoring platform. This integration allows you send sensors from within Home Assistant (eg. energy meters, solar panels, batteries, ...) to your EnergyID-record, using their webhooks.

• Some reasons why you would want to upload data (specifically energy measurements) to EnergyID:

  • To store your data online, as a backup
  • To use the EnergyID web-app and/or mobile app. We have many analyses, dashboards, reports you might want to use.
  • To participate in energy communities via EnergyID (energy sharing, virtual power plants etc.)
  • Benchmarking of energy data with other users on EnergyID
  • Data portability (people want to get data into EnergyID that they can only get from within their local network, hence they want to leverage Home Assistant)

As seen before in some threads and git repos (1 , 2) there was some demand for an official integration for data -> EID and not just the other way around.

Type of change

• [ ] Dependency upgrade
• [ ] Bugfix (non-breaking change which fixes an issue)
• [x] 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

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request: https://github.com/home-assistant/home-assistant.io/pull/37472
• Link to developer documentation pull request:
• Link to frontend pull request: https://github.com/home-assistant/brands/pull/6539

Checklist

• [x] The code change is tested and works locally.
• [x] Local tests pass. Your PR cannot be merged unless tests pass
• [x] There is no commented out code in this PR.
• [x] I have followed the development checklist
• [x] I have followed the perfect PR recommendations
• [x] The code has been formatted using Ruff (ruff format homeassistant tests)
• [x] Tests have been added to verify that the new code works.

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

• [x] Documentation added/updated for www.home-assistant.io

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

• [x] The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• [x] New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• [x] 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:

• [x] I have reviewed two other open pull requests in this repository.

[home-assistant[bot]]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks :+1:

Learn more about our pull request process.

[JrtPec]

@zweckj

• Some reasons why you would want to upload data (specifically energy measurements) to EnergyID:
  • To store your data online, as a backup
  • To use the EnergyID web-app and/or mobile app. We have many analyses, dashboards, reports you might want to use.
  • To participate in energy communities via EnergyID (energy sharing, virtual power plants etc.)
  • Benchmarking of energy data with other users on EnergyID
  • Data portability (people want to get data into EnergyID that they can only get from within their local network, hence they want to leverage Home Assistant)
• By library code, you mean energyid-webhooks? We can add type hinting, tagged releases, CI... shouldn't be any issue but please confirm this is what you mean.
• Can you clarify about services? (are they now called Actions?). You would like this integration implemented as such?

[zweckj]

@zweckj

• Some reasons why you would want to upload data (specifically energy measurements) to EnergyID:

check ✅

• By library code, you mean energyid-webhooks? We can add type hinting, tagged releases, CI... shouldn't be any issue but please confirm this is what you mean.

Yes exactly. Type hinting is nice to have and only a requirement for platinum quality. Tagged releases and CI is required for every new integration.

• Can you clarify about services? (are they now called Actions?). You would like this integration implemented as such?

Exactly what I was thinking about, but now that I understand the use-case a bit better not fitting. So you'd basically select one or multiple entities and the integration would continuously push the updates to the cloud right? In that case a service (action) wouldn't be fitting as those are one time calls triggered by the user

[Molier]

implemented tagged releases and typing in linked library

[Molier]

updated the integration, updated the docs PR as well

[Molier]

@zweckj Hi! anything I can do to move forward with this PR? Not sure if i can refresh the review request , since that is from a long time ago, when the integration was in a different state a well. I ended up implementing the sub config flow and rewrote the integration to use our new Webhooks as well, if you have any questions I'm happy to address them :)

[Molier]

Hi @zweckj,

Thank you for your detailed guidance on using the correct handlers. I've now completed the refactor to use the Subentry Flow pattern for managing the sensor mappings.

During the implementation, I ran into a challenging conflict between the mypy static type checker and the runtime behavior for this "lightweight" subentry pattern (where the mappings are stored in the parent's options).

• Following the mypy-compliant examples (kitchen_sink, mqtt) of returning the handler class directly (return {"key": HandlerClass}) resulted in a runtime AttributeError, as self.config_entry was not available when the flow started.
• To fix the runtime error, a lambda factory (lambda: Handler(config_entry)) is necessary to correctly pass the config_entry during instantiation. However, this causes mypy to fail due to an incompatible return type error.

The final solution I've implemented uses the lambda factory to ensure the code works correctly at runtime, and adds a # type: ignore[] comment. This approach satisfies all the pre-commit checks and appears to be the standard way to handle this specific architectural inconsistency in Home Assistant.

But I still feel I`m not quite grasping the subentry flow

I have also addressed your other feedback:

• The reconfigure flow has been removed for now.
• Logging has been updated to use debug and remove redundancy.
• The unique ID now uses the HA instance_id.
• Other code style suggestions have been applied.

This should now be ready for another look when you have a moment. Thanks again for your help and patience!

[Molier]

@zweckj I was looking for a way to find strings that are not used and strings that I have perhaps forgotten to add. But could not find any script or anything to check that. Is there anything for that ?

[Jaxom99]

Hi :wave: I just tried to add this integration to my EID/HA setup and wanted to leave some feedback on it, if it can help... Here's my process:

1. Copying the integration manually to HA folders, then add it via the web interface.

2. I'm prompted for key/secret from EID.

3. I go to EID webapp, and display the integration page

4. Before clicking on "activate", I have to create provisionning ID (top right button)

5. I enter those in the HA web interface, in the EID integration form, and click "validate"

6. The integration display an empty frame with just the "validate" button.

7. When I click it, I have the error : claim_failed_or_timed_out

8. In EID, I then click on "activate" the integration : the following form requests a folder to add it to (I choose my house) and a claim code: I have none :neutral_face:

So that's where I'm stuck. There is no error in the console or in the HA logs, so I don't know where to look. I hope you can work this out @Molier and I stay available to share info.

PS: My HA versions are Core 2025.3.4 / Interface utilisateur 20250306.0

[emontnemery]

@Molier There are unresolved comments from previous reviews, please address them. You can message me on Discord if you want to discuss review comments or need some help 👍

[Molier]

tests pass locally, i cant rerun CI i think?

[emontnemery]

tests pass locally, i cant rerun CI i think?

Yeah, it's a github limitation to prevent bots opening PRs which use CI to do crypto mining 😬 Once your first PR has been merged, CI will be automatically started.

[emontnemery]

There are some uncovered lines in homeassistant/components/energyid/config_flow.py and homeassistant/components/energyid/energyid_sensor_mapping_flow_py, please add tests covering them. Considering the nature of this integration, I also think we should have full test coverage of homeassistant/components/energyid/__init__.py

To check test coverage locally, run pytest --cov=homeassistant.components.energyid --cov-report html tests/components/energyid

[Molier]

There are some uncovered lines in homeassistant/components/energyid/config_flow.py and homeassistant/components/energyid/energyid_sensor_mapping_flow_py, please add tests covering them. Considering the nature of this integration, I also think we should have full test coverage of homeassistant/components/energyid/__init__.py

To check test coverage locally, run pytest --cov=homeassistant.components.energyid --cov-report html tests/components/energyid

added tests for full coverage and added some more advanced test for init

[Jaxom99]

Woooohoooo, big up @Molier :wink: And thank you all for the careful overview of this integration!