Undoubtedly, the ESP8266’s biggest selling point is its WiFi capability for a ridiculously low price. Paranoid folks probably await the day its closed-source firmware bits will turn against humanity in a giant botnet, but until then, hobbyists and commercial vendors alike will proceed putting them in their IoT projects and devices. One of those devices is the Yeelight desk lamp that lets you set its color temperature and brightness via mobile app.
[fvollmer] acquired such a lamp, and while he appreciated its design and general concept, he wasn’t happy that it communicates with external servers. So he did the only reasonable thing and wrote his own firmware that resembles the original functionality, but leaves out the WiFi part. After all, the ESP8266 has still a lot to offer in its core essence: a full-blown 32-bit microcontroller with support for the most common, hobbyist-friendly SDKs.
The lamp’s color temperature and brightness are set with a rotary encoder / push button combo switch, and the LEDs themselves are controlled via PWM. All things considered, it’s a rather straightforward endeavour, for which [fvollmer] chose the standalone C SDK. And in the end, it’s not like he’s unreasonably cautious to keep some control over his household items.
For me it is surprising, that Xiaomi use ESP8266. I think espruna and tasmota will follow with their firmware.
Yeah. I got one of these and just assumed they used some broadcom chipset. Would love to get tasmota on here (like all my sonoffs). Default firmware is pretty crappy in other ways; the encoder feels sluggish and unresponsive. Would love to map the encoder “click” to other functions on my network.
Heck yeah, fvollmer, the less electronic hands on commands the better. Good job :)
So basically, he disconnected the lamp from WiFi with custom firmware? Hmm.
Basically he removed the “feature” that justified the purchase in the first place.
Good job on the execution – but you played yourself. I would have returned that lamp and be done with it. No proper product, no money.
“acquired” does not imply that he “purchased” it.
If he did purchase it, maybe its price was lower than other desk lamps with adjustable color temperature.
But, even so… how does an ESP8266 contact the mother ship, if you don’t allow it to pass through one’s router?
Far to many run their home networks without a proper router.
I think that’s how the UK dude from the news got his super-gonorrhea.
gonorrouter?
Chances are that the functionality is crippled or absent without uplink. Many manufacturers make calling home mandatory for basic ooeration. That might be the reason fvollmer wrote his own firmware.
Got that lamp. Works without connection.
This is why I, and many others, have been using the Sonoff-Tasmota software with many of my ESP8266. It’s being ported to the ESP32 also. Basically it gives you lots of options for control and access without the need for cloud connectivity. My recent TCF demonstration used an AP with no Internet connectivity to demonstrate this with Node-Red and MQTT.
https://github.com/arendst/Sonoff-Tasmota/wiki
http://ushomeautomation.com/Presentations/TCF2018/index.html
Well what are you doing on Had? This isn’t a website for people to talk about how thrilled they were that they left the product alone. Give me a break.
Can somebody explain to me why a desklamp would need remote control?
It’s a plot by the rotary encoder manuf.
Well I have the “old” Philips Hue Lamps which come with a wireless touch-remote to set the color and brightness. Which is fine.
I for myself cannot understand why in the life of me I would want APP support for a lamp … but yeah. to each his own I think :-)
Same as the wireless touch remote, but cheaper for the manufacturer. And you potentially get far-remote control (though how useful that _actually_ is is a different matter…)
It’s not so much the app, but the iftt that they have been including in the apps to help add the product into a home automation system. Personally, they need to stop and just make it run Mqtt, which would save the some money. They are just writing the app to harvest your data to sell to advertisers.
One use case for wifi control would be using Alexia or Google Home to have voice control of light.
Maybe something like “OK Google set desklamp to 50%” or controlled in a group “OK Google set livingroom to warm look” and the desklamp and other livingroom lights would switch from daylight to warm-white color temperature.).
To replace the original spy-firmware with a different kind? Nice.
Ah yes, i didn’t think of that. But still… fools and their money, eh?
nothing comes from nothing, so in the name of the holy business, you must cheat others to gain some :)
Because IOT! Putting the internet in things makes those things more important and more expensive. And that is what we want, our things being more expensive.
It could change colour temperature at sunrise/sunset for instance.
Very good question. And why do we need to be handing all our data over to perverse social engineers and Russian psyop spooks so we can bicker on social media and post gifs of cats and dogs? Or allow dubious AI into our house so we can play the wrong song from across the room with a voice command?
The answer is that people will take any long-term risk or cost imaginable for an infinitesimal amount of convenience. The next beta of humanOS will hopefully include a patch for our risk-reward analysis engine.
The most fundamental reason for me is to have a single point of contact to control my things. I hate remote hunting. Siri (or Alexa) is pretty cool to. I like that I can shut the house down with a single verbal command on my way out the door in the morning. :)
That being said, I don’t let that shit talk to the internet. Ever.
Fun fact: the ESP8266 SDK has a giant security bug ;-)
Steps to show why using chinese crap ain’t worth it:
1. Connect your ESP8266 to your WiFi network (secured with a password of course!)
2. Get yourself an extra router / the hotspot feature of your phone and give the second network the exact same SSID as your real network. Set the network security of this second network to “open”, or “no encryption”.
3. Disconnect your ESP8266 from your real wifi network, either by rebooting it or by turning your normal router off.
4. ???
5. Profit! (The ESP8266 just connected to the open network which just had the correct name… Even though you configured it to only connect to your network, with the correct password…)
I am still hoping that someday a manufacturer releases a cheap wifi capable IoT microcontroller without such basic mistakes… (Preferably with FOSS firmware)
(For those wondering: ESP32 refuses to connect but then also gives up on connecting. Doing this will thus result in a sort of “denial of service” type of situation)
All of that might be true, I did not verify, but it’s true for most all WiFi stuff and you really don’t have to pull up some anti-Chinese statements.
It’s the same with most Japanese and US and Korean and Taiwanese and and -name your target- stuff.
Please consider removing the link in the “not like he’s unreasonably cautious” text. The article eventually linked has been removed from Medium and comments explain that basically, the guy was all wrong in his security assessment.
Hi Jeppedy, do you have more on that? Send something to tips@hackaday.com or elliotwilliams@hackaday.com. We should probably run a story on that — how it was gotten wrong and what happened? If it’s interesting.
All I get out of that article is Medium’s “no post” page.
I completely understand why he doesn’t want his lamp to talk with servers beyond his control.
But I don’t really understand why he removed connectivity altogether. Why not keep WiFi and enable control from local network through MQTT?
If this is the only smart light or home automation device he has it wouldn’t really make sense. Controlling just one light wouldn’t be worth the time or financial investments.
???? esp8266 makes a great web server. Would totally make sense…
https://hackaday.com/2014/11/15/running-a-web-server-on-the-esp8266/
The Arduino libs for esp8266 make impmenting a webserver dead simple. Takes less than 10 lines of code.
Just an idea, but if protocol is simple enough it would be interesting to make local server (Raspberry Pi for example) and then redirect lamp’s communication to it, making it local and contained.
This comment chain makes my head hurt. Why not just write the firmware to host a web page on the lamp? Redirecting packets on your Lan and adding a dedicated server for a single lamp…well…never mind…have fun.
I see IoT and the only thing that makes sense to me is ‘Internet of Toasters’. Because worst case the only thing a hijacked toaster can do is burn down your house. There is NO security in this nation of budding bot nets. We have to be at the point today where a distributed attack to pulse co-ordinated loads onto the power grid will collapse several states at once.
Probably made possible by ‘Smart Home’ and Google.
There is also another firmware, but it uses Arduino SDK: https://github.com/Torxgewinde/Desk-Lamp-Alternative-Firmware
There is also a tasmota one as well
https://github.com/arendst/Sonoff-Tasmota/wiki/Xiaomi-Mi-Desk-Lamp
When something like this is done, does it meant the WiFi module is turned off and there will be no RF emissions?
Or is it just not successfully establishing a connection, but still be on?
If this is a silly question, apologies. I have no knowledge whatsoever in this field.
Thank you.
I haven’t tested or looked further into it, but based on the project’s source code, none of the module’s WiFi capabilities are used – or in other words, there’s not a single call to any wifi_xxx() function, so WiFi itself is never set up. As I understand it, the default behaviour in that case is to have the modem itself in sleep mode and RF indeed disabled.
The question comes from the fact that according to this discussion on the Arduino StackExchange website:
https://arduino.stackexchange.com/questions/43376/can-the-wifi-on-esp8266-be-disabled
it seem like the WiFi functionality needs to be explicitly disabled.
In fvollmer’s code, as you correctly recall, there is no reference to functions or instructions related to the WiFi, hence my confusion – do we need to explicitly disable or explicitly enable the WiFi functionality?
Does the different in the approach has anything to do with the Arduino way of doing things?
I only recently started learning this stuff, so I was hoping I could get an experienced opinion about that.
Hi,
I have a problem with Led driver…Have you a datasheet of it (3YH786) ?
Thanks a lot for your help.
Nicolas