Those are on the official compatibility list, so definitely report it to support. That’s the best way to get an engineer looking at it:
https://support.smartthings.com/hc/en-us
(Eaton is the company, Cooper is the division, and aspire is the model line. The same device might be referred to by any of those three names.)
I have spent weeks with Support to no avail. They just want to blame the device, take days to respond, and only do so outside US daylight hours. Sigh.
I took the time today to setup a custom DTH so I could debug things.
I have a variety of Eaton Cooper Aspire 9536 and 9540 dimmers. Over zwave, they report model numbers 0002 and 0101 respectively. They all exhibit similar behavior with regard to the zwave Basic Set and Basic Report commands.
Specifically, they will report a Basic Set and Basic Report near-simultaneous upon pressing the on/off button. The Basic Set command provides the correct target dimmer brightness level: the level that will be reached when the dimmer finishes ramping. The Basic Report command contains a different value, seemingly the starting value the dimmer begins ramping up from. Given that ST always processes them in this order, I must assume that the Basic Set proceeds the Basic Report by milliseconds.
To get my lights somewhat working again, I’ve commented out processing of the Basic Report command in the DTH. This isn’t a long-term fix as it prevents core SmarthThings features like Refresh and Polling from working correctly. Here’s the source: https://github.com/cjisndenial/SmartThingsPublic/blob/master/devicetypes/cjisndenial/eaton-cooper-aspire-zwave-dimmer.src/eaton-cooper-aspire-zwave-dimmer.groovy
A bit of online research leads me to believe that a Basic Set is considered more authoritative than a Basic Report when arriving near-simultaneous. And I believe that prior to the 25.32 firmware, the hub handled this situation differently than it does now.
Does anyone know how I can get an actual ST developer to look at this? Clearly support is just going to bounce my ticket forever.
First, I’d like to give a shout out to our support team who work very diligently to respond to so many various tickets and requests from our customers, specially the tickets like yours where it requires so much in depth knowledge of various technical specifications. I do see the work they put in and they contact me about your ticket, and I provided them the information. However, I feel like you would like more technical information.
Regarding your issue with how our platform handles unsolicited events from your switch, I must give you a little background so things can start making a bit of sense.
Older Z-Wave switch models and non Z-Wave Plus (good way of knowing this) were barred by a since then expired Patent that made life harder on them to report manual changes of their state. So there were two ways to transfer that information from the switches to the controllers. One is an undocumented behavior where the switches would send their Node Information Frame and the controller would then ask for the latest state of the switch via (Basic Get). The other way basically the controller would poll the switch at a relatively high frequency (lets say every 10-15 seconds) and detect a change of state.
So your particular switches have a very odd behavior. When there is a manual change of state, they send their NIF to the hub. The hub sends a Basic Get, before responding to the Basic Get, the switch sends a Basic Set as shown below.
First of all, Basic Set is not meant to be used by switches to indicate a target value, that is not part of the Z-Wave specification, in fact, the switches are meant to use Basic Report to “report” their latest status and the newer switches do exactly that, 2nd version of Basic Report command actually adds the target and duration until target is reached besides the value at the time of message generation.
Although there are older switches that use “Basic Set” to report their latest state, we basically treat those commands the same as “Basic Report”, this is so some older models are also supported in our platform.
So from the Z-Wave Specification point of View, the Basic Set is the root of the problem, but there is also the problem of why is the switch sending a NIF when it appears to be supporting the Association command class. Basically, if the Association command class is supported, the switches are to send their latest state without having to use the old method of sending the NIF to the controller. So far, there are two major behavior that do not appear to comply with the Z-Wave specification.
So where do we go from here?
I do not find anything wrong with how the hub is handling this particular scenario and behavior at hand. The reason this was working in 0.25.32 was because in the 0.25.32 we had a bug where we did not generate a Basic Get when receiving a NIF from switches, so in that case there was no Basic Report after the Basic Set and all was good.
Replacing your switches would be the ideal solution, but that costs $$ and time. And given that the behavior of this product does not comply with the specification, we must find another way.
My suggestion would be to generate a “Basic Get” from the DTH for these Eaton switches some short time after receiving a Basic Set, that delay should hopefully be enough so that when receiving the second Basic Report, it should match the target destination/value of the switch.
If these devices are certified to work with SmartThings, I am going to work to make sure they are not because of this not-interopable behavior.
If you have other suggestions, please go ahead and let me know. Any other questions and comments are welcomed.
Klanoosh,
This is super helpful. Thank you for the detailed explanation.
With my limited skills, I would never have realized that the hub changed its behavior in response to the switch sending a NIF.
I would also point out that Cooper Aspire dimmers have had built-in instructions in the SmartThings app for adding them since I bought my SmartThings hub in 2015. And they still do today.
This is why I considered them and spent >$1000 replacing every switch in my house with them. Discovering a variance in the device’s z-wave spec behavior in 2019 and writing them off seems inappropriate. I would ask what devices gained support from the behavior change (sending BasicGet after a NIF) so that I could understand that trade-off.
Because the devices support Association, aren’t they required to send BasicSet on a hardware button press? Leviton Vizia RF+ and Cooper Aspire were the only switches on the market I knew of that licensed the Instant Status patent you reference when it was in effect. Again, another reason I selected these switches. The Aspire switches send other commands while they are being dimmed so that associated switches can follow them (ex: SwitchMultilevelStartLevelChange), and then send a BasicSet when the dimmer rocker is released. Given the zwave device ecosystem at the time, I assume they also sent the NIF to support other devices that might not pay attention if they didn’t?
Some solutions I can think of:
It seems both solutions could be added to the standard zwave dimmer DTH so that local execution stays supported for these switches. Add it appears there is precedence for this as there’s still some vendor-specific logic variations in that DTH today.
Thanks again for the response. Your thoughts on the above would be appreciated.
UPDATE: I have tried #2 above in my DTH. It works 99% of the time. It definitely has a race condition that is noticed at initial load of the DTH. I see that every time I update the code, and then it goes away.
