Flood light control via switch toggle patterns

Devices & Integrations
1

I have a RAB Stealth flood light that is hooked up to a GE switch. This particular light is primarily triggered by motion, but can be set to manual mode by toggling the switch off-on-off-on in < 2 seconds.

Has anyone considered creating a device based off of a Z-Wave switch template that, when turning it on, will send four commands instead of just the one? It’s the only way I can think of to get this light to function consistently in a manual mode with ST.

Thoughts? Things to keep in mind? Is it as simple as starting with the Z-Wave Switch code template?

Thanks,
Justin

2

This same situation has been discussed before. The short answer is you can’t do it in zwave.

Zwave is a mesh network. There’s no forced routing, and no guaranteed sequencing. Send 4 commands in under 3 seconds and you might get off off on on.

Nor can you force the ST cloud to process commands that quickly even if you have nothing else in the network but that one switch.

http://docs.smartthings.com/en/latest/smartapp-developers-guide/scheduling.html

You might have a chance if you had a star network (WiFi, most likely) and you were connected locally (not currently possible in ST). So maybe if you install a WeMo switch and have some kind of macro control. (Not using ST.)

It’s just not the kind of control zwave is intended for.

3

Notwithstanding what @JDRoberts says, because he’s most likely correct, you might be able to do this with a custom device type with a custom command. It’s not completely obvious what the failure rate might be, or that it would necessarily fail at all. Worth a try. It would be pretty obvious how to modify the standard device type to create this extra command. The extra command would handle the timing (something done in other z-wave device types).

In the metadata definition, just after all of the capabilities are listed, you would add,

  command "onoffonoff"

or some such. Then you’d add the command definition for “onoffonoff” by simply using the same code used to send “on” and to send “off”, with a delay of a few hundred milliseconds. Worth a shot…

1 Like
4

BTW, from an engineering standpoint the simplest solution is probably to install a second light that is not motion activated. Then just turn on the one you want and turn off the other one.

edited to add As @bravenel says, there’s no harm in trying a software solution first if you like. You might get lucky. :wink:

5

Scheduling has to do with SmartApps, not device types. You can specify delays in device types of 100 ms, or 300 ms, or whatever and that has nothing to do with scheduling or its limitations. I get the impression that a device type executes completely once it’s invoked. That’s not documented that I know of.

1 Like
6

Thanks for the correction on the device type. I’m still not used to the concept of device handlers that invent capabilities not provided by the manufacturer. In my world that stuff was always done in the app level.

If I had to, though, I’d put ten bucks down that the 4 command sequence will not be delivered reliably. But doesn’t hurt to try.

7

I have a custom device type for a dimmer that sets a level and then turns off the light right away (100 ms). It has never failed that I know of. Failure would be the light being on after that (off, setLevel; instead of setLevel, off). Going to on off on off is clearly more challenging.

Define “reliably” :grinning:

8

Yeah, I’m not betting on a two command sequence here, just the four. :wink:

My own definition of “reliably” for a residential lighting control would be works 999 times out of 1,000.

9

Laughing… 999 out of 1000 sort of rules ST out don’t you think?

3 Likes
10

Yeah a custom device type is what I was leaning towards. I’ll look into this. I’ll post back with the results.

Challenge accepted!

1 Like
11

Ok. So far, in my limited testing, it works great. And by ‘limited’ I mean I probably tried the sequence of 4 commands about 5 times.

So assuming it remains consistent, I’ll move forward with this approach.

Can I define a third state for the ‘switch’ attribute? E.g. ‘Manual’?

I have another question, but thoughts on the above will determine how I phrase it.

Thanks all for the input so far.

12

Cool. I’ll be surprised if it works reliably, but “all home automation is local,” if it works for you, great!

edited to add (I removed the cloud mention, @bravenel below is correct that likely won’t matter.)

One more caveat…usually with mesh, the more devices you add, the better everything works, because there are more alternative routing paths.

In this case, because you need such precise sequencing in such a short period of time, adding more zwave devices might interrupt your sequence.

Even assuming the hub releases the commands in the right order, traffic coming back the other way might tie up a repeater, delaying delivery.

So just something to be aware of over time. This particular switch is more likely to be affected by other traffic than most.

13

No, you won’t be able to add a third state in the way you suggest for a “switch”. You can add a custom attribute to the device type, and a method to set it’s state though. What do you need the attribute for?

14

I don’t think “load on the cloud” will have anything to do with whether it works or not. The cloud load issues you refer to are specific to scheduling, and this has nothing to do with that. Many z-wave device types have built in delays of up to 5000 ms, and they all work just fine (well, to the extent that ST works “just fine”). Your original worry about the mesh network lack of sequencing would be the most likely source of failure, but even that can be fought to some extent by managing the delay in the device type. With a small z-wave network, it’s very unlikely for routing differences to eat up say 250 ms.

The odds on your bet have shifted with Justin’s initial success!! :grinning:

15

Very true! Let’s see how it’s working in a month, then I’ll pay up. :beer: :pizza:

16

So here are my ideas:

  1. Modify the on() method so that it calls the off-on-off-on sequence instead of a simple on().

Pros:

  • can be used with the built in ST sunrise/sunset Hello Home actions

Cons:

  • can’t set it back to automatic mode through the app. There’d be no simple on() method anymore. Unless I coded the device page to switch between the three modes.
  1. add a custom command as Bruce suggested (currently what I have) and create a SmartApp that knows to call the offonoffon() method at sunset. Could also add a separate attribute to track the state: on/off/manual. Could transition from on->manual->off.

Pros:

  • more explicit
  • can more easily turn the light on/off or manual mode.

Cons:

  • requires a separate SmartApp that is aware of the custom command.
  • separate from the way I manage my other lights at sunrise/sunset.

Any input would be appreciated!

17

What I ended up doing was getting an Aeon Micro Switch, and wired it behind the floodlight. I wired it so that the Micro switch and the motion sensor could both trigger the light to turn on. Granted if there is motion I cannot turn the light off, but this is the behavior that I want anyways. It is great for my backdoor with no light switch by the door. When the door opens the door sensor triggers the floodlight to immediately go on.

2 Likes
18

One more idea for you to think about: you could add a virtual switch, which can be turned on by sunrise/sunset Hello Home actions. Then your separate SmartApp that knows about the custom command subscribes to the virtual switch, and then does what you want. Sort of a mix of the Pros of your two choices, with only the one Con of a separate SmartApp.

I think anyway you slice it you are into something custom; you just have to decide what works right for your use case.

1 Like