Eaton/Cooper RF9540 minimum level / rapid start not being honored via Zwave

Devices & Integrations
1

Long time lurker. First post.

I’ve got several Eaton/Cooper RF9540 dimmers. These have a rapid start function which ostensibly kicks an LED up to a level which will successfully start the lamps and then ramps back down to the previously preset level. When accessed via the physical switch, this works as expected, every time–it’ll start the lamps and ramp them down to the lowest dimming level they’ll run at flicker-free.

ST adds them with no problems as generic Zwave dimmers. And they will turn on and off and dim without issue, save for the fact that if the switch was left, say, dimmed to it’s lowest level, the ST issued zwave “on” command isn’t “rapid starting” the lamps–it appears to be turning the switch on directly to the previous level. And when that previous level is below the level at which the lamps will start, they either blink or don’t start at all until one ramps the dimming level up to the “start” level and put it back to the minimum. At this point, this has all been from the classic app–I have not tried automation yet to see what happens.

So, is there something I’m missing to either have ST issue the “correct” zwave command/commands to have the switch “rapid start” the lights? Is there a way to simply issue an “on?” Is it a device handler thing? Pardon the stupidity–I’ve had the platform for roughly a week.

2

That’s a nice switch. :sunglasses:

Most likely there are just some parameters that need to be set. It was quite common at the time that switch was designed to have one set of parameters that defined manual operation at the wall switch and a different set of parameters that defined the dimming behavior when the switch received a network command. Nobody really uses it that way much anymore, and newer generations don’t usually have that split, but that could be part of what’s going on.

Anyway, all you need to do is get in touch with Eaton Cooper Aspire support and have them tell you what parameters need to be set to what values to get the behavior that you want to see.

Once you know that, there’s a community – built utility, the zwave tweaker, which will expose all of the parameters for any mains powered zwave device, lets you change them and save them in the device, and then go back to your regular device type handler. It’s really slick code. :sunglasses:

The first you need to know is which parameters need to be set to which values. Which the manufacturer should be able to tell you regardless of what hub you are using.

There’s a support phone number at the top of the user guide, I don’t know what the email would be.

http://www.cooperindustries.com/content/dam/public/wiringdevices/products/documents/instruction_sheets/RFAL-DIMR-EN-REV-B.pdf

(The company is Eaton, the division is Cooper, the model line is Aspire. You can see that switch referred to by any of those three names, but always with the same model number. The Zwave versions will have “RF“ (for radio frequency) in the model number. Make sure you specify that when you talk to them as there is also a dumb version of the same switch.)

Once you have those values, you can see if the DTH you are already using exposes those parameters. If not, you temporarily change to the tweaker.

[BETA] Z-Wave Tweaker

It takes a few steps, but it’s pretty straightforward.

2 Likes
3

@JDRoberts: thanks for that. The zwave tweaker DTH looks to be brilliant, and probably surpluses what I’d thought I’d need to get in the way of a zwave handheld to pound associations later in my project.

So, the kickstart parameter in these switches (8) was set to “1” which the cooper documentation suggests is “on.” So, I changed it to “0” just as a test, and hit the physical switch with the preset being “less than a number which will start lamps.” They didn’t start. Triggered it on with the classic app. Didn’t start.

Set the parameter back to “1”. Physical switch press then results in the “rapid start” behavior. Toggling in ST-classic continues to result in the lamps not starting (actually, there’s a quarter second flicker, but nothing more). This would tell me that changing the parameter (zwave) is also changing the “physical” behavior, yet the zwave initiated behavior is still different.

Checking the logs within ST would indicate to a complete noob that ST is not sending any kind of set level to the switch along with the “on” command, but I don’t know if my ST foo is good enough to know that for sure, yet.

I suppose my next stop is asking the Cooper folks. Or getting a 96XX dimmer and giving it a whirl just to see.

Any other ideas cheerfully accepted.

1 Like
4

Just to get this out-of-the-way: after you changed the parameters, you did switch back to the other DTH, right? Because the tweaker can only be used to set parameters and associations, it won’t communicate well with the device for any other purpose.

5

Yep. (or, all testing was done with the “generic z-wave dimmer” device handler back in place.

In the interests of “why not?” I then joined a Cooper tabletop controller as a secondary, triggered the same dimmer from it, and got exactly the same behavior. I haven’t yet gone as far as excluding both the tabletop controller and the dimmer in question and associating them independently of ST, but that’s probably next, pending what Cooper or the forum would suggest I try :slight_smile:

Reached out to the folks who make the gear at Cooper and asked the question. I’ll report back with what I hear back.

2 Likes
6

Well, it would certainly be interesting to see what happens with smartthings out of the picture. :sunglasses:

1 Like