A Complex Way To Push A Button

We’ve likely all looked at a simple problem in our lives and thought that it would be an easy fix, only to realize that the project is enormously more complicated than we first realized. Whether that’s starting a home improvement project, doing a quick repair to a bicycle or car, or trying to install an obscure piece of software on a Linux machine, the amount of time we budget for these tasks often ends up woefully underestimated. []’s night light needs to have its brightness set every night, and it seems easy enough to get a microcontroller to automate that, right?

Well, upon opening the small device, the first issue is that there is no labeling on any of the parts, so simply adding a jumper on to existing microcontroller pins without damaging anything wouldn’t easily be possible. Adding a secondary microcontroller is the next logical step, but the power supply in the night light is extremely underpowered so using even the smallest Raspberry Pi or off-the-shelf Arduino was out of the question too. [Oscar] instead chose an ATtiny85, which solves the power requirement issue, but these are a bit more of a challenge to program without a USB device. From there, it needs a transistor wired in to the circuit to actually push the button for him, plus a few support resistors, so [Oscar] actually had a PCB custom-built to hold all of these components.

Even after all of that, the space within the night light enclosure made installing the PCB a challenge, but in the end he has a device which, when his home automation system powers on the plug for the nightlight, automatically boots up and pushes the switch the required number of times and then puts itself to sleep. We’d call that a success even after the colossal effort getting this inexpensive, small light working the way he wanted. There are some other low-powered solutions for problems like these too, as long as being battery-powered isn’t a dealbreaker.

Samsung’s SmartThings API Terminates Free Access

If there’s one constant in the world of commercial home automation solutions, it is that of decreasing availability and higher costs as time goes on. So too with Samsung’s SmartThings, the API of which will cease free access in October of 2026.

While this does not affect people who use the SmartThings app, any system that relies on access to this API will soon face a $4.99 per month fee for non-commercial users, with various commercial tiers also in the pipeline. While the rest of the blog post has all the elegance of the output of a ‘please generate a list of plausible excuses’ query to ChatGPT, the most likely reason is that offering free services after the sale of an Internet of Things device will never be profitable.

SmartThings was originally a 2012 Kickstarter campaign that ended up becoming successful enough that the company was bought by Samsung in 2014. Its current offerings are very much like other Smart Home products, with recently added support for Matter and interoperability with third-party devices.

If you have SmartThings integrated with your Home Assistant installation, you are also likely affected by this change if at any point you use the API. Of course, this isn’t the first time that SmartThings customers had to scramble to fix broken infrastructure, such as when in 2021 the original hubs got discontinued.

A vaguely perforated metal cylinder sits on a wooden box with a grey cylinder and LCD display atop it. There are holes in the top of the grey cylinder for air to flow through.

A Smarter DIY Air Filter

As predominantly indoor creatures, it’s important to maintain a healthy habitat for the hacker. [Kishan Pratap Singh] designed a clever solution in AirSense, an ESP32-powered air filter.

If you’re thinking of cleaning the air in your environment, you might also want to know some properties about the air coming out of the filter. AirSense measures PM2.5 dust concentration, Air Quality Index (AQI), temperature, humidity, and atmospheric pressure. The various sensors are mounted along the exhaust path of the filter, which lets your know what kind of air it’s pumping out.

The system drives a 150 mm exhaust fan mounted in a 3D printed cap that pulls air through a cylindrical Xiaomi HEPA filter inside a perforated metal trash can enclosure. The ESP32 and an LCD readout of the environmental data also live in the cap, giving the device a sleek look. While [Singh] chose to run the filter continuously, we wonder if it might be interesting to set it up to only filter the air if air quality drops below a certain level to conserve power, especially if you’re on a time-of-use power plan. That would require redesigning the sensor assembly (or running the unit in reverse), so maybe it’s over-complicating things?

We’ve seen the Xiaomi Air purifier filter mentioned before, but under the auspices of hacking it’s filter DRM, an open source air filter designed by [Naomi Wu], and even an ESP32 pressed into service to plug an air purifier into Home Assistant.

IBM Home Director: Home Automation In 1996

Back in the 1990s IBM had a pretty sizeable presence in the PC market, including its rather spiffy Aptiva series of PCs. Naturally their PCs had to feature heavily in another consumer-related thing that was popular in the 1990s, being smart home automation in the form of IBM Home Director. Recently [Ionic1k] took a look at this blast from the past, starting with one of the original IBM commercials.

At its core it used the same X10 protocol that similar solutions from RadioShack and others used, with many modules and packages you could get to use with it. You could also get a more bespoke installation performed at your home to move beyond mere X10, which some people are still finding when they’re buying a house.

Since this uses powerline communication, it required no wires to be run, just the requisite modules to be plugged into a power outlet, with the video demonstrating the basic setup and installation. The PC itself is plugged into the control module via the serial port, from which the Home Director control software can be used to create a configuration and control the state of connected modules.

Although X10 has the same issues as any kind of powerline communication, overall it seems like a very nice system, with a wide range of modules and absolutely easy to set up even for a casual Windows user.

Continue reading “IBM Home Director: Home Automation In 1996”

Reverse Engineering And Self-Hosting The OBI Smart Energy Tracker

Sold by German DIY store OBI, the OBI Energy Tracker is a €15 set of two devices, one of which you essentially stick on top of your existing electricity meter. This then allows for electricity usage to be measured and tracked, with the data sent to the second, gateway device. This latter cloud-bound device is linked to an OBI account via the heyOBI app. This correspondingly called for the gateway device to be reverse-engineered and freed from its cloud-based shackles, a task that [Aaron Christophel] happily took upon himself.

The whole process is also covered in two videos, with the first providing all the essentials on reprovisioning the original firmware for a local MQTT server in English, while the second, German-language video focuses on custom firmware for the ESP32-C3 inside of the gateway device.

Inside the reader device is a Cortex-M0+-based BAT32G135 MCU that communicates with the meter via its IR protocol. This is then communicated via 868 MHz LoRa to the gateway device that will be placed somewhere within Wi-Fi reach by the user. Inside this latter device is as mentioned the ESP32-C3, which by default runs firmware that communicates via secure MQTT with an AWS cloud instance for the typical cloud-based shenanigans.

The aforementioned reprovisioning option doesn’t require firmware flashing, just a handful of steps to follow. This involves fetching the 32-bit TEA key, generating your own PKI, running your own MQTTS-capable broker and having the provided Python script handle the rest from there.

Flashing custom firmware is the other option, with straightforward UART/JTAG reflashing sadly disabled by the manufacturer. With the effort required here you could perhaps argue that simply connecting the reader device to a custom gateway device might be a lot easier, especially if you already have a LoRa transceiver and associated hardware.

Continue reading “Reverse Engineering And Self-Hosting The OBI Smart Energy Tracker”

Home Automation: Simple Vs Easy

We’ve been talking a bunch of home automation on the Podcast lately, and this week, in the Mailbag segment, a reader asked us about our setups. Neither Kristina nor I are poster children for the home automation movement: she has absolutely no smart anything because she didn’t want her data up in “the cloud”, and I have an entirely local system that’s really nothing more than a bunch of ad-hoc scripts that talk to an MQTT broker, everything fully DIY but held together with metaphorical duct tape. Neither of us are doing it right, but we’re doing it wrong in interestingly different ways.

Kristina thought, probably because of the range of commercial devices out there that tie you into using their remote data storage services, that giving up control of her data was necessary to use it. And it might be, if you insist that setting up the system be as easy as possible. But the tradeoff for this ease is a drastic reduction in simplicity. You shouldn’t need a remote server in some foreign country to turn your lights on and off. Adding “the cloud” into the mix brings a lot of complexity, mostly in the form of servers that have to be paid for somehow by whatever company is providing the service. It needs to be secure. You might even have to create accounts, remember passwords, and manage that whole deal. Sure, that’s easy enough, but it’s a lot of moving parts, and you can’t blame her for rejecting that complexity.

My system is hosted on a now-ancient OrangePi in the corner, and the network in question is an old WiFi router that it sits on. Nothing needs to leave my four walls, but actually some of it does – I bridge some of the MQTT topics out to an external server for my own amusement. There is no protocol, and no real “system” frankly. Each device in the network has its own topic, and I’m responsible for knowing what it means. The thermometer in the basement has an ESP8266 that transmits on the home/basement/temperature topic, and it puts out its temperature in degrees Celsius. It was the simplest system I could think of, but I have to write whatever software I want to log, display, or act on the data. Of course, that’s simple if you can write some four-liner scripts on the OrangePi broker, but it’s not easy enough that my wife wants to hack on it.

So if the full-buy-in commercial systems are easy but overly complex, and my DIY network is transparently simple but requires a level of hands-on that isn’t easy for “normies”, is there a middle ground? I know half of you are already screaming Home Assistant or Domoticz, and you’re also thinking of which client device libraries you like the most for all your DIY applications: ESPHome vs Tasmota, for instance. And you’re all right!

We are living the in the golden age of the home automation projects. Open-source software and firmware, combined with an abundance of online tutorials and worked examples, have made huge strides toward bridging the gap between simplicity and ease of use. You can set up a hub for everything on a single-board computer, upload the software of your choice, and you don’t need the complexity or loss-of-support liability of a cloud provider. At the same time, setup is easy enough if you’re willing to roll up your sleeves a little bit, and when it’s not, chances are good that someone else has already figured it out for you. These days, interoperability with popular commercial products is shockingly easy to boot.

I need to spend some time and rationalize my system: given the state of the art, it’s simply too simple, and taking a step into an open-source solution would make it easier to use for the rest of the family, without overly complexifying things, adding sketchy dependencies, or losing our data sovereignty. I haven’t finished exploring my options yet, but from what I can see, the community has converged on some goldilocks setups: not too simple or too easy, but rather just right. Thanks, y’all!

Connecting Your Car To Home Assistant

With how much time many of us spend in our cars, it makes perfect sense to consider them a second home. Yet even if that’s not the case, there are still good reasons to connect a car to one’s smart home solution like Home Assistant, such as to keep track of certain parameters for easy monitoring and reminders. This is what [The Stock Pot] channel recently demonstrated using a widget that connects to the OBD-II port inside the car, as not every car comes with its own app yet.

The used dongle is the ESP32-S3-based WiCAN from Australian company MeatPi. This device runs the open source WiCAN firmware. After plugging the dongle into the OBD-II port of the car, the device powers on and can be configured via Wi-Fi like any other smart device these days. After that it’s just another Wi-Fi device on the network.

Since each car’s ECU will represent data differently, you need a car-specific configuration, which can take some tweaking. The idea of integrating with Home Assistant is directly supported by MeatPi, with a handy documentation page. Of course [The Stock Pot] shared their configuration if you want to feel inspired. Among the parameters monitored you get things like fuel level, days to service and coolant temperature.

Although you could make the argument that it mostly saves you from having to waddle over to the car to check the data there, being able to remotely access the OBD-II port of a car does seem rather practical even outside of home automation concepts, such as gathering performance statistics and early failure warnings, especially for aspects like tire pressure and unhappy engine or BEV battery conditions that can quickly go from an inconvenience to very expensive.

Continue reading “Connecting Your Car To Home Assistant”