[OBSOLETE] SmartLife (H801) RGBW LED Strip Wifi Controller & Bulb

Yes I did save and publish after the changes. The firmware version 2.0.6 Mar21,2017 and I did NOT have the latest DH changes from a few days ago. I am updating from Repo now. It looks like I was behind on all @erocm1231 device handlers that I have several of.

Just to confirm: Based on the latest code in GitHub, I am updating the code on line 577-592 with your changes, correct?

Also just for my own sanity; When I do an Update From Repo and I get a successful execution and several device handlers (or smartapps are updated) do I still need to go in and do a Save/Publish?

UPDATE: That did it! so one of my H801 is still acting weird and not tracking perfectly like all the others so I think it must be an old firmware and I am going to reflash that OTA.

Yeah, just the huesatToRGB function… nothing else should need to be different.

I wish I could answer about the ST IDE… I usually just copy and paste the code there! Someone smarter than me, I’m sure, can answer that question.

Well… the wife acceptance factor on this started on the edge of a cliff… she wasn’t a fan. I set up the police light program this morning and showed my 7 year old son how to activate it with Google Home. Of course, at dinner this evening, he couldn’t help himself… “Okay Google, Turn on the police lights”.

… wife acceptance factor dove off the cliff.

5 Likes

Yes, no updates or new pulls are live with SmartThings until they are published. You’ll notice the status in the API showing that you have made changes, the status field will say “Edited”. The edits don’t get pushed into use until they are “published”.

@cjcharles and @dalec I figured out my issue with the AngryIP scanner. After running the scanner I couldn’t see the ESP in the list then it dawned on me that my wireless router and my ST are plugged into the same switch. No Ethernet cables are plugged into my wireless router, so I ran an Ethernet cable to my wireless router to ST and viola my ESP discovered in the SmartLifeRGBW Light (connect) App. Now I just need to rerun my cables to make everything look pretty again (somebody doesn’t like the looks of it) lol.

Thanks so much for the suggestions to get me on the right path!

1 Like

Hey All,

I installed all the updates from Eric, and re-updated the code from David and I am happy to report that everything works perfectly. The primary colors come out 100% and secondary are the best I’ve had so far.
Really happy with the results. Thanks again to everyone involved.

1 Like

I have merged @daved314 s huesatToRGB change in github. Thanks @daved314 !

2 Likes

I’ve updated the firmware to the latest “SmartLifeRGBWBulb.ino.generic.bin” but i am still having issues with the controller losing it’s WiFi settings. Is there anything I can do to help it?

tell me what does your device handler report your firmware version to be at in the lower tile?

Way to go @daved314, being a contributor to Eric is pretty cool stuff… for me I just consume all his great code. :slight_smile:

Got a stumper for you… I have one finicky H801 that doesn’t seem to be taking the color commands correct from Google Home. The others are going as expected. But the one having issues is responding as follows:

If I say

  • turn RED the channels are R=0% G=94% B=0%
  • turn GREEN the channels are R=0% G=4% B=94%
  • turn BLUE the channels are R=0% G=0% B=4%

Things I have tried so far; cycle power to H801, reset H801, reloaded the current firmware OTA to the H801, Nothing so far has worked.

Can you explain where is that "lower tile"
I haven’t seen that

Never mind, just found it. :confused:

1 Like

Firmware 2.0.6
Mar21 2017

I don’t know what to say… I am using that version and my WiFi settings are staying intact.

What are the conditions for it losing WiFi settings? Power surge, pulling plug, something else?

Also, do you have a switch attached to J3?

I have a small question, I use smart lighting to controls de led. I’m trying to create an environnement where when my mode is on TV, I only light up the leds in my kitchen and living room with the color cyan(for exemple). I cannot find a way to change the color to white when there is motion in the kitchen and after 5min when motion stopped, go back to cyan.
Any idea how I could configure this?

Thanks!

Not sure if Smart Lighting can do what you are asking… however CoRE can.

2 Likes

I’ll give a try, thx!


Oh wow, this thing is crazy, you can do anything

2 Likes

I don’t think it is related to any power surge or outage. The only thing i can think of is my wifi is a little sketchy, so maybe it loses its wifi connection for a minute and falls back to the default ESP one?

I do have a switch connected, one i modified to be momentary like in one of the videos. I recently turned off the j3 reset, I’ll see if that helps.

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.