zigbrew-scales: grind by weight, not by time

On the Barista Express you start a grind by pushing the portafilter into the cradle, and a second push stops it early. The relay from part one can already make that push. So the whole project comes down to this: weigh the grounds as they land, and send one more push at the right moment.

I could have used a Bluetooth coffee scale and a Home Assistant automation. But then every reading has to go through a Bluetooth proxy, Home Assistant, Zigbee2MQTT and the relay. That takes a third to two thirds of a second, and never the same amount twice. At 1.6 g a second, that wobble alone is most of a gram. So I built my own scale. It decides when to stop by itself, 84 times a second, and talks straight to the relay over a Zigbee binding, a direct device-to-device link with no hub in the middle. Home Assistant only sets the target and writes down the result.

The safety net is the machine's own timer. GRIND AMOUNT is turned up so the timed dose always runs a little past the heaviest target. If the scale, the network or the relay drops out, the grind still ends on the timer, a gram or two heavy. The worst case is a heavy dose, never a grinder that won't stop, because the scale only sends short presses and never holds a switch on.

The hard part was where to put a scale on a machine that holds the portafilter by its ears, on two hooks, right under the grinder outlet with no room to spare. I started with two ideas. Direction A was a cup scale shaped like a portafilter that hangs in the cradle on its own; you'd tip the cup into the real portafilter afterwards. It got as far as a fit test and a parts order. Then I wondered whether it would be crazy to weigh straight into the portafilter instead. It wasn't, and that's Direction B, the one I built.

I already use a dosing ring, which clips onto the portafilter's ears and hangs on the cradle's hooks. B is that ring, cut in two, with a load cell as the only thing joining the halves. The top half hangs on the hooks and is never weighed. The bottom half grips the portafilter exactly as the ring does today. Everything below the cut, portafilter and coffee, hangs from the cell.

First, copy the dosing ring: the portafilter's ears go up into J-slots, twist, and a springy finger holds each one. Calipers gave the sizes; they're in the CAD.

The one rule for the whole part: nothing that's weighed may touch anything that isn't. The two halves sit 2.5 mm apart everywhere. A Z-shaped labyrinth in the wall stops grounds climbing out through the gap, and nothing narrows the bore: it's tamper-sized all the way through, so I tamp through the ring like today. The load cell keeps a millimetre clear of its box all round.

The CAD refuses to render if any of that is violated. By the end there were 24 touch checks, each one an OpenSCAD intersection that has to come back empty, and a deliberate wrong placement that has to trip it, so the check is known to work. The useful ones are the assembly checks: can the load cell get into the box, can the sleeve come up from below, can the lid go on. The first draft passed every clearance check and could not be put together.

Four wires from the cell to the HX711's screw terminal, four from the HX711 to the XIAO: data, clock, 3.3 V and ground. The clock pin is D2 on purpose: it's a low-power pin the C6 can hold high through deep sleep, which powers the HX711 down on battery. A printed jig holds both boards at exactly their spacing on the carrier, so the wires come out the right length and the wired pair lifts straight across.

I found one wiring mistake in a photo before powering up: red was on the HX711's VIO pad, one along from VIN. At first power-up it read 84 times a second, so the RATE switch really was on H, and calibration came out at 1,074.8 counts per gram. With the coins left on for a minute, the reading stayed flat with no drift, but every single reading was noisy to ±0.13 g.

The dose logic is a pure C++ header the firmware and a desktop simulator share. The simulator runs it against a model grinder with a start delay, a flow rate, stop latency with jitter, spin-down, grounds in the chute, motor vibration and a GRIND AMOUNT timer, then throws scenarios at it: a thousand doses, the timer ending the dose right at the stop point, 20% of commands lost, a slow link, the cup put on and taken off, a weight dropped on an idle scale. Every scenario runs at four noise levels, the last of which is a recorded minute of the real assembled ring, replayed from a random point, because real noise has spikes and wander that Gaussian noise doesn't.

It found real bugs before any hardware existed: five in the first controller, each caught by a scenario. The nastiest was a stop press landing just after the timer had already ended the dose. On an idle grinder a press is a start, so it quietly ground a second dose, and nothing noticed. The most surprising was the Arduino Zigbee library, which silently refuses to send an On unless it made the binding, so the firmware builds the command itself.

Once assembled, the ring went into the real cradle with the portafilter clipped on, still powered from the laptop's USB. First the boring checks, which all passed: the sleeve hangs free (every poke comes back to the same reading), re-clipping the portafilter repeats to 0.2 g, the calibration from the bench holds (two £1 coins read 17.49 g of 17.50), and noise is the same ±0.13 g as the bare cell. The portafilter weighs 492.5 g. Then I bound the trigger endpoint to zigbrew_grind in Zigbee2MQTT and ran an actual grind to see what would happen.

The first try pressed once, saw nothing for four seconds and gave up: the machine was off, and the relay can't start a grinder in standby. One press, no second, exactly as designed. Machine on, armed for 18.0 g with a guessed lead of 1.0 g:

2.99 s is too close to 3 s to be chance. The scale asks the relay to confirm each command, and if no confirmation comes back within 3 s, it sends the command again. The relay had obeyed the stop, but its confirmation got lost. So the scale sent the stop again three seconds later, and on this relay every On is a press, so the repeat started the grinder. (That 3 s is in the ZBOSS library under the Arduino core's Zigbee stack, if you want to look.) The relay should have spotted the repeat by its counter and ignored it. Why its duplicate table missed it I still don't know; a sniffer would tell. It doesn't matter for the fix: a press that is never resent can't be duplicated.

The second grind, with the ring emptied, was clean: two presses, two pulses, and it repeated the first one almost exactly. First grounds at 0.89 s, 1.62 g/s, stop press at 16.99 g, settled at 17.34. So 0.35 g arrives after the stop press, not the 1.0 g I'd guessed for the lead. The scale learned 30% of the error on its own (1.00 → 0.80), and I set it to 0.35 from the console to save a few doses. I called it there: enough wasted coffee, for now.

Part one's morning ends in one script that presses POWER, waits, and presses GRIND, each once a day. Only the GRIND press changed. If grind-by-weight is switched on and the scale has been heard from recently, the script arms the scale instead of pressing, waits for the scale's own start press to show up on the relay, and records the dose. If the scale is silent, it does the old timed press, so a dead scale still makes coffee. And if the scale was armed but no start press ever appears, the script notifies and stops. It never presses on the scale's behalf: fail to no coffee, never to a double press.

So that Sunday I ran the script by hand, with the scale on a USB wall plug and the 0.35 g lead:

Home Assistant also keeps a Coffee scale dashboard. Every dose shows up there with how many presses it took. Two is normal. One is "no grounds". Three or more is a rescue, and the logbook says why.

The bench build was a Zigbee router, a device that stays awake and passes messages on for others, drawing 30 to 80 mA. On a 250 mAh cell that's an afternoon. So on battery the ring is an end device, one that's allowed to sleep, and it deep-sleeps and checks in: every two minutes it wakes, rejoins the network from what it saved in flash, reports every reading and every setting, listens for a couple of seconds, and sleeps. Home Assistant can't write to a sleeping scale, so it keeps the wanted values and sends whatever differs while the scale is awake. If a grind is wanted, the check-in automation arms it. One dose per wake; a late or repeated arm is ignored.

The catch is that a grind can start up to two minutes after it's asked for.

It worked first time next to the laptop upstairs, rejoining in 0.3 s. Downstairs in the cradle it went quiet. With the laptop on the kitchen counter, I found two things wrong:

• A loop in the Zigbee library. When a join times out, the Arduino core helpfully resets the saved channel list to all sixteen channels. The next 8 s join can't finish a full scan, times out, resets again, forever. One slow rejoin after the move was enough to start it. Fix: pin channel 24 before every join, and give a join after a failure 20 s instead of 8.
• A steady 5.5 s rejoin from the cradle, against 0.3 s upstairs. The stack picks the best-heard router whose beacon says it takes end devices, sends it a rejoin request, and waits five seconds for an answer before trying the next. Something near the machine was advertising room for children and never answering. I guessed the two relays inside the machine. I was wrong.

With no sniffer to hand, I made the firmware log what each rejoin hears. If the router it tried first never answers, the scale ignores that router from then on.

Battery life is still an estimate, because the current hasn't been measured. At an assumed 80 mA awake, 2.5 s every two minutes is about 37 mAh a day, which is a week on this cell; every five minutes would be two. Battery level needs two resistors from BAT to a spare pin that aren't there yet, so for now it charges on a schedule, not on a number.

The whole project on one page, numbers as measured.