I'd like to propose a simple Capability. FanDirection which would allow selection of blade direction for a ceiling fan or other fan. This would be modeled after the simple "HomeKit" like capability which uses two values: 0 = "Clockwise", 1 = "Counter-clockwise"
For clarity, for a ceiling fan, I think the typical fan direction (when looking up at the fan) is that Clockwise results in air being drawn upward toward the ceiling, and Counter-clockwise is air being pushed down from the fan.
Is this the right place to raise this? If so, any thoughts on this - is this already handled somewhere that I missed?
Thanks. My thought was there should be some "standardization" of how this works, which suggest Hubitat have an "official" definition of the capability that everyone develops to a common standard to be added here: Driver Capability List - Hubitat Documentation
Most fans I've seen have a hardware switch for direction, and the controllers sonoff(wifi) & Wink zigbee and hampton bay (RF315mHz) I don't believe are capable to reverse direction
Else, something like the Fibaro Smart Implant (https://products.z-wavealliance.org/products/3640?selectedFrequencyId=2) to control a DPDT relay which could changing how the capacitor was wired to the sets of fan motor coils combined with the Inovelli fan controller and a modified driver.
Its a bit of a "if you build it, they will come" type situation - the capability to reverse is in some fans, but the tools available to build it should be defined - it seems this should start with a well-defined and commonly understood capability so that manufacturers can be the first resource to getting this done.
Hubitat "Capabilities" are just sets of standardized commands and attributes that a driver declaring such a capability must implement. It can also help in apps to narrow down device lists to just specific capabilities (for example, allowing you to just choose motion sensors in Motion Lighting for the sensor instead of presenting the entire list of devices and hoping you choose one that supports the attributes/events the app is looking for). It seems you may be clear on this, but some others were not.
What you're asking for on the device/driver side is already do-able with custom commands and attributes. For example, you could declare a custom setFanDirection() command and a fanDirection attribute. Hubitat could also put something like this with defined values into a hypothetical "FanDirection" capability. However, I've seen staff who've written drivers for lots of fans mention that few if any actually support this, so my guess is that we're unlikely to see this any time soon. As (more or less) mentioned above, you could use these custom commands and attributes in any app that supports them, including Rule Machine.
I don't think that making this a formal capability in Hubitat will have any sway on smart fan manufacturers, however. As much as I like Hubitat, I just don't think this change would have that much klout.
Perhaps making it a formal capability doesn't have much sway among manufactures, still, for developers, a standard way of implementing predictable features would be beneficial so that end-users get a common way of interacting. This seems like it would be a natural addition to existing defined capabilities.
As a related issue, maybe Hubitat is still too much in its infancy and this will come later, but there seems to be a general lack of clarity in its developer documentation for capabilities. For example, on the Fan topic, a Fan can have 3 main capabilities (i) Switch; (ii) FanControl; (iii) SwitchLevel. It is not well defined how these work together. For example, if Switch controls the On / Off function (which it should), then why does FanControl also have On/Off - shouldn't FanControl operate similar to SwitchLevel (i.e., by remembering the last level when the fan was turned off so it can be restored with Switch is st back to on)? Should the FanControl only show "On" and "Off" on the user interface if it is a binary-style on/off control - in which case, should it remain synchronized with the Switch control? And what about SwitchLevel - some fans allow a percentage based control (Inovelli's does - though, in fact, it seems to map 1-33 to 33; 34-66 to 66; and 67-99 to 99) - so what happens if a percentage is sent as a "level" -- does the interface synchronize its FanControl display to the "nearest correct value" (it seems it should) or what does happen? Similarly, for RGB bulbs, there can be different ways to set color - the drivers I've encountered don't seem to synchronize their controls on the Hubitat user interface (e.g., if I change Hue by the Hue control for Inovelli bulbs, there is a separate HSV control which doesn't stay in sync - very confusing). Apple's HomeKit Accessory Specification seems to go a good job of explaining how their different "Characteristics" (similar to Hubitat Capabilities) interact for certain defined Services. Its a good model and something along the same lines should be adopted.
Maybe a solution is a well-defined set of example "devices" and a formally defined set of "Shall Do" and "May DO" type instructions for how to implement lights, dimmers, Fans, locks, thermostats, etc. so there is consistency as to the interactions between Capabilities - This could be via a Wiki or other forum to allow developers / users to help define the interactions which could then be adopted by Hubitat as "official guidelines to common devices" or some such thing. Community forums are nice, but they don't have the weight of anything authoritative or common.
I'm having an issue where I'm trying to control a ceiling fan with fan direction capability via hubitat over the Amazon Echo Skill integration. Hubitat supports fan direction, Alexa also supports fan direction, but the skill that bridges control of devices over Alexa doesn't know what to do with fan direction. Can someone fix this?
