Ideas for reducing latency in turning on multiple lights and turning off others?

Developer Programs Writing SmartApps
, ,
1

I’d like to improve upon my existing “turn on my Philips Hue lights when I enter a room” code. It currently works using an established method described in the docs: its mode is triggered at sunset, after which:

  • motion on any of my sensors turns on the lights in the associated room,
  • a “checkForMotion” routine is then scheduled for that room in x minutes,
  • if motion is detected in the meantime, the routine is then re-scheduled to execute in x minutes, and finally
  • after x minutes without motion, the lights turn off.

The problem is that when I’m sitting at my desk in my office, or reading in a chair in my bedroom, etc., the lights turn off if I haven’t moved around much.

A nice workaround for the problem would be something like this:

  • If motion is detected in one room in which the lights are off, turn on the lights in that room, and turn off the lights in the adjacent room. Don’t schedule checks for motion; lights turn off only when the room is vacated (as established by motion in an adjacent room).

Because I live alone in a 2-bedroom apartment with three adjacent rooms, this should work perfectly. However, because I have multiple connected lights in each room (4 in the living room, and 3 in both the office & bedroom), latency is absolutely awful. Sending the on command to 3-4 lights and immediately sending the off command to 3-4 lights executes extremely poorly, and I can’t suss out why. My logic is of the form:

if (bedroomMotion && !state.bedroomOccupied) {
     bedroomLights.on()
     livingRoomLights.off() 
     state.livingRoomOccupied = false
     state.bedroomOccupied = true
     }

else if (livingRoomMotion && !state.livingRoomOccupied && !state.bedroomOccupied }  {
     livingRoomLights.on()
     officeLights.off()
     state.officeOccupied = false
     state.livingRoomOccupied = true 
     }

else if (livingRoomMotion && !state.livingRoomOccupied && state.bedroomOccupied) {
     livingRoomLights.on()
     bedroomLights.off()
     state.livingRoomOccupied = true
     state.bedroomOccupied = false
     } 

...etc.

I realize that I could just schedule the “lights off” routine using runIn(), but I’m posting this question both because (1) I’d like the transition to be more immediate, and (2) I’d like to understand what’s up with the latency (it’s sometimes on the order of 5-10 seconds, and often select lights will fail to turn on entirely). I can’t believe that evaluating a few conditionals and booleans would have anything to do with it (these should evaluate on the order of ms), and I really can’t imagine the bottleneck being 7 back-to-back Zigbee requests.

2

Others will have to look at your code (I depend on text to speech, and that does not do well with groovy), my first question is whether you have your bulbs connected to a hue bridge or directly to the smart things hub.

In either case, smartthings does not communicate locally with Hue. Your request has to go to the cloud and then come back. So it’s not just a question of X number of zigbee requests in a row. It’s X number of cloud requests.

If your bulbs are connected to a Hue bridge, The first question is do they show the same latency when you issue a command through the native hue app if you use it rather than through SmartThings?

1 Like
3

I understand your lights are Zibgee, but here is a thought from the Z-Wave world . . .
For Zwave dimmers, the default SmartThings Device Handler sends a level command, then waits about 5 seconds, then polls the switch to see if the switch has actually responded to the command and been set to the new level. The reason it waits about 5 seconds seems to be that most ZWave dimmer switches have a ramp-up or ramp-down delay and the SmartThings hub does not want to check the level until after the level command (including ramp-up) has enough time to complete. Maybe something similar is happening in Zigbee.

It seems to me that SmartThings needs the ability to send commands to a bunch of switches in a parallel / asynchronous manner - i.e., send an on / level command for everything in a group, then wait 5 seconds, then check everything. But that’s not how it seems to work. This is particularly annoying if you have a group of 5+ switches as the delays can become significant.

1 Like
4

As to your first question, the bulbs are connected to (and accessed from) the Hue bridge. I actually wasn’t aware that Hue bulbs could be connected to SmartThings otherwise, and will look into doing so.

And as to your second point–local vs. cloud-based communication–I’ve been wondering about the specifics of the cloud implementation. Do you happen to know off-hand of any good resources, or if they even exist? The docs haven’t been really forthcoming, or else I’m just looking in the wrong places. What gets passed back and forth to the cloud? Is it just parameters and return values/commands, or is execution more granular?

I’m using a number of booleans in the code I posted, stored using the state variable. For example, state dot living room occupied. It’s my understanding that state is stored locally, so if that’s the case, and if the entire function executes in the cloud, then I could see latency introduced at each conditional. There’d be the first round trip to access the motion handler function, followed by two round-trips at each conditional to query the various state booleans. This back-and-forth could account for the latency, depending on how cloud-based processing is implemented, especially when combined with back-and-forth requests for on/off commands. (Incidentally, I’m using the booleans to prevent the on/off commands from being issued if I’m currently in the room, the lights are on, and motion is detected. I don’t want the on/off sequence to be issued every 10 seconds.)

You mention X number of cloud requests. Do you mean that a separate, round-trip request is issued for each bulb, in series, rather than just a single bundle of requests issued for all X devices?

The latency is really only problematic in this particular setup. Using the previous routine (as described in the docs, where bulbs shut off in the absence of motion after X minutes) doesn’t introduce much noticeable latency. And as for the native Hue app: no problematic latency there, either, with either individual bulbs of groups of them.

And finally, thanks for your response! I see you all the time on these forums. You’re really helpful.

1 Like
5

Thanks for the insight into z-wave. I’m not positive it’d account for what I’m seeing in this particular problem, because my previous way of handling things involves issuing commands to 3-4 devices simultaneously, and latency (while not nonexistent) is dramatically less than what I’m seeing with the alternative routine.

At the same time, you’ve made me curious about the way the Hue bulbs are handled by ST. If there’s any kind of blocking going on between commands, it’s something I should definitely know about.

Thanks for your response!

6

This is called “groupcasting.” It’s supported in the third-party standards (Z wave and zigbee), but has not yet been implemented by SmartThings. Staff have said that they expect zigbee groupcasting to be implemented sometime in the future, but no specific timeline yet.

Of course, that would not affect the hue bridge, as in that case the communication between the smart things hub and the Phillips bridge is over LAN, not zigbee. The bridge forms its own mini ZLL network with the devices attached to it, they don’t communicate with the SmartThings zigbee network.

7

Use Hue scenes or Hue groups to turn on / adjust multiple bulbs at once.

1 Like
8

Just for clarity, that requires a Hue bridge.

One of the advantages of using a bridge is that it can groupcast to all of its devices, even though SmartThings as yet cannot. :sunglasses:

9

I think he said he had one.

1 Like