switch on high prio devices, even if they only use a fraction of the excess power.

Maik7 commented 4 months ago

https://github.com/InventoCasa/ha-advanced-blueprints/issues/63

issue#63

Switch on high prio devices, even if they only use a fraction of the excess power, if prio > 500

InventoCasa commented 4 months ago

@Maik7 thanks for the PR! Will try to review this on the upcoming weekend.

InventoCasa commented 4 months ago

@Maik7 Hmm, I'm not a fan of hardcoding a certain priority level at which the device get's switched on even if not enough excess power is available. This will not be clear to the user. Also, the appropriate change in the blueprint is missing which would explain this behaviour.

My suggestion would be to implement this feature as follows:

ditch the priority level
add two new variable to the blueprint, called e.g.
- "Maximum total grid support" <---- the max. amount of additional power draw from the grid, if the PV power is not enough.
- "Maximum appliance grid support" <---- the max. amount of additional power draw from the grid for this specific appliance.
Implementation-wise, you then have an individual "overdrive" for each appliance which is allowed to be imported from the grid.
When implementing, e.g. dynamic current control must be considered. Also, checks must be implemented, which check for:
- Sum of Maximum appliance grid support must be smaller or eq. to Maximum appliance grid support
- Maximum total grid support must be set to the same value in all blueprint instances / individual automations

Maik7 commented 4 months ago

@InventoCasa Hi, thanks for reviewing.

Hmm, I'm not a fan of hardcoding a certain priority level at which the device get's switched on even if not enough excess power is available. This will not be clear to the user.

yes, it would be better to use a priority level, which is out of the currently allowed range, e.g. >1000. (If priority level is the correct way of implementation at all)

Also, the appropriate change in the blueprint is missing which would explain this behaviour.

yes of course, that is needed. But first I wanted to discuss with you, if such a modification has a chance to be implemented

"Maximum total grid support" <---- the max. amount of additional power draw from the grid, if the PV power is not enough. "Maximum appliance grid support" <---- the max. amount of additional power draw from the grid for this specific appliance.

I need to think about that specific approach, but I fear, that this would cause unwanted behavior. Lets think about to appliances, one appliance A with high priority (400) and one appliance B with low priority (10). A has an Maximum appliance grid support lower than B. E.g. A.maximum_appliance_grid_support=0 and B.maximum_appliance_grid_support=100. A is switched on and B is switched off. The actual solar excess power is 100W and the power consumption of B is 150W. In that case the automation will switch on B causing a solar excess of -50W, which is ok for B, but not for the higher prioritized A. As a next step the automation will switch off A, but due to it's higher prioritization this is most likely not the intention of the user. Therefore the automation need to be much more complex. It this case it has to check (before switching on B) if there is a higher prioritized appliance which will caused to be switched off and do not switch on B. Or if A and B are running (e. g. B was started as much higher solar excess, but solar energy decreased since the start or power consumption of A increased in the meanwhile), and we have the same parameters as in the example above (solar excess = -50W). The automation has to detect, what is the correct appliance to be switched off. You can argue for B, as it has the lower prioritization, but you can also argue for A, as the rules for A are not fulfilled while the rules for B are fulfilled. Whatever the automation decides, there will be users saying "it is a bug". The situation gets more complex with 3 or more appliances, where prioritization and maximum_appliance_grid_support are in "conflict". I assume there is no formal correct solution of this problem, therefore this will cause oscillations. If I oversee it correctly, the only solutions is a direct link between prioritization and maximum_appliance_grid_support. In that case it is much easier, if there are not two individual parameters, but just one. (easier for the programmer and easier for the user.)

And my local version has already the ability to switch off lower prioritized appliances to switch on higher prioritized ones. That is getting much more complex with more parameters.

But this feature makes your great automation much more powerful. I am adjusting the priority on the fly. I have a small balcony power plant without real battery and want to use as much of the solar energy as possible. Your script has to control my e-bike chargers, a fish tank heater, a freezer and a camping battery (760Wh), which unfortunately can not feed back into the 230V net. Freezer and fish tank priority depends on the time, they were reported as idle. E. g. the freezer remains 40 mins idle before the freezer internal regulator wants to switch on, therefore I increase the priority after 50 min and force a switch on after 60 min (independent from the script, I will do some trials with thermal packs to prolong this time (with salt water I can realize a freezing temperature directly above the hysteresis)). If I fill the freezer I can press the button at the tasmota switch and it will be switched on for 1h. After this 1h my automation waits till the tasmota is reporting the freezer to be idle and then your script gets back the control. (to be honest, the freezer is right now replaced by a simulation of the freezer. As long as I code ...) :-) If I connect the e-bike the e-bike gets a low priority. By pressing the button I can tell the automation, when I want the e-bike to be charged. 1x press today, 2x press tomorrow, 3x ... The priority is then calculated depending on the remaining time and the solar forecast (and in the end it is forced to on).

Altogether a rather complex automation and your script is doing a perfect job. Therefore a big Thank You for sharing your work with the community!

Maik7 commented 4 months ago

I changed it to perform the same as the actual implementation for prio <= 1000 and for 1000 < prio <= 2000 an appliance will be switched on, even if they use more than 100% of the excess power. I added documentation to the blueprint yaml. @InventoCasa I think, this can be the final version of this pr.

liouma commented 4 months ago

@InventoCasa and @Maik7 : Thank you so much for your work on this feature. That will be a game changer for me and I guess most of the people who consume more than they produce without a good electricity selling price :)

InventoCasa commented 3 months ago

Alright, merging this now.

Although this is not a perfect solution, it is definitely adding some more nice possibilities to the script. Maybe we can still think about implementing appliance / total grid support at a later time / in another PR, even if it will be complex and we have to decide which logic it should follow.

Thanks again for the PR!

Maik7 commented 3 months ago

Maybe we can still think about implementing appliance / total grid support at a later time / in another PR, even if it will be complex and we have to decide which logic it should follow. @InventoCasa Maybe limiting the overall grid support will do that job? Currently I do not see a functional logic, which uses different values for the different appliances

InventoCasa / ha-advanced-blueprints

switch on high prio devices, even if they only use a fraction of the excess power. #64