Shoehorning A Slick Spotify Remote Into An ESP8266

July 11, 2018 by Kerry Scharfglass 9 Comments

In 2017 Spotify finally deprecated their public vanilla C SDK library, libspotify, and officially replaced it with dedicated SDKs for iOS and Android and this new-fangled web thing we’ve all heard so much about. This is probably great for their maintainability but makes writing a native application for a Linux or a hardware device significantly harder, at least without an application process and NDA. Or is it? Instead of using that boring slab of glass and metal in their pocket [Dani] wanted to build a handy “now playing” display and remote control interface but was constrained by the aforementioned SDK limitations. So they came up with a series of clever optimizations resulting in the clearly-named ESP8266 Spotify Remote Control.

The Spotify Remote Control has a color LCD with a touchscreen. Once attached to a Spotify account it will show the album art of the currently playing track (with a loading indicator!) and let you play/pause/skip tracks from its touch screen, all with impressively low latency. To get here [Dani] faced two major challenges: authorizing the ESP to interact with a user’s Spotify account, and low latency LCD drawing.

If you’re not on iOS or Android, the Spotify web API is the remaining non-NDA’d interface available. But it’s really designed to be used on relatively rich platforms such as fully featured web browsers, not an embedded device. To that end, gone are the days of asking a user to enter their username and password in a static login box, the newer (better) way is to negotiate for a per-user token (which is individually authorized per application), then to use that to authenticate your interaction. With this regime 3rd party applications (in this case an ESP8266) never see a user’s password. One codified and very common version of this process is called OAuth and the token dance is called a “workflow”. [Dani] has a pretty good writeup of the process in their post if you want more detail about the theory. After banging out the web requests and exception handling (user declines to authorize the device, etc) the final magic ended up being using mDNS to get the user’s browser to redirect itself to the ESP’s local web server without looking up an IP first. So the setup process is this: the ESP boots and displays a URL to go to, the user navigates there on a WiFi connected device and operates the authorization workflow, then tokens are exchanged and the Remote Control is authorized.

The second problem was smooth drawing. By the ESP’s standards the album art for a given track at full color depth is pretty storage-large, meaning slow transfers to the display and large memory requirements. [Dani] used a few tricks here. The first was to try 2 bit color depth which turned out atrociously (see image above). Eventually the solution became to decompress and draw the album art directly to the screen (instead of a frame buffer) only when the track changed, then redraw the transport controls quickly with 2 bit color. The final problem was that network transfers were also slow, requiring manual timesharing between the download code and the display drawing routing to ensure everything was redrawn frequently.

Check out [Dani]’s video after the break, and take a peek at the sources to try building a Spotify Remote Control yourself.

Continue reading “Shoehorning A Slick Spotify Remote Into An ESP8266” →

Battleships Over BGP

June 7, 2018 by Richard Baguley 14 Comments

The Border Gateway Protocol (BGP) is one of the foundations of the internet. It’s how the big routers that shift data around the Internet talk to each other, passing info on where they can send data to. It’s a simple protocol, with each router sending text messages that advertise the routes that they carry. The administrators of these routers create communities, each with an individual code, and this information is passed between routers. Most top-level ISPs don’t spread this data far, but [Ben Cox] realized that his ISP did. and that he could use this as an interesting way to transmit data over the Internet. What data to send? He decided to play battleships.

Continue reading “Battleships Over BGP” →

Internet Of Laundry — Let The ESP8266 Watch Your Dirty Drawers Get Clean

May 20, 2018 by Al Williams 31 Comments

When you think of world-changing devices, you usually don’t think of the washing machine. However, making laundry manageable changed not only how we dress but how much time people spent getting their clothes clean. So complaining about how laborious our laundry is today would make someone from the 1800s laugh. Still, we all hate the laundry and [Andrew Dupont], in particular, hates having to check on the machine to see if it is done. So he made Laundry Spy.

How do you sense when the machine — either a washer or a dryer — is done? [Andrew] thought about sensing current but didn’t want to mess with house current. His machines don’t have LED indicators, so using a light sensor wasn’t going to work either. However, an accelerometer can detect vibrations in the machine and most washers and dryers vibrate plenty while they are running.

The four-part build log shows how he took an ESP8266 and made it sense when the washer and dryer were done so it could text his cell phone. He’d already done a similar project with an Adafruit HUZZAH. But he wanted to build in some new ideas and currently likes working with NodeMCU. While he was at it he upgraded the motion sensor to an LIS3DH which was cheaper than the original sensor.

[Andrew] already runs Node – RED on a Raspberry Pi, so incorporating this project with his system was a snap. Of course, you could adapt the approach to lots of other things, as well. The device produces MQTT messages and Node – RED subscribes to them. The Pushover handles the text messaging. Node – RED has a graphical workflow that makes integrating all the pieces very intuitive. Here’s the high-level workflow:

You might wonder why he didn’t just have the ESP8266 talk directly to Pushover. That is possible, of course, but in part 2, [Andrew] enumerates some good reasons for his design. He wants to decouple components in the system for easier future upgrades. And MQTT is simple to publish on the sensor side of things compared to API calls which are handled by the Raspberry Pi for now.

Laundry monitoring isn’t a unique idea and everyone has a slightly different take on it, even some Hackaday authors. If phone notification is too subtle for you, you can always go bigger.

Welcome To The Internet Of Hamsters

May 16, 2018 by Tom Nardi 8 Comments

It was only a matter of time. Everything else is getting its data logged and reported to the Internet for detailed analysis, so why should our rodents be any different? The cover story is that [Nicole Horward] hooked her pet hamster Harold up to the web because she wanted to see if he was getting as much exercise as he should. The real reason is, of course, that Harold wanted to show off to his “friends” on Hamsterbook. (Editor’s note: dead link, but take a look at the Wayback Machine.)

The hardware side of this hack is very simple, a magnetic door sensor (like the kind used in alarm systems) is used to detect each time the wheel makes a complete rotation. The sensor is hooked up to the GPIO pins of a Raspberry Pi, where it’s read by a Python script. A small LCD screen was added to give some visual feedback on Harold’s daily activity, and the whole thing was boxed up in a laser cut enclosure.

That gave [Nicole] a cute little display next to Harold’s cage, but it didn’t do much for analyzing his activity. For that, a script is used to upload the data every minute to a ThingSpeak channel via MQTT. This automatically generates attractive graphs from the raw data, making it much easier to visualize what’s happening over the long term.

Now might be a good time to brush up on your MQTT knowledge, so that your pet could be the next to join the IoT revolution.

Continue reading “Welcome To The Internet Of Hamsters” →

Firefox Reality, A Browser For VR Devices

April 6, 2018 by Jenny List 31 Comments

The browser you are reading this page in will be an exceptionally powerful piece of software, with features and APIs undreamed of by the developers of its early-1990s ancestors such as NCSA Mosaic. For all that though, it will very probably be visually a descendant of those early browsers, a window for displaying two-dimensional web pages.

Some of this may be about to change, as in recognition of the place virtual reality devices are making for themselves, Mozilla have released Firefox Reality, in their words “a new web browser designed from the ground up for stand-alone virtual and augmented reality headset“. For now it will run on Daydream and GearVR devices as a developer preview, but the intended target for the software is a future generation of hardware that has yet to be released.

Readers with long memories may remember some of the hype surrounding VR in browsers back in the 1990s, when crystal-ball-gazers who’d read about VRML would hail it as the Next Big Thing without pausing to think about whether the devices to back it up were on the market. It could be that this time the hardware will match the expectation, and maybe one day you’ll be walking around the Hackaday WrencherSpace rather than reading this in a browser. See you there!

They’ve released a video preview that disappointingly consists of a 2D browser window in a VR environment. But it’s a start.

Continue reading “Firefox Reality, A Browser For VR Devices” →

IoT Potty Training

March 10, 2018 by Al Williams 22 Comments

If you have not had children, stop reading now, we implore you. Because before you’ve had kids, you can’t know how supremely important it is that they take care of going to the bathroom by themselves. [David Gouldin] knows how it is. But unlike most of us, he resorted to using an Amazon IoT button and Twilio. No, we are not kidding.

The problem he was trying to solve is when his younger child would need to use the potty in the middle of the night, calling out for assistance would wake the older child. [David] said it best himself:

Behind the smiling emoji facade is an Amazon IoT button, a variant of Amazon’s dash button. When my kid presses this button, it triggers an AWS Lambda function that uses Twilio’s Python Helper Library to call my iPhone from a Twilio number. The Twilio number is stored in my contacts with “emergency bypass” turned on, so even when it’s 2am and I’m on “do not disturb” I still get the call.

Continue reading “IoT Potty Training” →

Memcached Servers Abused For DDoS Attacks

March 1, 2018 by Bob Baddeley 11 Comments

Cloudflare announced recently that they are seeing an increase in amplification attacks using memcached servers, and that this exploit has the potential to be a big problem because memcached is capable of amplifying an attack significantly. This takes DDoS attacks to a new level, but the good news is that the problem is confined to a few thousand misconfigured servers, and the solution is to put the servers behind a tighter firewall and to disable UDP. What’s interesting is how the fundamental workings of the Internet are exploited to create and direct a massive amount of traffic.

We start with a botnet. This is when a bunch of Internet-connected devices are compromised and controlled by a malicious user. This could be a set of specific brand of web camera or printer or computer with unsecured firmware. Once the device is compromised, the malicious user can control the botnet and have it execute code. This code could mine cryptocurrency, upload sensitive data, or create a lot of web traffic directed at a particular server, flooding it with requests and creating a distributed denial of service (DDoS) attack that takes down the server. Since the server can’t distinguish regular traffic from malicious traffic, it can’t filter it out and becomes unresponsive.

This DDoS attack is limited to the size of the botnet’s bandwidth, though. If all the web cameras in the botnet are pounding a server as fast as they can, the botnet has reached its max. The next trick is called an amplification attack, and it exploits UDP. UDP (as opposed to TCP) is like the early post office; you send mail and hope it gets there, and if it doesn’t then oh well. There’s no handshaking between communicating computers. When a device sends a UDP packet to a server, it includes the return address so that the server can send the response back. If the device sends a carefully crafted fake request with a different return address, then the server will send the response to that spoofed return address.

So if the web camera sends a request to Server A and the response is sent to Server B, then Server A is unintentionally attacking Server B. If the request is the same size as the response, then there’s no benefit to this attack. If the request is smaller than the response, and Server A sends Server B a bunch of unrequested data for every request from the camera, then you have a successful amplification attack. In the case of memcached, traffic can be amplified by more than 50,000 times, meaning that a small botnet can have a huge effect.

Memcached is a memory caching system whose primary use is to help large websites by caching data that would otherwise be stored in a database or API, so it really shouldn’t be publicly accessible anyway. And the solution is to turn off public-facing memcached over UDP, but the larger solution is to think about what things you are making available to the Internet, and how they can be used maliciously.