Capability Flash (~Blink, ~Strobe)

strobe
blink
capability
flash

(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #1

Continuing the discussion from How to makes lights Flash:

@bravenel just described rather easy way to add “command "flash"” to a Switch or Light DTH.

  • This is one of the occasions I wish we could officially “extend” an existing Capability with new optional Commands and/or Attributes… but… anywayyyyyy

  • Not sure whether this should be called “Blink” or “Flash” (the latter implies a single bright moment of light).

  • I propose: command flash([frequency, duration ] | number of flashes), and automatically canceled by the next on() or off() command.

  • attribute flashing [true,false] (May be difficult to determine if not reported by the hardware. Is this needed?).

  • attribute flashFrequency [numeric] (not sure this is necessary at all).


Discuss?


(Mike Maxwell) #2

Blinking true / false can’t be implemented with Bruce’s delay command software implementation nor a hardware implementation such as I did with the aeon micros. Both would have be based on a local timer which I think would be onerous for this method.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #3

Great feedback, Mike, thanks…

Now that you’ve pointed it out, I guess there are two distinct Capabilities (I’ll split this Topic upon concurrence…):

###1. Blink

  • See Post #1 above.
  • Current SmartThings Platform issues limit implementation. Perhaps only “Flash” (below) is feasible?

###2. Flash (nb: as always, Capability names are subject to open discussion and change)

  • A single (small) set of blinks, not
  • Command flash() or flash( [number of cycles], option: leaveOn <boolean> )
  • Timing of the flashes (and perhaps the number of flashes) is determine by the DTH and/or hardware and usually not configurable except if the DTH developer offers a preference setting.

?


(Mike Maxwell) #4

Blink as a command is ok, what I meant was that the attribute true false implies the state of the thing blinking, which is not returned by the aeon hardware.
You can blink the aeon for like 10 minutes, but once you tell it to start blinking, there’s no report that says it’s blinking or has stopped blinking, if you follow


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #5

Ah … I understand; that attribute may not be particularly important. Do you have an example of the code handy? Can you force stop the blinking prior to the duration set, etc. ?


(Mike Maxwell) #6

It’s a parameter push for a zwave device, the only way to stop it is to issue another param write, but it can be stopped. This part of it is likely to be very device specific.
I’m not even sure you’re wanting to establish defined parameter ranges since these limits will be device specific as well.
A bit like the dimmer set level ramp rate option…


(Bruce) #7

You and I have completely different dictionaries. :grinning:

How can you infer momentariness to either? “Flashing” implies multiple, but flash does not necessary infer single momentary. When you tell someone to flash their headlights, they don’t necessarily do it only once!

To me “blink” is momentary. “Blinking” is obviously repeated. “If you blink you’ll miss it”, implies singular. If you tell someone to blink, they might interpret that to mean once, or repeatedly.

So, the distinction you raise, I assert, is not a distinction at all.

Besides which, talking about new capabilities and what not is pointless since ST ignores all of this as so much blather, if they even read it at all (ben, slagle, are you actually reading any of this?). (Notice the lack of tagging.)

EDITED FURTHER TO ADD:

BTW, if you actually implement this and use Rule Machine to trigger it, it unmistakably comes across as FLASHING. “Honey, why is that light flashing?”


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #8

I totally agree that coming up with the name of the Capability is immediately subject to personal experience. For some basic Capabilities, the name is the biggest hurdle; hence the idea of making the Topic Title of each Suggested Capability something that is open to evolution. In most cases, I hope the name can be settled fairly quickly so that the focus will be on the Commands and Attributes/Events (and PoC implementations using those as add-on/custom Commands and Attributes,

@yaimavaldivia has joined the SmartThings team as “Capability Czar” – OK… I just made up that title and she probably as a range of responsibilities. However, they just deployed a few new Capabilities after about a year of dead-air, so, I have a tiny bit of renewed enthusiasm.

@Kristopher is is enthused and contributing, some recent interest from @Kyse, and, yes … we have @slagle and @jody.albritton listening and advocating – they had an actual meeting on Capabilities on this past Friday. Yah … I know, nothing to write home about.

##Regardless… two things:

  1. I figure it never hurts to introduce a Capability suggestion. Discussion may result in:
    (a) concurrence about the idea and refinement.
    (b) concurrence that it is not needed / redundant / not a “Capability” at all.
    © staleness; lack of Community and/or ST involvement, but just a seed planted for future sprouting perhaps.

  2. For Case (a), even if SmartThings does not participate, maybe there’s a tiny chance that the Community can agree on it as a “Device Type Template” (pending Capability). In other words, DTH developers / editors / users could come to some amount of consensus regarding the custom / ad-hoc Attributes and Commands (all the way down to their names, datatypes, and parameters). Well – this bullet is very wishful thinking, but a fella can dream, no?

Yup … I’m definitely leaning towards “Capability Flash” now. Does that mean a rapidly, ummmm, blinking light is actually “Capability Strobe”? nb: strobe() has precedent as it is already a Command of Capability Alarm. [Insert pointless frustration here that Capabilities don’t have inheritance, so we’re bound to have redundancy…]. Maybe it’s not just precedent … maybe this is a suggestion that a Device that can strobe() (via hardware or software) should claim Capability Alarm; then again, if it can strobe() but not siren() then we have a problem with the Capability contract – exactly the sort of dilemmas that must have kept @jody.albritton and @slagle awake all Friday night. :sleepy:


(Bruce) #9

Whatever… :grinning:


(Scott G) #10

Personally it should be capability Alert since that’s the general use for a flashing bulb. Blink, flash, strobe, etc can be optional parameters and it can be up to the DTH to implement as close to them as they can.

I borrowed it from Hue where “blink” and “breathe” are the options, and it’s how I set it up in any custom zigbee bulb DTH I create. Zigbee bulbs are easy to flash because it’s standard in the hardware since they use it to signal pairing and reset. ZLL bulbs have even more options.

Bonus of these is that they flash full bright to full dim, but return to whatever state they were in prior automatically.


(Bruce) #11

Would you be willing to provide the code for a zigbee bulb to flash? The post below has some clumsy code for flashing a zigbee light. Show us the better code for flash(), and I’ll update that post. See this post:


(Scott G) #12

This is the generic code that should work for any zigbee bulb. It uses the Identify cluster to trigger the bulb’s identify behavior which per the standard is a full bright to full dim cycling that takes about 1 second per cycle. The parameter is the time in seconds to flash, and in my testing you will typically see 1 less flash than the number of seconds. The bulb decrements that value automatically and stops when it hits zero.

You can also send a really high value to start the bulb flashing, then send 0 to stop it immediately if you want it to flash until a secondary action occurs. This could be tied to a open/close sensor for instance for doors left open.

(Note: swapEndianHex() is a custom method and uses an additional method called reverseArray(). Both are commonly found in zigbee device handlers. It reverses the byte order since zigbee is little endian.)

def alert(alertTime = 7) {
    log.debug alertTime
    def payload = swapEndianHex(zigbee.convertToHexString(alertTime,4))
    zigbee.command(0x0003, 0x00, payload)
}

#13

As others have mentioned, “blink” (once) and “breathe” (15 repeated blinks) are both part of the official Zigbee Light Link standard and are considered “effects.”

See 7.4.2 in the following:


(Kevin [Yorkshire UK]) #14

For a one time event there’s maybe ‘pulse’ too with a delay time until it happens and a duration (pulse width time). You could add a repeat ‘n’ times to create a pulse train (flashing) . Blink and flash both have an implication that a light is involved but it may be a sounder/siren or something, or even a PWM waveform.


(Scott G) #15

Hue A19 accept both of these, plus Okay which turns the bulb green for 1 sec then returns it to whatever state it was in. I incorporated all of these into the Enhanced Zigbee Hue DTH.


(Dave) #16

Resurrecting this thread… :slight_smile:
“Is” there a way to blink a light/bulb based on an action/rule/piston?

thanks everyone!


(Jason) #17

Ask in core thread. Pretty sure adrian baked in a software way of doing this. Also if the bulb dth supports it you could use custom commands in core


(codersaur) #18

Would be good to have some kind of Blink capability, I implemented a blink() command in my GreenWave PowerNode device handler. The Indicator capability didn’t seem to fit.