Logging and recorder settings via the UI

Bringing the logging and recorder settings to the UI, for example to entity configuration. This makes it less annoying to add new entities and turning logging off.

I’m really digging the .yaml less life.

Yes! This is my wording:

Why do I have to go to the services page (or configuration.yaml) to change the logger level? Shouldn’t there be a log page where I can select which components to log at different levels?

I can envision a dropdown list (or something that updates as I type like the entity selector) which will then allow me to change the logging status for that domain/entity.

Voted!
And it would also be nice to have a “do not show this error again” button in the logs view.

More for warnings, but yes, if these logs can be uniquely identified, then a hide further messages button (with the ability to reset of course) would be a nice to have

Yes saving time for debugging could be very useful! Not sure if this could be set during runtime or not since I think it is a setting in python, but on the server tab (or close by) would be nice

I was about to add the same! :slight_smile:

Sadly I can vote only once for a single WTH post.
But having an UI to extlude entities from the recorder (and history) would be a life saver!
There are some entities for which you don’t want history, so ideally there should be a way to exclude them.
Ideally we should be able to set data retention per entity/pratform.
For example you don’t need to know when the heating pump was turn/off two months ago, but you would like to know what the temperature was then.

So each entity could have an option to pick recorder settings from the list:

  • Default (as configured in yaml)
  • Always store (override config from yaml)
  • Don’t store (override config from yaml)

And an option to specify the number of days for which we want to have history.

4 Likes

Voted!
I would also love to be able to give different retention periods for data in logging and recorder. I don’t care if the light was on last week at noon, but I do care if a camera event happened or my total energy usage at that moment for example.

3 Likes

I would also like an indication next to each entity that would show how many recorder entries it performs.

That way I could exclude something mildly interesting but heavy to the database

Something like this could be cool:

In case it wasn’t obvious, I’m not a designer and this is hacked up in Paint, just trying to convey an idea.

There’s actually a lot of integrations that have the same include, exclude filtering options as recorder, history and logbook so it would be cool if the whatever was built was extensible to anything implementing that interface. Picked 3 that I know do this as an example.

6 Likes

Uh, no thank you! Imagine clicking each device and toggling it in a list of 500 entities. Count me out on that one.

If this is done, it should be something that can be bulk selected and offer includes and excludes per device without having to enter a second window.

5 Likes

That’s true, I guess I was kind of thinking this could supplement a bulk experience like that. But you’re right, if this was the only way to change whether an entity was included or excluded then that would get frustrating

I’m with you. Let me do it in YAML, it will be a quick copy/paste of my existing recorder included/excludes with a few changes. Not to say it can’t have a UI component too, but it must have a YAML component.

It would be nice to have a UI manager (for example similar to the following image):

8 Likes

Take my vote, this has really bugged me at times. I would love to store temperatures, power usage and such for a long timespan, and i dont care when a lightbulb was on/off last month. This should probably not be that hard to implement either… :+1:

1 Like

I voted but not necessarily for the OP specific implementation.

When adding entities via yaml it’s not a big deal to modify recorder/history settings at the same time. However, when adding some other way (like via an integration, which is becoming the norm) the entities get added to an already running system – and start getting logged immediately. Thus, updates to recorder/history are needed plus a (seemingly unnecessary) restart.

Hopefully an updated method to handle all this can be arrived at?

  • A means to allowing entities to be modified individually in a running instance and/or as an entity attribute in yaml?
  • Default settings for newly added instances (whether to record, show in history, purge time)
1 Like