State Filter (Range Filter) Profile

Development Features
,
82

Adding ‘dBm’ to the UOM does mean that the value is no longer ignored, but the calculation is wrong

2025-09-11 15:27:26.917 [DEBUG] [internal.profiles.StateFilterProfile] - Evaluating Condition('$DELTA_PERCENT' $DELTA_PERCENT GT '10' ) with input: -84 dBm (QuantityType). Link: 'OutdoorSensor2_rssi -> mqtt:topic:SwitchBotOutdoorMeter:rssi2'
2025-09-11 15:27:26.917 [DEBUG] [internal.profiles.StateFilterProfile] - Calculating function: $DELTA_PERCENT
2025-09-11 15:27:26.918 [DEBUG] [internal.profiles.StateFilterProfile] - Performing a comparison between '$DELTA_PERCENT' state '25.89254' (DecimalType) and value '10' (DecimalType)
2025-09-11 15:27:26.918 [DEBUG] [internal.profiles.StateFilterProfile] - Received state update from handler: -84 dBm, forwarded as -84 dBm
==> /var/log/openhab/events.log <==
2025-09-11 15:27:26.920 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OutdoorSensor2_rssi' changed from -85 dBm to -84 dBm
2

I do remember, back in Dec 2024, that calculations on dBm were ‘difficult’, and that was why the suggestion to remove UOM from the channel worked.

83

@AndrewFG added some extra unit normalization code which may have altered this behaviour.

MQTT: generic Thing loses somehow connection for specific devices
84

Hello @jimtng,

Thanks for this feature, this is very great.

I discover it yesterday when I was asking myself of how to filter value coming from a ultrasonic level sensor I’m using for my fuel tank.

I’ve done some test, and have several interrogation / question about using it.

first to give you an overview of the previous situation, this is a snapshot of my previous unfiltered values.
As you can see, there is a lot of noise : value that are completely outside of range.
But as you can also see, the average of values are correct.
The jump on 26 around 8:00 is because we add 500 L to the tank.

What I try so far, is to filter the input value using a condition on DELTA_PERCENT.
This make thing smoother, but I’m not sure if it’s the best solution in my case.

Number
Sonde_Fuel_Rozier_Level_Current
“Sonde fuel level \[%s\]”			
(gTank)
\[ “Measurement” \]	
{
channel=“tuya:tuyaDevice:bfaa6efb840ae0e84bve3p:liquid_depth”  \[ profile=“basic-profiles:state-filter”, conditions=“$DELTA_PERCENT < 5” \]
}

image
image1855×889 46.9 KB

My question are the following:

  1. Is using $AVERAGE, or $MEDIAN can be a better solution in my case.
    If so, I don’t see sample of how to use it. Perhaps something like comparing my current incoming value with last 10 avg or median. Something like:
         conditions=“ABS(Sonde_Fuel_Rozier_Level_Current - $AVERAGE(10)) < 5” ]
  1. Second question is about mismatchState. If I understand properly, the default is to not update if the conditions are not met. Would it be an option to have a special mismatchState like mismatchState=”$AVERAGE” that will update the state with the average when condition are not meat.
  2. Also, how can I handle specific case like tank fill up, that will change the value with great increment (I think if I move to using an average or median window, it should work as it) ?

Thanks,

Laurent.

85

@lo92fr When I added all these improvements to the existing State Filter profile, I didn’t have a concrete need for it and didn’t have any real use case.

Now given your requirements gave me a concrete example to ponder and I think the current State Filter as it is is insufficient to achieve what you really want.

I think ideally the filter should be expressed in something like this:

ABS($CURRENT - $MEDIAN(10)) < 5

But the State Filter as it is doesn’t support such an expression.

So perhaps your best bet for now is to use this, which is unfortunately only available in 5.2-snapshot
https://next.openhab.org/addons/transformations/basicprofiles/#time-weighted-average-profile

Perhaps I (or someone else) need to work on the State Filter to enrich its expression capability in the future. Its power at the moment is that it performs the statistical calculations for you without lengthy code required (e.g. in javascript). The same functionality can be done in JS / jruby but it’s going to be a lot more complex to implement especially if you aren’t into coding.

I’m thinking for backwards compatibility, leave the current conditions as is, and implement a new expression for the more advanced syntax.

I’m currently working with Jinja in another thing (yaml model enhancements), and perhaps Jinja could be a candidate to implement this since it supports evaluating expressions out of the box, we just need to supply it with the actual data, or implement the custom functions such as median(num_of_samples) or ItemName (to represent its state).

86

Good evenning @jimtng,

thanks for your answer.
As I’m already on 5.2-Snap, I we take a look to time-weighted-average-profile.
I’m also developer, so of course coding something directly in Javascript is another options.
I see some code like this earlier this week, I will also give it a try.

Laurent.