Faux-AI Clapper Almost Seems To Be Listening

October 24, 2016 by Dan Maloney 8 Comments

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”.

Continue reading “Faux-AI Clapper Almost Seems To Be Listening” →

UK IT Specialist Unable To Boil Water, Make Tea

October 20, 2016 by Elliot Williams 54 Comments

In our latest episode of “IoT-Schadenfreude Theater” we bring you the story of [Mark], a British man who can’t boil water. Or more specifically, a man who can’t integrate MQTT with Amazon Echo, or IFTTT with HomeKit.

Yes, yes. We all love to laugh at a technology in its infancy. It’s like when robots fall down: it’s a cheap shot and things will surely get better, right? Indeed, the Guardian has had its fun with this particular WiFi kettle before — they’re British and nothing is more important than a remote-controlled cuppa.

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?

Headline image:Fredy Velásquez Orozco, via Wikimedia Commons Thumbnail image: Markus Schweiss, also Wikimedia Commons.

64×16 LED MQTT Laundry Display

October 11, 2016 by Rich Hawkes 2 Comments

When you have an MQTT broker receiving messages, you want to be able to see them. [Xose Pérez] already had a system set up that sent him notifications, but he had a pair of 32×16 LED matrices, so he decided to make a big, bright sign to let him know when he got an important message sent to the broker.

[Xose Pérez] had already built a laundry monitor which was sending messages to an MQTT broker so he wouldn’t forget his laundry sitting in the washing machine. To communicate with the broker, he used an ESP-12. He had already ported an Arduino library for the Holtek HT1362C display drivers used by the matrices to work with his driver board.

He wanted to try out SMD soldering so he built a custom PCB to hold the ESP-12, power supply, passive components, and a connector and he describes his methods and results. Instead of hardcoded messages, he wanted the system to be configurable and display messages coming in, not only from his laundry system, but also from other sensors. A web interface, built with jQuery and WebSockets, running on the ESP-12 allows the user to subscribe to a topic on the broker and show a customized name and value on the display when a payload is available.

All-in-all, [Xose Pérez] has posted a great tutorial in which he goes over the hardware he built, the libraries he used, SMD soldering, how he made the enclosure, and even his choice in IDE (PlatformIO). He also posted the software, board designs and enclosure models software and hardware on bitbucket. The end result is a great looking LED matrix that displays not only his laundry’s status, but also anything else he wants to from his MQTT broker.

If you want to try your hand with MQTT, the ESP8266 is a wonderful device for sensor nodes, and any Linux box (like the Raspberry Pi) makes an easy broker. Check out [Elliot Williams’] Minimal MQTT series and you will be up and running in no time.

An ESP8266 In Every Light Switch And Outlet

September 20, 2016 by Gerrit Coetzee 91 Comments

[Hristo Borisov] shows us his clever home automation project, a nicely packaged WiFi switchable wall socket. The ESP8266 has continuously proven itself to be a home automation panacea. Since the ESP8266 is practically a given at this point, the bragging rights have switched over to the skill with which the solution is implemented. By that metric, [Hristo]’s solution is pretty dang nice.

It’s all based around a simple board. An encapsulated power supply converts the 220V offered by the Bulgarian power authorities into two rails of 3.3V and 5V respectively. The 3.3V is used for an ESP8266 whose primary concern is the control of a triac and an RGB LED. The 5V is optional if the user decides to add a shield that needs it. That’s right, your light switches will now have their own shields that decide the complexity of the device.

The core module seen to the right contains the actual board. All it needs is AC on one side and something to switch or control on the other The enclosure is not shown (only the lid with the shield connectors is seen) but can be printed in a form factor that includes a cord to plug into an outlet, or with a metal flange to attach to an electrical box in the wall. The modules that mate with the core are also nicely packaged in a 3D printed shield. For example, to convert a lamp to wireless control, you use a shield with a power socket on it. To convert a light switch, use the control module that has a box flange and then any number of custom switch and display shields can be hot swapped on it.

It’s all controllable from command line, webpage, and even an iOS app; all of it is available on his GitHub. We’d love to hear your take on safety, modularity, and overall system design. We think [Hristo] has built a better light switch!

Asking The Security Question Of Home Automation

August 18, 2016 by Mike Szczys 53 Comments

“Security” is the proverbial dead horse we all like to beat when it comes to technology. This is of course not unjust — we live in a technological society built with a mindset of “security last”. There’s always one reason or another proffered for this: companies need to fail fast and will handle security once a product proves viable, end users will have a harder time with setup and use if systems are secured or encrypted, and governments/law enforcement don’t want criminals hiding behind strongly secured systems.

This is an argument I don’t want to get bogged down in. For this discussion let’s all agree on this starting point for the conversation: any system that manages something of value needs some type of security and the question becomes how much security makes sense? As the title suggests, the technology du jour is home automation. When you do manage to connect your thermostat to your door locks, lights, window shades, refrigerator, and toilet, what type of security needs to be part of the plan?

Join me after the break for an overview of a few Home Automation security concerns. This article is the third in our series — the first asked What is Home Automation and the second discussed the Software Hangups we face.

These have all been inspired by the Automation challenge round of the Hackaday Prize. Document your own Automation project by Monday morning to enter. Twenty projects will win $1000 each, becoming finalists with a chance at the grand prize of $150,000. We’re also giving away Hackaday T-shirts to people who leave comments that help carry this discussion forward, so let us know what you think below.

Continue reading “Asking The Security Question Of Home Automation” →

Home Automation Is Hung Up On Software

August 2, 2016 by Mike Szczys 98 Comments

Home automation is a favorite in sci-fi, from Tony Stark’s Jarvis, to Rosie the robotic maid on the Jetsons, and even the sliding doors pulled by a stagehand Star Trek. In fact, most people have a favorite technology that should be just about ready to make an appearance in their own home. So where are these things? We asked you a few weeks ago and the overwhelming answer was that the software just isn’t there yet.

We’re toddling through the smart home years, having been able to buy Internet-connected garage doors and thermostats for some time now. But for the most part all of these systems are islands under one roof. Automation is the topic of the current challenge for the 2016 Hackaday Prize. Developing the glue that can hold all of these pieces together would make a great entry. Why doesn’t that glue yet exist?

I think the problem is really twofold. On the one hand, there isn’t a clear way to make many devices work under one software. Second, there really isn’t an obvious example of great user experience when it comes to home automation. Let’s look at why and talk about what will eventually get us there.

Continue reading “Home Automation Is Hung Up On Software” →

Obsolescence As A Service

July 16, 2016 by Elliot Williams 70 Comments

Yet another Internet of Things service has left its customers in the lurch. IoT devices (mostly lightbulbs) ~~made~~ sold by Greenwave Systems stopped talking to the outside world on July 1. More specifically, the server to which they all connected (ahem, “the cloud”) has been turned off, which rules out using the bulbs with Internet-based services like IFTTT, which was a major selling point of the Things in the first place.

[Edit: We were contacted by Greenwave, and they pointed out that they merely sold the IoT devices in question. They are made by TCP, which is also responsible for cancelling the service. And TCP has a history of doing this sort of thing before.]

It’s not the first time we’ve seen IoT companies renege on their promises to provide service, and it’s surely not going to be the last. We’re preaching to the choir here, but when even Google is willing to take the PR hit to effectively brick your devices, the only protection that you’ve got against obsolescence is an open protocol.

At least the users of ~~Greenwave’s~~ TCP’s devices will continue to be able to control them from within the home. That, plus some clever hacking, will make them workable into the future. But it’s not like the convenience that was sold with the devices.

Boo to shady IoT companies! But thanks to [Adrian] for the tip.