Reduce strictness of supported_color_modes checking; or defer when it is enforced?

[CloCkWeRX]

I had a lot of struggle with Tuya devices, and then Localtuya after that.

Official documentation:

https://developers.home-assistant.io/docs/core/entity/light/#color-modes

Some extensions/manufacturer haven't read the above or don't stick to it.

Example:

I'm measuring an ANKO Strip at the moment that claims it supports Brightness, Color Temp, and Hue/Sat.

Right now, that will result in powercalc raising an exception and not setting up any entities, unless I've got all three (or... at least seems to) when doing the initial configuration.
However, I'm never going to be able to put it into "brightness" only mode; at least judging from the official UI.

Possible improvements: Documentation

I tweaked https://github.com/bramstroker/homeassistant-powercalc/wiki/Contributing-new-lights#which-color-modes-do-i-measure to suggest people go look at the raw entity registry to find the "true" color modes; and documented at least that some manufacturers do things inconsistent with the official docs.

Possible improvements: Measuring script

It would be useful if

• The power measurement script checked which color modes are advertised and
• The power measurement script then tried to use them, observing if the light stayed in the requested color mode.

This would remove a bit of the guess work, and allow errors to be raised if you are trying to measure a color mode that doesn't really exist.

Possible improvements: Entity setup

• Relax the initial setup check
• Let the power calculation entity / sensor raise an exception for unsupported color mode at run time / when observing the light

[bramstroker]

Yes this is definitely wrong. brightness must be the only supported mode for your light when it supports it.
When it has color_temp mode it can never has brightness. As you correctly found out this is also in the HA developer docs.

I will see if I can relax the initial setup check. There is also a check in place already for runtime, so maybe I can also remove the setup check. But is is also nice to give the user an error message asap, before they actually put the light in an unsupported mode.

Not sure yet if we need all this additional checks in measure script, need to think about that.

The real problem is the upstream component/integration being wrong. Could you file a bug report there?

[bramstroker]

Btw I have checked the support models list https://github.com/bramstroker/homeassistant-powercalc/blob/master/docs/supported_models.md.

I have found 3 models which we need to have a closer look at.

• lidl HG06106B (hs,brightness,color_temp)
• lidl HG06106C (hs,brightness,color_temp)
• signify LLC006 (hs,brightness)

These color_mode combinations should not be correct according to my understanding and HA documentation.

[CloCkWeRX]

Maybe the model.json validator could warn on a PR with invalid combos autpmatically?

[bramstroker]

Yes we can extend in https://github.com/bramstroker/homeassistant-powercalc/blob/master/.github/scripts/lut_validator/validate.js

[CloCkWeRX]

If you dont beat me to it, will try that this week

[bramstroker]

Sure, go ahead. I have also made an issue #965

[bramstroker]

You can just run this JS file locally by installing nodeJS, and than from the .github/scripts/lut_validator directory run node validate.js