Item to register "ON", but ignore "OFF" command -- possible?

Is it possible for an item to deal with a Thing sending an “ON” command (and update the state), but sort of ignore the “OFF” command (and leave the state as is). I was thinking about a Thing Channel Profile, but coudln’t find an appropriate one.

Use case:
My Sonoff motion sensor (linked via zigbee2mqtt and the mqtt binding) sends “ON” upon motion detected, and then sends “OFF” after approximately 90 secs. During these approx. 90 secs (cooling period, depends on the individual sensor) it will not send another “ON” and will also not extend the cooling period, if another motion is detected. I didnt check that, but I suppose that it would register the next motion and honor it with an “ON”, if it occured precisely 91 secs after the first one, but there could be an additional wait period.
The raw motion sensor input, is not appropriate for light control. It would turn on the light upon motion (which is fine), but I would like to turn the light off not at the random 90 secs after the first movement, but rather - say after 10 minutes after the last movement. I understand I can set expire to those 10 minutes… but I still would need a way for the Item to ignore the “OFF” after the 90 secs cooling period.

I also would like to avoid individual Rules for such a simple task, which will occur on many sensors.

This is what rules are for. They cost you nothing. You’re just making it difficult for yourself. Try to overcome whatever is your blocker here.

There are a lot of motion/light/delay examples in this forum.


Well, there are 27 motion sensors. What I’m trying to do, is to translate the motion event into a time parametrizable and retriggerable presence event.

Do I really need 27 rules and 54 items for that?

I understand, of course, I can do this with Rules. But it was my understanding from the documents that this situation is precisely what channel profiles are for → translate unexploitable Thing raw data into usable Item information.

Note that if this is the SNZB-03 device it has some pretty annoying behaviour:

If you do set the timeout to 10 minutes then perhaps that’s not an issue, but if it’s in an area where you may get constant movement for more than this period of time then your light won’t retrigger to ON until the next lack of motion has happened, and then some motion again.

You will need 56 Items, but only one rule :slight_smile: The magic word is “Groups”. Build pairs of Items, two per Sensor, the first Item is the input from sensor, the second item is the output from rule. Make names in a way, that it’s possible to get the name of the output Item from the name of the input Item, for example


Just make sure all Item names are consistent. Each Output Item should directly control the light. Each of these Items should get Metadata “Expiration Timer” with the timeout 10 Minutes and a send command “OFF”.

Now create two Groups for these Items, one for IN, one for OUT:


and put all Items in the corresponding group.

Now one rule will suffice.

rule "motion detected"
    Member of gMotion_IN received update ON
    val strName ="_").get(2) // last part of Itemname which triggered the rule.
    val outItem = gMotion_OUT.members.filter[i|].head

Whenever a Motion Item gets the update ON, the rule will trigger. strName is set to the last part of the name of the triggering Item. outItem is set to the Item, which matches to the input Item. The Item gets the command ON.
If there is no motion before timeout ends, the Item itself will issue the OFF command. If motion is detected, the Item gets another ON command and the timeout starts again.


One rule will do them all.
If you have 27 sensors, you will need 27 Items to represent them. It’s okay, these come free of charge as well.
To exploit a “one rule”, you will need an additional Item as well - a Group for your 27 sensors.

I don’t know how many lights you have, but you should have at least one Item for each of those.

Ah, parameters. If you want those controlled by users or time-of-day or suchlike, you will almost certainly be forced to use rules anyway, to make decisions about e.g. delay times. You cannot easily vary expire timer configuration.

That’s another Option. Just omit the OFF… Use a JavaScript for that. I’m not sure, though, if it’s possible not to update the value at all, but it would still be possible to send an ON, wether Input is ON or OFF. Of coarse you will have to subtract the 90 Seconds from Expiration time.

    return 'ON';

As profile, use JS with parameter on.js

EDIT: added single quotes so ON is handled as a string.

thank you very much this points me perfectly where I wanted to go.

    return 'ON';

requires 'ON' to be in string quotes, but for the rest this does what it should, no rule and only a single set of Items.

Cool :slight_smile:

1 Like

Comment; note that this does not ‘ignore’ OFF, but transforms everything to ON. For the benefit of later readers, beware of using this technique with sensors (e… zwave) that may periodically report “still off” when inactive.

1 Like

Fair point. I wonder if it’s possible not to send a return code at all (if getting an OFF command)

I think we’ve played with trying to get no-action return from transforms before e.g. to filter out glitchy ridiculous sensor values. Don’t think there’s a way to do it apart from provoking an error - return null or return something that will not ‘fit’ the Item type.