IoT has become such an polarizing, overused term. But here it is in its essence: [zeroflow] had a thing (his airconditioner) and he needed to put it on the Internet.
For his contribution to this modern vernacular atrocity, he first had to build an IR debugging tool and reverse engineer the signals coming from the air conditioner’s remote. He wrote up a really good summary of the process, and worth reading. He loads up an IR library onto an Arduino and dumps the resulting 32 bits of information to his computer. In a process much like filling in the blanks on a word puzzle, he eventually determines which blocks of the data correspond to the remote’s different buttons.
Next he throws an array of IR LEDS and an ESP8266 onto a bit of protoboard. After writing some code, available on GitHub, he could set the temperature of his room from anywhere on the planet. We take it on faith that [zeroflow] has a compelling reason for doing so.
Bolstered by this success, he didn’t stop there. [Zeroflow] admits to having more than one thing on the Internet. Boom! Internet of things.
In a lot of ways, portable toilets are superior to standard indoor-plumbing-style toilets. This is mostly due to the fact that they have a status indicator on the door. It’s a shame that no indoor bathrooms have figured this out yet, especially in office buildings where your awkward coworkers bang on every door rather than just check for feet in the huge gap that for some reason exists between the floor and the stall door. Anyway, [Chris] and [Daniel] came up with a solution for this issue, which also eliminates wait time for bathrooms in their office.
Their system is an automated bathroom status indicator that reports information about the bathroom’s use over WiFi. Since the bathrooms at their facility are spread out, it was helpful to be able to look up which bathroom would be free at any given moment. Several Raspberry Pis form the nerves of the project. Custom sensors were attached to a variety of different door locks to detect status. Each Pi reports back over WiFi. This accomplishes their goal of being subtle and simple. They also point out that they had to write very little code for this project since there are so many Unix and embedded hardware tools available to them. Checking the status of the bathroom can be as simple as running netcat.
If you’re looking to roll out your own bathroom status monitor solution, [Chris] and [Daniel] have made their code available on GitHub. There are a number of other ways to automate your bathroom, too, like switching the exhaust fan on when it gets too smelly or humid, or even creating a device that dispenses your toilet paper for you.
In a world full of products that are only used for a brief time and then discarded, it gives a lot of us solace to know that there was a time when furniture was made out of solid wood and not particle board, or when coffee makers were made out of metal and not plastic. It’s hard to say exactly what precipitated the change to our one-time-use culture, but in the meantime there are projects that serve to re-purpose those old, durable products from another time so that they can stay relevant in today’s ever-changing world. [Jose]’s new old radio is a great example of this style of hack.
[Jose] had a 1970s-era single-speaker radio that he found in a thrift store. The first thought that he had to get the aesthetically pleasing radio working again was to install a Bluetooth receiver into the radio’s amplifier. This proved to be too time-consuming of a task, and [Jose] decided to drive the Bluetooth module off of the power circuit for the light bulb. He built a 6V AC to 4.2V DC circuit, swapped over the speaker cable, and started listening to his tunes. The modifications he made aren’t destructive, either. If he wants, he will be able to reconnect the original (and still functional) circuitry back to the speaker and pretend he’s back in 1970.
While this isn’t the most intricate hack we’ve ever featured, it’s always refreshing to see someone get use out of an old piece of technology rather than send it off to the landfill with all of our Pentium IIs or last year’s IKEA shelves that have already fallen apart. And even if the 70s aren’t your era of choice, perhaps something newer will inspire you to bust a move.
“Round up the usual suspects…”
[CNLohr] just can’t get enough of the ESP8266 these days — now he’s working on getting a version of V-USB software low-speed USB device emulation working on the thing. (GitHub link here, video also embedded below.) That’s not likely to be an afternoon project, and we should warn you that it’s still a project in progress, but he’s made some in-progress material available, and if you’re interested either in USB or the way the mind of [CNLohr] works, it’s worth a watch.
In this video, he leans heavily on the logic analyzer. He’s not a USB expert, and couldn’t find the right resources online to implement a USB driver, so he taught himself by looking at the signals coming across as he wiggled a mouse on his desk. Using the ever-popular Wireshark helped him out a lot with this task as well. Then it was time to dig into Xtensa assembly language, because timing was critical.
Speaking of timing, one of the first things that he did was write some profiling routines so that he could figure out how long everything was taking. And did we mention that [CNLohr] didn’t know Xtensa assembly? So he wrote routines in C, compiled them using the Xtensa GCC compiler, and backed out the assembly. The end result is a mix of the two: assembly when speed counts, and C when it’s more comfortable.
Continue reading “[CNLohr], ESP8266, USB…”
[David]’s family acquired a swimming pool. While it’s not his favorite activity in the world, every now and then he’ll indulge in the blue plastic bin full of water occupying previously pristine land in his backyard.
As he says, cool beer is pleasant, but cool water tends to put a damper on the experience. Rather than do something pedestrian like touch the water himself to discover its temperature; he saw an opportunity for a fun little project in a wireless temperature monitor.
The heart of the device is a Telecom Design TD1208 which runs on the French SigFox network. For a small fee any device on the network can send up to 140 12byte packets of data a day. Not a lot, but certainly acceptable for the Microchip MCP9700 temperature sensor it uses. He got the board up and running, and even made his own custom helical coil antenna.
The case was 3D printed out of PLA. It’s a tiered cylindrical bobber. The wider top section floats on the water and the base acts as a ballast, holding the battery and sensor. The bobber is powered by a combination of a questionable Chinese lithium battery, charging circuit, and solar panel. [Dave] was keen to point out that the battery is, technically, water cooled.
He wrapped up the code for the bobber and used SigFox’s SDK to build a nice web interface. Now, when the rare mood strikes him, he can remain inside if the conditions aren’t right for a swim.
A person who is deaf can’t hear sound, but that doesn’t mean they can’t feel vibrations. For his Hackaday Prize entry, [Alex Hunt] is developing the Shakelet, a vibrating wristband for that notifies hearing impaired people about telephones, doorbells, and other sound alerts.
To tackle the difficulty of discriminating between the different sounds from different sources, [Alex’s] wants to attach little sound sensors directly to the sound emitting devices. The sensors wirelessly communicate with the wristband. If the wristband receives a trigger signal from one of the sensors, it alerts the wearer by vibrating. It also shows which device triggered the alert by flashing an RGB LED in a certain color. A first breadboard prototype of his idea confirmed the feasibility of the concept.
After solving a few minor problems with the sensitivity of the sensors, [Alex] now has a working prototype. The wristband features a pager motor and is controlled by an ATMEGA168. Two NRF24L01+ 2.4 GHz wireless transceiver modules take care of the communication. The sound sensors run on the smaller ATTiny85 and use a piezo disc as microphone. Check out the video below, where Alex demonstrates his build:
Continue reading “Hackaday Prize Entry: Shakelet”
[Joel] has a remote control ceiling fan. It’s nothing special, the controller has a low-power 350MHz transmitter and a Holtek encoder to send commands by keying the transmitter’s output. Desiring something a little better, he set about reverse engineering the device’s protocol and implementing it on a Lattice iCE40 FPGA.
To decode the device’s packets he reached for his RTL-SDR receiver and took a look at it in software. GQRX confirmed the presence of the carrier and allowed him to record a raw I/Q file, which he could then supply to Inspectrum to analyse the packet structure. He found it to be a simple on-off keying scheme, with bits expressed through differing pulse widths. He was then able to create a Gnu Radio project to read and decode them in real time.
Emulating the transmitter was then a fairly straightforward process of generating a 350MHz clock using the on-board PLL and gating it with his generated data stream to provide modulation. The result was able to control his fan with a short wire antenna, indeed he was worried that it might also be doing so for other similar fans in his apartment complex. You can take a look at his source code on GitHub if you would like to try something similar.
It’s worth pointing out that a transmitter like this will radiate a significant amount of harmonics at multiples of its base frequency, and thus without a filter on its output is likely to cause interference. It will also be breaking all the rules set out by whoever the spectrum regulator is where you live, despite its low power. However it’s an interesting project to read, with its reverse engineering and slightly novel use of an FPGA.
Wireless remote hacking seems to be a favorite pastime here in the Hackaday community. We’ve had 2.4GHz hacks and plenty of wireless mains outlet hacks.