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.
I sorta found that before. The one I purchased said 400 clicks per litre. Math was easy. In fact, while having some fields properties in the Counter Input Element so that it could have a Volume Value would be nice, I played with the new Global Element and did the math in a looping script. I will have to verify that the flow rate does not effect the clicks. The flow meter is on the output side of a SS Ball Valve that is either on or off. I have yet to wire and try it as I am still in the wiring process for all my new BruControl toys. I am really looking forward to doing my first brew with the setup. Just have to get it all wired and the two Arduino in their enclosure.

I hooked mine up and blew through it and the rate worked and total worked, I have digiflow ones to compare it to, maybe put both in line and test with a bucket for a general calibration... I also have a G1/2 brass one from eBay that if it works good I will get a few more of.
 
I have 2 of the G12. I got some converters to 1/2 NPT but they leak under pressure if I do not allow flow.

The ones I got say to 100C. I am only going to measure water as I am not sure about cleaning. I certainly would not use them anywhere except on the Hot side of Wort.

If they are close in Volume Measurement, it can help a lot. The other day I forgot to close a valve and added some water to an almost finished 90 min boil. Had to boil longer and hop profile was changed and I had to add more Flavor Hops. It was an IPA so maybe just a little more bitter. Most of our best beers have included a gross error so maybe this one will too.

If I had had a flow meter, I could have added just enough to flush what I was flushing then shut the valve.
 
my error:

Why would you change the Refresh Multiple for a Counter Element (or any other Elements that has this property)? This is how often the Element is polled(my assumption in conjunction with the refresh interval {on the Interface} ?

In other words, if your Refresh Interval is 1 second (the default), and you change the Refresh Multiple to 60, the Counter would be polled every minute (60 x 1 second)?

Is there any correlation with the Sampling Period, or are they totally independent of each other?
I do not understand the "practical" use of this Refresh Multiple property.

Is there a good reason to have a higher refresh for any Elements?
Is this to help with something like a Fementation Log where you might want less precise data ( like the fridge example in the manual)? It also seems the max would be every 10 minutes (Refresh Multiple x Refresh Interval 60 x 10 seconds)

Does anyone use this Refresh Multiple property on an Element?

I do see the "need" for slower communications with a wifi connection to set the Refresh Interval higher.

The refresh multiple is how many interface refresh cycles occur per each update. The interface refresh determines the rate at which BC and the interface communicate. You can slow it down for devices you don’t need updated that often like refrigeration. This saves bandwidth and data points stored.

No correlation to sampling.
 
Counter as flow meters.

I have a hall effect flow meter that will put out a pulse for every revolution.

How do I use a Counter Element to figure the flow.

The choices of the Values for a Counter are

Count Value
Rate Value

I know that the Count Value can be turned into gallons using a formula based on counts per litre.

Mine says 400 counts per litre.

In my case the Formula would be

1 gal = 3.78541 x 400 Counts

Total Gals = Count Value/ 1514.164

So if I wanted 6.5 gallons, My Count Value would equal 9482. (small error as you cannot do half counts). Would be nicer if it read 6.5.

Would be nice to have a volume choice (litre or gals)

You would need to know the physical counts per litre for the meter. Since it resets when you disable the Counter, that would not be an issue.

What do you use the Rate Value for? Is that just not the speed of the flow and not a volume measure? I have never used a flow meter but have always wanted to measure my Strike and Sparge water into our MLTs.

Rate is the amount over time - so if connecting a flow meter, that is flow.

We don’t use defined units like quarts or gallons per hour because the calibration system allows you to resolve to any unit you like. You just need to determine the math, but it’s all multiplication so it’s not that difficult.
 
I have 2 of the G12. I got some converters to 1/2 NPT but they leak under pressure if I do not allow flow.

The ones I got say to 100C. I am only going to measure water as I am not sure about cleaning. I certainly would not use them anywhere except on the Hot side of Wort.

If they are close in Volume Measurement, it can help a lot. The other day I forgot to close a valve and added some water to an almost finished 90 min boil. Had to boil longer and hop profile was changed and I had to add more Flavor Hops. It was an IPA so maybe just a little more bitter. Most of our best beers have included a gross error so maybe this one will too.

If I had had a flow meter, I could have added just enough to flush what I was flushing then shut the valve.

I only use for water, and try to do cool, so the cooling side of a heat exchangers is where I put it.. the brass G1/2 ones will seal if you use about 7 wraps of teflon tape and 20lb-ft of torque.. I tried ordering a digiflow with 3/4 Garden hose thread, but it came G3/4 <expletive> I wish good ones for us were made in actual GHT or in 3/4 TC fittings.. The adapters quadruple the cost of implementing... If you want to be anywhere near accurate, you should be in the middle of the range, which for me is the 1/4" NPT with "0.16 to 2.1 GPM", (I think it reads 2.7 max) but I am sure I will break the little plastic thing.
 
I am not able to install Firmware 45 on my Robodyn Mega 2560. It connects to BruControl as com 4 as a serial Connection.
Firmware45_1.png

Termite fails to install Firmware
no firmware 45-2.png
 
I am not able to install Firmware 45 on my Robodyn Mega 2560. It connects to BruControl as com 4 as a serial Connection.

I also use the RobotDyn MEGA aand had the same issue but resolved by shutting down the BruControl software first, then load the firmware V45

****Sorry just read what @clearwaterbrewer posted before I posted**** Try that and see if it resolves the issue. :yes:
 
Last edited:
I also use the RobotDyn MEGA aand had the same issue but resolved by shutting down the BruControl software first, then load the firmware V45

****Sorry just read what @clearwaterbrewer posted before I posted**** Try that and see if it resolves the issue. :yes:
Yep. That fixed it. As far as the firmware. Now to try the Networking. BruControl is still "off"
 
Which brings up another point. Can you Flash and Arduino over Ethernet or do you always have to use the USB. I find it cumbersome to hook up a USB in the Enclosure so I am just going to leave them connected to a USB powered hub that I can plug into when I need to Flash. One of the Mega(s) had a micro USB that fell off. Unfortunately, it was the one from BruControl and he nicely soldered the headers. I have ordered a Micro USB female and will try to replace it. One of the Pins broke on the OEM one so I cannot just re solder.

Network based FW updating is something we would love to have across the board, but right now the only microcontroller board that can handle it is the ESP32. Two things are needed: An interface which does not erase it's network settings upon new FW and the memory to handle two copies of FW onboard.
 
I am not able to install Firmware 45 on my Robodyn Mega 2560. It connects to BruControl as com 4 as a serial Connection.
View attachment 627830
Termite fails to install Firmware
View attachment 627831

Just want to chime in here for future learning... in this case, BC was communicating with the interface so it held the COM port (COM4) open. To free it, uncheck the 'Enabled' check box on the Settings... Interfaces tab for that interface. It will suspend communications and free up the port. That will allow you to update the FW, then you can re-enable it. This saves the headache of shutting down BC.

Thanks to @clearwaterbrewer and @Tartan1 for giving guidance on this.
 
Networking I had to do with .v43 firmware package..
Network based FW updating is something we would love to have across the board, but right now the only microcontroller board that can handle it is the ESP32. Two things are needed: An interface which does not erase it's network settings upon new FW and the memory to handle two copies of FW onboard.

Maybe a way to use a ESP32 connected via SPI or something to do the programming? I remember using a Pi ZeroW to program my SonOffs for Tasmota for CBP3..
 
That one has no Wi-Fi.

Oh man... thought it was perfect for what you were looking for! I have one on the way anyway! We've tested that screen before... it is slow to update so opted against, but we'll test with the ESP32 and see what we get.
 
The refresh multiple is how many interface refresh cycles occur per each update. The interface refresh determines the rate at which BC and the interface communicate. You can slow it down for devices you don’t need updated that often like refrigeration. This saves bandwidth and data points stored.

No correlation to sampling.


Ok I think I have it. You might want to update the Counter Total every 10 seconds or so, so the multiple would be 10 (assuming the Interface Refresh is set to 1 second). If you wanted it updated every second , the leave as 1.

The Sampling Period could be set to something like 10. That would take the total pulses in the sampling period and divide by 10 to get the Rate per second (done internally in BruControl. That might give you a decimal flow rate. I guess I need to hook it up and play to see how either affect anything. I would also assume that if the plumbing after the Flow Meter changes, the volume may also change (or not). Will test filling different things.
 
Correct on both.

If your pulse rate is consistent (in your case, flow), then there will be no difference changing the Sampling Period. But if your flow tends to vary rapidly (maybe bubbles or gunk like hops or trub) and you do not want to either see or script off a rate that changes from reading to reading, then extending sampling period longer will help smooth it out. The trade-off is responsiveness vs. smoothness. I'd suggest starting with something small like 2-3 seconds, then extend if needed.
 
If I have interfaces (a MEGA and an esp8266) that have v43 firmware on them, and they aren't particularly easy to get to (bad design on my part!), is there a compelling reason to dig them out and upgrade them to v45?
 
Thanks BrunDog, I'll get in there and update them. For future enclosures, I'm going to have to remember to keep an access port for the USB interface to the micro.

On a separate note, I got some ESP32 DevKit v1 boards to replace the problematic ESP8266 configuration I was using. To people that might use these on GPIO2, know that there is a 10K resistor to GND on the board. So, if you want to use GPIO2 as a counter and need a voltage divider down from 5V to 3V for the signal from the flow sensor or something, you need to account for this.

I found out when I connected my old divider (100k total resistance) to it and got <1V of signal from the flow sensor. I ended up just using a series 5k resistor with the signal from the flow sensor and the onboard 10k as the divider.
 
Do we know roughly what the power consumption is for the BruControl TF-3, RP-3 (w/4 RTDs), and the AA-1 boards? I am just trying to ensure I understand my power consumption for 3.3V as I contemplate powering these via the internal regulator on the Grand Central M4 that will replace my MEGA 2560.
 
Good question. The TF implements 20k resistors net, so that’s 1.65 uA per channel, or 1 mA in total. The RP is passive so it’s the power requirement of the amplifier board, which IIRC is only a mA or two each. The AA uses an op-amp which draws less than 1mA. It will power up to 75mA per channel but that’s passthrough and depends on the downstream device it is powering.

So all in all, these aren’t really of any concern. I would be more concerned with the outputs from the GC powering relays etc.
 
Easy enough, thanks BrunDog.

Is the GC any different in terms of how concerned one should be about powering relays compared to the MEGA 2560? I actually don't power the relay boards I use from the controller but a rather from a seperate power supply to remove that concern (if that is the concern you are referring to).
 
To expand on what I found a little using the flow meter and GPIO2 on an ESP32, the flow meter I'm using has a weak pull up (10k) and a strong pull down (35ohms) as its logic output. Therefore, the onboard 10kOhm pull down in the ESP32 won't allow for the pin to ever go to full scale which resulted in some real noise/false triggering problems. There is also an LED on that pin that lights when the pin is high.

Here is the flow sensor I'm using:
https://www.amazon.com/gp/product/B00YOKWBKO/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

The solution I am using (at least for now) is to buffer the output of the flow meter. The "back of a business card" schematic shows what I used. Basically just using a PNP transistor as a drive element and level shifter from 5V to 3.3V. Fortunately with these sensors all I care about is pulses since there is a signal inversion introduced by this circuit.
IMG_0847.jpg
 
The Grand Central is certainly different. There are trade-offs for the processor speed! It’s 3.3 V architecture so interfacing with hardware takes attention. As you said, relays need to have front ends that will activate with 3.3V and will not draw more than 5 mA (that’s a bit conservative but should be a design goal). For the record,
you should never power the relay coils from the interface’s power regulator. Relay boards’ front end circuitry draws very little power but switches the relay incoming power to switch the coils (relay switching a relay, so to speak). SSR’s that are being activated by the GC should also use low current - some don’t and will be borderline.

No input to the board can exceed 3.3V, so any 5V or higher signal to the board needs be divided down (sensor, flowmeter, etc.).

The power supply to the board should not be 12V if avoidable to save its regulator from needing to burn off that voltage - 5V might work.
 
I did a major script re-write and redesigned my workspaces with v1.1 release. I'm loving some of the new features (LEDs, globals, subroutines, etc.). I thought I would share some things I would like to see for your consideration (although I can imagine these may not be very high priorities).

1. I wish the buttons and/or switches could look like LEDs as well. I've actually faked this by using alarms instead. I make an alarm look like an LED, use a custom "click" sound not looped and set colors for on/off. I've also used a global boolean to display as a LED to act like switch for cases where I want the 2-step validation.

2. The other thing I've noticed is that my brew script (several hundred lines of code) could be so much more succinct if there were vectors. I find that I've got a bunch of loops (mash, hops, etc.) where I can't make an effective use of subroutines because each step has its own variables. Mash_Temp(i), Mash_Time(i), Hop_Time(i), etc. There's lots of redundant code that could go into routines easily if we could use vectors for these variables and increment the indices in between loops. There's certainly a way to do it without this but I find it requires a whole bunch if nested if statements to assign the right values between loops that I end up giving up.

3. I'll echo the name alias comments others have made above.

4. Finally, I wish globals had the same functionality as variables for inline math, concatenation, etc. This would avoid needing new in-script variables on the fly that really add no value. More importantly, I can never remember which ones can do what and then I waste more time debugging because the difference is not intuitive to me.

5. I've got a lot of scripts now... it would be nice if they could be structured/organized in folders. Not suggesting their functionality should be different... just a way to organize them in the list.

6. The ability to copy/paste an element would be great - just add "(1)" or "(copy)" to the name and keep everything else the same. I guess you'd also have to ask for the new port if it were a device element.

7. On email notifications from alarms: First, I would much prefer text messages to my phone rather than email. Second, it would be great if info could be passed into the email rather than just a generic email. The email or text could include a string.

Let me reiterate that these would be nice-to-have... nothing essential. Love the application. Haven't been this excited about brewing in years!
 
To expand on what I found a little using the flow meter and GPIO2 on an ESP32, the flow meter I'm using has a weak pull up (10k) and a strong pull down (35ohms) as its logic output. Therefore, the onboard 10kOhm pull down in the ESP32 won't allow for the pin to ever go to full scale which resulted in some real noise/false triggering problems. There is also an LED on that pin that lights when the pin is high.

Here is the flow sensor I'm using:
https://www.amazon.com/gp/product/B00YOKWBKO/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

The solution I am using (at least for now) is to buffer the output of the flow meter. The "back of a business card" schematic shows what I used. Basically just using a PNP transistor as a drive element and level shifter from 5V to 3.3V. Fortunately with these sensors all I care about is pulses since there is a signal inversion introduced by this circuit.
View attachment 628379

Curious... why not use a different counter pin?
 
I did a major script re-write and redesigned my workspaces with v1.1 release. I'm loving some of the new features (LEDs, globals, subroutines, etc.). I thought I would share some things I would like to see for your consideration (although I can imagine these may not be very high priorities).

1. I wish the buttons and/or switches could look like LEDs as well. I've actually faked this by using alarms instead. I make an alarm look like an LED, use a custom "click" sound not looped and set colors for on/off. I've also used a global boolean to display as a LED to act like switch for cases where I want the 2-step validation.

2. The other thing I've noticed is that my brew script (several hundred lines of code) could be so much more succinct if there were vectors. I find that I've got a bunch of loops (mash, hops, etc.) where I can't make an effective use of subroutines because each step has its own variables. Mash_Temp(i), Mash_Time(i), Hop_Time(i), etc. There's lots of redundant code that could go into routines easily if we could use vectors for these variables and increment the indices in between loops. There's certainly a way to do it without this but I find it requires a whole bunch if nested if statements to assign the right values between loops that I end up giving up.

3. I'll echo the name alias comments others have made above.

4. Finally, I wish globals had the same functionality as variables for inline math, concatenation, etc. This would avoid needing new in-script variables on the fly that really add no value. More importantly, I can never remember which ones can do what and then I waste more time debugging because the difference is not intuitive to me.

5. I've got a lot of scripts now... it would be nice if they could be structured/organized in folders. Not suggesting their functionality should be different... just a way to organize them in the list.

6. The ability to copy/paste an element would be great - just add "(1)" or "(copy)" to the name and keep everything else the same. I guess you'd also have to ask for the new port if it were a device element.

7. On email notifications from alarms: First, I would much prefer text messages to my phone rather than email. Second, it would be great if info could be passed into the email rather than just a generic email. The email or text could include a string.

Let me reiterate that these would be nice-to-have... nothing essential. Love the application. Haven't been this excited about brewing in years!

Appreciate the feedback! On #7, you should be able to email to text via your carrier. For example, for ATT, format is #######@txt.att.net.
 
I need four counters, so I need all of them to work. Have you guys considered doing firmware variants that have different options (I know, that would be a big headache). So if someone had flow sensors in a keg fridge and had 6 kegs, they could do it without needing 2 controllers? Not that 2 controllers is a big deal.
 
We can just add more counters. Would have no concern doing so for the fast processor models (Feather M0, ESP32, Grand Central). Would be hesitant to add much more to the MEGA. Will do it on the next update.

That would be awesome, thanks!
 
Back
Top