Expected quantities vs Measured quantities
See original GitHub issueObviously beersmith supports both, but IIRC @rocketman768 brewtarget only supports estimated values. I know there’s empty fields in the brewday print outs, but I don’t think brewtarget has any way to input measurements? Brewersfriend does not support measured values. Brewtoad does not support measured values. Beersmith does support it, and does export some of the properties in the recipe.xml file, notably abv vs est abv, and efficiency vs actual efficiency, batch size vs display batch size, etc etc.
As it stands I believe all quantities are currently the expected/estimated values?
If we are going to support both software estimated, and real life measured values, how will we do so?
A) Store the respective values in every property? My preference, as it keeps things following the current organization method rather than having to reproduce each schema for a measured copy.
IE
"boil_size": {
"units": "gal",
"volume": 5.5
},
Becomes
"boil_size": {
"units": "gal",
"volume":
{
"expected": 5.5,
"measured": 5.25
}
},
or
B) Have a separate file for all measured values. IE Estimated recipe.json and Measured recipe.json
Issue Analytics
- State:
- Created 6 years ago
- Comments:16 (11 by maintainers)
Top GitHub Comments
I am always disappointed that so few people know of the brewnotes.
tl;dr You will want a structure something like this:
It does have to be it’s own data structure. You will want what I would call an array of hashes, aka
[{}]
.The estimated v measured is interesting. I think I finally used three: calculated, projected and measured. Consider what happens when your recipe expects 75% efficiency, but you get 80%. That would not change the calculated ABV since that is based on the recipe and the expected efficiency. It would change the projected ABV, since that is based on what you actually brewed. And of course, there is the measured ABV after fermentation.
Another issue I had was dealing with changes to the original recipe. Imagine I brew a recipe three times and decide it needs a higher ABV, so I add another kilo of base malt. In my opinion, that should not change any of the information in the three batches I’ve already brewed. I ended up storing the original fields that I needed from the recipe into the brewnote.
I would like to see things like “brewer”, “assistant”, all of the primary/secondary/tertiary temperatures/dates/times removed from the recipe specification and put into this. Those possibly change with every brew day and should not be single values in the recipe object itself. Same for things like taste notes.
You may want to look at the BrewNotes objects in brewtarget and its database. I think it might provide some valuable input into this. I won’t claim it’s the best solution, but it has worked quite well for me.
I wonder if we are not trying to solve two different problems?
I mostly agree that recipe exchange between two users probably doesn’t need the historical information.
I believe very strongly that if a user wants to exchange software, they may want that historical information very badly. In other words, I want to make sure that a person who decides to go from brewtarget to brewtoad can take all of their information with them, not just the recipes.
If we do not specify some way of interchanging that data, then the data will never be interchanged. Not all the software (or any of it) needs to implement the feature, but I still strongly feel the idea needs to be there for those of us who want it. If the group decision is to not include it, fine. I lived without it in beerXML. But I think we are limiting a user’s ability to choose which software they want to use.
Having spent some time thinking about it, I do not believe a brew journal is really expressed as a modified copy of the existing recipe. A recipe is says “Add 28g of centennial at 15 minutes lef tin the boil”. A journal entry says “I ran out of centennial, so substituted columbus. I got busy talking to friends, so the 15 min addition became a 5 minute addition”. A copy of the recipe would gather the what, but not the why. I care about that why.
Yes, you could do that as notes on the copy of the recipe but I personally feel that it loses something important.