Automating lights *elegantly*

[Pgordon]

I\'m currently in the process of trying to write some responses to more elegantly control the management of lights being turned off in \"empty\" rooms.

The only inputs I have to determine room occupancy status are a CBUS wall switch and a PIR connected to a comfort zone. I can deduce if the CBUS switch in the room is operated then the room is occupied (at that point), but it\'s no use for determining on-going occupancy status, so for the purpose of this exercise I\'m pretty much ignoring that, and relying solely on the PIR.

In most (but not all) cases, I don\'t want lights ON to be automated based on motion; I prefer to have the occupant manually switch the light on if they want it. This discussion is specifically for the scenario where only the OFF is automated...

I don\'t want to rely on the users remembering to turn lights off when they leave the room, I want that to happen based on no motion observed for a set period.

However, there are cases where the user is just being very still in the room, so not being observed by the PIR, so I must allow for this... The lights OFF mechanism should occur regardless of time of day/outside light levels etc.

My approach currently, is as per the following pseudo code:

Attach response to PIR OFF event on the zone, response does:
Start timer 20 minutes
on timer expiry after 20 mins:
    retrieve the current light dim level by reading the value of the CBUS mapped counter
    store current light dim level by copying CBUS mapped counter to another counter
    divide current dim level by 2
    set CBUS counter to new value, thus dimming light to half whatever it was
    start timer again for 10 mins (using same timer currently)
    on timer expiry after 10 more minutes:
        Set CBUS mapped counter value to zero, thus turning light off

This should produce the effect whereby so long as motion is observed nothing happens, but after 20 mins of no movement the light level halves... this allows the user (if one is there) to know the system is managing the light OFF function... then after 10 more minutes with no motion the light goes off.. so far so good.

What I now need to add into the mix is the ability for the user, once they are aware of the light level dimming by half, to \"do something\" to say \"hey, I\'m still here, don\'t mess with my light!\" - by moving enough to be seen by the PIR... this is the bit I\'m thinking about now...

I\'m thinking this should be via a response on the PIR ON event... the response needs to be aware of the current state of the above actions... so I think the best way would be to check if the timer is running; if not, do nothing, if it is, then restore the light level to the original by copying the counter value back from the one I copied to in the first response.

A couple of things I\'m not 100% sure of, & would appreciate insight:

- I don\'t think it should be necessary in my ON response to stop the timer; when the PIR is triggered ON, very shortly after it will go OFF, thus running the OFF response, which will restart the timer with the first 20 minute value - yes?

- Every time the OFF response is triggered by the PIR, following motion having been observed, the OFF response will run, and this will always restart the timer from the full 20 minutes, thus so long as motion is observed before the timer expires it will always be reset back to 20 mins and never actually expire - yes?

- I don\'t think it should matter that I reuse the same timer for both countdowns in this response (obviously it\'s not used in any other response!); it\'s only ever loaded with 10 minutes after the 20 minute initial countdown has expired, and if motion is seen in the 10 minute countdown, again the ON response restores the light level, followed immediately by the OFF response which restarts the timer from 20 minutes... - yes?


Thoughts? - is my approach sound? - anyone see any \"gotchas\" I haven\'t thought about?

Cheers

Paul G.

[Pgordon]

Anyone got any thoughts about the logic of just taking the existing dim level and halving it? - works fine when lights are starting off at a fairly high level - which to be fair is most often the case - but there could be occasions when the light is already dimmed pretty low... if it starts off at only 10% dim, then halving that to 5% dim may - depending on the light(s) in question - not work very well... we all know that the dimming curve at very low levels can be inconsistent, some bulbs just won\'t reliably dim lower than 10% without either flickering or actually going off...

to cater for this (albeit probably rare) use case, what to do instead? - flash the light briefly? - do the reverse and actually increase the light level - and should that be temporarily or permanently?

Hmm....

 

[slychiu]

This seems like a very elegant solution and is an excellent example of how Comfort can do practical and useful automation tasks beyond switching things on and off.Switching off the lights when someone is sitting still is quite irritating.

- I don\'t think it should be necessary in my ON response to stop the timer; when the PIR is triggered ON, very shortly after it will go OFF, thus running the OFF response, which will restart the timer with the first 20 minute value - yes?

You are correct. However if you have a lot of people in the room like in a party, there may be constant motion and it may be possible although unlikely,  the PIR remains on and the timer keeps running down until the lights switch off

- Every time the OFF response is triggered by the PIR, following motion having been observed, the OFF response will run, and this will always restart the timer from the full 20 minutes, thus so long as motion is observed before the timer expires it will always be reset back to 20 mins and never actually expire - yes?

Yes, except for what I mentioned above

- I don\'t think it should matter that I reuse the same timer for both countdowns in this response (obviously it\'s not used in any other response!); it\'s only ever loaded with 10 minutes after the 20 minute initial countdown has expired, and if motion is seen in the 10 minute countdown, again the ON response restores the light level, followed immediately by the OFF response which restarts the timer from 20 minutes... - yes?

You can use the same timer since it when you start it, it is overriding the previous timer response

I\'m thinking this should be via a response on the PIR ON event... the response needs to be aware of the current state of the above actions... so I think the best way would be to check if the timer is running; if not, do nothing, if it is, then restore the light level to the original by copying the counter value back from the one I copied to in the first response.

Correct, you can check if the timer is running
Note that the latest Comfigurator has a feature  which will be useful for you for testing this. Each Timer has a Show Status button which shows the remaining time for the timer if it is still  running.

Anyone got any thoughts about the logic of just taking the existing dim level and halving it? - works fine when lights are starting off at a fairly high level - which to be fair is most often the case - but there could be occasions when the light is already dimmed pretty low... if it starts off at only 10% dim, then halving that to 5% dim may - depending on the light(s) in question - not work very well... we all know that the dimming curve at very low levels can be inconsistent, some bulbs just won\'t reliably dim lower than 10% without either flickering or actually going off...to cater for this (albeit probably rare) use case, what to do instead? - flash the light briefly? - do the reverse and actually increase the light level - and should that be temporarily or permanently?

You can also play a reminder message on the keypad saying the lights will be switched off if you dont move

[Pgordon]

Thanks Chiu.

Good point about the constant motion scenario... I think most of the rooms I need to implement this in are fairly low traffic ones though, bedrooms & bathrooms mostly, so I don\'t think it should be an issue, although certainly something to bear in mind & keep an eye out for.

One thing that I thought of... although thinking it through, I\'m not sure if it\'s a \'problem\' per se...

by using the same timer for both countdowns, when the ON response checks for timer running, and finds that it is, it cannot determine *which* timer instance it is; - the first 20 minutes one, or the second 10 minutes one... if it\'s still in the first 20 minute countdown (and thus hasn\'t yet stored & changed the dim level), the logic will still go & retrieve the stored dim level from the 2nd counter and restore it to the first counter, thus returning the light to the stored brightness.. even though the light hasn\'t yet been dimmed by half...

Since I only store the current dim level upon expiry of that first 20 minute period, I wonder if there\'s a possibility that this could result in the light changing dim level when not required... if the 2nd counter has a value from a previous instance of these responses running? the behaviour could I guess vary depending on whether the wall switch is in view of the PIR... thinking here of a room being entered for the first time...

- light is off, no timers are running, room unoccupied
- person enters the room, is seen by PIR, ON response runs
- ON response checks timer, not yet running, does nothing
- moments later, OFF response runs & starts 20 minute timer..
- occupant moves & is seen by PIR, so the ON response runs again...
- On response tests timer... now it IS running, so it copies counter value back from the copy to the mapped CBUS counter
- this could result in light level changing? - counter 2 value is unknown at this point?

Make sense?

Perhaps I could avoid this by either using separate timers, or perhaps by storing the current dim level every time the OFF response runs, not only after the 20 minute timer has expired... thus the ON response would only ever \'change\' the dim level to exactly what it already is, thus no effective change in the room..

This currently is the actual OFF response code:

Wait 1200 Seconds Using AAABedLight ! Wait 20 minutes
Get Counter CBUSAAAsLight ! Get the Level of AAA\'s light
Set AAALightMemory ! Store AAA\'s bedroom light level before changing it
Divide Immediate 2 ! Divide AAA\'s current light level in half
Set CBUSAAAsLight ! Dim AAA\'s light to half its current brightness
Wait 600 Seconds Using AAABedLight ! Wait another 10 minutes
Set CBUSAAAsLight = 0 ! Turn AAA\'s light off

And this is the ON response code:

If Timer AAABedLight <> 0 Then ! If the timer IS running...
    Copy Counter AAALightMemory To CBUSAAAsLight ! Restore AAA\'s light to previously saved level
End If

I think that if perhaps I move the first 3 lines of the OFF response around to:
Get Counter CBUSAAAsLight ! Get the Level of AAA\'s light
Set AAALightMemory ! Store AAA\'s bedroom light level before changing it
Wait 1200 Seconds Using AAABedLight ! Wait 20 minutes


This might be more reliable... there\'s no issue storing the value and then it changing whilst the 20 minute timer is running (by the user setting a new dim level on the switch) because the user going to the switch to alter the light level would be seen by the PIR, which would then store whatever the new dim level was in the PIR OFF response...

Also, when I get to this point:
Set CBUSAAAsLight = 0 ! Turn AAA\'s light off

I should also add:
Set AAALightMemory = 0 ! Set the copied value to zero to match CBUS

The only time this breaks down is if/when the dim level is changed programmatically by another response, or from another switch that is not in view of the PIR... - which now I come to think of it, I do have in a few places... If I turn a light OFF from a switch outside the room, the OFF response for the PIR in the room will not run and will not store the new dim value (0) in the copy counter... I think I need to put some conditionals in the responses to deal with a few other scenarios...

Darn this can get complicated!

TIA

Paul G.

[Ingo]

Paul,

I am doing exactly what you are attempting but using my PAC for all the logic. Works like a charm.

If you are worried about low dim levels, just set your cbus dimmer to min 10% so even if you set the counter to 1% it will dim to only 10%

Ingo

[Pgordon]

[user=436]Ingo[/user] wrote:

Paul,

I am doing exactly what you are attempting but using my PAC for all the logic. Works like a charm.

If you are worried about low dim levels, just set your cbus dimmer to min 10% so even if you set the counter to 1% it will dim to only 10%

Ingo

Yeah, I guess I needn\'t worry about the low dim level... but the question still remains how in that case to best signal to the occupant that in 10 minutes the lights will go off & they will be plunged into darkness!

I have a WISER, so I could just as easily do the logic there... how do you signal motion from the comfort PIR into the CBUS logic engine?

Cheers.

Paul G.

 

[Ingo]

That is a good question. For me the Level/2 is an indication that you need to move a bit so the PIR can detect you. If you don\'t do that then the lights will go out after X amount of minutes. I have 30 minutes and 30 minutes if I remember correctly which is long enough for some movement.

Oh, before I forget. I added my scullery PIR also to the mix. What happens in my house is that I get \'detected\' in the kitchen but then move to the scullery to do whatever. Sometimes I miss the \'Active\' timer and the kitchen lights go off if I doddle around too long away from the kitchen PIR. With the scullery PIR also a trigger it detects me there and restores the kitchen light as well.

Ingo

[slychiu]

I think it is simpler to use 2 timers so you can always check for the 2nd timer which is started after the lights are dimmed to the 1/2 level. That means the level at the end of the 1st time is saved and used when motion is detected. It would not matter if the light is switched off from outside the room

If you go the other way and use PAC, the UCM/Cbus2 can map physical inputs to any group address