fix: check brightness is set before attempting to map the range #1057

[dhutchison]

This fixes #1057, or at least my instance of the issue.

It introduces a check to ensure the self._brightness property is set before trying to map it into the range.

I'm not sure what type of testing this project usually required, I've only performed manual tests with a modified version of the component including this one line change and it seems to fix the problem.

[dhutchison]

Is there anything else that needs done before this can get closer to being merged? Guessing it needs an approval from an admin, (I can't remember how to find who are the writers to the repo on GitHub again...) to allow automated tests to be ran?

@CloCkWeRX do you know? (just stumbled across #781 and a few other issues & seen how active you seem to be in this project)

[CloCkWeRX]

So, it generally helps if you've got someone else experiencing your issue, who can test your patch locally / independently.

In this case it seems pretty safe - so safe I adopted a similar change on my fork (324dcd43):

 +        if self._brightness == None:
 +            return None
 +        if self.is_color_mode or self.is_white_mode:

Maybe also mark this PR as fixes #337

As I run my own fork, I integrate things that seem stable, if you feel like living on the edge - add a custom HACS repo for https://github.com/CloCkWeRX/localtuya-experimental (be sure to review the compare view though! https://github.com/rospogrigio/localtuya/compare/master...CloCkWeRX:localtuya-experimental:master )

[CloCkWeRX]

@rospogrigio this one or 324dcd43ca132efd1b695428f1752b80f412198c would be worthwhile merging. I've been running this locally, happily for some time. The code is basically equivalent.

[dhutchison]

I know how much of a can of worms it could open, but would attempting to add some sort of skeleton for unit tests be a benefit?

[pergolafabio]

Hi, is this project still active? Seems this PR is going stale?