State Filter (Range Filter) Profile

Ok I will follow the discussion here :slight_smile:
Thanks for the effort!

I’ll update this topic once they’re merged

Works now, the 0.2 F converted to 0.111 C.

Humidity works too. Thanks!

2025-01-19 09:48:05.133 [DEBUG] [internal.profiles.StateFilterProfile] - Performing a comparison between '$DELTA' state '0.10 °C' (QuantityType) and value '0.11111111111111111111111111111111112 °C' (QuantityType)

Hi @jimtng :
I can see the change has been merged to main about 3 weeks ago, and today I saw upgrade of OH 4.3.3, is it now part of 4.3.3?

The PRs with patch tag are included in 4.3.x
[basicprofiles] Convert to relative unit in State Filter's Delta check by jimtng · Pull Request #18127 · openhab/openhab-addons · GitHub included
[basicprofiles] Fix regular comparison of Percent Quantity interpreted as $DELTA_PERCENT check by jimtng · Pull Request #18121 · openhab/openhab-addons · GitHub NOT included unfortunately
[basicprofiles] Fix handling of multiple `$DELTA` conditions by jimtng · Pull Request #18088 · openhab/openhab-addons · GitHub included

1 Like

Just want to confirm, with 4.3.3 should I use the below:

conditions="$INPUT > 0 %", "$INPUT < 100 %"

Or:

conditions="> 0%, < 100%"

Many thanks in advance!

@somy because that one PR you needed didn’t get backported, you need to use this custom JAR I’ve just built for you. It’s the same as the standard 4.3.3 jar, but with that one PR added.

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

Once you’ve installed it, you need to change your conditions to:

conditions="> 0%, < 100%"

This syntax will then be compatible with openhab 5.0 so you won’t have to change it again later on.

1 Like

Hello, I’m trying to use the State Filter profile in order to extend the Keep Time of a motion detector. Basically, I’m trying to filter out all OFF state updates of a Motion Detector sensor (The Motion Detectors trigger ON on motion, but go back to ‘OFF’ after a short (random or preset) time, if no new motion is detected). I would like to ignore that ‘OFF’ update and replace it by an ‘OFF’ update after say - 15 minutes - with no motion detection.

Switch BaseCorridor_Presence "Presence" (BaseCorridor_StairsMotionDetector) ["Status","Presence"] { channel="mqtt:homeassistant:_:...:occupancy#sensor"[ profile="basic-profiles:state-filter", conditions="EQ ON" ], expire="5m,OFF" }

When I configure this within the UI, starting from the channel, creating a link to a new/existing item, I can configure the condition(s). When I try to do this in the posted format via the “Add Items From Textual Definitions” screen, it will accep the syntax ..

But the creation still fails… the state never updates and when I try to manually edit the profile condition from the appropriate dialogue, the “conditions” box has disappeared …

Seems like a small bug to me?

This sounds like possibly a bug in the “Add items from textual definitions” process, not in the profile itself.

I tried this too but can’t reproduce the problem though. When I pasted your text definition, I got an error, but the item got created without a link. When I tried to manually add a link it seemed to work fine.

Thanks a lot!

And good news, they will be included in the next release 4.3.4

Have all the changes for State Filter’s delta made it into OH5?

I’ve just upgraded from 4.3.6, and some channels have stopped working.

I have an MQTT channel linked to a dBM item, like this:

version: 1
items:
  OutdoorSensor2_rssi:
    type: Number
    dimension: Power
    label: OutdoorSensor2_rssi
    icon: network
    format: '%.0f'
    unit: dBm
    groups:
      - SwitchBot_Outdoor_Meter2
    tags:
      - Measurement
      - RSSI
    channels:
      mqtt:topic:SwitchBotOutdoorMeter:rssi2:
        profile: basic-profiles:state-filter
        conditions:
          - '> 10%'

I’m now on 5.0.1 release, and any changes on the MQTT channel do not get through to the item.

See this thread - December 2024 - it’s been working up to now.

I’ve tried using $DELTA_PERCENT > 10, but that doesn’t work either.

yes

Try adding another item without the filter and verify the data.

Furthermore set DEBUG log level on org.openhab.transform.basicprofiles.internal.profiles.StateFilterProfile

I did try that, and it works OK.

Turning on debug gives:

2025-09-11 12:16:00.447 [DEBUG] [internal.profiles.StateFilterProfile] - Received non allowed state update from handler: -62, ignored

Even setting a positive value is also ignored.

I have just re-setup my OH4.3.6 on an old Pi just to check, and it works fine.

Can you link the channel to a String item without any filtering, then log a few values so that I can test them? You can log them using a script that writes the value every update to a text file.

Here’s an example script in jruby (file-based) - assuming that the String item you created is named TempItem

updated(TempItem) { |event| File.write(OpenHAB::Core.config_folder / "rssi.txt", "#{event.state}\n", mode: 'a') }

Or you can create a UI based JRuby rule, triggering on TempItem update:

File.write(OpenHAB::Core.config_folder / "power_load.txt", "#{event.state}\n", mode: 'a')

I don’t know jruby, but I’ll try figure something out with javascript.

From my investigations so far, the problem seems to be linked to MQTT channels that do not have a Unit Of Measurement specified. I’ll let you know.

You could just copy paste the code as-is without knowing anything about Ruby. Or write the equivalent in JS.

Or bypass openhab and just use mosquitto_sub, redirect (or tee) the output to a text file. All I need is the raw mqtt data.

The raw mqtt is

{“temperature”:17.6,“humidity”:81,“battery”:64,“rssi”:-88}

Is that what you need?

So I can confirm that MQTT channels that do not have a Unit Of Measurement specified cause the problem.