Hi John… thanks for sharing the code!
If you can excuse me butting in, I have some ideas that are just humble optional suggestions…
I can delete this post immediately upon request.
1] Features
(a) May I suggest adding optional Device Preference Inputs (that the user can input using the Thing Preferences sub-tile), so that the user can configure their own custom speed values associated with Low, Med, High?
i.e.,
Add three lines of this syntax:
preferences {
input "lowSpeed", "number", title: "Sample Input Title", description: "Define low speed value", defaultValue: 20, required: false, displayDuringSetup: true
}
(b) Personally, I would prefer still having the speed slider available in addition to the Low/Med/High preset buttons. Get the best of both worlds that way, I suppose: Instant speed selection + fine tuning.
2] Coding Style:
(a) A totally insignificant deal in a small program, but to gain a wee bit of modularity, I suggest that your methods for lowSpeed()
, medSpeed()
, highSpeed()
should call “setLevel( number )
”, rather than referencing the underlying zwave methods directly – redundantly.
This makes your code easier to port to a different device, such as a ZigBee based fan controller, since all the low level hardware stuff is isolated to as few method definitions as possible.
(b) The Device Type should really be of “capability.fanSpeed
”, rather than “capability.switchLevel
”, but that is something currently “out of our hands”, as we can’t add new Capabilities on the fly; so I have no problem with that choice. However, you can consider maximizing consistency by not adding any attributes that are not really necessary. Switch Level already includes “attribute: level
”, you can use that in place of adding the new attribute “currentSpeed
”.
Since, fundamentally, your Device Type is overloading the setLevel()
command to set fan speed, the code is slightly cleaner if it commits to that overloading.
Just my 2c; hope I’ve been helpful rather than a nuisance; but let me know…
Have a good one!
…CP / Terry.