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.
Dependent Actor (cbpi-DependentActor)
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.
1wire Advanced (cbpi-OneWireAdvanced)
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.
On at Startup (cbpi-OnAtStartup)
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.
Cascade PID (cbpi-CascadePID)
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).
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.