Does anyone else find that automation traces sometimes don’t work, giving a “Chosen trace is no longer available” error message?
Also, how do you enable Script debugging in YAML mode? I can’t find anything in the Scripts Documentation page about it, and I’ve tried adding “id:” to a script without much luck.
I have an automation that is configured with an “id” to enable traces to be recorded. More often than not, when I click on “Show trace” in the Logbook, it tells me that the trace is no longer available. Yet that same automation has previously shown me a trace without issues, and will again sometimes work afterwards.
It’s not just one automation either, it happens with others with no particular pattern as to which one will fail to collect a trace.
Is there any debugging I can enable to find out why the traces sometimes don’t work?
Just in case it helps, one of the automations looks like this:
ah, that’s interesting. Should the logbook have a clickable “show trace” link next to each script entry? As seen in the screenshot below, I don’t see any trace option. (I’m running 2021.11.2)
Also, another example where the trace results in a “Chosen trace is no longer available” error message when I try to look at the " Aqara Opple kitchen Room" automation.
Hi @petro, thanks for your help. Keeping only 5 traces would make sense - would this count include subsequent script traces, or is it 5 automations and 5 script traces that are kept?
Do you know if there’s an automation size limit for traces? The example below has many conditions which doesn’t seem to work with a trace.
I also noticed that I can see script traces via Configuration → Scripts → ‘Debug script’ icon next to a script, but the “show trace” link never shows up in the logbook next to a script entry. Does this happen for you too?
I’ve had this automation for over a year now so the code/method is probably out of date.
5 traces per entity. I.e. 5 traces for each automation, 5 traces for each script.
I limit my logbook, but this is probably coming. Traces in scripts is rather new.
That automation is fine, it’s a little verbose but it should have no problem in traces.
This automation is alittle different than yours but it’s easier to debug in the trace window. If you put all your templates into a variable section, you can see what’s failing. You can even use variables as a ‘configuration’ for your automation by just using yaml. In this, I made a config for your actions so that you can easily add or remove an action. Then all you need to do is add or remove the paired script. No jinja modification required.
- alias: "Aqara Opple kitchen Room"
id: aqara_opple_kitchen_room
initial_state: 'on'
trigger:
- platform: mqtt
topic: 'zigbee2mqttcc1352/switch_opple_kitchen'
variables:
config:
button_1:
- single
- hold
button_2:
- single
- hold
button_3:
- single
- double
- triple
button_4:
- single
- double
- triple
- hold
button_5:
- single
- double
- triple
- hold
button_6:
- single
- double
- triple
- hold
event: >
{{ trigger.payload_json.action | default('button_0_invalid') }}
items: >
{{ event.split('_') }}
button:
{{ items[-2] }}
action: >
{{ items[-1] }}
continue: >
{{ config.get('button_' ~ button, {}).get(action) is not none }}
service: >
script.opple_kitchen_{{ button }}_{{ config['button_' ~ button][action] if continue else '' }}
condition:
- condition: template
value_template: "{{ continue }}"
action:
- service: "{{ service }}"
That’s an awesome automation, thank you for giving a great example! I never thought variables could be used that way, let alone figure out how to implement it as well as what you’ve done.
Most of my light switches use the Aqara Opple devices so this will drastically reduce my code - thanks!
Ah, I didn’t realise it was 5 per entity, I thought it was 5 traces across all entities - that’s really good to know, thank you!
I’ve been looking into this a bit more and discovered that the “show trace” link in the logbook is at fault here:
What’s more interesting is that the “show trace” link actually points to the “opple_kitchen_1_single” script name, but the URL path is an automation trace. This would explain why I see the “Chosen trace is no longer available” error message.
The Logbook “show trace” link looks like this: http://<my IP>:8123/config/automation/trace/opple_kitchen_1_single?run_id=2a05b1489387bbf10fac174edea2eceb
this:
entity_id: automation.aqara_opple_kitchen_room
state: 'on'
attributes:
last_triggered: '2021-12-02T11:48:58.081092+00:00'
mode: single
current: 0
id: aqara_opple_kitchen_room
friendly_name: Aqara Opple kitchen Room
last_changed: '2021-12-02T12:25:46.660537+00:00'
last_updated: '2021-12-02T12:25:46.660537+00:00'
context:
id: 3c446d7eba6b469aba2c5ded278eff7c
parent_id: null
user_id: null
trigger:
id: '0'
idx: '0'
platform: mqtt
topic: zigbee2mqttcc1352/switch_opple_kitchen
payload: >-
{"action":"","battery":100,"last_seen":"2021-12-02T12:38:05.818Z","linkquality":39,"operation_mode":null,"voltage":3049}
qos: 0
description: mqtt topic zigbee2mqttcc1352/switch_opple_kitchen
payload_json:
action: ''
battery: 100
last_seen: '2021-12-02T12:38:05.818Z'
linkquality: 39
operation_mode: null
voltage: 3049
config:
button_1:
- single
- hold
button_2:
- single
- hold
button_3:
- single
- double
- triple
button_4:
- single
- double
- triple
- hold
button_5:
- single
- double
- triple
- hold
button_6:
- single
- double
- triple
- hold
event: ''
items:
- ''
button: ''
action: ''
continue: false
service: script.opple_kitchen__
Is it because payload_json -> action doesn’t contain any value? Then again, I just pressed another Opple switch using the old automation and that had no value within Action either, yet it did successfully turn the lights on.
If it helps, MQTT Explorer does show that action is being populated:
the payload action was empty, it’s working as intended.
is there another trace before it? I’m assuming that it’s an event stream and it sends 2 events. 1 with the event, and 1 with it cleared. So check the previous trace.
I should have thought to look there as well!