I’m sure that you’ve heard about the Sonos speaker debacle. (If not, read about it on Hackaday.) Basically, a company that sells a premium Internet-connected speaker wanted to retire an older product line, and offered a 30% discount to people who would “trade in” their old speakers for new ones. The catch: they weren’t really trading them in, but instead flashing a “self-destruct” firmware and then taking it to the recycling.
Naturally, Sonos’ most loyal customers weren’t happy about intentionally bricking their faithful devices, a hubbub ensued, and eventually the CEO ended up reversing course and eating crow. Hackaday’s own Gerrit Coetzee wrote up our coverage and mentioned that maybe Sonos just couldn’t afford to support the service for the old products any more, and didn’t want them to remain in the wild. So much so, that it’s worth 30% of the cost of their current product to get out from under the implicit contract.
By buying one of these IoT devices, you’re paying more money up front for the promise that the company will keep supporting the service that it relies on into the future. But providing this service costs money, and as more and more “products” are actually services in disguise, we’ve seen case after case of working machines shut down because the company doesn’t want to keep paying for the service. It doesn’t seem to matter if the company is small, like Sonos, or an immensely wealthy monopoly player like Google. Somehow, the people planning these products have a much shorter lifetime in mind than their customers do, and fail to make the up-front price cover costs.
This puts these companies in a tough spot. The more a customer loves the device, the longer they’ll want to keep it running, and the worse the blowback will be when the firm eventually has to try to weasel its way out of a “lifetime” contract. And they are alienating exactly their most loyal customers — those who want to keep their widget running longer than might even be reasonable. Given that this whole business model is new, it’s not surprising that some firms will get it wrong. What’s surprising to me is how many fall into the IoT trap.
So take this as a cautionary tale as a consumer. And if you’re in a company offering a product that depends on a service to continue to function, ask yourself if you’re really going to be able to support it for the customer’s idea of the lifetime of the product. What looks like a great deal at a five-year horizon might bankrupt your company at ten. Will you, or your customers, be willing to throw their devices away? Should they be?
It’s the end of another decade, and while we don’t have real hoverboards, flying cars, or affordable dental care, we do have multicolored lightbulbs you can control over WiFi. [Don Howdeshell] picked up a couple of cheap Merkury branded units in a Black Friday sale, and quickly set about hacking them.
By and large, many of these bulbs are manufactured by various companies and rebranded for whoever happens to place an order. The bulbs tend to use the Tuya IOT ecosystem. Based on the ESP8266, reflashing the bulbs with custom firmware is simple, thanks to the Tuya Convert project. Using a Linux computer with a WiFi card running in Access Point mode, it spoofs a server that tricks the Tuya product into downloading a firmware update. From there, the bulb is an open book, ready to do your bidding.
One of [Don]’s attempts didn’t go so swimmingly, however. Flashing the firmware failed and the bulb was non-functional. [Don] elected to to a teardown, photographing it for our perusal, before hooking up to the ESP8266 directly over its serial interface. From there, it was simple to reprogram the bulb with Tasmota firmware, getting it back up and running.
Security alone is a great reason for running your own firmware on IoT devices. It never hurts to know what you’re connecting to your network!
There’s nothing quite like a deadline to cut through extras and get right at the heart of the problem. Maybe we should all follow Interpreet’s example and stop thinking about automating our homes and just make it in an eight-day hackathon. His talk at the 2019 Hackaday Superconference covers the zero-to-deployment home automation build he finished in the eight days leading up to his move from one continent to another.
Hackaday’s very own Inderpreet Singh found himself pulling up roots and moving from his home in India to teach at Centennial College in Toronto, Canada. He needed a way to keep an eye on his home from afar and the name of the game is IoT. When the only choice is “whatever works right now”, you can learn a lot about simple solutions.
He chose familiar hardware to work with, with the ESP8266 making up the bulk of the nodes and a Raspberry Pi as as a central hub for the setup. He chose to communicate between all the nodes on his system using WiFi because the hardware is robust and available. With security in mind, he keeps the automation system separate from the daily use WiFi system by grabbing an extra access point to serve as the automation network. The Raspberry Pi serves as a router of sorts; its Ethernet port is connected to the IoT device’s AP, while the onboard WiFi is used to connect to the home’s main AP for a connection to the wider Internet.
Software for the system is built on a REST API served by a Python Flask app. Many would advocate for using MQTT but Inderpreet’s testing with that protocol came up short as the broker he intended to use was no longer available. One of the interesting parts of his system design is that all nodes will check in at regular intervals; this allows them to inquire about actions they need to take, but it also allows the system to detect a malfunctioning node immediately. I’ve seen a similar trick used by Elliot Williams where he assigns a “ping” topic to all MQTT devices that causes them to report in with their IP address. Having a system to query and ensure the health of every node is a big tip to take away from this talk.
Continue reading “An Eight-Day Home Automation Hackathon Is Inspiration For Getting More Projects Done”
Home automation is a popular project to undertake but its complexity can quickly become daunting, especially if you go further than controlling a few lights (or if you’re a renter). To test the waters you may want to start with something like this home safety monitor, which is an IoT device based on an Arduino. It allows remote monitoring of a home for things such as temperature, toxic gasses, light, and other variables, which is valuable even if you don’t need or want to control anything.
The device is built around an Arduino Nano 33 IOT which has WiFi and Bluetooth capabilities as well as some integrated security features. This build features a number of sensors including pressure/humidity, a gas/smoke detector, and a light sensor. To report all of the information it gathers around the home, an interface with Ubidots is configured to allow easy (and secure) access to the data gathered by the device.
The PCB and code for the project are all provided on the project page, and there are a number of other options available if Ubidots isn’t your preferred method of interfacing with the Internet of Things. You might even give Mozilla’s WebThings a shot if you’re so inclined.
Well, this is it. The end of the decade. In a few days the 2010s will be behind us, and a lot of very smug people will start making jokes on social media about how we’re back in the “Roaring 20s” again. Only this time around there’s a lot more plastic, and drastically less bathtub gin. It’s still unclear as to how much jazz will be involved.
Around this time we always say the same thing, but once again it bears repeating: it’s been a fantastic year for Hackaday. Of course, we had our usual honor of featuring literally thousands of incredible creations from the hacking and making community. But beyond that, we also bore witness to some fascinating tech trends, moments that could legitimately be called historic, and a fair number of blunders which won’t soon be forgotten. In fact, this year we’ve covered a wider breadth of topics than ever before, and judging by the record setting numbers we’ve seen in response, it seems you’ve been just as excited to read it as we were to write it.
To close out the year, let’s take a look at a few of the most popular and interesting stories of 2019. It’s been a wild ride, and we can’t wait to do it all over again in 2020.
Continue reading “2019: As The Hardware World Turns”
Back at the 2017 Superconference, Hackaday Managing Editor Elliot Williams started his talk about the so-called “Internet of Things” by explaining the only part he doesn’t like about the idea is the Internet… and the things. It’s a statement that most of us would still agree with today. If anything, the situation has gotten worse in the intervening years. Commercial smart gadgets are now cheaper and more plentiful than they’ve ever been, but it seems like precious little has been done to improve their inherent privacy and security issues.
But his talk doesn’t serve to bash the companies producing these devices or even the services that ultimately folded and left their customers with neigh useless gadgets. That’s not his style. The central theme of “Nexus Technologies: Or How I Learned to Love WiFi” is that a smart home can be wonderful thing, assuming it works the way you want it to. Elliot argues that between low-cost modular hardware and open source software, the average hacker has everything they need to build their own self-contained home automation ecosystem. One that’s not only cheaper than what they’re selling at the Big Box electronics store, but also doesn’t invite any of the corporate giants to the party.
Of course, it wasn’t always so. A decade ago it would have been all but impossible, and five years ago it would have been too expensive to be practical. As Elliot details his journey towards a truly personal smart home, he explains the advances in hardware and software that have made it not just possible on the DIY level, but approachable. The real takeaway is that once more people realize how cheap and easy it is to roll your own smart home gadgets, they may end up more than willing to kick Big Brother to the curb and do IoT on their own terms.
This previously unpublished recording somehow slipped between the cracks of the editing room floor but upon recent discovery, it’s still just as relevant today. Take a look at Elliot’s view on Nexus Technologies, then join us after the break for a deeper dive. Make sure to subscribe to Hackaday’s YouTube channel to get in on the 2019 Hackaday Superconference live stream starting Saturday, November 16th.
Continue reading “Found Footage: Elliot Williams Talks Nexus Technologies”
For home use IoT systems, getting sensor data from tons of physical locations centralized to a single Raspberry Pi can be a difficult job, especially when considering the power consumption that’s necessary for doing it all over WiFi. When you’re using an ESP8266, for instance, swapping out batteries and accounting for connectivity issues can be a major hassle for a long-term solution. The NoCAN platform, created by [Alain Pannetrat], solves this problem using a wired approach that improves the use of the CAN bus.
Since SPI and I2C only work for short distances, approaches like RS-485 and CAN bus are a better bet for this type of setup. For systems with one centralized point, RS-485 works best – thus, the CAN bus is the better approach when you’re considering using multiple masters in a single environment.
CAN devices typically need a static address, so messaging involves sending data to the known address of the destination device. With NoCAN, a dynamic address assignment scheme allows nodes to request an address from a node manager on boot-up (similar to DHCP). A command line application also allows users to send and receive message from nodes using a pub/sub implementation – a device sends messages to a channel, and every device subscribed to the channel receives the message.
The hardware for the NoCAN platform consists of a Raspberry Pi with a “PiMaster” HAT and an Arduino-compatible CANZERO board. The PiMaster HAT uses an STM32F042 ARM Cortex M0 MCU, acting as an interface between the Pi and the CAN bus as well as preventing over-current events with a software-controlled smart switch. The CANZERO is based on the the SAMD21G18 ARM Cortex M0+ running at 48MHz, similar to the Arduino MKR Zero, with CAN bus networking using the STM32F042 ARM Cortex M0. The double MCU design allows the secondary MCU to reset the primary if it gets stuck due to a programming error, with the messages sent over the CAN bus.
To join the network together, a four-wire cable daisy-chains the nodes in the bus network, providing connectivity for up to 1000 feet. Either 12V or 24V DC power runs through the network, stepping down to 5V or 3.3V at each node. The approach is similar to PoE (power over Ethernet), although it is slower and lower in cost. Overall, it seems like a good solution for environments where wireless connectivity simply doesn’t cut it.