Format fixes in light module #1874
Conversation
| double b = (double) ((target ? _light_channel[2].target : _light_channel[2].inputValue) * brightness) / 255.0; | ||
| double r = static_cast<double>(target ? _light_channel[0].target : _light_channel[0].value); | ||
| double g = static_cast<double>(target ? _light_channel[1].target : _light_channel[1].value); | ||
| double b = static_cast<double>(target ? _light_channel[2].target : _light_channel[2].value); |
There was a problem hiding this comment.
I noticed this strange calculation earlier. inputValue is value without brightness, so maybe it makes sense in that case. But it tries adjust it even with target which is set from value, thus displayed value could be wrong.
@CrazyIvan359 does checking for target flag makes any sense here at all? Web sends it with false, but mqtt reports with true... I am not quite sure what was the reason for this conditional.
There was a problem hiding this comment.
inputValueisvaluewithout brightness
This is why HSV commands resulted in the wrong RGB values, because inputValue was calculated from input HSV, then scaled by V.
I don't know what target is. I'm not particularly familiar with the codebase and my C is a bit rusty. I will have a look and test this out though, hopefully one night this week, Saturday at the latest. Thank you!
There was a problem hiding this comment.
OK! Thanks
bool target param for _toHSV(output, output_size, >> target <<) function, selecting channel.target aka value+brightness via ternary 'if' above.
Last change to this was 19d0c5d, which states to report target (adjusted) values to mqtt & web, but that only happened with mqtt (see lightColor(false) usage).
Maybe there's no need for conditional at all and it should always use adjusted value
|
Adding for #1763, to not forget to use lightMap(...) |
doubleinputsmap()with older cores, add warning