I got a weird result happening with my H801. If I send it a specific color, it doesn’t set that color exactly:
For example if I set it to: #240d0e it sets the color to #200c0c
Why would it do that?
curl -s http://172.16.0.121/rgb?value=240d0e
{"rgb":"200c0c", "r":"20", "g":"0c", "b":"0c", "w1":"00", "w2":"00", "power":"on", "running":"false", "program":"", "uptime":"6 days and 16:39:43", "version":"2.0.6", "date":"Mar 21 2017 22:35:01"}
Edit:
I did some more testing, it seems the values are consistently counted in 0x04 increments. So only values 0x04, 0x08, 0x0c, 0x10, etc are available. The values for these are set at 0x04 increments with an off by one error from 0x00. So, 0x00-0x04 = 0x00; 0x05-0x08 = 0x04; 0x09-0x0c = 0x08, 0x0d-0x10 = 0x0c, 0x11-0x14 = 0x10
# curl -s http://172.16.0.121/r?value=01
{"rgb":"00ffff", "r":"00", "g":"ff", "b":"ff", "w1":"00", "w2":"00", "power":"on", "running":"false", "program":"", "uptime":"6 days and 20:52:38", "version":"2.0.6", "date":"Mar 21 2017 22:35:01"}
# curl -s http://172.16.0.121/r?value=02
{"rgb":"00ffff", "r":"00", "g":"ff", "b":"ff", "w1":"00", "w2":"00", "power":"on", "running":"false", "program":"", "uptime":"6 days and 20:52:41", "version":"2.0.6", "date":"Mar 21 2017 22:35:01"}
# curl -s http://172.16.0.121/r?value=03
{"rgb":"00ffff", "r":"00", "g":"ff", "b":"ff", "w1":"00", "w2":"00", "power":"on", "running":"false", "program":"", "uptime":"6 days and 20:52:43", "version":"2.0.6", "date":"Mar 21 2017 22:35:01"}
# curl -s http://172.16.0.121/r?value=04
{"rgb":"00ffff", "r":"00", "g":"ff", "b":"ff", "w1":"00", "w2":"00", "power":"on", "running":"false", "program":"", "uptime":"6 days and 20:52:44", "version":"2.0.6", "date":"Mar 21 2017 22:35:01"}
# curl -s http://172.16.0.121/r?value=05
{"rgb":"04ffff", "r":"04", "g":"ff", "b":"ff", "w1":"00", "w2":"00", "power":"on", "running":"false", "program":"", "uptime":"6 days and 20:52:46", "version":"2.0.6", "date":"Mar 21 2017 22:35:01"}
@erocm1231 what math are you doing to convert the input values to pwm signals? My guess is you are (rightly) converting it to the pwm range for the esp8266 clock of 0-1023 (which if you take 1023/255 you get just a tiny bit over 4) or you have a linear lookup array of values to try and “brightness correct” the rgb values? Is there anyway to have it follow the input and not modify it?
Edit 2:
There is definitely a bug in the math of the firmware. It appears the following is going on to convert RGB-input to RGB-output. If you assume RGB is split and converted the decimal… the following algo would produce what is being seen when going from input to output
If we take just R… where R is R-input and R’ is R-output
R’ = floor(floor(R / (1023/255)) * (1023/255))
It is as if the R is incorrectly converted to RGB from PWM and then converted from this bad PWM to PWM again!
The proper alog should be
R’ = floor((R * (1023/255)) * (255/1023))
Notice the missing internal floor to retain significant digits after the decimal place. Or if in a real world situation like the firmware
int rgb = 8;
float pwm_sig = rgb * (1023.0/255.0);
pwm = (int) pwm_sig;
analogWrite(PIN, pwm)
int rgb_output = (int) (pwm_sig * (255.0/1023.0))
Not knowing how the actual code is setup, this is all conjecture… but the broken algorithm provided would make sense as to being the source of a bug.