Add get tariff from cache action/service to enphase_envoy #134820
Conversation
|
Hey there @bdraco, @cgarwood, @joostlek, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
| # setup the nephase_envoy action services | ||
| await setup_hass_services(hass, entry) |
There was a problem hiding this comment.
typo
We should set these up in async_setup not in async_setup_entry. Please check the iqs on that
There was a problem hiding this comment.
Thanks for the review, I've moved it to async_setup and applied related changes for it.
|
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
|
|
||
|
|
||
| async def async_setup(hass: HomeAssistant, config: ConfigType) -> bool: | ||
| """Set up Enphase Envoy integration.""" |
There was a problem hiding this comment.
| """Set up Enphase Envoy integration.""" | |
| """Set up Enphase Envoy integration.""" |
| SERVICE_GET_FIRMWARE = "get_firmware" | ||
| SERVICE_GET_FIRMWARE_SCHEMA = vol.Schema( | ||
| { | ||
| vol.Required(ATTR_ENVOY): cv.entity_id, |
There was a problem hiding this comment.
I think we can also do a ConfigEntrySelector and select the config entry. (If I assume correctly that this is on a per enphase basis and not on a (sub) device basis). This way we don't give the user 100s of entities to pick from, but just every system they have, which is clearer I think
There was a problem hiding this comment.
Reworked to use ConfigEntrySelector ,
| return { | ||
| "firmware": envoy_to_use.firmware, | ||
| "previous_firmware": previous_firmware, | ||
| } |
| return None | ||
|
|
||
|
|
||
| def _find_envoy_coordinator( |
There was a problem hiding this comment.
I probably should have pointed you to this before, sorry for that. But have a check at Mealies services
There was a problem hiding this comment.
Used the Mealies format.
| # if there's difference between coordinator fw | ||
| # and envoy one, user should reload the entry | ||
| return { | ||
| "firmware": envoy_to_use.firmware, | ||
| "previous_firmware": previous_firmware, | ||
| } |
There was a problem hiding this comment.
But why would this happen? If the user should do that, why don't we build that in for them?
There was a problem hiding this comment.
Firmware refresh will move to coordinator. Replaced get)firmware service by get_raw_tariff services that returns a single endpoint only from raw cache. See updated description.
Proposed change
The enphase envoy integration collects data from the envoy device to populate various entity data. The set of available entities is based on actual envoy model, firmware version and configuration. Overall a most applicable set is provided for these mentioned drivers. When data is collected for the entities from various endpoints on the Envoy, all returned data is locally cached as 'raw' data. The raw cache contains more data as used for the entities.
This PR adds a service enphase_envoy.get_raw_tariff, to view 1 specific dataset from the raw cache: /admin/lib/tariff. This is data related to envoy battery operation. Recent firmware changes seem to have broken operation of some existing selector and switches. With this service the developers tools / actions tool can be used to view the full tariff data details and evaluate effect of changes on the battery operation. This data comes from the local cache maintained by the regular updates, no additional envoy communication is performed.
The documentation for below actions can be viewed here: https://deploy-preview-36740--home-assistant-docs.netlify.app/integrations/enphase_envoy/#action-enphase_envoyget_firmware
EDIT: This PR has been reworked after review. The original firmware retrieval will be made part of the coordinator itself. This service scope is limited to a single endpoint in the local cache.
Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
Documentation added/updated for www.home-assistant.io
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: