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.
(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?
Add three lines of this syntax:
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
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 “
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.