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.
So, I'm tackling the data exchange design on my build and have the basic hang of it using Node-Red and watching Bryan's Youtube several times. I'm having trouble with time. BeerSmith seems to use minutes for it's time related values. I'm looking for help getting the change node (Beer Parameters node in Bryan's example) properly formatted for acceptance into BruControl. If anyone has tackled this I would love some suggestions.

Thanks,
Mike
 
So, I'm tackling the data exchange design on my build and have the basic hang of it using Node-Red and watching Bryan's Youtube several times. I'm having trouble with time. BeerSmith seems to use minutes for it's time related values. I'm looking for help getting the change node (Beer Parameters node in Bryan's example) properly formatted for acceptance into BruControl. If anyone has tackled this I would love some suggestions.

Thanks,
Mike

For the example of boil time:

Use a change node to parse the messages.

Set - msg.BoilTime
(J: Expression) ($substringBefore(msg.payload.RECIPES.RECIPE.BOIL_TIME, ".")

Then create a function node and use the below code to format it in the proper syntax for BC.

Code:
if(msg.BoilTime < 60){BoilTime = "00:"+msg.BoilTime}
if(msg.BoilTime >= 60){
    msg.remainder = msg.BoilTime - 60
    BoilTime = "01:"+msg.remainder
}

If you have boil times longer than 2 hours you will need to add additional logic and if statements.

Finally, bring it into BC with a Global element set as time.

Hope that helps.

Joe
 
Initial look at the dual-vessel Workspace for the UniFlex. Need to add an alarm and maybe an I/O bank... plus the colors are a little cartoony but it needs to be clear and easy, so this is basic start. Suggestions appreciated!

We would provide to users to get started, then they can modify as they see fit. Sincere thanks to @DieDie_Beerery_Beerery for the background graphic!

View attachment 683402!
@Die_Beerery what software are you using to create your backgrounds, they look great!
 
I'm going to be checking a new batch of DS18B20 sensors (10 total). Since I use a single physical port for all 10 sensors is there a convenient way to differentiate them so I can mark them for later reference? I plan to record a baseline temp for each one in a spreadsheet and will physically mark the sensor for reference....I use to use the last 4 values of the sensor ID but it isn't exposed in BC.

Thanks
 
Unfortunately, no (not yet anyway). We never designed it for hot swapping... so identifying by address is not possible, only by an index. That index will change when the sensors are added or removed. I'd suggest you leave them all connected and only communicate with the ones you want at any time.
 
Have another data exchange question. I noticed that the BeerSmith XML does not have the Post Boil Volume or Pre Boil Gravity data (or a lot of other data). For post boil I just brought the evaporation rate down and calc'd it on the BC side. Am I missing a way to get more data out of BeerSmith? The pre boil gravity I just hand entered.
 
Correct, for some reason it is not part of the BeerXML standard, so we have to calculate it based on other data that is included.

In the function block, add these two lines.

Code:
PostBoilVolume = (BatchSize+KettleLoss)*1.04
PreBoilGravity = (((((PostBoilGravity-1)*1000)*(BatchSize+KettleLoss))/BoilVolume)/1000)+1

Obviously, make sure you are bringing in PostBoilGravity, BatchSize, KettleLoss and BoilVolume from the BeerXML.

Cheers,
Joe
 
Correct, for some reason it is not part of the BeerXML standard, so we have to calculate it based on other data that is included.

In the function block, add these two lines.

Code:
PostBoilVolume = (BatchSize+KettleLoss)*1.04
PreBoilGravity = (((((PostBoilGravity-1)*1000)*(BatchSize+KettleLoss))/BoilVolume)/1000)+1

Obviously, make sure you are bringing in PostBoilGravity, BatchSize, KettleLoss and BoilVolume from the BeerXML.

Cheers,
Joe
What's that magic factor '1.04' ? Spillage? Samples? Quarts to liters?
 
Thanks, I see, so one of the numbers is measured close to boiling, and the other close to 4C/40F.
 
I have a scripting question for all you experts out there. I have seen where I can take a datetime object and add or subtract a value to add or subtract a day or hour to get a new datetime value. I have not been able to reverse this where I can find the difference between two datetime values and use that difference value to set a timer element. Is this possible within the BruControl scripting language? Thanks for the help.
 
Question on AREF, if I am going to power the TF-4 with a separate 5VDC supply, should AREF be tied to that supply rather than the 5V pin on the MEGA?

Thanks

I would power it off the MEGA. The thermistors don’t use much power.

if you want to power separately anyway or for noise management, then yes, tie that PS 5V to AREF.
 
My experience with the RTD amplifier boards is similar to @clearwaterbrewer in the fact that I suspect SPI bus or general chip power issues can also cause these spikes. I built a panel to use 4 amplifier boards and soldered up some headers on a perf board to mount the amplifier boards. I also had a local LCD display on this panel. When I powered all the 5V components from the mega's onboard LDO I would get similar temp spikes when I enabled and wrote to the display. I got similar spikes when one of my fridges would turn on/off in the garage. I changed the power for the amplifiers to a separate 5V supply and that fixed the LCD issue, but not the fridge spikes.

My main brew panel that is also mounted in my garage does not have any of these issues, but I use thermistors in that panel. I have found that as long as you use a 1% or better 10K reference resistor and some caps for filtering that thermistors are accurate within their 1% specification without having to individually calibrate each sensor/circuit. The biggest ***** is calculating the steinheart coefficients, but I found a small script in the interwebs that will calculate those for you from the resistance/temp table in the thermistor's datasheet.

I still believe software is also good 'last resort' to handle the spikes, or drop-outs... I am not in a rush to have it implemented, but it would be nice to add someday, throw out values that are way, way off using a well-accepted math formula...
 
Because the new UniFlex Controller has no USB port, we needed a way to enable users to setup their networks without the serial terminal. So we created a mode where its ESP32 will become a Wi-Fi access point. Once connected to it, the user can open a web page to enter the parameters. Once saved, the ESP will boot using those settings going forward. This plus Over-the-Air firmware updates, and the ESP32 never needs to be connected by USB other than the first firmware install.

This will be standard in the FW going forward for all ESP32, starting with version 45K, which we’ll release soon.

Not the most beautiful of pages, but we need to reserve memory for function, not looks!
ED39261E-1EC1-4DCE-9F75-E040FBF2EF5A.png
 
While I am least a year away, I think it is start to plan. Since I am starting fresh, any comments on best temperature probes.

BCS 10K NTC Type

RTD 100

RTD 1000

One Wire

Pros and Cons:

I have been following the discussions regarding the RTD amps.
 
A year?!? Look what we added because of your requests!

View attachment 685767
Looks great. Would still be great to have a Path that could be a script property:

MyAlarm1 soundfilepath1 == "c:\brucontrol\media\alarms\myAlarmHops1.wav"

That way you could have unlimited alarms sounds for the same alarm.

You could do the same for alarm images.

I use "text to speech" to create unique alarm sound files.

It would make the program much better if you had unlimited sound or image files via a local path rather than the three limit. You would only need to add the script property for File1 or Background1.

I hope it is not a full year. I have just about cleaned up the burned down Barn. I found my Tilt and while the outside storage tube was melted on the ends, the Tilt may work. Need to get an ESP 32 to test.
 
It would make the program much better if you had unlimited sound or image files via a local path rather than the three limit. You would only need to add the script property for File1 or Background1.

Appreciate the feedback, but respectfully, I don't agree. There is a balance between ease of use and excessive options.
 
While I am least a year away, I think it is start to plan. Since I am starting fresh, any comments on best temperature probes.

BCS 10K NTC Type

RTD 100

RTD 1000

One Wire

Pros and Cons:

I have been following the discussions regarding the RTD amps.
Here's a screen grab of my NTC and 1-wire sitting side-by-side......NTC is blue:
Graphs.JPG
 
While we are sharing graphs,I had to post this... doing a video for the UniFlex, I set up a test bed using a 5500W heater in a small vessel, with no recirculation. I noticed an interesting oscillation develop when using default PID parameters. This was likely due to a lag that occurred between the heated, rising water reaching the probe mid-vessel. Did some manual tuning, and after about 5 iterations dialed it in quite a bit. This required lowering the Kp and integral windup (Max Integral %), and increasing the Kd quite a bit.

I know there have been requests for auto-tuning, but since 1. we aren't flying aircraft or rockets, and 2. we have brains... my feeling is we should be able to manually tune most brewing applications. I'm going to try a deadband on this and see what happens.

1592626812767.png
 
While we are sharing graphs,I had to post this... doing a video for the UniFlex, I set up a test bed using a 5500W heater in a small vessel, with no recirculation. I noticed an interesting oscillation develop when using default PID parameters. This was likely due to a lag that occurred between the heated, rising water reaching the probe mid-vessel. Did some manual tuning, and after about 5 iterations dialed it in quite a bit. This required lowering the Kp and integral windup (Max Integral %), and increasing the Kd quite a bit.

I know there have been requests for auto-tuning, but since 1. we aren't flying aircraft or rockets, and 2. we have brains... my feeling is we should be able to manually tune most brewing applications. I'm going to try a deadband on this and see what happens.

View attachment 685778
What type of sensor was this and what did you end up with for Kp, Ki, and Kd?
 
While I am least a year away, I think it is start to plan. Since I am starting fresh, any comments on best temperature probes.

BCS 10K NTC Type

RTD 100

RTD 1000

One Wire

Pros and Cons:

I have been following the discussions regarding the RTD amps.



RTD's -
Pros: accurate
Cons: They are not (cannot be) calibrated from the factory, calibrating BruControl to them is more difficult that it seems like it should be. They have downward spikes that makes triggering difficult without writing intermediary scripts.

1-Wire -
Pros: Easy to implement multiple proves without additional hardware
Cons: Not accurate enough and lack address permanence and manual designation in BruControl.

Tilt Hydrometer:
Pros: work great inside a fermenter
Cons: The resolution is horrible and only does 1.0 degrees F. BruControl implementation is painfully slower than the Tilt App or TiltPi program that reads every second. BruControl has no method to smooth out erroneous readings, ideally, it would read and display the user's choice of either the instantaneous reading or the average of the last 10 readings, and graph every 15 minutes to save datapoint memory.



I can say that if they made a 1-wire with the resolution of the RTD, at a cost of less than double of a DS18B20, that worked with BruControl, I would throw all my sensors in the damn trash and completely switch out...... it looks like post 3989 says BruControl uses 11 bit on the 1-wire, whereas 12 bit is what my ESP32/MAX31865/RTD has I guess, so maybe it is good enough... I thought the difference was at least 2 bits.. how much overhead would giving the option for 12 bit give?
 
........
I can say that if they made a 1-wire with the resolution of the RTD, at a cost of less than double of a DS18B20, that worked with BruControl, I would throw all my sensors in the damn trash and completely switch out...... it looks like post 3989 says BruControl uses 11 bit on the 1-wire, whereas 12 bit is what my ESP32/MAX31865/RTD has I guess, so maybe it is good enough... I thought the difference was at least 2 bits.. how much overhead would giving the option for 12 bit give?

From what I understand it is the first bit that is dropped for 11-bit resolution.....that is the 2^-4 bit. Accuracy is +- 0.5C (0.9F) so it doesn't seem that resolving out to -4 vs -3 would make much difference. Our critical temperature measurement is mash temp in brewing so I guess the question is, is +- 0.9F accurate enough?

RTD's are around 0.1C (0.2F) and I guess the challenge is to properly calibrate it so the precision is correct.

A 1% NTC provides +- 0.5C from 0 - 40 and +- 1.0 from -40 to 80. So in the mash temp range, NTC's are probably the least desirable.
 
RTD's -
Pros: accurate
Cons: They are not (cannot be) calibrated from the factory, calibrating BruControl to them is more difficult that it seems like it should be. They have downward spikes that makes triggering difficult without writing intermediary scripts.

1-Wire -
Pros: Easy to implement multiple proves without additional hardware
Cons: Not accurate enough and lack address permanence and manual designation in BruControl.

Tilt Hydrometer:
Pros: work great inside a fermenter
Cons: The resolution is horrible and only does 1.0 degrees F. BruControl implementation is painfully slower than the Tilt App or TiltPi program that reads every second. BruControl has no method to smooth out erroneous readings, ideally, it would read and display the user's choice of either the instantaneous reading or the average of the last 10 readings, and graph every 15 minutes to save datapoint memory.



I can say that if they made a 1-wire with the resolution of the RTD, at a cost of less than double of a DS18B20, that worked with BruControl, I would throw all my sensors in the damn trash and completely switch out...... it looks like post 3989 says BruControl uses 11 bit on the 1-wire, whereas 12 bit is what my ESP32/MAX31865/RTD has I guess, so maybe it is good enough... I thought the difference was at least 2 bits.. how much overhead would giving the option for 12 bit give?

Not sure what you mean calibrating is more difficult than they should be? Have you ever used the Lookup Table? Also spikes are a hardware problem - these are collections of noise that the builder needs to manage/suppress. We are building in some aberrant rejection - this isn't as easy as it sounds, because legacy reads need to be maintained. Stay tuned on this, but in the meantime, address any hardware issues. We've discussed 1W addresssing and will add it at some point. You are correct that we need to fix the error readings on the Tilt!

Gotta remember that 1W sits in the middle of the good/fast/cheap triangle - you can't have all three. We picked 11 bit for a good combo of speed and values, but keep in mind that the accuracy does not go up with higher resolution, just the reported values.

I think thermistors get a bad rap sometimes... I've been happy with mine, which are 0.5% Cantherm MF51E's.
 
From what I understand it is the first bit that is dropped for 11-bit resolution.....that is the 2^-4 bit. Accuracy is +- 0.5C (0.9F) so it doesn't seem that resolving out to -4 vs -3 would make much difference. Our critical temperature measurement is mash temp in brewing so I guess the question is, is +- 0.9F accurate enough?

RTD's are around 0.1C (0.2F) and I guess the challenge is to properly calibrate it so the precision is correct.

A 1% NTC provides +- 0.5C from 0 - 40 and +- 1.0 from -40 to 80. So in the mash temp range, NTC's are probably the least desirable.

according to the docs, RTD is 12 bit, and that is only that one bit different, and RTD is for sure good enough for mash temps, not sure what is actually going on inside BC, but I got MUCH better resolution than 0.9F, my 'steps' were 0.13 degrees F, and RTD was 0.06 degrees F, which makes perfect sense with 11-bit vs 12-bit...
https://www.homebrewtalk.com/thread...omation-software.624198/page-100#post-8751869
 
Last edited:
Not sure what you mean calibrating is more difficult than they should be? Have you ever used the Lookup Table? Also spikes are a hardware problem - these are collections of noise that the builder needs to manage/suppress. We are building in some aberrant rejection - this isn't as easy as it sounds, because legacy reads need to be maintained. Stay tuned on this, but in the meantime, address any hardware issues. We've discussed 1W addresssing and will add it at some point. You are correct that we need to fix the error readings on the Tilt!

Gotta remember that 1W sits in the middle of the good/fast/cheap triangle - you can't have all three. We picked 11 bit for a good combo of speed and values, but keep in mind that the accuracy does not go up with higher resolution, just the reported values.
no, I have not looked at lookup tables... manually editing tens or hundreds of values for each thermometer probe sounds daunting...


YES, spikes(dropouts actually) are a hardware problem, but they exist in every form of communication, can you imagine the uproar if Netflix shut off your show because the network dropped a packet... that is what happens if you have a script look for a temp to be below a certain value using RTD... AND, you are not getting off that easy :cool: ... right from the manual:

Code:
This averaging is performed for digital smoothing of the samples, which functionally reduces
noise common with analog devices and circuitry. Therefore, for example, with these default
settings, a new analog voltage measurement will be taken twice a second, and the resulting
average will be equal to 75% of the existing average and 25% of the new sample. If the current
sample needs be displayed, the ‘Avg Weight’ should be set to 100%. High impedance sensors
such as RTDs are mildly prone to noise, so an average weight such as 75% or more can be used

I am going to say that the smoothing algorithm needs improvement.... When the input is missing, instead of slamming to absolute zero, maybe just keep the same value?
 
according to the docs, RTD is 12 bit, and that is only that one bit different, and RTD is for sure good enough for mash temps, not sure what is actually going on inside BC, but I got MUCH better resolution than 0.9F, my 'steps' were 0.13 degrees F, and RTD was 0.06 degrees F, which makes perfect sense with 11-bit vs 12-bit...
https://www.homebrewtalk.com/thread...omation-software.624198/page-100#post-8751869

Keep in mind that resolution and accuracy are two different animals. Reporting more resolution of an inaccurate value might make us feel good, but it's just trash. For example, if the temp was actually 152.3 and I told you it was 152.4, then my friend said, "no, its 152.765". The friend sounds smarter, but is more wronger.
 
no, I have not looked at lookup tables... manually editing tens or hundreds of values for each thermometer probe sounds daunting...


YES, spikes(dropouts actually) are a hardware problem, but they exist in every form of communication, can you imagine the uproar if Netflix shut off your show because the network dropped a packet... that is what happens if you have a script look for a temp to be below a certain value using RTD... AND, you are not getting off that easy :cool: ... right from the manual:

Code:
This averaging is performed for digital smoothing of the samples, which functionally reduces
noise common with analog devices and circuitry. Therefore, for example, with these default
settings, a new analog voltage measurement will be taken twice a second, and the resulting
average will be equal to 75% of the existing average and 25% of the new sample. If the current
sample needs be displayed, the ‘Avg Weight’ should be set to 100%. High impedance sensors
such as RTDs are mildly prone to noise, so an average weight such as 75% or more can be used

I am going to say that the smoothing algorithm needs improvement.... When the input is missing, instead of slamming to absolute zero, maybe just keep the same value?

Lookup tables will interpolate in between points. The more points you add, the more accurate it will be. You can just add, say zero degrees and 212 degrees... everything in between is linearized. But if you add more points, you get more accuracy if the calibration is not linear... which it really never is.

You quoted the Analog Input smoothing algorithm. This doesn't apply to RTD reads. That said, it probably should! Actually, we should add a "rejection" field that allows you to define that any reading outside of a historic range gets dumped. The danger here is that if the rejection is set tight, and an actual rapid change occurs, the recording will effectively stop.
 
Last edited:
according to the docs, RTD is 12 bit, and that is only that one bit different, and RTD is for sure good enough for mash temps, not sure what is actually going on inside BC, but I got MUCH better resolution than 0.9F, my 'steps' were 0.13 degrees F, and RTD was 0.06 degrees F, which makes perfect sense with 11-bit vs 12-bit...
https://www.homebrewtalk.com/thread...omation-software.624198/page-100#post-8751869

My 11 bit vs 12 bit and 0.9F accuracy were all in relation to 1% 1-wire sensors......your numbers are right inline with RTD accuracy. The difference between 1-wire and RTD is one order of magnitude (1.0C vs 0.1C) but the number of bits won't change that, accuracy is not dependent on the number of bits.
 
I understand accuracy and resolution.. I do have an electrical engineering degree... I am solely worried about resolution here, as accuracy depends on individual components. If I mentioned 'accuracy'(I do not think I did), I apologize.

My 1-wire probes right now on my live system have a RESOLUTION of about .22 degrees F. (three live 1-wire probes are going back and forth between 86.00 and 86.22, another 86.67 to 86.89, and 86.90 to 87.12. this RESOLUTION is not good enough for some things... I can work on accuracy and repeatability if RESOLUTION is better. I would give my current RTD values, but when I rebooted the bc server for a windows update, the ESP's did not reconnect...

the ACCURACY, out of the box, without a bunch of hassle, lookup tables or offsets and multipliers, is horrible with even quality RTD's, likely due to the MAX31865, even the genuine adafruit ones... let's just say that the 1-wire is NOT 10 degrees off at the boiling point of water... it is 212 or 213... every... single.... one.... I sat for 3 hours trying to get 4 RTD's to be tuned to match a NIST calibrated glass thermometer and posted pics here it was horrible......
 
Last edited:
I get wanting better resolution. When I worked as a commercial brewer our brewhouse displays and the vessel displays only read to the nearest degree. When I have info to 10^-1 I just use it as a trend indicator.
 
Back
Top