Is there a list of supported capabilities, attributes and supported values for Hubitat posted somewhere? If not, can you please make such a document and link it here for developers to reference.
1 Like
I don't think there is an official document for HE but I use this smartthings link to refer too. HE pretty much supports all of them. There may be a few not supported that are really rare.
I do agree that HE needs to step up the documentation game though as there are some differences specific to HE that you can only find info on in the forum. One example is button implementation.
http://docs.smartthings.com/en/latest/capabilities-reference.html
1 Like
Yeah. We could really use some much better docs.
It's tricky enough trying to get your head around a new language (groovy), but when it's not obvious whether you've buggered it up yourself, or you're trying to do something the wrong way... it can be a bit hit and miss 
-- Jules
2 Likes
Official, list, hot off the press today...
https://docs.hubitat.com/index.php?title=Driver_Capability_List
10 Likes
Fantastic! Thank you. You guys are awesome.
Mike,
I see #9 on the list states "Button" yet everything I have seen in the forim says it isn't supported and should be changed to pushableButton?
Keep looking...,
We don't delete capabilities yet.
Probably should have been clearer, it is in the schema currently, so technically it could be used, however we don't use it in any or our apps or drivers, we never liked it, so we came up with our own which is very serviceable.
A capability that is truly unsupported, meaning it isn't defined in our schema will throw an error when trying to save the driver code.
Mike 2 questions:
a) I created a virtual audio volume device, i associated to a "capability.audioVolume" in an app. I subscribed with subscribe(volumemaster, "volume", volumeHandler), the event is triggered when i modify the virtual device, but when i tried to get volumemaster.volume is always null, what i am doing wrong
b) Is there a way to get a list of all atttributes, functions, command, etc, from a device with code? like for each attribute print the value....
thanks!
We already have one of these, anyway...
The syntax for this is device.currentValue("volume"), however it makes no sense to call this from your volume handler since the current value will be in the event value...
Thank you and sorry my english is not so good.
When I wrote "I created a virtual audio volume device", I meant I create a device and I selected in the combo Virtual audioVolume, the one you created...
device.currentValue("volume") works perfect... where can i find info about the syntax, is there any manual? for sure is in one of the topics in the community but there is any main document?
Thank you again!
thank you, the info it helps me... but ...
I am trying to use what you mentioned with a musicplayer too.
I have 2 musicplayer a SONOS (using the app hubitat provide), and Echo Alexa using the Echo Speak devices/app
if i use in code musicplayersonos.currentValue("level") or musicplayersonos.currentValue("volume") i got error like java.lang.IllegalArgumentException: Command 'currentValue' is not supported by device. on line 72
How could i know what is the correct way to access the volume level of the Sonos?
Same question with the Echo...
I know they work because RM can access to the volume level....
Mike (@mike.maxwell) -
Reviving an old thread to ask about an apparent difference between SmartThings and Hubitat regarding null attribute values.
Device Driver code fragment:
. . .
attribute "foo", "STRING"
. . .
sendEvent(name: "foo", value: "")
. . . -
On SmartThings, this sets the attribute named "foo" to
null(the null value). It appears as no text (blank) on the device attribute page, and(device).currentValue("foo")called from an App returns the (expected)nullvalue -
On Hubitat, this apparently does nothing - the attribute may even appear to change to
null(not blank - literally the word "null" in bold italics) on the device page, but(device).currentValue("foo")and(device).currentValue("foo", true)both return the value before the above sendEvent. Unlike ST, it appears that the attribute's value isn't being overwritten). Refreshing the device page will actually restore the previous value in the display!
Surely I'm missing something, because there seems no way to specifically set an attribute to the null value on Hubitat. My only solution so far is to either send a space (" ") or the String "null", and then check for both the null value (when the device is installed and attributes haven't been set yet) and the String "null"... tedious to say the least.
So, what's the secret to set an attribute (back to) the null value?
you're not missing anything, null isn't an acceptable value for an event's attribute value.
1 Like
Ummm...respectfully, null HAS TO BE a valid value (and not just because SmartThings implemented it that way) - null is the value of an attribute before it has been set - and its what currentValue() of an unset attribute will return.
I'm simply trying to find a way to get an attribute BACK to the original null value...
ok, but why?
We haven't identified a need for this in apps or drivers...
BTW null isn't an original value, it's what a database returns when a record set is empty...
1 Like
Also curious as to why null is displayed in the device's page after a sendEvent with value: "", and then why does it restore the old values when I refresh that device page?
It seems to me an incomplete implementation...I'd prefer it work like SmartThings (I know - sacrilege, sorry if I insulted anyone).
Use case: I have a device driver that manages a network-connected device. This device has numerous attributes (settings and states) that I'm trying to reflect in the device driver. I get them from the device in JSON format, and some of these attributes are occasionally (frequently) null, dependent upon the physical device. For example, if the device has an event running, it will provide me with the event_endDate in the JSON; when there is NO event running, this event_endDate will be null (meaning, there is no event running, so there is no end date). I want to present the event_endDate as an attribute, but when the event is over I need a way to set it back to the original null state.
Further, your documentation states that all event values sent using sendEvent must be Strings, and (respectfully) "" is a valid (empty) String. Nowhere can I find documentation that says an attribute cannot be null (or the null String "").
I'm sure you can work around this using other means.
Events (attribute state values) are not a display replacement for the tiles in smartthings...
Generating events that have no purpose other than an informational display should be discouraged as they use unnecessary resources.
Hubitat's event system is designed to trigger automations.
1 Like
OK, I see that you are digging in your heels on this one.
I'm not trying to replace tiles - I am trying to communicate information to the user or programmer. There is no other means for either persona to see what is going on inside a device except for attributes (end-users can't access dataValues in Dashboards or Rules).
Imagine a simple Hubitat Dashboard (or Rule Engine Rule) that displays the event_name that is running, and it also wants to display the event_endDate beside it. How else would I be able to get this information into the Dashboard, if not through an attribute? And while I could send a space " ", the result would not be a valid date if another App (or Rule) was trying to use that information.
There is a reason why null (undefined) exists in Groovy, and why null is a valid value for a String (and an Integer, and a BigDecimal, and a Boolean, and ...). There is a also reason that Hubitat will return null when asked for the currentValue() of an attribute that hasn't been initialized yet - it isn't true or false - it's null (aka undefined). There's probably even a reason that Hubitat's Device page shows the word "null" for such values, albeit momentarily (and incorrectly, I guess, because the underlying value has not been actually changed).
Frankly, I don't get why the push-back.
Hubitat clearly understands when an attribute is null, because it will return null when asked for the currentValue of an uninitialized attribute. It is is also clear that at least SOME code (device display page) understands how to display null values. Somewhere, the code is indeed letting "null" into the device (perhaps only into some cache, I guess), but that code isn't overriding the attribute value when it goes to unload the cache (I'm just guessing here).
And yes, while I can code around your chosen implementation, it requires code to do excess work on Hubitat than should be necessary - I really should only have to test if the returned value is null or not:
Hubitat code
def event_endDate = theDevice.currentValue("event_endDate", true) // force reading the cache
if (event_endDate) // verify the response isn't null because it hasn't been initialized yet
{
if (event_endDate != 'null') // check if it has been set to literal `null`
{
// Handle the actual end-date
}
else
{
// There is no event running
}
}
else
{
// The attribute hasn't been initialized yet
}
verses SmartThings code
def event_endDate = theDevice.currentValue("event_endDate", true) // force reading the cache
if (event_endDate) // verify the response isn't null because it hasn't been initialized yet
{
// Handle the actual end-date
}
else
{
// There is no event running
}
