LowBrau morphs into a Raspberry Pi brewbot

It’s been 4 months since I last wrote about my automated brewing project.  LowBrau was meant to be a low cost single-vessel automated step mash and boiling system.  But, although the controller box was mostly complete, I ran into problems when I fried my Arduino.  That and the hellishly cramped nature of my project box (which was designed to sit neatly under the boiling vessel) really put the brakes on mentally for me – I just wasn’t super motivated to push forward.

Although I may have been silent on this one, I have been working on the next iteration of the project for the last couple of months.  It was always my intention to not simply clone the commercially available systems, but to better them where I see a feature that is clunky or limited.  As a result this hiatus seemed like the perfect opportunity to rethink the core technologies of the project.

The biggest change is that I have now decided to ditch the Arduino and base the control box off a Raspberry Pi.  At $35 this little embedded linux computer is vastly more powerful than an Arduino, yet it really isn’t much more expensive than a name-brand Arduino.  It will allow profoundly enhanced functionality.

I also bought a far bigger project box.  Rather than living under the boiling vessel this one will be fully detachable, with all inputs and outputs connected via sockets.  It can happily live on the bench next to the brewbot.  I divided it into two physical sections with an off-cut of PVC square-section drainpipe to separate the high and low voltage components.

I’ll write a bit of commentary about each main component pictured in the photo below…

As I wanted the control box fully detachable the AC power comes in and the pump and element connect via IEC sockets.  I went with snap in mountings rather than ones that require bolts/rivets, so all that was needed was an accurately sized rectangular hole to push them through.

The element and pump are switched by solid state relays.  Mine are Fotek 25DA.  I neither recommend or warn you off them – other than to say that they cost less than $4 each including postage and one of them came dead-on-arrival.  They’re mounted onto the heatsink used in the previous edition of the controller box.

Lastly in the high voltage area there’s the 5V 2A power supply module.  Everything else in the box gets powered off this 5V supply.  The RPi requires 1A, so there’s an additional 1A overhead for all the rest of the bits.

Down the left hand side is the Raspberry Pi (RPi).  The 26 pin general purpose input/output (GPIO) connector is connected to my breakout board via some grey ribbon cable.  I have thrown a very cheap $4 USB wifi (rtl8188cus chipset) on the RPi which will allow the advanced interface opportunities.

The temperature probe attaches via a 4 pin socket on the right.  The probe uses the DS18B20 chipset which is read natively by the RPi using the 1-Wire connector on the GPIO.  In linux the output of this probe appears as a text file for easy reading.  Couldn’t be simpler.

Along with wifi control, I also want to keep the option to control everything through the control box as usual.  I have selected a 20×4 LCD ($5), which provides more screen space than the Braumeister’s 16×2.  This in turn will allow me to implement a more sensible user interface that doesn’t require so many nested menus and laborious button pressing.  The LCD is a standard HD44780 chipset, however I do not connect it straight to the GPIO.  I have soldered to the back an i2c conversion board ($3) which further shrinks the number of IO lines to 2.  It also conveniently takes care of all the contrast potentiometer wiring.  Between this board and the RPi is a level shifter board ($2).  This is necessary because the RPi GPIO all works off 3.3V levels, not the 5V standard.  This board is bi-directional so it pumps 3.3V signals to 5V in one direction and 5V back down to 3.3 in the other.

On a related note, all the other outputs (SSR signals and LED indicators) are passed through a Darlington array (60c).  The 3.3V supply internal to the RPi only has a total capacity of 50mA – so even 3 LEDs would take it beyond its capacity!

The buttons are set with both pull-up resistors and current limiting resistors.  The pull-ups (10k) are required to stop the inputs from floating.  The current limiting resistors (1k) are often left out by people, but they’re a pretty good idea to do it correctly.  If your GPIO is always set up correctly as inputs then you’d never need them, but in the case that they get set erroneously as outputs they prevent them from creating a short circuit between the RPi output and ground.  I have also installed 100nF ceramic capacitors across the terminals of the buttons to hardware debounce them.  A quick circuit diagram is below.

And finally, there’s a speaker and amplifier.  One of the annoyances I find with the Braumeister is the incessant beeping that seems to accompany almost every step of the process.  Yet despite this it can also be surprisingly unapparent when everything has stopped waiting for you to press a button.  I have decided to solve these problems by replacing the buzzer in favour of voice prompts driven off the RPi audio output.  While a flashing status LED will give clear indication that a user input is needed.  The amp is a 5V D-class 3W audio amplifier ($3), which is commonly used in USB speakers and for that reason conveniently runs off my 5V supply and is plenty loud enough.

RaspBMC: Ebay USB IR remote

One of the beauties of RaspBMC is the variety of control methods available to the user.  My first box is connected to an HDMI-capable television and uses CEC to pass control codes from the TV to the Raspi, which is all very neat and convenient.  I also use Yatse XBMC remote on my Android phone because there are lots of benefits to being able to browse titles, select and queue content to watch (it can also be a little more responsive than the TV remote).  I also like the feature where you can browse on your phone and send youtube content to the TV, etc.

But the second box is connected via composite video and so gaining control codes from the remote is not an option.  Until very recently this unit did not have network connectivity either, so control via a phone app wasn’t possible either.  Indeed even though it now does have wifi, phone control as the sole option isn’t exactly the golden solution.  Sure, browsing the library via the phone is much nicer than the blocky, hard to read, low resolution of the TV but for every day tasks like pausing, volume control, etc having to unlock your phone is not super convenient.

So I thought that I’d have a go ordering a really cheap, generic USB IR remote off ebay ($4 delivered) and simply see what happens.  Again this is one of those areas where I have not read any forums posts about whether or not this works but it’s not a high-stakes gamble.

And the answer is that yes it does work.  You’ll need to reboot to get it to recognise, it won’t just hot-plug the same way that connecting a mouse to your PC would.  Many of the common keys are already functional straight away (eg play, pause, arrows, page up/down) and the mouse feature also works.  There are plenty of buttons however that are not assigned, but that should be fairly trivial to work out using a similar approach to detecting CEC commands via SSH and then creating an appropriate entry in /home/pi/.xbmc/userdata/keymaps/remote.xml.

RaspBMC: USB Wifi with RTL8188CUS

I recently built up my second RaspBMC box and due to its location this one really has a need for wireless network connectivity.  Taking a quick look on ebay this is actually a very cheap thing to achieve – indeed, a tiny USB wifi adapter at $4 (including postage) is cheaper than buying a network cable.

The one draw-back is that I have read many forums posts about people having issues with certain chipsets not being supported by RaspBMC out of the box.  In particular was Realtek’s RTL8188CUS, which seems to be by far the most popular (if not completely ubiquitous) chip in these cheap usb wifi sticks.  Most of the posts seemed to me to be a number of months old and in that time the RaspBMC project has come a long a lot in terms of updates.  So, although I have not read anything to say that this problem has gone away, I thought I would commit the measly funds required to buy one regardless and see what would happen.

And so the point of this post… I have tried it with RC4 and the RTL8188CUS chipset works totally fine without the need to install any additional drivers.  The Network Manager add-on was required, however, to get everything configured and connected.  And it’s worth noting that if initial wired network connectivity is a problem there are some pre-built images available which come with this add-on already installed.

Hopefully this post will let others know that it appears that bog-standard ebay adapters are now fine after all and the search for less widely available chipsets is no longer required.

RaspBMC: Samsung remote key codes

In a previous post I detailed the difficulty that I have been experiencing mapping the non-standard key codes implemented by Samsung for my television remote.  In that post I showed how SSH can be used to inspect log files to see what actions are taking place in response to key presses.  While this can be very useful it is not always possible to discover all the key names in order to map them.  So the purpose of this post is to keep a running list of the keys on my remote, whether they are mappable and what their key code is (if I can discover it).  As I find new codes I’ll update the list.

First of all here’s a picture of my remote for reference.  I would seem that plenty of Samsung TV remotes for different models keep the same physical layout but just screen print different labels on the buttons.  If your remote differs from mine only in a minor way it may be worth matching your physical button up with mine and giving the respective code a go.  Certainly on my remote the key codes do not necessarily match the physical label on the button.

So working from left to right, top to bottom I will present each button in the following format: <physical label>,<behaviour>,<key code>…

POWER    tv only  --
TV/DTV   tv only  --
ON/OFF   tv only  --
1        passed   one
2        passed   two
3        passed   three
4        passed   four
5        passed   five
6        passed   six
7        passed   seven 
8        passed   eight
9        passed   nine
-/--     passed   title
0        passed   zero
PRE-CH   ??       ??
+(ch)    passed   pageplus
MUTE     tv only  --
^(vol)   tv only  --
-(ch)    passed   pageminus
SOURCE   tv only  --
v(vol)   tv only  --
GUIDE    passed   guide
MENU     tv only  --
W.LINK   tv only  --
TOOLS    tv only  --
^        passed   up
RETURN   passed   ??
<        passed   left
ENTER    passed   select
>        passed   right
INFO     tv only  --
v        passed   down
EXIT     passed   back
RED      passed   red
GREEN    passed   green
YELLOW   passed   yellow
BLUE     passed   blue
TTX/MIX  tv only  --
P.SIZE   tv only  --
DMA      tv only  --
E.MODE   tv only  --
CHLIST   passed   livetv
SUBT     tv only  --
<<(rew)  passed   reverse
PAUSE    passed   pause
>>(ffwd) passed   forward
REC      ??       ??
PLAY     passed   play
STOP     passed   stop

RaspBMC dual card risk mitigation strategy

Recently the RC5 update came out for RaspBMC.  Unfortunately for me (and others) this update completely boned what was a perfectly functioning RC4.   It all started during the update process when my system got stuck in an endless loop of RaspBMC logo, XBMC time-out screen and install progress bar.  Even after a fresh install (ie loosing all my library database, custom keymaps, etc) it’s still horribly flakey – a scan to sync files with tvdb, etc causes the system to hang, the network drops out and the GUI freezes and gets covered in terminal text with clockwork regularity.

It must be said that this project is well and truly up the hobbyist end of the open-source community spectrum and quality control is not exactly robust.  It is after all basically one guy’s hobby putting it together (and what a great guy for doing it!).  But this doesn’t reduce the frustration when you go to use your media centre only to find it’s auto-updated itself into a flaming heap.  Yes, that’s right: auto-updates are turned on by default.

I can’t help but think that the responsible course of action would be for them to distribute the system with auto-update turned off by default and for the RaspBMC website to list prominently on the necessary hardware page a recommendation to run two SD cards – a primary and a test card.  Having just visited the local supermarket this is exactly the operating model that I plan to adopt.  This way the current system can be duplicated onto the test card, the update applied to it, it can be run in for a day or two and then if it all works okay it can be kept.  Should it all grind to an awkward halt then it’s super easy to simply swap the cards back like nothing ever happened.

I fully acknowledge that this project is still very much in the embryonic development stage, but users should be encouraged to treat it as such – and that involves treating updates with a high degree of skepticism until shaken down, to maintain a robust backup strategy and not to rely on the irreversible inbuilt auto-updaters.  Yet this isn’t the how it comes across in their documentation – if anything the opposite: the auto-updater has its praises sung and the files needed to install previous versions are not officially provided (I got my image file from a bloke on the forums!).

By officially encouraging the use of two cards (which let’s face it costs loose change) all the potential bad-blood from a premature code release is completely negated.  For me, if I manage to get one other user onto the dual-card system without having to find out the hard way then this post has been worth it.