Remove the 3’s they don’t belong there. The setParameter command has only two parameters , the parameter number you’re setting and the value you want it set to
I would expect the extra data to be ignored but who knows, maybe it’s screwing with something? 
I would also remove the Refresh since it’s causing unnecessary activity in this case
The Gen3 Blues and Reds (VZMxx and VZWxx) have a ton of more capabilities than the Gen2 Reds (LZWxx). In particular, you can set each individual LED separately (color, intensity, etc.) AND those have separate setting for when the switch is on or off. SO, that would require a minimum of 32 child devices and likely more. So using that method became quite cumbersome and was not scalable. The new method may be less “elegant” but is simple and highly scalable - which is nice when new features are added.
Yeah, I can see that - but I do think those capabilities could have been moved to the child device and exposed in a nicer way. The functionality on the switch is clearly improved, but the driver interaction has taken a step backwards to expose it, is my opinion anyway 
I think that might have done it - I definitely got it in my head I needed to send those 3s, and then I added the refresh action when it wasn’t working properly. I took the 3s and the refresh actions off and so far, it seems to be doing exactly what I expected. Thanks for the tip! I hadn’t done direct parameter setting via RM before so this was a good learning experience.
I’m struggling to see how 32+ child devices for each switch would be a step forwards with all the new functionality (and more being added). IMHO it would be a big mess. Im willing to consider other suggestions, but adding more and more child devices is not the right approach for all this (and future) functionality
That’s fair enough! I figured a single child device might be enough, but if you want to individually address each segment I can see how it would get out of hand.
But that issue aside, I actually spoke too soon here and the issue I was originally seeing persists. After a few hours idle, either in the “on” or “off” position, these switches just don’t execute the LED changes. The new parameters have definitely been stored and received but just don’t “apply” to the lights until something is physically actuated. All my testing and fooling around earlier must not have given them time to go idle first and so what looked like success wasn’t.
For anyone looking, the repro steps for this seem to be:
VZM35-SN, FW 1.04
Hubitat C7, v2.3.6.146
Switch wired with neutral, no aux, set to 3-speed ceiling fan mode
Pair the switch to the hub as normal, using official drivers
Turn the fan on, any speed
Walk away and don’t touch it for 5 or 6 hours
Use Rule Machine to change parameters 95, 96, 97 per the image in my first post
Observe that the LED does not change on the target switch
Actuate the switch via paddle
Observe that the previously sent parameter changes are now in effect
Send additional parameter changes via rule machine and observe that they are reflected immediately, as long as that extended period of time does not elapse first
Being that these are ceiling fan controls and pretty much just run at the same speed 24x7, the switch sees very little use, so this situation comes up quite often.
After a day or two of testing, my idea to swap the refresh command for initialize also doesn’t seem to have worked. There’s just some kind of a bug in the switches, I think, and now I’m just trying to find the workaround in the meantime.
Not sure where bug reports are collected @Eric_Inovelli is there a place it’s best to submit them?
Hi @jon, I’ve reported the issue to an engineer. I will let you know what they say. Since it requires time to let the device sit for several hours it might take a while to get to the bottom of it.
Thank you so much! Appreciate the responsiveness. I feel confident they’ll be able to reproduce with the steps I provided, but understand the timeout will take… time… to analyze. I’ve had the same issue testing my own workarounds. Look forward to hearing more about what you see!
Curious if you can try this workaround:
At the end of the rule send a 1 or 2 second notification to the switch. This can match the color you are trying to set the bar to can be “clear” or whatever.
I will gladly give this a try this weekend! Thanks for the suggestion and stay tuned. Appreciate the idea.
I was just able to replicate the same/similar issue not using rules or scenes; just from the device page. Parameter 95 and 96 wasn’t taking effect at the switch until I press on the up/down paddle. @EricM_Inovelli sent you a video of it. May or may not be related.
Oh good, I’m glad I’m not crazy 
Thanks for chiming in! If videos are helpful I can certainly do the same. I think rule machine itself is far on the outside of this issue; it’s all about the parameter setting itself
Thanks for the info. The engineers are checking it out. If you get a chance please also try the workaround as I am curious if it makes a difference.
I just tried this out and it did work - I sent a quick 2 second fast blink notification to a fan switch that was stuck in a prior LED configuration; it picked up the notification right away and when it ended, the correct LED configuration was displayed.
That’s a helpful workaround since I can probably use that to make these automations work, but I still think it would be nice if it wasn’t necessary
For sure, it is something we will take care of in an update. Just wanted something to help in the meantime.
Not sure if you have had a chance to test this yet, but do you know if firmware 1.05+ fixed this issue?
Edit: it has been fixed according to the update notes, but I just want to make sure.
I haven’t yet - I’ve been watching the changelog thread for the new FW and been a little apprehensive of trying it out as it seems like there are still some kinks. Do you think there’s another version bump coming or should I jump in?