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.