8000 Add SolarEdge Modules integration by tronikos · Pull Request #146036 · home-assistant/core · GitHub
[go: up one dir, main page]
Skip to content

Add SolarEdge Modules integration #146036

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 3 commits into
base: dev
Choose a base branch
from
Open

Add SolarEdge Modules integration #146036

wants to merge 3 commits into from
+720 −1

Conversation

tronikos
Copy link
Member
@tronikos tronikos commented Jun 2, 2025 •
edited
Loading

Breaking change

Proposed change

This is similar to https://github.com/ProudElm/solaredgeoptimizers but:

  1. uses a different endpoint which only provides energy (in Wh) but provides data for all equipment in a single response.

    I personally don't find current and voltage useful. To get those we would have to make several requests, one for each module, similar to the custom integration, but that would be too slow. Among all my integrations the solaredgeoptimizers is an order of magnitude slower. Now there is a single request for all equipment: inverter/string/module for the last 7 days.

  2. uses statistics instead of sensors since data is often delayed by a couple of hours.

    Data isn't real time. It's often delayed by longer than an hour. The custom integration suffers from this which polls every 15m and uses 0 if data is longer than 1 hour. This has now made that integration practically useless. See many open issues in that repo. Since data isn't real time I opted for polling every 12 hours (seems a good value to me; users who want faster can reload the integration via an automation) and inserting the data into statistics for use in Statistics graph card.

I opted for a new integration instead of the existing SolarEdge integration due to:

  1. It uses unofficial API for Web requiring username/password while the current integration uses official API which only requires API key.
  2. Config flow would be complicated supporting both adding confusion to the user why they need to provide both API key and username/password pair. Also would we want to allow only one of the two? E.g. I'm getting data locally via modbus every second and don't need the SolarEdge API integration but I want the SolarEdge Modules integration since per module data is not available via modbus.
  3. New integration only adds statistics, no sensors, so it's meant for advanced users using statistics cards. Why fill the database for average users that don't even know the data exists?

Example using Statistics graph cards:
image

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

  • 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.

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:

@tronikos tronikos mentioned this pull request Jun 3, 2025
Open
8 tasks
8000
@tronikos tronikos marked this pull request as ready for review June 3, 2025 00:40
@frenck
Copy link
Member
frenck commented Jun 3, 2025

It seems like this is web scraping the web interface/portal, right?

../Frenck

@tronikos
Copy link
Member Author
tronikos commented Jun 3, 2025

It seems like this is web scraping the web interface/portal, right?

../Frenck

There is no scraping. There is only 3 requests being done: one for login, one for getting the equipment layout (the integration only uses the display name from it), and one for the energy production over the past week. The login response is XML which we don't need to parse. Instead we extract the token (valid for 21 days) from the session cookies. The other 2 responses are JSON. See the code at https://github.com/tronikos/solaredge-web/blob/main/src/solaredge_web/solaredge.py

erwindouna
erwindouna suggested changes Jun 3, 2025
View reviewed changes
@tronikos tronikos mentioned this pull request Jun 3, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@erwindouna erwindouna erwindouna requested changes

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
cla-signed core has-tests integration: solaredge_modules new-integration quality-scale
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@tronikos @frenck @erwindouna
0