I’d like to share some approach to set a “presence” item following the switch or contact channel of a motion detector while defining the “
OFF/CLOSED”-timeout via expire metadata.
An arbitrary motion detector sends
ON command (or
OPEN) when motion is detected. After a certain timeout, the motion detector sends the ‘
OFF’ (or ‘
CLOSED’). If the time between ‘ON/OPEN’ and ‘OFF/CLOSED’ can be adjusted to fit our needs - fine.
But what if this is not the case? Means, what if the motion detector’s timeout DOES NOT fit the need for some automation in openHAB or simply has no option to set the timeout from the openHAB side?
Not clear yet? Well, some Example:
Let’s take a Philips Hue Zigbee motion detector connected to the Zigbee binding. This device brings (beside
illuminance, temperature, battery) one channel for ‘
When motion is detected, this particular sensor sends “
ON” to the occupation channel and sends “
OFF” 10 seconds after last motion is seen.
This timeout is not configurable AFAIK. For staircase lighting this is way to short, I’d probably like to set e.g. a timeout of 1 minute.
Obvious solution would be using a rule been triggered just on the ‘
ON’ command with the rule’s action setting a proxy item with some timer or “
expire” settings. But this is overly complicated for that simple use case… (even if we use channel triggers )
Leverage a MAP transformation to filter out the “
CLOSED" just let the “
ON” (or “
OPEN”) get through to set the presence item. The “
OFF” (or “
CLOSED”) is provided by openHAB’s
To filter out the unwanted “OFF” command, I’ve created a “
justOnOpen.map” transformation file:
ON=OPEN OPEN=OPEN OFF=EXPIRE CLOSED=EXPIRE
which sets the unwanted ‘
OFF’ or ‘
CLOSED’ to something which does not update the status of my contact item for the presence. This prevents ‘
OFF’ and/or ‘
CLOSED’ from updating the presence item.
Then we can apply this transformation as a profile to the channel linked to our presence item:
Finally, we attach
expire metadata to the presence item and adjust the timeout to our needs:
This solution neither needs a proxy item nor a rule.