Add compensation and compensation_entity

[rrozema]

Is your feature request related to a problem? Please describe. Next to costs, the energy dashboard also keeps track of compensations. I would a.o. like to keep track of the compensation I would have received for the energy my solar panels generated, not just the part that was returned into the grid.

Describe the solution you'd like Current implementation creates cost sensors only. I would also like to be able to create compensation sensors, similar to those for energy produced for solar panels. An easy way to do this could be to add two more configuration options compensation: and compensation_entity: which would create a _compensation sensor for the defined utility meter's value.

Describe alternatives you've considered An alternative could be to add one extra configuration option f.e. is_compensation, which can be set to true or false, and steers whether a cost of compensation gets created of the price or price_entity configuration. However this setup would prevent having both a cost and a compensation at the same time of the same utility meter.

Additional context I do not have an idea on how to handle a utility meter that has net_consumption: set to true. I don't think we would be able to properly separate a cost-component and compensation-component for such utility meters from the net change in the value, hence we would not be able to determine proper price and compensation values for those components. f.e. If in one time frame +1kWh was consumed and within the same time frame 1kWh was also produced, the net result could be 0kWh, but if the price and compensation values are not the same there could still be a net change in the total costs or total compensations. We would however be unable to detect this by looking at the net result of the utility meter only. Maybe we could just say that this net_consumption: true configuration is not supported?

[Roving-Ronin]

@rrozema Are you trying to simply create an entity that tracks the amount of money that you should receive from exporting your surplus solar ?

If so suggest you look at the configuration that I have posted in: https://github.com/zeronounours/HA-custom-component-energy-meter/issues/37

apart from all the other cost entities, that will also create an 'Exported Daily/Monthly/Yearly Cost' entity, see:

Note: HS in the name just refers to Huawei Solar (pulling data using https://github.com/wlcrs/huawei_solar ) versus I also compare with data from IoTaWatt and Solar Analytics also pulling data into HA.

HS Power - Exported Daily (kWh)

HS Power Exported Daily Cost (if you don't want to keep the word 'cost' then edit it in the GUI to Income/Profit etc).

Monthly and Yearly correspondingly show total kWh exported and the $$$ I should receive for those time periods / kWh.

[rrozema]

I do already have setup without your solution keeping track of my actual surplus self-produced energy plus the compensation received for that. I do however use your solution to keep track of all consumed self-produced energy (= solar + theoretically battery out) plus the price this represented at the time of usage. i.e. these are my savings from not having to use and buy grid energy. Then I also keep track of my total consumed energy plus the price this represented at the time of consumption (= what I would have paid had I done no investments in self producing energy). Together with some more these statistics will help me determine if and when I break even on my solar system investments. Another I keep track of is total self-produced energy plus the compensation I would have received had I returned it all into the grid without using any of it. I aim to use this in doing what-if calculations for adding a battery.

By using proper logic and clever templates a lot of things can be setup already. My suggestion is to make setting up such calculations easier for most. Where in your current solution costs are the result of adding to some meter, in my suggestion compensations are the result of lowering some meter: the compensation increases while the metering reduces. I think this will be a more natural match to the way people see their grid provider's billing. Plus it matches what many grid provider's meters do: they add up energy consumed from the grid and subtract what you've returned into the grid. Most times however consumed and returned grid energy are billed at different rates. By introducing compensation and compensation_entity we can define the returned energy rate where the price and price_entity define the rate for consumed energy and both CAN be defined of one and the same meter.

Op vr 17 nov. 2023 04:24 schreef Roving Ronin @.***>:

@rrozema https://github.com/rrozema Are you trying to simply create an entity that tracks the amount of money that you should receive from exporting your surplus solar ?

If so suggest you look at the configuration that I have posted in: #37 https://github.com/zeronounours/HA-custom-component-energy-meter/issues/37

apart from all the other cost entities, that will also create an 'Exported Daily/Monthly/Yearly Cost' entity, see:

[image: image] https://user-images.githubusercontent.com/108674933/283661897-c34f02ff-8780-4f92-8735-033356b74a68.png

Note: HS in the name just refers to Huawei Solar (pulling data using https://github.com/wlcrs/huawei_solar ) versus I also compare with data from IoTaWatt and Solar Analytics also pulling data into HA.

HS Power - Exported Daily (kWh) [image: image] https://user-images.githubusercontent.com/108674933/283661996-3ed1b126-48ef-45ed-849d-89fa2eb66fe2.png

HS Power Exported Daily Cost (if you don't want to keep the word 'cost' then edit it in the GUI to Income/Profit etc). [image: image] https://user-images.githubusercontent.com/108674933/283662128-aa3f330c-d88c-4fb7-a236-695dec957d1c.png

Monthly and Yearly correspondingly show total kWh exported and the $$$ I should receive for those time periods / kWh.

— Reply to this email directly, view it on GitHub https://github.com/zeronounours/HA-custom-component-energy-meter/issues/53#issuecomment-1815689494, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANKYDUY4OUCULUHDPGTUY3YE3KGHAVCNFSM6AAAAAA7MQJWPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJVGY4DSNBZGQ . You are receiving this because you were mentioned.Message ID: @.*** .com>

[rrozema]

As an extra note: I don't need any daily, weekly, monthly etc. utility meter values. Instead of those I use the Long Term Statistics (LTS) values as also used by the Energy Dashboard. Doing so I can select the values over any period I want at any time by doing a few clicks in the period selection above the overview. For example, for any single day I can see the usage, costs & savings: Or I can show the cumulated data over multiple days/weeks/months or even years. I only created these entities on the day before yesterday, so I currently only have data for the 16th, 17th and 18th of november (up to one +- 1 hour ago) so far. But as you can see I can already show my savings, etc. over these 3 days. It is sadly very hard to add data for past periods into those LTS, so I won't be able to show my systems entire life span anymore. But at least I can see how it evolves from now. Thank you very much already for what you've achieved so far!

[Roving-Ronin]

@rrozema care to publish your templates etc, to see how your doing it?

[rrozema]

Of course i want to share what I've got after you've made it all possible with these components :-)

I put a quick sum-up together in this word document. I hope I've got it all in there: solar roi.docx

I am planning on writing an article on it, but I know by now that I'm terrible at finishing such things, so if you want to do one to show of the key points of your work, you can take my code and use it as you see fit...

[Roving-Ronin]

@rrozema just wondering how are you billed for your electricity in (?). ? ie in Australia I'm on a Time of Use plan (TOU) with a peak, shoulder, off peak rate.

Peak is 7-9am and 5-8pm Monday to Friday

Shoulder is 9am - 5pm and 8-10pm Monday to Friday

Off Peak is 10pm 7am Monday to Friday and all Saturday and Sunday.

There's also a daily fee, but I'm not tracking that atm myself.

Is your billing like that or something else ?

Asking as your way of doing the electricity cost is very long and complex.

[rrozema]

In the Netherlands we're most often billed in 2 different tariffs, low and high. High tariff being for energy used during weekdays 07:00-19:00 and low tariff for the other hours plus weekend days. Because many different tariff plans are implemented by the various providers is exactly why I did it this way: I created one entity that has the "current price for energy consumed" and another one for the "current price for energy produced". All logic using either "energy price" should always only reference either of those two entities. Doing it this way none of the logic needs to be changed when your tariff plan differs from mine or if mine changes. All you need to do is change how to determine the state for those 2 entities and all the rest will remain the same.

i.e. you'd have to adjust the template for the "electricity_meter_energy_consumption_price" and the "electricity_meter_energy_production_compensation" sensors to one that gives you the current price according your provider's plan and the rest should be fine.

Also, my logic already provides for battery support too. Currently the energy_discharged and energy_charged entities have a state template that always returns 0. So the effect will be nihil, but when I add a battery, all I have to do is adjust the templates for those two entities and the effects of the battery will be included in the resulting figures.

Note: As I indicated in the word document already I saw that I made an error in the electricty_self_produced energy_meter, the source references my enphase integration directly, the source for this energy_meter should have been sensor.energy_produced. However I remember now that that entity didn't want to give any result while I was building this. Now that I'm a day further it does return a proper value and I can change it to source: sensor.energy_produced as it was intended.

[rrozema]

B.t.w. I've got one more suggestion to complete the LTS-toolbox (Long Term Statistics) you're creating here. If you could create an additional stats() function, that can be called from f.e. a jinja template similar to the states() function that would enable us to create calculations on statistics values too, and use them in for example templates for secondary_info: sections. This stats() function would exactly mimic the functionality of the states() function, including all of it's parameter options, but it would have the additional requirement of having an energy-period-selector on the page to determine the period to work on.

[zeronounours]

I've added support for compensation tracking through #56. It won't be possible to add a compensation_entity or something similar to it. Indeed, the integration relies on the builtin energy cost sensor which only support tracking one source.

The stats performed in the dashboard are done on the front-end: it is just difference / sum between other costs that may be tracked. In a nutshell:

home_energy = from_grid_energy + solar_energy + battery_out_energy - to_grid_energy - battery_in_energy

You may use this integration to estimate your savings by tracking solar_energy for instance.

[zeronounours]

Regarding your proposal to add a stats() function in jinja template, it is not up to this integration to provide it. Templates are managed within Home assistant core. You'd rather create a feature request their. But you're not the only one wanting it: https://community.home-assistant.io/t/long-term-statistics-in-automations-or-templates/388060

For now, the only possibility to work with LTS is:

• To create a dedicated custom_component (maybe someone already did)
• To create a lovelace component for the frontend