BruControl: Brewery control & automation software

Yakima 728
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.
Exporting Global data. I have many globals that I store information in. Some of it relates to starting setting (Temps, Times, Volumes etc) for the Brew. Other capture the data (such as time to transfer Strike Water) and others are imputed manually during the brew process (such as Strike Volume). I want to put these in a database so we can do regression analysis. Anyone exporting data like this?
 
I am not. Maybe because I have so many globals, it slows down the loading (maybe 10 minutes) and the database gets huge (gigabytes) in a hurry. I want to move them to an MS Access database that I am very proficient in. I could link to an sql database but MS Access can't handle that much data. Regardless, I am not interested in all the hits of the data, just one each. I do not want to know what my transfer time is by the millisecond, just once.
 
I just added my first one wire sensor on my Grand Central UNI. It read right away. I can use it instead of a 10k NTC probe for monitoring such things as Brew Kettle, Chilling Water, and Wort Out that are not temperature controlled by my Mega.

I know there are some issues with one wire indexing. As I have never used them, I would like to know more about this issue before I jump off a cliff.

Several things other than indexing:

Can you control an Element with them?

Proportional Valve?
 
And what happens when the index changes?

Say I have VCG_200_OneW_BrewKettle_B1 as interface 200 for a one wire for my Brew Kettle
I add VCG_201__OneW_LittleMac_B1as interface 201 for a one wire for my 2nd Brew Kettle
I later add VCG_202_One_W_CoolingWater_B1 as interface 202 for a one wire for my cooling Water
I then add VCG_203_OneW_WortOut_B1 as interface 203 for a one wire for my Wort Out of the Kettle

I add another one a month later
VCG_204_OneW_WortIN_B1 as interface 204 for a one wire for my Wort In of the Fermentor.

I do not understand how the index effects the one wire. Does it mean that it could switch probes so that my physical in the Brew Kettle (Port 200) is now my Wort Out (Port 203) probe?
 
The element will start reading a different sensor if the index changes. The index will “point” to a physical sensor. The order of sensors is set based on their internal identification number during interface boot up. It will always put them in the same order of index numbers as long as they are the same sensors. As soon as you add or remove a sensor on the bus, they will line up to different index numbers.

Again this only happens when you physically add or remove sensors, so there will never be a surprise in the middle of a brew day.
 
Would also be nice to have a Read Global Now as an option for a global to be read and a script command to read any that are set to read now. I use a lot of globals to "capture" transfer times, specific gravities and volumes. Some are automatically captured but some I manually enter during the Brew Process. For example, I get a prompt to Enter my "Sparge Volume" before I add the grain (waiting on Strike). I enter the Volume in a Global Value Element. At the end of the brew, I want send this to the database. Since it never changes, I only need it once.

By capturing the data, I can improve my process and also see where I need improvement in consistency.


With a script command, I can add that command at the end of my script to read those globals once.
 
Does anyone have a script to detect if an interface is down?

I had an issue last night where a control interface for a fermenter (ESP32 on an integrated relay board) seems to have frozen. I woke up and saw a sudden drop in gravity overnight (my Tilt interface is a separate ESP32 so it can sit on the metal fermenter), and then I saw that BC hasn't connected to the control interface for several hours (based on graph data). All other interfaces were fine. I went and reset the control interface, and it immediately kicked on the pump and pressure release, indicating it was the interface that was the fail point (it failed, the wort warmed, and the yeast got more active, hence the gravity drop). I went back to my PC to see the temp was in the low 70s and the pressure built up to 13 psi. This is a lager...I hope the higher pressure paired well with the higher temp to prevent ill effects, hah. All is good now.

I have alarm scripts set up to warn me if the temps are too low/high from target or if the pressure release doesn't seem to be working. But those won't work if the interface isn't working/connecting.

I looked into seeing if I could use an unused button as a Digital In. It would be "ON" (or "true") by default, and I hoped it would see the device as "false" during a forced drop, but no dice. BC reflects the last state value.

I might try making a Digital Out device and a Digital In device, with a jumper wire between those pins. Could have the Out status switch on and off and detect whether the In status changes as well. If not, then I'm not getting comms. I could then have a timer set to start when the Out and In aren't equal, and after 2 minutes, an alarm could trigger (so two scripts here). But before this, I want to see it anyone had a better programmatic route.
 
So my above idea worked out. I have a jumper between two pins, with one being Digital Out (DO) and the other Digital In (DI). I have a first script that flips DO on/off (depending on current state), then it waits 3 seconds. If DI != DO, then it starts a timer and waits for DI == DO. Otherwise, it doesn't start the timer (keeping it at 00:00:00), and it sleeps then loops back.

A second script waits for that timer to hit 1 minute. When it does, it triggers an alarm and global (for Node-RED to see and send a message to my phone). It then stops the first script, resets both DO and DI to off/false states/values, then starts the first script again. If the state/value still don't match after that restart and first loop, it will simply wait and be restarted again (this later part allows for the interface drop to clear itself up, if it does). If the state/value does end up matching after the first script is reset (no matter how many tries), that first script runs like normal and will turn off the alarm and global.

If anyone wants to pursue this, let me know and I can share my script codes.
 
CDCTx said:
Does anyone have a script to detect if an interface is down?

I had an issue last night where a control interface for a fermenter (ESP32 on an integrated relay board) seems to have frozen. I woke up and saw a sudden drop in gravity overnight (my Tilt interface is a separate ESP32 so it can sit on the metal fermenter), and then I saw that BC hasn't connected to the control interface for several hours (based on graph data). All other interfaces were fine. I went and reset the control interface, and it immediately kicked on the pump and pressure release, indicating it was the interface that was the fail point (it failed, the wort warmed, and the yeast got more active, hence the gravity drop). I went back to my PC to see the temp was in the low 70s and the pressure built up to 13 psi. This is a lager...I hope the higher pressure paired well with the higher temp to prevent ill effects, hah. All is good now.

I have alarm scripts set up to warn me if the temps are too low/high from target or if the pressure release doesn't seem to be working. But those won't work if the interface isn't working/connecting.

I looked into seeing if I could use an unused button as a Digital In. It would be "ON" (or "true") by default, and I hoped it would see the device as "false" during a forced drop, but no dice. BC reflects the last state value.

I might try making a Digital Out device and a Digital In device, with a jumper wire between those pins. Could have the Out status switch on and off and detect whether the In status changes as well. If not, then I'm not getting comms. I could then have a timer set to start when the Out and In aren't equal, and after 2 minutes, an alarm could trigger (so two scripts here). But before this, I want to see it anyone had a better programmatic route.
Click to expand...
Just curious, but were you using hysteresis elements for control, or controlling via script from BC for your temp/pressure targets?
 
So was the hysteresis working, but not getting new targets? Did other elements on the interface show online or did they say offline like this?
1663064568860.png
Just trying to understand the failure mode here.

I track an interface status by looking at an individual element with the "connected" status. Seems pretty reliable so far, but if your comms were up but the board wasn't working, thats a different issue.

*edit* - I re-read and you said the wort warmed up, so I'm going to take that as the interface was completely unresponsive on both comms and function.
 
Last edited:
Per @RiverCityBrewer, the "connected" property of a device element will tell the script if the interface is connected or not.

How are you powering this ESP32? Usually microcontroller failures are power related (voltage dip, spike, etc). The ESP does have a realtime OS, so it is *possible* that crashed, though I think highly unlikely.
 
RiverCityBrewer said:
So was the hysteresis working, but not getting new targets? Did other elements on the interface show online or did they say offline like this?View attachment 780823 Just trying to understand the failure mode here.

I track an interface status by looking at an individual element with the "connected" status. Seems pretty reliable so far, but if your comms were up but the board wasn't working, thats a different issue.

*edit* - I re-read and you said the wort warmed up, so I'm going to take that as the interface was completely unresponsive on both comms and function.
Click to expand...
Yeah, the board was unresponsive and seemingly not functional. No device updated on BC, and the board wasn't showing on WiFi. I just unplugged and plugged it back in, then it worked.

My other fermenter's control board did the same last night, but my script alerted me, and I quickly resolved it. I'm trying to find patterns to see what may be causing it.

BrunDog said:
Per @RiverCityBrewer, the "connected" property of a device element will tell the script if the interface is connected or not.
Click to expand...

Ah, I just now see the Connected property. I printed the script section out and put it presentation book for quick access, and the Connected (true/false) is tucked at the very top of the next page from All Device Elements, hah. But at least I learned it is there now. Thanks!

RiverCityBrewer said:
Hopefully you added a resistor (10k to gnd for example) in that jumper, otherwise you are creating a direct short.
Click to expand...
10k makes the input not receive the signal. But once I play with the Connected value, this may be moot (and better!).

BrunDog said:
How are you powering this ESP32? Usually microcontroller failures are power related (voltage dip, spike, etc). The ESP does have a realtime OS, so it is *possible* that crashed, though I think highly unlikely.
Click to expand...
It's the ESP32R4 from Robodyn, and I'm powering it with 110v AC input (the board has 110V AC or 12-24V DC with step downs for the MCU; a jumper sets which input is used). Under the board, I daisy chained each relay's COM to the 110V hot input so that single source of 110V can be used (and tucked this thing away into a nice protected project box for safety). I'm only running a 24W glycol pump and the 12v/12w pressure release solenoid (with converter) on the relays; my house is warm enough to let the wort free climb, so no heat wrap is powered.

On my previous setup (1 ESP32 dev board for to fermenters and wired to one 8-relay board), I had the ESP32 powered by standard USB, and I had a separate USB link to power the relay board. That board sometimes dropped as well, so I hoped splitting the load and power to two different boards for both fermenters would work.

Update: The Connected property does work well for this. Thanks! If I'm traveling and have something in a tank that I want to watch/control, I use the localhost IP with different ports and Node-RED to connect to my interfaces from anywhere, so this will limit that ability since the TCP connection into Node-RED indicates a connection is made. But while home ( and thus, the only time I'm able to do anything about a dropped interface anyways), I use network IPs, so this is perfect.
 
Last edited:
BrunDog said:
I’m surprised that unit locked up. Any chance the power flashed?
Click to expand...
If so, it didn't effect the other unit. Both run off the same power strip. Checking the interface logs and other BC events around the time of the last freeze, I don't see anything out of the ordinary, so it does feel somehow hardware/power related.

I note my keezer and glycol chiller are on the same home circuit, so I'm gonna plug the keezer into another circuit in the same room in case there is a power draw issue when it and the glycol compressors kick on around the same time, and I'll watch from there. With the 110v feed and the step downs to 5v (capacitors and all), I wouldn't think it would be an issue, but it's worth trying nonetheless.

Otherwise, I am loving this unit well above my last setup. It's a dream for BC once the analog pins are opened up.

If I can't find the issue, I may get another one of these units and make my own controlled power center for these BC interfaces (I'd code it in Arduino so it's super simple). Then, if BC detects a long down period on an interface, Node-RED can switch the relay off and on to reset it.
 
Does that unit (I don't recall) have a battery terminal for a LiPo battery?

I have an Adafruit Feather M0 which has been controlling my dispenser/fermenter for about 5 years without a crash. The LiPo helps bridge power spikes and drops.

Also, you can load default boot-up ports into the ESP32. While this won't fix a situation where its "locked up", it will on a power-reset where the connection to BC is lost.
 
BrunDog said:
Does that unit (I don't recall) have a battery terminal for a LiPo battery?

I have an Adafruit Feather M0 which has been controlling my dispenser/fermenter for about 5 years without a crash. The LiPo helps bridge power spikes and drops.

Also, you can load default boot-up ports into the ESP32. While this won't fix a situation where its "locked up", it will on a power-reset where the connection to BC is lost.
Click to expand...
No battery terminal, unfortunately. Just 110v AC or 12–24v DC (and UART pins for upload).

Nice on the Feather. I considered it first when I got BC, but the performance of the ESP32 gave me ideas for other projects, so it became my default MCU.

I've been meaning to play with the power-on interface configuration. Just for clarity, if I run %5 for an interface, it will tell the ESP32 to save which devices should be enabled at boot as well as their current targets/offsets/etc., right? So if I want to store the current config at a certain time or event, and power is reset after, the interface will start up with that config's device targets (until BC connects and overrides)?
 
CDCTx said:
Does anyone have a script to detect if an interface is down?

I had an issue last night where a control interface for a fermenter (ESP32 on an integrated relay board) seems to have frozen. I woke up and saw a sudden drop in gravity overnight (my Tilt interface is a separate ESP32 so it can sit on the metal fermenter), and then I saw that BC hasn't connected to the control interface for several hours (based on graph data). All other interfaces were fine. I went and reset the control interface, and it immediately kicked on the pump and pressure release, indicating it was the interface that was the fail point (it failed, the wort warmed, and the yeast got more active, hence the gravity drop). I went back to my PC to see the temp was in the low 70s and the pressure built up to 13 psi. This is a lager...I hope the higher pressure paired well with the higher temp to prevent ill effects, hah. All is good now.

I have alarm scripts set up to warn me if the temps are too low/high from target or if the pressure release doesn't seem to be working. But those won't work if the interface isn't working/connecting.

I looked into seeing if I could use an unused button as a Digital In. It would be "ON" (or "true") by default, and I hoped it would see the device as "false" during a forced drop, but no dice. BC reflects the last state value.

I might try making a Digital Out device and a Digital In device, with a jumper wire between those pins. Could have the Out status switch on and off and detect whether the In status changes as well. If not, then I'm not getting comms. I could then have a timer set to start when the Out and In aren't equal, and after 2 minutes, an alarm could trigger (so two scripts here). But before this, I want to see it anyone had a better programmatic route.
Click to expand...
hi, for detecting if the interface is down, I am using the following workaround:



//scirpt "connected"
//last changed 25.01.2021
//Autostart
// this script is checking connectivity to one element, assuming that if element is disc. whole MEGA is disc.
new datetime dt
"Message2" Visibility = Hidden
[loop]
if "RIMS PID" Connected != true
dt = now
"Message2" Visibility = Visible
"Message2" Value = dt
"Message2" Value = "Dissconnected on: \n" + "Message2" Value
endif
sleep 500
goto loop


Although its not " interface down" script, you can test just one element of specific interface with same effect – in my case PID Control element.
ahhh sorry for duplicating post, I just saw RiverCityBrewer already answered.
 
exoticatom said:
hi, for detecting if the interface is down, I am using the following workaround:



//scirpt "connected"
//last changed 25.01.2021
//Autostart
// this script is checking connectivity to one element, assuming that if element is disc. whole MEGA is disc.
new datetime dt
"Message2" Visibility = Hidden
[loop]
if "RIMS PID" Connected != true
dt = now
"Message2" Visibility = Visible
"Message2" Value = dt
"Message2" Value = "Dissconnected on: \n" + "Message2" Value
endif
sleep 500
goto loop


Although its not " interface down" script, you can test just one element of specific interface with same effect – in my case PID Control element.
ahhh sorry for duplicating post, I just saw RiverCityBrewer already answered.
Click to expand...
Thanks! Still good to see. This method has worked well. I have it start a timer and wait for the connection to come back. If it doesn't come back after a minute, it sets the alarm series. If the connection comes back, then the timer stops and reset.

I still can't believe I've missed seeing "Connected (true/false)" in the manual all this time. I open it up at least once a week to see if an idea seems feasible, but it is just tucked away at the top of the page in my presentation book. Just never caught me eye. But it's so useful.
 
CDCTx said:
Thanks! Still good to see. This method has worked well. I have it start a timer and wait for the connection to come back. If it doesn't come back after a minute, it sets the alarm series. If the connection comes back, then the timer stops and reset.

I still can't believe I've missed seeing "Connected (true/false)" in the manual all this time. I open it up at least once a week to see if an idea seems feasible, but it is just tucked away at the top of the page in my presentation book. Just never caught me eye. But it's so useful.
Click to expand...
A little Off Topic:off: because I was flamed for not "reading the manual" some time ago. I wrote many different "help" manuals. They are a chore and while the info is there, an maybe in front of your face, it is always hard to see. If you add everything every time, it becomes somewhat verbose. But if you repeat it for all elements, it would be more apparent. Because I have run "help", over the years (and some time ago now), a standard smug response of "RTFM" is just that, SMUG:agressive: and not helpful. I am glad that did not happen in this case and we all learned. I hope the people on this forum remember to help and not be SMUG. If you know the answer, Help! If you want to be a little smug, just quote the manual.:bigmug:
 
oakbarn said:
A little Off Topic:off: because I was flamed for not "reading the manual" some time ago. I wrote many different "help" manuals. They are a chore and while the info is there, an maybe in front of your face, it is always hard to see. If you add everything every time, it becomes somewhat verbose. But if you repeat it for all elements, it would be more apparent. Because I have run "help", over the years (and some time ago now), a standard smug response of "RTFM" is just that, SMUG:agressive: and not helpful. I am glad that did not happen in this case and we all learned. I hope the people on this forum remember to help and not be SMUG. If you know the answer, Help! If you want to be a little smug, just quote the manual.:bigmug:
Click to expand...
Hopefully that doesn't happen much now. I likely shared enough to indicate that I read the manual; it's just a lot to take in or things get buried (or my blind @$$ misses something I wish I had seen a while ago). Seriously, I want a refund on my glasses and contacts. Or maybe I shouldn't sample my homebrew before playing around with BC and code ;)
 
Basic wiring question:

I have 24 vdc valves and 110 vac Rip Tide Pumps. Can I run the valve control wires and the pump power cord side by side or do I need to separate them? The control voltage for the valves only is present when opening or closing a valve. If separated, what is minimum distance.

I am running these around and under my new stand.

I am running any temp probes away from other wiring as much as possible and never in same conduit.
 
In industry, running various voltages side by side is common, just not in the same conduit. 6-8" separation is pretty standard minimum.
 
RiverCityBrewer said:
In industry, running various voltages side by side is common, just not in the same conduit. 6-8" separation is pretty standard minimum.
Click to expand...
Thanks I had already decided to get them as far apart as reasonable for the stand I made. Trying to go much more automated on my valves. Before I only had two automated valves to turn on water to fill two different vessels. I planned my manifold and valves so I can fill and move liquid both directions in the manifold, generally between any two vessels. I ended up with 20 valves. That is only 3 more valves that I had when I has mostly manual valves. I have a separate script that just handles the valve configurations.

We ran our manual manifold for several years and never had any cleaning issues with CIP. We would bore scope them every once in a while but they were always clean (especially for the hot side). That lead me to believe I could hard pipe the entire hot side and not have any issues. We have only had one infection since 2008 and that was when someone (not me) put his hand into the Wort stream going to the Fermentor.
 
For One Wire:

I am planning on running a twisted pair from my Port/Pin 5 and Ground to a terminal bar where I will star off the one wire probes. As a practical matter, has any one done this (use a terminal bar) for one wire?

If so, how far away from the Arduino did you put the terminal bar. Form a wiring point of view I would like to run it to where I can hook up the One wire probes directly to the Terminal bar. The leads are about 6 feet. For some I will still have to add more lead wire to get to my kettles. If I use the 6 foot lead (what the probes already have), I would need to make the wire from the Arduino to the terminal bar about 10 feet.

I could place the Terminal bar closer to the Arduino and just increase each individual lead.

Thoughts?

I could just wire it and try, but any guidance would be helpful as I have never used one wire.

I am using these one wire probes for 2 boil kettles (direct fired), my cooling water, The wort to the Fermentor.
 
I have a roll of Belden 8761 (shielded twisted pair with drain wire). I will try it and see. I can always shorten the lead from Pin 5 to the terminal bar. I am using these probes to see the general temperature and not for control (although I might get a proportional valve to control the cooling medium in the plate chiller (or the wort side depending on which works best with manual valves).

I generally leave the drain not grounded but that could change depending on what I see.
 
One wire on the Unishield Grand Central:

I have the Dip Switch set for AREF to Pin 5.

I connect the Data to Pin 5, the GND to GND.

Do I use the 5 v Output on the Riser or the 3.3 v for VDD of the probe?
 
BrunDog said:
Per @RiverCityBrewer, the "connected" property of a device element will tell the script if the interface is connected or not.

How are you powering this ESP32? Usually microcontroller failures are power related (voltage dip, spike, etc). The ESP does have a realtime OS, so it is *possible* that crashed, though I think highly unlikely.
Click to expand...
I have had this happen for YEARS and have asked for a watchdog or something to reset it... it even happens when plugged into a UPS...
 
clearwaterbrewer said:
I have had this happen for YEARS and have asked for a watchdog or something to reset it... it even happens when plugged into a UPS...
Click to expand...
I've had it happen on one controller a few times this week. Looking at my graphs, it has consistently happened when my max high offset temp was reached, indicating it happens around the time my associated glycol pump (24W, I assume 12V 2A) should be kicking on (but not every time of this scenario; I'll go 6–10 hours, sometimes a few days, before it freezes again). But I don't have good data about the pump actually kicking on at that time. I'll see if I can correlate something and test from there.

This hasn't been happening on my other fermentation controller, which is the same setup and runs on the same wall AC line. This controller runs a 60W pump (I assume 12V 5A). If it were a current issue when the pump kicks on (which shouldn't happen given the capacitors on the board), I'd expect it to happen with the 60W pump, not the 24W one.

I hope to address the cause, but I'm gonna make my own smart power strip as a failsafe. I will code the ESP32 relay board myself in Arduino. It will ping the IP of each BC controller, and after an X number of sequential ping failures, it'll switch the associated port off then on to reset. I'll also add a routine so Node-RED can send a reset message for a specific port if BC hasn't reconnected to the device in over a minute (some redundancy is good).

I already have an alarm script to count how long a drop occurs, and Node-RED will see my associated global and send me a Pushover alert and send a message through my Google speakers. This let me address the issue quickly, even at 2 am (I really want my Pils to go well).
 
Last edited:
I was very lightly using brucontrol in my last house but life got in a way for a while and now I've moved into a new place and feel like I'm a noob again.

My brucontrol is still the same version 1.1 build 22 and all my settings are the same as the old setup. I reconnected my esp32 to the new wifi and everything is working except for the 1wire probes. I know they have to be plugged in before the interface gets power which they are, yet they don't show any readings. The devices show as mapped to port 200/sensor index 0, port 201/sensor index1, etc through port 203/index3 which is how they were setup before. I would think they would just work as all that has really changed was reconfiguring the wireless network on the esp32 yet I can't seem to get them to read.

What am I missing?
 
Hannabrew said:
I was very lightly using brucontrol in my last house but life got in a way for a while and now I've moved into a new place and feel like I'm a noob again.

My brucontrol is still the same version 1.1 build 22 and all my settings are the same as the old setup. I reconnected my esp32 to the new wifi and everything is working except for the 1wire probes. I know they have to be plugged in before the interface gets power which they are, yet they don't show any readings. The devices show as mapped to port 200/sensor index 0, port 201/sensor index1, etc through port 203/index3 which is how they were setup before. I would think they would just work as all that has really changed was reconfiguring the wireless network on the esp32 yet I can't seem to get them to read.

What am I missing?
Click to expand...

Do your probes have end connections (like an audio jack or other plugable device)? Or even a hub that you wired together? If so, it may be worth checking the solder/crimp connections. I had to do that on one probe after putting it away and pulling it out later. A solder connection came loose, and it didn't show anything on BC until I fixed that.

And do you have the resister in place for these?
 
CDCTx said:
Do your probes have end connections (like an audio jack or other plugable device)? Or even a hub that you wired together? If so, it may be worth checking the solder/crimp connections. I had to do that on one probe after putting it away and pulling it out later. A solder connection came loose, and it didn't show anything on BC until I fixed that.

And do you have the resister in place for these?
Click to expand...
Yes resistors are in place and yes there are audio jacks on the wires that plug into my box

I'll double check all the connections for starters
 

Similar threads

h22lude
My BruControl UniFlex review
Replies
3
Views
2K
h22lude
h22lude
duncan.brown
Brewery Dashboard
Replies
18
Views
2K
suprchunk
suprchunk
braumke
Automate your electric brewery - 4 Testers needed for open source project
Replies
29
Views
5K
estricklin
estricklin
RonBurgundy10
BruControl Uniflex: Automation For All
2
Replies
51
Views
8K
BrunDog
BrunDog
muhteeus
muh's BruControl Build
Replies
25
Views
6K
sensei247
sensei247
SSBrew 300

Latest posts

Back
Top