I’m finally getting with the program and making my own hop water. The first version I made is based on various chunks of advice received from my homebrew club. Super simple:
20 litres of Guelph water (extremely hard water with high alkalinity)
20 grams of citric acid
20 grams of T90 hops (El Dorado for v1)
Method
My strategy was to seal a jar with 1 litre of 80C water, with the hops, and its share of the citric acid for 20 minutes. I wanted to include acid in this stage to lower the pH to hopefully reduce extraction of astringent hop compounds. While waiting for the hops to steep, I filled a sanitized keg with 19 litres of cold water, and the rest of the citric acid. Once time was up I then used my pour-over coffee set up (ceramic Hario v60 dripper) to drip the hop tea directly into the keg before topping up water and installing the spear. I then carbonated at 30psi in my keg fridge, which amounts to a bit more than 4 vols of CO2.
Citric Acid from one of my local homebrew shops
Hop tea, approximately 20g hops/1g citric acid in 1litre of 80C water for 20 minutes.
Filtering hop tea with coffee filter
What’s left. It appears rather shiny and oily, so this may have been too fine of a filter.
Initial thoughts
The hop taste is quite low, but present. The material left in the coffee filter appeared very oily leading me to believe a lot of the good stuff was left behind. For the next batch I will use a much coarser filtration method for same quantity of hops and see how the hop presence changes.
In general the flavour is pretty good, and the acid level seemed appropriate. You can definitely taste lemony acidity from the citric acid at this level, and I’m undecided if that’s a feature or a flaw. I haven’t checked the pH of the result either, but likely somewhere in the 4 to 4.5 range for this water. I’ll finish this keg before I decide to do anything with the acid for the next batch, which I don’t expect will take long!
In early 2019 a brewer, and reader of this blog by the name of Chris Van reached out to me for some more details on the plumbing of my brewery. We’ve chatted off and on since, while he built his own interpretation of my brewery design. He now has a handful of brews under his belt using this system, and has provided some pictures.
Chris’ iteration includes a removable drain pan near the pump and system drain in his brew stand, and shelves for his counterflow chiller (Northern Brewer) and brewery controller (auber instruments). He went for a 3-way valve on the pump outlet (to route wort through his RIMS tube into his mash tun during mash recirculation, or towards his boil kettle), and another 3 way valve near the boil kettle (to select between boil kettle recirculation or to route wort through his CFC). The 3 way valves allow the system to be more compact (and look great). Like me, he opted for custom kettles with tri clamp fittings from Spike Brewing.
In the process of planning the revisions detailed in part 3, I remembered that with my next brewery update, I had wanted to implement low oxygen brewing principles. This meant going back and adding a couple more design goals – namely the ability to underlet my mash tun to mash in with deaerated strike water. Also, I wanted to fill my boil kettle from the bottom port rather than the 20cm or so from the bottom through my whirlpool port. On the want-to-haves was (and still is), a stainless counterflow chiller.
It doesn’t sound like a lot, or maybe it does, but if my intention is still to have a hose-change-less brewery, the piping gets pretty complicated with even one of these feature additions. So for awhile I contemplated a brewery design that would have me making some hose changes instead.
Somewhere along the line I realized I don’t have the time or capital to see it all through, for now at least. I still have a PhD to finish here and hadn’t done the (essential?) task of brewing in several months. The last brew day at home was in May (4 months ago)!
So what I’ve done for now is basically completely revert things and settle with a few minor but meaningful improvements. Thankfully I had resolved to not destroy my old brew stand while I was exploring all of the system changes I explored (see parts 1, 2, 3), so it was there waiting for me…
Valve swap
The most immediately noticeable change is that I swapped out the butterfly valves that control the flow into my mash tun and boil kettle, for full bore quick-clean ball valves. What I had been experiencing during lautering with my system, is that the head pressure difference between a full mash tun and empty boil kettle was great enough, and my pipe restriction/friction losses minimal enough, that I could not control the transfer rate to be as slow and consistent as I wanted it. My pump VFD, which I dreamt as a panacea to all things flow rate control, was useless here. The butterfly valves essentially can only be used in an on/off type of scenario so there was no back up solution here. I had sanitary diaphragm valves at one point in my brewery’s history, and I expect I may eventually move back to those in some way. We’ll see how this goes first.
My brewery, now with quick clean ball valves (blue handles), for some primitive flow restriction.
Plumbing isolation
What else? I added a couple butterfly valves immediately off my pump output tee. This allows me to isolate sections of my plumbing. From a sanitation perspective this offered an improvement as the plumbing between my pump and mash tun return was free to back flow while transferring wort to fermentor, and that liquid, and the plumbing holding it hadn’t been boiled/pasteurized in the same way. This also gives me a bit more flexibility should I want to partially pull apart my brewery while in use, or only use a part of my brewery (i.e. limit soiling/contamination/cleaning) say for cleaning kegs or for using my mash tun and RIMS tube for Sous Vide.
Kind of difficult to see – but two butterfly valves have been added to my pump outlet to provide some ability to isolate sections of my brewery plumbing (black handled valves seen near top of image by pump).
Gaskets
Lastly, my friend Pat sourced some PTFE/EPDM/PTFE sandwich gaskets for me. Originally I used EPDM gaskets throughout my brewery, but I found they:
Didn’t have the rigidity that I wanted (i.e. most hardware required supports)
Seemed to swell pretty quickly – short lifespan,
Were so soft that they were easily overtightened/deformed, and,
They seemed to stick hardware pieces together/were hard to remove if had been in place for any extended period of time (perhaps due to minerality of local water interacting, I thought?).
The move to PTFE gaskets addressed all of these things, but unfortunately due to some very minor alignment issues in the vessel outputs, when connected with unforgiving PTFE gaskets they either leaked or put undue stress on the ports. Just a little bit of flexibility here using a series of sandwich gaskets has remedied this issue nicely for me, and I’m happy with that!
PTFE/EPDM/PTFE sandwich gaskets are awesome.
Diagram
Updated process diagram
Conclusion
So there you have it. My 2019 updated brewery. Time to brew!
This post assumes parts 1 and 2 have been read first, and probably won’t make much sense otherwise!
After a small tweak, I was able to get my idea of RIMS+loop to work basically as I envisioned it in a water test. A ball valve controlling the loop flow rate more linearly (compared to the butterfly valve used in my first revision) proved to be essential.
While I was setting everything up for my test [and preparing myself for failure], I figured even if only a small amount of flow was looped in the design, that would offer some meaningful safety for use of an inline heater – and surely that was possible.
Using two ball valves, I am able to dial in a RIMS loop recirculation rate ranging from 1/2 to 3/4 of the overflow (for example, 12 litres/min flow rate through the RIMS tube, with 9 litres/min recirculating back through the pump immediately, and the flow rate in/out of the mash tun consisting of the remaining 3 litres/min. I keep the pump frequency around 50%. Centrifugal pump RPM and flow rates have roughly a quadratic relationship, so this is may be more of a reduction in actual flow rate than you might think (N.B. I don’t actually have a flow meter, unfortunately. Sanitary flow meters are super expensive – even without taking into account the ability to handle some suspended solids).
With the water test a success. I should probably brew with it. For the test brew, I won’t worry about making the plumbing look perfect and will focus on functionality. If the real world performance impresses, I will consider implementing the design more permanently (which I figure may require one custom Tri Clamp tee to pull off). I can’t brew with the set up shown here exactly as I removed a temperature probe from my RIMS tube to run the tests. Yes that’s my old stand. Good think I didn’t demolish it yet.
I’ve made some progress with the design changes I detailed in post 1 of this series. I was able to implement the design, but in testing, it failed to give me the result I was hoping for. It has informed a revised design that I hold hope for working, however. This post won’t make any sense without reading the one linked above first.
When the loop was open to a significant degree (controlled by a butterfly valve), excessive pressure is not built within the loop – pressure sufficient to push liquid up to the mash tun return anyways. A check valve may be required on the mash tun output to prevent this, as with this design there is nothing stopping that loop pressure from being removed with just a bit of back flow. I don’t know enough about check valve internals and mechanisms to know whether it would be advisable to put one in this location. I do know that it would be a bit of an expense for me to get one to try it. My instinct is that a check valve isn’t a great idea as the involved pressures are pretty low and likely insufficient to trigger the most check valve mechanisms (whether closing a normally open check valve, or vice versa), and this may not even be the main issue.
The second issue, what I think is a larger issue, is that some kind of proportional valve, rather than a butterfly valve is necessary to control the loop flow rate. I think it’s possible that with sufficient throttling at this point that the idea works without a check valve on the mash tun outlet. In my initial testing, I did not have the granularity to test this using the butterfly valve. You would think this would be as easy as swapping one valve out – and it is, except the valve dimensions are different from one another, requiring a new plumbing layout. So, I’m in the process of testing a revise design with the butterfly valve swapped for a ball valve. Due to some decreased confidence in this idea, I am no longer determined to devise an entirely hard piped layout to test the second design revision. If I figure something out, great. Ironically, as my revised plumbing is almost identical to what I started with – I could’ve easily tested this without work on a new brewstand.
All in all, this has been a good lesson for me – test new ideas as rudimentary as possible and build from there. My next post will be testing the second design revision, hopefully with different results!
Planning the brew stand for the design using whatever I can find.
Closer look at the plumbing layout I was working to accomodate
Brew stand made, roughly. Requires more support and fastening, but sufficient for a small test.
I had to move the whole assembly near my wall mounted VFD for testing. I had left casters on my old stand – not wanting to modify it until this new design was sorted out entirely. A little short sighted, but I persevered.
More looks at plumbing. Only concerned with testing the mash side of things at this point.
Does it work? Not really. The mash tun flow here is essentially under the “old method” – the loop is nearly fully closed.
Updated process diagram, with addition of check valve and proportional valve (highlighted in yellow). Revision 1 diagram can be found on the previous blog entry.
I am always tweaking things in the brewery. Motivation for these changes vary, but usually start with a curiousity and snowball from there. This year’s updates have been related to an idea I’ve been sharing for recirculating mash systems. These types of breweries require recirculation that is quick enough to keep wort well mixed such that temperature readings are representative (minimal lag and stratification), heat exchange is effective (ideally somewhat turbulent flow), and mash solids (coagulated proteins, lipids, various grain material) suitably suspended to prevent scorching and other issues. At the same time, the draw/return rate from the mash lauter tun must be low enough as to not cause grain bed compaction, vectoring, etc.
My idea is not unique, but I haven’t seen it used by another homebrewer anyways. It involves a high flow rate “loop” in a breweries plumbing, which should prevent the formation of excess pressure across the grain bed (i.e. can work as a wort grant, essentially), and also allows higher flow rates in a HERMS coil or RIMS heater without requiring a high draw/return from the mash lauter tun. I don’t know exactly what to call this modified design. RIMS+loop and HERMS+loop?
Some brewers, myself included, have been reducing the wattage of their inline heater during the mash recirculation process. This remains as a good, common-sense idea, though I expect that with this kind of system you may not find that is necessary. I personally will be experimenting with gradually lifting the limiter I apply during mash recirculation.
Everything is perhaps best explained diagrammatically. Check out Figures 1 through 3 for plumbing and flow paths during mash recirculation, lautering, and whirlpool. The descriptions contain lots of extra details.
Figure 1: This diagram shows the mash recirculation process. Line thickness indicates the relative flow rates. You can see that a high flow rate is maintained in a loop containing an inline heater (for RIMS anyways, though the idea would work as well for HERMS) and the pump. A relatively low flow rate is maintained for actual mash lauter tun draw and returns. This offers a safety advantage over a no-loop RIMS system, in that if there are permeability issues with your grain bed, liquid will continue to move across the inline heating element and your temperature sensor should continue to be accurate if placed within the loop. Ideally this situation does not happen due to the ability of the loop to function like a wort grant – preventing the formation of excessive pressure across the grain bed.
Figure 2: This figure depicts the lautering process. It is very similar to Figure 1- a higher velocity pump-heater loop is involved (which could be used for heating to mash runnings to a mash out temperature, or just used passively), with a lower draw rate from the mash lauter tun. The pump-heater loop again provides some of the functionality of a wort grant in theory.Figure 3: This figure depicts whirlpool process, which can be carried out as usual.
Next steps
This will surely require some optimization on my part. I expect that it is not suitable for most homebrewer pumps (e.g. smaller chugger or march pumps), though I could be wrong (I use a 1/2 hp sanitary centrifugal pump).
In terms of “dials to tweak” that I have with my brewery using this design, I now have a couple full port quick clean ball valves for my mash lauter tun and boil kettle return ports which should offer reasonable flow rate control. I also have VFD pump control which can control the flow rate and pressure of the pump-heater loop. There is also a small amount of flow rate control possible with the butterfly valves throughout my brewery – but not much!
I have some concern over the generation of excessive wort shear. I have not researched this sufficiently, but my understanding is that it can be damaging to wort quality in ways. Certainly it can disrupt coagulations of proteins and lipids, possibly allowing these materials to be carried further through the brewing process than might be ideal. Perhaps having impacts to beer stability or clarity. Whether proteins are actually degraded somehow seems unlikely to me with the forces that I would be generating… but not an expert here (yet).
I was able to implement the plumbing changes without really buying any new tri clamp pieces – I’ve amassed enough at this point to experiment with whatever idea I might have, which is handy. The valve tree had some inspiration from the SSbrewtech nano systems.
I would very much like to incorporate one or two sight glasses to my revised plumbing. These are very useful in monitoring the brewing process (e.g. mash running clarity, flow rate), but I have not found a great placement for them yet.
I also have to make a new brew stand or modify my existing one to work with my new plumbing. Pump placement, spacing, support locations are all slightly different. I am leaning towards making a completely new stand from lumber in case I end up wanting to go back or something. The materials are very cheap and already on hand, so no issues there.
This post continues my discussion of Node-RED for brewing applications. Read part 1 here.
The most recent information and version of my brewing dashboard can always be found on github. I’ll improve it and add features from time to time, and it’s all there for you to borrow ideas from/copy/modify and otherwise jump start your own process of using Node-RED.
My brewing dashboard is quite specific to my 2 vessel brewery. Node-RED really encourages intensely personalized app/dashboard development. Notable features of my brewing dashboard are:
PID temperature control of mash (using RIMS), with output limiting functionality
PID temperature control and manual control options of a boil kettle
Output blocking to ensure only a single element is used at once
Volume sensing (not shown in screenshots below as I had my pressure transmitter disconnected)
Looks nice and has mobile friendly buttons and sliders
MIT opensource license (any my code anyways, Node-RED itself is licensed under Apache 2.0)
There’s a bit more detail in each of the below screenshots. Please let me know if you have any questions about what I have going on here!
This dashboard has worked incredibly well for me so far. I’ve been using it in some form to brew for the past year or so. Changes I make to my dashboard now have tended towards more aesthetics rather than function. A goal of mine is to eventually incorporate control of my pump VFD (beyond basic on/off functionality), through this dashboard.
This is the main view of my brewing dashboard. Works well on mobile too (using 1 column instead of 2). Ignore the missing temperatures, I took this UI screenshot while all of my sensors were disconnected for brewery modifications…The mash settings page has all the advanced output and settings in regards to mash temperature control, that you may expect. One somewhat novel feature is that I have an output limiter for my RIMS inline heater. So for heating strike water I may use 100% output, but dial it back to 25% max for mash recirculation and temperature control. Also on this page, a temperature Δ may be specified (mash target vs. rims target). This may be necessary when brewing in situations with high heat loss (e.g. outside in the winter).The boil settings page is a little simpler. Just basic PID settings and PID related outputs (these are useful for tuning and troubleshooting PID behaviour). A PID on the boil may be used for no-boil beers or kettle sours. Possibly as well for a hop stand, though I think that’d be overkill.
Node-RED is a popular framework for visual programming. It is included with Raspbian, the official operating system of Raspberry Pi, and sees wide use for interfacing IoT devices and task automation. Programming in Node-RED is flow orientated – essentially signals or messages propagate through nodes which each deliver some functionality (e.g. directing, modifying, or expanding a message)
These flows are created using a visual editor, and 1000s of user created and maintained nodes exist to do pretty much anything with a simple drag, drop, and route workflow. If the included and contributed nodes are not enough, and you have some basic programming experience, it is easy to write your own function nodes using JavaScript. You can even call code written in some other language if you wanted. Pretty damn flexible.
The messages themselves may be invoked through interaction from a user (e.g. a button click on an associated dashboard), some scheduled regular injection, various input nodes, etc. For example, you can have a node which streams messages from a DS18B20 temperature sensor. You may route that message to a node that provides some kind of smoothing functionality, then to to a UI element that displays the current temperature.
Example flows in which a temperature reading is triggered by regular insertation of a timestamp. This temperature reading is smoothed for display in UI, and it is also routed to a PID algorithm.
While a dashboard is not necessary for a Node-RED project, they are commonly used. Lots of basic UI widgets are included with Node-RED-dashboard, the default dashboard package. These should cover most of what you would want to use, but again, you can also write your own widgets. Elements from Angular Material can be used without any extra setup or configuration, and this makes it relatively easy to create fully customized, modern and attractive widgets. You are not restricted to using Node-RED-dashboard however, and can use essentially any other front end library (e.g. vue.js) that you may want to build your dashboard if you want further flexibility. Check out the short video below for a demo of a custom ui widget I made – the lightning bolts indicate power and ability to power each of my two brewery elements (I prevent powering of both elements simultaneously with my Node-RED dashboard)
It’s easy to see why Node-RED is so popular across the complete range of programming experience levels and applications. About 18 months ago I think it was, I began playing with Node-RED myself. The programming style was a bit different from what I was used to, but eventually I became somewhat proficient in it and built a dashboard to control my homebrewery.
In comparison to CraftBeerPi, which is probably the most popular software on the Raspberry Pi for brewery control right now, a Node-RED dashboard is certainly more “assembly required”. It does have the benefits of wider use even if that use is not homebrewing specific though. The Node-RED discourse forum has thousands of questions and posts from other hobbyists and makers on how to do specific things with Node-RED, which can be easily related back to homebrewing. In comparison to the CraftBeerPi project, development is much more active, the project is much more stable, and it is also truly opensource (Apache 2.0 license).
For a user wanting custom functionality, endless control, and not afraid to get their hands dirty, Node-RED a good match.
I’ve been meaning to do a quick write up of the fermentation controller I built that uses an ESP8266 running BrewPiLess, with my ESP8266 PCB. The ESP8266 is a very popular WiFi enabled IoT device. Their most popular commercial use that I know of is in “smart plugs”. They’re used all the time for various home automation tasks.
There’s not much to this build, really. The ESP8266 PCB keeps the connections simple. In a small enclosure, I have an ESP8266 with my PCB, with a pair of relays for heating and cooling outputs. There’s a 5V DC power supply to power the ESP8266. For temperature sensors, the popular and cheap DS18B20 sensors are used. At minimum you need two sensors: one for beer/fermentor temperature, the other for chamber temperature. You could optionally use a third for the “room temperature”. And that’s it!
While the build is pretty simple, I know when planning a project like this, it can be very useful to see finished projects. I’ll include a parts list at the end.
Here are the internals of a completed controller. In the upper left is my ESP8266. In the upper right are some solid state relays. In the bottom left, there is a 5V DC power supply. Connections for temperature sensors and heating/cooling outputs are found on the bottom.
Here’s a better look at just the ESP8266 on my PCB. You’ll notice I use an external antenna. The metal enclosure used for the controller operates essentially as a Faraday cage. So a ~$1 upgrade to include the wireless antenna really helps with the strength of the controller’s WiFi connection, and reliability. Though it continues to work if the WiFi connection is dropped, you can’t do things like change the beer or chamber set points.
Here’s a close up of one of my assembled ESP8266 PCBs. The screw terminals are used for powering the device (5V), temperature probe connections, and heating and cooling outputs. They’re all labelled (which can’t be seen here). There are also 4 pins across the top which are used to connect to an LCD using the I2C protocol. More details on this PCB can in another post, here.
Here’s the bottom of my enclosure – I use XLR connectors for my DS18B20 temperature probes, and cable glands to secure SJOOW for AC inputs and outputs. I personally find these a fair bit easier to install than installing outlets into a controller (which generally involves bringing out the jigsaw if you’re using an enclosure like mine).
This is the LCD I mentioned earlier. It is a 20 x 4 line display. This shows the current controller status, as well as some basic information such as the IP address when booting up. These LCDs are 5V logic whereas the ESP8266 is 3.3V logic, so making this work required a logic level conversion circuit on my PCB (otherwise the PCB would be a bit simpler).
And finally, a shot of it all closed up! I did still need my jigsaw for this project in order to make a cutout for the LCD.
That about covers it. Let me know if you have any questions in the comments.
The parts list below uses Amazon.ca links as it’s what I generally use and I do get a small commission for purchases through my links. These components are generally easily found on other Amazon locales, or can be ordered directly from China (generally cheaper but longer wait) using on eBay or Aliexpress.
Link
Quantity
Description
1
Electrical enclosure for controller and relays. This is the one I use. There are many other options for this – including 3d printing one.
1
2 channel relay module. One channel for heating and one for cooling. In this build I used a pair of high quality SSRs as it is what I had on hand. Whatever you use, ensure that it is properly rated for the application at hand. For a fridge, or other appliance with a compressor, you should really use HP-rated contactor, that is controlled by this 5V relay module.
1 (optional)
Raspberry Pi. You can run Fermentrack on this Raspberry Pi to manage many of these fermentation controllers, or if you would like to do without, you can run BrewPiLess directly on each of your ESP8266. Both work great.
If you are using a Raspberry Pi, you will also require a 5V power adapter and a microSD card – there’s lots of well priced kits available that have everything you need to get started.
1 (optional)
2004 LCD (20×4 LCD). This is extra display that will show the activity of the controller. It’s a “nice to have” – not at all necessary to have a working controller. These can be found for cheap on eBay and Aliexpress.
2
DS18B20 Temperature probes. 2 are required (one for chamber, one for fermentor). Note that the link provided on the left is for a set of 3. A third can be used to monitor outside ambient temperature.
1
Wemos D1 mini (ESP8266). This is the actual microcontroller used in each controller. It will read our temperature sensors, and based on our settings and temperature history, it will activate the heating or cooling relays. It also has wireless capabilities for connecting to your network.
1
An ESP8266 PCB, as well as the necessary components for its assembly.
1
A 5V DC power supply for the ESP8266. Can also be found on Aliexpress or eBay for cheap.
Various
Miscellaneous connectors/receptacles are required for:
I spent about 2 years using CraftBeerPi 3.0 (CBPi 3.0) as the software running my Raspberry Pi brewery controller. During this time I have written a handful of plugins to enhance or extend the functionality of the software. These have all in turned been made opensource and shared with the CBPi community. What follows is an introduction to each of these plugins.
Note that I’ve since moved away from using CBPi (subject of a future post), but I do still try to maintain these plugins for the many people using them. Feel free to use the comment section here if you have any questions about these plugins. Bugs and issues are best reported directly on the respective Github repository.
Edit: Unfortunately I have discontinued support for these plugins as of May 22, 2019. Their respective repositories have been archived. The plugins can still be used as well as developed on personal forks.
The motivation of this plugin was to provide a very basic check in the software before activating actors in CBPi, on the basis of the state of some other relevant actors. For anybody unfamiliar with CBPi, actor is the generic term used for of any outputs that are controlled by the software. An Actor could be a heating element, a pump, a mash stirrer, an electrically actuated valve – you get it.
To be specific, this plugin provides, a new actor type called DependentActor in CBPi. A DependentActor is a container for some existing Base Actor, which will only power ON when it is triggered if its Actor Dependency is in a specific state. The Actor Dependency must be already ON if it is set as a prerequisite, and OFF if it is set as a restriction.
Note that checking the state of the actor’s dependency is only done once at time of actor attempted activation. If the actor dependency’s state is changed while base actor is on, the base actor will stay on! One way around this is to make two DependentActors and set them both to have each other as restrictions or dependencies. Once this is done I would suggest hiding the original base actors, and ensuring that it is the DependentActor containers referenced in any kettle or fermentor logic.
The most common use case for this plugin is when somebody does not want two electrical heating elements powered at the same time due to brewery control panel power limitations.
Another common use case is when a brewer only wants to allow a heating element to be on when its associated pump is on, such as in a RIMS brewery. This would be done to prevent settling of mash solids near heater interface which could lead to scorching/burning, as well as to keep mash runnings well mixed to ensure a reliable temperature reading.
This plugin is not a substitute for physical electrical safety devices such as breakers and fuses providing overcurrent protection where needed, and properly rated components throughout your panel, flow switches, etc., rather it provides some convenience in the software and an extra level of safety.
This plugin was built to provide some advanced functionality for the popular DS18B20 1wire temperature sensors, in comparison to the basic 1wire plugin included with CBPi.
This plugin allows you to set the precision of your 1wire sensors (different sensor precision has different sampling rates).
It provides functionality for sensor calibration (simple offset at this time).
It offers exponential moving averages for these sensors.
It can filter high and low values, and provide notification of their occurrence. Erroneous values are often encountered due to intermittent connection issues, etc.
You can set the update interval for your temperature sensors (e.g. 1.5 sec instead of 3.0 sec default for a system parameter that must be closely controlled such as a RIMS tube), and longer where frequent updating is not required.
Pretty useful stuff! Use it in place of the included 1wire plugin.
This is a simple one. Allows you to set an actor to come on automatically with start up of CraftBeerPi. I used this for turning on some lights and a system fan. Who knows what purpose you may find for it.
I wrote a plugin to implement a Cascade PID – which is just as it sounds: one PID controlling the set point of a second PID. Why would anybody want this? Well in RIMS and HERMS breweries, brewers often manually set a temperature differential between their RIMS tube or HLT and their target mash temperature. This can lead to pretty slow temperature control, and the required differential is often dependent on the brewery’s environment (e.g. winter brewday in a garage ≠ climate controlled indoor brewday). If you have ever lamented about slow ramp times with these systems with this control method, a CascadePID actor in CBPi MAY be for you.
Cascade PIDs are pretty difficult to tune honestly, best used for RIMS or HERMS types of systems as mentioned. If using this algorithm for mash temperature control, you must ensure consistent flow characteristics (which may be overly optimistic in a brewing application). To use it you must have a sensor for both the inner loop (e.g. RIMS tube, or HLT in HERMS) and the outer loop (actual mash temperature). You should probably have some sort of additional safety mechanism in case you run into a stuck recirculation too (e.g. flow switch). Read the README in the github repository for more details on Cascade PIDs.
And while I developed the plugin to try out this idea of CascadePID, what it is actually most popular for is the basic PID algorithm that I include in it, SinglePID. It has some extra parameters you can set in it in regards to controlling the integrator and integrator wind up. It seems to be the most reliable PID plugin for CBPi currently.
Edit: This plugin was renamed to Cascade Control, and also includes hysteresis functionality (including an advanced PID-controlled hysteresis).
Closing
CBPi software appeals to many homebrewers using Raspberry Pis due to its simplicity to set up. It can be used for hot side brewery process control, or cold side. For those that want more control over the exact algorithms being used, they’ll need to do things like write their own plugins (not that difficult for someone with any programming experience), or turn to other software. CBPi 4.0 is currently in development, and I expect that the plugin system will once again be one of its shining points. I do not expect however any of these will be compatible with it (fine by me 🙂). Until then, I hope these plugins make your CBPi controller a little more powerful.
