Filter sensor

My WTH moment was discovering the filter sensor. It just seems so pointless. In order to calculate a moving average I had to create a MQTT sensor with the raw data and a filter sensor with the average.

IHO filters should be an option on all sensors:

  - platform: mqtt
    state_topic: "home/bedroom/temperature"
    filters:
      - filter: outlier
        window_size: 4
        radius: 4.0
      - filter: lowpass
        time_constant: 10
        precision: 2

The current filter sensor would then become a template sensor with standard filters available.

Dont know what your talking about, but a vote for the formatting :wink:

1 Like

And be configurable via the UI

tbh I don’t understand why sensors are so different feature-wise.
Yes, filter would be a feature of each sensor. So ability to assign default icon or use templates to setup attributes.
The need of creating intermediate sensors just to achieve final sensor with required features is counter-productive.

1 Like

Because a sensor can be anything. True/False, numerical, text based. You name it, a sensor can do it.

And worse, filter doesn’t appear as a sensor if one types “Sensor” in the docs even though it is a Sensor.

What? Can you elaborate?

Fortunately, it works on the Integrations page:

My mistake, I see what you mean now. It isn’t included in the sensor category.


EDIT

It’s considered to be part of the Utility category.

If one executes this search: https://www.home-assistant.io/integrations#search/sensor various first class sensors don’t appear including filter, statistics etc. In general I think that any of the existing sensors that require the entity_id of another sensor should be implemented as filters.

Edit: min_max too and maybe a few others. One could probably drop min_max in favour of statistics or vice versa.

That’s because sensor is not in the name filter. That search is a simple ‘does the title of the integration contain the word’ search.

You’re welcome to edit the help pages and add that in. It’s very simple to do.

Idk if this helps make them more discoverable since the categories are so huge but there is a sensor and binary sensor category. Looks like most integrations categorize themselves there when their integration makes either a sensor or a binary sensor. The utility integrations don’t currently seem to do that, they probably should be updated and dual-listed for some small increased visibility.

It won’t help with the search since that’s still a search by name but maybe a bit easier to find. Also it might be nice if when your search term exactly matched a category if the UI showed a link at the top of the search results like “did you mean the category ‘sensor’?” for users to click on.

As the author of the filter sensor, I’m shamelessly voting up this one :sweat_smile:

This was my intention when the integration was submitted.

3 Likes

Created a PR to add the missing categories. I can at least do that much :slight_smile:

2 Likes

Wow! Thanks!

As the author of the filter sensor, I’m shamelessly voting up this one :sweat_smile:

This was my intention when the integration was submitted.

I had a look at this pull request. You worked really hard on filter sensor and making it acceptable.

What was the reasoning for a separate sensor and not a decorator on Sensor? I didn’t see that?

I think esphome does it right: Sensor Component — ESPHome

1 Like

It’s in my comment: Data Filter Sensor (was: Filter helper decorator) by dgomes · Pull Request #12506 · home-assistant/core · GitHub

1 Like