It’s the end of another decade, and while we don’t have real hoverboards, flying cars, or affordable dental care, we do have multicolored lightbulbs you can control over WiFi. [Don Howdeshell] picked up a couple of cheap Merkury branded units in a Black Friday sale, and quickly set about hacking them.
By and large, many of these bulbs are manufactured by various companies and rebranded for whoever happens to place an order. The bulbs tend to use the Tuya IOT ecosystem. Based on the ESP8266, reflashing the bulbs with custom firmware is simple, thanks to the Tuya Convert project. Using a Linux computer with a WiFi card running in Access Point mode, it spoofs a server that tricks the Tuya product into downloading a firmware update. From there, the bulb is an open book, ready to do your bidding.
One of [Don]’s attempts didn’t go so swimmingly, however. Flashing the firmware failed and the bulb was non-functional. [Don] elected to to a teardown, photographing it for our perusal, before hooking up to the ESP8266 directly over its serial interface. From there, it was simple to reprogram the bulb with Tasmota firmware, getting it back up and running.
Security alone is a great reason for running your own firmware on IoT devices. It never hurts to know what you’re connecting to your network!
No made but designed by Tuya.
Interesting… I did not know that. Thanks for the clarification.
Sort of like how Trident Microsystems “didn’t make videocards” despite the many thousands (or millions) that were out there with their company name, logo, URL, FCC:ID numbers etc on the PCB.
What Trident did was *design* video cards and manufacture video chips. They made “reference kits” as “samples” intended for manufacturers to use as a base to work from to do their own things like modifying the video BIOS and drivers.
But Trident would sell anyone as many “samples” as they wanted – in pieces – along with providing the reference drivers. Since Trident didn’t solder the pieces together and didn’t provide things like boxes and manuals or driver install disks they claimed they weren’t the manufacturer, despite all of Trident’s info imprinted on the PCB which they either made themselves or had made to include with their “samples”.
Being a sneaky “not a manufacturer” that way did work in the PC owners favor because of the very very few companies that didn’t simply solder together the kits and stuff them in their own boxes, most of those few *did* do things to the stock BIOS and drivers so when those companies went out of business or stopped support, the reference drivers wouldn’t work. So one could have two cards with the same Trident chip, one an assembled kit, the other all but the Trident PCB markings identical, and the not-actually-Trident card would max out at working with Win98 original while the actually-Trident card could work with 98SE, 2000, and perhaps even XP.
Pretty certain Tuya is just doing the designs and host the smart platform.
Then you make the hardware off there design and plug it into their backend.
tuya provides the firmware and infrastructure for cloud connectivity. hardware is made by different manufacturers.
A “Merkury” brand sounds like it should be a CFL. :)
I ended up flashing a lot of ESP8266 sockets to Tasmota and it has been a dream in terms of reliability. I tried the Tuya Convert route but could never get it to work – I ended up just opening up the devices and soldering programming wires and manually flashing one at a time.
I had been through a *lot* of z-wave, zigbee and other devices which just weren’t reliable. Home-brew set ups with USB-dongles, paying for SmartThings, Hue, Ikea and others … nothing seemed to work reliably.
Now I have a MQTT broker running on a RPi and talking to ESP8266 sockets over wifi and it has been 100% rock-solid and pretty much bullet proof. I use OpenHAB for cloud/phone integration and it is also pretty decently reliable compared to commercial offerings. I personally found that there is a lot of value in relying on wifi vs z-wave et al – just being able to ping the devices makes a huge difference!
Of note: with this bulb running the Tasmota firmware, it is apparently possible (and quite easy) to have both the white LEDs and the color LEDs powered simultaneously (by having both the color and white sliders moved past the ‘off’ / completely dimmed setting). Doing so will lead to overheating of the bulb, which itself leads to crashes & reboots about every five minutes. I am unsure how to easily fix this issue using Tasmota, but by controlling the bulb through Home Assistant instead of directly through the integrated web server I have been able to avoid falling into this particular trap.
Ha, I went through a very similar process last year as well!
https://newadventuresinwi-fi.blogspot.com/2019/11/brilliant-wifi-a60-globes-rgbw-20699.html
Wow! I think I actually came across your blog when I was working on this. Glad to know you’re a fellow HaD’er.
Anyone know if the Techin/Teckin bulbs on amazon work with this? I’ve had a few of them recently (but don’t currently own any to crack open and check) and loved the hardware but not the software. Tasmota on these would be a dream come true!
I’m a bit late to this party but a good place to start is look up the MAC address, if it has an Espressif MAC then it’s an ESP826x series chip in there and it should work. I recently got some Feit bulbs at Costco that were supposed to be ESP8266 based but it turned out they had changed to some other chip which can’t be reflashed.
My apologies for the Necro post here, but have any of you moved on to wifi ip cameras? I’d really like a custom firmware solution for those socket based ip cams that all seem to be manufactured similarly, for similar security purposes.
Try OpenIPC or Thingino?