Disable Automation On/Off/Unavailable Logbook Entries

Feature Requests
1

Request is to disable logbook entries for automations when ALL automations are reloaded.

I just updated a single automation to add a delay and the result was a logbook flood of hundreds of entries of EVERY automation becoming ‘unavailable’ (while they reloaded) and then back to ON/OFF after the reload.

This prevents the logbook from being useful around the times when automations are updated.

Secondary request / fix could also be to reload ONLY the automation updated vs. ALL automations when only a single automation is edited via the UI.

Logbook snippet showing a handful of my automations becoming unavailable. Keep in mind, there are hundreds of these (# of automations x 2 [one showing unavailable and one to on/off]):

image

3

Hi Mark, I have the same issue. I made a small automation and when I saved it it put all other automations to unavailable and then back to on/off. All automation which were running were cancelled.

My question: did you resolved it? Is there a solution?

4

No. I have not been able to find a way to ‘hide’ / ‘disable’ these unnecessary logbook entries when automation(s) are reloaded unfortunately.

5

See logbook config:

logbook:
  exclude:
    domains:
      - automation

Or if you don’t care about the history of the state of your automations at all then exclude them from recorder:

recorder:
  exclude:
    domains:
      - automation
6

But you don’t have the issue with the running automations being cancelled. What happens with my automations is that they become unavailable for a brief moment and the reappear as on or off. In that process. Running automations are cancelled. They just stop. And that’s annoying.

7

I’ve had this domain excluded in the past (and posted about it [Logbook - Trigger Event]).

While this fixes this on/off/unavailable ‘mess’ - it also causes the logbook to show odd events - devices being turned on / off by other devices vs. the automations where they’re triggers w/in. [my link above shows more].

8

Hm ok. Yea I don’t think there’s a way to do this then. You basically just exclude entire entities but that’s not what you want. You want some types of events for automations (the “triggered” ones) but not others (state_changed in this case). Seems like it would be useful.

9

Or even simply to reload ‘only’ the automation that’s updated when hitting SAVE after editing/updating an automation in the UI. A single logbook entry showing the ‘update’ to the single automation would be great - vs. default behavior currently of reloading every automation when saving a single when and spamming the logbook w/ unavailable / etc. entries (like this feature request suggests). Just trying to find a cleaner / more useful way to show these updates - clearly not mission-critical and just my $.02 suggestion.

1 Like
10

Yea that’s definitely needed. For many reasons, not just this one. Biggest one is that it makes delay and wait really dangerous for users which use the UI editor. Since anytime they save an automation all automations in the middle of a delay or wait are killed.

1 Like
11

:open_mouth:

Didn’t realize this…

Also makes sense (single automation reload vs. all) given the preference/push/migration from editing in YAML to editing in UI (though realize editing in YAML requires a reload of ALL automations [or reboot] to take effect).

12

FWIW, I posted an FR for incremental reloading of automations (and other integrations) almost three years ago (currently over 250 votes).

It used to be worse; you had to restart Home Assistant to load a newly created/modified automation. At least now you can execute Reload Automations without having to restart everything. Nevertheless, there’s room for improvement because Reload Automations terminates all “in progress” automations (i.e. automations that are busy executing delay, wait_template, wait_for_trigger, repeat, etc).

My guess is there has been little progress over the past 3 years probably because it’s a technically daunting task .

13

Yes! Had already voted for your FR and fully agree with it. Also fully understand that it’s likely a big lift and that not all ‘good ideas’ are able to be implemented quickly…