Problem with debugging automation

johny_mnemonic · May 9, 2024, 11:10am

Thanks for opening this topic!
I am really struggling with automation debugging as the “Step details” is complete mess for more complex automations from my point of view.

Maybe I do not understand how it works, but here is an example of trace I just got and I am unable to find why the automation did what it did as the trace is total mess for me:

Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
conditions/0
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
conditions/0/conditions/0
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: false
conditions/0/conditions/0/entity_id/0
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: false
state: Fast
wanted_state: Stop
conditions/1
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
conditions/1/conditions/0
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
conditions/1/conditions/0/conditions/0
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
conditions/1/conditions/0/conditions/0/entity_id/0
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
state: 8665
conditions/1/conditions/0/conditions/1
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
conditions/1/conditions/0/conditions/1/conditions/0
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
conditions/1/conditions/0/conditions/1/conditions/0/conditions/0
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
conditions/1/conditions/0/conditions/1/conditions/0/conditions/0/entity_id/0
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
state: 73
conditions/1/conditions/0/conditions/1/conditions/0/conditions/1
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
conditions/1/conditions/0/conditions/1/conditions/0/conditions/1/conditions/0
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
conditions/1/conditions/0/conditions/1/conditions/0/conditions/1/conditions/0/entity_id/0
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
state: 3871
conditions/1/conditions/0/conditions/1/conditions/0/conditions/1/conditions/1
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
conditions/1/conditions/0/conditions/1/conditions/0/conditions/1/conditions/1/entity_id/0
Executed: May 9, 2024 at 12:15:00 PM
Result:
result: true
state: 4033

Here is the condition part of the automation:

conditions:
  - alias: Charger Use Mode is not Stop
    condition: not
    conditions:
      - condition: state
        entity_id: sensor.solax_evc_charger_use_mode
        state: Stop
  - condition: or
    conditions:
      - alias: PV charging + low PV power
        condition: and
        conditions:
          - condition: numeric_state
            entity_id: sensor.solax_inverter_power
            above: 1500
            alias: PV charging
          - alias: Home not charged or PV low
            condition: or
            conditions:
              - alias: Home not charged and not enough PV for EV and Home
                condition: and
                conditions:
                  - condition: numeric_state
                    entity_id: sensor.solax_battery_capacity
                    below: 95
                  - condition: and
                    conditions:
                      - condition: numeric_state
                        entity_id: sensor.solax_pv_power_total
                        below: input_number.kona_ev_charging_min_pv
                      - condition: numeric_state
                        entity_id: sensor.pv_power_smooth
                        below: input_number.kona_ev_charging_min_pv
                    alias: Not enough PV
              - alias: Home charged but PV low
                condition: and
                conditions:
                  - condition: numeric_state
                    entity_id: sensor.solax_battery_capacity
                    above: 95
                  - alias: Low PV
                    condition: and
                    conditions:
                      - condition: numeric_state
                        entity_id: input_number.kona_ev_charging_min_pv
                        value_template: >-
                          {{ states('input_number.kona_ev_charging_min_pv') |
                          float * 0.81 }}
                        above: sensor.pv_power_smooth
                        alias: PV smooth too low
                      - condition: numeric_state
                        entity_id: input_number.kona_ev_charging_min_pv
                        value_template: >-
                          {{ states('input_number.kona_ev_charging_min_pv') |
                          float * 0.81 }}
                        above: sensor.solax_pv_power_total
                        alias: PV too low
      - alias: Grid charging + min batt or high tariff
        condition: and
        conditions:
          - condition: numeric_state
            entity_id: sensor.solax_grid_import
            above: 2500
          - condition: or
            conditions:
              - alias: Battery above minimal level (helper)
                condition: numeric_state
                entity_id: sensor.kona_ev_battery_level
                above: input_number.kona_battery_minimal_charge
              - condition: state
                entity_id: binary_sensor.signal_hdo_tuv_pv
                state: 'off'
      - condition: numeric_state
        entity_id: sensor.solax_battery_capacity
        enabled: true
        below: 55

Finding which part of the trace corresponds to which part of the automation code is a real nightmare for me. If anyone has an advice how to untangle this I am all ears

So many steps just contain “result: true” without giving any clue to which condition it relates, that it is really hard finding what happened. The only way I am able to sometimes decipher this is thanks to those steps containing returned number. As then I can check the history of all the used variables/sensors and try to guess which one it is based to what value it had at the time of the automation run. It would be much better if the step contained at least the name of the entity if not the condition it is evaluating.

Troon · May 9, 2024, 12:02pm

That’s what the path represents. For example, this, remembering counting starts from 0:

conditions/1/conditions/0/conditions/1/conditions/0/conditions/0

Second condition (the or:)
First under that (the and:)
Second under that (the or:)
First under that: (the and:)
First under that (battery capacity below 95)

If this seems too complicated, it’s because you have a very deep set of conditions.

parautenbach · May 9, 2024, 12:18pm

It’s definitely great that are trying to understand how this works. Well done for making an effort.

That said, you can tell us what the problematic symptom is too. Perhaps we can help.

Two things can be done to reduce the complexity (good job for giving aliases to your conditions), at some additional cost: If I have a lot of logic, I tend to use template conditions, since it’s denser and thus easier to read. The other option is to group pieces and make binary sensors for it. Having logical names would make reading the automation and conditions easier. The nice thing about the latter is that you can chart the history of such sensors which can also aid in debugging.

johny_mnemonic · May 9, 2024, 3:23pm

I posted this here mainly as an example how useless the current debugging of automations is when you have complex set of conditions.

Why you need to spend so much time deciphering which condition pairs to which result as @Troon describes? It’s so tedious and time consuming. I really hate it with passion
In case each step also contained the condition, not just it’s result, it would be super useful! Or at least the alias or entity name, something, but giving you nothing apart from occasional compared value is gravely not enough.

The reason why I added those aliases was not just a better readability, but I hoped these aliases will be visible in the trace, which they sadly aren’t

Template conditions are fine for making less lines in the trace, but with the template you are completely blind how it evaluated or what went wrong. With normal conditions you at least have a clue what was the value it tried to compare to for example, which you looses with template condition as there you only get true/false for the whole logic inside the template.
So I am using template conditions only when I am unable to do the same by normal conditions.

What you describe with the binary sensor sounds promising. Thanks for the hint!
You are talking about template sensors right? So instead of having the condition in automation you have it as a template sensor and then just compare it in the automation.
Do I get it correctly?

I have few of such sensors for complex number logic but using it for binary conditions could be nifty as well