Cost integration

[jvexiau]

Hi,
first of all, thanks for this new module,

I integrated this module into my Docker Compose setup with the required variables, and everything is working well. I just ran into a small issue: I had included port 8123 in my HOMEASSISTANT_HOST configuration, and it was a bit tricky to figure out how to change it. I eventually realized it had to be modified directly in the container’s /app/config/ folder.
So, does this mean that the Docker Compose variables are only used during the initialization phase?

Other than that, everything is working perfectly.

One major improvement would be the ability to automatically integrate energy costs when new data is added. I think the approach taken by the ha-linky project (https://github.com/bokub/ha-linky), which supports a dynamic configuration, would be a great addition.

What do you think?

[ssenart]

Hello,

1. Yes, environment variables are used once at container build time. Later, if you want to change a configuration:

• Either, you rebuild the container after changing the variable value.
• Or, you mount the /config container directory on your host, and you will be able to change the configuration file directly on your host (my preferred way).

It is more flexible to mount the /config directory on your host rather than going inside the container.

2. Regarding cost integration, thanks for the proposal. I will evaluate it. For those having fixed gas price, it will be probably a list of date with the corresponding new price.

But how should we integrate variable prices for those having variable contract ? Is there any gas price feed per provider somewhere ?

[jvexiau]

Hello @ssenart,

Indeed, dynamically retrieving prices seems complicated, especially since prices are no longer regulated. I know there are APIs available, but their costs are prohibitive. There were discussions on this topic here: https://forum.hacf.fr/t/api-cout-du-gaz-et-de-lelectricite/17111.

That's why I thought about the solution of entering prices as part of the configuration, with possible start and end dates, similar to the configuration in HA-Link. It allows those with fixed rates to have a simple setup, and for others, they would need to update the rates whenever they change (but it’s only 2 or 3 times a year, right?).

Thanks anyway! :)

[ssenart]

What is the benefit of specifying 'start date' and 'end date' of a period when all the periods are contiguous and 'end date' of the current period is for sure 'start date' of the next period ?

If I take the example:

- price: 0.21
  end_date: '2024-07-01'
- price: 0.22
  start_date: '2024-07-01'
  end_date: '2024-09-01'
- price: 0.23
  start_date: '2024-09-01'

The following might equivalent and shorter:

- price: 0.21
- price: 0.22
  start_date: '2024-07-01'
- price: 0.23
  start_date: '2024-09-01'

Perhaps I miss somehting ?

[jvexiau]

Hi,

I think you're right, I don't know the exact reason. As long as we read the rules from top to bottom, it doesn't cause any issues. I believe that:

• It's probably for ease of writing the code (but that’s not necessarily a good reason 😉),
• In the specific case of the ha-linky project, there’s the possibility to configure multiple PRMs (which would be equivalent to multiple PCEs in our case), and consequently, reading the configuration file could be more complex.