FYI - Lutron updated the Caseta SmartBridge Pro firmware to allow 75 devices.
However, Lutron Caseta switches and dimmers do not natively support the FLASH capability. Thus, in order to make those devices flash, one would need to use something like Rule Machine to create a repeating loop to turn on the light, wait, turn off the light, etc...
I believe higher-end Lutron RadioRA2 devices 'might' support FLASH.
Most bulbs and many switches do not support FLASH, so be careful of what you purchase if this feature is important to you.
Can the looping rule be create to make it look flashing (instant on and off) or it will be like dim slowing on and dim slowly off etc?
I tried experimenting with a Zwave color bulb last night and I didn't have much luck with it but I am still learning so I am sure if something I didn't do right when setting up. It only dimmed on then dimmed off not instant on/off for me when I experiment with it.
I doubt Lutron will remove the telnet port. Plenty of people are using this with expensive home control products like Control4 which can easily be a 6 figure investment. If they take away the capability, there will be a lot of Lutron gear in the trash cans in rich neighborhoods.
The Lutron RadioRa 2 system is designed for integration. Integration capability is one of the main points of the system. This integration capability has trickled down to the Caseta Pro version of the bridge as well.
There's no reason you couldn't create a rule to mimic a flash, at least not if your devices respond fast enough to on/off commands or whatever you'd be using to create the effect. This is actually what Hubitat's native Z-Wave switch/dimmer drivers to do implement their flash command--turning them on and off repeatedly until you perform some action to stop it. There is no leveraging of some "native" capability here.
The flash command isn't a standard command but happens to be a custom command that is widely implemented to such an extent that Hubitat (besides implementing it in a lot of their own drivers) references it in some places like built-in Rule Machine actions. In any case, there's no guarantee as to how it will behave or whether it will be there at all. On some devices, this may indeed look like a fade down and fade up rather than a "sharp" off and on (some Z-Wave dimmers have parameters for how long this should take, but some probably just do whatever their pre-determined to do here; a setLevel(0,0) might make a faster off than off() in some case and setLevel(100,0) a faster on than on(), but this would again depend on the device--definitely something you could play around with).
I second the advice above to consider your selection of lights/switches carefully if this matters to you--or at least be willing to deal with devices that might behave slightly differently from others.
This is interesting... If this is indeed how Hubitat implements their FLASH command (which has only ever worked for me on Z-Wave switches), I am curious why Hubitat has not implement FLASH in the driver for the Lutron Caseta devices, Zigbee bulbs, etc...? Tagging @mike.maxwell and @bravenel for their feedback.
Thanks. Very interesting. Any reason why the Lutron Caseta Switch device drivers don't seem to implement flash? (at least I don't think they do...) I understand that dimmers would be troublesome due to their transition times.
Obviously Mike knows, but to see for yourself, the basis of my comment was this:
...where you can see that flash() basically just repeatedly sends on and off commands to the device at the specified interval.
FWIW, in CoCoHue, I used the Hue API's lselect feature on the bulbs. This is really just an extension of select that is used in the Hue app to quickly blink a bulb for the purpose of identification (e.g., to know which is which if you tap on the device in the Hue mobile app), but the effect it creates is a flash--with the caveat that it stops after 15 cycles. This is an example of how a device might include, to some extent, hardware support for this. (I don't like that it's not indefinite, but considering flash() isn't a standard command and I've documented the behavior, I'm also not too worried about it.)
Thanks! I wonder what this means from a Z-Wave Mesh stability standpoint. If a user selects all of their switches to respond to an HSM alarm event to start flashing, that Z-Wave mesh is going to get very chatty very quickly, eh? Something to consider.
In terms of your question: Lutron Vs. Zwave Vs. Zigbee
I'd like to point out that one of the strongest advantages that Hubitat has over many other Home Automation devices is that HE can easily handle all 3 protocols with ease. (For example, I have around 50+ Zwave devices, 40+ Zigbee, and 5 Lutron). No problem.
The only issue that I see is that you have to have a strong mesh in order to get good results. There is good documentation on how to put together a good mesh. (Zigbee and Zwave). https://docs.hubitat.com/index.php?title=How_to_Build_a_Solid_Zigbee_Mesh https://docs.hubitat.com/index.php?title=How_to_Build_a_Solid_Z-Wave_Mesh
In other words, you must think tactically if you want to mix and match - in other words, try and visualize the path to your hub via zwave or zigbee or both.
As others have mentioned in other posts, the efficacy of Lutron is without comparison. They seem to always work, without any issues. Unfortunately, they are more expensive than other switches, and many don't like the way they look.
In terms of Zwave switches, I personally have Zooz, Leviton, Inovelli, and GE, and they are all "quality" makes. Some of them have special features. For example, the new Inovelli switches have a built in LED, which you can program as to colour and effect. Some switches have a "double tap" feature. This requires some research as to what you really need.
In terms of Zigbee switches the field is somewhat more limited. GE has a line, (and they are coming out shortly with an even better line: Enbrighten Zigbee under the Jasco banner).There are also others as well. Sinope is coming out shortly.
There is also one other alternative, which I haven't yet checked out. It is possible to keep your existing switches, and use a "micro controller" for your smart home control via HE. Such devices are made by RGBGenie, and Aeotec, and Fibaro, and others. They may be Zigbee, or Zwave. Prices are competitive, but this is not a "low cost" option.
Have lots of fun deciding! - It's not an easy decision.
It is very, very bad for it. Basically like hitting refresh on every device included every second (actually worse).
I would have thought they would have not implemented that function to 'save us from ourselves'... Like they do with the custom 'refresh' buttons on some devices (to prevent users from en masse refreshing lots of devices).
Granted, the odds of en masse flashing bulbs regularly would be low - for obvious optical reasons - whereas refresh en masse could definitely happen.
This is the only negative thing I can say about Lutron. Not that is their "fault", but I did have to augment my Z-wave network with some outlets after replacing all my leviton switches. That and price aside, I love the Keypad options, and Pico selection of Lutron Radio RA2. The night stand Picos are prefect for guest room nights stand and we get comments about them with every new visitor.
I have a bunch of Zigbee bulb in my setup. The nice thing about Zigbee is that you can setup group messaging. 20 Zigbee's in a group should be less demanding than 20 Z-wave devices being polled separately.
Of course that changes things up a bit. It doesn't really fit well with your assorted switches, and Zigbee bulbs can be problematic. For example, I have all my Zigbee bulbs on their own hub so the other Zigbee traffic (eg: motion sensors) don't confuse the bulbs. Or you can go with bulbs that are not repeaters like the Sengleds.
It all depends on how you want to implement everything.
If this is indeed how Hubitat implements their FLASH command (which has only ever worked for me on Z-Wave switches), I am curious why Hubitat has not implement FLASH in the driver for the Lutron Caseta devices, Zigbee bulbs, etc...? Tagging 
