Lighting timer for 'near' proximity to solve motion detection latency issues

#1

I have a number of existing pistons that use what seems to be the canonical timing pattern for lighting automations, ie:

  1. If motion detected, turn on
  2. else, wait n minutes, turn off

The problem I have is that the reaction time is poor (3-4 seconds, sometimes up to 20). I use mostly Smartthings own motion sensors - so one question is whether there’s anything I’m missing that would solve the latency issue.

However, if not, my idea is to use nearby motion sensors to trigger lighting as one approaches a room, but on a short timer, and then lengthen the timeout if you actually enter the room. So basically:

  1. Motion detected in hallway, turn on kitchen light for 30 seconds
  2. If no motion detected in Kitchen within that time, turn kitchen off
  3. Motion detected in kitchen, keep kitchen light on for at least 5 minutes

The way timers work in WebCore is something I’m not totally sure about. Should this be one piston or two? Any particular hints about how to set this up?

#2

I came up with this:

image
image.png1178×1110 111 KB

The top motion sensor is the one outside the room, and the bottom sensor is the one inside. WDYT?

#3

Ok, this doesn’t quite work because on leaving the kitchen, you trigger the hallway sensor again, and so the piston triggers like this:

  1. hallway motion and occupied = false: turn kitchen on
  2. kitchen motion: turn kitchen on and set occupied = true
  3. hallway motion ends: no action because occupied = true

then as you leave…

  1. hallway motion: no action because occupied = true
  2. kitchen motion ends: set up timer to turn kitchen off in 10 mins
  3. hallway motion ends: no action BUT TIMER CANCELLED

I think the issue is the task cancellation policy…

#4

OK, this seems to work:

image
image.png1178×1269 131 KB

So basically set a task cancellation policy of ‘never’ and explicitly cancel pending tasks when I want the lights to stay on.

#5

Is your original reaction time slow to turn on, turn off, or both?

#6

Hi! Slow to turn on.

#7

There may be some devices known for delays, but SmartThings sensors should not be one of them…

I am curious… Do you have the same triggers in multiple pistons?

For example, ignoring the syntax for a moment:
How many pistons have a trigger next to Sensor 5’s motion?
How many pistons have a trigger next to Sensor 7’s motion?

Sample syntax to ignore:
Changes, is, was, stays, etc…

#8

Not that many… I have 19 pistons in total, 5 that are motion/lighting related. And I live in a fairly small 2 bed apartment, so it’s not really a range issue. Might it depend on the version of the ST hub that I have?

Prior to today’s experiments, most motion sensors featured in one piston for the lighting for that room, and also in the intruder alarm piston. In moving to the pattern above the motion sensors are involved in other rooms’ pistons, so it’s more. But still < 5 pistons per sensor I guess.

#9

Everyone is different here, but here is my advice…

It’s not always possible, but ideally, any event should only trigger a single piston.

So, for example, I want a maximum of:

  • one piston to execute when Sensor5’s motion changes
  • one piston to execute when Sensor5’s temperature changes
  • one piston to execute when Sensor5’s switch changes
    (I made this last one up, but you get the idea)

I may have dozens of pistons checking the status from that device (as normal conditions)… but when the device changes, I only want a single piston reacting.

This method makes a huge impact on speed and reliability.

Likewise… when you combine a bunch of different triggers in the same piston, then each event has to process all of that extra stuff.

… and of course, processing extra stuff means it will take longer to process the important stuff.

If I had to make a guess, it sounds like you are writing code with the intention of consolidation or organization, but you are (unintentionally) making your SmartHome work overtime.

Another way to say all of this… If you have 5 pistons all trying to execute at the instant the motion sensor changes, and if each piston takes a couple of seconds to process, then I would expect that you will occasionally be waiting 10-20 seconds for the last one to finish.

Tied in with this is the fact that motion sensors are known to be some of the chattiest of devices. You are literally spamming your SmartHome network.

… if I shifted to a philosophical stance for a moment, I’d have to mention that your latest piston only adds more chatter to your home network.

#10

hm, wow, ok. food for thought.

So would you have a piston for each sensor, rather than one for each use case?

And for motion sensors, should I be triggering based on ‘changes’ or ‘is’. I’ve seen lots of both in the forum and both seem to work.

#11

For the most part, yes. My bathroom piston is structured around the bathroom’s motion sensor trigger… The living room piston is centered around the LR motion trigger…

I usually try to avoid the following, but there may be exceptions like:
Only do something if three sensors are inactive...
If I really must combine triggers in one piston, I will make sure the code is streamlined, and the commands are quick and simple. (I want that piston to complete in it’s entirety in under a second)

Plus, I will put in zero extra triggers in that piston. (it’s already bad enough, LOL)

Personally, I like the precise moment of triggers (changes to X) instead of vague conditions (is X)… but there are uses for both.