[SOLVED] Motion sensor timer on 2 way lighting

[crumpy10 (Simon Crump)]

Hi everyone,
I am working on a presence sensor that is based on a D1mini board with a PIR flashed with Tasmota. I have that part working fine and its sending MQTT messages ON,OFF etc… I can see this on MQTTfx.

Now what I am trying to do is have only an off timer. I am not trying to sense movement and switch a light ON. ie when the kids go down the hallway and leave the light on, after a pre determined time it turns the light OFF.

My lighting setup is a bit complex, detailed in this thread -:

How does OH know the state of a switch?

“An exercise for the reader” Seeing as you have multiple similar Items, this is an ideal case for deploying ‘Associated Items’ naming techniques with the vers 2.3 on Group rule triggers. This allows all related Items to share one set of rules. Use a scheme to name Items like myLight, myLight_sonoff, hisLight, hisLight_sonoff. Group these items, e.g. gLights , gSonoffs This will allow rules to work out the name of an associated Item from the name of the one it’s working with. Rules can then…

and I am trying to add the timer in this thread-:

[Deprecated] Design Pattern: Motion Sensor Timer

There is now a rule template in the marketplace that implements this. See below for instructions on how to set it up for this DP. Please see Design Pattern: What is a Design Pattern and How Do I Use Them for details on how to use DPs. Problem Statement Many motion detectors only report ON when they detect motion but do not send a corresponding OFF after no motion has been detected after a period of time. In addition, often one wants to control a device like a light for a certain period after …

So far I have tried my best to adapt this motion sensor example to my needs, but I am getting very lost. I am looking to trigger the timer when the D1mini sends an ON command and then when the timer is up, send a command to the 2 way light rule to turn the light off. Is there something special I have to do to trigger another rule from the timer rule?

Heres my items

//D1 Mini boards used with PIR's for presence detection

Switch D1mini_pir1 <pir> (gPresent) { mqtt=">[broker:cmnd/d1mini_pir1/POWER1:command:*:default],<[broker:d1mini_pir1:state:default]", autoupdate="false" }

Rules

var Timer occupancyTimer = null
val int timeoutMinutes = 1 // choose an appropriate value

rule "D1mini_pir1 received ON"
when
    Item D1mini_pir1 received update ON
then
    if(occupancyTimer === null) {
        occupancyTimer = createTimer(now.plusMinutes(timeoutMinutes ), [|
            Sonoff4ch_2Channel5.sendCommand(OFF)
            occupancyTimer = null
        ])
    }
    else {
        occupancyTimer.reschedule(now.plusMinutes(timeoutMinutes ))
    }
end

I am struggling to understand the flow of events from when the broker gets the ON from the PIR on MQTT.

Hope someone can point me in the right direction away from confusion.

Thanks

Crumpy

[rlkoshak (Rich Koshak)]

@crumpy10

Is there something special I have to do to trigger another rule from the timer rule?

The only way to trigger another Rule is to sendCommand or postUpdate (depending on the trigger) to an Item that triggers the other Rule.

[crumpy10 (Simon Crump)]

Thanks Rich,

So, is what I have done so far correct? When the D1mini sends an ON via MQTT, the rule above creates a timer and when expired it sends an OFF command to the Sonoff4ch_2Channel5. This in itself has a rule setup depending on the state of the physical light.

Now are we saying that instead of sending the command to Sonoff4ch_2Channel5, I need to send it to a sort of virtual switch in the D1mini items file? How do I then trigger the 2 way lighting rule from there to switch the light off?

Sorry for all the questions, I am pretty new at all this and trying to make head or tail of how it all works together.

Cheers
Crumpy

[rossko57]

That looks sensible, except that your text describes ‘triggered on command’ and the rule triggers from update.

[crumpy10 (Simon Crump)]

@crumpy10

rule “D1mini_pir1 received ON” when Item D1mini_pir1 received update ON then

Ah, thanks Rossko. So it should read-:

rule "D1mini_pir1 received ON"
when
    Item D1mini_pir1 received command ON
then

Is that what you mean?

[rossko57]

@crumpy10

Now are we saying that instead of sending the command to Sonoff4ch_2Channel5, I need to send it to a sort of virtual switch in the D1mini items file? How do I then trigger the 2 way lighting rule from there to switch the light off?

I’m not sure what you’re thinking there. The timing rule in this thread will send an OFF command after a time to Sonoff_channel Item, the rule in your other thread will see that command and act on it.

The part that isn’t visible to us is how the light gets switched ON in the first place, but maybe that’s a manual action.

[crumpy10 (Simon Crump)]

@rossko57

The part that isn’t visible to us is how the light gets switched ON in the first place, but maybe that’s a manual action.

Correct, if the kids turn the light on or anyone leaves a light on and the presence sensor detects nobody in the hall then the system turns the light off.
I am not after an auto on and off light.
Cheers

[rossko57]

It’s worth understanding that your timer is going to kicking even if the light is OFF to start with.
That may be fine, but it does allow a situation where the light is manually turned ON and an already running timer turns the light OFF again in less than the usual time.
Whether that’s a problem is probably about how likely a “light user” is to trip your motion sensor.

One way to deal with that in this case would be to start/schedule the timer whenever the light goes ON.

That would also take care of somehow turning light ON and never tripping motion sensor at all, which would never start the existing timer.
You could add a “light changed to on” trigger to the rule here.

[crumpy10 (Simon Crump)]

@rossko57

It’s worth understanding that your timer is going to kicking even if the light is OFF to start with.

Yes I see what you mean, I dont think thats a problem.

@rossko57

but it does allow a situation where the light is manually turned ON and an already running timer turns the light OFF again in less than the usual time.

But doesnt the timer get re-scheduled if the PIR sends another ON command? Is that not how the else part of the rule works?

@rossko57

Whether that’s a problem is probably about how likely a “light user” is to trip your motion sensor.

Anyone entering the hallway is going to be sensed, the sensor is mounted in an spare LED down light fitting.

@rossko57

You could add a “light changed to on” trigger to the rule here

Yes, thats what I thought about to start with but ruled it out as if say someone is cleaning in the hallway, I would want the light to stay on and not turn off on the timer. Hence the reschedule timer bit…

So if I change that update to command part, will the “Sonoff4ch_2Channel5.sendCommand(OFF)” part of the rule work in conjunction with the other rule I have for 2 way lighting? ie when this command is sent to “Sonoff4ch_2Channel5” will it abide by the other rule that I have set for that light??

Sorry, Jeez I am getting so confused…

Cheers

Crumpy

[rossko57]

@crumpy10

But doesnt the timer get re-scheduled if the PIR sends another ON command?

Yes, absolutely. All I was trying to point out, it does all rely on consistent triggering of your PIR. I you’re confident that no-one could avoid it, that’s fine.

@crumpy10

will the “Sonoff4ch_2Channel5.sendCommand(OFF)” part of the rule work in conjunction with the other rule I have for 2 way lighting?

There’s two parts to rules - when, the trigger conditions, listening to events; and the then part, the “doing” code, making things happen.

If one of the things you make happen is to send a command to an Item, any and all rules listening for a command to that item will get triggered next.

This is the “bus” you may have seen mentioned, every command (whatever its source) gets put on the bus for every rule to see.

[crumpy10 (Simon Crump)]

Thats a great explanation, Thanks. That makes sense.

I think if I change that line in the rules file when I get home then it should work as I want it to…

Will update later…
Cheers

[rossko57]

I’m not sure you need to change the trigger at all. You mentioned command trigger while coding for update, is all. Which you really want depends on how your PIR signal gets into openHAB, how you’ve configured your Item/MQTT?

Sensor device don’t usually generate commends, a binding normally updates the Item, causing its state to change (or maybe stay the same). Such updates go on that bus, of course

[crumpy10 (Simon Crump)]

OK, I thought I was getting somewhere when I found I had an _ instead of an / but still I cant figure it out.

So heres my items file-:

//D1 Mini boards used with PIR's for presence detection

Switch D1mini_pir1 <pir> (gPresent) { mqtt="<[broker:d1mini/pir1:state:default]" ,autoupdate="false"}

and heres my detector rules-:

var Timer occupancyTimer = null
val int timeoutMinutes = 1 // choose an appropriate value

rule "D1mini_pir1 received ON"
when
    Item D1mini_pir1 received update ON
then
    if(occupancyTimer === null) {
        occupancyTimer = createTimer(now.plusMinutes(timeoutMinutes ), [|
            Sonoff4ch_2Channel5.sendCommand(OFF)
            occupancyTimer = null
        ])
    }
    else {
        occupancyTimer.reschedule(now.plusMinutes(timeoutMinutes ))
    }
end

and here is what I am sending from the D1mini when the PIR is triggered-:

You can see from the bottom up. arduino/channel5 is the light being manually turned on. Then the PIR triggers ON (RESULT and POWER), then the PIR switches OFF (RESULT and POWER again).

I feel like I have the When part of the rule wrong but I cant see it! Its like the rule is not getting the received update.

Any pointers would be greatly appreciated.\

Cheers

Crumpy

[vzorglub (Vincent Regaud)]

@crumpy10

Its like the rule is not getting the received update.

That’s because your topics are incorrect.
Also you don’t need the autoupdate option because you are not seding commands to the item.

Switch D1mini_pir1 <pir> (gPresent) { mqtt="<[broker:stat/d1mini/pir1/RESULT:state:default]" }

[crumpy10 (Simon Crump)]

@vzorglub

That’s because your topics are incorrect.
Also you don’t need the autoupdate option because you are not seding commands to the item.

Switch D1mini_pir1 <pir> (gPresent) { mqtt="<[broker:stat/d1mini/pir1/RESULT:state:default]" }

Thanks Vincent, that makes sense as I am seeing the result being sent on the MQTT message but I now get this error in the log-:

2018-12-08 09:35:43.125 [WARN ] [b.core.events.EventPublisherDelegate] - given new state is NULL, couldn't post update for 'D1mini_pir1'

Does the When part of the rule need to be changed to RESULT instead of update ?? I am struggling to see the flow of how it all works at the moment but I dare say once it works it will be obvious!

[vzorglub (Vincent Regaud)]

@crumpy10

I now get this error in the log-:

2018-12-08 09:35:43.125 [WARN ] [b.core.events.EventPublisherDelegate] - given new state is NULL, couldn't post update for 'D1mini_pir1'

When do you see this error in the log?
Could you show both logs for the same event, please?

Change your rule to:

rule "D1mini_pir1 received ON"
when
    Item D1mini_pir1 received update ON
then
    logInfo("PIR1","RECEIVED UPDATE ON")
    if(occupancyTimer === null) {
        logInfo("PIR1","Creating Timer")
        occupancyTimer = createTimer(now.plusMinutes(timeoutMinutes ), [ |
            Sonoff4ch_2Channel5.sendCommand(OFF)
            occupancyTimer = null
            logInfo("PIR1","Timer Expired")
        ])
    }
    else {
        occupancyTimer.reschedule(now.plusMinutes(timeoutMinutes ))
        logInfo("PIR1","Timer Rescheduled")
    }
end

[crumpy10 (Simon Crump)]

@vzorglub

When do you see this error in the log?

Every time the D1mini PIR sends an ON or OFF through MQTT

@vzorglub

Could you show both logs for the same event, please?

Which other log do you mean? Sorry I am really quite new at all this and learning rapidly…

I have changed the rule with the logInfo extra bits, is this the other log you mean? How do I see that?

Cheers

[vzorglub (Vincent Regaud)]

events.log and openhab.log

[vzorglub (Vincent Regaud)]

And I made a mistake:
POWER not RESULT

Switch D1mini_pir1 <pir> (gPresent) { mqtt="<[broker:stat/d1mini/pir1/POWER:state:default]" }

[crumpy10 (Simon Crump)]

I just tried that before I saw your post! I see where I made the mistake now, in my first items file I used POWER1 instead of POWER… Doh…

Thanks for your help on this @vzorglub and @rossko57 Your legends, no more kids leaving the lights on…cheaper power bills here we come.

Once I get the D1mini in its full time new home of an old LED downlight case with a specific adapter board for the PIR I will post a full run down on how it was all made and got going.

Cheers

Crumpy