Depends on their integration, I have never tested the Stock H801 firmware as I flashed them as soon as they arrived 
If they are using fairly up-to-date versions of the standard ESP8266 libraries then to be honest they should also support WPA2.
This is a great project! I got all the parts and pieces needed and setup a H801 controller running 3 LED strips above and below a set of cabinets. I should add I was using a 12v 5A wall wart to power it. Everything was great so I moved on to install an identical setup on another set of cabinets on the other side of the kitchen. I bought the same items (same H801, same brand LED strips, etc…) as the first time except power was an issue so I got a 12v 10A power supply and wired it to a switch. Everything’s great EXCEPT the colors are different between the two sets. (ex: I tell both sets to display purple and while they’re both purple they’re noticeably different)
First thought was the different amps was making a difference so ordered a 2nd 12v 10A power supply, hooked it up and while it did change the colors it still doesn’t match the other set. I’m able to manually adjust one set to get it close to the other but it’s still slightly off.
Has anyone else run into a problem with colors not matching up between LED strips from the same manufacturer?
Every LED strip will be different since LEDs are made in batches and will have some differences. In addition different lengths of cable will put different drains on the transformer and controller, so may also have different colours.
That said i am surprised that you have really noticeable differences. Can i suggest swapping the controllers to see if it is the strip or the controller that is different. The other thing to check is whether the secondary colours are the same - i.e. Yellow, magenta, turquoise. I would hope it is only one channel (rgb) that is different, but perhaps they are all a bit different.
After i cant suggest anything other than to buy two LED strips at the same time.
What is the exact LED you ordered? Can you put up a link. Also when you say 3 LED strips, what is the total length in feet connected to each channel.
The same question for the new H801 you installed. How many feet per channel is wired.
It seems to me you might be overloading a channel or two?
This will help determine if you overloaded a channel. If there is no change when swapping H801 then that lends itself to different loads
This is the LED strip LEDENET 16.4ft (5m) 5050 300LEDs RGB+Warm WHITE Flexible RGBW Waterproof LED Strip Lighting Kit 5M RGBWW Strip Black PCB Board
By saying 3 strips I mean that I cut 3 segments off the spool. One long strip along top of cabinets and 2 smaller ones for the bottoms.
There was excess LED strip left over off of each roll so the total length is <16 ft I’d estimate the longest of the two is ~10-12 ft.
This might be the answer! My Amazon order history shows the same item Lixada 5-24V WiFi APP Controlled Smart Dimmer Wireless Receiver Output 5 Routes PWM Data for RGBW LED Strip Light Lamp however I seem to remember the label one of the H801s was different. (I’m at work without access to the devices)
This is a good idea and I feel dumb for not thinking of it! If this makes a difference I’ll just order 2 H801s and use the current two in other locations where the difference isn’t noticeable. I’ll swap units tonight and report back with the results.
Thanks for the help/ideas!
(edited for grammar and clarification)
I’ve been trying to flash my new H801 with the SmartLifeRGBWController.ino.generic.bin file using the suggested adafruit FTDI adapter. I’m on linux so this should be similar to any mac install but I can’t get the H801 to boot after flashing successfully.
Here is the report of the FTDI I have:
ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
usb 1-2: Detected FT232RL
usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
This particular FTDI module allows you to switch between 5v and 3.3v by using solder jumpers on the back. The default is 5v so I had to disconnect the jumper and connect the 3.3v jumper. I then verified that the VCC output was 3.3v.
When I flash this is the output I get from esptool:
# esptool.py --baud 74880 --port /dev/ttyUSB0 write_flash -fm=dio --verify 0x00000 ~xxxxxx/Downloads/SmartLifeRGBWController.ino.generic.bin
esptool.py v1.3
Connecting....
Auto-detected Flash size: 8m
Running Cesanta flasher stub...
Flash params set to 0x0220
Wrote 360448 bytes at 0x0 in 48.1 seconds (60.0 kbit/s)...
Leaving...
Verifying just-written flash...
Flash params set to 0x0220
Verifying 0x57670 (358000) bytes @ 0x00000000 in flash against /home/xxxxxx/Downloads/SmartLifeRGBWController.ino.generic.bin...
-- verify OK (digest matched)
At this point the D2 LED remains a constant green color and D1 never lights up. (when I first booted the device these lights were flashing like normal with the default firmware). To try and debug I started up miniterm.py with a baud rate of 74880 (this was suggested on the esptool github for debugging) and un-jumped J3. When I do this I see this error message repeated infinitely:
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v3de0c112
~ld
Fatal exception (0):
epc1=0x40226588, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
Fatal exception (0):
epc1=0x40226588, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
Fatal exception (0):
epc1=0x40226588, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
Fatal exception (0):
epc1=0x40226588, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
If I then reboot the device with J3 jumped again it go back into flash mode. I tried a few more options with esptool. I can do the “read_mac” and “chip_id”
# esptool.py --baud 74880 --port /dev/ttyUSB0 read_mac
esptool.py v1.3
Connecting....
MAC: a0:20:a6:1a:xx:xx
# esptool.py --baud 74880 --port /dev/ttyUSB0 chip_id
esptool.py v1.3
Connecting...
Chip ID: 0x011axxxx
I’ve also tried flashing with various other options and all result in the same outcome… a solid green D1 light with an infinite loop of fatal errors during boot. Looking further into the esptool website for troubleshooting, there was a suggestion that non-booting firmwares could be caused by low amperage. There were suggestions to add 10uf caps to the VCC line as well as verifying that at least 200mA was available. So, I added a few caps and verified that in my setup 700mA was available on the VCC (I ran another power supply (arduino 3.3v output) in parallel to boost the amps). I then restarted my efforts to flash the file. Again, the same results. The file would flash and verify a proper flash but then the H801 would just sit there with a solid green D1 and no SSID broadcast.
So, I guess I’m asking where do I go from here? Here is the MD5 sum of the file… maybe it is corrupt?
# md5sum SmartLifeRGBWController.ino.generic.bin
96cda681687d57776571914bc57d51bf SmartLifeRGBWController.ino.generic.bin
Thanks in advance to anyone that can help!
That is very strange, do you have access to a Windows PC at all? Whilst I would love to help it would be complete guesses on a Linux/Unix based system, especially if there are any differences in esptool…
If you want some guesses to try then I would start with the following:
- The serial adaptor does seem to be behaving strangely given miniterm gives errors and all that does is open the serial port from what I recall. Were you calling it with the right parameters? Or was the serial port already in use perhaps? If you cant get the serial adaptor working when just jumpered then it makes me think that is the current problem.
- If you get past that, do you get a different behaviour when you start the H801 when jumpered and when not-jumpered? (I dont mean the serial adaptor jumpered) If you dont see a difference in the LEDs then I would suggest that the H801 has been corrupted (and hence has been partially flashed).
- I find it strange that it finds an 8m flash chip, since I believe it is no more than 4m. Perhaps the serial adaptor is having some dodgy connection to the device itself.
Thats as much as I can help Im afraid…
From what I can gather, the miniterm output is coming directly from the H801 as a boot post… that is to say, it is showing debugging information printed by the H801 to the serial tx/rx. If I run the miniterm when booting into “flash mode” with the J3 jumper jumped I get this output (no error from the H801):
ets Jan 8 2013,rst cause:2, boot mode:(1,6)
the boot mode seems to change from (3,7) when booting from flash without the jumper to (1,6) with the jumper connected. I don’t know what those numbers mean for the ESP chip but it seems to me that it is a good indication the connection is clear and solid with the FTDI being able to read data.
I actually bought two of the H801 and haven’t touched the second one. I’m going to try and pull off the original firmware from the second one and re-flashing it onto the first one and see if that results in anything different (it would rule out it being the FTDI or my connection).
I do have access to a Windows™ and Mac machine… those will be last testing resorts 
Ah, so to test the FTDI you are supposed to jumpter the FTDI TX and RX and not having the H801 connected at all. Is that what you have been doing when using miniterm?
Having miniterm and esptool connected to serial at the same time can probably give problems (it does on Windows though that doesnt say much). When flashing I would just open esptool.py once the device has booted with J3 jumpered. If the device is receiving serial data then you should spot the LED flashing very quickly while data is received - that is a good giveaway and normally means you should get a good flash.
No the H801 is connected and J3 is jumpered. The H801 has a built-in boot debug on the ESP chip and miniterm is just reading those signals through the FTDI rx/tx pins. (like it does when it sends the file). I tried booting the unaltered H801 with miniterm connected and this is the output when booting with J3 unjumped and then jumped respectively:
ets Jan 8 2013,rst cause:2, boot mode:(3,0)
load 0x40100000, len 612, room 16
tail 4
chksum 0x12
load 0x3ffe8000, len 788, room 4
tail 0
chksum 0x50
load 0x3ffe8314, len 264, room 8
tail 0
chksum 0x4a
csum 0x4a
2nd boot version : 1.1
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size : 4Mbit
jump to run user1
-------- jumped j3 ---------
ets Jan 8 2013,rst cause:2, boot mode:(1,6)
␀
ets Jan 8 2013,rst cause:2, boot mode:(1,6)
ets Jan 8 2013,rst cause:2, boot mode:(1,6)
�
ets Jan 8 2013,rst cause:2, boot mode:(1,7)
ets Jan 8 2013,rst cause:2, boot mode:(1,0)
ets Jan 8 2013,rst cause:2, boot mode:(1,0)
idk what it means but maybe someone else does.
So just as an update… I have successfully restored the factory flash for the H801 (I did a flash_read from an unaltered one). I get a solid D2 in green and solid D1 in red with an SSID being broadcast.
This to me rules out the FTDI being the issue. I wonder if the H801 has a newer chipset that doesn’t work with the SmartLifeRGBWController.ino.generic.bin
The chip on the board isn’t a straight ESP8266 it has an EX at the end… ESP8266EX
https://espressif.com/en/products/hardware/esp8266ex/overview
Don’t know if that makes a difference
edit: read != red
Success! not really
Edit:
After setting up the H801, I noticed the mac address looked strange. It turns out the H801 that I flashed was the second one. So basically it flashed without issue. After I discovered this, I tried to flash the first H801 like I had planned… well it failed to boot after the successful flash. At this point I’m going to call the first H801 DOA and send it back to Amazon for another one. It must have been something I did because it did boot up once with the default firmware… Maybe I shorted something out or got disconnected that prevents it from accessing the firmware via qio during boot but can be written via dio for writing.
/Edit:
So, to re-upload the factory image to the first H801, I had to use different options to get it to load properly. (it never did verify the md5 sum but it booted ¯\_(ツ)_/¯ ). I threw caution to the wind and tried to re-flash the SmartLifeRGBWController.ino.generic.bin file but using the same options (basically not letting any defaults but specifying them even if they are default in esptool). Here is the command I used (and the progress):
# ./esptool.py --port /dev/ttyUSB0 write_flash --no-compress -fm=dio -fs=32m -ff=40m --verify 0x0 ~xxxxxx/Downloads/SmartLifeRGBWController.ino.generic.bin
WARNING: Flash size arguments in megabits like '32m' are deprecated.
Please use the equivalent size '4MB'.
Megabit arguments may be removed in a future release.
esptool.py v2.0-beta2
Connecting....
Detecting chip type... ESP8266
Uploading stub...
Running stub...
Stub running...
Attaching SPI flash...
Configuring flash size...
Flash params set to 0x0240
Wrote 360448 bytes at 0x00000000 in 32.3 seconds (89.2 kbit/s)...
Hash of data verified.
Leaving...
Verifying just-written flash...
(This option is deprecated, flash contents are now always read back after flashing.)
Flash params set to 0x0240
Verifying 0x57670 (358000) bytes @ 0x00000000 in flash against /home/xxxxxx/Downloads/SmartLifeRGBWController.ino.generic.bin...
-- verify OK (digest matched)
Staying in bootloader.
Then when I rebooted the H801 with J3 disconnected I got this in miniterm:
miniterm-2.py --exit-char 27 /dev/ttyUSB0 74880
--- Miniterm on /dev/ttyUSB0 74880,8,N,1 ---
--- Quit: Ctrl+[ | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
␀
␀
ets Jan 8 2013,rst cause:2, boot mode:(3,0)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v3de0c112
~ld
"8��
As you can see I also upgraded to the beta v2 version of esptool (though I had tried it before when it wasn’t working to no avail).
I’ll report back if flashing the second one with just the above command works. One thing that might have happened is the flash got corrupted somewhere the first time I flashed it and it wasn’t until I overwrote it with the factory firmware did it then allow me to flash the image properly. I wonder if the SmartLifeRGBWController.ino.generic.bin firmware utilizes something left over from the factory firmware? Maybe the first time I flashed the FTDI module wasn’t providing enough current and so it corrupted the flash (but then why after I corrected the current problem would successive flashing wouldn’t correct it?)? Hopefully the others work on the first try!
Gotcha, the point of connecting Rx and TX without the h801 is to check the
ftdi is working on its own, but based on the clear text responses it
clearly is. So just need to work out the h801 then.
I would suggest you keep on trying and perhaps the contact got moved a bit
while fishing to corrupt it. Some people have said it can take a few
flashes (up to lots e.g. 15!) though it’s always worked for me
That is strange. The people who have had failed flashes in the past have found that it was caused by a dodgy FTDI, however given yours is from Adafruit I would be surprised if it was dodgy. If it was from a dodgy seller on Amazon who was selling something whilst claiming it was an Adafruit then that would make sense.
The same people who had these problems with flashing found that by flashing multiple times back to back (up to 15) it eventually started working successfully. You can tell if it was successful because the LEDs change their status when the flashing has worked. Maybe worth a shot if another 10minutes saves the faff of an Amazon return.
I’ve got the H801 all setup and configured in Smartthings! Thanks everyone for the help so far. Everything works as far as I can see within the Smartthings App (I’m on Android). I can control my RGB strip just as expected (I don’t have W1 or W2 connected to anything).
The problem I’m seeing now is I’ve connected my Smartthings devices to the new Google Assistant. When I tell Google to change the light to “Red” the event log for the device shows that the setColor command was called as:
setColor([hue:0, saturation:100]) command was sent to Aquarium
What this appears to do is turn off all the RGB channels and then turn on the W1 channel to 100%. The command to turn lights red from google works with my OSRAM flex strip. The event log shows setColor gets the same command
setColor([hue:0, saturation:100]) command was sent to Kitchen Sink
I’ve tried to look into the device handler for setColor but haven’t seen where it would decided to switch to white if hue is 0 and saturation is 100. I’ll keep looking but if someone can see it right off the bat, I’d be more than appreciative.
I have a fix in place for this bug. I’ll try to release it tonight. The problem is that when value.hue is 0, that is interpreted as false (which throws off one of my if statements).
Edit: Actually, I just posted the fix, but have only partially tested it. You can try it if you would like and let me know.
Works for me!
I only applied the logic fix on line 418. Wasn’t sure what the change on line 466 with the uri = "/rgb?value=${dimmedColor.substring(1)}" being changed to uri = "/rgb?value=${dimmedColor}"
Is the .substring(1) just superfluous?
Well, I noticed that a character was getting cut off of my hex value which is why I removed it. That is the main reason it isn’t fully tested. It was initially there probably to remove the # sign in #ff00ff type of hex values, but the way things are working now it is only getting passed ff00ff (without the # sign). I need to see if there are any cases where this needs to be evaluated.
no sir 
I would stay away from that particular model
1 Like