Cutting An IoT Fan Free Of The Cloud

The cloud is supposed to make everything better. You can control things remotely, with the aid of a benevolent corporation and their totally friendly servers. However, you might not like those servers, and you might prefer to take personal control of your hardware. If that’s the case, you might like to follow the story of [ouaibe] and their quest to free a fan from the cloud.

The unit in question was a tower fan from Dreo. [ouaibe] noted that there was already a project to control the fans using Home Assistant, but pure lower-level local control was the real goal here. Work began on pulling apart the Dreo Android app to determine how it talked to the fan, eventually turning up a webserver on board, but little progress. The next step was to disassemble the unit entirely. That turned up multiple PCBs inside, with one obviously for wireless communication and another hosting a Sino Wealth microcontroller. Dumping firmwares followed,  along with reverse engineering the webserver, and finally establishing a custom ESPHome integration to fully control the fan.

[ouaibe] has shared instructions on how to cut your own fan from the cloud, though notes that the work won’t be extended to other Dreo products any time soon. In any case, it’s a great example of just how much work it can take to fully understand and control an IoT device that’s tethered to a commercial cloud server. It’s not always easy, but it can be done!

Hackaday Links Column Banner

Hackaday Links: March 31, 2024

Battlelines are being drawn in Canada over the lowly Flipper Zero, a device seen by some as an existential threat to motor vehicle owners across the Great White North. The story started a month or so ago, when someone in the government floated the idea of banning devices that could be “used to steal vehicles by copying the wireless signals for remote keyless entry.” The Flipper Zero was singled out as an example of such a nefarious device, even though relatively few vehicles on the road today can be boosted using the simple replay attack that a Flipper is capable of, and the ones that are vulnerable to this attack aren’t all that desirable — apologies to the 1993 Camry, of course. With that threat hanging in the air, the folks over at Flipper Devices started a Change.org petition to educate people about the misperceptions surrounding the Flipper Zero’s capabilities, and to urge the Canadian government to reconsider their position on devices intended to explore the RF spectrum. That last bit is important, since transmit-capable SDR devices like the HackRF could fall afoul of a broad interpretation of the proposed ban; heck, even a receive-only SDR dongle might be construed as a restricted device. We’re generally not much for petitions, but this case might represent an exception. “First they came for the Flipper Zero, but I did nothing because I don’t have a Flipper Zero…”

Continue reading “Hackaday Links: March 31, 2024”

Weasley Clock For Magically Low Cost

For those unfamiliar with the details of the expansive work of fiction of Harry Potter, it did introduce a few ideas that have really stuck in the collective conscious. Besides containing one of the few instances of time travel done properly and introducing a fairly comprehensive magical physics system, the one thing specifically that seems to have had the most impact around here is the Weasley family clock, which shows the location of several of the characters. We’ve seen these built before in non-magical ways, but this latest build seeks to drop the price tag on one substantially.

To do this, the build relies on several low-cost cloud computing solutions and smartphone apps to solve the location-finding problem. The app is called OwnTracks and is an open-source location tracker which can report data to any of a number of services. [Simon] sends the MQTT data to a cloud-based solution called HiveMQCloud, but you could send it anywhere in principle. With the location tracking handled, he turns to some very low-cost Arduinos to control the stepper motors which point the clock hands to the correct locations on the face.

While the build does rely on a 3D printer for some of the internal workings of the clock, this does bring the cost down substantially when compared to other options. Especially when compared to this Weasley family clock which was built into a much larger piece of timekeeping equipment, having an option for a lower-cost location-tracking clock face like this one is certainly welcome.

2022 Hackaday Prize: Boondock Echo Connects Your Radios With The Cloud

[Mark J Hughes] volunteers as a part of a local community fire watch which coordinates by radio. The La Habra Heights region of Los Angeles is an area of peaks and valleys, which makes direct radio connections challenging. Repeaters work well for range improvement, but in such areas, there is no good place to locate these. [Mark] says that during an emergency (such as a wildfire) the radio usage explodes, with him regularly tracking as many as eight radio frequencies and trying to make sense of it, whilst working out how to send the information on and to whom.

This led him together with collaborator [Kaushlesh Chandel] to create Project Boondock Echo, to help alleviate some of the stress of it all. The concept is to use a cheap Baofeng radio to feed into a gateway based around an ESP32 audio development kit. Mount this in a box with a LiPo based power supply, and you’ve got yourself a movable radio-to-cloud time-shift audio recorder.

By placing one or more of these units in the properties of several of the community group radio operators, all messages can be captured to an audio file, tagged with the radio frequency and time of transmission, and uploaded to a central server. From there they can be retrieved by anybody with access, no matter the physical location, only an internet connection is needed.

The next trick that can be performed, is to reverse the process and queue up previous recordings, and send it back over the cloud to remote locations for re-transmission via radio into the field. This is obviously a massive asset, because wherever there is some urbanization, there is likely an internet connection. With the addition of a Boondock Echo unit, anyone that has a receiver within a few miles can be fully connected with what’s going on outside the range of direct radio communications.

Source for the ESP32’s firmware as well as the web side of things can found on the project Boondock Echo GitHub, complete with some STLs for a 3D printed box to sit it in. Like always, there’s more than one way to solve a particular problem. Here’s an amateur radio repeater based using an RTL-SDR and a Raspberry Pi.

Against The Cloud

One of our writers is working on an article about hosting your own (project) website on your own iron, instead of doing it the modern, cloudy-servicey way. Already, this has caused quite a bit of hubbub in the Hackaday Headquarters. Who would run their own server in 2022, and why?

The arguments against DIY are all strong. If you just want to spin up a static website, you can do it for free in a bazillion different places. GitHub’s Pages is super convenient, and your content is version controlled as a side benefit. If you want an IoT-type data-logging and presentation service, there are tons of those as well — I don’t have a favorite. If you want e-mail, well, I don’t have to tell you that a large American search monopoly offers free accounts, for the low price of slurping up all of your behavioral data. Whatever your need, chances are very good that there’s a service for you out there somewhere in the cloud.

And that’s awesome if you only want the service provided. But what if you want to play around? Or learn how it all works under the hood? This is Hackaday!

For instance, you could run your own mail server just for your friends and family. The aforementioned search monopolist will probably flag all of your e-mail as spam, partly because they don’t trust small e-mail providers, and partly because that’s the “m” in monopoly. But if you can get folks to whitelist the addresses, you’ll be in business. And then you open up a world of fun and foolery. You can write hooks to automatically handle mail, or you can create an infinite number of mail accounts, even on the fly as per Spamgourmet, the most awesome anti-spam tool of the last 30 years. Or you can invent your own. Run a mailing list for your relatives. Or do something stupid.

I used to run a service where, when a particular account received an e-mail, the attached photo was pushed up to a website with the subject line as the caption. Instant photo-blog, of the strangest and least secure sort. Getting it running was a few lines of Bash scripting, and an afternoon of fun. Is there a service that does this, already existing in the cloud? Probably. One that allows you a little privacy and doesn’t track your every move? Maybe. But even if there is, would I have learned about sendmail by using this service? Nope!

I hear you saying “security” under your breath, and you’re right. This system was secured by lock made of purest obscurity. But still, in seven years of running the service, nobody guessed the magic e-mail address, not once. Knowledge of the e-mail address was essentially a password, but if I needed extra security I probably could have implemented it in a few lines of Bash anyway. The webpage itself was static HTML, so good luck with that, Hackerman! (The site’s been down for a while now, so you missed your chance.)

If you just want a service, you can be served. But if you want to be a server, a first-class Internet citizen, with your own cloud in the sky, nothing’s stopping you either. And in contrast to using someone else’s computers, running your own is an invitation to play. It’s a big, Internet-connected sandbox. There are an infinity of funny ideas out there that you can implement on your own box, and a lot to learn. If you hack on someone else’s box, it’s a crime. If you hack on your own, it’s a pleasure.

I know it’s anachronistic, but give it a try. (PDF, obscenity, uncorrected typos.) Be your own cloud.

DOOM Played By Tweet

Getting DOOM to run on hardware it was never intended to run on is a tradition as old as time. Old cell phones, embedded systems, and ancient televisions have all been converted to play this classic first-person shooter. This style of playing games on old hardware might be passé now as the new trend seems to be the ability to play this game on more ethereal platforms instead. This project brings DOOM to Twitter.

The gameplay is a little nontraditional as well. To play the game, a tweet needs to be sent with specific instructions for the bot. The bot then plays the game according to its instructions and then tweets a video. By responding to this tweet with more instructions, the player can continue the game tweet-by-tweet. While slightly cumbersome, it does have the advantage of allowing a player to resume any game simply by responding to the tweet where they would like to start. Behind the scenes of the DOOM-playing Twitter bot is interesting as well and the code is available on the project’s GitHub page.

While we’ve seen plenty of DOOM instances on all kinds of hardware, it’s safe to say we’ve never really seen a gameplay experience quite like this one. It may stay as a curiosity, but DOOM porters are always looking for something else to run this classic game so it may eventually branch out or develop into something more user-friendly like this cloud-based Atari 2600.