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.
clearwaterbrewer said:
Just an FYI -

in BC V1.1, I could use, but not add devices to my SonOff Dual interfaces. I loaded up the last RC version of BC and added the device I wanted and went back to 1.1 and it all worked... I will upgrade the FW on the SonOff, but they are mounted high up on a wall.
View attachment 626303
Click to expand...

OK, if all else fails, RTFM... I see that the SonOff is not listed in 1.1 manual. doh...

I do hope it is added back to 1.1 in the future, it works now, so counting my blessings, and the devices are a godsend when you want a interface at a remote location and not have to cobble together a power supply and a relay board ... I would be happy to buy new units of a different manufacturer to get ESP32, but I don't see any yet..
 
ver 1.2 request

It would be really great for all Elements to have a new field TextDisplay that is a String.

TextDisplay would replace all of the Name Slots on all Elements and take over all the Appearance Properties of the Name. The Name would only be displayed on the Element Dialog.

For legacy, all names would populate the TextDisplay if TextDisplay is Blank. That could also work for any new Elements.

TextDisplay would not need to unique and is not called by any code. The Name would still be the way to access an Element Property via script. It is just what is displayed on the screen.

For the Appearance Properties, you could write a utility that places all of the Name Appearance Properties in a new TextDisplay Appearance Properties.

That way, I could have as many "Blue Pump" as I wanted on different workspaces (using a Global instead of the Digital Out.

Of course you would have to write some script for the Global to control the Pump, but that would be easy.

I have thought of a way to do that now with the background property and setting the Name to Hidden.
background name.png
 
BrunDog said:
Ethernet devices (Wiznet based) do not have a MAC address hard-coded into the chip or onboard. Therefore, the firmware cannot poll the address - it can only assign it. The units which have a sticker are simply there to tell the user that specific address was reserved for that board (they paid for it). The units which don't require you to generate one, and in doing so, could create a duplicate one, though the risks of overlap are small as most devices will be behind private networks like ours.

So while your idea is a good one, it would not be possible. You mentioned your router found the MAC address, but possibly it found the default MAC in the firmware of AB:BC:CD: DE:EF:FA and IP of 192.168.1.100. WiFi devices do have MAC addresses hard-coded, and those can be polled.
Click to expand...

Fair enough.

How about displaying the IP address on the LCD by default, unless something else is written to it?

That would be really helpful in my case where my WiFi extender seems to change the MAC address of the ethernet card reported inside when running from inside primary ethernet network.

So my WiFi extender connects over wireless, but I have devices plugged into a switch which is plugged into the extender.
 
We could probably do that... would need to think of the implications, if any.

That said, nothing should be changing the shield's MAC address. Maybe I don't understand the issue, but the shield's MAC and IP (if static) should never change.
 
BrunDog said:
Not sure I am following. Are you saying you want multiple elements to be able to use the same name? Or maybe not name but an alias?
Click to expand...

Yes, an Alias is a better name. It would be what is displayed in the Name field of an Element. You could write the element to display the Alias instead of the name if the Alias was not blank. It is possible to do the background trick with everything but a button. Buttons Elements are somewhat easier than a Switch Element on non touch screen as they have a bigger target area.

Not trying to put two digital Outs "Blue Pump" controlling the same Pump, just use a Switch, Button, or Global Element to control the "Blue Pump" digital Out on a different Workspace.

Another advantage is that you could change the Alias on the Workspace and not affect any Script. You would need an "Alias value" property.

For example, you could have a screen where you have a timer. During Mash, the Timer Alias is "Mash Timer", When you switch to Sparging, the Alias could change to "Sparge Timer".

I know you can have different timers, but in my mind rather than having the visibility "hidden" or "visible", an Alias change is would simplify Scripts.
 
BrunDog said:
We could probably do that... would need to think of the implications, if any.

That said, nothing should be changing the shield's MAC address. Maybe I don't understand the issue, but the shield's MAC and IP (if static) should never change.
Click to expand...

If you are assigning static IP address via DHCP, then you need the MAC address. You can grab that from the router list of assigned IP addresses.

Forget about displaying the MAC address on the LCD. That's not important, was just a nice. If not possible, then forget about it.
 
Can anyone comment on max length of PT100 probes? I am looking at around a 4M cable length probe. Is that going to cause any problems with the amps the Arduino can push down the wire?

As an aside, is there any way to read the MAX31865's error fault condition? I am chasing down a temperate readings problem (pretty sure it is related to electrical noise and am investigating shielded probes).
 
I should let others respond, but here is what I know:

1. The probes should be shielded, with the shield tied to ground back at the enclosure.
2. Pt100 are relatively low impedance and will be susceptible to EMI. Shielding, distance from noisy equipment, and length all play factors.
3. No offense, but the cheaper Chinese probes... you get what you pay for comes into play here. No major current down the wire.
4. The amplifier boards should be close to the Arduino with as short wires as possible.

We discard fault data as we don’t have an easy way to process it in the lightweight communication protocol, we could provide a “diagnostic” firmware for you to flush this out though.
 
Man, around in circles I go. I was just talking to a component supplier in Australia who was saying the probe would not need to be earthed, and it would be an earthing problem with the PT100 transmitter (4-20mA converter), which I assume in this case is the MAX31865 board.

The MAX31865 plugs straight into a support board I had built (has ground plane built into it) which plugs straight into Arduino mega headers. So I'm not sure this would be causing problems.. e.g no wires afer MAX31865, all header pins.

I spent about $AU20 Australian so probably still a cheap component.

So should I still be chasing a 4 metre long PT100 probe with shielding built in, which I earth the shielding to the Arduino? because the component guy doesn't think so.

:confused:
 
Last edited:
And the component guy's comment goes against my tinfoil shielding experiment I got my client to do with a 1 metre probe he has on hand.

He "shielded" the temp probe cable in tinfoil, and earthed that out to the Arduino GND pin. Temp probe then worked as per normal.
 
Last edited:
The probe should have a stainless or other, possibly internal, metal jacket. The two, three, or 4 RTD wires run inside that. The jacket terminates to the Arduino ground.

Now that said, the probe end might be grounded to the grounded metal kettles, which could set up a ground loop. Bottom line is wires should be shielded, but termination ends may need to be tested. All grounds ideally should come to one point.
 
The shield being grounded is what I have come to believe, but then the components guy says no, and he made the point of being in industry for 30 years so...

Cool, I will continue to chase down a 4 metre shielded 3-wire PT100 probe and ground it to arduino gnd.

We haven't even placed the PT100 in the thermowell in the fermentor (need long cable) so hadn't got to that point yet. Maybe heat-shrink the probe if the fermentor is grounded (no idea on that)

Awesome, thanks for your help again. I will update my software to use the BruControl API tonight instead of the logs. Initial API testing has worked well and it will be about a 10 minute job to update my in-between software to use the API.
 
When we provide power to the 24V ball valves attached to the cooling system, the temps read straight to -246 and then slowly come back up to actual reading. Like the probe or associated circuit had complete power loss.

I'm wondering whether the existing cooling system and fermentors use shielded 24V power cables, or perhaps don't use RTD probes.

If we run 12V power to arduino and have the temp probe nowhere near the 24V cables, we still get the same problem. The power cables and PT100 cables are nowhere near each other (over 1m apart) in that test scenario and we still get interference.

Any other suggestions other than shielded temp probes? I've been quoted $AU140 for each 4 metre cable, which is a bit of a hit to my client. I'll spring for one cable just to make sure it is going to solve the problem, but he'll still be paying for 2 cables.
 
Last edited:
OK, it is entirely possible (actually probably) the problem is not EMI but is power associated. Therefore the problem may not be occuring via the probe, but via the power supply system. Sorry to beat the horse dead, but I'm guessing without a schematic, models, and/or pictures.

You could isolate the probe by creating a cheap dummy: Attach two short wires to one side and one short wire to the other side of a 100 ohm resistor, then wire to the amplifier. Again, keep these short to reduce antenna effect. Then cycle the valve - if the problem occurs, then you know its in the power supply/feed.

IIRC the valves are 24VDC. They may have a motor which is energized, the dumping that power back into the power bus when switching. It could be your power supply is underpowered, causing a drag on the system when the valve inrush current happens. What is the valve model?

Also, I see tons of braided RTD's on ebay for less than $10. Not sure where the $140 is coming from. No doubt ebay stuff from China is not always the best quality, but you should be able to find something in the middle.
 
Last edited:
That was for a PT100 sheathed in stainless steel braid with a drain wire incorporated hand-built in Australia. Things are always expensive here.

I'll chase up a cheaper braided 4 metre probe on eBay or something. So a probe like this or this. And then solder a wire to sheet to earth out? Problem is I can't find any cheap ones in Aus and delivery from Hong Kong, etc is end of month.

I'm chasing up the models of the pumps, but they were supplied by a Chinese company so I am pretty sure the details won't help you out anyway.
 

Attachments

  • madocke_wiring.PNG
    madocke_wiring.PNG
    14 KB · Views: 32
I hate chasing Temperature Problems. To ground or not to ground, that is the question.

Fortunately my question is simple.
Answered my own question!
 
Last edited:
That schematic is missing the relays. Which brings me to the next test. Disconnect the valves from the relays and cycle the relays via BruControl. Any noise then? What about manually cycling the valves by jumping wires to their switch signal as if you were the relay (take the relay out)?

Let’s take this offline so we don’t clog up this thread. Pls email us. We can then come back here to report the solution.
 
I do not understand how you can or would use a Port for a Different Element:

For Example: My Port 2 is a Hall Effect Counter.

I can still select Port 2 for all of the Outs and as a Digital Input on a New Device.

Are there Restrictions? For example, you could use a Digital Input but not a Digits Out for Port 2 that had been used as a Hall Effect Counter?

It is a good idea to do this? Do you need any addition circuits? Why would you do it?

Just trying to wrap my head around it. Some practical application explanation would be nice.
 
oakbarn said:
I do not understand how you can or would use a Port for a Different Element:

For Example: My Port 2 is a Hall Effect Counter.

I can still select Port 2 for all of the Outs and as a Digital Input on a New Device.

Are there Restrictions? For example, you could use a Digital Input but not a Digits Out for Port 2 that had been used as a Hall Effect Counter?

It is a good idea to do this? Do you need any addition circuits? Why would you do it?

Just trying to wrap my head around it. Some practical application explanation would be nice.
Click to expand...

BC just gives you the flexibility to make whatever each pin/port is capable of. If you have a counter input on a pin, you would likely not create another element on that pin/port. However, if you had a heater element on a pin, you might make a PID Output as well as a Duty Cycle on that port. When you enable one device element, the others on the same port are automatically disabled.

Again, this is just there for ultimate flexibility. We don't tell you you "you have 8 inputs and 8 outputs and that's it"... we are saying "you have 16 I/O - do what you like with them". I suppose we could disable all output creation when a port is defined as an input - but we think you are all smart enough to know this and won't create conflicting I/O inconsistent with the hardware. Make sense?
 
Angus Grant said:
The shield being grounded is what I have come to believe, but then the components guy says no, and he made the point of being in industry for 30 years so...

Cool, I will continue to chase down a 4 metre shielded 3-wire PT100 probe and ground it to arduino gnd.

We haven't even placed the PT100 in the thermowell in the fermentor (need long cable) so hadn't got to that point yet. Maybe heat-shrink the probe if the fermentor is grounded (no idea on that)

Awesome, thanks for your help again. I will update my software to use the BruControl API tonight instead of the logs. Initial API testing has worked well and it will be about a 10 minute job to update my in-between software to use the API.
Click to expand...
in my case I use cheap ebay p100 sensors because I found out of all the different ones Ive bought they are all made by the same 2 manufacturers and most were the same manufacturer as aubrins uses (DTK I believe as they come in a labeled plastic bag) I use these currently on my 3bbl setup
https://www.ebay.com/itm/Waterproof...6b9c:m:mTTq-5qwPOpefFX7RqAmjMg&frcectupt=true

I got temp spikes from noise like elements firing or relays activating or deactivating.. I had to add snubbers in my panel as well as remove the shielding connection at one end of my probe wire... The problem was with the pt100 cable being grounded to both the kettle and the control panel and the heating element also carrying the same ground, it seemed to create a ground loop. I discovered this by accident when plugging in my probe xlr connectors but not connecting the screw ring and therefore not grounding that end to the panel. after months or not being an issue my spikes have recently returned when activating or deactivating my 240v element and main power relays. I assume one of my snubbers is failing?
 
Looks VERY similar to the seller I just bought 4 probes from. Although I could not find any shielded 4m cables, so just bought normal 4m cables and will add the shielding myself.

I'll be looking at adding flyback diodes to all my relays which switch 24V on advice from BrunDog and a crap-ton of Internet research
 
Updated my local software to use the BruControl API to submit target and temp readings to my API.

Tomorrow night's task is to pass down the calculated target temperature based on Tilt gravity readings from my API to my local software and then pass that into BruControl's API.

Fully automated ferments based on automatic Tilt readings according to brewer-defined gravity schedule. :cool:

brucontrol_api.PNG
 
BrunDog said:
BC just gives you the flexibility to make whatever each pin/port is capable of. If you have a counter input on a pin, you would likely not create another element on that pin/port. However, if you had a heater element on a pin, you might make a PID Output as well as a Duty Cycle on that port. When you enable one device element, the others on the same port are automatically disabled.

Again, this is just there for ultimate flexibility. We don't tell you you "you have 8 inputs and 8 outputs and that's it"... we are saying "you have 16 I/O - do what you like with them". I suppose we could disable all output creation when a port is defined as an input - but we think you are all smart enough to know this and won't create conflicting I/O inconsistent with the hardware. Make sense?
Click to expand...
Let's see if I got this:

OK. It is different control methods for the same physical widget attached to the PIN.

Let's say I have a Electric Heater Element in my HLT ("HLT Element")that is connected to an SSR that is controlled by Port (Pin) 24.

I could set up a Digital Out on Port 24 named "Full ON HLT Element"

I could create another PID Control on Port 24 named "PID HLT Element"

I could script that "Full On HLT Element" is on until my HLT Probe reaches 160 F.
I could then change the ednabled of my "PID HLT Element" to True and it would take PID Control of my "HLT Element".
That would automatically cause "Full ON HLT Element" enabled to be False.

I know I could just start with "PID Control" all the way. This may (or may not) be a viable practical use but how it works.

Do I have that correct?


port test.png
 
RiverCityBrewer said:
Yes... I also setup something very similar, but I go between PID and duty cycle.
Click to expand...


Very useful with Electric Kettles. (Strike vs Boil)
I could see the same heating element being under different types of control.

I guess you could use a Digital Input like a Float Switch and Counter on the same port, but with Arduino being so cheap, another Mega is a better idea in my mind.

I cannot think of any good reason to share a port that is SPI.

Thanks. I think I got the concept now.
 

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
Yakima 300

Latest posts

Back
Top