That was my intent. 
(I had local control disabled and remote control enabled because I used to need to turn the dimmer off and on via Hubitat when the dimmer would flake out at low loads and just turn the load off like it used to on old firmware ā sometimes I could get away with doing that instead of using the air gap. If the level was lower, I definitely didnāt do it, but Iām not sure if maybe that somehow got disabled and my āsceneā tap down to turn off the lights became a āreally turn off the loadā kind of thing and then the Hue bulbs freaked out on the ramp back up, even though that behavior never stopped until I tried a few more thingsā¦)
Do you have your ramp rate / dimming speed set to 0? This makes the dimmer act like an ON / OFF unless the level is adjusted via z-wave.
Edit: I think I saw something similar but it was with an Incandescent bulb after the flashing of the Holtek firmware finished. It was like this:
Iāve tried to set all those parameters to 0 (physical or digital, on/off or dimming) both for this reason and the fact that even as a ārealā dimmer I find 3s or whatever the default is unbearbly slow. 
That video of the incandescent is about what I saw with the Hue bulbs. If I can get it to happen again (but I almost hope not), I can try replacing it with an incandescent to see if it still happens. I almost did when this happened just to see if it would help get rid of the problem, but I couldnāt find my emergency backup incandescent at that momentā¦haha.
Correct. I am using it for a smart bulb and keeping the switch at 99% with disable local control. The switch is never controlled via remote either (itās hidden from all panels/interfaces).
Edit: no dim speed set because I never dim I guess. It was not during a āturn the switch onā operation, it was during a ācommand the light onā operation if I remember correctly. BUT Iāll try the alternative (the fixture was pretty cheap) and see if I can replicate the issue.
Just happened this morning when a Hue group dimmed from 100% to 60% via an automation.
When the bulbs start flashing the power needs to be removed for at least 1 minute either by dimmer power off or air gap. That means the flashing is being done from within the Hue ecosystem. The power loss and recovery must confuse the Hue hub in some fashion as all the lights in the group are flashing in sync.
Once recovered, I ran a test to dim the Hue group from 100 to 60. I ran the test 3 times. Every time the lights failed to hold at 60%. The failure mode was to flicker and go on to 100% (the default of the Hue bulbs). Once they started the rhythmic flash for 1-2 seconds, but recovered to the 100% state. In those 3 tests the lights did not go to continuous flash.
The physical dimmer is set to 99 and all ramp rates are set to 0. I would suggest that you force these values and lock them when choosing ādisable local controlā to prevent at least some end user issues.
I understand that electronic switches and dimmers especially can be tricky to design. Implementing a quasi-relay in a dimmer must be especially difficult. Even Lutron has multiple devices to cover multiple load scenarios. And I believe they specifically recommend against using dimmers as quasi relays.
Iād go so far as to suggest you consider making a completely separate device to control smart bulbs. Make the smart bulb controller with the form of your dimmer but with the relay of your switch.
Bill.d, to confirm, you are commanding the hue lights to dim to 60%, NOT the switch, correct? Meaning there is zero history for the switch at that time? Seems silly even asking, but have to lol.
Iām worried that this is a new development with firmware 1.44. Can @bill.d @BertABCD1234 @kreene1987 verify which firmware versions you have seen this on?
Also, you guys are all flashing both the otz and bin files right?
I have only seen it on 1.44, and Iāve updated both the .OTZ and .BIN targets (I swear, I even though Iām on Hubitat 
ā¦ I have a C-3 with a Z-Stick).
Iām on 1.44. Iāve flashed both sets of firmware twice.
@BertABCD1234 I believe you LOL. Iām just making sure I have all my facts straight.
@BertABCD1234 @bill.d So you didnāt see it in 1.41 or 1.43 right?
1.43 was the first that I tried after 1.35 (original firmware). There were power issues with previous firmware, I believe (but am not sure) that they were more of flicker then off. I donāt remember the flashing.
I didnāt see it with any of the previous updates (I think I tried all the betas?).
Soā¦I know there are storage limitations on the switches, but, what if you made another parameter where you set the bulb type such as LED/Incandescent/whatever and based on that parameter, the min/max values would be proportional. Not sure if Iām making sense. Basically what Iām saying is that because a LED bulb needs much less power as a min/max than an incandescent bulb you could base the min/max on the bulb type selected. So a min of 5 might be suitable for a LED bulb instead of a min of 50.
@EricM_Inovelli how do we update the 2nd bin file using @bcopeland z-wave upload tool? it requires an otz file.
Also, is there an email list we can subscribe to get alerted of when new updates come out?
You canāt update the 2nd file with the z-wave firmware updater app, only the otz in location 1. For the second file you need a z-wave usb stick added as a secondary controller (if on hubitat), then you can update both locations. I use the z-wave.me usb stick that seems to be the cheapest option.
thereās no way around this? the whole point of the updater app is not have to buy a separate stick
Many people seem to have had success with just the otz file, so you may not need to do both
Unfortunately there is no way around this at this time. Our LZW31 has a second MCU because the space on the Z-Wave 500 chip was not sufficient for the features we were adding. Our other devices LZW30, Bulbs, 4-in-1, etc. will not have this issue though and will be fully updateable with the tool.
@bill.d @BertABCD1234 @kreene1987 Have you guys discovered any way to easily/consistently trigger the bulb flashing? I have Hue bulbs and would love to replicate the problem to capture some logging.
Mine is/was on 1.43 when this happened (still is). Iāve tried to replicate but not having any luck!
Will update to 1.44 to see if it happens again.