Search | Half Built HQ

BrewTrak Update: A Lot Has ChangedIt has been a few months since the last BrewTrak update. I did not realise quite how much had changed until I sat down and looked back through it.UpdateBrewTrak Brewing software Brewery automationIt 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.

BrewTrak Update: From Brew Day Tool to Brewery PlatformSince the last update, BrewTrak has kept growing from a brew day controller and fermentation tracker into something much broader. The clearest change is that the system now has a stronger shape around how a brewery…UpdateSince the last update, BrewTrak has kept growing from a brew day controller and fermentation tracker into something much broader. The clearest change is that the system now has a stronger shape around how a brewery actually works. Recipes define what I’m trying to make. Batches become the production record. Brew sessions handle the live brewhouse run. Finished inventory then carries the beer through packaging, serving, and taplist workflows. That might sound obvious, but getting those pieces to behave and link together has been a big step forward. A lot of the recent work has gone into strengthening recipes and batches, adding styles and ensuring user experience matches the purpose of the actions. Recipes now support audit history, revision checkpoints, BeerXML import, recipe logos, mash profile selection, mash-step snapshots, and checks against available inventory. Mash profiles can also be copied into a recipe and adjusted there without changing the default profile, which makes it much safer to fine-tune a process for a specific recipe. Batches have grown even more. They now carry the real production story: identity, lifecycle state, recipe snapshots, fermentation setup, QA and release notes, brewhouse measurements, and packaged inventory. Fermentation now belongs properly to the batch rather than being treated as part of the live brew session, which makes much more sense once the wort has left the brewhouse. That area now supports charting, samples, process steps, held-wort handling, and RAPT integration work. Inventory has also become more practical. BrewTrak now separates ingredients from finished beer, supports stock movements and transfers. I’ve added imports from Brewfather inventory and batches to bring historic context for the “intelligence” layer, and can connect recipe planning back to what is actually on hand in terms of ingredients. I have implemented the filter for what I can brew with ingredients in stock, as well as what likely substitutes are from other stock on hand. Packaging and serving are starting to take shape too. There is now support for wort kit batches (brewing from a kit), soft drink batches, finished beer inventory views, taplist setup, and a more display-ready tap board ready for keg volume tracking. Reporting has also started to come together, with date filters and batch volume reporting now in place. That gives BrewTrak a clearer path toward production dashboards, review tools, and eventually costing. So, in short, BrewTrak is now well beyond basic brew day logging. It is becoming a connected brewery platform for recipe design, batch execution, fermentation tracking, inventory, packaging, taplist display, and production reporting. Current Focus The next stage is refinement. I’m working on making ingredient identity smarter for real brewery use, especially hops, where harvest year and alpha acid percentage matter. I’m also continuing to harden the import flows and polish the production workflows so BrewTrak feels fast, reliable, and natural to use during actual brewing. The biggest shift is that BrewTrak is starting to feel less like a collection of useful brewing tools and more like one connected system. There is still plenty to tighten, but the shape of it is becoming much clearer. More soon.

BrewTrak Update: Practical Water Chemistry for Real BrewingI have cared about brewing water since I first moved into all-grain. Meaningful water adjustment has always made sense to me because it is one of those quiet process changes that can make a real difference in the…UpdateI have cared about brewing water since I first moved into all-grain. Meaningful water adjustment has always made sense to me because it is one of those quiet process changes that can make a real difference in the finished beer. That carried through into my professional brewing work as well, where water treatment was something I kept coming back to as part of recipe and process development. So when I started adding water chemistry into BrewTrak, I knew I did not want it to just be another “match these numbers” tool. The goal is not just to let a brewer enter a target profile and throw salts at it until the numbers line up. That can be useful, but it can also miss the bigger picture. Brewing water is not just about matching ppm targets. It is about mash performance, balance, and the final beer. For BrewTrak, that means the first priority is mash pH. Once that is in the right zone, the focus shifts to flavour, mouthfeel, and whether the recommended changes actually make sense for the beer being brewed. Recipes can now store the full water plan, including the starting water, target profile, dilution, mash pH target and estimate, sparge acidification target, and brewer notes. The actual salts and acids are stored separately, so the recipe can keep the planning side clear while still turning that plan into practical brew day additions. That separation matters because it keeps the intent and the execution connected without mixing them together. The brewer can see the target, the reasoning behind it, and the expected effect before deciding what to apply. A lot has gone into making this useful in normal brewing conditions. BrewTrak now supports reusable source and target water profiles, source water ion balance checks, residual alkalinity calculations, and style-aware target recommendations for hop-forward beers, malt-driven beers, lagers, dark beers, and balanced profiles. The pH estimation work now takes into account the grist, source alkalinity, mineral additions, acid additions, and mash-profile acid rests. Residual alkalinity and flavour diagnostics are also shown directly in the recipe editor, so the brewer can see how the water plan is shaping the beer rather than just staring at a table of numbers. Salt calculations can be handled automatically, similar to other brewing water tools, but BrewTrak does not force the brewer to accept them blindly. The brewer stays in control of what is actually applied. Before committing changes to the batch, they can review the effect on residual alkalinity, estimated mash pH, and other flavour-related metrics, then adjust the additions if needed. One of the more important parts of this work is adding guardrails around aggressive sulfate recommendations. It is easy to look at a famous brewing region, copy the numbers, and assume that matching the profile is the goal. Highly mineralised profiles can make sense in the right context, especially for certain hop-forward beers, but they are not automatically better just because they are historically significant. Some Burton-upon-Trent-style profiles can sit in the range of 700–800 ppm sulfate, and chasing those numbers blindly is unlikely to produce a balanced, well-seasoned beer. I think of it a bit like seasoning food. If you order a steak at a good restaurant, it is probably already seasoned with intent. If you blindly add more salt before tasting it, the salt stops enhancing the meal and starts becoming the main thing you notice. Brewing water can work the same way. Minerals should support the beer, not dominate it. In a lot of cases, the same broad flavour direction can be reached without making extreme water changes purely for the sake of matching a regional profile. BrewTrak is being built to favour practical, balanced recommendations over blind target chasing. The workflow now supports the brewer from the starting point through to the actual brew day decision: what water do I have, what kind of profile suits this beer, what needs to change for mash pH, what additions support the flavour goal, and what do I actually add? That is the direction I want for water chemistry in BrewTrak: a practical tool that helps brewers apply brewing water science without making the process feel harder than it needs to be. It should make water chemistry clearer, more usable, and more focused on the beer at the end of it.

BrewTrak Update: Sharpening the Software, Wiring the Panel, and Learning From Brew DayBrewTrak has taken a solid step forward. It is now live-tracking the fermentation of a batch of Lamington Porter, and it was also used to track the BrewZilla telemetry on brew day. This recent stretch of work was all…UpdateBrewTrak has taken a solid step forward. It is now live-tracking the fermentation of a batch of Lamington Porter , and it was also used to track the BrewZilla telemetry on brew day. This recent stretch of work was all about getting the system closer to real brewery use. In the lead-up to brew day, the focus was on tightening up the live brewing experience, improving fermentation data handling, including ingesting some data from the RAPT API, and making sure the advisory AI behaves more like a disciplined brewing assistant than a confident guess machine. At the same time, progress has continued on the physical side too. One of the big milestones in this phase is that the high-voltage side of the BrewTrak wiring has now been completed . That is a meaningful step toward full panel bring-up and live control integration, and it helps close the gap between the software model and the hardware it is ultimately meant to run. That milestone means I can now wire up the low-voltage side safely, plug the signal wires into the ESP32 board, and then keep pushing ahead on the firmware. Once that is done, we are ready to test it with a water brew. A More Practical Brew Day Shape One of the biggest software shifts has been in how BrewTrak thinks about the brew day itself. Rather than centring the experience around abstract session concepts, the system has been pushed further toward a batch-first workflow . In practice, that means the batch is becoming the main place where brewing work happens. That sounds like it should have been obvious, but in the overall architecture it can sometimes get lost because of how the system interacts internally. On brew day, the user does not think in terms of software objects. They think about the batch in front of them, what stage it is in, what needs to happen next, and what the process is telling them. That has now been made much clearer, and real-world use confirmed that the batch record flow is more natural than a separate brew-session-driven interface. Brewhouse telemetry showing mash steps, pre-boil ramp/hold for sparge and boil It also highlighted that the live brewing area still needs to become easier to scan, less crowded, and more immediate in how it presents controls and information. The path forward there is now more obvious: key stage controls need to sit directly in the main brewhouse workspace, and the interface needs to feel faster and calmer under real conditions. While it is not the primary focus right now, it definitely needs to happen before I use it solely to manage a brew day. Brew Day Feedback Actually Matters! The first live use of BrewTrak as a secondary source of info was valuable for the right reason: it exposed the difference between what looks fine in development and what actually works when you are brewing. Some of the lessons were straightforward. Layout matters more than expected. Dense screens feel much heavier once they are in front of someone actively working. Charts looked larger than they needed to on laptop-sized screens. Actions that should feel instant still had too much friction. Mobile use also stood out as a genuine requirement, not a nice extra. If BrewTrak is going to be useful in real brewery conditions, it has to behave properly on a phone. That means modals must always scroll, drawers must dismiss cleanly, and quick actions like checking status, acknowledging something, or logging an event must work without friction. Those are not cosmetic concerns. They are part of what makes software usable when hands are busy and attention is already split across a live process. Better Fermentation Data, Better Decisions A big part of this work also went into making fermentation data more trustworthy. Support for RAPT telemetry has been improved so the platform can now handle raw gravity values and calibrated gravity values separately , rather than flattening them into a single view of the world. The start of fermentation telemetry coming from the RAPT Pill Brew day and the work immediately after it also exposed an important issue: some fermentation views and forecasts were being influenced by pre-fermentation telemetry. In other words, the system was sometimes letting “before the real start” bleed into “what is happening now”. That can distort charts, confuse pitch timing, and produce misleading forecast logic. That behaviour has now been tightened up so fermentation views and forecast logic are driven by the actual fermentation window rather than stray pre-start data. It is one of those changes that may sound small and obvious from the outside, but sometimes you do not see the issue until it is there. This round of work helped correct that and make the fermentation side of BrewTrak feel much more grounded. AI, but on a Short Leash The AI side has also continued to evolve, but with the same principle that has guided it from the start: AI should stay advisory only (at least for now). That principle has become even clearer after brew day. The useful version of AI in a brewing system is not a magical expert voice pretending to know everything. It is a conservative assistant that works from the data packet in front of it, stays close to evidence, and is honest about uncertainty. That means no false certainty, no invented causality, and no pretending to know sensory outcomes that the system cannot possibly measure. The AI review work is now moving in a better direction: looking at telemetry, process execution, recipe intent versus actual results, likely outcome, and practical ideas for iteration. That is much more valuable than generic commentary. It makes the AI layer feel less like a novelty and more like a structured second opinion. Over time, those reviews will also help build recipe-level intelligence from completed batches, which is where BrewTrak starts becoming more than a live process tool and more of a brewing knowledge system. What This Phase Really Proved More than anything, this stretch of work was useful because it clarified the true state of BrewTrak and what I can take away and learn from over the next week in preparation for the next brew day. I’ll have a video of the Lamington Porter up on the channel soon, so make sure you check it out. Cheers!

From Foundations to Forecast IntelligenceSince mid-February, BrewTrak has been progressing in a way that probably looks quieter from the outside than it has felt behind the scenes. There still is not a live working prototype yet, and that has been deliberate.…UpdateSince mid-February, BrewTrak has been progressing in a way that probably looks quieter from the outside than it has felt behind the scenes. There still is not a live working prototype yet, and that has been deliberate. Rather than rushing to first power-up, I have been focusing on getting the foundations right so the project has a stronger base when the hardware starts coming together. A lot of the recent work has been about structure. Device identity is now much more defined, with controllers declaring what they are and what role they are meant to perform when they are claimed. That is an important step because BrewTrak is being built as a modular system, not just a one-off controller with a fixed layout. Provisioning and discovery have also been tightened up so devices can be found and brought online more reliably. It is the kind of work that sits in the background, but it makes a big difference to how stable the system feels once real hardware enters the picture. The firmware has been maturing in parallel as well. What was once still fairly experimental is now taking on a much more structured shape, with clearer build configuration, storage behaviour, and debugging layers. It is still early, but it is starting to feel like a real platform rather than a loose test bed. At the same time, one of the bigger ideas in the project has started to become much clearer: Forecast Intelligence . Originally, it would have been easy to think about BrewTrak in terms of simple stage updates, things like knowing when a batch is ready for cold crash, or packaging. Those updates are still useful, but they only tell part of the story. What has become more interesting is the idea of trajectory. Rather than only reacting when one value crosses a threshold, I want BrewTrak to understand how a batch is progressing, whether it is tracking as expected, whether it is ahead or behind the usual curve, and what that means for the next likely process window. That is the thinking behind Forecast Intelligence. The goal is not just to say that a beer has reached a point where something can happen. The goal is to build a system that can interpret what is happening, forecast where things are heading, and give a clearer picture of timing, confidence, and risk. That leads to much more useful questions. Is the batch progressing normally? Is it behind expectation? When is terminal gravity likely to be reached? Does the current profile suggest more patience is needed before the next step? That feels much closer to the kind of tool I want BrewTrak to become. Not a system that simply pushes cold updates, but one that helps support better decisions. A lot of the recent backend work has been moving in support of that idea. Forecasts, event timing, snapshots, comparisons, scorecards, and similar-batch summaries are all starting to contribute to something that is less about one-off notifications and more about understanding batch behaviour over time. The important thing is that I do not want BrewTrak to become a black box. The goal is not to replace process logic with vague intelligence. It is to build something that can compare forecasting approaches, learn from outcomes, and surface something genuinely useful without taking control away from the brewer. That is why this phase has mattered, even if it has not produced the most obvious visual milestones. The next shift will come when that groundwork starts meeting physical hardware more directly. Wiring is getting closer, GPIO mapping will need to be validated against real inputs, and the state machine and heating logic will start moving toward live testing. BrewTrak still has a long way to go, but the direction feels much clearer now. The work since mid-February has not just been about adding pieces. It has been about shaping what kind of system this is actually going to be. And more and more, it is starting to look like a system built not just to monitor brewing, but to understand it.

BrewTrak Update February 13, 2026Laying the Groundwork Recent work has focused on strengthening the foundations before wiring and first power up. BrewTrak is not a working prototype yet, but it is moving deliberately toward one. Board Profiles Defined…UpdateLaying the Groundwork Recent work has focused on strengthening the foundations before wiring and first power up. BrewTrak is not a working prototype yet, but it is moving deliberately toward one. Board Profiles Defined Board profiles can now be exported from BrewTrak Core as TXT and PDF files. Pin mapping and harness labelling are now system defined rather than informal. This locks in the hardware contract before anything is powered. Device Claiming Structured Controllers must now declare their identity and use case when claimed, with that role stored in the database. This prevents loose device behaviour and prepares the system for future modular expansion. Discovery Hardened mDNS handling, IPv4 resolution, static IP fallback support, and Docker networking have all been tightened to improve provisioning reliability. Firmware Maturing The firmware has moved into a structured ESP IDF project with defined build configuration, partitions, persistent storage, and organised debug layers. It is not complete, but it is no longer experimental. Next Steps Panel wiring begins. GPIO mapping will be validated against physical inputs. The control state machine will be tested under real conditions. Heating logic will move closer to live validation.

Introducing BrewTrak CoreBrewTrak Core is the foundation of a brewing system I’m building to track, control, and understand the entire brewing process. It is early-stage, actively evolving, and being built alongside the first piece of BrewTrak…BrewingBrewTrak Core is the foundation of a brewing system I’m building to track, control, and understand the entire brewing process. It is early-stage, actively evolving, and being built alongside the first piece of BrewTrak hardware: a minimal brewhouse control module intended to run and validate the system in the real world. This is not a product launch. It’s a working project, built step by step. Why BrewTrak Exists Modern brewing tools tend to specialise in one area: recipes, fermentation, control, or logging. Once you try to connect those pieces, the cracks start to show. BrewTrak exists to explore a different approach. Instead of separate tools stitched together after the fact, BrewTrak is designed as a single system where software, hardware, and data models evolve together. What BrewTrak Core Is BrewTrak Core is the central operating layer. It provides the structure that everything else builds on, including: Brewery and equipment configuration Batch and process state management Sensor and control data handling Local data storage and querying Core does not try to do everything itself. It defines how the system behaves, how data moves, and how decisions are made. Hardware, Built Alongside the Software BrewTrak is not software-first or hardware-first. The first BrewTrak hardware module is a minimal brewhouse control layer designed to validate the Core architecture under real brewing conditions. It focuses on: basic process control reliable sensor input predictable behaviour over features This hardware is intentionally simple. Its job is to prove the foundations before complexity is added. Beyond Control and Logging While control and monitoring are important, BrewTrak is being designed as a broader brewing system. Core work already includes foundations for: Recipe storage and search Water profiles and chemistry tracking Inventory and ingredient management Batch history and cross-batch comparison These systems are being built as part of the same data model, not bolted on later. Local First, Modular by Design BrewTrak is designed to run locally, continue operating without internet access, and keep full control of data close to the brewery. Both hardware and software are modular. Individual components can evolve independently, while still fitting into a consistent system structure. Where It Is Right Now BrewTrak Core and the first brewhouse control module are being developed in parallel. Some parts exist only as scaffolding. Others are already functional and quietly doing their job. Many decisions are still open. That uncertainty is part of the process. It allows the real problems to surface before solutions are locked in. What Comes Next Future updates will focus on specific parts of the system as they take shape, including: Core architecture decisions Hardware design and wiring Recipe, water, and inventory modelling Lessons learned from testing and failure Progress will be uneven. Everything will be documented.

Welcome to Half Built HQHalf Built HQ is a working record of projects in motion. Brewing systems, building work, and practical technology are developed over time and documented not just for the final result, but for the process that gets…UpdateHalf Built HQ is a working record of projects in motion. Brewing systems, building work, and practical technology are developed over time and documented not just for the final result, but for the process that gets there. The videos are the entry point. They show what’s being built, tested, broken, and improved. The articles are where the detail lives. Measurements, decisions, design trade-offs, data, mistakes, and the reasoning behind what you’re seeing on screen. Some projects are small. Some span months or years. Many evolve as new constraints appear or better ideas replace old ones. Nothing here is presented as finished or definitive. Everything is documented as it exists at that moment in time. Brewing is a core focus. Recipes, fermentation tracking, system design, and repeatability matter. Over time, this site will expand to include a dedicated Recipes section that pulls directly from BrewTrak. Batches, process data, and outcomes will be linked so recipes are tied to real results, not just ingredients on a page. Building and infrastructure projects follow the same philosophy. Materials, layout decisions, energy efficiency, automation, and long-term performance are prioritised over quick wins or cosmetic results. Technology ties it all together. Monitoring, data capture, control systems, and software are built to support the physical world rather than abstract it away. Half Built HQ isn’t a showcase. It’s a living archive of work in progress, documented so others can follow along, dig deeper, or build on what’s here. Brewing. Building. Tech.

Search the archive