(Perhaps this doesn’t belong “literally” in the New Capability Types Category … though maybe this Category can be renamed to handle definition issues related to existing Capabilities as well?)
I am concerned that Capability “Valve” has it’s main attribute called:
contact ["closed", "open"].
A Valve is not a “contact sensor”. (NB: Is this just a Documentation error, @Jim ?).
Per the Capability Guidelines (in draft by yours truly…), I recommend that the Primary Attribute of a Capability be named similarly to the Capability:
valve ["closed", "open"]
(For grammar reasons, to avoid using the word "open-ed ", I would prefer:
", "open"] … Whatever, I’m Canadian ).
My Guidelines also suggest a Best Practice to avoid using Command Names that may overlap with other Capabilities. I suppose this is impractical in the long term, unless a prefix is used. This Best Practice exists because a single SmartDevice Type is permitted to implement multiple Capabilities; therefore, if the Command Names overlap among those served Capabilities, then we have a serious problem unless the Command always has the exact same meaning on the composite-Device.
It is hard to imagine that a Device which is a Valve would also be a Door Control, but should that occur, we would be unable to implement the Commands “
open()” & “
close()” as there is a namespace conflict.
It may be “too late” for Valve, but, in general, IMHO, there is some value to making up creative Capability tailored Attribute and Command names (and, even, Values). For Valve, I might suggest Commands: "
stopFlow()". I concede that this can get awkward really fast, so this practice need only be seriously considered when there is a high probability of a Command name conflict (i.e., when Capabilities are likely to be implemented in a single device).