Prioritization is exactly the opposite of description
LotharWoman opened this issue · 5 comments
Hello,
could it be that there was an error in the following description/translation?
"Appliance priority:
Appliances with a higher number are prioritized compared to appliances with a lower number."
My 3 automations behave exactly the opposite. First, my two automations with the lower number and BatterySoc 100% at end of the day are switched to. Only then does the automation follow with the higher number and BatterySoc 40%.
So the behavior looks like this:
"Appliance priority:
Appliances with a lower number are prioritized compared to appliances with a higher number.
First of all, you cannot have different SoC settings between the appliances. Percentage and sensor must be identical in all automations created with this blueprint.
I looked at the code and checked the behaviour with my two appliances. I think the prioritization is correctly implemented.
The problem might be coming from another root cause: The current implementation does not "deal" a higher prio appliance agains a already running lower prio appliance. This leads to the fact that appliances with higher consumption and prio effectivly get punished against lower consumptio & lower prio appliances. Couly that
Example (my case) with two appliances:
- I got a car charger which at the lowest setting can support 4.2kW and go up to 11kW. This automation has the higher prio.
- I got a heater with 1kW, which has the lower prio.
The day starts and of course appliance 2 gets turned on first as the solar power produced start to grow. Then production reaches a level , where appliance 1 (car) could be turned on. But it does not get turned on, because appliance 2 (heater) is already running.
Then production grows more and both appliances get turned on. The automation increases the current for the car charger (1) but never turns of the heater (2).
Only of some clouds occur, which temporarily reduce the available power, the prioritization shuts off the heater (2) and leaves the car (1) on.
So in short: The code needs enhancements to switch off lower prio appliances, if the current production allows turning on or increasing a higher prio appliance.
@stefan73 regarding your idea to add the ability to switch off lower prio devices:
I would like to add a new parameter that controls whether the automation should switch off lower prio devices to maintain backwards compatibility. The default is false.
In the "determining which devices can be switched on" loop: in the case of a device being "off" and unable to be switched on due to the current criteria, I would calculate the power of the running lower prio devices that could be switched off. If this power would allow us to switch on the devices, there are two ways to proceed:
- Just turn them on and the lower prio devices will be turned off a little later.
- store the defined_power of the device to be switched on and use this power in the loop to determine the devices to be switched off.
Not sure which is the better approach. The 2nd seems to be better, as it does not cause a need for external power. However, if the newly switched on device slowly increases it's power consumption, this could result in a low power device being switched on for a short period of time.
In any case only one device should be switched on during one loop to keep the calculations simple.
@InventoCasa what do you think? Should I try to code this feature?
@Maik7 I think I've mentioned this issue somewhere before, it would be a very welcome improvement for me! In my case my water heater is the highest priority device and currently the only one that actually matters most of the year, but on cloudy days or early spring/late fall it will rarely be turned on despite there being enough power for several hours because low priority devices use up the available power.