Supported_features

@AnyOneWhoCanHelpMe. I am working on navive HomeKit Integration as I am looking at the best possible and “leanest config” options I am extremely curious about the “supported_features” attribute I see in the “states” tab of the “developer tools” of the front-end. I guess that option if of great interest to configure the connection automagically. F.I. a light, can it be switched on/of only, can it DIM, does it have RGB or any other features etc. Again another guess based on my experience is that it is a bitmapped field.

My question is; Where can I find some Docs on that?

1 Like

You should look in the base class e.g ligts/init.py

i am also interested in this?

How does this add together?

i have a hue light with supported_feature 41 (this one makes sense)
and i have another one with color_temp supported_feature 43 (how does this one work)
How would a RGB lamp look like???

# Bitfield of features supported by the light entity
ATTR_SUPPORTED_FEATURES = 'supported_features'
SUPPORT_BRIGHTNESS = 1
SUPPORT_COLOR_TEMP = 2
SUPPORT_EFFECT = 4
SUPPORT_FLASH = 8
SUPPORT_RGB_COLOR = 16
SUPPORT_TRANSITION = 32
SUPPORT_XY_COLOR = 64
SUPPORT_WHITE_VALUE = 128
1 Like

yea its difficult to do, i am working on a smart app for google assistant

I know this post is old, but the calculation is basically binary conversion.
So 43 gets you…
SUPPORT_TRANSITION = 32
SUPPORT_FLASH = 8
SUPPORT_COLOR_TEMP = 2
SUPPORT_BRIGHTNESS = 1
See the math there?

The Sengled bulbs I have are only 33 so I get…
SUPPORT_TRANSITION = 32
SUPPORT_BRIGHTNESS = 1

At least this is how I believe the value is determined.

3 Likes

It’s old, but this method hasn’t been explained yet.

to check if a light supports RGB, use

if (supported_features & SUPPORT_RGB_COLOR) {
// rgb supported  
} else {
// no rgb
}

this is the polite way to ask if the flag for RGB is set and it works on any type of light regardless of supported features. Technically, this way you ask the computer if supported_features and SUPPORT_RGB_COLOR both have the same bit (value 16 which means bit 4) enabled. You don’t care about the other bits.

What does all this mean?
How do you control the flash behaviour in an automation, for a bulb that has supported_features = 41 ?
And does some documentation on this “feature” numbers exist somewhere?
How did @JustMe0815 know that feature #8 = FLASH ??

This is all in the backend. It’s in python, you have to read the python in order to understand the numbers. What’s your question about?

Well, if flashing is a feature of a bulb that is reported to have Supported_Features = 41 then I’d like to know how to get it to FLASH.
(I just use FLASH here as an example).
My objective is to try to understand what Supported_Features = 41 actually means, and how this (these) feature(s) can be put to good use in an automation.

# Bitfield of features supported by the light entity
SUPPORT_BRIGHTNESS = 1
SUPPORT_COLOR_TEMP = 2
SUPPORT_EFFECT = 4
SUPPORT_FLASH = 8
SUPPORT_COLOR = 16
SUPPORT_TRANSITION = 32
SUPPORT_WHITE_VALUE = 128

If your light has 41 as it’s supported features, that means it supports Transition, Flash, and Brightness.

That’s because, 41 can only be represented by 32+8+1 (given the possibilities I listed above).

I got this information from reading the light component code linked here.

Reading through the possible service calls, I see that flash (Short or Long) is supported by the service calls turn_on, turn_off, and toggle.

I got that information from the light services code linked here (ctrl-f for “flash”).

Are you saying that flashing is “supported” by manually switching the bulb on and off ?? (or by using toggle)

That’s like saying a car will also move if you push it (but it’s not a very convenient way to travel)

No.

You would use the service call for it, in a script or automation, etc.

For example to make a light start flashing, in your automation you would have an action of:

  action:
    - service: light.turn_on
      entity_id: light.kitchen_light
      flash: short

Fantastic!! It actually works! :clap:
But how on earth did you know that the syntax flash: short would do the trick ?

There are at least three ways to learn this. I’m listing them in the order I used, since I’m more comfortable reading through the code itself. However you might want to focus most on #3 since that’s the most simple and doesn’t require looking at any code. -

1 - In the code I linked above (this one), it tells you exactly how it works in plain words:

turn_on:
  description: Turn a light on.
  fields:
   [...]
    flash:
      description: If the light should flash. Valid values are short and long.
      example: short
      values:
        - short
        - long

In the text segment above (starting with “flash:”) is in the code, and I found it by searching for “flash”. The first 3 lines (“turn_on”) are at the top of the indenting of flash. That means the flash parameter is part of the turn_on service. The “flash” parameter is also under turn_off and toggle. So from that I know that “flash” is a valid flag for those 3 services.

2 - To confirm what I read in the code was correct, I went into my Home-Assistance instance, then to Developer Tools, then Services, and selected the light.turn_on service. From there, at the bottom, it shows you all the possible valid options. I was able to see that the flash parameter was described there.

3 - You can check the documentation for light entities and it will describe the flash parameter being valid for the same 3 services mentioned previously. The documentation is here: Light - Home Assistant

1 Like

Superb! Thank you so much :blush:
As i slowly brake into all these mysteries - I stumble upon new and equally confusing settings.
The supported features: 41 was explained above and I finally understood its meaning. However, why the Brightness attribute is listed in cleartext while the Flash attribute is hidden in the number 41, is a mystery to me.
Also, I have devices with many listed attributes while at the same time has supported features: 1 which to me mean that it should only support on/off and nothing more. But that’s not the case.
Can you explain that too?

I may be able to, but I’m not an expert by any means. Can you give me an example of what integration does this, and which attributes it does show, just not under the supported_features section?

What abut this camera. It has a ton of attributes while still being listed with only one supported feature bit (2):

From __init__.py in homeassistant.components.camera it states:

# Bitfield of features supported by the camera entity
SUPPORT_ON_OFF = 1
SUPPORT_STREAM = 2

So your camera supports ‘stream’ but not ‘on_off’.

supported_features and number of attributes have no correlation.

You are usually right @petro, but then please explain this entity (light) where both the attirbute list as well as supported_fatures include “brightness” (41) ? Are these two different “brightness” (since there is no correlation)?

image