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 don't know about the latest model, but the two tilts that I have broadcast their readings every second, but only update the readings they are broadcasting every 10 seconds or so. The ESP32 only has one 2.4ghz radio, so it can either be connected to BLE or connected to WiFi. The way I've observed it working, trying to read BLE every second would leave little to no time for WiFi connectivity. I do like the idea of a hardware dampened reading, but trying to read the BLE beacon faster than every 10 seconds seems moot.
My Tilt on TiltPi updates every 5 seconds, and receives a beacon every one second.
 
I have a gen 1 and gen 2 (double cap) Tilt, and there are clear differences between the electronics packages, so I'm not surprised that there are software differences as well. Fortunately, fermentation doesn't change so fast that 5 second, 10 second, or even 1 minute updates would make a difference. I'm not familiar with fermentation meant for distillation, but your raw tilt readings would lead me to believe the fermentation is very active/violent. In the absence of hardware dampening, have you considered scripting to give you an average? I use a script to take a raw tilt reading every 10 minutes and roll it into a 60 minute average. Gives me a smooth graph, but more importantly the trend it creates (when the properly calibrated) is typically +/- 1 gravity point of the real gravity. I'm sure our fermentation goals are different given that you are a commercial distillation operation, so I'm curious what your end goal is while tracking the fermentation curve.
 
... I have noticed the ESP32 takes a much longer power cycle (AC) or it doesn't come back up correctly... DC power cycle can be quick, but there must be enough juice in the power adapter for 30 seconds or so to interfere with a good reboot... I am reluctant to run a LiPo battery backup on it as it is located in the ceiling...

The ESP32 should connect to Wi-Fi within 5 seconds of power up. It will take 30-60 seconds to report it's first Tilt reading.

Ya... LiPo in an inaccessible location is not a great idea, but LiPo backups are awesome... I have a Feather M0 controlling refrigeration which has run continuously for over 3 years without a hiccup. This is an N of 1, so certainly not scientific... but I think its a good idea to assure continuation in light of power hiccups.
 
I have both Gen1 and Gen2 tilts also. Gen1 was built from an off-the-shelf "Light blue bean". V2 and V3 are same internals.. I agree that fermentation does not change that fast, but I do need faster than a 1-hour average, I could do that manually with a hydrometer. I am absolutely looking to use the available number of discrete values sent to overcome a very active fermentation (9%ABV in 12-18 hours) moving the tilt around. Keep in mind that it does not take much movement to show a 0.010-0.020 change in gravity... Scripting has been considered, but is extremely cumbersome, and undesirable when a simple calculation in the interface would suffice. My end goal is that of any commercial fermenting operation... To have the system let me know when it is not going right... I do not need every second, but if a new value is coming every 5 seconds, which I have verified with my own eyes, then asking to take that value to roll into a 5 or 15 minute average seems reasonable.
1597416099948.png
 
The ESP32 should connect to Wi-Fi within 5 seconds of power up. It will take 30-60 seconds to report it's first Tilt reading.

Ya... LiPo in an inaccessible location is not a great idea, but LiPo backups are awesome... I have a Feather M0 controlling refrigeration which has run continuously for over 3 years without a hiccup. This is an N of 1, so certainly not scientific... but I think its a good idea to assure continuation in light of power hiccups.

yes, if the USB adapter has AC powered off for more than a minute, or the USB cable has been removed, the ESP32 comes right up... it is when the AC USB dongle(mostly iphone usb chargers) is only removed from power for 20 seconds, and then power is re-applied, there is something happening...

You do a great job in the interface firmware, I think this is more environmental/hardware, and i did notice much faster boot of the SonOff Dual ESP8285 with the firmware updates this year.
 
We could easily do averaging in the interface... but consciously decided against it. Averaging should be implemented to reduce noise or aberrant readings, like those you can get with analog reads picking up EMI. If we add it, I think many people will be frustrated to see that the report in the Tilt app does not match the report in BruControl. Since the device is a mechanical one which is already damped, it should not be reporting noise. Therefore, if you want to do time averaging, doing it via scripting per @RiverCityBrewer is indeed the best way to give you the flexibility you want (percentages, time windows, etc.). We can help you with a script if you'd like.

Regarding the AC USB dongle... I'm surprised it has enough capacitance to power an ESP32 for 20 seconds. I guess that says the ESP is power efficient and doesn't draw much! I'm not sure how to qualify the quality of that type of power supply compared to a legit one. It might be worthwhile doing a comparative test at some point.

Anyway, thank you for the continued feedback. Share that graph once it has some hours behind it so we can see if the new FW is eliminating the default spikes.
 
We could easily do averaging in the interface... but consciously decided against it. Averaging should be implemented to reduce noise or aberrant readings, like those you can get with analog reads picking up EMI. If we add it, I think many people will be frustrated to see that the report in the Tilt app does not match the report in BruControl.

It doesn't match now... The TiltPi app updates every 5 seconds, and shows how long it has been since last update... BC is about every 20-30 seconds, I am sitting here with a watch with a second hand watchign it live now, sometimes 20 seconds, sometimes 30-35 seconds... I have it set to 10 in the configuration.

1597419500530.png
 
I posted my scripting some months ago for how I do it... the sample time and weighting is easily changed. See post #4030 for details.

Were you able to keep both Tilt readings, Temp and SG in the same container? I have not been able to justify the time to set aside to sit down for hours and understand and write scripts...
 
Were you able to keep both Tilt readings, Temp and SG in the same container? I have not been able to justify the time to set aside to sit down for hours and understand and write scripts...
If by same container you mean the interface element, then yes, nothing changed from that respect. All I did was create a global and use the script to feed it averaged data, then the global feeds the trend. If you look at the screenshot in that referenced post, you'll see the original tilt element, then just to the right of it is the weighted average.
 
It doesn't match now... The TiltPi app updates every 5 seconds, and shows how long it has been since last update... BC is about every 20-30 seconds, I am sitting here with a watch with a second hand watchign it live now, sometimes 20 seconds, sometimes 30-35 seconds... I have it set to 10 in the configuration.

View attachment 693878

BC initiates a scan every 25 seconds. So if you add up the max of 25 seconds and a refresh of 10 seconds, the oldest the read could be would be 35 seconds. We could make it faster, but until we can figure out how to prevent the Wi-Fi and BT from clashing while keeping I/O real time, we need to keep these longer delays.
 
@


Ok, this has me concerned... See the 'IP:0.0.0.0' lines? This is telling you that the adapter is reporting no IP address.

I recommend you try DHCP. After you save the settings, make sure you reset the MEGA.
Reset the mega by pressing the physical button on the board? If I choose DHCP it will automatically come up with an IP address in which I'll have to find within my router and then assign that to BC correct?
 
Minor feature request. Low Priority. Be able to change the font color on the Chart Element DisplayName property to accommodate visibility when using light background themes/backgrounds.
 
Can I power (3) RP-3 boards with 5v output from Mega? I have 12v to VIN. Not sure if draw more than 250mA combined
 
Yes. They don't use much.
Sweet. I think I'm honing in on one of my issues. When I power Mega with 12v (12.3 measured) the Ethernet board cycles repeadtly very fast so really never actually running. Would 12.3 volts to Mega cause stability issues?

DHCP is working much better. I think the static IP assigned was being erased whenever I would hook up 12v. I can swap back and forth between 12v and USB power and the cycling issue goes away. I see this issue with running 12V positive to VIN and negative directly to the 24V to 12V stepdown transformer.

I have a voltage adj screw on my 24V power supply perhaps lowering that will lower the output from the stepdown transformer within range.
 
Minor feature request. Low Priority. Be able to change the font color on the Chart Element DisplayName property to accommodate visibility when using light background themes/backgrounds.
I like this one, I actually tried changing the color about a month ago and was surprised that this wasn't a feature.
 
OK hold on... 12VDC to the MEGA should not be a problem UNLESS you are drawing a bunch of current through it. This is why I suggest you disconnect everything and run just the MEGA with Ethernet shield. If that alone doesn't work, then you should not progress to the next step of hooking up any devices.

How are you powering the MEGA with 12VDC? (through what pins)? You say stepdown transformer... those are for AC - are you sure you aren't powering with AC? Are you saying the MEGA works correctly when powering it via the USB input and a 5V power supply (or computer)?

Edit: Did you post or send us schematic? It doesn't matter until we get a stable MEGA/shield working but ultimately might help.
 
OK hold on... 12VDC to the MEGA should not be a problem UNLESS you are drawing a bunch of current through it. This is why I suggest you disconnect everything and run just the MEGA with Ethernet shield. If that alone doesn't work, then you should not progress to the next step of hooking up any devices.
Yes I have done this. Everything is disconnected! Per my previous post, it works with USB power, I have began hooking one component at a time to figure out the issue. There seems to be an issue at my 12V power supply. I understand the concept of minimizing components connected to the Mega to assist with diagnosing the issue.

How are you powering the MEGA with 12VDC? (through what pins)? You say stepdown transformer... those are for AC - are you sure you aren't powering with AC? Are you saying the MEGA works correctly when powering it via the USB input and a 5V power supply (or computer)?
I am using one of these. It is fed with a 24V DC power supply. DC+ goes to VIN and DC- goes to my grounding strip which is where the Mega DC- also runs to. A star pattern. Ive also tried running DC+ and DC- from Mega directly to this guy. Same issue.
61KCgYdrc9L._AC_SL1200_.jpg


Edit: Did you post or send us schematic? It doesn't matter until we get a stable MEGA/shield working but ultimately might help.
Yes I have, since everything is unplugged its wired as shown on the BC Power wiring example. Let me try with a few other power sources. I have a 120V to 12VDC transformer I can try on Monday.

So 12.3 Volts DC is ok?
 
Yes, ditch that thing. Looks like its got good reviews, but let's continue to isolate out stuff that hasn't proven itself not to be the culprit. Try a proper 12VDC power supply (not transformer). If you power via the MEGA jack or Vin pin, you can *technically* power it up to 20V... but that's a lot of pressure on the linear regulator that needs to dump the over-voltage. In the meantime, if you have a new 9V battery laying around... try that - its clean and should work for a little while.
 
Yes, ditch that thing. Looks like its got good reviews, but let's continue to isolate out stuff that hasn't proven itself not to be the culprit. Try a proper 12VDC power supply (not transformer). If you power via the MEGA jack or Vin pin, you can *technically* power it up to 20V... but that's a lot of pressure on the linear regulator that needs to dump the over-voltage. In the meantime, if you have a new 9V battery laying around... try that - its clean and should work for a little while.
Will do, I have a LIPO battery I can try as well.
 
If by same container you mean the interface element, then yes, nothing changed from that respect. All I did was create a global and use the script to feed it averaged data, then the global feeds the trend. If you look at the screenshot in that referenced post, you'll see the original tilt element, then just to the right of it is the weighted average.

I do not see the interface element for the tilt in your screenshot, it looks like you have new discrete variables displayed, such as "FV1 SG Avg".

can I have it display like normal with both SG and temp in the widget, without a lot of work?:
1597492379138.png
 
Sorry, I see the disconnect here... The Tilt is in the screenshot, but it was disabled at the time. So yes, you can still have the normal Gravity/Temp display.
 
I have a simplified version of the script installed and monitoring.. I guess I will display the original dual input element, and graph the SG Avg and hide the value

1597503671239.png
1597503671239.png

Code:
Add Elements:
FV1 Tilt
FV2 Tilt

Add Globals
FV1 SG Avg
FV2 SG Avg

[setup]
new value CurrSG
CurrSG precision = 0
new value CurrAvg
CurrAvg = 0
new value SGAVG
SGAVG precision = 4
new value SGRAW
SGRAW precision = 4
new value SGUPD
SGUPD precision = 4
SGAVG = 0
SGRAW = 0
new value Tilt
Tilt = 0
new bool FV1bootstrap
new bool FV2bootstrap
FV1bootstrap = True
FV2bootstrap = True



[check_active]
    if FV1bootstrap == True
        //Set AVG to current Tilt value on startup
        "FV1 SG Avg" Value = "FV1 Tilt" SG
        FV1bootstrap = False
    endif
    if "FV1 Tilt" SG > 0.980  //Check if tilt reading is valid
        Tilt = "FV1 Tilt" SG  //capture raw tilt reading
        SGUPD = "FV1 SG Avg" Value * .80  //weight current average at 80%
        CurrAvg = "FV1 SG Avg" Value  //grab current average for calcs
        call calculate
        //update calc display
        "FV1 SG Avg" Value = SGAVG
    endif

    if FV2bootstrap == True
        //Set AVG to current Tilt value on startup
        "FV2 SG Avg" Value = "FV2 Tilt" SG
        FV2bootstrap = False
    endif
    if "FV2 Tilt" SG > 0.980  //Check if tilt reading is valid
        Tilt = "FV2 Tilt" SG  //capture raw tilt reading
        SGUPD = "FV2 SG Avg" Value * .80  //weight current average at 80%
        CurrAvg = "FV2 SG Avg" Value  //grab current average for calcs
        call calculate
        //update calc display
        "FV2 SG Avg" Value = SGAVG
    endif


sleep 300000
goto check_active

[calculate]
//Update rolling gravity average
SGRAW = Tilt * .20  //new tilt reading weighted at 20%
if SGUPD < .5  //make sure 80% average makes numerical sense
    SGUPD = Tilt
endif
SGAVG = SGUPD + SGRAW  //update average

//Update Attenuation
CurrSG = CurrAvg - 1
CurrSG = CurrSG * 1000

return

[end]
stop "Fermentation Calcs"
1597503671239.png
 
interesting issue with graphing... after a while, a graph in a different workspace than the test setup is missing data.. this never happens in the graph in the same workspace. To get it to re-appear, I have to open the graph properties(in either workspace) and close again.. but it just fills int he data gap with a straight line, see how the right half of the red line is smoother than the left, this is where I noticed it happening. the left is my main page, the right is my temp workspace.

Another interesting thing is you see the FV1 SG Avg and FV2 SG Avg are not equal, but they are reading the same tilt... I guess it is just timing, but they are calculated a millisecond after each other, so it seems rare for it to happen... I am going to lower it to 10% input from 20% per cycle and see what happens..
1597518365084.png
 
Having an interesting problem. I am finally testing my 12VDC pump using a MOSFET. MEGA, 12V, and 5V grounds are all tied together. With the pump either at 0% or 100% everything is fine. With any other intermediate value the 1-wire bus acts up giving me intermittent values of -196.6....happens on all 1-wire sensors at no particular interval....I'm thinking ground but they seem to be in order.

EDIT: fixed 196.6 to -196.6 Also, running the MOSFET without the motor load does not cause this issue.
 
Last edited:
interesting issue with graphing... after a while, a graph in a different workspace than the test setup is missing data.. this never happens in the graph in the same workspace. To get it to re-appear, I have to open the graph properties(in either workspace) and close again.. but it just fills int he data gap with a straight line, see how the right half of the red line is smoother than the left, this is where I noticed it happening. the left is my main page, the right is my temp workspace.

Another interesting thing is you see the FV1 SG Avg and FV2 SG Avg are not equal, but they are reading the same tilt... I guess it is just timing, but they are calculated a millisecond after each other, so it seems rare for it to happen... I am going to lower it to 10% input from 20% per cycle and see what happens..
View attachment 694058
I recall you saying somewhere that you are running the 1.1 production release of BC, the graphing issue has been resolved in the latest "test" release. I believe it was an issue with globals not graphing when the graph wasn't on the active workspace.
 
Having an interesting problem. I am finally testing my 12VDC pump using a MOSFET. MEGA, 12V, and 5V grounds are all tied together. With the pump either at 0% or 100% everything is fine. With any other intermediate value the 1-wire bus acts up giving me intermittent values of -196.6....happens on all 1-wire sensors at no particular interval....I'm thinking ground but they seem to be in order.

EDIT: fixed 196.6 to -196.6 Also, running the MOSFET without the motor load does not cause this issue.

Sounds like these are generating noise to the 1-wires. Can you post a pic(s) of how all this is wired?
 
I recall you saying somewhere that you are running the 1.1 production release of BC, the graphing issue has been resolved in the latest "test" release. I believe it was an issue with globals not graphing when the graph wasn't on the active workspace.
ahhh, thank you... I will wait till 1.2, maybe I will try using an inspector, not a global for the time being...
 
Sounds like these are generating noise to the 1-wires. Can you post a pic(s) of how all this is wired?

Question....while troubleshooting this I found that sending %3 to reset the 1-wire, shut my MOSFET module off. I verified this with a voltage reading. Is this by design? 1-Wire is on port 15, MOSFET module is on port 6.

EDIT: I moved the MOSFET to port 13 (a non-1-wire port). It still shuts off with a %3 but I have no intermittent issues with the probes now and the PWM control on the pump is much better on this port.
 
Last edited:
Kinda... when you send that bus reset control command, it initates the startup sequence, which as of a few firmwares ago, scans all the pins up to 15 for a 1-wire device. So it will inadvertently reset any existing ouputs on those pins. I suppose we could add a command to reset just the "last known pin" if needed.
 
Kinda... when you send that bus reset control command, it initates the startup sequence, which as of a few firmwares ago, scans all the pins up to 15 for a 1-wire device. So it will inadvertently reset any existing ouputs on those pins. I suppose we could add a command to reset just the "last known pin" if needed.

No problem, just checking since I'm on 45K and 1.1.9. Makes sense that it still happens on 13 then. Just happy that 1-wire is behaving now.
 
Help me with what I'm seeing here. I have added a Counter Element to port 19 that is connected to a flow meter. It's a basic Hall Effect sensor with the formula F=7.5Q I am getting good count total and rate readings but as I increase my pump speed the rate decreases even though the pump output is increasing. The sensor is horizontally level. The sensor is rated at 1-30L/min and the pump max output is ~13L/min so I'm not exceeding the sensor specs. Any ideas?
 
What FM?

Does this still occur with every other device disabled?

it’s possible you will need to add pull-up resistor in the line to make sure a legit square wave is happening assuming the FM has an open collector on the output.
 
Back
Top