Ignore specific state updates for presence /motion detection?


I’m using OH3 and I’m wondering if there is a way to drop certain state updates?

As simple example, I have an Item that is updated by a Things Channel every 30 sec with a state “ON” or “OFF”.
I would like to have the “OFF” updates filtered out / dropped / blocked / ignored so I would be able to only receive the “ON” updates in combination with an expire=“5m,OFF”.

This way I would be able to (for example) subscribe to wildcard MQTT topics, (simple) presence detections (without debouncing proxy Items), etc.

Is there a way to filter out these state updates / events?

Best regards,

Are you subscribing to that event using a rule?
You could only look for the changed event then:

Hi @Sascha_Billian ,

Thank you for your reply!
No I’m not subscribing through a rule, not per se.

Say something like this:
MQTTbroker → {state: ON/OFF; …} → Binding → Thing (/topic/presence/#/state & “ON”) → Item(expire=“5m,OFF”)

filtered only passthrough “ON” updates. If the updates don’t come anymore (dropped), then expire and set to OFF.

Best regards,

OK, I think you would neet to use a rule and hav a proxy item in between.
Your MQTT triggers the proxy item. When the proxy item changes (and only if it changes), you fire a rule that triggers the actual item that has a expiration.
With that you also have much more flexibility

Yes well, I’m already at 300+ Items (modbus, jeay) so I would like to handle these things within the Items and/or Things configurations. Just adding proxy items and groups doesn’t make things better. The MQTT is just an example, could also be a zigbee / Zwave device, an Unifi wirelessclients, some wallswitch or PIR detector, doorbell, camera motion event, cooking hood, manual ventilation overwrite, etc. Just in the basic, isn’t it possible to filter out with using some transformation?

Best regards,

You might be overthinking this. If you get OFF updates, there will not be any expire action … the Item is now OFF or was already OFF.

Rules are there to meet complex or unusual requirements, don’t tie yourself in knots trying to avoid them.

Let’s focus on that - selecting from multiple events.

Have a Switch Item “myPresence”, and use expire 5mins on that.

Then there’s 50 sensor Items.
Some are motion sensors, they go ON for detect and auto-OFF later - only interested in ON transitions for first detection, or updates for continued detection.
Some are door/window contacts - interested in any transition (somebody did that), but not interested in any steady state.

I’ll make two Groups -
gActivechange for motion sensors
gAnychange for door contacts

Now I’ll make a rule to run the whole show

rule "note active detection"
   Member of gActivechange received update ON or
   Member of gAnychange changed

That’s it.
“Filtering” by Group membership and careful choice of rule trigger, no proxies.

hi @rossko57 ,

Thank you for your contribution.

If it’s possible to use an event /status filter It could be done with a simple overlaying group-aggregation Group:Switch:OR(ON,OFF) and having the expire configuration set on the items (which is the source that expires).

Practically I would like to achieve is motion/presence detectors with individual expire timers configured for specific sources (presence on wirelessclient, zigbee/zwave motion detectors, camera motion detections, presence on wallswitches, etc) and with that some debouncing (ignoring the OFF as an direct Item update).

Best regards,

Well, set to it. Groups and rules are available to make your task easier.

Why? Who cares about sensor states as such. Re-cast this, you want to use sensor info in different ways to derive various “presence” conditions. Let sensor Items reflect sensor state accurately, do manipulations elsewhere.

So lets bung all sensors that indicate a short-term presence (say, motion sensor in the hall) into one Group.
And sensors that indicate a long-term presence in another (TV turned on).
Rules can produce different actions for activity within each Group.

Thank you for your example @rossko57 ,

As you point it this way it sounds easier to setup and maintain, indeed.
I suppose the expire binding will then be set on the myPresence Item, right?

Best regards,

Of course you have myPresenceLongtime and myPresenceShorttime etc.with different expires, and Group gMasterpresence as an OR of those.

What about using profiles and mapping OFF to ON?

What about it?

rule "note active detection"
   Member of gInterestedInOffstates received update OFF or
   Member of gInterestedInOffstates received update CLOSED or
   Member of gInterestedInOnstates received update ON or
   Member of gInterestedInOnToOff changed from ON to OFF or
   Member of gAnychange changed

I’ve thrown in Contacts as well

1 Like

Hi @Matze0211 ,

That would still give updates and will prevent the expire to expire.

@rossko57 :
This works like a charm, a real clean solution. I was pointed into the wrong direction by reading some debounce and expire tutorials. Very simple to implement and to maintain!

Best regards,