Wyze are a company that produces a variety of home automation products. Their Wyze Sense package is a system of contact and PIR home security sensors, that piggy backs off their Wyze Cam product. In the interests of being able to use this hardware outside the prescribed corporate ecosystem, [Xuan Xing] got down to hacking.
The project starts by tearing down the Wyze Cam, and getting serial console access. This was made easier by an existing Github project, which develops custom firmwares for smart cameras. With that in place he was able to see what was going on under the hood, and read the camera’s system logs.
By poring over these logs, and examining the disassembled Wyze Sense dongle, he’s well on the way to discovering how the sensors communicate with the Wyze Cam. The end goal is to enable the Wyze security sensors to be used with the Raspberry Pi platform, and to share the code on Github for other makers to experiment with.
A common complaint about open hardware and software is that the aesthetic aspects of the projects often leave something to be desired. This isn’t wholly surprising, as the type of hackers who are building these things tend to be more concerned with how well they work than what they look like. But there’s certainly nothing wrong with putting a little polish on a well designed system, especially if you want “normal” people to get excited about it.
For a perfect example, look no further than the HestiaPi Touch. This entry into the 2019 Hackaday Prize promises to deliver all the home automation advantages of something like Google’s Nest “smart” thermostat without running the risk of your data being sold to the highest bidder. But even if we take our tinfoil hat out of the equation, it’s a very slick piece of hardware from a functional and visual standpoint.
As you probably guessed from the name, the thermostat is powered by the Raspberry Pi Zero, which is connected to a custom PCB that includes a couple of relays and a connector for a BME280 environmental sensor. The clever design of the 3D printed case means that the 3.5 inch touch screen LCD on the front can connect directly to the Pi’s GPIO header when everything is buttoned up.
Of course, the hardware is only half the equation. To get the HestiaPi Touch talking to all the other smart gadgets in your life, it leverages the wildly popular OpenHAB platform. As demonstrated in the video after the break, this allows you to use the HestiaPi and its mobile companion application to not only control your home’s heating and air conditioning systems, but pretty much anything else you can think of.
The HestiaPi Touch has already blown past its funding goal on Crowd Supply, and the team is hard at work refining the hardware and software elements of the product; including looking at ways to utilize the unique honeycomb shape of the 3D printed enclosure to link it to other add-on modules.
HestiaPi Touch - An Open Source Open Hardware Smart Thermostat - YouTube
Since his AC unit had an infrared remote control, the first thing [Giulio] needed to do was come up with a way to emulate it. An easy enough project using the ESP8266 and an IR LED, especially when he found that somebody had already written a IR communications library for his particular brand of AC. From there, he could start tacking on sensors and functionality.
With the addition of a DHT11 sensor, [Giulio] can have the AC turn on and off based on the current room temperature. It also gives him an easy way to verify the AC is actually on and operating. By checking to see if the room starts cooling off after sending the IR command to start the AC, his software can determine whether it should try resending the code, or maybe send a notification to alert him that something doesn’t seem right. Of course, it wouldn’t be a proper ESP8266 project without some Internet connectivity, so he’s also created a smartphone application that lets him control the system while away from home.
Now admittedly nothing in this project is exactly new, we’ve seen plenty of hackers switch on their AC with the ESP8266 at this point. But what we particularly liked was how well thought out and documented the whole process was. The rationale behind each decision is explained, and he even documented things like his network topology to help illustrate how the whole system comes together. Even if the techniques are well known by many of us, this is the kind of project documentation that makes it accessible to newcomers. Our hats off to [Giulio] for going the extra mile.
The idea of the so-called “smart bulb” sounds good; who wouldn’t want to be able to verify the porch light is on if you’re out of town for the night, or check to see if you left the bathroom lights on in your rush out the door in the morning? But in practice, it can be a nightmare. Each brand wants to push their own protocol. Even worse, it seems you can’t get anything done without signing up for three different services, each with its own application that needs to be installed on your phone. It’s a frustrating and often expensive mire to find yourself in.
[Dom Gregori] liked the Hue bulbs offered by Philips, but didn’t want to buy into the whole ecosystem of phone apps and hardware hubs they require. So he decided to create his own open source version that would do everything he wanted, without any of the seemingly unavoidable baggage of the commercial offerings. The final result is a professional looking ESP8266 controlled RGB bulb that hooks into Home Assistant via MQTT.
Looking at his Bill of Materials, it’s actually pretty amazing to see how little it really takes to pull a project like this off. Outside of the Wemos D1 Mini board, [Dom] just needed a few concentric WS2812 rings, and a USB charger small enough to fit into the base of his 3D printed enclosure.
We especially like how he handled the socket-side of the bulb, as that’s the part that would have left us scratching our heads. Rather than trying to salvage the base from an existing bulb, or come up with his own printed piece to stick in the socket, he just used a cheap and readily available light socket adapter. The solution might be a little bulky, but we like how he’s deftly avoided having to handle any AC voltages in this project.
There is something strangely amusing about the idea of a sprinkler system relying on a cloud. But it was this limitation in some commercial offerings that led [Zack Lalanne] to create his own controller when it was time to upgrade his aging irrigator.
It’s a straightforward enough device, he’s taken an ESP8266 on the ubiquitous NodeMCU board, and added a shift register for some output line expansion to drive a set of relays. The interest here lies with the software, in which he’s used the ESPHome firmware and added his own custom part for the shift register. This change alone should be useful for many other experimenters with the ‘8266 and ESPHome combination.
The ESP8266 end of the device ties in with his instance of the Home Assistant home automation hub software. On this he’s been able to tie in all his various sprinkler outputs he added, and apply whatever automation scripts he chooses. The result is a freshly watered lawn, with not a cloud in the sky (or backend).
The value of this project lies only partly in its use for sprinkler owners, for us it also lies in the clear write-up showing the way for others with similar home automation tasks. It’s not the only way to make an ESP sprinkler controller, you should also see this one from 2017.
Visitors to the Wizarding World of Harry Potter at Universal Studios are able to cast “spells” by waving special interactive wands in the air. Hackers like us understand that there must be some unknown machinations happening behind the scenes to detect how the wands are moving, but for the kids wielding them, it might as well be real magic. So when his son asked to have a Harry Potter themed birthday party, [Adam Thole] decided to try recreating the system used at Universal Studios in his own home.
Components used in the IR streaming camera
The basic idea is that each wand has a reflector in the tip, which coupled with strong IR illumination makes them glow on camera. This allows for easy gesture recognition using computer vision techniques, all without any active components in the wand itself.
[Adam] notes that you can actually buy the official interactive wands from the Universal Studios online store, and they’d even work with his system, but at $50 USD each they were too expensive to distribute to the guests at the birthday party. His solution was to simply 3D print the wands and put a bit of white prismatic reflective tape on the ends.
With the wands out of the way, he turned his attention to the IR imaging side of the system. His final design is a very impressive 3D printed unit which includes four IR illuminators, a Raspberry Pi Zero with the NoIR camera module. [Adam] notes that his software setup specifically locks the camera at 41 FPS, as that triggers it to use a reduced field of view by essentially “zooming in” on the image. If you don’t request a FPS higher than 40, the camera will deliver a wider image which didn’t have any advantage in this particular project.
The last part of the project was taking the video stream from his IR camera and processing it to detect the bright glow of a wand’s tip. For each frame of the video the background is first removed and then any remaining pixel that doesn’t exceed a set brightness level if ignored. The end result is an isolated point of light representing the tip of the wand, which can be fed into Open CV’s optical flow function to show [Adam] what shape the user was trying to make. From there, his software just needs to match the shape with one of the stock “spells”, and execute the appropriate function (such as changing the color of the lights in the room) with Home Assistant.
Overall, it’s an exceptionally well designed system considering the goal was simply to entertain a group of children for a few hours. We almost feel bad for the other parents in the neighborhood; it’s going to take more than a piñata to impress these kids after [Adam] had them conjuring the Dark Arts at his son’s party.
The increase in network-connected devices the past years has been something of a dual-edged sword. While on one hand it’s really nice to have an easy and straight-forward method to have devices talk with each other, this also comes with a whole host of complications, mostly related to reliability and security.
With WiFi, integrating new devices into the network is much trickier than with Ethernet or CAN, and security (e.g. WPA and TLS) isn’t optional any more, because physical access to the network fabric can no longer be restricted. Add to this reliability issues due to interference from nearby competing WiFi networks and other sources of electromagnetic noise, and things get fairly complicated already before considering which top-layer communication protocol one should use.
In this article we’ll be looking at implementing such a network-based system, securing a WiFi network with TLS, and the use of MQTT in combination with a proxy. I’ll illustrate this using experiences and lessons learned while working on this Building Management and Control (BMaC) project that I covered in a previous article.
Getting MQTT into your system
Message Queuing Telemetry Transport (MQTT) is a small, binary protocol that was developed by Andy Stanford-Clark of IBM and Arlen Nipper of Cirrus Link in 1999. Its version 3.1 was submitted in 2013 IBM to OASIS for standardization. Another version of MQTT is MQTT-SN, which is designed for lower-bandwidth, non-TCP networks, such as Zigbee, UDP and Bluetooth.
Due to its compact size and simple, client-server architecture, it is highly suitable for connecting larger and smaller networks of sensors, especially in high-latency, low bandwidth situations. It uses a subscribe-publish model, where clients can subscribe to topics on which others can publish messages. These messages can be persistent, have guaranteed delivery and (as of version 5) can automatically expire if they cannot be delivered.
The obvious advantage of MQTT is that it supports everything from always-online, high-bandwidth clients, to low-powered, remote sensor nodes which just wake up every week, dial into a satellite link and send some sensor readings while updating their calibration settings from data which they receive at the same time from some other client.
The use of MQTT (with the Mosquitto MQTT broker) in the BMaC project was initially more of a coincidence, with us using it mostly because an MQTT client was already integrated into the framework we were using on the microcontrollers. None of us had really thought about the advantages or disadvantages of MQTT over any alternatives. Now, years later, it’s easy to see why MQTT was the right choice. While running it on an internal, TCP-based network, we got the guaranteed delivery aspect of TCP along with its built-in checksum verification, with the MQTT protocol itself putting no constraints on the payload it can carry, whether it be text-based or binary.
Real competition for MQTT does not really exist. AMQP is also fairly popular, but it targets desktop and server systems in an enterprise setting, and doesn’t really scale down to RAM-constrained 8-bit microcontrollers. Further, AMQP also defines an encoding scheme for the payload, whereas MQTT leaves one free to use whichever encoding or serialization scheme one wishes to use.
With BMaC we could thus develop our own payload format that would be sent to and from the ESP8266-based nodes. This resulted in a compact, binary format using just a few bytes at most that sufficed to configure nodes over MQTT as well as adjust the fan and relay settings.
Securing the System
The best way to secure a system is through the practice of security in depth. That means that every part that could be exploited should be secured in some fashion. Assuming a system like that of BMaC, this means that the physical hardware is all inside an office building, which has its own security system installed.
This security system can be simple mechanical locks, or some NFC tag-based system. Sensitive areas like server rooms require their own access keys or permissions associated with the NFC tags. This practically eliminates any risk of unauthorized individuals gaining access to the hardware, let alone perform any nefarious actions.
Wireless networks for a system like this are of course secured by WPA2 or similar, meaning that without the right password or certificate, one cannot connect to the wireless network. Any traffic on the network will consequently be encrypted. This shifts the most likely threat to those who somehow have gained access to the network, whether through legal means, or because the WiFi SSID and password were in a photograph that got published on the public company blog (true story).
At this point we have an okay level of security, but the missing ingredient is to secure the traffic between the nodes and the backend servers, meaning either TLS encryption (very common), or Elliptic Curve Cryptography (ECC), which would be the superior choice because it’s faster, requires significantly less RAM, and has much smaller certificates. Unfortunately ECC has taken the backseat to TLS, mostly on account of it being patent-encumbered for much longer.
This made TLS the easier type to integrate into the BMaC project, as adding ECC would have meant ditching the axTLS library in the framework which we were using for the ESP8266 nodes and integrating an alternate library that supports ECC and also fits in the limited RAM provided by this microcontroller.
The Part Where Things go Boom
We quickly found out that the default handshake setting in TLS encryption for TCP connections causes massive problems for an ESP8266 and similar MCUs which tend to have less than 30 kB of SRAM available when this handshake event occurs.
The default TLS configuration dictates namely that the maximum TX/RX buffer sizes are allocated when a secure connection is attempted, being 16 kB each, or 32 kB in total. With non-trivial firmware this results in the MCU running out of memory and the MCU resetting. Fortunately this setting can be changed on the side of the server, as noted in this article on TLS. This would allow the server to set the TLS buffer size to something that would fit in the MCU’s SRAM.
Sadly for BMaC, the server on the Mosquitto MQTT broker didn’t have this as a configuration setting, requiring us to change it in the source code and recompile the server. That seemed a bit of overkill.
Instead we opted to add a different TLS endpoint to the system, using HAProxy as an intermediate. We configured an interface with TLS-only access that simply routes any decrypted data to Mosquitto via the localhost loopback interface, and set the tune.ssl.maxrecord property to 2 kB, for 4 kB of buffer space on the ESP8266. After enabling both server and client certificates on the HAProxy and BMaC node firmware respectively, we had a TLS-encrypted connection up and running, ensuring that not even our colleagues could sniff on what we were doing.
Putting it Together
By the time we had finished wiring up the first controller for the air conditioning system at the office, the BMaC project consisted out of a wireless network of motion, temperature, CO2, air pressure and coffee usage sensors, along with a bunch of relays and fan controllers, all tied together using a central backend server and secure MQTT connections..
After getting the network set up, with MQTT secured using client-side certificates to make sure that only genuine BMaC MQTT clients could connect, it was very nice to be able to focus on getting the commands and data transferred between the nodes and the backend. The only issue that really annoyed me there was the lack of an MQTT desktop client that would allow me to do MQTT monitoring, active topic discovery and be directly compatible with binary payloads instead of assuming that one would only ever use MQTT for text-based payloads.
This led to me developing a C++/Qt-based MQTT desktop client called MQTTCute. It’s the client I wish I would have had right from the beginning as I was setting up the whole system, trying to get an idea of what was being sent around on the MQTT topics. Since we ended up using a binary protocol for BMaC, having a built-in hex view function in the desktop client would have been invaluable.
Regardless, if we had to do it all again, with the knowledge we gained, we would pretty much still have picked the same route. Likely we would try to use ECC instead of TLS, however, just to save ourselves the overhead of using an additional TLS endpoint and proxy server.
We also found that a number of MQTT libraries assumed text-based payloads, and would use C functions like strlen() and kin. Many of them have since received pull requests from yours truly so that those libraries now happily accept any kind of binary data one wishes to send via MQTT, including images.
The Elephant in the Room
When it comes to MQTT and similar client-broker systems, there’s always the argument that they cannot be reliable because they have a single point of failure in the form of the MQTT broker. This is definitely a valid point, but also not nearly as valid as one might assume.
MQTT brokers tend to run on reliable server hardware, in the case of BMaC as a Linux virtual machine instance on a storage cluster. For the broker to suddenly vanish off the network would require the kind of catastrophic failure that’d cripple the company’s network along with it.
One could conceivably set up a second, fall-over MQTT broker on a secondary address, but that would be a lot of work without good cause. In our own year-long BMaC development process, we had zero failures of the Mosquitto broker and more issues with glitches in the (old) WiFi access points.
At this point it’s something of a given that a member of the ESP8266 family is likely your best bet if you want to cobble together a small Internet-connected gadget. Costing as little as $3 USD, this well documented all-in-one solution really can’t be beat. But of course, the hardware is only one half of the equation. Deciding how to handle the software side of your homebrew Internet of Things device is another story entirely.
A simple Telegram ESP8266 switch
It would be fair to say that there’s no clear-cut “right” way to approach the software, and it really depends on the needs or limitations of your particular project. For example [Brian Lough] finds that building Telegram support into his ESP8266 allows him to accomplish his goals with the minimum amount of fuss while at the same time using an environment he’s already comfortable with. He recently wrote in to share one of his Telegram projects with us, and in the video after the break, takes the time to explain some of the things he likes best about controlling his hardware through the encrypted chat platform.
But you don’t have to take his word for it, you can try it yourself. Thanks to the software library that [Brian] has developed to connect his projects to Telegram, the aptly named “Universal Telegram Bot Library”, anyone can easily follow in his footsteps. Adding his Telegram library to your next ESP8266 project is as easy as selecting it in the Arduino IDE. From there the video explains the process for getting a bot ID from Telegram, and ultimately how you use it to receive messages from the service. What you do with those messages is entirely up to you.
Today’s story is one of victory and defeat, of mystery and adventure… It’s time to automate the garage door. Connecting the garage door to the internet was a must on my list of smart home features. Our opener has internet connection capabilities built-in. As you might guess, I’m very skeptical of connecting a device to the internet when I have no control over the software running on it.
The garage door is controlled by a button hung on the garage wall. There is only a pair of wires, so a simple relay should be all that is needed to simulate the button press from a Raspberry Pi. I wired a relay module to a GPIO on the Pi mounted in the garage ceiling, and wrote a quick and dirty test program in Python. Sure enough, the little relay was clicking happily– but the garage door wasn’t budging. Time to troubleshoot. Does the push button still work? *raises the garage door* yep. How about the relay now? *click…click* nope.
You may have figured out by now, but this garage door opener isn’t just a simple momentary contact push button. Yes, that’s a microcontroller, in a garage door button. This sort of scenario calls for forensic equipment more capable than a simple multimeter, and so I turned to Amazon for a USB oscilloscope that could do some limited signal analysis. A device with Linux support was a must, and Pico Technology fit the bill nicely.
Searching for a Secret We Don’t Actually Need
My 2 channel Picotech oscilloscope, the 2204A, finally arrived, and it was time to see what sort of alien technology was in this garage door opener. There are two leads to the button, a ground and a five volt line. When the button is pressed, the microcontroller sends data back over that line by pulling the 5 V line to ground. If this isn’t an implementation of Dallas 1-wire, it’s a very similar concept.
The wire protocol appears simple enough to reproduce, ideally with an opto-isolator. I found a suitable chip and got it on order. With the physical interface sorted, it was time to move on to the data itself.
So, what does the request to open look like? “Open Sesame”? The Picoscope software is capable of signal decoding, so some futzing with those settings got reproducible results. UART at 9.6 kbaud. 38 bytes of data were being sent over the wire, and the next step was to capture several of those packets to look for patterns.
Each packet started with a repeatable pattern that Picoscope decoded as 55 01 00. A header of sorts? A source or destination identifier? So far, I just didn’t have enough information to tell. Other than that pattern, the data appeared to be random. So where to from here?
The underside of the switch lists a couple patent numbers. Patent applications often have lots of useful information that is not available anywhere else. Patents also show off legalspeak at its worst. Wading through patents like 7,561,075 does yield the occasional nugget. It describes an encryption (or obfuscation) scheme revolving around a simple transformation. Looking at the patent documentation, I suspected it would be possible to break the encryption scheme and spoof the garage door button being pressed.
A Python script to do the data processing was my next planned move. With a little luck, I thought I could re-create the algorithm, as well as potentially recover the secrets used to generate the data. Many a project have been derailed when the needs of real life have intruded in the life of the hacker, and I’m not immune. For about a month, that’s where the project languished. We’ve moved into the house, my firstborn is a week old, and it’s time to finally get the garage door working.
Spoof the Button, Not the Cryptography
Remember how we started by looking for a simple push button switch? It turns out, there is such a switch built in to the wired opener. Soldering leads onto that small button is the fastest to implement, if not the most elegant. Yes, my solution is a Raspberry Pi running a relay, and that relay bridging the tiny physical button on the wired opener.
Elegant but complicated solutions can be major pitfalls to getting stuff done. Sometimes you have the time to dig in and put together the ideal solution, but sometimes you just have to get the project done. If it’s cheating and it works, it’s not… Ok, it’s still cheating, but it works, which is more important.
We can open the garage door from a command line on the Raspberry Pi. That’s useful, but perhaps a bit clunky. Remember way back in the first article, I mentioned using flask to create a RESTful interface? Here’s where we can really get started.
This runs a rudimentary flask server, listening for http connections. Here the relay is on GPIO20, and so the server is waiting for a request for “/moment/20”, at which point, it flips that GPIO high for a half second, triggering the garage door. In order to run automatically, I’ve saved this to /usr/local/bin/gpio-flask.py, and then defined a systemd service at /lib/systemd/system/gpio-flask.service:
Description=Flask Service for GPIO
Telling systemctl to enable and start that service gets us in business. One last piece of the puzzle, let’s build a control page on our PXE server.
We’ll expand on this PHP script more in the future, but for now it has two functions. The first builds and displays the interface page — just a single big button labelled “cycle garage”. The second part of the script only acts when a POST request is received. If the “GDO” value is present in the request, it uses curl to fire off the command to our Raspberry Pi, raising the garage door. It’s been a long road, but it finally works. A button on a web page opens my garage door. Let me relish my small victory for a moment…
Now that we’ve cheated our way past the garage door opener, next time we can work on data logging and HVAC control. Until then, happy hacking!
The month or so after the holidays have always been a great time to pick up some interesting gadgets on steep clearance, but with decorations and lights becoming increasingly complex over the last few years, the “Christmas Clearance” rack is an absolute must see for enterprising hackers. You might just luck out like [ModernHam] and find a couple packs of these dirt cheap wireless light controllers, which can fairly easily be hacked into the start of a home automation system with little more than the Raspberry Pi and a short length of wire.
In the video after the break, [ModernHam] walks the viewer through the start to finish process of commanding these cheap remote plugs. Starting with finding which frequencies the remotes use thanks to the FCC database and ending with using cron to schedule the transmission of control signals from the Pi, his video really is a wealth of information. Even if you don’t have this particular model of remote plug, or don’t necessarily want to setup a home automation system, there’s probably some element of this video that you could still adapt to your own projects.
The first step of the process is figuring out how the remote is communicating to the plugs. [ModernHam] noticed there was no frequency listed on the devices, but using their FCC IDs he was able to find the relevant information. In the United States, devices like these must have their FCC IDs visible (though they could be behind a battery door) by law, so the searchable database is an invaluable tool to do some basic reconnaissance on a poorly documented gadget.
An RTL-SDR receiver is then used to fine tune the information gleaned from the FCC filing. [ModernHam] found that the signals for all four of the remote plugs were being broadcast on the same frequency, which makes controlling them all the easier. Using the rtl-sdr command, he was able to capture the various signals from the transmitter and save them to separate files. Then it’s just a matter of replaying the appropriate file to get the plugs to do your bidding.
Of course, the RTL-SDR can’t transmit so you’ll have to leave your dongle behind for this last step. Luckily all you need to transmit is the rpitx package created by [F5OEO], along with a supported Raspberry Pi and a small length of wire attached to the appropriate GPIO pin. This package contains the tool sendiq which can be used to replay the raw captures made in the previous step. With some scripting, it’s fairly straightforward to automate these transmissions to control the remote plugs however you wish from the Pi.