Any idea what the best capability would be to report a level from a sensor? Specifically a water level in a tank? I want to report as a percentage to full but cant see any sensor level capabilities. All I can see is Switch Level which seems to be for devices controlling the level of something (dimmer, volume, speed etc).
Just use Capability āSensorā and add arbitrary Attribute(s)
Or use any Capability that has a numeric value for a sensor (e.g., Temperature, Switch Level, Power, ā¦).
I strongly recommend approach #2, because then your DTH will be instantly compatible with SmartApps that react to that Capability as an input.
e.g., If there is a SmartApp that āalert me when it is too hotā, then writing your Water Level to Temperature will immediately be able to use that SmartApp!
(And apps like ActionTiles will be able to display your Water Level on a Temperature Tile).
I am making my own LAN connected device to report the value, but just need the best way to record it in ST. I can quite happily use an attribute and custom commands to handle the data but thought there might be a more āstandardā way.
Nick
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
5
Itās not so much that there is a āstandardā, as there is a lack of standards.
The only way you can be certain your DTH will work with existing SmartApps is if you use one of the existing Capabilities.
It is also acceptable to do it both at the same time. e.g., create an ad hoc Attribute āwaterLevelā while also writing the same value to Attribute ātemperatureā (and claiming Capability ātemperature measurementā). For devices that donāt emit a lot of events, the overhead is trivial.
Just curious, if he chose Switch Level, which is read write, can he override it and make it read only? Or would his Setter just throw a silent exception?
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
7
Technically, SmartThingsās āDevice Instance Objectsā donāt have setter methods; instead, they offer Commands which may have the side effect of changing the values of Attributes.
If a DTH claims Capability āSwitch Levelā, then it should / must offer the setLevel() Command.
Thereās no contract that the Command must perform any function successfully. I think it would be safest to fail silently, or post a warning to Live Logging; but a more severe Error is likely unnecessary.
If you donāt provide at least a stub Command, then you risk App and SmartApp exceptions with possibly serious implications, such as crashing (since such apps may not have been written with clean exception trapping).