A long time ago I wrote a position about grouping - I called it teams and it was a concept to describe multiple devices of identical types used as 1. EG; 4 ct bulbs in an array for a bathroom.
I find my devices for dashboard management have a weakness in that I have outlets which I use as repeaters, and I have switches. Switches in my case are normally in-wall, and flip a light. Outlets are plugins that control various asundries.
The weakness is apparent when I set a default icons for on/ off devices. If I set the imagery to Outlets, then the switches get forced to take that default. If I set the imagery to Switches, then the outlets are wrong. Relays (and the children) also fall into this ... um. for lack of a better term - weakness.
There is an indication that others know of this missing area - since groups have barely evolved but now allow you to set 'switch' or 'bulb'. a similiar example of sub grouping.
By defining all off/on devices as one type, i don't have the ability to work on these sub - types.
It becomes really apparent, at least to me, when you write a rule to turn 'all lights off'. You really can't unless you manage the groups and create one called all lights. Similarly, turning off all outlets or turning off all switches.
In the future, a hub manufacturer who allows the ability to choose and sort the subgroup type will get a leg up over their competition.
This is kind of a misnomer. From the hub's perspective, there aren't really on/off devices, but there are devices with the on/off capability which I think is a keen distinction. Using capabilities over device types for most things gives a higher level of flexibility. This setup may be mildly annoying for a few people, but the inverse would also impact others. I'd err towards the side of flexibility over solving an edge case any day.
Case in point, Google Home does default grouping by device type. That means that every light assigned to a specific room, regardless of their capabilities, are grouped together. For someone wanting to maximize control over their devices, this adds an extra layer of tapping through menus to do so. It's very frustrating for me, but several others enjoy the simplicity.
And then there's always the default response...you can always write your own app (or plead to the right developer) to solve your use-case. A custom app can certainly group devices by type assuming you follow some sort of naming convention to differentiate between a light switch and an outlet.
I don’t understand.
I don’t actually change my dashboard icons, but I looked just now and I’m pretty sure what I’m seeing is the option to adjust them by device type. So there’s one template for outlets, and another one for switches.
Or perhaps there’s something different about groups on dashboards that I’m not understanding.
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.
What platform version are you running? I can reproduce this with 2.3.4.119.
Tagging @gopher.ny
Button is a capability. Here's the full listing from the developer docs.
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.
Same here.
2.3.4.117 - haven't updated - was waiting for calm because of the troubles over the last few days.
The response from staff in that old thread still seems relevant:
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.
What do I not know? (and don't start a list!) I pulled this from the current example driver at Hubitat Git.
metadata {
definition (name: "Advanced Zigbee CT Bulb", namespace: "hubitat", author: "Mike Maxwell") {
capability "Actuator"
capability "Switch"
capability "SwitchLevel"
capability "ChangeLevel"
capability "Bulb"
capability "Configuration"
capability "Color Temperature"
//capability "Level Preset"
//capability "Color Preset"
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.
That needs fixin'...
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.
This is completely false.
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.
