Add Utility Cost helper component

[mikke89]

Proposed change

Add a new helper component which calculates the utility costs based on a utility consumption sensor and a price sensor.

Some use cases enabled by this change:

• Track the energy costs of individual sensors.
• Track the cost of any utility even when it has variable pricing.
• Track the cost of the same utility based on different pricing models (e.g. spot vs. fixed pricing).

These use cases are not easily solved otherwise:

• Currently, it is possible to track the overall cost of your energy usage in the energy dashboard, based on the price from a given entity. However, sometimes it is useful to break this cost down to individual sensors. This is not possible from the energy dashboard.
• The utility meter can break consumption into fixed tariffs, but this is not sufficient for continuously varying prices, such as based on hourly market prices. This can be worked around by using the the Riemann integration sensor coupled with the total current power usage, see e.g. this community thread. However, this is a convoluted step, and additionally, it won't work for utilities that are only available in their accumulated form (e.g. if you only have total energy consumption and not power).

Furthermore, this may lead to a simpler setup for people interested in utility costs even when their pricing is divided into tariffs. Previously you would need to set up a utility meter with tariffs which produces different sensors for each tariff, and a selector. Then an automation for the selector would be needed, and finally a template sensor to sum up all the tariff sensors together at each tariff's price. Instead, if you can express your price as a single template sensor then with this feature you would only need that price sensor in addition to your consumption meter.

The helper component can be setup using the frontend (Settings -> Devices & Services -> Helpers -> Create), or by adding a sensor using the yaml configuration:

sensor:
  - platform: utility_cost
    utility_source: sensor.energy_consumption
    price_source: sensor.energy_price
    name: energy_cost

This sensor is made such that it resets any time its utility_source resets. Thus, to get the cumulative cost for a given period (e.g. daily, monthly), it can be setup to use the output from a Utility Meter which handles the resets on the given periodicity. Just like the Utility Meter, there is also a last_period attribute which records the value before the last reset.

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 is a result of the discussion in #77443. While the use cases are equivalent, this PR instead implements this functionality in a separate helper component. This was the desired approach as discussed in the previous PR. Pinging @dgomes and @emontnemery as these were active in the previous discussion.

There was a discussion about re-using EnergyCostSensor in homeassistant/components/energy/sensor.py, as it implements a lot of the same functionality. However, I decided to make a separate sensor. First, I figured it would be more helpful if we generalized this feature to any utility rather than just dealing with energy. Additionally, I was worried about any potential complexity arising from coupling these components tightly. I think in the future it might make some sense to spawn a utility cost sensor from the energy dashboard instead of the other way around, but I wanted to keep things simple for now.

Please feel free to voice your thoughts on the naming of everything, the component itself, the attributes, and the configuration.

I'm quite new Home Assistant development, I've tried to follow the dev checklist and write tests as best I can. I'd appreciate assistance with any steps needed before it can be accepted. Please feel free to push changes to this PR if you see some potential for improvements.

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] The code has been formatted using Black (black --fast homeassistant tests)
• [x] Tests have been added to verify that the new code works.

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.
• [ ] Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• [ ] No score or internal
• [ ] 🥈 Silver
• [ ] 🥇 Gold
• [ ] 🏆 Platinum

To help with the load of incoming pull requests:

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

[Bluhme1]

@mikke89 Looks very interesting. Have you stopped hoping that it will be accepted. A lot of users asked for a way to set cost to individual devices through this months WTH (What The Heck). This integration could solve that problem

[mikke89]

Thanks! I still want to see this through. Not sure if there is anything I can do to get the attention of maintainers.

[frenck]

@Bluhme1 there is a lot of interesting things to be found here, that many other people want too. Please, don't ping for that. Thanks! 🙂

[Bluhme1]

OK. Just wanted to help. The WTH proposal about adding cost to individual entities has got 320 votes. So not a minor thing

Water on Energy Dashboard got 377

[frenck]

Pinging doesn't help with that. Please avoid doing that.

For a more content related response: I think this PR is not the right approach to solve that WTH. None of the cost calculations are done this way, thus imho this doesn't make sense.

That said, this PR will have to await his turn.

[github-actions[bot]]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.