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

Look in the log to see if there is anything unusual while changing the color. Set the device debugging level first in the SmartThings app.

Watch carefully in the log to see what hex value is being sent to the device. Should look something like 00ff00 and it should be part of a url that is being hit on the device itself. ie. /rgb?value=4affe9&channels=true&transition=0

Will do,

thanks

Hello again Eric,

not sure if this is what you need, or if it’s enough, but as an example, this is for the color red. I am giving you the log for one of my original H801 that performs correctly and the logs of one of my new units that does not.

Each log as 2 reading, the first is for the color red as selected from the main page of the app. Both units do pretty much the same thing and both colors are good.
The second is when I choose the red circle from the color selection page. I understand that this red is not the same and as a bit of blue in it, but it is mostly red.
With my old unit, I get a strong red, with my new one, I get green.

All my new units do this except one, which performs like the old one. Here are the log excerpts:

One of my new modules (incorrect colors)

11:14:30 PM: debug {“rgb”:“00f003”, “r”:“00”, “g”:“f0”, “b”:“03”, “w1”:“00”, “w2”:“00”, “power”:“on”, “running”:“false”, “program”:“0”, “uptime”:“0:11:25”, “version”:“2.0.6”, “date”:“Apr 10 2017 18:24:07”}
11:14:30 PM: debug /rgb?value=#ff0030&channels=false&transition=0
11:14:30 PM: debug setting color with hex
11:14:30 PM: debug setColor being called with [red:255, hex:#FF0222, saturation:99.21568, blue:34, hue:97.89196, green:2, alpha:1.0]
11:13:55 PM: debug {“rgb”:“ff0000”, “r”:“ff”, “g”:“00”, “b”:“00”, “w1”:“00”, “w2”:“00”, “power”:“on”, “running”:“false”, “program”:“0”, “uptime”:“0:10:50”, “version”:“2.0.6”, “date”:“Apr 10 2017 18:24:07”}
11:13:55 PM: debug /r?value=ff&channels=false&transition=0
11:13:55 PM: debug redOn()

One of my original (correctly working):

11:18:36 PM: debug {“rgb”:“ff0030”, “r”:“ff”, “g”:“00”, “b”:“30”, “w1”:“00”, “w2”:“00”, “power”:“on”, “running”:“false”, “program”:“3”, “uptime”:“2 days and 2:54:12”, “version”:“2.0.6”, “date”:“Apr 10 2017 18:24:07”}
11:18:36 PM: debug /rgb?value=ff0030&channels=false&transition=true
11:18:36 PM: debug setting color with hex
11:18:36 PM: debug setColor being called with [red:255, hex:#FF0222, saturation:99.21568, blue:34, hue:97.89196, green:2, alpha:1.0]
11:17:45 PM: debug {“rgb”:“ff0000”, “r”:“ff”, “g”:“00”, “b”:“00”, “w1”:“00”, “w2”:“00”, “power”:“on”, “running”:“false”, “program”:“3”, “uptime”:“2 days and 2:53:20”, “version”:“2.0.6”, “date”:“Apr 10 2017 18:24:07”}
11:17:44 PM: debug /r?value=ff&channels=false&transition=true
11:17:44 PM: debug redOn()

So there is the problem. For some reason one device is sending the color with a # in front of it. I’ll have to look to see what is going on.

Thanks,

let me know if you need anything else

I just posted a fix, but it looks like if the main level slider is used at least once before the color picker is, the bug shouldn’t ever appear. Out of curiosity you may want to try that before updating the handler (just to see). This would be why it is a rare occurrence.

1 Like

I just tried it, and of course, you are right. Using the main level slider first, fixes the problem.

And I understand why my old units didn’t show the problem. Simply because they are installed, so always powered. In that case you don’t need to first use the slider as it’s already activated.

Thank you kind Sir

1 Like

I had one of my units malfunction on me yesterday… The W1 channel would not shut off on the landscape lights when I put in the two 5 watt warm white floods on the single white channel.

The RGB side of things worked beautifully, but white refused to respond. It worked great the night before, but when I came home yesterday I noticed the white lights were on during the daytime, and would not shut off or respond to dim commands. I unplugged the unit last night until I could dig into it further.

I opened the landscape box up this morning and found this…


The circuit board is discolored at the transistor on the top edge in the image. The solder plane on the board that the transistor attaches to is the output for the W1 channel. On the backside of the board is where one of the two thick black wires is soldered that runs over to the W1/W2 pins.

This unit is my original H801 and has been running with no issues for quite some time. It wasn’t until I put two 12v 5 watt LEDs on that channel that it had problems. I picked up some replacements that I can flash and send out to interested parties and to replace this one… I’m thinking this isn’t an issue that should have happened on a unit designed to handle four amps of output per channel…

Anyone else noticing similar?

Yep, had a similar issue with one of my H801. Melt down on the W2 channel due to amps overloading

I’m curious about what you put on it that would have overloaded it? 12v at 10 watts is only .8 amps or so… If the output can handle 4 amps per channel then we either had bad units which worked perfectly without issue until scenario, or they are drastically overstating the load capability of the units. Which is scary.

I imagine it will probably be a combination of multiple issues:

  • I imagine the 4A rating is probably quite optimistic, especially if multiple chips are running at the same time since that would be a lot of heat that needs dumping. I will get the chip ID next time I open one up and check - quite often they need a proper heatsink at their current limits, and they clearly don’t have one…
  • I am not 100% confident that the 5W rating of an LED flood is accurate, there could easily be surges or fluctuations. Could be a figure quoted in output terms, in which case at an average efficiency they would be more like 12W input (unlikely I agree).
  • Could be just bad luck, all components have failure rates, especially cheap ones, one transistor dying isn’t the end of the world in large scale electronics and is why large safety factors are often applied.

Could you take a photo of the backside of the PCB as Id like to look at that too if poss?

I used a multi-meter with current capabilities to verify actual current draw. Theoretically you shouldn’t have an issue but in real life something else is going on that your volt-amp meter will help you trouble shoot. You are assuming the issue is on the H801 which is of course a possibility but you need to consider the entire system which is your landscaping light spec is off or your installation of wiring is imparting the amps due to poor connections or too small, your power supply is undersized, etc. In my case the amp draw of the dual row LED’s was indeed higher than stated. If I remember correctly I ran a separate spare channel out midway , or I did just a separate power supply to boost. It wasn’t on my home system so I can’t go look right now.

EDIT: I posted this back in February [OBSOLETE] SmartLife (H801) RGBW LED Strip Wifi Controller & Bulb - #517 by dalec I used this RGBW Amplifier to fix my issue.

https://www.amazon.com/LEDENET-Amplifier-Repeater-Channels-Aluminum/dp/B00MN7AFLC/

Checked the datasheet from online:

They are very highly spec’d MOSFETs actually so I am happy they are well chosen. At 1A they will be sinking about 0.75W due to the 0.75V Vds(on) voltage which is not insignificant if they are not given something to sink heat into… Hence design isnt amazing though choice of component is good.

1 Like

Both of you make very fair and valid points. It’s possible that the LEDs are drawing more than they are advertised at. I’ll pull the meter tonight and do some testing. The transistor is the LR024N. It likely does need a heatsink, though they are using the board traces and contact pads as the thermal sinks.

I think on the new units and my last existing unit I’ll throw some adhesive thermal sinks across the top of the transistors to ensure they don’t repeat this issue… On that note, I still have some rail mounts and header clips that will allow me to build module dock-n-lock units to plug these into… Removing the case would allow larger heatsinks, though I don’t intend to run them under heavy load…

This unit still operates for RGB, and likely W2. I’ll throw it in a non-critical function with some heatsinks to see what happens. It’s possible W1 will continue to work properly now that it has cooled down and is no longer in thermal runaway.

Mine worked very intermittently after my melt down and I ended up taking it out of service. Let me know how yours works.

FYI Dont put a single heatsink across all of the units unless you use an insulating paste and are very careful. Because they have their tab as the drain and heatsink it will effectively short circuit all of the MOSFETs to ground (if any of them are on) and give you white light at all times.

P.s. Interesting, they have changed the MOSFET they use… they used to use 20N06L but now you have one with a LR024N. I wonder if it is related to supply / price / specs… Each chip seems to have some good specs and some bad ones though I havent checked price!

Yup. :slight_smile: The tabs on these are soldered direct to board, using the board traces as the sink. So the heatsink I apply would be to the case of the transistor. It would sink some heat, though much less efficiently than if it was direct to metal.

Also, this unit is one I’ve had for just under a year now? Shortly after this thread was started. They may have changed the designs a bit since then… Perhaps the load rating changed in the later designs?

I have one new one that is running one of the landscape channels. I can open it up and note any difference between the two. Perhaps the newer units are rated for the higher load, and this, being an older unit, isn’t capable?

Hey, Eric (or anyone else)…if you screwed up the import program string, is there an easy way to delete it? Apparently I messed up and now when I tried to configure Program #3, it doesn’t allow me to go into the settings. Also, when I try to add another program, it fails with “unexpected error” probably due to the screw up on Program #3. I looked in the IDE and couldn’t find a way to delete the program (and i’d prefer not to delete the entire light).

EDIT: So I’ve definitely messed this up. When I turn it on and off it fires a cycle of “Police” and then turns on and off. ST main slider shows off when lights are on and on when they are off. When I go into the browser and look at the device without ST, hit “Config” and then get “Success:False” and it turns the lights off. Please tell me I don’t have to climb up 10ft and pull the device and reflash (and re-setup all the CoRE pistons).

EDIT #2: So to keep the peace in the house, I completely deleted the device and the SmartApp. Re-added the SmartApp and then Re-added the controller. Back to normal…at least it will be once the four pistons are updated. Word to the wise…save yourself some trouble and cut/paste the imports. I tired typing them in and I think that’s what cause this mess. Have a great rest of the weekend.

I ordered six more of the H801 units. They arrived today.

I’ve soldered header pins to the serial connector and the J3 jumper to allow easy reflashing and/or wiring up a momentary contact switch for the purposes of controlling the LEDs with a momentary contact.

They are now all flashed successfully, connected to my wireless, and I’m in the process of testing them all one by one with an RGBWW LED strip to confirm full functionality.
I’m going to let three or four of them go once I reset the software on them…

Anyone interested in picking them up pre-flashed and tested?