I’m using Hubitat rule machine to set my LEDs for status, and seeing some odd behavior specifically on these new blue series fan switches. I set parameters 95, 96, 97 to adjust from blue to red, and turn down the brightness at night. The rule machine rules work properly, but the changes don’t reflect on the switch until after I actually operate the device. So for example, when my home switches from day to night mode, the LEDs change from blue to red and brightness drops from 33 to 1. The settings are applied to the switch but the LEDs don’t change. If I go tap the paddle, the new LED settings are there waiting.
It seems like the switch goes to sleep and does not respond to changes after a period of time. Once I’ve done this wakeup operation, I can apply new LED updates to it no problem until it “sleeps” again.
This isn’t an issue with my LZW31s, LZW30s, or LZW36s, but they are totally different devices and Z-wave, etc.
I have tried including a refresh operation at the end of the rule machine rules, but it didn’t make any difference.
Anyone else seen this or have tips? I am attaching a screenshot of the rule as well. I also want to say I miss the child device configuration for LEDs that my dozens of Red series switches have. It was way more elegant.
I started experimenting with running the ledEffectAll command instead of setting these individual parameters; so far it works much better. Maybe I was just doing it wrong! I need to let it sit for a few hours to make sure the switches are “idle” and run some more tests.
Well, I spoke too soon. The LED change is much more reliable, but when there is a notification active, the LED bar no longer shows switch status (speed, dimmer level, etc) - only the notification. So this isn’t actually a solution, even though the notifications work much, much better.
I am starting to wonder if maybe the initialize command instead of the refresh at the end of my original rule actions would do the trick. I just need something to force the switch to wake up that isn’t an actual power operation or physical button tap.
Hey, thanks for the tip! I will go look at it at least, I’ve never heard of it. My needs are super basic here and that’s why it’s so annoying that it’s not working. My automation is good, but the switch doesn’t respond like it should.
Appreciate the pointer though, will def check in again once I look
Ohh super cool app. I love that this exists, but it’s using the same notification functions that already didn’t work like I wanted. Solid suggestion, but when these notifications are active you lose actual switch operating status and I want to preserve that.
Hi! Do I not need to send the 3? Reading the rule machine docs it seemed to manually set parameters like this you had to send the expected size as part of the payload. Is that not true? I can drop em if you think that would help.
The refresh at the end was a late addition to try and get those two devices to wake up and apply the settings I had sent them; it didn’t work and it’s just still in the rule while I change one thing at a time for testing.
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!
