BrewTrak Update: A Lot Has Changed

It has been a few months since the last BrewTrak update, and I honestly did not realise how much had changed until I sat down and looked back through the repository.

There have been more than 200 commits since May. That probably explains where quite a few of my evenings went.

Back in May, BrewTrak was starting to feel like one connected system. Recipes flowed into batches, batches carried the production record, and fermentation, packaging, inventory, and the taplist were beginning to join up.

Since then, I have been less interested in adding another big feature and more interested in whether I can actually trust what is already there.

Can I use it on brew day without fighting the screen? Does it know the difference between a device that is configured and one that is actually online? Can it show me why it calculated a number? If I lose the database, can I restore it? If something goes offline, does BrewTrak fail safely?

Those questions have shaped most of the recent work.

Using it like I would actually brew

BrewTrak can now run a batch without a controller attached. I still get the timers, prompts, measurements, notes, and brew-day record, but it does not pretend it can control anything.

That sounds obvious, but software has a habit of showing a green light because something was configured once. I do not want BrewTrak doing that around heating elements and pumps.

The RAPT BrewZilla integration has come a long way as well. A BrewZilla can be the control path without needing a second BrewTrak controller. Manual control and automatic mash control are kept separate, and BrewTrak checks that the connection and telemetry are current before allowing an on command. The off commands stay available because being able to turn something off is a different problem from proving it is safe to turn on.

I have also turned the Water Test into a proper commissioning run. I wanted a way to learn what my system actually does without putting a batch of beer at risk.

It can now record probe comparisons, heat-up performance, recirculation spread, vessel volume checks, and a stable boil. There are also separate checks for boil-off, kettle retention, transfer loss, and mash-tun deadspace.

If one of those measurements is useful, BrewTrak can offer it back to the equipment profile. It does not quietly update the profile in the background. I have to review it and decide whether it represents the way I normally run the system.

That part is important because none of this has been physically proven yet. The workflow is there, but I still need to put water in the brewery, use a reference thermometer, run the pumps, test the normal plumbing path, and see whether the results make sense.

I wanted the calculations to show their working

I have spent a lot of time on the recipe calculations too.

BrewTrak used to show OG, FG, ABV, IBU, colour, mash pH, and a few ratios as neat numbers at the top of the recipe. The problem was that a neat number can look much more certain than it really is.

Those values can now open a calculation receipt. It shows the formula, the inputs BrewTrak used, where those inputs came from, and what is missing or assumed.

It is probably more detail than most people want every time they open a recipe, which is why it stays tucked away. But it is exactly the sort of detail I want when a result looks wrong.

Mash temperature and time now have an effect on the predicted FG, including recipes with multiple rests. I am not treating that prediction as gospel. It is a planning guide, and I need real batches before I will know how useful the model is for my brewery.

The water-planning screen has had a similar cleanup. The normal view now walks through source water, volumes, the target profile, adjustments, and brew-day checks. The big worksheet is still there as an advanced view when I want to dig into everything.

I also added proper recipe cloning. A cloned recipe gets its own ingredients, water plan, mash schedule, equipment choices, and fermentation steps. It does not remain tangled up with the source recipe’s batches and history.

The hardware project keeps growing too

The scale node started as a fairly simple idea and, as usual, became its own project.

BrewTrak now has a clearer setup flow for scale nodes, a transfer-scale workflow, and pour tracking based on changes in keg weight. I have also been working on the enclosures, including a larger transfer scale with its own display.

The ESP32-S3 and HERMS controller have had another substantial round of work covering the heater logic, outputs, networking, configuration, state changes, and the API back to Core.

The firmware is getting much closer, but compiling is not commissioning. I still need to test the controller, probes, relays, interlocks, and plumbing together. That is where the interesting problems usually appear.

The boring work was starting to matter

Some of the most important changes are not very photogenic.

The batch and recipe pages were starting to pull too much data at once. They now load smaller summaries first, fetch the detail when it is needed, and bring in recent events and telemetry without holding up the whole page.

I also found some memory and recovery problems around backups and RAPT synchronisation. Backups now run in their own limited worker instead of competing with the main BrewTrak application, and the telemetry sync has had a fairly serious reliability pass.

It is not the fun part of building BrewTrak, but it is the difference between something that works for a demonstration and something I can leave running.

And yes, I changed the interface again

As BrewTrak gained more capability, the interface started to feel busy. Too many panels were competing for attention, even when only one of them mattered for the job in front of me.

I started a UI v2 pass with the recipe ingredients screen and liked the direction enough to carry it into the recipe library, dashboard, batches, inventory, and ingredient catalogue.

The goal is not to remove information. It is to make the next action obvious and let the supporting detail stay quieter until I need it.

The current fermentation workspace. Active work stays at the front, while completed batch records are still easy to get back to.

I am working through fermentation and packaging now. Reports, the taplist, settings, and the hardware screens still need the same treatment.

What is next

BrewTrak feels much closer to the thing I originally wanted to build, but there is still a gap between implemented and proven.

The next useful step is not another impressive-looking feature. It is finishing the interface work, running the water commissioning properly, testing the HERMS controller and scales on the real hardware, and comparing BrewTrak’s predictions with what actually happens in a batch.

I have built enough of the system now. It is time to make it earn some trust.