Have you checked the trace for that automation? That should tell you which step it is failing on, so you can make sure the conditions are working as expected.
Let’s assume the problem is in the condition and you correct it. Now the automation will trigger whenever there’s an a system_log_event, of level WARNING or ERROR, and will record it to the system log using the system_log.write service.
Running that service will produce a system_log_event which will re-trigger the automation. What it wrote to the log contains the phrase that condition looks for (including a level of WARNING) so it will proceed to execute its action. In other words, won’t the first trigger start an endless loop?
hmm, that might be a correct assumption, but, it is easily mitigated by changing the service…
- service: system_log.write
data:
message: >
Ikea integration was reloaded because of {{trigger.id}}
level: warning
logger: homeassistant.components.tradfri
or something simple
i was wondering about the condition, because elsewhere I found a reference to trigger.event.data.message[0] and that made me think the condition might be incorrect, even though I dont yet see what the [0] would do in my specific situation
Based on what I have seen, message contains a list.
Then you agree it would become an endless loop unless corrected.
FWIW, I mention this only because I fell into the same trap and created a similar endless loop. Fortunately it was creating persistent notifications so I immediately detected the problem because it was highly visible (about a hundred notifications produced within seconds of the first trigger).
Yup, because message contains a list (as shown in the linked post). Not sure why it’s a list (when do multiple errors/warnings occur in the same message?) but there it is.
I think it works if you set variables at the top of the automation where they should be updated immediately after a trigger fires (i.e. just before the condition is evaluated).
have some more details, and maybe I need to change the template. what happened:
Logger: coap
Source: /usr/local/lib/python3.9/site-packages/aiocoap/transports/tinydtls.py:280
First occurred: 08:29:58 (2 occurrences)
Last logged: 08:29:59
Error received in UDP connection under DTLS: [Errno 111] Connection refused
was logged and the automation kicked in showing me the notification:
which is very nice. However, as you can see there is much more detail in the log more-info, which I also like to have in my notification. Based on the {{trigger.event.data.message[0]}} I now use in the automation, would another template be able to show me these other details, especially Logger and Source? maybe I need to check a full {{trigger.event.data}} to see what’s available…
note btw the odd mixup in trigger id which is reported to be ‘observation’, and origins a Warning level, while this was an Error, and should have logged id ‘failed’…
update
this is what happens:
Full data: {'name': 'coap', 'message': ['Error received in UDP connection under DTLS: [Errno 111] Connection refused'], 'level': 'WARNING', 'source': ('/usr/local/lib/python3.9/site-packages/aiocoap/transports/tinydtls.py', 280), 'timestamp': 1637155664.0627038, 'exception': '', 'count': 1, 'first_occurred': 1637155664.0627038}
testing:
- service: persistent_notification.create
data:
title: >
{{trigger.event.data.level}}: Tradfri reloaded
message: >
{{now().timestamp()|timestamp_custom('%X')}}: Ikea Tradfri integration was
reloaded because of {{trigger.id}}:
Message: {{trigger.event.data.message[0]}},
Logger: {{trigger.event.data.name}},
Source: {{trigger.event.data.source}},
Level: {{trigger.event.data.level}},
Full data: {{trigger.event.data}}
