Ability to reverse logic of this integration

[KrzysztofHajdamowicz]

Is your feature request related to a problem? Please describe.
I want to use two instances of this integration to perform two tasks:

1. Find X cheapest hours to charge battery pack
2. Find X most expensive hours to discharge battery pack

Describe the solution you'd like

Add a binary switch or select entity to determine expected result from algorithm

Describe alternatives you've considered
It's already available in Jinja2 macro: https://github.com/TheFes/cheapest-energy-hours/

Additional context
Actually, I will run 3 instances of this integration:
To control (dis)charge of household battery pack and to charge EV.

[jonasbkarlsson]

Thanks for the suggestion. I have actually been thinking a bit about this.

For testing I have 3 instances of this integration. The instance that is used for discharging of the household battery pack uses template helpers that inverted the SOC entities {{ 100.0 - states('entity.providing_soc') | float(0) }} and then I use an instance of the Nordpool integration which is configured to invert the price {{ (current_price * -1.0 ) | float }}. This works fine, but is of course quite ugly. A switch would be a proper implementation.

However, I felt that this would be too simple. To make sense, I thought you need to add knowledge of the high and low price levels. If the purpose of this is to do price arbitrage, then it only make sense of the high price is a certain amount above the low price. This felt a bit complicated to implemented, so I didn't do anything more...

What is your comments on this? Is just a switch enough?

[KrzysztofHajdamowicz]

Let's start with a switch, if someone wants to further expand logic, another layer of template sensors can be used.

I don't know if switch is sufficient in terms of UX design. Maybe with custom translations you can translate off/on to discharge/charge, but select seems more natural for most users.

select.Mode:
 - charge
 - discharge