Closed JohnTRoth closed 4 years ago
That's a tricky decision... I put in the W parameter despite the plugin not actually supporting the W section of LEDs, as a shortcut to setting the RGB values the same (therefore white). I will think about how to not potentially break this for others, my first thought is to prioritize the RGB values over white, if they are both included for this type of strip.
Changed the priority to make R/G/B parameters come above W parameters. Hopefully should not be too much of a breaking change, since there is no true W support in the plugin, and if users are typing commands manually, then they were wasting time typing R/G/B and then W would override it. So hopefully this is the right way around.
Implemented for 0.6.0.
Hey @JohnTRoth - could you test 0.6.0-rc.1 with this feature in it?
Can be installed by using the following URL in plugin manager > Get more > ...from URL:
https://github.com/cp2004/OctoPrint-WS281x_LED_Status/archive/0.6.0-rc.1.zip
Please provide general feedback in the feedback ticket - an 'all is working fine' is valuable feedback since it lets me know people are testing this release. Thanks!
I am currently using your plugin with the M150 Control plugin, but just have RGB lights. The M150 plugin sends the W parameter with every M150 command. When that command is intercepted, it is being ignored (or flagged as invalid) due to the W parameter.
It sends: M150 R0 U98 B255 W160 P255
If I remove the W160 and resend it, it works great. I believe the W should be ignored if sent for a strip that doesn't support it.
By the way - thank you for directing me to your plugin from the RGB_Status one I was using. You've done a great job with this!