Fermentation readings in multiple vessels

Hi,
I’ve noticed you can now have the same batch in multiple vessels, which is great news for us, as we often split the same batch into multiple vessels for fermentation, then blend it back together prior to racking. I was just wondering how fermentation readings would work under this scenario?

We don’t want multiple gyles per brew as it gets confusing, but it would be great to keep a separate fermentation reading per FV for the same batch as at the moment I usually take an average to enter into the fermentation readings for the batch. I don’t want to lose the compare batches function either, which is a great feature, and really helps with analysis.

On a somewhat related note, an estimated time until put on chill function, calculated from the gravity analysis graph and based on the target final gravity (either set per beer or even better based on a set number of points above the target FG that you guys already calculate based on the OG) would be great, especially when planning weekends!

Cheers,

Keir.

Hi Keir,

Ah sure, I can see what you mean! At the moment fermentation readings are still on a per-batch basis, which I can see might be confusing when you have split into multiple vessels and would like to record on a per-vessel basis.

However, allowing fermentation readings on a per-vessel basis does raise a few issues that would then need to be solved. For example, what if you split a batch into 3 vessels, and Vessel 1 ends at 4%, Vessel 2 is at 5%, and Vessel 3 at 6% - what do we use as the entire batch’s ABV? We could average it, but it seems at that point that they are actually quite different batches of the same beer, and they are best represented that way in Breww. Anyway, that’s the reason we don’t split it per vessel at the moment! Happy to knock some ideas around of course and get your thoughts!

Great to hear its helpful!

Yeah absolutely, this would be a great feature! Would that basically be then the estimated time until the target FG is reached? Presumably that’s the chilling time the majority of the time.

Cheers,
Max

Hi Max,
Yes, I can see the problem. However, what you described is almost exactly what we do. Each brew is split equally into 2-3 fermentation vessels and we blend them back together in our racking tank (which is the only vessel we have big enough for a full brew), which averages out all the readings.

It seems that what we need is some sort of sub-gyle we can create to keep track of the separate readings. For example, we could create a new batch - say gyle 123 - transfer it into copper, so we get a recorded start volume, and then when we transfer it into three separate FVs we get gyles 123a, 123b, and 123c. Or perhaps we could have one FV set as the master gyle and then 123-2 and 123-3 for any subsequent gyles we transfer out after that?

The sub-gyles could also be kept, should we need to rack from just one of the vessels.

As far as the averaging goes, I would say that averaging out the readings proportionally by volume should work out fine. At the moment we simply say that 500 litres of 1.010 + 1000 litres of a 1.013 = a blended gravity of 1.012. The original gravity for the beers is the same, so working out the ABV should be straightforward too. Other readings should be just as straightforward, I think.

Another approach would be that should you blend beers back together, you could put a stop on any packaging until a new fermentation reading is done and entered onto Breww for the re-blended beer. Again, we would always take a blended reading before racking to ensure we have the correct final gravity recorded, so it would make sense from our perspective.

For the graphs and comparing batches, a sort of flow chart approach to readings with branching lines of the same colour that re-join when blended would be great, but I would be happy with an average reading across the whole fermentation, once the gyle is complete, if it is simpler to do.

Some sort of solution like this would make it much simpler to keep track of things for us, as at the moment, we are using workarounds to use Breww. Fermentation readings are obviously a large part of it, as I have to record everything on paper, work out an average to enter as our fermentation reading. I then enter the actual results in the notes. This gets more tricky on the day the vessels are put on chill though, as we end up with some vessels on chill before others, and knowing whether to still take an average or just enter the details for the FV that is still fermenting can be problematic.

Similarly, because we can only use one FV on Breww, I have to do similar things with the cleaning records too, making notes on which FVs were actually used when they were cleaned, and which pH reading is for which FV. All of this is especially fiddly, as I do most of the day to day recording on my phone.

Of course, if you have any ideas, I’d be happy to hear them, or any workarounds for problems, for now, would also be appreciated. For example, I’m already wondering why I don’t just transfer 1 litre from each brew into each of the other FVs we use, to trigger cleaning records! I’m sure there’s plenty of other things we could do too.

Cheers,

Keir.

We’ve just begun looking at the “time until chill” problem ourselves. Breww will allow you to overlay the readings of a previous brew over the current graph - we are going to experiment with this to see if it helps.

Hi Max,
Just another quick thought, but would it be far easier from your end to simply allow a custom set of fields to allow separate readings to be performed for breweries that split gyles the way we do? That way we Breww could just look at which vessels a single fermenting gyle is in and allow you to click on the batch, go to add fermentation reading along the lines of:

FV1 Gravity,
FV1 pH
FV1 Temp
FV2 Gravity,
FV2 pH
FV2 Temp

It could then take an average of all the gravities, pHs etc, and use those as the actual readings that get entered as the fermentation readings that are used on all the graphs and comparisons.

It would solve nearly all our problems, as we could look at the details should we need to, or could build reports to allow us to compare batches in more detail, should we need to. Most of the time, however, this would give us all we need.

Cheers,

Keir.

Hi Keir,

Ah yes, I see what you mean! Basically on the Add fermentation readings, display each field for each vessel and then average all the readings together before then storing them?

I think it would be possible (and maybe the ideal solution?) for Breww to provide the ability to record per-batch and per-vessel fermentation reading functionality that you’re looking for here, by allowing you to enter the vessel on which you are taking the readings. Breww would then store the full data about the readings for when you have a batch split, and could show them each individually or aggregated on the “Recent batch comparison graph” and also the main batch analysis graph.

Breww could then also display on the production dashboard the measured ABV of that batch in each vessel it is currently in. The slight difficulty is, what does Breww display as the overall batch’s ABV during the time the batch is split, when each vessel has different gravity readings, and they’ve all been taken at different times - but I’m sure we can work something out!

The batch would also still need a single original gravity and a single final gravity for the purposes of working out a definitive final ABV - but it sounds like that would be fine!

Let me know what you think!

Thanks,
Max

Hi Max,
Yep, that would indeed be the ideal solution for us. I can’t really see any problems at all with that method. I’m not too worried about the measured ABV by vessel, as our OGs are always kept within tolerance, and we aim for a standard target FG, using the tolerance allowed for ABV variance, instead of a varying FG depending on an exact ABV.

Basically, this all sounds great and will make life a lot simpler. Thank you. Can’t wait to be able to ditch the old, inevitably beer-soaked, paper fermentation records for good!

Cheers,

Keir.

1 Like

I’ve moved this thread to the feature request area so we can track this through to implementation.

Please can anybody who would like to see support for this give it a vote with the button in the top left? Thank you.