-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Brightness Control for RGBLed #11
Conversation
Indicate it is created by RGB color mixing vs dedicted White LED. Also avoid conflict with the MACRO WHITE used with Adafruit OLED library.
To support a simpler brightness level change for the LED, made new _brightness private attribute. It initializes to 100 (full), and a new brigthness() method taking single int brightness to change created. And calls to setColor changed to call intensity with _brightness.
The brightness() functions that take a color and brightness updated to save the brightness value for later use.
Hello @hpreston, First of all thank you for the contribution, and the fact that the library is suitable for you waiting, however, I do not really understand how If it is really a problem, I will put a BREAKING CHANGE in the description of the new version. For brightness, it is indeed a good idea that I did not think of. And for the management of RGBW LEDs I am not against a contribution, because I do not have much time to spend at the moment. |
@wilmouths thanks for the quick reply. I wasn't happy having to make a change that was breaking. As I was putting together the details for you here, I actually found an alternative to fix the conflict that did NOT require changing the value here. I will update my PR to restore the value to But, in case you are interested in what I ran into, here are more details: Here is what I get when I try to compile when I have
I interpreted the above output to indicate that the use of the name I am not using the I dropped into GitHub code for the Adafruit library where the conflicting macro existed. It is here: https://github.com/adafruit/Adafruit_SSD1306/blob/master/Adafruit_SSD1306.h#L67 When I checked, I found the comment that the macro // Disable "old" color codes from library to avoid conflit with name WHITE
#define NO_ADAFRUIT_SSD1306_COLOR_COMPATIBILITY 1 And now when I try to verify my code I get NO error. |
After finding a way to disable the conflicting macros in the Adafruit library, putting these back to their original values.
Okay, I have updated the PR, restoring the I did add a |
Thanks @hpreston for this, as this is a feature I was looking for also. Hope to see these changes merged as they bring really welcome improvements to an excellent library. |
First, this is great Library. Exactly what I was hoping existed to save me time from having to start from scratch for my building of some LED light kits for my own use.
As I was working with it, I found I wanted to "store" the brightness level setting on the LED between changes. Kind of like a "master brightness knob" on a physical controller. Then any setting for a color would be automatically adjusted to the brightness level stored.
Most of what was needed for this already existed in the library, I just added in a new private attributed to the LED object for
_brightness
, and then updated the other methods to leverage theintensity
function instead ofcolor
, and use the_brigthness
property. This will make more sense when you look at the code submission.I have tested this change for the basic
setColor
,blink
, andfade
functions. And the existingbrightness
functions continue to work, and the setting forbrightness
is saved for use on later calls/changes. A newbrightness
method that just takes abrightness
value has been added to JUST set the brightness level.Another change you'll see in the PR is a rename of the
RGBLed::WHITE
toRGBLed::RGB_WHITE
. I made this change for 2 reasons. First, and most pressing is that the use of justWHITE
for the static conflicted with a defined macro in another Library I'm using to control an LED screen. That library usesWHITE
as the font color.I'm also looking at updating this library to support
RGBW
LEDs, so renaming theWHITE
color to indicate that it is created by combining RGB LEDs to create White vs a "native white LED" seemed a reasonable change.I hope you find this enhancement useful. If there are any changes you'd like to see before merging in, please just let me know.