check_usable_template Not working as expected
Closed this issue · 5 comments
Version of the custom_component
1.5.0
Configuration
algorithm:
initial_temp: 1000
min_temp: 0.1
cooling_factor: 0.95
max_iteration_number: 1000
devices:
- name: Tesla Model Y Charging
check_usable_template: "{{states('device_tracker.location_tracker') == 'home' and is_state('binary_sensor.charger', 'on') and states('sensor.battery_2') | float(100) < states('number.charge_limit') | float(90) }}"
entity_id: switch.charger
power_entity_id: "number.charging_amps"
power_min: 220
power_max: 2860
power_step: 220
duration_min: 15
duration_stop_min: 15
action_mode: service_call
activation_service: "switch/turn_on"
deactivation_service: "switch/turn_off"
change_power_service: "number/set_value"
convert_power_divide_factor: 220
Describe the bug
I use the solar optimizer to control the charging power of my Tesla depending on the overproduction of my solar panels. This works great when I'm at home, however I noticed that the component will also disable charging when I'm not at home and charging at another place.
I expted the check_usable_template
parameter to prevent this from happening, but maybe I understand it wrong? As you can see there's a states('device_tracker.location_tracker') == 'home'
condition inside the template, which is false when the Tesla is not at home, but still the component turns off charging.
In the logs below, you can see it logged 'is_usable': False
, so it seems to understand that the tesla is not usable at that time. I did notice that the Calling service switch/turn_off for entity switch.charger
log comes before that log, so maybe the component is evaluating the condition too late?
Debug log
Sadly I don't have debug logs, but maybe the info logs can help to begin with?
2024-03-22 22:53:26.943 INFO (MainThread) [custom_components.solar_optimizer.coordinator] Refreshing Solar Optimizer calculation
2024-03-22 22:53:26.952 INFO (MainThread) [custom_components.solar_optimizer.managed_device] Calling service switch/turn_off for entity switch.charger
2024-03-22 22:53:26.953 INFO (MainThread) [custom_components.solar_optimizer.managed_device] Sending event solar_optimizer_state_change_event with action Deactivate for entity switch.charger with requested_power 0 and current_power 3520
2024-03-22 22:53:26.955 INFO (MainThread) [custom_components.solar_optimizer.coordinator] Calculated data are: {'power_production': 783, 'power_production_brut': 792.0, 'power_consumption': 792.0, 'sell_cost': 0.0641, 'buy_cost': 0.210171, 'sell_tax_percent': 0.0, 'best_solution': [{'power_max': 2600, 'power_min': 220, 'power_step': 220, 'current_power': 3520, 'requested_power': 3520, 'name': 'Tesla Model Y Charging', 'state': False, 'is_usable': False, 'is_waiting': False, 'can_change_power': True}], 'best_objective': 606.9013202270747, 'total_power': 0, 'tesla_model_y_charging': <custom_components.solar_optimizer.managed_device.ManagedDevice object at 0x7f822354ddf0>}
2024-03-22 22:53:27.286 INFO (MainThread) [custom_components.solar_optimizer.switch] Appel de on_state_change à 2024-03-22 22:53:27.286156 avec l'event <Event state_changed[L]: entity_id=switch.charger, old_state=<state switch.charger=on; attribution=Data provided by Tesla, icon=mdi:ev-station, friendly_name=Tesla Model Y Charger @ 2024-03-22T22:48:39.037859+01:00>, new_state=<state switch.charger=off; attribution=Data provided by Tesla, icon=mdi:ev-station, friendly_name=Tesla Model Y Charger @ 2024-03-22T22:53:27.285562+01:00>>
Hello @vyruz1986 ,
This should work as expected. Have you evaluate the check_usable_template in the Development Tools / Templates to see if there is syntax error or something like that ? Is your device_tracker.location_tracker
working as expected ?
More over, it is better (because simplier) to use is_state
syntax rather that states
== 'home'.
Because it is working for all users I suspect more an issue in your environment than a bug.
I was faced with a similar issue so I digged a little deeper, and I think there's something that needs to de clarified at least for me.
Context : Instead of defining all conditions in check_usable_template, I've defined a template binary sensor with the relevant conditions.
Here's the code for this sensor :
template:
- binary_sensor:
- name: chonk_check_usable_template
state: >
{{
is_state('sun.sun', 'above_horizon') and
is_state('input_select.chonk_charge_plan', 'Solaire') and
not is_state('sensor.rte_tempo_couleur_actuelle', 'Rouge') and
is_state('device_tracker.chonk_location_tracker', 'home') and
is_state('binary_sensor.chonk_charger', 'on') and
(states('sensor.chonk_battery') | float(100) < states('number.chonk_charge_limit') | float(90))
}}
And in solar optimizer yaml :
check_usable_template: "{{ is_state('binary_sensor.chonk_check_usable_template','on') }}"
Now, the weird thing is, when I look at the sensors/switch history, here's what happens :
- first line : tesla charger entity. On = car is charging
- second line : solar optimizer switch
switch.solar_optimizer_<name>
- third line : solar optimizer switch
switch.enable_solar_optimizer_<name>
- fourth line : template binary sensor for check usable template.
Now, I'd expect switch.solar_optimizer_<name>
not to be turned on when switch.enable_solar_optimizer_<name>
and check_usable_template are both either off or false. However, everynight, when the car starts charging it does turn on switch.solar_optimizer_<name>
and, if I had not setup an automation, it'd turn off charging as it does for @vyruz1986.
Edit, I just checked on my other car, which is currently charging : attribute is usable is false even if the binary sensor for this one is true (and it is currently charging).
and as a sanity check, this car does indeed make use of the template binary sensor for the check_usable_condition :
devices:
- name: "titine"
entity_id: "switch.titine_charger"
[....]
check_usable_template: "{{ is_state('binary_sensor.titine_check_usable_template','on') }}"
Hello @MrBLJ ,
Now, I'd expect switch.solar_optimizer_ not to be turned on when switch.enable_solar_optimizer_ and check_usable_template are both either off or false
switch.solar_optimizer_ is on when the underlying is switch is on. Else how will know that it is activated ?
and, if I had not setup an automation, it'd turn off charging as it does for @vyruz1986.
If usable is false or enabled is false, Solar Optimizer will not try to turn on or off. Those flags are there exactly for that purpose.
I don't see where is the problem with that way of working (once you know it)
Thanks for the explanation, it's clearer now. I guess I must have left the enable switch turned on at night.
I'll try removing the automation now that I know my binary template sensor works as intended, and we'll see if the charging is turned off when the switch triggers.
I close this issue. Reopen if you think i'm wrong.