Designing a new driver with non-standard capabilities and commands

[MihaK]

I am writing a driver for a hydroponic gardening device that provides data and accepts commands.

Data that can be polled is [current pH, average pH, current EC, average EC, current water temp, time of last sampling, time of last pH correction, time of last EC correction, is_connected... ]

Device also accepts several commands: [pH_up(ml), pH_down(ml), nutrient1(ml), nutrient2(ml), flush_pump(#) ]

Design questions for the Hubitat driver:

• should this be packed into one driver or a hierarchy with main driver and sensor/commands children?
• how to expose all these attributes and commands to other apps in the most sensible way? All attributes and commands should be visible to webCoRE, Sharptools, ActionTiles and any other integrations.

So far, I packed everything into one driver and am declaring a whole bunch of non-relevant standard capabilities (CO2 sensor, pushButton, Humidity sensor, power sensor...) just to piggy-back on their standard (yet misnamed) attributes and commands to carry my own data and commands over to Hubitat integrations.

Is this the only way or am I messing it up?

[csteele]

Are you going to have multiple gardening devices? If Yes, then Parent/Child else single driver.

As to custom Attributes and Commands, go for it. They are automatically exposed via Custom Commands In RM, etc. Here's an example of a Thermostat driver I support that shows a mix of Capability, Commands and Attributes being defined.

Example

        capability "Polling"
        capability "Thermostat"
        capability "Refresh"
        capability "Temperature Measurement"
        capability "Sensor"
        capability "Relative Humidity Measurement"
        capability "Initialize"   
        command    "heatLevelUp"
        command    "heatLevelDown"
        command    "coolLevelUp"
        command    "coolLevelDown"
        command    "setFollowSchedule"
        attribute  "outdoorHumidity",    "number"
        attribute  "outdoorTemperature", "number"
        attribute  "lastUpdate",         "string"
        attribute  "followSchedule",     "string"
        attribute  "fanOperatingState",  "string"
        
        attribute "humidifierStatus", "string"
        attribute "humidifierSetPoint", "number"
        attribute "humidifierUpperLimit", "number"
        attribute "humidifierLowerLimit", "number"

[MihaK]

Are your custom attributes and commands visible to - say - Sharptools and Action Tiles? When I try it, all custom attributes and commands were not visible to integration apps...

[snell]

Custom attributes and commands should be available to other things, pretty much every one of my drivers have both, some more than others.

One thing to be careful of (that just recently came to my attention) is to avoid having spaces or periods (any special character really) in an attribute. While they WILL work you can get some odd results when they are displayed on the device's Current States list.

[josh]

Custom attributes and commands should show up in SharpTools. You can use a Hero Attribute tile or Super Tile to display custom attributes:

Tiles, Super Tiles, and Custom Tiles Compared - SharpTools Knowledge Base

Last I checked, just a few weeks ago, Action Tiles did not support custom attributes. The device would need to use one of the display capabilities that AT supports (eg. Switch / Temperature / etc)

[stephen_nutt]

@snell

Custom attributes and commands should be available to other things, pretty much every one of my drivers have both, some more than others.

One thing to be careful of (that just recently came to my attention) is to avoid having spaces or periods (any special character really) in an attribute. While they WILL work you can get some odd results when they are displayed on the device's Current States list.

Today, I have been modifying the Omni Sensor to accept values from the Alexa Air Quality Monitor. Within the last hour, I discovered that the Attributes don't like upper-case letters if you want them to be selectable in an Attribute Dashboard tile. The Current States also did not persist thru a browser refresh until I changed to all lower-case letters.

[aaiyar]

@stephen_nutt

Attributes don't like upper-case letters

Hmm … I use camelCase in my custom attributes without any issues, so perhaps case only matters for the first letter

[stephen_nutt]

You are probably right. I originally had 1st letter of each word capitalized and just changed all of it to lower-case just in case based on what I saw in native states.

EDIT: @aaiyar You ARE right. I switched mine to capitalizing the first letter of 2nd and 3rd words in an attribute name and it still works.

[MihaK]

Indeed, all of my variables/attributes and commands are capitalized. Well, they WERE.

We should document this somewhere, would save tons of frustration.

[snell]

Capitalization is one area I have never had an issue with.

I documented what I originally found as a Feature Request and I did find out it is "not" a bug because this is actually how Groovy does stuff and it would require Hubitat to code a workaround (thus, Feature Request).