State Filter (Range Filter) Profile

Development Features
,
42

Thanks! I have made the change and will report back how it goes.

43

Iā€™ve submitted a PR to fix this:
https://github.com/openhab/openhab-addons/pull/18091

There are also two other PRs to fix other bugs Iā€™ve discovered during testing.

1 Like
44

Hi @jimtng :
Unfortunately the new version doesnā€™t seem to help.
Below is my configuration:

Number:Dimensionless    ToolshedHumidity                        "Toolshed Humidity [%.1f %unit%]"                                                    (gToolshedWeatherSensor)                                     {channel="miio:lumi:xxxxxxxx:humidity"[profile="basic-profiles:state-filter", conditions="> 0 %", "< 100 %"], unit="%"}

And I have cleaned cache and tmp folder and double checked the version of basic profile binding. I can see many spikes later today:

IMG_5908
IMG_59081206Ɨ2622 229 KB

Shall I try without % like conditions=ā€œ> 0ā€, ā€œ< 100ā€?
Many thanks in advance!

45

@somy change your conditions as noted above

Also, have you downloaded the jar that I posted above?

46

Hi @jimtng : sorry my bad I didnā€™t have the dollar sign before INPUT.
So far I havenā€™t seen any spike so it seems to work well (will keep an eye on it for the next couple of days).
BTW it also seems to work when I donā€™t specify unit ā€œ%ā€ in the condition.

47

Iā€™m on OH 4.3.2. When I try the ā€˜>ā€™ or ā€˜<ā€™ symbols, this state filter doesnā€™t seem to work. But if I use the GT or LT, it works. Iā€™m setting this via MainUI.

link jsondb that works when I use ā€˜GTā€™:

      "configuration": {
        "properties": {
          "conditions": [
            "GT -100.0"
          ],
          "mismatchState": "12.0",
          "profile": "basic-profiles:state-filter"
        }
      },

link jsondb with the > that doesnā€™t work. Does the ā€˜>ā€™ not get through the MainUI properly?

      "configuration": {
        "properties": {
          "conditions": [
            "\u003e -100.0"
          ],
          "mismatchState": "12.0",
          "profile": "basic-profiles:state-filter"
        }
      },
48

I tried this myself, and indeed when using >, the jsondb will contain the condition as \u003e -100.0. However, when I tested the filter in action, it performs as expected.

Can you show me the channel configuration that this link is linked to?

BTW you are using the built-in addon, not some temporary / test jar from me that youā€™ve placed inside your addons folder?

49

How do you debug this? Are there any useful debug logs that can be enabled? Right now I put an unusual value in the mismatch, then monitor the event log to try to get some idea of what it is doing.

I think I have multiple issues, so Iā€™d prefer to sort those out on my own.

Anyway, I installed the ā€˜Basic Profilesā€™ from the Transformations. Is that not the correct one to use? I think this is the one:

347 ā”‚ Active ā”‚  75 ā”‚ 4.3.2                 ā”‚ openHAB Add-ons :: Bundles :: Transformation Service :: Basic Profiles
50

Enable debug or trace log level for org.openhab.transform.basicprofiles

1 Like
51

Okay, hereā€™s one that I donā€™t understand. The initial Item state is 18.8 C, 18.7 C comes in, and my condition is $DELTA GT 0.2 Ā°F. 0.1 C delta is less than 0.2 F, so I do not expect it to pass through, but it does. Must I use Ā°C in the condition instead?

2025-01-17 17:08:24.396 [DEBUG] [internal.profiles.StateFilterProfile] - Received state update from handler: 18.80 Ā°C, forwarded as 18.80 Ā°C

2025-01-17 17:08:29.438 [DEBUG] [internal.profiles.StateFilterProfile] - Evaluating Condition('$DELTA' $DELTA GT '0.2 Ā°F' ) with input: 18.70 Ā°C (QuantityType). Link: 'IndoorTemperatureSNZB02P -> zigbee:device:52956d2d72:842712fffeffbfe9:842712FFFEFFBFE9_1_temperature'
2025-01-17 17:08:29.438 [DEBUG] [internal.profiles.StateFilterProfile] - Calculating function: $DELTA
2025-01-17 17:08:29.439 [DEBUG] [internal.profiles.StateFilterProfile] - Performing a comparison between '$DELTA' state '0.10 Ā°C' (QuantityType) and value '0.2 Ā°F' (QuantityType)
2025-01-17 17:08:29.439 [DEBUG] [internal.profiles.StateFilterProfile] - Received state update from handler: 18.70 Ā°C, forwarded as 18.70 Ā°C
52

The problem is the comparison is done as if they were absolute numbers, not delta.
0.1 Ā°C => 32.18 Ā°F, so that is bigger than 0.2 Ā°F.

Using the same unit in the condition would avoid this issue.

This is probably a ā€œbugā€ or can be improved in the filter - I need to think about this. Iā€™m open to suggestions

53

Hereā€™s another one I donā€™t understand. I have a humidity sensor that occasionally reports greater than 100% humidity (!). I put in ā€˜LT 100.0 %ā€™ as the condition. That gets interpreted as $DELTA_PERCENT which I wasnā€™t expecting. Maybe I should just use ā€˜LT 100.0ā€™?

2025-01-17 21:01:57.920 [DEBUG] [internal.profiles.StateFilterProfile] - Evaluating Condition('$DELTA_PERCENT' $DELTA_PERCENT LT '100.0' ) with input: 82.84 % (QuantityType). Link: 'OUTDOOR_HUMIDITY -> mihome:sensor_weather_v1:7811dcb90279:158d0006bcda72:humidity'
2025-01-17 21:01:57.920 [DEBUG] [internal.profiles.StateFilterProfile] - Calculating function: $DELTA_PERCENT
2025-01-17 21:01:57.920 [DEBUG] [internal.profiles.StateFilterProfile] - Performing a comparison between '$DELTA_PERCENT' state '1.91' (DecimalType) and value '100.0' (DecimalType)
54

Yes, using C for the comparison works fine:

2025-01-17 21:13:03.769 [DEBUG] [internal.profiles.StateFilterProfile] - Performing a comparison between '$DELTA' state '0.10 Ā°C' (QuantityType) and value '0.12 Ā°C' (QuantityType)
2025-01-17 21:13:03.770 [DEBUG] [internal.profiles.StateFilterProfile] - Received state update from handler: 17.70 Ā°C, not forwarded to item

Thatā€™s kind of a problem because I was unaware that the underlying channel was using C - everything I see is in F. So when I wrote the filter, I had no inkling that I had to use C. And the filter kept passing everything through. (It does make sense that C is used by these sensors as that is the proper unit, but Iā€™m trained to use F)

55

This is a known issue reported by @somy a few posts above.
A current solution has been submitted as a PR, but I need to think whether thereā€™s a better way to automatically figure out that the comparison is done on the input value and not delta when the input value is a quantity type with percent as unit.

56

I agree, and Iā€™ve just found the solution. I need to use toUnitRelative! Iā€™ll post this as a PR soon.

57

@somy, @jswim788

For filtering the humidity value that comes in as a Percent value, I have published two possible solutions.

https://github.com/openhab/openhab-addons/pull/18121
https://github.com/openhab/openhab-addons/pull/18091

Both solutions can coexist, although perhaps #18091 is not strictly necessary.

WDYT?

58

Iā€™ve submitted a PR to address this:
https://github.com/openhab/openhab-addons/pull/18127

@jswim788 would you mind testing this JAR please. It should allow you to specify the DELTA filter using Ā°F even when the incoming data is in Ā°C.

  • I uploaded the jar in the next post
59

And this one contains both fixes

  • DELTA check with relative unit
  • Perform comparisons of input percent values, do not interpret it as DELTA_PERCENT comparison

org.openhab.transform.basicprofiles-4.3.3-SNAPSHOT.jar.txt (61.3 KB)

2 Likes
60

Hi @jimtng

There is official 4.3.2 release and would like to ask if the change for humidity is in 4.3.2 so I can use the official version?
Thanks

61

Unfortunately it hasnā€™t been merged yet :frowning:

It is likely that the new solution will be accepted, so instead of using $INPUT, you would go back to the original conditions, i.e. without $INPUT.

There are a few other bug fixes (all related to delta / delta percent!) yet to be merged. Hopefully theyā€™ll all be merged and ready for 4.3.3 (not sure when that will be)