• Please visit and share your knowledge at our sister communities:
  • If you have not, please join our official Homebrewing Facebook Group!

    Homebrewing Facebook Group

BruControl: Brewery control & automation software

Homebrew Talk

Help Support Homebrew Talk:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
This is a fantastic idea but probably not possible. The hydrostatic pressure sensor you would need would probably only need to be ~2 psi. Spunding is I think ~20+ psi, which means you would need a sensor that can the highest possible pressure, which would give fairly poor/inaccurate resolution at fill pressures.
 
It’s easily accomplished by a higher pressure sensor in the top say T’d off the blow off/prv, and and a more precise liquid (0-10kpa) in the bottom. I use both in my brewery.
IMG_3855.JPG

Kettle pressure is a higher pressure sensor and kettle volume is 0-10kpa
I have a spunding setup as well
View attachment 618885
 

Attachments

  • IMG_3854.JPG
    IMG_3854.JPG
    571 KB
Last edited:
Tested this and confirmed. It's related to the if/endif block. The call/return works outside the block, not that this does your script and intention any good! This will be addressed in an upcoming update (not today's, sorry).

Thanks for the confirmation.
 
It’s easily accomplished by a higher pressure sensor in the top say T’d off the blow off/prv, and and a more precise liquid (0-10kpa) in the bottom. I use both in my brewery.
Kettle pressure is a higher pressure sensor and kettle volume is 0-10kpa
I have a spunding setup as well

Do you mind sharing the specs of your liquid level sensor? I'm assuming its something greater than the standard 2x pressure before damage can occur?
 
All,

We posted an update to the v1.1 Release Candidate (v1.0.1.12). I think this is getting pretty close. Fixes in this build:
1. Fixed the Global Date/Time 'value' property in scripts.
2. Timers with alarms do not continually trigger the alarm when the time exceeds the alarm.
3. Updated info and grip icons to improve transparency and appearance.
4. Text formatting is stripped when pasting text into a script.

Feedback is appreciated!

Not sure this is unique to this release, but when I went to adjust a thermistor calibration, I could input as many numbers before the decimal as I wanted, but only 6 decimal places. I got around it by typing the decimal in a notepad and copy/paste into the thermistor calibration field.
 
Not sure this is unique to this release, but when I went to adjust a thermistor calibration, I could input as many numbers before the decimal as I wanted, but only 6 decimal places. I got around it by typing the decimal in a notepad and copy/paste into the thermistor calibration field.

I noticed this in the last couple revisions as well.
 
Then the more simple solution and what I also do is to put a flow sensor on the output of the BK to the FV.
IMG_3859.JPG

You can then get an accurate volume measurement into the FV, and then use 1 higher pressure (30psi) pressure sensor in the conical. However, I am not aware of any unitanks that can take above ~1bar. But anyways, yea easy to do as well.
 
I was thinking about using two sensors and removing the low pressure one after I've filled the fermenter. It would be on a tri clamp and would be the same port that I use for sampling.

The higher pressure one would be in the lid and would remain in place.
 
Another question as I plan my BruControl build. I have a conical fermenter that I use as a unitank with a spunding valve to carbonate near the end of fermentation. If I put a pressure sensor on my conical using one of the ports near the bottom, could I use that to determine the volume of wort that I end up with in my fermenter post boil? Then, once I have that volume and have started fermentation, when it comes time to put my conical under pressure, could I then "tare" out the valve reading to be 0 psi with whatever pressure it is under with that volume of liquid and then turn the valve into a basic psi pressure sensor?
you can, but I have seen far more accurate things done(read TTB approved) with load cells, and saw a guy doing it with spirits one time with a 3-pack of USB 'puck-style' ones... that would be cool it integrate, but might need a higher resolution A/D interface... maybe something like this? http://www.esp32learning.com/code/ads1115-analog-to-digital-converter-and-esp32.php

edit - the ADS1118 looks to be more compatible, wire it up like an RTD sensor
s-l500.jpg


Edit 2: better yet, HX711 is 24-bit just for scales, and 4 50KG load cells for $9.75 (but needs special code, so might not be the best choice) https://www.amazon.com/Half-bridge-...ocphy=9012391&hvtargid=pla-426277064612&psc=1
 
Last edited:
I know folks around here have tended to stay away from using mass as a means to measure volume but in my area (biopharmaceutical manufacturing), mass is the gold standard if you want to know the volume of a liquid. This is especially true in fixed/permanent tank installations where mass information is feed into a DCS historian every ~5 seconds 24/7/365. Where hygienic design is paramount, any extra wetted components are frowned upon. Granted that level of cleanliness is not as important in brewing but to be considered none the less. Following on work done by @paledragon I went with load cells, two Uno's w/lcd displays, HX711, and MCP4725 DACs to measure the mass of my boil kettle and MLT for my two vessel RIMS setup. I know drift (it is actually characterized as "creep") is often cited as a concern but I have not seen that to be a problem and I have found readings to be more cyclical (when looking at days of data) where the values will go down and up not just down, down, down. I attribute that to changes in room temperature but it is a tiny amount (0.038 kg max so far). While I do not intend to use the mass cells for long term measurement, I see no evidence that it couldn't. I am also using a one wire temp sensor to provide temp info from the load cell installation location and using that to provide "temp comp" for the load cells if/when they get outside the designed "already temp compensated" range for the load cells. I was going to deploy some time based compensation for creep and while I may still do that, I have not found that I need to at the moment.

Especially with the advent of the lookup table function in the BC RC, calibrating the analog output from the MCP4725 has made the mass (I convert to volume in the BC element) to be very accurate throughout the entire measurement range even if the input (DAC output) is not exactly linear. Creep appears to be insignificant in the context of how I plan to deploy it.

Sure it would be great to perhaps integrate this into a controller connected to BC directly and perhaps someday that will be possible. Considering the low cost of these controllers and how I wanted a local display with local tare functionality from that local UI, the separate controllers, lcd displays, and feeding an analog output to the BC controller via the 12-bit MCP4725 DAC works really well. That kind of detail would not be easy within the confines of a BC element for example nor would driving a local display to show the units I want, etc.. Don't be afraid to use mass is what I would say and also don't use super cheap load cells from a bathroom scale that lacks any specifications. The 50 kg units from Phidgets for less than $10 a piece look to be good units. A beauty of BC is the flexibility to do it your way!

This is what my scale enclosure for two vessels looks like. Also note you could do this with one controller but I wanted two displays showing the same data at the same time for both load cell setups.

thumb.php
 
Last edited:
All,

We posted an update to the v1.1 Release Candidate (v1.0.1.12). I think this is getting pretty close. Fixes in this build:
1. Fixed the Global Date/Time 'value' property in scripts.
2. Timers with alarms do not continually trigger the alarm when the time exceeds the alarm.
3. Updated info and grip icons to improve transparency and appearance.
4. Text formatting is stripped when pasting text into a script.

Feedback is appreciated!

What are "grip icons"?
 
Wow @VacationLand , that's really cool! We're OBLIGATED to get this into BC!

Grip icons are the little dots in the right bottom corner of elements that tell you "grip here" to resize the element. Nothing fancy - just a visual cue.

Oh, that is what those are called. I learned something today!

I will post the Arduino sketch for the "Mass Controller" which is fairly well commented and that should help anyone interested along quite a bit if they want to go this route. It is a bunch of work but in the end I do get a sweet element in BC giving me gallons, or liters, or quarts, or kg, or lbs for my BK and MLT.
 
Last edited:
For anyone interested in putting together an Arduino Uno based load cell controller with a local LCD display, local tare and calibration functions via the LCD buttons, with an analog output via a 12-bit DAC that can be connected to a controller running a BC firmware, the Arduino sketch in the attached text file will get you there. There are many ways to do things so feel free to make changes as you see fit.
 

Attachments

  • Mass_Controller.txt
    14.5 KB
.....

Sure it would be great to perhaps integrate this into a controller connected to BC directly and perhaps someday that will be possible. Considering the low cost of these controllers and how I wanted a local display with local tare functionality from that local UI, the separate controllers, lcd displays, and feeding an analog output to the BC controller via the 12-bit MCP4725 DAC works really well.


so the HX711 24-bit ADC converts the load cells to digital, the 12-bit MCP4725 converts it back to analog where the BC connected interface converts it back to digital? it seems like we lose a lot of resolution... is that the case? If we could keep the 24-bit, that would be awesome 12 bit is 4000 steps, is that enough? That is a gram in 4 kilograms or .01lbs in 40lbs even the new grandcentral ATSAMD51 is still 12-bit, is there an ESP32 or something that has at least 16 bit? Am I overthinking?
 
I agree the double conversion is not ideal, but as @VacationLand pointed out, using the lookup table creates a very accurate result so long as the measurement process is repeatable.

12 bit is 4096 values, and here’s a dirty little secret: v1.1 will have per-interface ADC resolution settings. This means that devices which support it, such as the Feather M0 and ESP32, will have 12 bit resolution. Keep in mind these ADC’s are not perfectly linear, so additional resolution isn’t a free lunch. But, it’s in there, so we think you should be able to take advantage from a data perspective and will turn it on with the final release.

No @clearwaterbrewer, you aren’t overthinking - resolution needs be considered. But again, if the measurement accuracy or repeatability isn’t good, having lots of resolution doesn’t help. For example, what would be better in your example: getting resolution down to 0.25 grams with results on the same measurement +/- 10 steps (2.5 grams) or resolution of 1 grams with results +/- 2 steps.
 
Last edited:
I agree the double conversion is not ideal, but as @VacationLand pointed out, using the lookup table creates a very accurate result so long as the measurement process is repeatable.

12 bit is 4096 values, and here’s a dirty little secret: v1.1 will have per-interface ADC resolution settings. This means that devices which support it, such as the Feather M0 and ESP32, will have 12 bit resolution. Keep in mind these ADC’s are not perfectly linear, so additional resolution isn’t a free lunch. But, it’s in there, so we think you should be able to take advantage from a data perspective and will turn it on with the final release.

No @clearwaterbrewer, you aren’t overthinking - resolution needs be considered. But again, if the measurement accuracy or repeatability isn’t good, having lots of resolution doesn’t help. For example, what would be better in your example: getting resolution down to 0.25 grams with results on the same measurement +/- 10 steps (2.5 grams) or resolution of 1 grams with results +/- 2 steps.

Just tested a workaround by using Node Red to send a value to a 1-wire device in BC. Works a treat! Created a dummy interface (pick any board you like) with the same IP as my Node Red server and a TCP in node in Node Red to listen to port 5000. Then I used a function node and wrote a small code to insert a value. BC sends ?200; and expects a reply with the value for example ?200=3456; which will show as 34.56 in the 1-wire device. and send it to the TCP out node configured as "reply to tcp". Thats it!
 
@VacationLand Can you show pics of your load cell setup/platforms, etc?

Thanks
I'm not home but this is what pictures I have. I welded the box steel into an "X", ran the wiring internally and used some components from a few scales I had to finish off the install. The load cells are M5 threaded.
thumb.php


thumb.php
 
Last edited:
so the HX711 24-bit ADC converts the load cells to digital, the 12-bit MCP4725 converts it back to analog where the BC connected interface converts it back to digital? it seems like we lose a lot of resolution... is that the case? If we could keep the 24-bit, that would be awesome 12 bit is 4000 steps, is that enough? That is a gram in 4 kilograms or .01lbs in 40lbs even the new grandcentral ATSAMD51 is still 12-bit, is there an ESP32 or something that has at least 16 bit? Am I overthinking?

Before I knew what I was doing, I assumed I could just hook the HX711 up to my MEGA 2560 running the BC firmware and to do exactly what you were talking about. But once I realized I couldn't just mess around in an Arduino sketch to make it work due to the BC firmware, a different route was needed. I certainly don't "like" all the ADC/DAC conversions. I produced a robust look up table from 12 points of data in the range I needed (1 gallon to 20 gallons). With that, the BC value matches the local display value on the Uno, which is the load cell data coming directly out of the HX711 lacking all the unsightly conversions. So it appears that pragmatism works in this case.
 
Just tested a workaround by using Node Red to send a value to a 1-wire device in BC. Works a treat! Created a dummy interface (pick any board you like) with the same IP as my Node Red server and a TCP in node in Node Red to listen to port 5000. Then I used a function node and wrote a small code to insert a value. BC sends ?200; and expects a reply with the value for example ?200=3456; which will show as 34.56 in the 1-wire device. and send it to the TCP out node configured as "reply to tcp". Thats it!

That’s very creative!! We need to create a data element so you can get information into and out of BC to save you the effort of workarounds!
 
Can we see what your lookup table looks like?

Are you accounting for wort density?
I don't have it handy but it is just BC read weights vs. known values. If I wanted to account for density I could do it either in the table or on the Uno. I would probably set up the LCD buttons to change the output between water (1.00) and say wort (1.050). I am not sure I need that yet but it would be easy enough.
 
That’s very creative!! We need to create a data element so you can get information into and out of BC to save you the effort of workarounds!

+1 for that data element! It will take BC to the next level for sure with possibilities to import recipe data, fermentation schedules, fermentation logging to external services (like Brewfather) and also open up for custom sensors and actuators like MQTT, modbus, REST, iSpindel devices, scales, servos, etc.
One suggestion from me is to start with making a BC custom node in Node Red and by that supporting Node Red as one of the interfaces. From Node Red there are endless possibilities to what data you want to connect to the interface. Shouldn't be too hard to make the node as existing communication can be used and can probably be made by anyone who know a bit of javascript.
 
Last edited:
One suggestion from me is to start with making a BC custom node in Node Red and by that supporting Node Red as one of the interfaces. From Node Red there are endless possibilities to what data you want to connect to the interface. Shouldn't be too hard to make the node as existing communication can be used and can probably be made by anyone who know a bit of javascript.

I think this is quite a good idea. Having a custom connector for Node Red would open up a lot of possibilities. I like the idea of a direct element for devices in BC, but this would help support a lot of the one-off type situations and add endless flexibility.
 
Hello folks, spent some hours (quite a few..) to make a flow in Node Red to interface with BC. The flow is attached in a text file if someone wants to give it a try. To set it up import the flow to Node Red and then you set up a Mega in BC with the IP where Node Red is running. If you need to install Node Red first it works perfectly on the Windows machine with BC. Or just use a Rpi.

It's the first time I am using Node Red so don't expect the interface to be perfect, but it works quite decent. It uses all 15 analog inputs and 10 1wire inputs to send values to BC. It don't seem to be an upper value for the analog inputs so the resolution is awesome. I also made 18 digital I/O which can be used as digital in, digital out, pwm out and duty cycle. In Node Red outgoing pins must be configured different than ingoing pins, just take a look at the examples I have made for pin 2, 3, 4 and the analog pins. Hysteresis and PID is not supported but the functionality can be added within Node Red. Digital I/O can also be further increased limited by the I/O on the Mega. Resolution on the out values is limited to pwm max which is 255.

Next project now is to get recipe data from Brewfather straight into BC!

Screenshot 2019-03-28 at 01.22.09.png
 

Attachments

  • BCflow.txt
    30.3 KB
Very Nice, I got node red installe, and the mega in BC, they are talking. This is my first time ever looking at node red so I am not sure.. but I REALLY want to input xml files.
 
where might I find the documentation on setting up the tilt? I believe I somehow had a connection earlier yesterday when it was reading the temp and giving me an SG of 2 but im not sure how to reconnect via bluetooth? I fiddled with the buttons on the esp with no luck
 
The Tilt doesn't really "connect" to anything, they just broadcast to anything listening. If you have the device element set to a 220 series and the correct color set in the element, it should be listening. If you can't see the Tilt from BC, can you use your phone and verify that the Tilt is powered up and broadcasting? If you can see it with your phone, the ESP32 may be bad (or may need a re-flash). If you can't see it with your phone, check the battery in the Tilt or contact them as you may have a bad unit.

Good luck,
Joe
 
Hello folks, spent some hours (quite a few..) to make a flow in Node Red to interface with BC. The flow is attached in a text file if someone wants to give it a try. To set it up import the flow to Node Red and then you set up a Mega in BC with the IP where Node Red is running. If you need to install Node Red first it works perfectly on the Windows machine with BC. Or just use a Rpi.

It's the first time I am using Node Red so don't expect the interface to be perfect, but it works quite decent. It uses all 15 analog inputs and 10 1wire inputs to send values to BC. It don't seem to be an upper value for the analog inputs so the resolution is awesome. I also made 18 digital I/O which can be used as digital in, digital out, pwm out and duty cycle. In Node Red outgoing pins must be configured different than ingoing pins, just take a look at the examples I have made for pin 2, 3, 4 and the analog pins. Hysteresis and PID is not supported but the functionality can be added within Node Red. Digital I/O can also be further increased limited by the I/O on the Mega. Resolution on the out values is limited to pwm max which is 255.

Next project now is to get recipe data from Brewfather straight into BC!

View attachment 619419
Wow, you rock!... saved me a lot of time building out the same thing. I'm working on getting an EasyDens connected in... I'll share my work as well (if I ever get it finished) if anyone else has one.

@Die_Beerery - It should be possible to parse out an XML file and send it to separate elements. Before moving to BruControl, I was thinking about building a new control system using a SCADA/DCS system called Ignition, which also has a Node Red connector. I was working on something similar, so I'll look up my old work and see if I can make a parallel.
 
The Tilt doesn't really "connect" to anything, they just broadcast to anything listening. If you have the device element set to a 220 series and the correct color set in the element, it should be listening. If you can't see the Tilt from BC, can you use your phone and verify that the Tilt is powered up and broadcasting? If you can see it with your phone, the ESP32 may be bad (or may need a re-flash). If you can't see it with your phone, check the battery in the Tilt or contact them as you may have a bad unit.

Good luck,
Joe
ok thanks, It does connect via bluetooth but the color designation must act as/bypass the normal pairing sequence. I wondered if that was the case but its good to confirm this.
 
I also want to add that I appreciate the ingenuity and efforts of users like @smort and @Die_Beerery to help us debug issues and enhance BruControl.

I think I mentioned it above, but we are looking at ways to give you the ability to get your own data in and out of BC. The NodeRed technique above is cool but I think we can do better to create a bi-directional pathway.
 
Back
Top