Trigger Your Home Automation Routines With Home Buttons

November 10, 2022 by Dave Rowntree 11 Comments

Home automation systems are all well and good, so long as the person who built it all is around to drive it. Let’s face it, they’re quite often a complex web of interconnected systems, all tied to the specifics of one’s home — and someone less familiar with it all could get a little irritated if, on a chilly day, the interface to the boiler is via a Python script, and something won’t work. Just saying. Home Buttons by [Matej Planinšek] over on Hackaday.IO is a nicely polished project, which aims to take some of the hackiness out of such automation by providing a sleek front end to those automation routines, enabling anyone to rock on over and set one in action without hassle.

The PCB is based around the ESP32-S2-mini which deals with WiFi connectivity and integration with Home Assistant using the usual MQTT protocol. We expect integration with other flavors of home automation would not be difficult to achieve. The center of the unit holds a simple E-Ink display, for that low-standby power. Specifically, the unit chosen is a Good Display GDEY029T94 2.9″ which this scribe can confirm is easy to interface and pretty cheap to purchase from the usual Chinese online vendors. This was matched up with six clicky Alps SKRB-series low-profile tact switches, which sit on either side of the display, and corresponds to a flexure-type affair on the 3D printed front casing. Neat and simple.

The PCB design was provided in Altium format, which you can find on the project GitHub page. This shows a straightforward design, with a few nice little details here and there. The internally mounted 18650 cell is reportedly good for at least a year of operation, but when time, it can be charged via USB. A Xysemi XB8608AF (PDF) protection chip provides appropriate limiting for the 18650 cell, shielding it from the perils of overcharging, discharging, and whatnot. Not that that is likely in this current setup. A Sensiron SHTC3 humidity and temperature sensor is also in there, hanging off the I2C bus, which makes sense for this application.

Home Automation hacks are plenty on these pages, like this scroll-wheel interface, for instance. If all this stuff is looking quite overbearingly complicated to get into, how about starting with a Pico W?

3D Printering: Adding A Web Interface Where There Was None Before

December 31, 2021 by Dave Rowntree 8 Comments

[Renzo Mischianti] got himself a Chinese 3D printer, specifically a FlyingBear Ghost 5. (Cracking name, huh?) He was more than a little irritated with the fact that whilst the controller, an MKS Robin Nano, did have a integrated Wi-FI module, it provided no browser-based interface for monitoring and control purposes. This seemed a bit short-sighted in this day and age, to say the least. Not being at all happy with that situation, [Renzo] proceeded to write dedicated Wi-Fi firmware using websockets, but not without fully documenting his journey in a detailed series of the blog posts.

The resulting BeePrint web interface supports all the usual functions you would expect when managing a printer, everything from monitoring warm-up at the prep stage, to keeping tabs on the potential spaghetti monster via the connected IP camera. All good stuff. [Renzo] used an ESP32-cam, which is a low-cost 2 MP unit from our friends at Olimex, but we suspect it wouldn’t vastly difficult to add your own IP camera into the mix.

[Renzo] has a YT channel detailing quite a few other projects, which is definitely worth some viewing time in our opinion.

We’ve been covering 3D printer hacking since the dinosaurs were roaming. This is the oldest, and still one of the strangest, posts that we could find in a quick search. Anyone care to find something older?

Continue reading “3D Printering: Adding A Web Interface Where There Was None Before” →

ESP8266 Based WiFi Game Boy Cartridge Browses WikiPedia

December 18, 2021 by Dave Rowntree 8 Comments

[Sebastian Staacks] came across his old Game Boy and was wondering (as you do) what happened to recent attempts at getting a WiFi interface wedged into a standard cartridge. After a while the conclusion was that people had been scuppered by approaching the problem in a way that made it too hard. Obviously that meant it was necessary to follow through and build something, which is precisely what he did with his WiFi Game Boy Cartridge.

A trend lately has been to hook up a fast microcontroller to a bus, then move the whole interfacing shenanigans into software. This works fine in some circumstances, but for the GB interface, it’s not so easy. The GB is powered by the Sharp LR35902, running at a smidge over 4 MHz, but its machine cycle takes four clocks giving an instruction rate of only 1 MHz. The cartridge interface presents the raw CPU bus directly. This is both good and bad. It’s good, because it enables all kinds of expansion modules, like cameras, printers, and other custom peripherals, but it’s bad because the burden of interfacing with the CPU, at its full speed, lies squarely in the cartridge’s remit.

Rather than trying to hook this bus directly to a fast microcontroller, [Staacks] has taken a different approach; by decoding the address bus with discrete logic, it was easy to derive chip selects for an embedded ESP8266 as well as a socketed EEPROM. The clock for the former was also gated and sent into the ESP8266, generating an interrupt to wake it up. The EEPROM stores a simple application whose job is to present an OSD keyboard and send requests to Wikipedia, via the ESP8266 WiFi stack. The resulting text is then displayed on the 160×144 dot matrix display. The interrupt latency of the ESP8266 was mitigated by the application simply discarding the first data byte sent to it, and retrying the access. This way the ESP8266 could spend the majority of its time dealing with wireless duties, only pausing to swap a byte now-and-then with the application. A simple solution which appears to actually work! If you’re up for building one of these and writing your own applications, you can wander over to GitHub, clone yourself a copy and crack on!

We’ve seen a few attempts at doing this before, [davedarko] tried with this project, and if you search hackaday.io you’ll get loads of GB hacks to browse. Finally a recent twitter thread also points to another effort to do something similar with Wi-Fi, but development is still ongoing. We’ll check back later!

Continue reading “ESP8266 Based WiFi Game Boy Cartridge Browses WikiPedia” →

So. What’s Up With All These Crazy Event Networks Then?

November 11, 2021 by Jenny List 21 Comments

As an itinerant Hackaday writer I am privileged to meet the people who make up our community as I travel the continent in search of the coolest gatherings. This weekend I’ve made the trek to the east of the Netherlands for the ETH0 hacker camp, in a camping hostel set in wooded countryside. Sit down, connect to the network, grab a Club-Mate, and I’m ready to go!

Forget the CTF, Connecting To WiFi Is The Real Challenge!

There no doubt comes a point in every traveling hacker’s life when a small annoyance becomes a major one and a rant boils up from within, and perhaps it’s ETH0’s misfortune that it’s at their event that something has finally boiled over. I’m speaking of course about wireless networks.

While on the road I connect to a lot of them, the normal commercial hotspots, hackerspaces, and of course at hacker camps. Connecting to a wireless network is a simple experience, with a level of security provided by WPA2 and access credentials being a password. Find the SSID, bang in the password, and you’re in. I’m as securely connected as I reasonably can be, and can get on with whatever I need to do. At hacker camps though, for some reason it never seems to be so simple.

Instead of a simple password field you are presented with a complex dialogue with a load of fields that make little sense, and someone breezily saying “Just enter hacker and hacker!” doesn’t cut it when that simply doesn’t work. When you have to publish an app just so that attendees can hook up their phones to a network, perhaps it’s time to take another look . Continue reading “So. What’s Up With All These Crazy Event Networks Then?” →

Rolling Your Own LED Matrix Driver, With Copper Foil Tape To The Rescue

May 30, 2020 by Donald Papp 1 Comment

It all started when [Damien Walsh] got his hands on some surplus LED boards. Each panel contained 100 mini-PCBs hosting a single bright LED that were meant to be to be snapped apart as needed. [Damien] had a much better idea: leave them in their 20×5 array and design a driver allowing each LED to be controlled over WiFi. He was successful (a brief demo video is embedded down below after the break) and had a few interesting tips to share about the process of making it from scratch.

The first hurdle he ran into was something most of us can relate to; it’s difficult to research something when one doesn’t know the correct terms. In [Damien]’s case, his searches led him to a cornucopia of LED drivers intended to be used for room lighting or backlights. These devices make a large array of smaller LEDs act like a single larger light source, but he wanted to be able to individually address each LED.

Eventually he came across the IS32FL3738 6×8 Dot Matrix LED Driver IC from ISSI which hit all the right bases. Three of these would be enough to control the 100-LED panel; it offered I2C control and even had the ability to synchronize the PWM of the LEDs across multiple chips, so there would be no mismatched flicker between LEDs on different drivers. As for micontroller and WiFi connectivity, we all have our favorites and [Damien] is a big fan of Espressif’s ESP32 series, and used the ESP32-WROOM to head it all up.

LED pads bridged to copper tape, with Kapton (polyimide) tape insulating any crossovers.

The other issue that needed attention was wiring. Each of the LEDs is on its own little PCB with handy exposed soldering pads, but soldering up 100 LEDs is the kind of job where a little planning goes a long way. [Damien] settled on a clever system of using strips of copper tape, insulated by Kapton (a super handy material with a sadly tragic history.) One tip [Damien] has for soldering to copper tape: make sure to have a fume extractor fan running because it’s a much smokier process than soldering to wires.

A 3D-printed baffle using tracing paper to diffuse the light rounds out the device, yielding a 20 x 5 matrix of individually-controlled rectangles that light up smoothly and evenly. The end result looks fantastic, and you can see it in action in the short video embedded below.

Continue reading “Rolling Your Own LED Matrix Driver, With Copper Foil Tape To The Rescue” →

The Linux Throwie: A Non-Spacefaring Satellite

November 20, 2018 by Sean Boyce 42 Comments

Throwies occupy a special place in hardware culture — a coin cell battery, LED, and a magnet that can be thrown into an inaccessible place and stick there as a little beacon of colored light. Many of us will fondly remember this as a first project. Alas, time marches inevitably on, and launching cheerful lights no longer teaches me new skills. With a nod to those simpler times, I’ve been working on the unusual idea of building a fully functional server that can be left in remote places and remain functional, like a throwie (please don’t actually throw it). It’s a little kooky, yet should still deliver a few years of occasional remote access if you leave it somewhere with sunlight.

A short while ago, I described the power stages for this solar-powered, cloud accessible Linux server. It only activates on demand, so a small solar cell and modest battery are sufficient to keep the whole show running.

Where we left off, I had a solar cell that could charge a battery, and provide regulated 12 V and 5 V output. For it to be a functional device, there are three high level problems to solve:

It must be possible to set up the device without direct physical access
You must be able to remotely turn it on and off as needed.
It needs to be accessible from the Internet.

The funny thing is, this hardware reminds me of a satellite. Of course it’s not meant to go into space, but I do plan to put it somewhere not easy to get to again, it runs off of solar power, and there’s a special subsystem (ESP8266) to tend the power, check for remote activation, and turn the main computer (Raspberry Pi 3) on and off as necessary. This sounds a lot like space race tech, right?

As I have a bit more code than usual to share with you today, I’ll discuss the most interesting parts, and provide links to the full firmware files at the end of the article.

Continue reading “The Linux Throwie: A Non-Spacefaring Satellite” →

Easy Access Point Configuration On ESP8266

October 4, 2018 by Tom Nardi 19 Comments

One of the biggest advantages of using the ESP8266 in your projects is how easy it is to get WiFi up and running. Just plug in the WiFi library, put the SSID and encryption key in your source code, and away you go. It authenticates with your network in seconds and you can get on with building your project. But things get a little trickier if you want to take your project someplace else, or distribute your source code to others. Quickly we learn the downside of using static variables for authentication.

While there are already a few solutions to this problem out there, [Martin Raynsford] wasn’t too thrilled with them. Usually they put the ESP8266 in Access Point mode, allow the user to connect, and then ask which network they should authenticate with. But he didn’t want his projects to require an existing network, and figured he could do just as well making a field-configurable AP.

Using it is simple. Once the ESP8266 starts up it will create a new network in the form of “APConfig XXXXXX”, which should be easy enough to find from your client side device. Once connected, you can go to a simple administration page which allows you to configure a new AP name and encryption key. You even have the option to create an open AP by leaving the “Password” field blank. Once rebooted, the ESP8266 will create a new network with the defined parameters.

[Martin] has also included a “backdoor” to let anyone with physical access to the ESP8266 board create a new open AP that can be used to reconfigure the network settings. During boot up there is a brief period, indicated with specific blinks of the LED, wherein you can hit the reset button and trigger the open AP. This keeps you from getting locked out of your own project if you forget what key you gave it.

If you’re not one to go the austere route, take a look at some of the more robust solutions we’ve seen for easier end-user setup of the ESP8266.