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.
My license log:

09:26:55.796: File created 07/04/2021
09:26:55.827: Attempting to synchronize local license with server...
09:26:56.833: Server response successful. License status: OKf

EDIT: I have not updated in a while and running 1.1 Build 4
 
No changes to my system, thanks @TenaCJed and @RiverCityBrewer for checking on your ends.

Here is what I'm getting, I'd be more suspicious of my end if @RiverCityBrewer wasn't also seeing an issue.

08:47:09.443: Attempting to synchronize local license with server...
08:47:12.387: Exception while synchronizing license with server. Error: There was no endpoint listening at https://brundog.com/services/v1/licensing.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
09:33:27.745: Attempting to synchronize local license with server...
09:34:23.465: Exception while synchronizing license with server. Error: The request channel timed out while waiting for a reply after 00:00:59.8315449. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
 
Last edited:
Hi guys,

The server host reports they are having an outage, and claim it should be back up shortly. While this is the first time this has happened, it's not lost on me that if your system hasn't synched in 30 days, you'd be locked out, and I never want a system issue to prevent you from brewing. Will think of a solution...

Edit: back up and running as of last night. Might be time to find a new provider!
 
Last edited:
Back in business, mashing 32 lbs for a quad. V22 is running nicely. Thanks BrunDog!

Finally got a decent digital scale that can handle up to 55 lbs. Should have done that long ago.

My controller build is by a friend from maybe 8 years ago, I swapped out the board and Brewtroller for a MEGA and BruControl, which has been great.


dumbluck-outside.jpg

dumbluck-inside.jpg


But I'm getting ready for a V2 build as I've run out of space, and would like some additional relays to control the pumps and a few more valves for hot liquor (currently do that by hand), plus a connection for a volume sensor on the HLT. Might also switch to some proportional valves to control the fly sparge.

I have a 15 year old Mac Pro enclosure that I'm planning to use, should be about 60% more space to work with, with good cooling and a solid frame to connect to. I don't plan to go with the touchscreen interface again, but reusing the temp displays might be fun.

- Gregg

Currently brewing Belgian quad (kegs 173/174)
Drinking House Mouse Demise (imperial multigrain farmhouse, 8.7%), a Belgian Pale (6.3%), and a commercial NEIPA (Marsh Island Pulp Truck 6.0%) left over from a work party.
Next up brewing: Barnglow (New England Farmhouse IPA, 8.3%)
 
Saw this new fanless mini pc from gigabyte with my search for the jasper lake N5105 10nm - 10w cpu... not available yet, and will not win any beauty contests, but is low power high performance and has a few other neat features like regular and m.2 ssd, along with being from a reputable manufacturer, I will likely get one for my BC implementation.
 
Saw this new fanless mini pc from gigabyte with my search for the jasper lake N5105 10nm - 10w cpu... not available yet, and will not win any beauty contests, but is low power high performance and has a few other neat features like regular and m.2 ssd, along with being from a reputable manufacturer, I will likely get one for my BC implementation.
Might wait for Windows 11
 
Logging data to Brewfather?
Can you send fermentation data from BruControl to Brewfather?

A quick search of google and this thread I only find people trying to get their recipes into BruControl and no one trying to go the other way. I know that is clue but I'm asking anyway.

I have a EBIAB setup with my own arduino based semiautomatic control that I am happy with. For my fermenter though I have been using Brewpiless and Ispindel for control and data. The logging over wifi has been unreliable. The control is fine but I like having my data in my batch on Brewfather.
 
Hey guys almost have my cold storage controller complete should be putting power to it soon. In the meantime I'm working on the script for the LCD readout. My goal is to have the LCD report various 1-wire temperature values as well as the setpoint for the hysteresis devices driving the unit..

Code:
[Setup]
new string CC                        // declare a new string variable
CC = "1"                            //  turn on lcd backlight
new string csroomtemp
new string csminisplitfinsensor

[Loop]
csroomtemp = "CS ROOM SENSOR" DisplayText        //  "CS ROOM SENSOR" is 1-wire temp input 
display "ESP32-Cold Storage" 1 csroomtemp            //  "ESP32-Cold Storage" is interface
sleep 3000
csminisplitfinsensor = "CS MINI-SPLIT FIN SENSOR" DisplayText    //  "CS MINI-SPLIT FIN SENSOR" is 1-wire temp input 
display "ESP32-Cold Storage" 1 csroomtemp            //  "ESP32-Cold Storage" is interface
sleep 3000

goto "Loop"
 
Not sure what your specific question is, but it looks like you have a copy/paste typo. Both of your display commands are writing the same string variable. I'm assuming the second display command should be for csminisplitfinsensor and not csroomtemp?
 
Not sure what your specific question is, but it looks like you have a copy/paste typo. Both of your display commands are writing the same string variable. I'm assuming the second display command should be for csminisplitfinsensor and not csroomtemp?
That is correct for the typo. I made correction to read csminisplitfinsensor.

I have connection to interface and script is running with no hickups but I see an array of black blocks on both lines the LCD module.
 
Still seeing an array of blocks on both lines of the LCD module after tuning the contrast pot. Any ideas where Im going wrong?
 
I don't know if that is compatible... the amazon page shows the LCD which is correct, but I can't tell about the I2C "backpack" compatibility.
Before I move on with the return what is the most simple script I can send to ensure its not on BC end?
 
It's likely not a script thing... its a firmware thing. The firmware is speaking one "language" while the LCD you have understands a different one.

I might be able to get you a basic firmware that will just write text... would be a couple of days though if you can hang.
 
It's likely not a script thing... its a firmware thing. The firmware is speaking one "language" while the LCD you have understands a different one.

I might be able to get you a basic firmware that will just write text... would be a couple of days though if you can hang.
Thanks Pete, I'll check in in a few days
 
Ran into a problem today with my ESP Unishield. I changed out power supplies when my original supply failed and following that my ESP32 would not connect to BruControl. After hours of troubleshooting, I narrowed it down to GPIO 12. When I disconnected my plastic flowmeter connected to this pin, the ESP32 would boot and everything was happy. Turns out, GPIO 12 will cause a boot fail if the pin is high at startup. The flowmeter will end up high or low depending on where it stopped last. Please avoid this pin for flowmeter use.

Found the info at;
ESP32 Pinout Reference: Which GPIO pins should you use? | Random Nerd Tutorials

GPIOInputOutputNotes
0pulled upOKoutputs PWM signal at boot
1TX pinOKdebug output at boot
2OKOKconnected to on-board LED
3OKRX pinHIGH at boot
4OKOK
5OKOKoutputs PWM signal at boot
6xxconnected to the integrated SPI flash
7xxconnected to the integrated SPI flash
8xxconnected to the integrated SPI flash
9xxconnected to the integrated SPI flash
10xxconnected to the integrated SPI flash
11xxconnected to the integrated SPI flash
12OKOKboot fail if pulled high
 

Attachments

  • Screenshot_20210814_083024.jpg
    Screenshot_20210814_083024.jpg
    324.4 KB · Views: 13
It's likely not a script thing... its a firmware thing. The firmware is speaking one "language" while the LCD you have understands a different one.

I might be able to get you a basic firmware that will just write text... would be a couple of days though if you can hang.
Hey Pete just checking in on this. Thanks
 
OK... just added an LCD test firmware into the version 45 package. Download off the website, run the FW tool as usual, use the "BruControl.LCDTest.MEGA.S" version. This only displays a counter on a connected display, so should help you determine if the wiring and hardware are correct. This assumes the defaultI2C address on the backpack (no jumpers changed).
 
OK... just added an LCD test firmware into the version 45 package. Download off the website, run the FW tool as usual, use the "BruControl.LCDTest.MEGA.S" version. This only displays a counter on a connected display, so should help you determine if the wiring and hardware are correct. This assumes the defaultI2C address on the backpack (no jumpers changed).
I have the LCD connected to a ESP32. I see Mega in the version name. Just checking if this is correct.

On a side note, I have my system set up to trigger an alarm in the event BC is disconnected. All it working well but I am looking for a way to receive an email in the event I lose my router. Obviously if I lose my router I lose internet so I can expect BC to send an email. Is there a way to add this to a queue to where the email is sent when the internet is back online?
 
Crap... didn't realize it was on an ESP32. Will need to cut that firmware... stay tuned.

Good question... I think the email would probably just fail without a server available. I'll add this to a list of upgrades to evaluate.
 
Doesn't 1-wire have a certain order turning on the interface, plugging in wires, etc..? I had a working system and I extended the 1-wire wire length and now im seeing --- on all of the inputs.

edit: i just remembered to reset the interface using communications with %3. Didnt seem to help
 
Last edited:
Yes. The order don’t change when you extend the wire length. But extending the wire length could introduce noise depending on the length and exposure. How long are they, and how many? You can use shielded wire (drained back at the controller ground only) and get better distances.

Edit: Updated the firmware again. ESP32 test LCD is in there. SDA and SCL are GPIO 21 and 22, respectively.
 
Just so I understand one wire:

1. Once you assign a Port/Pin to a one wire probe, it should not be moved to a different Port/Pin?

2. You can change the wire length, and other than noise concerns, it is not an issue?

3. Can you change the Physical Probe at the end of the wire without any issues?

4. Other one wire issues?
 
With regards to #2 cable length. One-wire uses open drain for the signalling. This requires a resistor to pull the signal voltage up to 3.3V/5V when either the master or slave releases the bus. Long cables and/or many devices on one chain can increase the overall capacitance which will slow down the rise time of the signal. This can cause communication errors if it's too slow. To overcome this you change the 4.7K Ohm pull-up resistor to a lower value which will decrease the rise time.
 
The nominal One-Wire pull-up resistor values are 2.2K for 3.3V applications and 4.7K for 5V applications.

fwiw, I have multiple One-Wire "networks" in my home including a few with 5 ds18b20 temperature sensors. Half of these networks are on 5V (Arduino UNO and MEGA usage) and the other half on 3.3V (Raspberry Pi and ESP8266/ESP32 applications), some with almost 20 meters of total wire, and all use the "nominal" pull-up values...

Cheers!
 
Yes. The order don’t change when you extend the wire length. But extending the wire length could introduce noise depending on the length and exposure. How long are they, and how many? You can use shielded wire (drained back at the controller ground only) and get better distances.

Edit: Updated the firmware again. ESP32 test LCD is in there. SDA and SCL are GPIO 21 and 22, respectively.
Thankyou. I'll give this a try next time I'm down there
The nominal One-Wire pull-up resistor values are 2.2K for 3.3V applications and 4.7K for 5V applications.

fwiw, I have multiple One-Wire "networks" in my home including a few with 5 ds18b20 temperature sensors. Half of these networks are on 5V (Arduino UNO and MEGA usage) and the other half on 3.3V (Raspberry Pi and ESP8266/ESP32 applications), some with almost 20 meters of total wire, and all use the "nominal" pull-up values...

Cheers!
I don't understand the term "pull up" I have a resistor wired in per the diagrams on BC website. Although I'm using a 4.7K with 3.3v. it worked with a short single 1-wire probe. I'll give the 2.2K a shot.
 
Kinda like a spring return on a door… a person goes through the door, opening it, but for it to close the spring return is needed.

The switch (transistor) in the chip provides a connection to ground when it’s sending data. The external resistor “pulls up” the voltage when that switch is off to create the return to a default state. The receiving circuits can then read the full voltage rises and falls.
 
Back
Top