jmcollin78 / solar_optimizer

The Solar Optimizer integration for Home Assistant starts and stops your equipments depending on the Solar net production
MIT License
53 stars 10 forks source link

check_usable_template Not working as expected #29

Open vyruz1986 opened 3 months ago

vyruz1986 commented 3 months ago

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>>
jmcollin78 commented 3 months ago

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.

MrBLJ commented 3 months ago

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_usabletemplate, 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 : image

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).

image

image

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') }}"
jmcollin78 commented 3 months ago

Hello @MrBLJ ,

Now, I'd expect switch.solaroptimizer not to be turned on when switch.enable_solaroptimizer and check_usable_template are both either off or false

switch.solaroptimizer 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)

MrBLJ commented 3 months ago

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.