So glad to hear that!
I’m surprised (and somewhat confused) to hear that it’s turning on and dimming for you, but not turning off? Offhand, I don’t see how that would be happening.
Happy to look into it with you, though – are you up for some live-log analysis?
I can talk you through, but I’d be especially curious to de-comment the
log.debug statements in the
buttonEvent() handlers in both the smartApp (line 72) and the DTH (line 159), and also to add some new ones in the DTH’s supporting methods
buttonToStatus() (lines 186 and 192, respectively).
The old control path (see
handleManufacturerProprietary() at line 92 of the DTH) expects the on/off state to be encoded in the Manufacturer Proprietary messages that I’ve only ever seen coming out of my very first VRCZ4. (And they still do, FWIW.)
The new control path uses Z-Wave association to associate the “on” sides of the buttons with “button” numbers 1-4, and the “off” sides of the same physical rocker-buttons to “button” numbers 5-8. Everything else keys off of those button-number assignments, so I’d expect “on” and “off” to work (or not work) similarly to each other.
I can see two possibilities thus far: Perhaps you’re on the old control path and the Manufacturer Proprietary codes you’re getting are slightly different from mine (so that the "on"s match, but the "off"s don’t?); or it could be that you’re on the new control path, and you’re (somehow?) successfully associating the “on” button-numbers but not the “off” button-numbers?
In any case, the debug statements I’ve suggested above (along with, perhaps, the ones in
handleManufacturerProprietary()) should shine some immediate light on the situation.
Let me know what you see?