next_date_available stuck in the past

[MrBLJ]

Version of the custom_component

v1.5.0

Configuration

---
# ------------------------------------------------------------------------------
# File: solar_optimizer.yaml
# Desc: Solar optimizer related entities and config. Check github : 
# https://github.com/jmcollin78/solar_optimizer
#
# Content:
# 1. Algorithm.
# 2. Devices.
# ------------------------------------------------------------------------------

# 1. Algorithm.

algorithm:
   initial_temp: 1000
   min_temp: 0.1
   cooling_factor: 0.95
   max_iteration_number: 1000

# 2. Devices.
devices:
  - name: "titine"
    entity_id: "switch.titine_charger"
    # La puissance minimale de charge est 220 W (soit 1 Amp car convert_power_divide_factor=220 aussi)
    power_min: 220
    # La puissance maximale de charge est 2200 W (soit 10 Amp (= 2200/220) )
    power_max: 2200
    # le step de 660 soit 1 Amp après division par convert_power_divide_factor
    power_step: 220
    # Utilisable si le mode de charge est "Solaire" et la voiture est branchée sur le chargeur et elle est chargée à moins de 90 % (donc ca s'arrête tout seul à 90% )
    check_usable_template: "{{ is_state('sun.sun', 'above_horizon') and is_state('input_select.titine_charge_plan', 'Solaire') and is_state('device_tracker.titine_location_tracker', 'home') and is_state('binary_sensor.titine_charger', 'on') and states('sensor.titine_battery') | float(100) < states('number.titine_charge_limit') | float(90) }}"
    # 1 h de charge minimum
    duration_min: 60
    # 15 min de stop charge minimum
    duration_stop_min: 15
    # L'entité qui pilote l'ampérage de charge
    power_entity_id: "number.titine_charging_amps"
    # 5 min minimum entre 2 changements de puissance
    duration_power_min: 5
    # l'activation se fait par un appel de service
    action_mode: "service_call"
    activation_service: "switch/turn_on"
    deactivation_service: "switch/turn_off"
    # le changement de puissance se fait par un appel de service
    change_power_service: "number/set_value"
    # le facteur permettant de convertir la puissance consigne en Ampères (number.tesla_charging_amps prend des Ampères)
    convert_power_divide_factor: 220
  - name: "chonk"
    entity_id: "switch.chonk_charger"
    # La puissance minimale de charge est 220 W (soit 1 Amp car convert_power_divide_factor=220 aussi)
    power_min: 220
    # La puissance maximale de charge est 2200 W (soit 10 Amp (= 2200/220) )
    power_max: 2200
    # le step de 660 soit 1 Amp après division par convert_power_divide_factor
    power_step: 220
    # Utilisable si le mode de charge est "Solaire" et la voiture est branchée sur le chargeur et elle est chargée à moins de 90 % (donc ca s'arrête tout seul à 90% )
    check_usable_template: "{{ is_state('sun.sun', 'above_horizon') and is_state('input_select.chonk_charge_plan', 'Solaire') 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) }}"
    # 1 h de charge minimum
    duration_min: 60
    # 15 min de stop charge minimum
    duration_stop_min: 15
    # L'entité qui pilote l'ampérage de charge
    power_entity_id: "number.chonk_charging_amps"
    # 5 min minimum entre 2 changements de puissance
    duration_power_min: 5
    # l'activation se fait par un appel de service
    action_mode: "service_call"
    activation_service: "switch/turn_on"
    deactivation_service: "switch/turn_off"
    # le changement de puissance se fait par un appel de service
    change_power_service: "number/set_value"
    # le facteur permettant de convertir la puissance consigne en Ampères (number.tesla_charging_amps prend des Ampères)
    convert_power_divide_factor: 220

Describe the bug

_next_dateavailable is sometimes stuck in the past , which gives negative values to the sensor. In that case, the optimization won't trigger and the addon appears to be frozen.

Rebooting HA fixes the issue.

No error appears in the logs.

[jmcollin78]

Hello @MrBLJ,

Where did you see that next_date_available in the past ?

If it is in the switch state like this:

this is normal. This doesn't mean that it is stuck but only that it is not usable or enable ...:

is_enabled: false
is_active: false
is_waiting: false
is_usable: false

[MrBLJ]

Hello @jmcollin78,

Thanks for your reply :). As an example, here's a screenshot I took a few days ago :

In this one, _next_date_availablepower is in the past (time on my phone and HA are synced, I tripled checked that). In this case, what I have to do is reboot HA and _next_date_availablepower will usually be t+5mins (time between power changes).

Note : this one is controlling the charge of my car, and there are lots of current issues with the Tesla integration. Maybe it could be linked to that I'm not sure.

[jmcollin78]

Why do you think it is not normal ? Between two power change there is delay (to avoid changing charging Amps too fast in case of a Tesla). If the newt_date_available_power is in the past, itjust mean that the Amps can be change when possible. Which is certainly normal if the last power change occurs x min before now (x is the configurable parameter duration_power_min

[MrBLJ]

My understanding was incorrect I apologize. _next_date_availablepower appeared to me as the next time at which there would be a power check (difference or ratio between production and consumption).

I guess my issue is related to something else : the charging amps of my vehicle are sometimes frozen (without any mention of an issue in the logs) and the optimizer is not adjusting the power.

[MrBLJ]

Bad understanding on my end of what _next_date_availablepower is. My issue is related to something else.

[jmcollin78]

No problem.