A Failed SwitchBot Plug Mini and Cooking Electrolytics

Poorly designed PCBs and enclosures that slowly cook the electrolytic capacitors within are a common failure scenario in general, but they seem especially prevalent in so-called Internet-of-Things devices. The SwitchBot Plug Mini that [Denki Otaku] took a look at after many reports of them failing is one such example.
The location of the failed electrolytic cap in the SwitchBot Plug Mini. (Credit: Denki Otaku, YouTube)
These Mini Plugs are ‘smart’ plugs that fit into a regular outlet and then allow you to control them remotely, albeit not integrated into a wall or such like the Shelly 2.5 smart relay that also began dying in droves. Yet whereas with the Shelly relays this always seemed to take a few years to show up, generally in the form of WiFi connectivity issues, these SwitchBot plugs sometimes failed within weeks or start constantly switching the relay on and off.

After SwitchBot started an exchange program for these plugs, [Denki Otaku] decided to examine these failed devices from affected users. Inside a dead unit the secondary side’s 680 µF capacitor was clearly bulging and had cooked off its electrolyte as a teardown of a dead capacitor confirmed. After replacing this one capacitor a formerly unresponsive plug sprung back to life.

This failed capacitor is important as it serves as the buffer for the 3.3 V rail, which otherwise sags below the operational range of the microcontroller during power-hungry WiFi operations, causing it to reset. As for the question of why this failure happened, there are two possibilities: one involves the B- or C-tier capacitor – for which no datasheet could be found – being unsuitable for dealing with the ripple current it was exposed to, the other being the high temperatures in that section of the PCB.
Thermal image of the electrolytic capacitor area in the SwitchBot Plug Mini. (Credit: Denki Otaku, YouTube)
As a thermal image of the working PCB shows, the voltage regulator and switching circuitry present on the PCB – right below where the failed capacitor is located – reach a temperature of up to about 50°C, without taking into account the sealed enclosure that the PCB is located in.

The WiFi module that is located next to the capacitor and sticking up vertically from the PCB also reached a similar high temperature, making sure to bake the affected capacitor from below and the side. Even in open air the capacitor reached a temperature of about 43°C.

While a higher-quality capacitor will very likely cope with ripple current better, ultimately it’s pretty much just an unnecessarily stressful environment for electrolytic capacitors. While investigating two newer batches of these Plug Minis that are not subject to recall, the older unit still had the same flawed capacitor, while the new unit had replaced it with what looks like a polymer capacitor with the same ratings.

Interestingly, one of the failed plugs that [Denki Otaku] got sent did use one of these polymer capacitors, but appears to have another fault that wasn’t further investigated. Either way, the use of a polymer capacitor seems to help with the longevity to get it at least past the warranty period, but without a redesign these units seem doomed to fail due to rapid capacitor aging.

youtube.com/embed/YkI5GK734eI?…

hackaday.com/2026/02/07/a-fail…

Making a DIY Refrigerated Vest With Battery and Solar Power

Keeping a cool head is difficult at the best of times, least of all when it’s summer and merely thinking of touching bare skin to the pavement already gets you a second-degree burn. Unfortunately, it’s not possible to spend all summer in an air-conditioned room, but what if you took said room with you? Introducing [Hyperspace Pirate]’s air-conditioned vest.

Following on from last time’s adventures with a battery-powered air-conditioner that merely blew cold air onto one’s overheating body, this time the same compressor is used for a more compact build.

Since obviously using your body as part of the condenser would be uncomfortable, instead a heat exchanger was used that transfers the delicious frosty cold to water-filled tubing, zip-tied inside a very fashionable vest.

The basic unit runs on a couple of LiPo packs, but a solar-powered circuit was also built and tested using two small-ish panels. Of course, the requisite backpack-sized setup for that configuration is somewhat bulky, but at least the panels can also provide shade in addition to power for the compressor, hitting two fiery birds with one frosty stone.

Compared to one of those solar-powered caps with a built-in fan, this unit with some refinement could actually be an improvement, as well as keeping you a lot chillier. We’re looking forward to [Hyperspace]’s trial runs in the upcoming Floridian summer, as well as future chilling adventures.

youtube.com/embed/qv0IJM3BV9Y?…

hackaday.com/2026/02/07/making…

Robots Talking to Robots

Although there are a few robots on the market that can make life a bit easier, plenty of them have closed-source software or smartphone apps required for control that may phone home and send any amount of data from the user’s LAN back to some unknown server. Many people will block off Internet access for these types of devices, if they buy them at all, but that can restrict the abilities of the robots in some situations. [Max]’s robot vacuum has this problem, but he was able to keep it offline while retaining its functionality by using an interesting approach.

Home Assistant, a popular open source home automation system, has a few options for voice commands, and can also be set up to transmit voice commands as well. This robotic vacuum can accept voice commands in lieu of commands from its proprietary smartphone app, so to bypass this [Max] set up a system of automations in Home Assistant that would command the robot over voice. His software is called jacadi and is built in Go, which uses text-to-speech to command the vacuum using a USB speaker, keeping it usable while still offline.

Integrating a voice-controlled appliance like this robotic vacuum cleaner allows things like scheduled cleanings and other commands to be sent to the vacuum even when [Max] isn’t home. There are still a few limitations though, largely that communication is only one way to the vacuum and the Home Assistant server can’t know when it’s finished or exactly when to send new commands to the device. But it’s still an excellent way to keep something like this offline without having to rewrite its control software entirely.

hackaday.com/2026/02/07/robots…

He’s a Wrapper (Wire Wrapper, That Is)

Before PCBs, wiring electronic circuits was a major challenge in electronics production. A skilled person could make beautiful wire connections between terminal strips and components with a soldering iron, but it was labor-intensive and expensive. One answer that was very popular was wire wrapping, and [Sawdust & Circuits] shows off an old-fashioned wire wrap gun in the video below.

The idea was to use a spinning tool to tightly wrap solid wire on square pins. A proper wrap was a stable alternative to soldering. It required less skill, no heat, and was easy to unwrap (using a different tool) if you changed your mind. The tech started out as wiring telephone switchboards but quickly spread.

Not all tools were guns or electric. Some used a mechanical handle, and others were like pencils — you simply rotated them by hand. You could specify levels for sockets and terminals to get a certain pin length. A three-level pin could accept three wire wrap connections on a single pin, for example. There were also automated machines that could mass-produce wire-wrapped circuits.

The wire often had thin insulation, and tools usually had a slot made to strip the insulation on the tiny wires. Some guns created a “modified wrap” that left insulation at the top one or two wraps to relieve stress on the wire as it exited the post. If you can find the right tools, wires, and sockets, this is still a viable way to make circuits.

Want to know more about wire wrapping? Ask [Bil Herd].

youtube.com/embed/TzlM8yZR5RI?…

hackaday.com/2026/02/07/hes-a-…

Why PlayStation Graphics Wobble, Flicker and Twitch

Although often tossed together into a singular ‘retro game’ aesthetic, the first game consoles that focused on 3D graphics like the Nintendo 64 and Sony PlayStation featured very distinct visuals that make these different systems easy to distinguish. Yet whereas the N64 mostly suffered from a small texture buffer, the PS’s weak graphics hardware necessitated compromises that led to the highly defining jittery and wobbly PlayStation graphics.

These weaknesses of the PlayStation and their results are explored by [LorD of Nerds] in a recent video. Make sure to toggle on subtitles if you do not speak German.

It could be argued that the PlayStation didn’t have a 3D graphics chip at all, just a video chip that could blit primitives and sprites to the framebuffer. This forced PS developers to draw 3D graphics without such niceties like a Z-buffer, putting a lot of extra work on the CPU.

This problem extends also to texture mapping, by doing affine texture mapping, as it’s called on the PS. This mapping of textures is rather flawed and leads to the constant shifting of textures as the camera’s perspective is not taken into account. Although this texture mapping can be improved, the developers of the game have to add more polygons for this, which of course reduces performance. This is the main cause of the shifting and wobbling of textures.

Another issue on the PS was a lack of mipmapping support, which means a sequence of the same texture, each with each a different resolution. This allows for high-resolution textures to be used when the camera is close, and low-resolution textures when far away. On the PS this lack of mipmapping led to many texture pixels being rendered to the same point on the display, with camera movement leading to interesting flickering effects.

When it came to rendering to the output format, the Nintendo 64 created smooth gradients between the texture pixels (texels) to make them fit on the output resolution, whereas the PS used the much more primitive nearest neighbor interpolation that made especially edges of objects look like they both shimmered and changed shape and color.

The PS also lacked a dedicated floating point unit to handle graphics calculations, forcing a special Geometry Transformation Engine (GTE) in the CPU to handle transformation calculations, but all in integer calculations instead of with floating point values. This made e.g. fixed camera angles as in Resident Evil games very attractive for developers as movement would inevitably lead to visible artefacts.

Finally, the cartridge-based games of the N64 could load data from the mask ROMs about 100x faster than from the PS’s CDs, and with much lower latency. All of these differences would lead to entirely different games for both game consoles, with the N64 being clearly superior for 3D games, yet the PS being released long before the N64 for a competitive price along with the backing of Sony would make sure that it became a commercial success.

youtube.com/embed/0psAfIFPtVI?…

hackaday.com/2026/02/06/why-pl…