it's a good reply, and I almost agreed until I recognized why your response didn't click for me - a capability is not all inclusive. A CT bulb driver has the capability of "bulb" as well as "color Temperature". its a bulb. but it's also a CT. it belongs to 2 groups. But the weakness I've described is that I don't get a multiple picklist - I can't drill down. Regardless of googles decision on how they implement, as a dev the idea is to give THEM the flexibility - not pre-build the limitations. The concept should be to open it up, not create inherent limits.
Just furthering my POV, in our HE screen is a type column - and HE provides us with a Virtual Button. What made it a button and not a switch? it's capability? or the devs decision to define and prioritize it? The argument goes further down the hole - why can't I pick out 'devices with XYZ' capability from the interface?
So how could something like this be implemented or how could I extend HE myself if their structure is in stone? Control4 lets me pull devices with Capabilities - and I've seen other tools that do as well as some dashboards that offer to help.
It's an interesting discussion to me.
You did make a well thought point - and I appreciated it.
Just another Add to this - I honestly had never seen this before I SWEAR!
I was updating one of my personal drivers and in the Developers Tools/ Drivers code screen is this:
Note the capabilities field! but it's blank and I've no idea why.
You'd have to be more specific. There are several places where devices are selected based on capabilities.
It's not set in stone. Here's a snippet of code from one of the apps I developed:
input "carbonMonoxideSensors", "capability.carbonMonoxideDetector", title: "CO sensors to monitor", multiple:true, required:true
This generates a dropdown list of all devices on the hub with the carbon monoxide detector capability. This is just an example, but most things around device/app management are not very locked down on the platform. It's not until you get into trying to manipulate the hub itself that you start seeing real limitations.
All this to say, there are separate capabilities between switch and outlet but how those show up are dependent on what's written in the device driver that you're using. Maybe your outlets are using the switch driver instead of an outlet driver.
There is no such capability as "bulb". There are three capabilities for a CT bulb: "Color Temperature", "Switch Level", and "Switch". Each such CT bulb could be selected from 3 distinct selectors, one for each of those attributes. If you want to turn off all lights that are CT bulbs, you could do that easily in any of the automation apps (see below).
Of course you can. You can choose what capability you want to select a device from, and only those devices are presented for selection. This is true in most of the apps that offer multiple device selection, not including Alexa Skill, Google Home and Maker API. Should those apps support multiple capabilities? Perhaps, and perhaps some day they will.
You're right, and I'm wrong. So there are lots of ways to select such a device. None of the apps use "Bulb". Although, in theory it could be used in Custom Attribute in RM.
gosh - while we're on the subject - wouldn't a capability for 'relay' also be valuable? Not sure what it would do, but being able to ID the relay devices to target for icons and such would be quite useful as well. The Android Dashboard guy just added 'outlet' as a distinct device type with now will let me separate outlets from switches - can we extend that without upsetting the applecart?
Every smart switch and smart outlet has a relay within. So does a smart GDO. Smart thermostats have multiple relays. How does creating this proposed capability add value if it cannot distinguish between them?
its the sensing of multiple capabilities I think. How does a tile know its a thermostat? The user chooses to select the type. If an outlet is also a switch, why can't a relay be a switch? How does a CT bulb differentiate itself from an RGB? a driver advertising multiple capabilities gives the user functional control - isn't that what HE is trying to provide?
I wrote in the Android Dashboard thread:
There is something to be said about multi-function devices. a big weakness of HE is the assignment of capability type - something that is becoming very apparent to me. 3 years ago, devices were singlular (for the most part) in their abilities - a motion sensor was a motion sensor. a contact sensor was a contact sensor. Now, we have motion sensors with Lux and temp. We have switches that also dim, we have outlets that also repeat.
As someone who twiddles with his icons, it really becomes a huge weakness that a dashboard dev is limited in the ability to pre-decide what icon and features to display. This isn't the dashboards fault, its the underlying structure that fails. Today it's a smoke and carbon sensor, tomorrow it will be a relay with temp sensing.
At the dashboard, the dev's all struggle (this is across the board on dashboards, not just our favorite Android Dash) with what do I display? what is the primary function? What do I do with the extra capabilites?
If the idea behind why we talk amongst ourselves is to move the ball forward, this is an area I feel could use TLC.
These are the devices that offer these extra features. I'm missing how this is a problem. A driver for a Hue Motion Sensor, from years ago, had motion, temperature, battery and illuminance capabilities. This isn't something new.
Seriously? Can't the user pick what they want? How can this possibly be an argument against offering the capabilities that the device itself has?
I have old ST Multi-Sensors that I use in some instances as a contact sensor, in other as an acceleration device, and in others as temperature. These multi-sensors existed before Hubitat. And, I have some of these in Dashboards.
ST MultiSensor was one of the very first, original Zigbee drivers in Hubitat. I should know since I have several of them, and used them extensively. I had to run Hub Link leaving them in ST at first, because we didn't have a driver for them. That was fixed many months before Hub C-3 was launched as a product. So this concept of multi-function devices has existed for as long as there has been a company named Hubitat. Some are used as temp/garage-door/acceleration.
What additional control does a "relay" provide that the existing types do not provide? Recall, your original use case was to use the type "relay" to select for all devices that were relays as quoted below:
And my point, which you may have missed, is that adding the capability "relay" would dramatically increase the number of devices one would have to screen through rather than simplify it.
How about letting the end user decide? I have sensors that I use as motion sensors on dashboards, and as both motion and lux sensors in automations. The built-in Dashboard app permits the same device to be represented multiple times with different capabilities/attributes for each tile.
