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

[Vebra]

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.

 

[brewman !]

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.

 

[brewman !]

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.

 

[Yorg]

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.

 

[jimmayhugh]

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.

 

[jimmayhugh]

My USB one wire adapter (USB9097) arrived today.

FYI, owfs does not appear in the Fedora 17 stable repository.

It is available in the Debian distro for the RPi.

 

[kladue]

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.

 

[brewman !]

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.

 

[Yorg]

I'm not looking for level sensing either, and I think that falls into the 'big bang' category.

 

[Yorg]

Oh yes - use python. (If I have to learn a language then it seems that's the one.)

 

[ColoHox]

Brewman !, if you have a chance, I have a bunch of questions about your equipment. Also, I think a component/hardware/equipment list would be handy.

What is your brewing setup (Herms, rims, direct fire?)

How many burners/pumps will you be controlling? Will you be using ON/OFF gas solenoid valves or variable output? Natural gas or LP?

Will you use a (SS or mechanical) relay expansion board?
Will you be mounting your electronics to your brewstand?

I'm sorry if these are dumb questions, I am just trying to think ahead. I have done loads of low voltage automation with python, but something about flames, connecting to the mains...all while drinking, scares me.

Thanks for your time.

 

[brewman !]

Brewman !, if you have a chance, I have a bunch of questions about your equipment. Also, I think a component/hardware/equipment list would be handy.

RPi
4 GB SD card
USB Wifi adapter
USB One Wire adapter
GPIO relay board, not USB

What is your brewing setup (Herms, rims, direct fire?)

See here:
https://www.homebrewtalk.com/f51/birth-zeus-non-typical-brewstand-build-368010/

3 kettles + 1 on demand hot water heater.

The kettles are a dedicated direct fire mash tun + 2 boil kettles, each with their own pump.

How many burners

3 plus possibly the on demand hot water heater.

pumps will you be controlling?

3

Will you be using ON/OFF gas solenoid valves or variable output?

On/Off, using real gas control valves, NOT SOLENOIDS.

Natural gas or LP?

NG, but it would be the same thing for LP.

Will you use a (SS or mechanical) relay expansion board?

My relay board has 8 mechanical relays on it, 10A each.

Will you be mounting your electronics to your brewstand?

Yes. Everything goes under the cover on the lower shelf. The cover flips up for easy access. I thought this to be the most unobtrusive place, mostly shielded from water and away from heat.

I'm sorry if these are dumb questions, I am just trying to think ahead.

There is never any such thing as a dumb question, except one that is asked too late.

I have done loads of low voltage automation with python, but something about flames, connecting to the mains...all while drinking, scares me.

Worst thing that happens is that a burner stays on when it shouldn't. The gas control valves make it explosion proof. No pilot = no gas = no boom.

Thanks for your time.

I'm only too happy to give back.

 

[BoxBrewer]

I am having a little trouble understanding the temperature sensors you guys are using... Do they attach with some sort of thermowell or something?

Why not look into something like this: http://www.ebay.com/itm/PC-Laptop-U...or-Data-Log-Computer-/200685562709#vi-content

Edit: Or maybe using an RTD sensor, wiring one of the wires to the data+, the other to the data- from a cut up USB cord?

 

[brewman !]

I am having a little trouble understanding the temperature sensors you guys are using... Do they attach with some sort of thermowell or something?

Nope... err... they will.

The DS18S20 comes in several packages. I am using the TO92ish package, which looks like a little transistor, if you are familiar with them.

They have 3 leads, 5V, GND and data. You can steal power from the data bus only run 2 wires to them if you need to.

I'll be embedding my sensors into pieces of thin wall SS or copper tubing using epoxy and then immersing them into whatever liquid needs measuring. I might install them into various places in a waterproof (wort proof) manner using a compression fitting over the tubing.

I don't like how some people set up "thermowells" as there is a lot of thermal mass between the sensor and the liquid.

I might use copper tubing over SS for better thermal conductivity. If one can reduce the temperature reading lag time enough, one can probably do without a PID control system and use a simple bang bang algorithm. (Insert hopeful look here.)

Digikey.com and other vendors have datasheets for these devices which include mechanical drawings near the end.

 

[BoxBrewer]

I might use copper tubing over SS for better thermal conductivity. If one can reduce the temperature reading lag time enough, one can probably do without a PID control system and use a simple bang bang algorithm. (Insert hopeful look here.)

Digikey.com and other vendors have datasheets for these devices which include mechanical drawings near the end.

Gotcha. I just already am working on a PID setup using RTD sensors, which are nice because they're waterproof and have NPT threads and such. I am trying to teach myself about all this stuff but I am having some trouble understanding all the hardware. I'll be following the thread though, hopefully I can make sense of it all and contribute

 

[brewman !]

Its pretty simple once you see how its done. Stay tuned.

 

[helibrewer]

Ok, so I have my raspi running with VNC, Apache2, php5, FTP, SSH, MySQL, and MyPhpAdmin. I have also connected my Arduino 2650 via usb (dev/ttyACM0).

My relay board has not arrived yet. One wire is running on the raspi but I have not connected any sensors yet to test. Once I get the sensors communicating I will start working on the web interface.

 

[brewman !]

Ok, so I have my raspi running with VNC, Apache2, php5, FTP, SSH, MySQL, and MyPhpAdmin. I have also connected my Arduino 2650 via usb (dev/ttyACM0).

My relay board has not arrived yet. One wire is running on the raspi but I have not connected any sensors yet to test. Once I get the sensors communicating I will start working on the web interface.

Do you need Apache if you use pyWeb ?

I think it would be helpful for everyone to be on the same page as far as the data flow and tools/stack used from raw sensor data though to the web page being served. Otherwise we are going to get a whole mix of technologies and approaches.

Lets assume that everyone agrees to use OWFS. What is your data flow from there to where the data for a sensor is displayed on a web page ?

 

[helibrewer]

Do you need Apache if you use pyWeb ?

I think it would be helpful for everyone to be on the same page as far as the data flow and tools/stack used from raw sensor data though to the web page being served. Otherwise we are going to get a whole mix of technologies and approaches.

Lets assume that everyone agrees to use OWFS. What is your data flow from there to where the data for a sensor is displayed on a web page ?

I may have missed it but I didn't see pyWeb mentioned anywhere in the thread. Seems programming using pyWeb would allow for interaction without a web server but I'm not sure I want to completely bypass the server option. I'll take a look at OWFS for sensor interface.

 

[brewman !]

I may have missed it but I didn't see pyWeb mentioned anywhere in the thread.

It probably wasn't. And I'm not 100% sure what it will and won't do.

Seems programming using pyWeb would allow for interaction without a web server but I'm not sure I want to completely bypass the server option.

I'm not 100% sure either, but setting up Apache seems like a lot of overhead for such a simple function.

I'll take a look at OWFS for sensor interface.

Keep us informed.

 

[helibrewer]

So it appears one needs to choose between the native w1 kernel module or OWFS. From the reading I have done, the GPIO cannot present itself as a physical bus connection required for OWFS. W1 kernel and OWFS are not compatible.

The OWFS direction seems more practical for I2C since I2C is a serial implementation and that's what OWFS likes.

I have been using the DS18x20's on GPIO4 using the native w1 kernel implementation.

OWFS should work with a USB 1-wire adapter since the USB device can act as the physical bus master for OWFS...if you just want to run the sensors to GPIO4 then the kernel implementation works great.

 

[brewman !]

So it appears one needs to choose between the native w1 kernel module or OWFS. From the reading I have done, the GPIO cannot present itself as a physical bus connection required for OWFS. W1 kernel and OWFS are not compatible.

The OWFS direction seems more practical for I2C since I2C is a serial implementation and that's what OWFS likes.

I have been using the DS18x20's on GPIO4 using the native w1 kernel implementation.

OWFS should work with a USB 1-wire adapter since the USB device can act as the physical bus master for OWFS...if you just want to run the sensors to GPIO4 then the kernel implementation works great.

a) Thanks for looking into this and reporting it. The "gotyas" are what make these projects difficult.

b) I'll take your word for your decision(s) until I get a chance to dig in. Others are welcome to joint the fray.

c) Initial impression, I like the thought of doing OWFS with the USB adapter. I think I'll prefer the USB adapter to doing it with the kernel.

Carry on !

 

[BoxBrewer]

This might be a good link for good info on some Linux stuff for people searching this thread.

 

[helibrewer]

My latest dilemma is getting data from the GPIO displayed on javascript gauges. Javascript executes on the client side, I use python to pull GPIO data. Python runs on the server...connecting the two is the the challenge....assuming you want to serve your temperature readings real time over a webpage.

I found a promising little app called pico (not the text editor) which acts as a very simple RPC between JS and python. You can basically call a python script through a javascript in your html page.

I'm no js expert so if anyone knows a better way to pull the data, process it, possibly store it, then serve it up on a webpage, I'm all ears. It looks like the data needs to be pulled with a loop, or possibly through edge triggering to reduce cpu load on the Raspi.

 

[brewman !]

I have not looked at this in any detail at all. I can't make a meaningful comment until I do.

 

[tob77]

I hacked the hmiPhpExampleData data widget from JMWidgets (http://www.jmwidgets.com/index.php/docs/data-widgets-api/hmiphpexampledata/) It works pretty good. I can read and send data to the python server by using any of the JMWidgets embedded in html. It could be cleaned up a lot as I am no js expert. I am willing to share my efforts if anyone is interested. Does anyone know of a good way that we could share code with each other?

 

[helibrewer]

I hacked the hmiPhpExampleData data widget from JMWidgets (http://www.jmwidgets.com/index.php/docs/data-widgets-api/hmiphpexampledata/) It works pretty good. I can read and send data to the python server by using any of the JMWidgets embedded in html. It could be cleaned up a lot as I am no js expert. I am willing to share my efforts if anyone is interested. Does anyone know of a good way that we could share code with each other?

Nice, more reading to do This seems more elegant than what I found.

 

[brewman !]

I love the contributions I see in this thread. Everyone does things differently. More ideas = better outcome.

I'm working on my stand itself today. I'll join the fray when I get a chance.

 

[wdevauld]

Sorry I'm late to the party.

I'd like to help out around here, as I'm in the same boat. Assembling a new rig, and planning on using a pi to keep things in check. Here are a couple of thoughts I had when ripping through the pages:

- There is a One-Wire patch for the rPi, as helibrewer pointed out. This will allow you to use the GPIO pins on the board to poll the bus, as well as freeing up a USB port. It is too late for Brewman !, but it could save future readers $17 for the USB adapter. Furthermore because it is exposed at the kernel level as a file handle you can use epoll/select type programming to watch levels without having to busy wait your CPU or riddle it with sleep(1) s

- I rolled my own temperature sensors. I picked up some DS18B20s and some 'protection tubes' from http://www.brewershardware.com/Straight-Tubes/. I then used some binary thermal adhesive from Arctic Silver (http://www.arcticsilver.com/arctic_silver_thermal_adhesive.htm) to seat the sensors in the end. Testing against a Spectrum industrial sensor I was 0.2 degrees off at 70 Celsius. Considering that is the error tolerance for the 'industrial' sensor at that point, it was good enough for me.

- Those Canvas Steel gauges are sexy. Thanks jimmayhugh, I will be using those in the future. Yes, I think that visualizing data can be sexy.

- I agree with Yorg, use python. It's a bloody elegant language, and most of the libraries are written in python themselves, so no problems porting to the ARM processors on the rPi

- I agree with Brewman ! that a full LAMP stack is way overkill for this purpose. I do like pyWeb, although there seems to be more web servers these days than there are homebrewers. I personally like making the clients do most of the heavy lifting which means that all you provide is static HTML/JS/CSS and then serve up data on demand. I'm not even sure you need to venture outside of Python; you could use the built in SimpleHTTPServer to watch port 80, serve up static files and data and then use the built in pickle as a super simplistic 'database' of historical information. If you can keep your external requirement to just Python, it keeps installation (and customization) very easy.

Let's keep the ideas rolling.

 

[brewman !]

Welcome to the party. wdevauld.

I love where this is going.

I disagree with the one wire kernel driver versus the USB one wire adapter, but I haven't played with either of them yet, nor am I set on either one. So we'll see where this goes.

Here is a one wire open collector (drains) driver (DS2408) that could be use to drive typical brewstand relays, among other things.

http://www.digikey.com/product-detail/en/DS2408S+/DS2408S+-ND/1197414

This device would be handy for people using the One Wire interface for temperature measurement and wanting to drive more relays than the GPIO port on the RPi board will allow directly.