@dgomes awesome work on filters. Is your “low pass” filter the same as “Exponential Moving Average” ?
Yes!
The time constant and window size control the weights and the lag respectively.
You need to set a new sensor for each entity you need to filter.
Hi, Could you please post a sample on how to do setup new filter sensor for each entity? I tried all sort of combinations. Nothing works for multiple filters. The only thing that works is the exact configuration posted in help. (ie: ONE filter with multiple sub-filters inside. What I need is a filter for each sensor… So below does not work:
- platform: filter
filters:
- name: "EMA Wind"
entity_id: sensor.pws_wind_kph
filters:
- filter: outlier
window_size: 4
radius: 6.0
- filter: lowpass
time_constant: 3
precision: 2
- name: "EMA Gust Wind"
entity_id: sensor.pws_wind_gust_kph
filters:
- filter: outlier
window_size: 4
radius: 6.0
- filter: lowpass
time_constant: 3
precision: 2
But this works perfectly:
- platform: filter
name: "EMA Wind"
entity_id: sensor.pws_wind_kph
filters:
- filter: outlier
window_size: 4
radius: 6.0
- filter: lowpass
time_constant: 3
precision: 2Just declare a filter for each entity:
- platform: filter
name: "EMA Gust Wind"
entity_id: sensor.pws_wind_gust_kph
filters:
- filter: outlier
window_size: 4
radius: 6.0
- filter: lowpass
time_constant: 3
precision: 2
- platform: filter
name: "EMA Wind"
entity_id: sensor.pws_wind_kph
filters:
- filter: outlier
window_size: 4
radius: 6.0
- filter: lowpass
time_constant: 3
precision: 2
2 Likes
Ok, Thank you…
this is a bit different syntax for having multiple “things” from the format for all others…
Yeah, that’s not going to be at all confusing… 
I find this format more straight forward as it enables me to maintain the filter sensor declaration right next to the raw sensor declaration.
But can agree that a single platform instantiation would be more inline with the template_sensor (an example).
It would be a breaking change (people would need to change their configuration), but if enough people “love” this comment, I’ll move the configuration to something like How to use the new filter sensor with “sensors:” instead of the first “filters:”
2 Likes
I’ve revised my previous answer:
Low Pass filter is the algorithm described in https://en.wikipedia.org/wiki/Exponential_smoothing
1 Like
Sorry, just reviewed the code, the filter has nothing todo with average/median.
It is exponential_smoothing.
Here is the relevant code:
new_weight = 1.0 / self._time_constant
prev_weight = 1.0 - new_weight
filtered = prev_weight * self.states[-1] + new_weight * new_state
Wikipedia’s alpha = new_weight
I would also vote for allowing us to add the “entity_id” as a first line for the filter. Currently the “name” attribute determines the entity id used by HA. it converts the name to id with “_”. template sensor and other components, allow us to specify id by explicitly providing them. . like my_filter_id: . name should be just a friendly display name in HA.
ie:
- platform: filter
my_filter_id:
name: "EMA Gust Wind"
entity_id: sensor.pws_wind_gust_kph
filters:
- filter: outlier
window_size: 5
radius: 5.0
- filter: lowpass
time_constant: 5
precision: 2
1 Like
you can set the name of the sensor to whatever you want… don’t understand…
Yes, let me try explain…
I can set the name of the sensor to anything I want, for as long as HA does not think that my names of multiple sensors are too similar and collide them to the same id and then complain. in below log entry: sensor.ema_wind sensor was created by HA, by converting the “name” attribute I have given: “EMA Wind” to “ema_wind” as id. If I have a second sensor with a name “EMA Wind Gust”, I was having HA telling me I have a duplicate name… I think HA was trying to create another “ema_wind” id… So I had to name my second sensor: “EMA Gust Wind” instead of what I wanted “EMA Wind Gust” , to make sure HA does not collide ids…
If I could explicitly provide id for the sensor , I would avoid collision and at the same time still could have the display name I want.
If I am missing something simple here , please correct me… I hope this explains what I am asking…
And again, if you look at “template sensor” the schema for template sensor does provide to specify “id” as a first config parameter…
For example this is definition of a sensor with id “windy” as my template sensor:
windy:
friendly_name: 'Current Wind'
icon_template: mdi:weather-windy
value_template: >-
{% if (states.sensor.pws_wind_kph.state | float + states.sensor.pws_wind_gust_kph.state | float)/2.0 > 20.0 -%}
Windy
{%- else -%}
Beer
{%- endif -%}
This is an entry in a log file where you can see my new filter sensor being given an id “ema_wind” by HA…
2018-03-10 18:31:28 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.ema_wind, old_state=None, new_state=<state sensor.ema_wind=unknown; entity_id=sensor.pws_wind_kph, friendly_name=EMA Wind @ 2018-03-10T18:
Again, I think that filters idea is awesome !! We really need it…
Another request for you: Can you implement a “bias correction” in the next version?
As it the filter will take some time to “warm up” especially when there is no history before. bias correction is a small change to the formula and should be optional to the filter. it would fix the filter during the “warm up” period.
entity_id is constructed by slugify(name)
If name’s are different entity_id is different… I cannot replicate what you have described 
the template_sensor “id” is actually a name.
I have already a PR in https://github.com/home-assistant/home-assistant/pull/13075 that will “warm up” based on the history component.
It should solve your issue
1 Like
Ok, let me play with it a bit more… and see if I can replicate it again. I was getting the error while I was struggling the the format of yaml for multiple sensors. Maybe it was unrelated…
warm up from history will be great as well.
But with “bias correction” you don’t need history… You add another component to your formula that will not weight history as much at the warm-up period and start to weight it more as filter gets more periods of time… And since it is NOT dependent on history, it will be much simpler to implement as well. Both would be useful and maybe a “parameter” to warm-up: warm-up=history or warm-up=bias-correction or “auto” . If history exists, use history, if does not exist, use “bias correction”
@dgomes.
Feedback:
Been using the outlier filter for a few days…
What is needed in my case and probably with others is the “asymmetric outlier” filter.
Ie: we should be able to specify different radius on the bottom and top. this way I could filter out outliers on the drop of the signal side or on the top. by default radius is same on both sides. (maybe parameter “symmetric/asymmetric” , if we chose asymmetric , then we specify two different radius and you would keep track of median values of the TOP side and the BOTTOM side. and replace each side with each own median value…
That would be REALLY useful additional filter. or V2 version of the outlier filter.
What do you think?
I can see an extra option on the outlier filter to implement what you describe.
But currently I’m really busy with pushing other components (plus my day job). I’ll have to leave it as a backlog.
But since this an Open Source project, someone else can also do the changes 
1 Like