BruControl: Brewery control & automation software

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Ya something is amiss. Keep in mind 5500W is a LOT of heat in a small cavity. It will heat it REALLY quickly. You must make sure:

1. Don't allow power to it unless you are sure there is adequate flow.
2. Don't allow too much power to it... if Duty Cycle, start really small. If PID put a cap on the max.
3. There is an exit for steam to escape... else bad things can happen!

The temperature sensor was too far out of the liquid. I ordered a Tc to female fitting that should fix it.
IMG_0457.JPG
 
Can't you just remove the coupling and a nipple?

The Tc is a male 1/2 and so is the compression fitting for the sensor. So I used a coupler I had laying around. I ordered a Tc to 1/2 female NPT fitting that should help.
 
Oh, I see. Looked at it too fast before. You want the tip of the probe below the level of the exit.

Also, the QZ has baffles. The top one should be near the top of the heaters to keep the heaters aligned and to ensure turbulence (mixing) of the liquid as it leaves the heaters.
 
Oh, I see. Looked at it too fast before. You want the tip of the probe below the level of the exit.

Also, the QZ has baffles. The top one should be near the top of the heaters to keep the heaters aligned and to ensure turbulence (mixing) of the liquid as it leaves the heaters.

Thanks for the info, I will check the baffle.
 
It's all good... just tryna help a man out. 3435 and 3950 are two different animals - we would need to know which you actually have.

These numbers refer to the thermistor's beta coefficient. It is a simpler approximation than the Steinhart-Hart coefficients BC uses, but you can get them close.

If you use an ohmmeter, you can measure the resistance at known temperatures. True "knowns" would be 0 (ice water) and 100 (boiling water at sea level). Other knowns can be measured with a quality temp probe. Put them into this calculator to figure out the SH coefficients: https://www.thinksrs.com/downloads/programs/therm calc/ntccalibrator/ntccalculator.html
The bag the sensors came in state they are 3435 thermistors.
 
Ok so I figured out my issue after swapping the probes only to have the same issue... I only had the #1 channel connected to a probe on my brucontrol interface so I decided to set up the other probe channels in the software and found all the other channels but the #1 output on the board work correctly. Even with no proble wired to the #1 output screw terminals I was still getting 72.63 degrees so it appears something is not functioning on the #1 channel.
Luckily I only need 4 out of the 6 channels.
 
Measure the voltage of the #1 channel with respect to ground, with and without the probe attached. If it doesn’t change, something is wrong with the thermistor filter. This is really unlikely as it’s some simple passive components but nevetheless we’ll replace it.
 
Measure the voltage of the #1 channel with respect to ground, with and without the probe attached. If it doesn’t change, something is wrong with the thermistor filter. This is really unlikely as it’s some simple passive components but nevetheless we’ll replace it.
I will, it works but measures 103 degrees at 59 degrees temp (climbed when I warmed the probe) and 72.63 with all the wires disconnected. I moved the wires to the unused channel #5 and all is well so not sure what's going on unless the problem is with my output off the shield but I checked the wiring there for stray wires or poor connection and found none.
 
Is that with that channel going to different analog inputs on the interface (MEGA)? In other words, have you tested the combinations to see if it is the Analog input channel or the filter output channel which is causing the problem?
 
Is that with that channel going to different analog inputs on the interface (MEGA)? In other words, have you tested the combinations to see if it is the Analog input channel or the filter output channel which is causing the problem?
thats what I intend to do today. I will post an update.
 
Quick question. I want to interface a load cell into my brucontrol mega via a sparkfun HX711 load cell amplifier. This certainly can be done with the mega but I am not sure about it in the context of the brucontrol software and firmware however. I want to track weight changes during brewing and I would very much prefer to not use pressure as I do not want to punch any more holes in my kettle! Can this be accomplished and would there be any way to tare the load cell?
 
Last edited:
Right now, the firmware doesn't read this amplifier. We are considering making an element which can read and write over the I2C bus.

For load cells right now, you might consider going with an analog output version - these are easy to integrate.
 
Indeed analog would be easy but I currently am struggling to find a solution with an analog output (at least I think I am struggling with this but perhaps I am not seeing a potential solution properly). For a bit more clarity, I am using four load cells and using a wheatstone bridge configuration to combine them (via a sparkfun load combinator). Any recommendations to take this type of input and get an analog output that brucontrol could use?
 
Last edited:
Since we're on the load cell topic :)

I've got my load cells hooked up to a separate arduino mega, which then outputs a variable frequency PWM signal (using the Timer3 library) into the Brucontrol mega using the counter input. Using offset and multiplier on the rate, the rate displays as the HLT volume in gallons. I actually just got it working about an hour ago.

Question for anyone that might be able to help a noobie:

Is there any way to get rid of the counter totalizer and just display the rate (in other words the HLT volume)?

I tried to port that rate value over to a variable, but the variable displays as many decimal points as it can (sometimes 3, sometimes 10, etc.). Is there a way to format a variable so that it would only display 1 or 2 decimal points?

View media item 69791
thanks!

p.d.
 
Since we're on the load cell topic :)

I've got my load cells hooked up to a separate arduino mega, which then outputs a variable frequency PWM signal (using the Timer3 library) into the Brucontrol mega using the counter input. Using offset and multiplier on the rate, the rate displays as the HLT volume in gallons. I actually just got it working about an hour ago.

Question for anyone that might be able to help a noobie:

Is there any way to get rid of the counter totalizer and just display the rate (in other words the HLT volume)?

I tried to port that rate value over to a variable, but the variable displays as many decimal points as it can (sometimes 3, sometimes 10, etc.). Is there a way to format a variable so that it would only display 1 or 2 decimal points?

View media item 69791
thanks!

p.d.


I believe you can also emulate the value as a onewire DS18B20 in the weight cell mega and recieve the value in BC as a onewire input. Checkout onewirehub library.
 
Loaded up BruControl this last weekend, played with it for a couple hours, and was able to actually get a brew in on it the same day. Seemed stable, and did everything I needed it to do for now, and seems like it will be able to grow to whatever functions I could possibly need. I did have a couple issues though.

For starters, what is everyone using for their PID settings in their RIMS tubes? Is there an autotune function to get to the right ballpark? I went all over the place, and finally settled on P:1.75 I:.15 D:1 for it, and it worked good for most of the brew, but the slightest change in valve position, and it would start to oscillate further and further away from the set point, up to +/- 5 degrees. Most of the brew it was within a half degree though, so it has to be close. I am using a 5500 watt element at 120, so only 1375 watts, in a Stout RIMS tube. I know 5500 watts is a lot of power in that small of a space, but I was previously able to run the tube on both low and high power with my Auber PID and it kept it in check pretty well.

Also, how is everyone handling enabling and disabling their elements when the interface is locked. First I tried adding a switch, but I found no way to tie that directly to the element in question. Then, I built a simple script that monitors that switch, and if the switch is enabled/disabled, it then changes the output to the same status.

Code:
[elements]
//Check HLT switch status, turn element on or off
if "HLT" state == on
    "HLT Element" enabled == on
endif
if "HLT" state == off
    "HLT Element" enabled == off
endif

// Check RIMS switch status, turn element on or off
if "Rims" state == on
    "Rims Element" enabled == on
endif
if "Rims" state == off
    "Rims Element" enabled == off
endif

//Check Boil switch status, turn element on or off
if "Boil" state == on
    "Boil Element" enabled == on
endif
if "Boil" state == off
    "Boil Element" enabled == off
endif

//Repeat ad nauseum
sleep 1000
goto elements

This seemed to work good for making the switch control the outputs, however whenever the script would run, my graphs stop working. It seemed to be a product of the sleep statement. If I increased the sleep time to 10 seconds, graphs continued to work fine, but I really don't want a 10 second delay between telling it to turn off, and it actually turning off. Bad things could happen in that long of a time period.

Finally, in my panel the last device power runs through before going to the element, is a large 30 amp contactor powered by a switch on the front of my panel. Because the script switch wasn't working well, I was using the physical switch to enable/disable it. Frequently when throwing that switch, it would cause some sort of EMF or something, and the temp probes (PT100) would drop connection for a second. It then comes back, and all is well, but the -1700 some degrees really throws off my graph for the 10 minutes it takes to scroll off. Any suggestions to keep this from happening? I set the floor of the temp probes to 50 degrees, and that helped make the graph not so drastic, but that's just a band aid, and I would like to fix the root cause.

Also, @BrunDog, these are the Wemos D1 Lite I inquired about possibly working with your 8266 firmware. They are supposed to be the same thing, only missing the flash storage. Thanks.

https://www.amazon.com/dp/B07BK435ZW/?tag=skimlinks_replacement-20
 
Communication is 3000ms, so you will want to increase that to at least that. I am betting 1000 is messing with the loop.
 
Also, how is everyone handling enabling and disabling their elements when the interface is locked. First I tried adding a switch, but I found no way to tie that directly to the element in question. Then, I built a simple script that monitors that switch, and if the switch is enabled/disabled, it then changes the output to the same status.

Code:
[elements]
//Check HLT switch status, turn element on or off
if "HLT" state == on
    "HLT Element" enabled == on
endif
if "HLT" state == off
    "HLT Element" enabled == off
endif

// Check RIMS switch status, turn element on or off
if "Rims" state == on
    "Rims Element" enabled == on
endif
if "Rims" state == off
    "Rims Element" enabled == off
endif

//Check Boil switch status, turn element on or off
if "Boil" state == on
    "Boil Element" enabled == on
endif
if "Boil" state == off
    "Boil Element" enabled == off
endif

//Repeat ad nauseum
sleep 1000
goto elements

This seemed to work good for making the switch control the outputs, however whenever the script would run, my graphs stop working. It seemed to be a product of the sleep statement. If I increased the sleep time to 10 seconds, graphs continued to work fine, but I really don't want a 10 second delay between telling it to turn off, and it actually turning off. Bad things could happen in that long of a time period.

This is how I've handled my shutdown. I just have a general kill switch for everything, elements, pumps and all. The main Brew Day script starts the Shutdown script. The Shutdown script pauses the main Brew Day script. When I take care of the issue that prompted the shutdown, I simply resume the Brew Day script and I pick up where I left off.

[loop]
"SHUTDOWN" State = false
wait "SHUTDOWN" State == true
"PUMP: Wort" Enabled = false
"PUMP: Wort" State = off
"PUMP: Water" Enabled = false
"PUMP: Water" State = off
"PID: Elem1" Enabled = false
"PID: Elem2" Enabled = false
"DUTY: Elem1" Enabled = false
"DUTY: Elem2" Enabled = false
pause "Brew Day"
goto loop
 
Communication is 3000ms, so you will want to increase that to at least that. I am betting 1000 is messing with the loop.
What do you mean communication? Communication to the Arduino? I have that set to 1 second, so is that still applicable?

This is how I've handled my shutdown. I just have a general kill switch for everything, elements, pumps and all. The main Brew Day script starts the Shutdown script. The Shutdown script pauses the main Brew Day script. When I take care of the issue that prompted the shutdown, I simply resume the Brew Day script and I pick up where I left off.

[loop]
"SHUTDOWN" State = false
wait "SHUTDOWN" State == true
"PUMP: Wort" Enabled = false
"PUMP: Wort" State = off
"PUMP: Water" Enabled = false
"PUMP: Water" State = off
"PID: Elem1" Enabled = false
"PID: Elem2" Enabled = false
"DUTY: Elem1" Enabled = false
"DUTY: Elem2" Enabled = false
pause "Brew Day"
goto loop

Not really looking for a shutdown script, I'm looking more for control of turning the elements on and off while brewing, similar to the switch on my panel. When the workspace is locked, you cant open the elements properties to disable it, only change the temp set point.
 
You can use the script I posted and modify it to do exactly what you're describing.

Edit: realized your not looking for just a way to turn it off.

You should be able to turn the element on/off even if it's locked. If it's a Duty Cycle set it to zero. If it's PID, set the temp to something absurdly low. But if you feel that takes too long, just use the script I posted above and create two buttons, one for "off" and the other for "on".
 
Last edited:
Loaded up BruControl this last weekend, played with it for a couple hours, and was able to actually get a brew in on it the same day. Seemed stable, and did everything I needed it to do for now, and seems like it will be able to grow to whatever functions I could possibly need. I did have a couple issues though.

For starters, what is everyone using for their PID settings in their RIMS tubes? Is there an autotune function to get to the right ballpark? I went all over the place, and finally settled on P:1.75 I:.15 D:1 for it, and it worked good for most of the brew, but the slightest change in valve position, and it would start to oscillate further and further away from the set point, up to +/- 5 degrees. Most of the brew it was within a half degree though, so it has to be close. I am using a 5500 watt element at 120, so only 1375 watts, in a Stout RIMS tube. I know 5500 watts is a lot of power in that small of a space, but I was previously able to run the tube on both low and high power with my Auber PID and it kept it in check pretty well.

Also, how is everyone handling enabling and disabling their elements when the interface is locked. First I tried adding a switch, but I found no way to tie that directly to the element in question. Then, I built a simple script that monitors that switch, and if the switch is enabled/disabled, it then changes the output to the same status.

Code:
[elements]
//Check HLT switch status, turn element on or off
if "HLT" state == on
    "HLT Element" enabled == on
endif
if "HLT" state == off
    "HLT Element" enabled == off
endif

// Check RIMS switch status, turn element on or off
if "Rims" state == on
    "Rims Element" enabled == on
endif
if "Rims" state == off
    "Rims Element" enabled == off
endif

//Check Boil switch status, turn element on or off
if "Boil" state == on
    "Boil Element" enabled == on
endif
if "Boil" state == off
    "Boil Element" enabled == off
endif

//Repeat ad nauseum
sleep 1000
goto elements

This seemed to work good for making the switch control the outputs, however whenever the script would run, my graphs stop working. It seemed to be a product of the sleep statement. If I increased the sleep time to 10 seconds, graphs continued to work fine, but I really don't want a 10 second delay between telling it to turn off, and it actually turning off. Bad things could happen in that long of a time period.

Finally, in my panel the last device power runs through before going to the element, is a large 30 amp contactor powered by a switch on the front of my panel. Because the script switch wasn't working well, I was using the physical switch to enable/disable it. Frequently when throwing that switch, it would cause some sort of EMF or something, and the temp probes (PT100) would drop connection for a second. It then comes back, and all is well, but the -1700 some degrees really throws off my graph for the 10 minutes it takes to scroll off. Any suggestions to keep this from happening? I set the floor of the temp probes to 50 degrees, and that helped make the graph not so drastic, but that's just a band aid, and I would like to fix the root cause.

Also, @BrunDog, these are the Wemos D1 Lite I inquired about possibly working with your 8266 firmware. They are supposed to be the same thing, only missing the flash storage. Thanks.

https://www.amazon.com/dp/B07BK435ZW/?tag=skimlinks_replacement-20

Regarding your RIMs tube, those are some pretty soft values. The integrator may not be enough. Where is the sensor located that is driving that PID (top of tube or somewhere else?). There is currently no auto-tune, but we shouldn't need one - this is a relatively slow responding control system.

Regarding the script... there is a minor issue that got re-introduced in the last version which allows scripts to continually re-send repeat instructions to the interface. In your script, this happens every second, which doesn't allow the PIDs to complete a calculation cycle. As a work-around, try this. The toggle only allows the enable/disable command to be sent to the interface when the switch changes (once). Note I am only showing the HLT toggle - you get the gist and can copy the concept down to the RIMS and Boil sections.

Code:
[start]
new boolean HLTtoggle
new boolean RIMStoggle
new boolean BKtoggle
HLTtoggle = false
RIMStoggle = false
BKtoggle = false

[elements]
//Check HLT switch status, turn element on or off
if "HLT" state == on
    if HLTtoggle == false
        "HLT Element" enabled == on
        HLTtoggle = true
    endif
endif
if "HLT" state == off
    if HLTtoggle == true
        "HLT Element" enabled == off
        HLTtoggle = false
    endif
endif

//Repeat ad nauseum
sleep 1000
goto elements

Graphs should never stop working, but I suspect the above code will fix it for the same reason.

The switch spike is occurring when the contactor's inductive load drops. A MOV and/or RC snubber should help it. You'll need to read above to understand that, or LMK and I'll provide more info.

WRT the mini-lites, they have the ESP8285 (not ESP8266), which has on-chip flash. These should work fine.
 
Last edited:
WRT the mini-lites, they have the ESP8285 (not ESP8266), which has on-chip flash. These should work fine.
So I've tried and tried, but I can not get it to work. It looks like the firmware flashes ok, but I can not get it to connect to my wireless network. These don't seem to have the built in AP mode that you use to connect it, and I just can get it to go. Do you have copies of the firmware in .INO or .LUA that I can open with Arduino IDE or ESPlorer? I think I've found a way to hard set the ssid, but it requires editing the sketch.
 
After flashing, are you connecting via the terminal to set up the network parameters? We don't use AP mode to set them up - we use the network setup steps which is built into the Universal FW installation tool.

Does that work for the ESPs? I was under the impression that that was only for the wiznets on the arduinos. I will try it though
 
I believe you can also emulate the value as a onewire DS18B20 in the weight cell mega and recieve the value in BC as a onewire input. Checkout onewirehub library.

smort,

thanks for that tip! got an Uno up and running sending values to Brucontrol by emulating a 1-wire device. not sure which way i'll go yet, but it's good to have options.

p.d.
 
Please check the documentation. Its for all interface FW that uses E, F, W (Ethernet 1, Ethernet 2, Wi-Fi) connections. Not S, P, or Y (Serial, Panel config, or Yun).

So, I used the install tool to configure the network, but still no dice. It flashes the firmware and looks good, but when trying to config the network it just doesn't want to talk any more. Entering the %0&15; command produces no response from the ESP. Just to make sure I wasn't crazy, I used a D1 mini (not lite) that I have running another project, blanked it first, then uploaded the Brucontrol firmware and tried configuring the network on it. Same result, could not get any response from the terminal window when entering the config command.
 
Last edited:
Arg. Not sure what's happening, but I keep frying MEGAs. The first two I chalked up to being careless while building, etc., but the last one died after I turned a contactor on and then off again, so I think that it was perhaps a casualty of the dreaded voltage spikes. I'm powering it via a 12v power supply through the VIN pin on this screw shield.

I need to update my wiring diagram to reflect how it has progressed during the build, but the image below is more or less how the low voltage side of things is wired. Are there any obvious gotchas that I need to look out for in my wiring? I have this 8 channel relay board. The 40a contactors, one of which I believe caused the most recent damage are controlled (via BruControl) by the relay board. I switched on and off one of the contactors and observed one of my RTD probes reset (but not the two others). Then I switche on and off the other contactor, and the MEGA disappeared. It can no longer be powered by the VIN, even though VIN is seeing 12V.

HELP!



Adam BruControl DC wiring.png
 
Arg. Not sure what's happening, but I keep frying MEGAs. The first two I chalked up to being careless while building, etc., but the last one died after I turned a contactor on and then off again, so I think that it was perhaps a casualty of the dreaded voltage spikes. I'm powering it via a 12v power supply through the VIN pin on this screw shield.

I need to update my wiring diagram to reflect how it has progressed during the build, but the image below is more or less how the low voltage side of things is wired. Are there any obvious gotchas that I need to look out for in my wiring? I have this 8 channel relay board. The 40a contactors, one of which I believe caused the most recent damage are controlled (via BruControl) by the relay board. I switched on and off one of the contactors and observed one of my RTD probes reset (but not the two others). Then I switche on and off the other contactor, and the MEGA disappeared. It can no longer be powered by the VIN, even though VIN is seeing 12V.

HELP!



View attachment 598689
I'm confused by something you said. You have contactors being controlled by relays (SSRs?)?

Or do you mean you're controlling your 40A SSRs via the relay board? Which would still be confusing to me.
 
I'm confused by something you said. You have contactors being controlled by relays (SSRs?)?

Or do you mean you're controlling your 40A SSRs via the relay board? Which would still be confusing to me.
Sorry I wasn’t clear—I have 2 5500 watt elements that are controlled by SSRs as usual, but they are also physically switched on via DPST contactors. This is so both hot lines to the elements are disconnected unless I have “activated” them. This requires that the contactors’ coils be powered, which is controlled via the relay board. The relay board is just acting as a switch to enable each element.
 
@BrunDog, is there any reason the Rugged MEGA wouldn’t work? I’m not going to buy it just yet— I still have a spare MEGA lying around and I’m not that keen on spending $110 on a part that I keep burning up until I’ve done some more significant troubleshooting. But it does seem appealing right now when I’m faced with the prospect of pulling out another MEGA and then reconnecting everything. Ugh.
 
Back
Top