If necessity is the mother of invention, then inconvenience is its frustrating co-conspirator. Faced with a finicky dryer that would shut down mid-cycle with a barely audible beep if its load was uneven (leaving a soggy mass of laundry), [the0ry] decided to add the dryer to the Internet of Things so it could send them an email whenever it shut itself down.
After opening a thinger.io account, adding the soon-to-be device, and setting up the email notification process, [the0ry] combined the ESP8266 Development Board, a photosensitive resistor, and a 5V power supply on a mini breadboard. All that was left was to mount it on the dryer and direct the LDR (light-dependent resistor) to the machine’s door lock LED to trigger an email when it turned off — indicating the cycle had finished or terminated prematurely. A little tape ensured the LDR would only be tripped by the desired light source.
If you’re an apartment-dweller have WiFi in the wash area it would be awesome to see a battery-powered version you take with you. But in general this is a great hardware blueprint as many device have status LEDs that can be monitored in a similar way. If you want to keep the server in-house (literally in this case) check out the Minimal MQTT series [Elliot Williams] recently finished up. It uses a Raspberry Pi as the center server and an ESP8266 is one of the limitless examples of hardware that plays nicely with the protocol.
We love seeing hacks like this because not only does it conserve water and energy by reducing instances of rewashing, but it’s also a clever way to extend the life of an appliance and potentially save hundreds of dollars in replacing it. Add this to the bevvy of hacks that add convenience to one’s home — some of which produce delicious results.
It’s no secret that we love the ESP8266 chip, and the community of hackers that have contributed to making it useful. We often joke about this or that new WiFi-enabler being an ESP8266 killer, but so far none have stepped up. Here we go again!
Espressif has released a chip that’s going to be an ESP8266 killer, and no, it’s not the ESP32. The ESP8285 went into mass production in March, and should start to appear in the usual outlets fairly soon.
What makes it an ESP8266 killer? It’s an ESP8266, but with the flash memory onboard. Nothing more, but also nothing less. What does this mean? Tiny, tiny designs are possible. And, if the street price ends up being right, there’s no reason you wouldn’t opt for built-in flash. (Unless you were planning on doing some ROM hacking.)
[David] created a great looking e-ink WiFi display project that works a little like a network-connected picture frame with a few improvements over other similar projects. With the help of an ESP8266 it boots up, grabs an 800×600 image over the network, updates the screen, then goes back to sleep. Thanks to some reverse engineering, he was able to make his own firmware for the onboard controller to handle the low-level driving of the display. Since e-ink displays require no power to hold an image and the rest of the unit spends most of the time either asleep or off, power use is extremely low. [David] hopes to go months without needing to recharge the internal lithium-polymer battery.
We previously featured another WiFi-connected e-ink display project that was in fact also the inspiration for this version. [David] uses a 4.3″ 800×600 GDE043A e-ink display and wrote his own firmware for the STM32F103ZE ARM CortexM3 SoC used as a display controller, a process that required some reverse engineering but was aided by the manufacturer providing a closed-source driver for him to use. [David] writes that some reverse-engineering work for this display had already been done, but he had such a hard time getting a clear understanding from it that he reverse engineered the firmware anyway and used the documents mainly for validation and guidance.
As a result, [David] was able to make use of the low-level driver electronics already present on the board instead of having to make and interface his own. E-ink displays have some unusual driving requirements which include generating relatively high positive and negative voltages, and rapidly switching them when updating the display. Taking advantage of the board’s existing low-level driver electronics was a big benefit.
The ESP8266 rounds out the project by taking care of periodically booting things up, connecting to the wireless network and downloading an image, feeding the image data to the STM32 to update the display, then disconnecting power from all non-essential electronics and going back to sleep. We especially like how the unit automatically creates a WiFi access point to allow easy (re)configuring.
There’s one more nice touch. [David] goes the extra mile with server software (in the form of PHP scripts) to design screens for the display with data like weather forecasts, stock prices, and exchange rates. Check it out in the project’s github repository.
There’s nothing to be ashamed of. It’s a problem we all have. You change your code a lot — you can’t help it, you just need to tweak one last little bit. And then you have to go downstairs, fetch your ESP8266 module, plug it in to your computer, flash the new firmware in, and then run back down and re-install your wine-cellar temperature monitor. If only there were a way to continuously update your ESP8266 over the air, pulling new code down from your GitHub repository, automatically running your test suite on it, and then pushing it off to the ESP.
OK, it’s ridiculous overkill, but [Daniel] strung together a bunch of open-source continuous integration tools and made them work with the ESP8266. A simple PHP script connects the ESP to the rest of the web infrastructure.
[Daniel] says the word “security” in the same way that gin aficionados whisper “vermouth” over their Martinis. Which is to say, there is none. But for a home solution, or if you want to play around with continuous development, it’s a good start.
And this is a cool project because it makes use of the ESP8266 OTA (over-the-air) programming library to push the code across. And we do hate having to run around the house to update firmware.
So check it out if you want to push code to your ESP8266s without physically going to fetch them, or if you want to integrate your web development with your home deployment.
Your multimeter is probably your most useful instrument if you work regularly with electronics. It goes with you everywhere, and is your first port of call in most cases when you are presented with a piece of equipment. And when you think about it, it’s a pretty amazing instrument. Multimeter technology has advanced to the point at which even an inexpensive modern device has functions that would have required a hefty budget a few decades ago.
There is still one thing affordable multimeters remain unable to do: they can’t log their readings for analysis on a computer. They’re an instantaneous instrument, just as they always have been.
Lord of Hackaday [Sprite_TM] decided to hack his multimeter to serve its readings over Wi-Fi. Rather than start with a throwaway meter from the bargain bin, he did it with a Fluke. The meter he chose was a Fluke 15B+, the company’s budget offering for the Indian and Chinese markets, since he had one spare.
Opening up the 15B+, he was presented with its processor concealed under a blob of epoxy and thus unidentifiable. Armed with the knowledge that other similar Flukes contain Fortune Semiconductor parts, he investigated as many data sheets as he could find from the same company and finally identified it as an FS98O24 one-time-programmable microprocessor. Sadly this chip has no serial port, but he did find an I2C EEPROM which he correctly guessed held calibration settings. Removing this chip gave him a meter with slightly off calibration, but also gave him a serial port of sorts.
Further detective work allowed him to identify the baud rate, and supplying random commands delivered him some that returned data packets. Eventually he identified a packet containing the states of the LCD’s segments, from which he could derive its displayed value. Connecting an ESP8266 module with appropriate software left him with a Wi-Fi connected multimeter. There was a little more refinement to his hack, he created a power management board to activate the ESP when needed, and a neat hack to display its IP address on the screen.
Gerrit and I were scoping out the Intel booth at Bay Area Maker Faire and we ran into Nolan Moore who was showing of his work to mash together a Nintendo Power Glove with an AR Drone quadcopter. Not only did it work, but the booth had a netted cage which Nolan had all to himself to show off his work. Check the video clip below for that.
The control scheme is pretty sweet, hold your hand flat (palm toward the ground) to hover, make a fist and tilt it in any direction to affect pitch and roll, point a finger up or down to affect altitude, and point straight and twist your hand for yaw control. We were talking with Nolan about these controls it sounded sketchy, but the demo proves it’s quite responsive.
The guts of the Power Glove have been completely removed (that’s a fun project log to browse through too!) and two new boards designed and fabbed to replace them. He started off in Eagle but ended up switching to KiCAD before sending the designs out for fabrication. I really enjoy the footprints he made to use the stock buttons from the wrist portion of the glove.
A Teensy LC pulls everything together, reading from an IMU on the board installed over the back of the hand, as well as from the flex sensors to measure what your fingers are up to. It parses these gestures and passes appropriate commands to an ESP8266 module. The AR Drone 2.0 is WiFi controlled, letting the ESP8266 act as the controller.
In this installment of Minimal MQTT, I’m going to cover two loose ends: one on the sensor node side, and one on the MQTT server side. Specifically, I’ll tackle the NodeMCU’s sleep mode to reduce power and step you through bridging MQTT servers to get your data securely out of your home server and into “the cloud”, which is really just other people’s servers.
If you’re just stepping into this series now, you should really check out the other three posts, where I set up a server, then build up some sensor nodes, and then flesh-out a few ways to control everything from your phone or the web. That’s the coolest material, anyway. This last installment just refines what we’ve built on. Let’s go!