Add Leneda integration - base functionality #145972
Conversation
|
|
||
|
|
||
| @pytest.fixture(autouse=True) | ||
| async def recorder_mock( |
| _LOGGER = logging.getLogger(__name__) | ||
|
|
||
|
|
||
| def _create_statistic_id(metering_point: str, obis: str) -> str: |
| "title": "Leneda Authentication", | ||
| "description": "Set up your Leneda integration by providing your Energy ID and API key.", | ||
| "data": { | ||
| "api_token": "API Key", |
There was a problem hiding this comment.
Can be replaced with the common string "[%key:common::config_flow::data::api_key%]" as you already have on line 63.
| "entry_type": "Metering point", | ||
| "step": { | ||
| "init": { | ||
| "title": "Add Metering Point", |
There was a problem hiding this comment.
Can be replaced with reference to line 93, also fixing the missing sentence-casing this way.
| from .const import CONF_API_TOKEN, CONF_ENERGY_ID | ||
| from .coordinator import LenedaCoordinator | ||
|
|
||
| PLATFORMS: list[Platform] = [Platform.SENSOR] |
There was a problem hiding this comment.
Am I missing something, it seems the sensor platform is missing (no sensor.py)?
There was a problem hiding this comment.
You are right - the sensor platform is coming up.
I am "stacking" PRs as I have the whole thing laid out locally, but will introduce the changes bit by bit. This bit unfortunately slipped through.
So, it's going to be relevant for the next PR. If you wish, I can also completely remove it from the current PR.
There was a problem hiding this comment.
I would recommend including the basic sensor platform at least and improving on that after merging. Just in case this takes a while, and not everything is ready for 2025.7.0. At least the integration will do something, otherwise this could cause errors and problems for users.
There was a problem hiding this comment.
Yeah, this is what made me so torn between having one big (first) PR and several smaller ones. As it stands, the current PR will only allow users to add authentication (config entries), and not even metering points / energy meters (config subentries).
To have something "usable", the metering points stuff will need to be included as well. 😅
There was a problem hiding this comment.
I think the initial PR should be the MVP, so in this case, no logic around dynamic metering points or anything, just register what is available and create something. But I'll leave that for someone from core.
Proposed change
This change introduces a new integration for the Leneda Luxembourg Energy Platform. The platform allows users to read electricity and gas consumption and production data. This integration allows to connect Home Assistant to the platform.
The user configures an account (Energy-Id + API token), and can then add metering point(s) per account. A metering point is like an electrical or gas meters that can be read out.
Please note that this is a new iteration of an earlier attempt. The previous PR was closed by me: #144774
Major differences since the previous PR:
What's in this PR?
This PR lays the groundwork for the Leneda integration and focuses on scaffolding and very basic core functionality:
Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.To help with the load of incoming pull requests: