Whether you’re making coffee or beer or complex chemicals, weighing your ingredients carefully and tracking them is key to getting good results. [Tech Dregs] decided to build a logging scale that would work seamlessly with his smartphone, and shared the design on YouTube.
The design begins with a Greater Goods manual electronic scale, which was chosen for its convenient design and 750 gram load cell. Once cracked open, [Tech Dregs] pulled out the original PCB to replace it with his own. Only the original buttons are used, with an Seed Xiao ESP32-C3 replacing the scale’s original brains. The original LCD screen was swapped out for an OLED display, and it also got a rechargeable lithium battery for better usability.
The real value of the project, though, is its communication capability. It’s able to talk to an Android smartphone over Bluetooth Low Energy. Thanks to a custom app, [Tech Dregs] is able to log weight readings from the scale over time and even graph them live on the smartphone. As a demonstration, the scale is used to log the weight of a cup as it fills with a shot of coffee, which should serve [Tech Dregs] well in his coffee automation projects.
It’s getting harder and harder to think of a modern premium-level appliance that doesn’t come with some level of Internet connectivity. These days it seems all but the cheapest refrigerators, air purifiers, and microwaves include wireless capabilities — unfortunately they’re often poorly implemented or behind a proprietary system. [Matt] recently purchased a high-end coffee maker with Bluetooth functionality which turned out to be nearly useless, and set to work reverse-engineering his coffee maker and adapting it to work by sending commands from GitHub.
Since the wireless connectivity and app for this coffee maker was so buggy and unreliable, [Matt] first needed to get deep into the weeds on Bluetooth Low Energy (BTLE). After sniffing traffic and identifying the coffee maker, he set about building an interface for it in Rust. Once he is able to send commands to it, the next step was to integrate it with GitHub, so that filing issues on the GitHub interface sends the commands from a nearby computer over Bluetooth to the coffee maker, with much more reliability than the coffee maker came with originally.
Using [Matt]’s methods, anyone stuck with one of these coffee makers, a Delonghi Dinamica Plus, should be able to reactivate the use of its wireless functionality. While we’d hope that anyone selling a premium product like this would take a tiny amount of time and make sure that the extra features actually work, this low bar seems to be oddly common for companies to surmount. But it’s not required to pick up an expensive machine like this just to remotely brew a cup of coffee. You can do that pretty easily with a non-luxury coffee maker and some basic wireless hardware.
Safe, clean drinking water is a scarce resource that shouldn’t be wasted. But it’s not always easy to see how much you’re using when you turn on the tap: is it one liter a minute? Is it ten? How much do you actually use when washing your hands or brushing your teeth? If you’d like to get some hard data on your water usage, have a look at [Josh EJ]’s Sensible Flow project. It contains designs for a set of sensors that measure your water consumption and a convenient little display that shows the total amount consumed.
The most obvious way of measuring water consumption is to install an off-the-shelf flow meter onto your pipe, which is something that Sensible Flow supports. But probably the most interesting part of the project is a design for a non-invasive flow sensor that you can simply attach to any type of tap. This sensor contains a nine-axis inertial measurement unit (IMU) that detects how far you’ve twisted, turned or tilted the handle, and uses that information to estimate the amount of water flow. You will need to perform an initial calibration step using a timer and measuring cup, but you won’t have to rip open your plumbing just to keep track of your water usage.
Both types of sensors are powered by a coin cell battery that is estimated to work for about one year, thanks to a power-efficient Arduino Pro Mini and a BlueTooth Low Energy (BLE) module to communicate with the base station. The base station plugs into a wall socket and shows the total water consumption on a small one-inch OLED display. STL files for the enclosures are available on the project page, along with detailed circuit diagrams that show how all the parts are connected.
When a company creates an infrastructure of devices, we sometimes subvert this infrastructure and use it to solve tricky problems. For example, here’s a question that many a hacker has pondered – how do you detect when someone puts mail into your mailbox? Depending on the availability of power and wireless/wired connectivity options, this problem can range from “very easy” to “impractical to solve”. [dakhnod] just made this problem trivial for the vast majority of hackers, with the FakeTag project – piggybacking off the Apple’s AirTag infrastructure.
This project uses a cheap generic CR2032-powered NRF51822 board, sending the mailbox status over the FindMy system Apple has built for the AirTag devices. For the incoming mail detection, he uses a simple vibration sensor, glued to the flap lid – we imagine that, for flap-less mailboxes, an optical sensor or a different kind of mechanical sensor could be used instead. Every time someone with a FindMy-friendly iPhone passes by [dakhnod]’s mailbox, he gets an update on its status, with a counter of times the sensor has been triggered. [dakhnod] estimates that the device could run for up to a year on a single battery.
The team from the Sensing, Interaction & Perception Lab at ETH Zürich, Switzerland have come up with TapType, an interesting text input method that relies purely on a pair of wrist-worn devices, that sense acceleration values when the wearer types on any old surface. By feeding the acceleration values from a pair of sensors on each wrist into a Bayesian inference classification type neural network which in turn feeds a traditional probabilistic language model (predictive text, to you and I) the resulting text can be input at up to 19 WPM with 0.6% average error. Expert TapTypers report speeds of up to 25 WPM, which could be quite usable.
Details are a little scarce (it is a research project, after all) but the actual hardware seems simple enough, based around the Dialog DA14695 which is a nice Cortex M33 based Bluetooth Low Energy SoC. This is an interesting device in its own right, containing a “sensor node controller” block, that is capable of handling sensor devices connected to its interfaces, independant from the main CPU. The sensor device used is the Bosch BMA456 3-axis accelerometer, which is notable for its low power consumption of a mere 150 μA.
The wristband units themselves appear to be a combination of a main PCB hosting the BLE chip and supporting circuit, connected to a flex PCB with a pair of the accelerometer devices at each end. The assembly was then slipped into a flexible wristband, likely constructed from 3D printed TPU, but we’re just guessing really, as the progression from the first embedded platform to the wearable prototype is unclear.
What is clear is that the wristband itself is just a dumb data-streaming device, and all the clever processing is performed on the connected device. Training of the system (and subsequent selection of the most accurate classifier architecture) was performed by recording volunteers “typing” on an A3 sized keyboard image, with finger movements tracked with a motion tracking camera, whilst recording the acceleration data streams from both wrists. There are a few more details in the published paper for those interested in digging into this research a little deeper.
You’ve probably heard of the infamous rule 34, but we’d like to propose a new rule — call it rule 35: Anything that can be used for nefarious purposes will be, even if you can’t think of how at the moment. Case in point: apparently there has been an uptick in people using AirTags to do bad things. People have used them to stalk people or to tag cars so they can be found later and stolen. According to [Fabian Bräunlein], Apple’s responses to this don’t consider cases where clones or modified AirTags are in play. To prove the point, he built a clone that bypasses the current protection features and used it to track a willing experimental subject for 5 days with no notifications.
According to the post, Apple says that AirTags have serial numbers and beep when they have not been around their host Apple device for a certain period. [Fabian] points out that clone tags don’t have serial numbers and may also not have speakers. There is apparently a thriving market, too, for genuine tags that have been modified to remove their speakers. [Fabian’s] clone uses an ESP32 with no speaker and no serial number.
The other protection, according to Apple, is that if they note an AirTag moving with you over some period of time without the owner, you get a notification. In other words, if your iPhone sees your own tag repeatedly, that’s fine. It also doesn’t mind seeing someone else’s tags if they are near you. But if your phone sees a tag many times and the owner isn’t around, you get a notification. That way, you can help identify random tags, but you’ll know if someone is trying to track you. [Fabian] gets around that by cycling between 2,000 pre-loaded public keys so that the tracked person’s device doesn’t realize that it is seeing the same tag over and over. Even Apple’s Android app that scans for trackers is vulnerable to this strategy.
Even for folks who aren’t particularly privacy minded, it’s pretty clear a worldwide network of mass-market devices that allow almost anyone to be tracked is a problem. But what’s the solution? Even the better strategies employed by AirGuard won’t catch everything, as [Fabian] explains.
With everything being “connected” these days smartphone applications are of course a ubiquitous part of our existence. We’ve seen plenty of examples connecting your Bluetooth-enabled projects to an Android device, but comparatively fewer tutorials for connecting to iOS devices. This mostly has to do with Android’s much larger market share and also Android’s more open-source friendly business model. Nevertheless, if you do much IoT development either as a hobby or professionally, then you probably find yourself interacting with Apple devices more than you like to admit.
[Akio’s] app is essentially updating a chart, in real-time, with data read from an Adafruit nRF52832 Feather board. He then walks you through all the basics of creating a user interface (UI) using Apple’s Storyboard interface, a simple drag-and-drop scheme similar to something you’ve probably used in many other contexts. [Akio] shows readers how to add buttons for allowing users to interact with the app, labels for displaying data to the user, as well as walks you through Apple’s odd methodology of connecting UI elements to code using IBAction and IBOutlets. The highlight of his tutorial is showing readers how to add charts to their iOS apps which seems to take a few more steps than you might imagine.
[Akio] does a really good job detailing all the relevant functions so that readers will hopefully understand what each piece of the code is doing. And we really enjoyed him adding individual video tutorials for some of the trickier programming steps. He also readily admits that some folks may opt to develop their UI exclusively in code as opposed to the Storyboard but he argues that the Storyboard is still important for beginners and is really handy when the UI is fairly simple.