Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
SolarEdge Local Component #23996
Creates a new integration similar to the current SolarEdge component, except this communicates over a local API instead of cloud polling. Note, this is not a replacement for the current SolarEdge component, as many SolarEdge Inverters do not have this API. Details are available in the documentation
Related issue (if applicable): fixes drobtravels/solaredge-local#2
Example entry for
I'm happy to architect this however is recommended, however there are some big differences between the local API and cloud, which may make this component very messy.
To start with I exposed the same parameters to keep it simple, but the local API exposes a lot of details that the cloud version doesn't have such as optimizer level information, production meter information, and real time status. Likewise cloud API has historical data not found in the local api. Some users may want to use both together.
They also use different protocols. The local API uses protocol buffers with no authentication, while the official cloud API supports JSON, XML, and CSV with API key authentication.
Due to these differences, they will likely require 2 independent python packages to communicate and different implementations.
Let me know how you recommend proceeding or if I can provide additional details.
@rohankapoorcom Let me know if you have any further guidance based on my comments above. If they were combined into a single component, I can think of two options for user configuration
sensor: - platform: solaredge local_api: enabled: true ip_address: 192.168.1.130 cloud_api: enabled: true api_key: API_KEY site_id: SITE_ID monitored_conditions: - lifetime_energy - energy_this_year - energy_this_month - energy_today - current_power - site_details - sensors - gateways - batteries
sensor: - platform: solaredge local_api: enabled: true ip_address: 192.168.1.130 monitored_conditions: - lifetime_energy - energy_this_year - energy_this_month - energy_today - current_power cloud_api: enabled: true api_key: API_KEY site_id: SITE_ID monitored_conditions: - site_details - sensors - gateways - batteries
From an end user perspective, I think option 1 might be confusing as different monitored_conditions will be supported based on which APIs they configured. Option 2 seems fine but doesn't seem any better then two separate components IMO. From a code perspective, I think they should remain two different python packages.
Based on upcoming ABR003 -> home-assistant/architecture#244
Remove monitor condition. I think the local component is fine because it's a completely different protocol. I agree with @rohankapoorcom but it is how it is with smart homes... So you can choice if you want to merge the APIs together or let it like it is.