[Chris] has been playing with the Amazon Echo. It’s sort of like having Siri or Google Now available as part of your home, but with built-in support for certain other home automation appliances like those from Belkin WeMo and Philips. The problem was [Chris] didn’t want to be limited to only those brands. He had other home automation gear that he felt should work with Amazon Echo, but didn’t. That’s when he came up with the clever idea to just emulate one of the supported platforms.
The WeMo devices use UPnP to perform certain functions over the network. [Chris] wanted to see how these communications actually worked, so he fired up his laptop and put his WiFi adapter into monitor mode. Then he used Wireshark to start collecting packets. He found that the device detection function starts out with the Echo searching for WeMo devices using UPnP. The device then responds to the Echo with the device’s URL using HTTP over UDP. The Echo then requests the device’s description using that HTTP URL. The description is then returned as an HTTP response.
The actual “on/off” functionality of the WeMo devices is simpler since the Echo already knows about the device. The Echo simply connects to the WeMo over the HTTP interface and issues a “SetBinaryState” command. The WeMo then obliges and returns a confirmation via HTTP.
[Steve] was able to use this information to set up his own WeMo “virtual cloud”. Each virtual device would have its own IP address. They would also need to have a listener for UDP broadcasts as well as an HTTP listener running on the WeMo port 49153. Each virtual device would also need to be able to respond to the UPnP discovery requests and the “on/off” commands.
[Chris] used a Linux server, creating a new virtual Ethernet interface for each virtual WeMo switch. A single Python script runs the WeMo emulation, listening for the UPnP broadcast and sending a different response for each virtual device. Part of the response includes the device’s “friendly name”, which is what the Echo listens for when the user says voice commands. Since the virtual WeMo devices are free, this allows [Chris] to make multiple phrases for each device. So rather than be limited to “television”, he can also make a separate device for “TV” that performs the same function. [Chris] is also no longer limited to only specific brands of home automation gear.
There’s still a long way to go in hacking this device. There’s a lot of hardware under the hood to work with. Has anyone else gotten their hands (and bench tools) on one of these?
If you’re looking to build the next creepy Halloween decoration or simply thinking about trying out OpenCV for the first time, this next project will have you covered. [Glen] made a pair of giant googly eyes that follow you around the room using some servos and some very powerful software.
This part of the project is arguably the most interesting if you’re new to OpenCV; [Glen] uses this software package to recognize different faces. From there, the computer picks out the most prominent face and sends commands to the Arduino to move the eyes to the appropriate position. The project goes into great detail, from Arduino code to installing Ubuntu to running OpenCV for the first time!
We’ve featured some of [Glen]’s projects before, like his FPGA-driven LED wall, and it’s good to see he’s still making great things!
[Gnif] had a recent hard drive failure in his home server. When rebuilding his RAID array, he decided to update to the ZFS file system. While researching ZFS, [Gnif] learned that the file system allows for a small USB cache disk to greatly improve his disk performance. Since USB is rather slow, [Gnif] had an idea to try to use an old i-RAM PCI card instead.
The problem was that he didn’t have any free PCI slots left in his home server. It didn’t take long for [Gnif] to realize that the PCI card was only using the PCI slot for power. All of the data transfer is actually done via a SATA cable. [Gnif] decided that he could likely get by without an actual PCI slot with just a bit of hacking.
[Gnif] desoldered a PCI socket from an old faulty motherboard, losing half of the pins in the process. Luckily, the pins he needed still remained. [Gnif] knew that DDR memory can be very power-hungry. This meant that he couldn’t only solder one wire for each of the 3v, 5v, 12v, and ground pins. He had to connect all of them in order to share the current load. All in all, this ended up being about 20 pins. He later tested the current draw and found it reached as high as 1.2 amps, confirming his earlier decision. Finally, the reset pin needed to be pulled to 3.3V in order to make the disk accessible.
All of the wires from his adapter were run to Molex connectors. This allows [Gnif] to power the device from a computer power supply. All of the connections were covered in hot glue to prevent them from wriggling lose.
Russians blowing up capacitors! As we all know, electronics only work because of blue smoke. [kreosan] is releasing this blue smoke from a few hundred caps. Fun times, even if they are a large number of inert tube shields in their collection of caps.
[Richard] wanted a Minecraft server, but not just any Minecraft server; this one demanded a custom case. A grass block was the inspiration, acrylic the medium, and a quad-core Mini-ITX the guts of the project.
[Matthias Wandel], a.k.a. the woodgears.ca dude, is well-known in certain circles for being a wizard of wood. One of the first projects that put him on the map was a pantorouter – a router to cut mortises and tenons. He’s going back to his roots and building a bigger version. This version uses models of routers that are available outside North America, and in the latest video [Matthias] has it dialed in very well.
The Intel Edison is an incredibly small and cheap x86 computing platform, and with that comes the obvious applications for robotics and wearable computing. [mz] had another idea: what if the Edison could do work that is usually done by workstations? Would it make economic sense to buy a handful of Edisons over a single quad-core Xeon system?
[mz] thought the Edison would be an ideal platform for fuzz testing, or sending random, automated data at a program or system to figure out if they’ll misbehave in interesting ways. After figuring out where to solder power and ground wires to boot an Edison without a breakout board, [mz] got to work benchmarking his fuzz testing setup.
Comparing the benchmarks of a fuzzing job running on the Edison and a few servers and workstations, calculations of cost-efficiency worked out well for this tiny x86 system on module. For parallelizable tasks, the Edison is about 8x less powerful than a reasonably modern server, but it’s also about 5-8x cheaper than a comparable desktop machine. Although renting a server is by far the more economic solution for getting a lot of computing power easily, there are a few use cases where a cluster of Edisons in your pocket would make sense.
Don’t like sunglasses? Deal with it. They’re the pixeley, retro sunglasses from your favorite animated .GIFs, made real in laser cut acrylic. Points of interest include heat-bent frames made out of a single piece of acrylic.
Sparkfun is now hosting the Internet of Things. They’re giving people a tiny bit of space to push data to, and you can also deploy your own server. That’s interesting, and you can expect us doing a full post on this soon.
If you only have $20 to spend on a board, you’ll want to pick up at Teensy 3.1. [Karl] wrote some bare metal libraries for this awesome board, and while it’s not as extensive as the standard Arduino libs, it’s more than enough to get most projects off the ground. Included are UARTs, string manipulation tools, support for the periodic interval timers on the chip, and FAT and SD card support.
[Frank] knows how important backups are for data security, but his old method of plugging a hard drive in to take manual backups every so often is not the most reliable or secure way of backing up data. He realized he was going to need a secure, automated solution. He didn’t need a full-sized computer with a ton of power; why waste electricity for something so simple? His solution was to use a Raspberry Pi as the backup computer.
The main problem he faced with the Pi was finding a way to make it rack mountable. [Frank] started with an empty 1U server case. He then had to bend a few metal plates in order to securely mount the backup drive into the case. A couple of small rubber pads help dampen any vibrations caused by the hard drive.
The computer power supply was able to put out the 12V needed for the hard disk, but not the 5V required to run the Pi. [Frank’s] solution was to use an LM2596 based switching supply to turn the 12V into 5V. He soldered the power supply wires directly to the Pi, thinking that a USB plug might vibrate loose over time. Mounting the Pi to the computer case should have been the trickiest part but [Frank] made it easy by simply gluing the Pi’s plastic case to the inside of the computer case. When all was said in done, the backup server pulls 29W under full load, 9W with the disk spinning, and only about 2W in an idle state.
On the software side of things, [Frank’s] backup box uses bash shell scripts to get the job done. The Pi connects to his main server via VPN and then the bash scripts use rsync to actually collect the files. The system not only saves backups every night, but also keeps week old backups just in case. If you are really paranoid about your backups, try hooking up a custom battery backup solution to your Pi. If a Pi just isn’t doing it for you, you can always try one of many other methods.