When you want to play around with a new technology, do you jump straight to production machinery? Nope. Nothing beats a simplified model as proof of concept. And the only thing better than a good proof of concept is an amusing proof of concept. In that spirit [Eric Tsai], alias [electronichamsters], built the world’s most complicated electronic gingerbread house this Christmas, because a home-automated gingerbread house is still simpler than a home-automated home.
Yeah, there are blinky lights and it’s all controlled by his smartphone. That’s just the basics. The crux of the demo, however, is the Bluetooth-to-MQTT gateway that he built along the way. A Raspberry Pi with a BTLE radio receives local data from BTLE sensors and pushes them off to an MQTT server, where they can in principle be read from anywhere in the world. If you’ve tried to network battery-powered ESP8266 nodes, you know that battery life is the Achilles heel. Swapping over to BTLE for the radio layer makes a lot of sense.
It is interesting to see the wide coverage of a police investigation looking to harvest data from the Amazon Echo, the always-listening home automation device you may know as Alexa. A murder investigation has led them to issue Amazon a warrant to fork over any recordings made during the time of a crime, and Amazon has so far refused.
Not too long ago, this is the sort of news would have been discussed on Hackaday but the rest of my family would have never heard about it. Now we just need to get everyone to think one step beyond this and we’ll be getting somewhere.
What isn’t being discussed here is more of concern to me. How many of you have a piece of tape over your webcam right now? Why did you do that? It’s because we know there are compromised systems that allow attackers to turn on the camera remotely. Don’t we have to assume that this will eventually happen with the Echo as well? Police warrants likely to affect far less users than account breaches like the massive ones we’ve seen with password data.
All of the major voice activated technologies assert that their products are only listening for the trigger words. In this case, police aren’t just looking for a recording of someone saying “Alexa, help I’m being attacked by…” but for any question to Alexa that would put the suspect at the scene of the crime at a specific time. Put yourself in the mind of a black hat. If you could design malware to trigger on the word “Visa” you can probably catch a user giving their credit card number over the phone. This is, of course, a big step beyond the data already stored from normal use of the system.
It’s not surprising that Amazon would be served a warrant for this data. You would expect phone records (although not recordings of the calls) to be reviewed in any murder case. Already disclosed in this case is that a smart water meter from the home reported a rather large water usage during the time of the murder — a piece of evidence that may be used to indicate a crime scene clean-up effort.
What’s newsworthy here is that people who don’t normally think about device security are now wondering what their voice-controlled tech actually hears them say. And this is a step in the right direction.
Very few residential architectural elements lend themselves to automation, with doors and windows being particularly thorny problems. You can buy powered doors and windows, true, but you’ll pay a pretty penny and have to go through an expensive remodeling project to install them. Solving this problem is why this double-hung window automation project caught our eye.
Another reason we took an interest in this project is that [deeewhite] chose to use a PLC to control his windows. We don’t see much love for industrial automation controllers around here, what with the space awash in cheap and easy to use microcontrollers. They have their place, though, and a project like this is a good application for a PLC. But the controller doesn’t matter at all if you can’t move the window, for which task [deeewhite] chose 12V linear actuators. The fact that the actuators are mounted in the center of the window is probably necessary given the tendency of sashes to rack in their frames and jam; unfortunately, this makes for a somewhat unsightly presentation. [deeewhite] also provides the ladder logic for his PLC and discusses how he interfaces his system with Alexa, a WeMo and IFTT.
We’d love to see this project carried forward a bit with actuators hidden under the window trim, or a rack and pinion system built into the window tracks themselves. This is a pretty good start and should inspire work on other styles of windows. While you’re at it, don’t forget to automate the window blinds.
An open door overnight leaves chickens and their food vulnerable to predation. Rather than handle the chore manually and risk one forgetful moment that could wipe out his flock, [Eddy] used a servo to power the door and an Arduino to control it. To keep track of bedtime and wakeup, a Raspberry Pi looks up the local civil dawn and twilight times online and tells the Arduino when the moment is at hand. The Pi cleverly caches the times for use the next day in case the WiFi connection is down, and also provides a web interface to check on the door’s status and manually override the cycle. Result: safe, happy chickens.
If all this seems a bit much for a simple job, [Eddy] agrees. But he’s using this as a testbed to develop a home automation framework that can be retasked at will. Sounds like he’s on the right track to us, but for more IoT animal husbandry tips, he’ll want to check out this small farm automation effort.
In a previous life, he had reverse engineered the protocol these cheap wireless plugs, garage doors, and electric window shutters all use. This eventually resulted in a little library called rf-ctrl that can toggle and read GPIO pins in the correct way to control these objects. He has a few of the more popular protocols built into the library and even wrote a guide on how to do the reverse engineering yourself if you have need.
Having successfully interfaced with the plugs to use with his space heaters, [Jean-Christophe] went about converting a cheap TP Link router into a command center for them. Since TP Link never expected anyone to hammer their square peg into a mismatched hole, it takes a careful hand at soldering and some enamel wire to break out the GPIO pins, but it’s well within the average skill set.
The end result is a nicely contained blue box with a little antenna hanging out of it, and we hope, a warm abode for the coming winter.
When a job can be handled with a microcontroller, [devttys0] likes to buck the trend and build a circuit that requires no coding. Such was the case with this “Clapper”-inspired faux-AI light controller, which ends up being a great lesson in analog design.
The goal was to create a poor man’s JARVIS – something to turn the workshop lights on with a free-form vocal command. Or, at least to make it look that way. This is an all-analog circuit with a couple of op amps and a pair of comparators, so it can’t actually process what’s being said. “Aziz! Light!” will work just as well as any other phrase since the circuit triggers on the amplitude and duration of the spoken command. The AI-lite effect comes from the clever use of the comparators, RC networks to control delays, and what amounts to an AND gate built of discrete MOSFETs. The end result is a circuit that waits until you finish talking to trigger the lights, making it seems like it’s actually analyzing what you say.
We always enjoy [devttys0]’s videos because they’re great lessons in circuit design. From block diagram to finished prototype, everything is presented in logical steps, and there’s always something to learn. His analog circuits that demonstrate math concepts was a real eye-opener for us. And if you want some background on the height of 1980s AI tech that inspired this build, check out the guts of the original “Clapper”.
Every time we hear about one walled-garden protocol not speaking to another, and the resulting configuration mayhem that ensues, we can’t help think that [Mike] was right: home automation has a software problem. But that’s putting the blame on the technology. (We’re sure that [Mark] could have made the kettle work if he’d just applied a little Wireshark.)
There’s another mismatch here — one of expectations about the users. A water kettle is an object that should be usable by grandmothers, and a complex networked device is clearly aimed at techies and early adopters. Combining the two is asking for trouble. Non-functioning IoT devices are the blinking 12:00 of our generation.
What do you think? Where’s the blame here? Poor design, bad software stack, stupid users, or failure of mega-corps to integrate their systems together? More importantly, how could we make it better?