Trigger automation from dynamic list of input_boolean

Configuration
,
1

Hi all,

I don’t know if this is possible or not. I am trying to have a whole bunch of input_booleans so that I can toggle specific parts of the logging on or off. I think this will make it much easier to debug issues.
In the dev tools template this works for generating a list of the booleans I use to toggle logging

  {% for boolean in states.input_boolean if "_logging" in boolean.entity_id %}
    {{ boolean.entity_id }}{% if not loop.last %}, {% endif %}
  {%- endfor %}

However I am struggling to work out how to use this in the trigger. I basically want the trigger to fire if the state of any of the entities in the list changes.

Is this possible?

Thanks

2

Use a State Trigger to listen for state-changes of a dynamically generated list of input_booleans? No. A State Trigger doesn’t support templates.

A Template Trigger supports templates. However it simply evaluates the template and triggers when the result of the evaluation is a boolean True.

3

Thanks for the response, so am I right in thinking that I cannot do it at all as if it only evaluates when its true I would be able to turn logging on but not off?

4

Different question but the same answer, no.

To understand why, try creating a template that listens for state-changes of a dynamically generated list of entities and evaluates to True when one of the entities changes state. To make it initially easier, start with a fixed list of entities. The exercise will make you understand the hurdle better than any explanation.

5

If you really want/need an automation that is triggered whenever an input_boolean, from a dynamic list of such entities, changes state, that can be done using an event trigger that looks for a state_changed event and then uses an appropriate condition.

However, I have to ask, is that really what you need? What is the ultimate goal of the automation?

6

Thanks for the response Phil, What I want to make is a screen with an input select for the log level then a ton of input_booleans one for each type of logging so I can turn on and off specific sections of the log. I find it much easier if I can trim the log down to just the type of thing I am debugging. So for instance I would be able to change the logging level of automations to debug without rebooting or turn off mqtt logging.

Hope that makes sense.

7

Wow, that seems like a lot of work. How often do you need to debug something? And when you do, why not just use the services page?

But, like I said, you could do it with an event trigger looking for a state_changed event.

1 Like
8

I’m confused… it seems to me there are many things you just have to go through the logs to find out what the errors are or am I being a dufus and there is a much easier way?

9

?

How many errors are we talking about here and how frequently do they occur? Something is amiss if you feel you need a debugging infrastructure to manage them.

10

I’m just saying instead of building a huge infrastructure to change logging levels via helper entities, on the hopefully rare occasion when you need to adjust logging levels (and you want to do it without modifying a config file and restarting), why not just use the logger.set_level service from the dev tools page?

11

pnbruckner is referring to all of the existing functionality available to you via the Logger integration:

12

Ahhhhh now I understand I am being a dufus! Services page it is for me from now on. Sometimes I just dont connect the dots correctly.

Thanks guys

1 Like