CraftBeerPI Brew Controller

[sittingaround]

Today I used the craftbeerpi controller to do a brew for the first time. I couldn't get the mash schedule recipe to actually control the kettle. I only have one kettle (BIAB) and no pumps/agitators etc. It reads temp ok, and i can manually activate the element using the flame button on the kettle panel. When I wanted to start the recipe schedule, I opened my recipe, hit the little car button on the kettle panel and pressed start above my recipe schedule. It wouldn't activate the kettle until I hit the flame button, and then once it reached temp it would just keep climbing. Also the timer clock that appears underneath each step would just stay at 00:00:00 and not move. If I hit start again, it would just skip the step. Somehow I managed to get one of the steps to work (but the timer wouldn't), and it would automatically use the overshoot logic to shut off close to target temp, but then it would just fall and not reactivate.

I ended up just turning the kettle on and off manually to control the temp. Not what I had planned.

What the hell am I doing wrong? All I want is for it to activate the kettle element, maintain temp then move on to the next step according to the times and temps I've preset. I'm hoping someone smarter than me can see where I've missed something. I set everything up following the official youtube clip.

Cheers! B)

Spid question but when you set up your mash schedule you allocated a time frame for each step? Can you post a pic of you mash schedule?

 

[Mat B]

Spid question but when you set up your mash schedule you allocated a time frame for each step? Can you post a pic of you mash schedule?

Here's some screenshots after my brew. I know it's recorded the times, but I manually controlled the kettle the entire time. It never ran the timer.

 

[tumi2]

i also did my first brew on the weekend using Craftbeerpi. I used a dual Kambrook portable heating plate to get me to mash temp and then maintain it. i usually brew 100% on gas.

It all worked fine including the auto schedule where it timed each step and turned the element on an off accordingly.

@Mat B - I know when i do it I always load my steps > Press Reset > then Start > then the Auto car button only after i can see the little arrow appear at step 1. Perhaps it is the order that you press the buttons.

One thing i noticed is that the timing all worked very well and in all my tests worked just as planned but at one stage it overshot my mash temp from 67 to 79 degrees (ouch!!). Not sure how it happened because everything else worked just to plan. I wonder if the wort heated slowly and then a mass of hot water sitting below the temp probe rose to the middle where my probe was. At this time the wort was now way past the desired temp the element turned off and i had to quickly add cold water to get temp back down. I cant think of how else this could have happened.... It made me realise why so many brewers recirculate the wort.

Overall though, i can see that craftbeerpi will be very good, particularly when the version 2.2 is released.

 

[Mat B]

Yeah I thought it might have something to do with the order I hit the buttons. I might do a test with some water following the steps you've outlined.

Regarding your big temp increase, something similar happened to me. I noticed that the probe had slipped a little bit out of the thermowell, and wasn't getting a good reading. I also suspect some cold draft blowing towards the thermowell entrance didn't help. So I put it back in and blocked it up which solved it.

Also Tumi2, what have you got the overshoot logic set to?

 

[sittingaround]

Yeah I thought it might have something to do with the order I hit the buttons. I might do a test with some water following the steps you've outlined.

Regarding your big temp increase, something similar happened to me. I noticed that the probe had slipped a little bit out of the thermowell, and wasn't getting a good reading. I also suspect some cold draft blowing towards the thermowell entrance didn't help. So I put it back in and blocked it up which solved it.

Also Tumi2, what have you got the overshoot logic set to?

Come to think of it i did have an issue getting to start but hitting reset a few times seemed to fix it. I ran overshoot for my firat brew and it was always over or under by upto a 1 deg. I found using the pid logic works fantastically well. Hit target temps without o erahooting and holds them there within .3 of a deg.

 

[tumi2]

I certainly seem to need to push Reset at least once, wait a few secs and then hit start. I think this is simple delay in the input being received by the app over your wifi network and then running whatever scripts need to run. I have noticed a little inconsistency in getting the Start button to start by hitting Reset waiting a sec and then start seems to work.

I have my Overshoot set to 1 degree. I am going to set it to 2 degrees to allow for a delay in the desired temp being reached and then the app adjusting accordingly.

Im not really sure what PID logic means and what the fields stand for.

 

[Mat B]

Im not really sure what PID logic means and what the fields stand for.

I'm also not that familiar with it. My understanding is most temp controllers are PID controllers. How does this option vary from the overshoot option?

BTW, good advice re the reset button delay. I'll be sure to try that.

 

[sittingaround]

It seems to control the rate at witch it climbs and tappers off as it reaches the target temp. I found the overshoot logic seemed to ramp right up at full ball then pull up just before.

 

[Mat B]

I found the same thing. It was annoying.

 

[GibboQLD]

Im not really sure what PID logic means and what the fields stand for.

I'm also not that familiar with it. My understanding is most temp controllers are PID controllers. How does this option vary from the overshoot option?

It seems to control the rate at witch it climbs and tappers off as it reaches the target temp. I found the overshoot logic seemed to ramp right up at full ball then pull up just before.

I'm not affiliated with CraftBeerPi at all, just taking a crack at answering this for you in case Manuel doesn't show for a few days.

Overshoot logic is basically a comparison between your current temperature + the overshoot amount, and the target temperature. If your target temperature is 68° and your overshoot is 2°, your element will run at 100% until it reaches 66°, at which point it will turn off. Similarly, if the element is off and the mash cools below 66°, the element will be turned back on at 100% until it tips above whatever your setpoint is, less the overshoot amount. There are only ever 2 settings: off (0%) or on (100%).

As you've already found, overshoot can be good if all you need is simple temperature control, but since the element continues to heat the mash/water after it's turned off, you can get quite large spikes in temperature which make it hard to "dial in" mash temperatures and/or hold precise temperatures. It only gets worse if there's a bit of a path/process between the element and your temperature sensor, since there may be a few degrees difference between those points anyway, let alone what happens after the element is switched off.

There are people on this forum (and the internet in general) who could explain PID way better than I could, but in a nutshell, it allows you to scale the output of your element to suit the setpoint, and to maintain temperatures with much less variation. Without boring you with the details about type A, B or C implementations, the PID algorithm in the context of CraftBeerPi has three terms:

1. Proportional term: compares the difference between the setpoint and the current temperature. If the difference is large, the proportional term is large. Referred to as 'error value'.
2. Integral term: compares past error values with the setpoint and adds them together, determining the effectiveness of the current output in reaching a target temperature. If the current output is too slow or not strong enough, the error values will accumulate over time and the controller will respond by scaling the output accordingly.
3. Derivative term: works on the rate of change and tries to scale the output to meet future values.

All three terms are summed and the resulting output typically represents a percentage between 0 and 100. As with the case of the overshoot logic example above, if your setpoint is 68° and the current temperature is 66°, the resulting output would be the combination of the proportional term (i.e., a small difference), the integral term (i.e., accumulation of small error values) and the derivative term (which may actually be negative if the rate of change results in future values that are too high), which may cause the output to scale to a very low percentage in order to meet the temperature.

There's a pretty good write-up about PID as it relates to homebrew here, which I believe may have been referenced by Manuel for CraftBeerPi. It also includes a good run-down of how the writer tuned his system and derived values for Kc, Ti and Td to suit his brew setup.

 

[Mat B]

Sounds like PID logic might be worth a try then. SO if I understand correctly, the PID logic will adjust/scale the output as it approaches target, which should reduce the chance of it overshooting wildly?

 

[sittingaround]

Yeah thats how i read it. Ive used both and the pid logic hasnt overshot my set temp once since using it. I run a multi step mash and it works really well.

 

[tumi2]

Thanks for that good explanation. I will give it ago but it may take a few brews to tune the system correctly.

 

[Moad]

Edit: a little research answered my question...

 

[sittingaround]

Ok so be careful and nake sure you can see you control pannel at all times. Im using 2.1 and brewed with it yesterday 4th brew and i was running a stepped mash with a mash out at 78. As i eas getting my sparge water ready the temp prob stopped sending or the Pi stopped reading either way i had to shut down and reboot the pi. As a result the element goes full ball and my mash out temp reached 85 before i noticed it. Thankfully it waa withing the last 5 mins of mash out.

 

[GibboQLD]

As i eas getting my sparge water ready the temp prob stopped sending or the Pi stopped reading either way i had to shut down and reboot the pi. As a result the element goes full ball

From the pictures of your setup, it looks like you've got your SSR connected to either pin 3 or pin 5 -- a few people have done tests on the power-up condition of the GPIO pins and found that pins 3/5 (GPIO 2/3) default to high unless configured otherwise, which would explain why your element was active.

Might be a good idea to investigate/implement a bit of interface circuitry between the Pi and the SSR to prevent the element from turning on under similar conditions. Alternatively, you could change the way it switches so that low = on and high = off, assuming CraftBeerPi allows you to configure it that way.

 

[sittingaround]

Na the was active because it was on auto mode so when the temp probe cut off it read as -1 so the software turns on the element to reach the pre set step temp of 78.

 

[tumi2]

An update on my experience to date with Craftbeer Pi... Overall i think I am going to stick with this and look forward to version 2.2 to be released.

1) SSR experience
So if you recall from earlier posts i could not activate my Fotek SSR without adding a power source and adding a transistor into the circuit. Once the transistor was added using the 5v power from the RPI the Fotek SSR worked as expected. Someone on here advised to try Inkbird SSR which I did on the weekend and it worked directly from the RPI input and activated as expected. The lesson here is that the dodgy Fotek SSR's did not activate directly from the 3v input pin while the Inkbird does. I have tested this with 2 Fotek SSR's and they both would NOT activate without the transistor circuit. So im now ordering another Inkbird SSR so i dont need the complication of transistor circuity.

2) PID and Overshoot logic
I brewed on the weekend and tried to use PID logic rather than Overshoot. Last time i used overshoot it massively oversshot my mash target. The PID logic seemed to work better but it was continuously switching my SSR in a pretty consistent pattern of 4 seconds Power Off and one second Power On. This concerned me a little as i wondered if it would damage either the SSR or my heating element. Due to this i reverted to Overshoot with a setting of 2. Provided i frequently stirred the mash to ensure an even spread of temp the overshoot worked much better. I also set the temp probe quite close to the base of the pot so it would read the water as it is heated. The lesson here was stir the mash to ensure even temp distribution and the Overshoot logic works fine.

3) Calibrating PID Logic - Can anyone share their calibration that i might be able to steal rather than figure my own out. I brew BIAB in a 50L SS pot in about 35 liters of mash water. I want to try the PID logic again but think the calibration is important

 

[Dave_022]

2) PID and Overshoot logic
I brewed on the weekend and tried to use PID logic rather than Overshoot. Last time i used overshoot it massively oversshot my mash target. The PID logic seemed to work better but it was continuously switching my SSR in a pretty consistent pattern of 4 seconds Power Off and one second Power On. This concerned me a little as i wondered if it would damage either the SSR or my heating element. Due to this i reverted to Overshoot with a setting of 2. Provided i frequently stirred the mash to ensure an even spread of temp the overshoot worked much better. I also set the temp probe quite close to the base of the pot so it would read the water as it is heated. The lesson here was stir the mash to ensure even temp distribution and the Overshoot logic works fine.

SSR's are fairly resilient that is why they are preferred over Electro-mechanical Relays (EMRs) these days. The mean time before failure of an EMR is about 100K where as an SSR will operate between 50-500 million times before failure. Implementation of PID logic for temperature is generally as follows.

Take the total output power of a system (say 2400W)
Take the error; which is the difference between the setpoint and measured temp.

Then the error is used to determine the proportional, integral and derivative which basically try and ramp temperature up as fast as possible without overshooting or creating a 'ripple effect' by measuring the changes to error over time.

This gives a % of power required at any given (preferably regular) interval at which the calculation is performed.

If the system is analog then you can simply set the power i.e 1200W for 50% etc.

However to use a digital system which only does on and off you select a window (5 seconds for example) and set a duty cycle from this; so for your 1 second on 4 seconds off it is working at 20%.

What you should see is it on all the time at the beginning and as you approach set temp it to spend more time off than on.

Given the above failure times and the use in this application i wouldn't worry to much about the SSR and the heating element won't know the difference between being operated like this and having a lower current passing through it because it is just a big resistor.

In comparison overshoot just realises that the element will still be hot when the power has gone and therefore it will continue to rise until it reaches equilibrium; so we take a punt at what the residual temperature rise will be. Obviously you can easily measure this by manually heating water, turning it off and measuring overshoot.

PID is a bit more complicated as you need to balance P, I and D to ensure that actually temp is reached; and in a timely manner and that it doesn't overshoot.... which is short, is a sod.

So why PID? When set properly the temperature will rise evenly without overshoot and then stay within about 0.1 degree C.

However, PID systems usually control systems where the setpoint changes and you don't want too much overshoot i.e. a missile guidance system where the target moves and you don't want it flying too far left then too far right etc etc.

Water heating on the other hand is a simple system so it may be considered overkill for this application; a bang-bang temperature control should be able to keep you within 1 degree easliy and probably better.

The choice is yours of course; in the past I have gone for PID because I spent ages perfecting the algorithm for another application on Arduino.....

On the other hand, I also like to drink beer so spending ages calibrating a system may fall further down on my priority list...

 

[loco88]

Can any of you blokes take a few pics of your Pi/Relay/Probe setup for me? I've setup a BrewPi before but that wasn't using the Pi pins, plus I want to see if I have enough spare parts lying around to make one of these Cheers