Standalone, Plug and Play Raspberry Pi Headless Brewstand Controller-Server

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.

brewman !

Well-Known Member
Joined
Nov 27, 2006
Messages
2,131
Reaction score
236
This thread is dedicated to the sharing of ideas and development of a standalone, plug and play, Raspberry Pi based headless brewstand controller-server.

Raspberry Pi is the $35 open source ARM based single board computer, generally running Linux.
http://www.raspberrypi.org/

Plug and Play means we want as little soldering and difficult wiring as possible. We will certainly avoid developing a dedicated circuit board if possible.

Standalone means that the board itself does the I/O directly with the hardware as much as it can. We will avoid using a slave micro controller if possible.

Headless means that generally the RPi board will run as a black box, not connected to a keyboard or display. It will, however be connected to at least one other computer via a network.

Brewstand controller means that the purpose of this device is to control the functions associated with brewing beer on a brewstand, ie burner control, kettle temperature monitoring and display, pump control, valve control, brew session timers and clocks, note taking, data logging, etc.

This unit is not intended to monitor a fermentation process. Such a unit would be called a fermentation controller. That is not what we are building here, though many of the components of this device could be used to implement one.

Server means that the device will ultimately serve the User Interface to its functions as web pages viewable in a browser on another computer on the network.

This thread was born out of discussion that occurred in this thread.
https://www.homebrewtalk.com/f235/raspberry-pi-temp-controller-344529/

Let the fun begin !
 
[posted also on the other thread, more appropriate here]

Found this guy in youtube, RPI talking directly with a cheap relay board, without any intermediary board. Also code is shown.

 
Last edited by a moderator:
Just trying to get my head around the options.
Brewman, as you may remember from previous post, I sympathise with using R Pi standalone.
If I understand correctly, on the hardware side, the R Pi, the one wire adapter, and a relay board are the hardware needed to provide temp input and control output?
So, asking the question:
The one wire adapter is close to $20 on its own. An Arduino Uno is about the same.
That said, what development from the Arduino community could be leveraged for this project that would have to be redeveloped with the standalone approach?
PID libraries? Or has Steve 071 who started the initial thread already developed a good solution ( as mentioned in his first post.)
Anything else?

Also, did you buy the pre-potted DS1820 from the same ebay vendor as the one wire adapter? If so, does it seem good quality?
 
Just trying to get my head around the options.
Brewman, as you may remember from previous post, I sympathise with using R Pi standalone.
If I understand correctly, on the hardware side, the R Pi, the one wire adapter, and a relay board are the hardware needed to provide temp input and control output?
Yes.

So, asking the question:
The one wire adapter is close to $20 on its own. An Arduino Uno is about the same.
That said, what development from the Arduino community could be leveraged for this project that would have to be redeveloped with the standalone approach?
I have no idea and frankly I don't care.

Also, did you buy the pre-potted DS1820 from the same ebay vendor as the one wire adapter? If so, does it seem good quality?
I bought raw DS18S20s from Digikey. ~$5 each.

I plan to pot them into various cavities myself. In doing so, I will try to minimize the thermal capacitance of the sensor and maximize the surface area, increasing its reaction time, hopefully lessening the need to use a PID loop in the first place.
 
For those wondering, here is my cost breakdown on this system.

RPi board, $35
4 GB SD card, $8
USB Wifi adapter, $12
Relay board, $10
USB One Wire adapter $17 with the USB dongle, a breakout board and a sensor potted into a short probe.

Additional DS18S20 devices are ~$5 each as needed.
All prices plus shipping. The SD card and Wifi adapter were purchased locally.

Not included in the parts list is a 5V power supply and a case, but I have these built into my stand for other purposes already.

Total cost thus far is $82, plus shipping.

For this you get

- a stand alone computer running Linux (!)
- with Wifi connectivity
- all the relay outputs necessary to run a gas fired brewstand (8x 10A each)
- virtually unlimited temperature inputs, with sensors costing $5 each.
- the ability to serve the UI as web pages
- the ability to keep a small database
- the ability to interface with just about any USB device
- the ability to connect a keyboard and mouse and drive a display monitor
- can be administered remotely via the usual Linux tools, ssh, etc.
- has built in text editor, C compiler, python, Java, window GUI, terminal program, bash, grep, etc.
- could be unplugged and completely re purposed for another function around the house in about a minute.

What were you saying about an Arduino ?
 
Sounds great.
I'm looking for a way I can contribute - but I'm not technical.
That said, I have some experience in usability and functional requirements gathering, with access to a top guy working in the field, and could offer work on the UI side.
Otherwise, I can cheer from the sidelines.
Let me know if there's anything I can do.
 
Sounds great.
I'm looking for a way I can contribute - but I'm not technical.
That said, I have some experience in usability and functional requirements gathering, with access to a top guy working in the field, and could offer work on the UI side.
Otherwise, I can cheer from the sidelines.
Let me know if there's anything I can do.

Glad to have you on the team.

This will be a system that pretty non technical people should be able to set up. The skill set required should be that of burning an SD card from an ISO file, connecting wires from relays to solenoids, gas control valves, motors and wiring temperature sensors. That is it. No soldering, no micro controller programming, no code development, etc.

Something that could really help me time wise is if someone compiled a list (links) of all the available brewing control systems and posted images of what their UIs looked like and knew what functionality they had.

That would be a good place to start when figuring out what we want this system to do. I have not done that yet, except to note that some systems have nice gauges. (In his Homer voice, with eyes glazed over) Mmmm... gauges.

I'll warn you that I am going to get the hardware working with a command line level interface first just because its simpler and an order of magnitude easier to do.

Once its working on that level, I (or someone else) can add in the web server and GUI component.
 
That would be a good place to start when figuring out what we want this system to do. I have not done that yet, except to note that some systems have nice gauges. (In his Homer voice, with eyes glazed over) Mmmm... gauges.


Here is a link to some javascript gauges that run well on the pi. They have just about any type you would like
https://github.com/HanSolo/SteelSeries-Canvas

Here are links to a set of demos...

http://www.wilmslowastro.com/steelseries/demoRadial.html
http://www.wilmslowastro.com/steelseries/demoLinear.html
http://www.wilmslowastro.com/steelseries/demoExtras.html
http://www.wilmslowastro.com/steelseries/demoStopWatch.html
http://www.wilmslowastro.com/steelseries/demoTrafficLight.html
http://www.wilmslowastro.com/steelseries/demoLightBulb.html
http://www.wilmslowastro.com/steelseries/demoLcdSections.html

Enjoy
 
If the UI is intended as a Web Page, then the only one I know, and know reasonably well is the BCS460.
The other UI I've seen a little of is the Brewtroller, but the rotary encoder and smallish LCD display is frankly a big reason to go Web UI in the first place, and I wonder if referencing such systems is all that good a use of time or particularly instructive - since the limitations of the interface drive the process/programming approach considerably.
I'm happy to do some more research though - see a couple of links at bottom.

I would add that the BCS 460's general approach is quite easily understood, and readily configurable to one's equipment. Essentially:
- In 'manual' mode:
A 'state' is specified by the user, and the system adjusts outputs to achieve the 'state'. See the table titled "Manual Mode" in the attached pic.
Using the row for Output1 in the picture as an example, you can see that the temp probe named 'HLT Temp' is associated with Output1 - which, you guessed it, is controlling the HLT. The control method assigned is simple on/off, which will be used to get the temp up to - in this case - 80, and maintain it there. (The control method could also be PWM - handy for throttling back a boil for example, or PID rather than just on/off.)
- Auto mode:
Simply a bunch of manual mode configurations ('states') that are strung together, using 'exit conditions' to specify when to move from one state to another. Exit conditions can be a physical switch, a web UI button, a target temp, or a timer.


(Why not just get one of these? I have on, but as I've mentioned it doesn't suit my needs basically because of cost and klunky UI.)

Here's something else I've found - note the link to the manual:
http://gryphonbrewing.com.au/product_info.php?products_id=512

Here's Kladue's (on this forum). Way more scope, but also an example of a user interface that I think is more complicated as a consequence - at least for what I'd be looking for:


Brewmagic - note the video.
https://brewmagic.com/brew-magic-v350ms-system

700px-Mmode.jpg
 
Last edited by a moderator:
That UI was the old Java one from 4 years ago, the current one is a bit better and .Net. I have moved on from the Opto hardware and am currently working with I2C networked chips to get the same functionality down to 2 - 3" X 4" boards. I have a USB connected I2C setup with 8 AI board, and 16 DI/DO board to play with and sort out the I2C code and IO timing.
 
Those devices can be had much more cheaply on ebay. I bought 50 for under a buck a piece.

I saw some of those sources too. I didn't trust that they weren't 3rd party knock offs or manufacturing line rejects. I'll start with genuine parts from a trusted supplier and consider alternatives once I got them working.

Also, I got the DS18S20s rather than the DS18B20s.

The B series allows one to set the resolution of the response to be finer than the 9 bits (0.5C, 0.7F) that the S series is fixed at. The accuracy on these devices is +/- 0.5C from the factory, so the only way that I could see needing higher resolution is if one applied a correction curve to the output.

At this point I didn't think it was worth it. I'll be happy to get the factory accuracy and resolution working. I'll reconsider things once I do that.
 
Good work collecting info, Yorg.

Do people like the BCS462 UI or could it be improved ? It seems complicated.

The hard part about this part of the project will be designing a UI that is simple and works for what everyone wants to do.

One really neat feature I thought of today is power sharing.

Lets say that people are running a multi vessel electric brewstand and running multiple heaters at the same time. HLT, Mashtun, maybe a boil. Lets say that they don't have enough power to have all three heaters on at the same time. But lets say that none of the processes need full power to maintain temperature, as is often the case. In such a situation, if the controller was smart enough, it could give the boil kettle 50% of the power, the mash tun 20% and the HLT 10%, by simple smart duty cycle sharing, ie not having them all on at once.

However, one would have to give the controller some rules to guide its behavior in those circumstances and they probably change as the brew session advances and then the logic and UI to implement it gets complicated, quickly, at least at first glance.

My approach in these situations is to get something, anything, running ASAP and in the hands of the user and then take what is learned from using it and move the functionality forward. I am not in favor of the "Big Bang" approach where we would try to create the ultimate controller all at once. Get the kernel working, and then add/refine/tune ad nauseum.

Who following this thread intends to get an RPi and relays and sensors and work along with me as we do this ? There is about a month of lead time getting an RPi.
 
The other question that needs to be asked is if I should start with bit banging the one wire bus or if I should use the USB one wire adapter. What do people think they are going to use ?
 
brewman ! said:
Who following this thread intends to get an RPi and relays and sensors and work along with me as we do this ? There is about a month of lead time getting an RPi.

I already have 2 RPi's (knew it was going to be hard to get them so...) and I will be following along. Still need sensors/relays but that is quick and I'll be getting the same items you listed earlier.
 
I agree about getting something up and going and not going for the ultimate controller. But I'd like to say:
Having worked in a para-it role, interfacing between business and IT to develop solutions, I have learned the hard way to have a vision and functional architecture to work to. Without it, a project starts wandering about, gathering functionality, and making additions to functionality difficult because it invariably leads to:

"Gee, if we knew that, then we would have taken a different approach, and it would have been easy to add what you want, but with the current architecture it would mean a big re-program".
On this note I've attached a couple of interface drawings as suggestions - with due credit to the bcs guy for similarities in approach.

How about:
If we comment on these, and arrive at something agreed, mindful to keep it do-able and not going for the big bang, then it would give good direction for you technical types with respect to development approach.
?

So to also respond to your question about the bcs interface - as i've said before, it is clunky, and hopefully the drawings move toward a simpler approach.

Regarding the bit banging question - I think you should collect the complete hardware set and develop from there - especially if we have established that without it the R PI can be 'wonky'.

Re the power sharing - another benefit of the 'step' / state machine approach is that it is probably easier to program, as each state is discrete and allows a % to be allocated per Output for that step.

Kladue - your knowledge and results on a number of things I've seen on this forum are awesome. I'm not sure you have the time to do your own thing as well as contribute here, but with the talent circling this thread, including brewman, adding you would make a great team.

Let me know what you think of the 'step' / state machine approach and the interface itself as suggested in the attached drawings.

Cheers.

edit: clearly not a complete set of 'pages', but not many more would do it.
edit2: Damn, these have been shrunk by the forum upload to be illegible - anyone know how to make them loadable in native resolution?
edit 3: Should I do a video and youtube it, demonstrating the bcs approach live, so you know what I'm talking about better?

UI and function suggestion1.jpg


UI and function suggestion1a.jpg


UI and function suggestion2.jpg
 
That is way more complicated than I had in mind. But the beauty of it is that people can build whatever they want. Don't let me stop you.

I guess it comes down to do we want to automate the process or automate the control ?

For me, I think I'd be happy being able to set the boil kettle target temp to 210F manually when I want and then having the machine take over and possibly do a temperature log. I don't think I want a bunch of pre programmed steps running my brew session. Maybe that is just me.

I'd like to know what the UI for the Brewmagic system looks like. Anyone know it in detail ?

I'll start with building the drivers for the devices so they can be run from the command line. We'll see where we go from there.
 
I am working on I2C hardware at this time, off the shelf IO boards are available, code is not difficult, scan time is 50 ms an analog input, 50 ms to set 16 digital IO, and a USB to I2C interface makes it capable of working with different platforms. When I can get the advanced IO board built and running I should have most of the functions of the Opto 22 hardware on 2 - 3" X 4" boards.
As to a user interface, make it simple, batch info ( malt, water ratio, batch size), mash temps, and schedule, then let the software do the calculating and set point generation. The less that a new user has to do the better the chance of success if they do not have to guess at settings, just enter the recipe volumes and get the answers automatically.
You will need a setup screen for establishing system thermal mass factor, vessel volumes, and temperature/flow sensor tuning, which should be made as simple as possible for the non tech folks.
My 2 cents, the R-PI is a neat board, but you will find that by the time you have invested considerable time, cash, and effort it still takes more hardware than necessary to make it function. While the 1 wire hardware is cheap, it also is extremely limited in function, and scan time is not what I would consider fast.
It seems like it would be time better spent to look at the mini 2440 boards with a touch screen that would form the basis of a standalone controller using I2C IO hardware. That is the direction I am headed as I have the software from previous efforts, just need to finish IO hardware.
 
In a 5 gallon batch (6+ gallons in the boil kettle), why are we concerned about temperature sensor scan times ?

A human is (usually) able to control the burner manually and at the end of a long brewing day my reaction times are in the order of 10 seconds to 10 minutes.

If the thermal mass of the temperature sensor is minimized why do we even need a PID loop ? How many degrees are we expecting the wort/mash to climb after I turn off the burner ? These systems have huge thermal capacitance and almost no thermal inductance that I can see. How much energy can the bottom of the brew pot store ?

I'm going to start really simple and see where it takes me. I'll learn as I go. I'll report everything I learn.

I do not understand some of the approaches people are taking to the problem of controlling a brewstand. Maybe I'll change my views as we move forward. Either way, we need a first step and I'll be taking it in the next couple weeks.
 
Talking about the brewtroller UI, not to forget to mention that a webUI is already on stage for this system

Browse to http:// live.brewtroller.com

There you can input the local ip of the brewtroller and everything is then manageable from this UI

UI developed by a bt user, nice example to see. Different, but useful approach to see.
 
Fair enough Brewman and Kladue.
Look forward to seeing what you develop.
Cheers.
 
Hey goingmad, you sure about that brewtroller link? Not working for me right now.
 
I saw some of those sources too. I didn't trust that they weren't 3rd party knock offs or manufacturing line rejects. I'll start with genuine parts from a trusted supplier and consider alternatives once I got them working.

Also, I got the DS18S20s rather than the DS18B20s.

The B series allows one to set the resolution of the response to be finer than the 9 bits (0.5C, 0.7F) that the S series is fixed at. The accuracy on these devices is +/- 0.5C from the factory, so the only way that I could see needing higher resolution is if one applied a correction curve to the output.

At this point I didn't think it was worth it. I'll be happy to get the factory accuracy and resolution working. I'll reconsider things once I do that.

I've tested about 20 of them so far, and all have been spot-on. As to the resolution, a few bytes of code are all that's needed to use the 9-bit resolution and the resultant increased response time. I tend toward the " better to have it and not need it" philosophy.

I've picked up all of my DS2406+ parts from Digi-Key, as they are not as widely available.
 
What are you guys using to draw the UIs ? I'd like some gauge and vessel jpegs if you have them.
 
I have an R Pi, an Arduino 2560, a handfull of DS18B20's (a couple are hi-temp, thermowell), basic java experience from Android and Arduino coding, and experience in requirements documentation. My R Pi wifi is in the mail. I do not have a relay board or one wire dongle since I was initially looking at the R Pi/Arduino option.

I will be following closely and continue to expand my hardware so I can play better.
 
Very interested to see how the progresses and will help in any way possible. I've been working on an RPi system for a little bit. Tested it last night and seems like it will work well. As of right now I just have an RPi hooked up to a couple of relays, and a simple Python script done over the command line to turn the relays on and off. I run it over an SSH connection from my laptop. The RPi performed better then expected and am excited over the posibilities.

My complete plan for the whole thing is going to be a web interface optimized for running on a tablet. Get a low cost 7" tablet and run the whole brewery from that.
 
My USB one wire adapter (USB9097) arrived today.

Dmesg on my Fedora 17 workstation reports the following.

[] usb 3-2.4: new full-speed USB device number 10 using xhci_hcd
[] usb 3-2.4: New USB device found, idVendor=1a86, idProduct=7523
[] usb 3-2.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[] usb 3-2.4: Product: USB2.0-Serial

uname -a
Linux XPS.localdomain 3.6.7-4.fc17.x86_64 #1 SMP Tue Nov 20 19:40:01 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

The device shipment included a mini CDROM. I have no idea what is on it.

I won't have any time to play with it until Sunday.

Interesting links

http://owfs.org/index.php?page=usb-usb9097

http://owfs.sourceforge.net/index_old.html

Also, Google "Linux kernel 9097 one wire", without the quotes.

I am not sure if I am going to use the owfs package or handle my own IO by speaking directly to the device/senors from my (Python ?) application.

I'm all for Linux/Unix file type I/O, I'm just wondering if it would be faster and easier to speak directly to the temp sensors themselves. It seems overkill to implement a fs just for temp sensors. Then again, that is the Unix/Linux way.

Any feedback here ?

FYI, owfs does not appear in the Fedora 17 stable repository.
 
Very interested to see how the progresses and will help in any way possible. I've been working on an RPi system for a little bit. Tested it last night and seems like it will work well. As of right now I just have an RPi hooked up to a couple of relays, and a simple Python script done over the command line to turn the relays on and off. I run it over an SSH connection from my laptop. The RPi performed better then expected and am excited over the posibilities.

My complete plan for the whole thing is going to be a web interface optimized for running on a tablet. Get a low cost 7" tablet and run the whole brewery from that.

Tablets are very getting very commonplace now. Ditto laptops, especially older ones. They'll make great control interfaces for a headless controller. All they have to do is run a semi current browser.

Given the choice between building a hard wired system using dedicated PIDs and switches in a box or building a headless server system like the RPi setup we are about to embark on, I'll take the headless server system every time. I hate wiring and doing things in software allows so much more flexibility.
 
Here's an option to avoid using/expense of the one-wire bus at all, but still get +/-.25C accuracy.
http://raspberrypi.stackexchange.com/questions/1207/how-to-measure-temperature
The spec sheet link on the page indicates a max of +/-1C variation, but perhaps testing a few and picking the most accurate one would be a good idea.

Just be aware that the I2C bus is meant to be used for relatively short runs, usually a few feet tops, whereas I have tested the 1-wire at distances in excess of 25ft. This may make a difference if you want to keep the RPi away from possible heat/ignition sources.
 
What are you going to do for level sensing, pulse counting for flow with 1 wire?, or are you going to just do digital and temperature sensing only.

I'm not looking for that much automation. I'm only really looking for PID burner control and pump on/off.

Pulse counting and level control sensing (ADC ?) is easily done with a different USB board. There are many GPIO USB boards on eBay and elsewhere.
 
I'm not looking for level sensing either, and I think that falls into the 'big bang' category.
 
Oh yes - use python. (If I have to learn a language then it seems that's the one.)
 
Back
Top