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.
BrunDog I have a few questions about BruControl, I am midway through my panel build and want to keep the panel as sparse as possible.

1) Does Bructrol support having a button used to activate a script.
2) Are there plans to have Brucontrol send data to a file?
3) Can you used a button to open up another workspace?
4) Can you put different workspaces on different monitors, if so do they all need to be the same size?
5) Is there a way to hide the menus and tab bar on top, to use as a more finished looking display?

Thanks, I really appreciate all the time you devote to your product.
 
1. Yes.
2. All data is currently logged into files. It can be a bit tricky figuring out which one because they are named by a UID, but nonetheless the data is there in .CSV format.
3. Not in the released version. In v1.1 a script command will allow for a particular workspace to be displayed (hoping release within a few weeks).
4. No. v1.2 will support web browser display. I suppose you could have multiple browser windows to display multiple workspaces. But we have not started development on it yet.
5. Not currently but this is a good idea. Are you suggesting a "fullscreen" mode? I think this is something we should add, triggered by script or button.
 
1. Yes.
2. All data is currently logged into files. It can be a bit tricky figuring out which one because they are named by a UID, but nonetheless the data is there in .CSV format.
3. Not in the released version. In v1.1 a script command will allow for a particular workspace to be displayed (hoping release within a few weeks).
4. No. v1.2 will support web browser display. I suppose you could have multiple browser windows to display multiple workspaces. But we have not started development on it yet.
5. Not currently but this is a good idea. Are you suggesting a "fullscreen" mode? I think this is something we should add, triggered by script or button.
This is nothing I cant work around but I can second the desire to have the ability to have a second workspace in a second window on another display.
Mainly because in my configuration I will have my conicals and all thats entailed in that control panel running all the time and normally have a flatscreen on the wall to display the information for this.. Currently when I brew I need to move this workspace to my different resolution touchscreen to use the hotside workspace and when I move it back to the tv monitor everything is resized and need to be fixed manually.
I intend on having the fermenter/chiller tilt readings on a flatscreen on our brewpub wall for all that equipment which resides in the basement and it would just be easier to not have to mess with the workspace each time I brew. I realize one way around all this is to just have two licenses but wouldnt that require two separate pcs as well?

I am pumped about the upcoming tilt support in v 1.1. This may be a dumb question but will the tilt be communicating directly with the firmware on the arduino through a bluetooth adapter on the arduino or through the software and pc? if on the latter I understand it will change the ability of the controller to work when the pc communication is lost.
 
Last edited:
I think this is a fair request. Multiple monitors for multiple workspaces. You guys are ahead of the game!!

We could probably build in multi-monitor support but we’ll discuss it. Right now 1.1 is locked for changes so it won’t happen tomorrow. But thank you for the great ideas.
 
I think this is a fair request. Multiple monitors for multiple workspaces. You guys are ahead of the game!!

We could probably build in multi-monitor support but we’ll discuss it. Right now 1.1 is locked for changes so it won’t happen tomorrow. But thank you for the great ideas.
That was quick!
I edited my post while you were responding. Did you happen to see my question about the tilt support?
 
Tilt support will be through interfaces which have BT capability built in. Right now, that is the Arduino Primo (discontinued recently, unfortunately), the Arduino 101, and the ESP32. We hadn't looked at incorporating the Tilt via a separate BT adapter but its not impossible.
 
Tilt support will be through interfaces which have BT capability built in. Right now, that is the Arduino Primo (discontinued recently, unfortunately), the Arduino 101, and the ESP32. We hadn't looked at incorporating the Tilt via a separate BT adapter but its not impossible.
Ok thank you, I have already purchased all the hardware to build the mega based fermentation panel.. Maybe by the time I am ready to assemble it there will be another option for me.
 
5. Not currently but this is a good idea. Are you suggesting a "fullscreen" mode? I think this is something we should add, triggered by script or button.

Yes, that was exactly what I was thinking. It would be nice to build up a workspace just for displaying.
I would love to have one for my fermentation room as well as for my Keezer. I could use real time data as a digital tap list and a complete replacement for raspberrypints. The modular nature of your program, lends itself for so many uses, just by adding another arduino.
 
I am sorry for all the questions, but will Brucontrol work on windows server 2016?
 
I'm working on my panel layout and as usual, space is becoming a premium.

What do you think about this relay board?: https://www.amazon.com/dp/B010URDEUK/?tag=skimlinks_replacement-20

It takes up half the space of a SPDT 8 relay board; 5a limit isn't an issue - nothing I'm going to switch has even close to that. The single throw is also not a concern, as I'm not planning on using the NC contacts anyway. I also like that the relays can be replaced if one fails. The only real issue I see is that the relays don't get an independent power supply - they use Mega's pins to provide power. According to the spec sheet, each relay uses 25ma. From what I can tell, the Mega's pins can handle up to 40ma each. Even if all 8 relays are on, that's only 200ma total draw off the Mega's internal 5v power supply.

Is there something that I am missing on this?

Thanks!
 
Last edited by a moderator:
Hi @Wizard_of_Frobozz...

I like that relay package a lot... but I think 25mA per I/O is pushing it. The nominal max current of the MEGA per pin is 20mA. The absolute max is 40mA, which basically means any higher and you likely risk damage to the chip.

So my guidance is this... if you don’t have a boatload more outputs which will draw current through the micro-controller, then go for it. Maybe drop a heatsink on top of the chip to help it cool off! Also, the less you have on at a time, the better.

If you do, you might consider a relay board with a transistorized front end. I have stacked 4-pack relay boards using threaded spacers and this dramatically reduces the footprint required.

Hopefully that provides some guidance. At the end of the day... if you cook a micro, it won’t cost you much to replace it!!

That said, you may want to weigh in on my next post...
 
Hi BC users and contributors,

We have been successfully implementing legacy micro-controller interfaces like the Arduino MEGA, but in order to utilize the newest boards and chip sets like the ESP32, we will need to adjust to their 3.3V interface voltages. So we have decided to put together a custom designed screw-shield which will make the interfacing easy. The big question is: do we create 5V interface shield, or do we go further and deliver a higher voltage & current board.

A interface would behave just like the current MEGA's 5V. This would allow a 3.3V interface to work with 5V devices like relays, SSRs, switches, flowmeters, etc. Both digital inputs and outputs would be 5V, including PWM. Analog inputs would probably maintain a 0-3.3V range. This would add moderate cost, but expect a screw shield in the neighborhood of ~$75.

A high power board would provide 12 or 24VDC outputs (user selectable), each of up to 2.5A (that's 2500mA, roughly 1000x more than currently available). Both digital inputs and outputs would be 12V, including PWM. These outputs would permit direct drive of valves, relays/contactors, solenoids, and other industrial level components. Analog inputs would probably maintain a 0-3.3V range. This would add more cost than the 5V board, probably in the neighborhood of ~$125. Inputs would

So... which one should we pursue? 5V is easy to integrate with a broad range of devices, but 12/24V may be a nice option for direct drive stuff. Right now we are leaning to the 5V interface, but would like to hear from this community. Ultimately, we may do both, but need to tackle one at a time.

Any feedback/thoughts are appreciated!!
 
Hi BC users and contributors,

We have been successfully implementing legacy micro-controller interfaces like the Arduino MEGA, but in order to utilize the newest boards and chip sets like the ESP32, we will need to adjust to their 3.3V interface voltages. So we have decided to put together a custom designed screw-shield which will make the interfacing easy. The big question is: do we create 5V interface shield, or do we go further and deliver a higher voltage & current board.

A interface would behave just like the current MEGA's 5V. This would allow a 3.3V interface to work with 5V devices like relays, SSRs, switches, flowmeters, etc. Both digital inputs and outputs would be 5V, including PWM. Analog inputs would probably maintain a 0-3.3V range. This would add moderate cost, but expect a screw shield in the neighborhood of ~$75.

A high power board would provide 12 or 24VDC outputs (user selectable), each of up to 2.5A (that's 2500mA, roughly 1000x more than currently available). Both digital inputs and outputs would be 12V, including PWM. These outputs would permit direct drive of valves, relays/contactors, solenoids, and other industrial level components. Analog inputs would probably maintain a 0-3.3V range. This would add more cost than the 5V board, probably in the neighborhood of ~$125. Inputs would

So... which one should we pursue? 5V is easy to integrate with a broad range of devices, but 12/24V may be a nice option for direct drive stuff. Right now we are leaning to the 5V interface, but would like to hear from this community. Ultimately, we may do both, but need to tackle one at a time.

Any feedback/thoughts are appreciated!!
This is a tough call, but I would lean towards the 12V it saves space and some money in relays. It would be nice if it was din mount and allowed for shields.

The 5V is great too....

Start from scratch build a Bruduino. Lol
 
Both is best!

I think one of the biggest barriers for people on this whole thing is the complexity of it all: 3.3v, 5v, 12v, etc. Designing a system requires a good understanding of how all this works and not everyone has the time or desire to learn it. Something that helps people overcome that complexity is a good thing for someone who is just starting out. This would probably mean focusing on 12v.

For me personally, I was initially a bit intimidated by it all but I’ve had a lot of fun figuring it out. I would lean towards 5v, just because I have already figured out how to get my relays, inputs, etc. working with it. I also think it leaves more freedom to build the system exactly the way I want it from scratch.

I see both sides to this. Simple encourages more people to jump into it, but more options means more ways to build your system. In the end, I think the complexity of automation like this should include a good understanding of how it works, so forcing people to learn it ensures the systems are safe. If you don’t know what you are doing, it can be dangerous and keeping it too simple could backfire because people just copied a set up vs. really knowing why it works.
 
I use craftbeerpi currently but am considering moving the brucontrol for more flexibility. I would like the option of both but that’s a lot of work to put together two products.
 
@BrunDog, You touched briefly on "other industrial-grade components," and that is why my preference would be for the 12/24VDC board. A glance through the catalogs of industrial suppliers like Phoenix and Finder show that there is plenty of stuff available to make a system as simple or complex as you'd like. I also agree with @Wizard_of_Frobozz in that a system should offer the opportunity to take a deep dive into automation, but that deep dive is certainly available at higher voltages.

In my mind, the 12/24 solution broadens the potential reach of your system to those seeking simplicity, and still offers plenty of capability and options for those looking to build their automation chops.

You build it, and I'll buy one.
 
I was having trouble with understanding how to integrate the feather at 3.3v and putting 5v devices into the circuit by means of a voltage divider. As a result, I bought a Mega and a 12v power supply to accommodate the 5v devices I am adding such as a flow meter, and motorized valves. If the 12/24v board can accommodate the three voltages, that would be the best.
 
Hi BrunDog,

I would like to be able to have a switch control each fermentor. Could you give me a example of a script for having a switch control a fermentor. I just don't want to have to turn off all the elements individually. I would like when "fermenter1switch" is off it disables "heat1" "cool1" and stops "Ferm1 Script" and when its on it enables "heat1 "cool1" and runs "ferm1 script"
 
Hi BrunDog,

I would like to be able to have a switch control each fermentor. Could you give me a example of a script for having a switch control a fermentor. I just don't want to have to turn off all the elements individually. I would like when "fermenter1switch" is off it disables "heat1" "cool1" and stops "Ferm1 Script" and when its on it enables "heat1 "cool1" and runs "ferm1 script"

Thank you for posting here so others can learn from it!

Here is the script... fairly straightforward. Hopefully it makes sense but feel free to ask for clarification anywhere.

Code:
[prep]
new bool scriptrunning            // create a flag so script is only started once
scriptrunning = false            // clear the flag (set it to false)
[loop]
if "Fermenter1Switch" State == true    // check to see if the switch is on
    "Heat1" Enabled = true            // if it is, enable the heat and cool
    "Cool1" Enabled = true
    if scriptrunning == false        // if flag is clear, start script and set flag
        start "Ferm1 Script"
        scriptrunning = true
    endif
else                        // otherwise, switch must be off
    "Heat1" Enabled = false            // disable the heat and cool
    "Cool1" Enabled = false
    stop "Ferm1 Script"            // stop the script
    scriptrunning = false            // clear the flag
endif

sleep 5000                    // wait 5 seconds bewteen switch checks
goto loop                    // go back to the 'loop' section start
 
Good question. I can't speak to that without looking into the chipset. It doesn't ring a bell offhand. The reason the chipset is important is because not all of them can receive iBeacon advertising packets, which the Tilt uses. Usually BLE (Bluetooth Low Energy) devices can, but not all of the code is exposed.

That said, we have made plans to incorporate the Adafruit BlueFruit as an add-on Bluetooth reader for non native bluetooth chipsets. We are working on the ESP32 first... then will add it. This will give you a choice, but may want to incorporate the ESP32's just for this purpose. They are cheap, err... inexpensive... at around $15 each, and you will be able to add them as additional interfaces.
 
Good question. I can't speak to that without looking into the chipset. It doesn't ring a bell offhand. The reason the chipset is important is because not all of them can receive iBeacon advertising packets, which the Tilt uses. Usually BLE (Bluetooth Low Energy) devices can, but not all of the code is exposed.

That said, we have made plans to incorporate the Adafruit BlueFruit as an add-on Bluetooth reader for non native bluetooth chipsets. We are working on the ESP32 first... then will add it. This will give you a choice, but may want to incorporate the ESP32's just for this purpose. They are cheap, err... inexpensive... at around $15 each, and you will be able to add them as additional interfaces.
yeah I ordered one a few days ago... if I add it as an additional interface how will it communicate with my fermentation panel mega without the pc running?
 
WHich did you order?
sorry esp32 board...https://www.ebay.com/itm/ESP32-Rev1-Development-Board-with-USB2Serial-Made-in-USA-Arduino-Programmable/262809348271?ssPageName=STRK:MEBIDX:IT&_trksid=p2057872.m2749.l2649

I actually ordered this a while back too which is probably useless...
https://www.ebay.com/itm/HM-10-CC2540-CC2541-BLE-Bluetooth-4-0-Serial-Wireless-Module-for-Arduino-iBeacon/162508058657?ssPageName=STRK:MEBIDX:IT&_trksid=p2057872.m2749.l2649

I can honestly just pick up an adafruit bluefruit module if these wont work. its going to be months before this is implemented anyway.
 
Last edited:
The ESP is good. We should have firmware out in a couple of weeks for it, including the Tilt support.

The other one... well, sit on it - you never know!
Thanks.

I guess my question is.. how to I get it to communicate with the mega controller that controls my glycol and heaters for the conicals? through the brucontrol GUI software and scripts? my concern is if the pc reboots or shutsdown will the script still run? It cant right because the arduinos arent directly linked?

or do I need to replace the mega outright with the esp32? i will need 3.3v controlled relay boards then right?

Sorry ive been so busy with opening the brewpub I havent been doing a good job of staying on top of this stuff as it progresses.
 
It would not communicate with the MEGA directly. Even if it did, the MEGA wouldn’t know what to do with the data currently. BruControl ties them together assuming you want the fermenters to adjust based upon Tilt data, so BC needs to be running to do that.

If your computer reboots make sure BC automatically starts. We will be adding that option but you can set it manually for now.
 
It would not communicate with the MEGA directly. Even if it did, the MEGA wouldn’t know what to do with the data currently. BruControl ties them together assuming you want the fermenters to adjust based upon Tilt data, so BC needs to be running to do that.

If your computer reboots make sure BC automatically starts. We will be adding that option but you can set it manually for now.
ok thanks, thats what I was thinking too. my current brewery pc reboots from time to time. (likely after an automatic update and a setting I can change)
 
Yeah turn that off.

How is the nano coming? What stage are you at? Opening date?
Its coming along slowly.. soo much to do. The FEDS changed a bunch of rules in january, We had to amend our federal license and then they informed us we couldnt be a microbrewery because we are serving from a walk in cooler (like 90% of the other microbreweries in the area) so we had to change to a brewpub more $$ we are now going to serve food and ny wines and ciders.
we are almost done with the 2 walk in coolers and working on a platform with a floor drain to brew on this weekend.

Hoping for late june for opening but I would be surprised if we make it. Its mainly just my business partner and I doing most of the work. havent even had time to brew in months.
 
Last edited:
OK HBT,

Warning... this will be a controversial post! Opinions are mine - take with a grain of salt!

One of the home brewery configurations still used in new builds is HERMs to perform mash temperature control. Conceptually, it doesn't make much sense to me: in order to heat liquid, you need to first heat other liquid. Why not just heat the liquid you want and be done? I believe in the "old days", an HLT was needed to heat water, and that HLT required a power circuit (element, SSR, contactor, PID, wiring, plugs, etc.). 30A breweries cannot run multiple elements simultaneously, and since that HLT was already there, the builder could just re-use that power circuit, hence running the mash liquid back through the HLT volume via HERMs coils.

This is of course why RIMs was created - but RIMs gets a bad reputation. If the brewer wants to run one, they need an additional power circuit to the HLT one, which adds cost, complexity, etc. That's where high power RIMs can come in... a full-power RIMs element can replace the HLT altogether and serve the function of heating strike water, maintaining mash temp, mashing out, and direct heat sparging. My personal rig uses a 5500 W element in the RIMs tube and employs a high/low relay to adjust its power between 1350 and 5500 W. It uses full power for strike water heating, mashing out, and direct heat fly-sparging and low power for mash temp steps and maintenance. Low power is used to protect the mash from the evil but mostly mythical "scorching" devil. I think that a simpler implementation of this can be used: either via software or hardware, or both.

Using software: all PIDs I am aware of have an option to limit the PID maximum output of an element. Theoretically, capping the max output of the PID to 25% during mashing will serve the same net function as a high/low relay. This can be done manually, or in BruControl, can be changed on the fly with a script command (e.g. "RIMs" MaxOutput = 25).

But what about hardware? There is no doubt that a 5500 W straight LWD (Low Wattage Density) element at 120 watts per square inch does not offer the same scorching protection as a ULWD (Ultra Low Wattage Density) element. I have personally not had any scorching in 25+ brews using this element, having applied full power to wort during mash out. But understandably many would be apprehensive.

All this said, I think a two-vessel RIMs direct heat fly-sparge system (aka 2VDS) is the best possible configuration. The hardware, space, and cost of the HLT and HERMs hardware is eliminated, accessory hardware like valves and tubing is reduced, 3 vessel benefits such as efficiency and clear wort are maintained, mash steps occur quickly and accurately independent of batch size, the brew day is faster and simplified, and control panels are no more complex than HERMs. The only complexity to implementing direct heat fly-sparging is the need to fix the incoming water rate. Here is a simple flow diagram:

2VDS.png


I am so convinced the world needs to move past HERMs, I am putting my money where my mouth is! I have had a custom RIMs tube element made, purpose suited for this application, which we are fondly calling "QuadZilla". This is a ULWD element assembly, especially made for high-power RIMs applications in brewing. The QuadZilla is an assembled four-pack of 304 stainless steel sheathed cartridge heaters welded in a 1.5" tri-clamp cap. Each heater provides 1375 W @ 240 VAC for a total power of 5500 W and the heat density is 61 watts per square inch (9.5 W/cm^2), which is equivalent to the 5500 W ripple elements used in home brew boil kettles. Now, brewers can build a RIMs tube and run it at full power without concern of scorching. Used vertically, there is no need for RIMs flow switches or flowmeters to halt power in case of a stuck mash. In addition, they can heat strike water, mashout, and direct heat fly-sparge very easily. See more here: http://brucontrol.com/buy/quadzilla/

QuadZilla_full.jpg


I have no intentions of offending lovers of HERMs here - one of the great aspects of our hobby is the different ways we approach making beer. But I strongly feel it is time to advance past the ways of old, in the same way I believe automation greatly improves our beer. I look forward to a healthy discussion and hope many others will see the benefits of a 2VDS configuration and this RIMs element. Special thanks to @augiedoggy for the general concept of cartridge heaters in RIMs applications.
 
Last edited:
Dang! That is one sweet heating element.

I assume that the ends of the heaters can handle direct contact with liquid, correct? A lot of lower end cartridge heaters don’t have fully sealed ends and can’t be immersed in liquid.
 
Back
Top