Making Smart Bulbs Smarter With The Power Of MQTT

What’s the point of smart home automation? To make every day tasks easier, of course! According to [Tomasz Cybulski], that wasn’t the case when he installed IKEA smart lights in his closet. It’s handy to have them in a common switch, in this case a remote control, but having to look for it every time he needed the lights could use some improvement. Enter his project to make smart bulbs smarter, through the use of a simple ESP8266.

While hooking a door switch to the lights’ power supply could provide a quick solution, [Tomasz]’s wife wanted to keep the functionality of the remote control, so he had to look elsewhere. These light bulbs use the simple Zigbee protocol, so arranging for other devices was rather trivial. A USB dongle to interface with the protocol was configured for his existing Raspberry Pi automation controller, while an ESP8266 served as the real-world sensor by connecting it to reed switches installed in the closet doors.

With all the hardware sorted out, it’s a simple matter of making it all talk to each other. The ESP8266, using the Tasmota firmware, sends a signal to an MQTT server running on the Raspberry Pi, which in turn translates it to a remote trigger on the Zigbee frequency with the dongle. The lights turn on when the door opens, and off again once it closes. And since there were no further modifications to the lights themselves, the original IKEA controller still works as expected, which we’re sure [Tomasz]’s wife appreciates!

MQTT can be an interesting piece of software that goes beyond just home automation though, and if you already have a server in your home you can use it to transfer your clipboard’s contents to another device. If you are using it for home automation though, here’s an inspiration for a rather unusual dashboard to keep things interesting. Check out this hack in action after the break.

Continue reading “Making Smart Bulbs Smarter With The Power Of MQTT”

Another IoT Debacle: Charter Offers Home Insecurity

If you are a glass-half-empty person, you’ll view Charter’s announcement that they will shutter their home security and smart home service on February 5th as another reason not to buy into closed-source IoT devices. If you are a glass-half-full person though, you’ll see the cable company’s announcement as a sign that a lot of Zigbee hardware will soon flood the surplus market. Ars Technica reports that after investigation it appears that some of the devices may connect to a standard Zigbee hub after a factory reset, but many others will definitely not.

As you might expect, users were less than thrilled. Especially those that shelled out thousands of dollars on sensors and cameras. This sort of thing might be expected if a company goes out of business, but Charter just doesn’t want to be in the home security business anymore.

Continue reading “Another IoT Debacle: Charter Offers Home Insecurity”

New Part Day: Alexa Connect Kit Now Available For Sale

People who were subscribed to updates on the Alexa Connect Kit (ACK) would recently have received an email informing that this kit is now available for sale. Last time we covered the ACK was back in September of 2018, the ‘release’ moniker meant ‘preview’ and there wasn’t any hardware one could actually purchase.

Over a year a later it seems that we can now finally get our grubby mitts on this kit that should enable us to make any of our projects Alexa-enabled. What this basically seems to mean is that one can spend close to 200 US dollars on an Arduino Zero and an Arduino shield-mounted WM-BN-MT-52 module from USI (though not listed on their site, but similar to the WM-BN-BM-22?) that integrates a 192 MHz Cortex-M MCU and a WiFi/Bluetooth module, as summarized on the Amazon Developer page for the ACK.

Continue reading “New Part Day: Alexa Connect Kit Now Available For Sale”

DIY ZigBee Therapy Lights Are Hue Compatible

Working on a project into the wee hours is hardly uncommon for us hackers, but if you’re consistently sleeping until the afternoon, it’s possible you’re suffering from a condition known as Delayed Phase Sleep Disorder (DPSD). Put simply, your body’s internal clock is out of alignment with the world around you. One of the ways to treat this condition is to expose yourself to bright light in the morning, which can help you wake up and feel more refreshed. Unfortunately, these so-called “Bright Light Therapy” boxes tend to be pretty expensive.

Looking for a way to treat his own DPSD, [Edward Shin] decided to build his own light box based on the research he’d done on the various commercial offerings out there. After all, a box full of bright lights that operates on a timer doesn’t seem particularly complex. Of course, in reality there’s a bit more to it than that, but so far the results are certainly promising.

The first decision [Edward] had to make was what kind of light he wanted. Classic light therapy devices, often used to treat Seasonal Affective Disorder (SAD), tend to be full spectrum lights that try and simulate sunlight. But in his research, he found a paper from Nature that explained the melanopsin in the human eye responds primarily to blue and green light. But as intense blue light can apparently lead to macular degeneration, he decided to go with green.

Since [Edward] already uses the Philips Hue system for his home’s lighting, he wanted to bring his therapy light into that ecosystem. The idea was that he could easily schedule his new green light box to go on when he wanted to wake up in the morning. So he used the Mesh Bee from Seeed Studio which not only supports ZigBee, but for which software is available to emulate a Hue bulb. Then he just needed to pair that with a sufficiently beefy LED driver and some 510 nm emitters. Everything is enclosed in a box made of laser cut wood that’s designed to hang from the headboard and shine down onto his face.

Over the years we’ve seen a number of similar projects trying to address SAD, so the idea of a hacker tweaking the concept to tackle DPSD seems a natural enough evolution of the idea. Just remember to speak with a medical professional before coming up with a homebrew treatment plan.

Drone Gives Up Its Wireless Secrets To Zigbee Sniffer

There’s something thrilling about decoding an unknown communications protocol. You start with a few clues, poke at the problem with some simple tools, and eventually work your way up to that first breakthrough that lets you crack the code. It can be frustrating, but when you eventually win, it can be very rewarding.

It seems that [Jason] learned this while decoding the wireless conversation between his mass-market quad and its controller. The quad in question, a Yuneec Q500, is one of those mid-range, ready-to-fly drones that’s targeted at those looking to get in the air easily and take some cool pictures. Unsure how the drone and controller were talking, [Jason] popped the covers and found a Zigbee chipset within. With the help of a $14 Zigbee USB dongle and some packet sniffing software from TI, [Jason] was able to see packets flowing, but decoding them was laborious. Luckily, the sniffer app can be set up to stream packets to another device, so [Jason] wrote a program to receive and display packets. He used that to completely characterize each controller input and the data coming back from the drone. It’s a long and strange toolchain, but the upshot is that he’s now able to create KML in real time and track the drone on Google Earth as it flies. The video below shows the build and a few backyard test flights.

Congratulations to [Jason] for breaking the protocol and opening up drones like this for other hackers. If you’re interested in learning more about Zigbee sniffing, you can actually hack a few smarthome gadgets into useful sniffers.

Continue reading “Drone Gives Up Its Wireless Secrets To Zigbee Sniffer”

Which Wireless Is Right Wireless?

Back in the early days of Arduino proliferation (and before you ask, yes we realize there was a time before that too), wireless was a strange and foreign beast. IR communication was definitely a thing. And if you had the funds there was this cool technology called ZigBee that was available, often in funny blue house-shaped XBee boards. With even more funds and a stomach for AT commands you could even bolt on a 2G cell radio for unlimited range. WiFi existed too, but connecting it to a hobbyist ecosystem of boards was a little hairier (though maybe not for our readership).

But as cell phones pushed demand for low power wireless forward and the progression of what would become the Internet of marking Terms (the IoT, of course) began, a proliferation of options appeared for wireless communication. Earlier this week we came across a great primer on some of the major wireless technologies which was put together by Digikey earlier in the year. Let’s not bury the lede. This table is the crux of the piece:

There are some neat entries here that are a little less common (and our old friend, the oft-maligned and never market-penetrating ZigBee). It’s actually even missing some entries. Let’s break it down:

  • Extremely short range: Just NFC. Very useful for transferring small amount of sensitive information slowly, or things with high location-relevance (like between phones that are touching).
  • Short range: BLE, Zigbee, Z-Wave, etc. Handy for so-called Personal Area Networks and home-scale systems.
  • Medium/long range: Wifi, Bluetooth, Zigbee, Z-Wave, LoRaWAN: Sometimes stretching for a kilometer or more in open spaces. Useful for everything from emitting tweets to stitching together a mesh network across a forrest, as long as there are enough nodes. Some of these are also useful at shorter range.
  • Very Long range/rangeless: Sigfox, NB-IoT, LTE Category-0. Connect anywhere, usually with some sort of subscription for network access. Rangeless in the sense that range is so long you use infrastructure instead of hooking a radio up to a Raspberry Pi under your desk. Though LoRa can be a fun exception to that.

You’re unlikely to go from zero to custom wireless solution without getting down into the mud with the available dev boards for a few different common protocols, but which ones? The landscape has changed so rapidly over the years, it’s easy to get stuck in one comfortable technology and miss the appearance of the next big thing (like how LoRaWAN is becoming new cool kid these days). This guide is a good overview to help catch you up and help decide which dev kits are worth a further look. But of course we still want to hear from you below about your favorite wireless gems — past, present, and future — that didn’t make it into the list (we’re looking at you 433 MHz).

Michael Ossmann Pulls DSSS Out Of Nowhere

[Michael Ossmann] spoke on Friday to a packed house in the wireless hacking village at DEF CON 25. There’s still a day and a half of talks remaining but it will be hard for anything to unseat his Reverse Engineering Direct Sequence Spread Spectrum (DSSS) talk as my favorite of the con.

DSSS is a technique used to transmit reliable data where low signal strength and high noise are likely. It’s used in GPS communications where the signal received from a satellite is often far too small for you to detect visually on a waterfall display. Yet we know that data is being received and decoded by every cell phone on the planet. It is also used for WiFi management packets, ZigBee, and found in proprietary systems especially any dealing with satellite communications.

[Michael] really pulled a rabbit out of a hat with his demos which detected the DSSS signal parameters in what appeared to be nothing but noise. You can see below the signal with and without noise; the latter is completely indiscernible as a signal at all to the eye, but can be detected using his techniques.

Detecting DSSS with Simple Math

[Michael] mentioned simple math tricks, and he wasn’t kidding. It’s easy to assume that someone as experienced in RF as he would have a different definition of ‘simple’ than we would. But truly, he’s using multiplication and subtraction to do an awful lot.

DSSS transmits binary values as a set called a chip. The chip for digital 1 might be 11100010010 with the digital 0 being the inverse of that. You can see this in the slide at the top of this article. Normal DSSS decoding compares the signal to expected values, using a correlation algorithm that multiplies the two and gives a score. If the score is high enough, 11 in this example, then a bit has been detected.

To reverse engineer this it is necessary to center on the correct frequency and then detect the chip encoding. GNU radio is the tool of choice for processing a DSSS capture from a SPOT Connect module designed to push simple messages to a satellite communication network. The first math trick is to multiply the signal by itself and then look at spectrum analysis to see if there is a noticeable spike indicating the center of the frequency. This can then be adjusted with an offset and smaller spikes on either side will be observed.

When visualized in a constellation view you begin to observe a center and two opposite clusters. The next math trick is to square the signal (multiply it by itself) and it will join those opposite clusters onto one side. What this accomplishes is a strong periodic component (the cycle from the center to the cluster and back again) which reveals the chip rate.

Detecting symbols within the chip is another math trick. Subtract each successive value in the signal from the last and you will mostly end up with zero (high signal minus high signal is zero, etc). But every time the signal spikes you’re looking at a transition point and the visualization begins to look like logic traced out on an oscilloscope. This technique can deal with small amounts of noise but becomes more robust with a bit of filtering.

This sort of exploration of the signal is both fun and interesting. But if you want to actually get some work done you need a tool. [Michael] built his own in the form of a python script that cobbles up a .cfile and spits out the frequency offset, chip rate, chip sequence length, and decoded chip sequence.

Running his sample file through with increasing levels of noise added, the script was rock solid on detecting the parameters of the signal. Interestingly, it is even measuring the 3 parts per million difference between the transmitter and receiver clocks in the detected chip rate value. What isn’t rock solid is the actual bit information, which begins to degrade as the noise is increased. But just establishing the parameters of the protocol being used is the biggest part of the battle and this is a dependable solution for doing that quickly and automatically.

You can give the script a try. It is part of [Michael’s] Clock Recovery repo. This talk was recorded and you should add it to your reminder list for after the con when talks begin to be published. To hold you over until then, we suggest you take a look at his RF Design workshop from the 2015 Hackaday Superconference.