How To: BrewPi LCD Add-On

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.
Soldered up my 3 boards. Gonna put my controller back together this weekend. So what's the cat Jack for?

Nevermind....always go back and read before asking a question.
(NEW) Break-Out Board support: An RJ45 to allow for a remote break-out board. This uses an Ethernet cable (which is straight-through) as opposed to the smaller RJ11 (telephone cord) because phone cords are cross-over by default. The pin-out supports @Thorrak's original breakout boards, however support for remotely placing the heat/cool relays is also included. A breakout board supporting all of this is in development:
  • Pin 1 - Unused
  • Pin 2 - Unused
  • Pin 3 - VCC
  • Pin 4 - OneWire Data (A4 or A0)
  • Pin 5 - GND
  • Pin 6 - Door (D4)
  • Pin 7 - Cool (D5)
  • Pin 8 - Heat (D6)
 
Last edited:
I don't particularly like the breakout board I made FYI ... the intent there was more to demonstrate all of the potential. Still, being able to choose between DuPont or screw terminals as well as have heat/cool LED's in a board that's only 1.21 x 1.96 inches (30.8 x 49.8 mm) is pretty nice. I suspect that I'll make a couple of much smaller boards to allow a person to choose between having either the DuPont or screw terminals and get it even smaller. The idea of the breakout board was @Thorrak's, but I'm not above stealing a good idea. :)

Of course my dumb @$$ bought RJ11 jacks not RJ45 jacks so I'm still waiting for those from China. Right now my test board has pins made from component leads sticking out so I can test.

Incidentally, I tested the new 1.3.1 board with the 0.2.10 RevC firmware. I didn't have any doubts that it would work but I figured I'd answer that question before someone asked it. I also verified that I have the same 185° F/85° C issue at startup that I had with the 0.2.11 and 0.2.12 firmware. Then I tested a bare Arduino with a single temp sensor and 0.2.10, same issue.

The 0.2.10 is the original firmware compiled by Elco (or one of those guys anyway) so this rules out the board and the firmware as a causal item. That's a load off my mind. I was frankly worried that an error was injected somewhere by the new PlatformIO-compiled versions.

So, I have a set of sensors which should be delivered today (thank you Amazon Prime!) from a different vendor to do some more testing.
 
In my mind, this should make the controller call for cooling (since the probes report 24 degrees), but it keeps sitting at "idling" - it doesn't seem to start trying to lower the temperature, and the temperature on the right in the display just keeps showing: --.-
Found a json error - not sure how I managed to introduce THAT but I believe what you are experiencing is related to that. I'll be able to have a look in a couple hours.
Got through all the testing. RevC looks good to go with 1.3.1 with all three firmware versions: 0.2.10, 0.2.11, 0.2.12.

I2C, not so much. When switching between modes via the web interface, the Arduino resets and does not enter into the mode properly. At times it will actually lock up so for right now definitely don't run I2C in production. Damned if I know why that happens just yet but at least I have the fail case figured out. It does work when using the rotary encoder through so it's something about receiving/parsing the json. Fairly certain this means it's firmware rather than hardware but I'm not sure yet.
 
How was that the worst flight ever?
Coming into KC the pilot said he was going to try to "land in between two bands of storms." Well, apparently that didn't work out. They decided to abort approach and while turning we hit an up/down draft and crap went everywhere. Ladies were screaming, kids crying, folks puking ... we diverted from MCI down to near ICT, loitered a bit then back up to KC. The air was still pretty bad at that point crossing maybe 10k but we made it in. Not my favorite flight memory, for sure.
 
Coming into KC the pilot said he was going to try to "land in between two bands of storms." Well, apparently that didn't work out. They decided to abort approach and while turning we hit an up/down draft and crap went everywhere. Ladies were screaming, kids crying, folks puking ... we diverted from MCI down to near ICT, loitered a bit then back up to KC. The air was still pretty bad at that point crossing maybe 10k but we made it in. Not my favorite flight memory, for sure.
That my friend sounds horrible and this is why I drive when I can.
 
I have a few 1.3.1 boards available if anyone in the US is in need. PM me directly with your mailing address and I can mail you one.

These are not 1.3.1a - the main change to the "a" was moving a few silkscreens to make them easier to read. A couple notations got buried under parts in 1.3.1.
 
I forget who was messing with the 0.2.12 I2C code. I just pushed a change (use --beta tag) that will allow it to work. It does not make annotations in the interface when you change modes, but other than that it looks okay. If anyone tests, please let me know.
 
Hey Lee. Been a while since I've posted and it looks like everyone has been a bit baron around here. Question in your new shield. I'm using fermentrack. Should I use the 2.11 firmware? Why I ask is that's what I flashed and I'm seeing the relay but none of the probes. I want to know if I need to check to see if it is my soldering.

And I'm assuming I2C isn't implemented in ferment track yet as I see the I2C firmware at the bottom labeled do not touch.

ETA:. I do see this from your write-up. I'm assuming this has to do with the one wire select pins....when you say you have to choose A0....does that mean jump it to the center pin?
f you want to use the I2C there are two important things you need to keep in mind!
  1. I2C support is a separate firmware image and only available in version 0.2.12. As of right now (6/1/19) this is a beta image, but I should be ready to release it soon. Firmware 0.2.12 requires BrewPi Scripts/WWW v0.5.2.1 which is currently in the Devel branch.
  2. You MUST select "A0" on the One-Wire selector.
When configured for I2C this is technically a new shield definition (I2C). When configured for the parallel LCD it works as an updated RevC.
 
Last edited:
Ok but does that jumper have anything to do with the one wire probes? I'm wondering why they aren't working.
 
Last edited:
Yes, it does, as the probes are the devices actually using the One-Wire bus. With the parallel LCD we use A4, but that pin is used by the I2C interface option. So if you're using an I2C LCD you need to select A0 for the One-Wire bus - and load the I2C-enabled sketch Lee pointed to...

Cheers!
 
I am building my second controller, using Arduino and Cadibrewer's shield. First one I made a while ago, so I forget all the little issues I had along the way and how to fix them.

I got everything hooked up, LCD and rotary encoder in place. When I turn the rotary knob, the backlight shuts off, and the whole thing seems to reboot (I can tell since the Idle Time resets) This happens either direction I turn the knob. The LCD is connected to the shield using all 16 pins in their respective headers. Encoder is configured as follows:

GND —-> GND
+ ——> 5v
SW ——> Pin 7
DT ——> Pin 8
CLK —-> Pin 9


I remember having this issue before, but I forget what the resolution was. Any ideas?
 
Um, my guess is that 5V connection is the culprit.
The encoder switch doesn't require any voltage, just GPIO 7-9 and GND.
There are pull up resistors and noise-reducing capacitors for the GPIO pins on the shield...

Cheers!

[edit] If using a nekkid encoder switch this is the wiring scheme. Purple is GPIO 7 (PB), Blue is GPIO 8 (+), Green is GPIO 9 (-), and Black is GND.

encoder.jpg
 
Last edited:
Cool! I took out the 5v pin and it seems to be working! Weird that my other controller with the same hardware has the 5v pin plugged in for the encoder currently and doesn’t have the issue. But it resolved the problem for this one so I guess that’s what matters ;)
 
Glad that worked out.
If the hardware is identical, I'm gonna guess the other controller's encoder 5v pin wire isn't actually plugged on a 5v source...

Cheers!
 
Is it time? It might be time. Time for something new in the world of BrewPi Arduino. Thanks to @CadiBrewer for putting up with my crazy ideas, a new shield is born!

This is v1.3, code named: "The One Shield." I can't see where we can do anything different with the Arduino Uno. Perhaps most significantly, this shield provides hardware support for an I2C display (there's important information about this below). There are other improvements which I think you guys are gonna dig.

BrewPi Arduino Uno Shield v1.3 (I2C/RevC) Changelog:
  • (NEW) Four-pin I2C header. No more having to use that 16-pin ribbon! A mere 4 wires to connect your display. (Yes, the previous parallel LCD is supported as well.)
  • (NEW) Rotary encoder header - No more having to figure out which Arduino header pins to use! There's also a rotary encoder breakout (thanks @gromitdj!) to make that easier to wire up.
  • (CHANGE) LED headers - The old headers were one pin each for heat and cool, connected to a pull-up resistor. That worked fine with "normal" setups, but the wiring was not straightforward for what I call "mere mortals." And, if you used non-inverted outputs for heat and cool (such as with SRs) you found yourself in a strange position. These headers are three-pin: VCC <-> D5/6 <-> GND. This means if you are using "normal" inverted outputs, you connect your LEDs to VCC and the center pin for either LED. If you are using non-inverted outputs, you connect the LEDs to GND and the center pin for either LED.
  • (CHANGE) Relays: This change re-orders the pins to match the typical relay headers.
  • (NEW) OneWire Selection: One each three-pin header to switch between A0 or A4 for the One-Wire bus. You must use A0 if you are using I2C. Not sure why Elco ever used A4 but that's one of the hard-wired I2C pins for the Arduino so a chance was necessary.
  • (CHANGE) Power: Version 1.2 split the power for the LCD and used the ICSP header to power the LCD backlight to reduce LCD scrambling. By all accounts that had no impact. On some Arduino clones (as well as the combo ESP8266/ATmega328P boards) have the ICSP header in a different place, which ended up requiring jumpers to apply power to the LCD, and/or creating a shorting point with the pins hitting an unexpected place on the controller board. This has been re-combined with the power and ground points looped together to form a single larger bus. In addition, from v0.2.11 of the Arduino firmware, there is a timer which resets the LCD display every 180 seconds to get rid of any scrambling.
  • (NEW) Break-Out Board support: An RJ45 to allow for a remote break-out board. This uses an Ethernet cable (which is straight-through) as opposed to the smaller RJ11 (telephone cord) because phone cords are cross-over by default. The pin-out supports @Thorrak's original breakout boards, however support for remotely placing the heat/cool relays is also included. A breakout board supporting all of this is in development:
    • Pin 1 - Unused
    • Pin 2 - Unused
    • Pin 3 - VCC
    • Pin 4 - OneWire Data (A4 or A0)
    • Pin 5 - GND
    • Pin 6 - Door (D4)
    • Pin 7 - Cool (D5)
    • Pin 8 - Heat (D6)
  • (NEW) Door pins: The original Arduino firmware has support for a contact switch which detects when the door is open. I don't know of many folks using this but adding two pins for that was easy enough since we already put it on the RJ45.
  • (NEW) Alarm: The original firmware has VERY basic support for an alarm (piezo speaker). Right now, it only beeps when the Arduino resets but maybe we can do something more with it later.
  • (CHANGE) Parallel LCD header: Even though the old header was 16-pins, we only used 12 of them. Using a straight 16 was simpler and kept people form screwing things up too bad but we needed the room. So, the parallel LCD header is now split into two 6-pin headers. This does give the benefit of making this connection much easier to route as bending two 6-wire ribbons is a lot easier than a 16-wire one.
  • (NEW) LCD Backlight always-on: If one used the v1.2 board with no rotary encoder or at least a switch, the LCD would time-out and not be able to be turned back on. Added R13 to keep the backlight always-on in those cases. To make use of this functionality, REMOVE R12 and ADD R13.
If you want to use the I2C there are two important things you need to keep in mind!
  1. I2C support is a separate firmware image and only available in version 0.2.12. As of right now (6/1/19) this is a beta image, but I should be ready to release it soon. Firmware 0.2.12 requires BrewPi Scripts/WWW v0.5.2.1 which is currently in the Devel branch.
  2. You MUST select "A0" on the One-Wire selector.
When configured for I2C this is technically a new shield definition (I2C). When configured for the parallel LCD it works as an updated RevC.

Here's some PCB porn:

View attachment 629357 View attachment 629358

I have not yet uploaded the Eagle files to the BrewPi Remix website, but if you want to get a jump on things, get some board quickly (but maybe for a few extra bucks); I've uploaded the files to OshPark (hence the purple board.) The BOM is there as well, including a link to a BOM on Mouser which contains most of the parts needed.

This board should rightfully be considered an Alpha release, since none exist in the wild yet. Three people have reviewed the design however, and it builds on a successful predecessor for the more complicated circuits. I have the boards on order, should be assembling next weekend. I was way too excited not to share in this thread, however. As soon as they are tested, I'll make a release post on the Mega Thread.

As with most things related to electronics on this project, a HUGE thanks to @day_trippr for his original design, his assistance which was given to @CadiBrewer for versions 1.1 and 1.2, and for answering my stupid questions finalizing v1.3.

Hi LBussy,

Great work as always. My BPR setup has been up and running beautifully for a few months now, and I've just about finished the final version of it (a neat one!).

I have an Adafruit I2C OLED, designed to work with the RPi0W. I'm hoping to connect it to the Arduino Uno R3 via I2C, however the onewire bus runs through A4 (I2C SDA pin). Does the firmware you mentioned above (allowing changing from A4 to A0) function without the PCB you designed? And, would I then be able to use the I2C pins for the OLED? I simply want to display the BPR four lines of status (temps, cooling/heating/etc) on this little OLED.

I'm sure I'm missing quite a bit here :D Just trying to avoid having to work out how to display the same data via I2C from the RPi0W. Cheers!

https://www.adafruit.com/product/3527

day_trippr said:
Yes, it does, as the probes are the devices actually using the One-Wire bus. With the parallel LCD we use A4, but that pin is used by the I2C interface option. So if you're using an I2C LCD you need to select A0 for the One-Wire bus - and load the I2C-enabled sketch Lee pointed to...

Cheers!

Man, I need to really learn to read. This is exactly what I want to do. I'll get to it.
 
Last edited:
Yep, like you found, the I2C code looks to A0 automatically.

I have not tested the LCD you mention, so please let us know how it works.
 
Yep, like you found, the I2C code looks to A0 automatically.

I have not tested the LCD you mention, so please let us know how it works.

Ahh great, thanks LBussy.

Just waiting for the screen to arrive, then I'll flash the new firmware and see how it goes. It's 128x32, so I'm wondering if it will display the text infinitely small...
 
Just waiting for the screen to arrive, then I'll flash the new firmware and see how it goes. It's 128x32, so I'm wondering if it will display the text infinitely small...
I mean, my guess would be that it will not work at all ... but who knows? There were some stubs in the original BrewPi that started OLED work. The thing is, I2C took us up to like 96 or 98% flash size and I had to actually shorten some display strings by a few letters here and there to keep it from crashing. I can't imagine being able to shoehorn anything else in there.

This is one that I know works.
 
I would be surprised if one gets literally any response from that display in this application running this code.
It uses a totally different display type - it's an array of pixels and decidedly not character oriented - and thus uses a different controller with a completely different display protocol (and enabling Python library) from the 20x4 displays...
 
I mean, my guess would be that it will not work at all ... but who knows? There were some stubs in the original BrewPi that started OLED work. The thing is, I2C took us up to like 96 or 98% flash size and I had to actually shorten some display strings by a few letters here and there to keep it from crashing. I can't imagine being able to shoehorn anything else in there.

This is one that I know works.

Yes I was originally eyeing off one of those displays on eBay, because it seemed to be an easy fit (and what others had done using GPIO 10, 11 & 13 via shift registers etc) - but I quite like the look of the little one. If I can get it running I'll be stoked, but otherwise will looking into getting it to display the same data via the RPi0W'a I2C pins.
 
I would be surprised if one gets literally any response from that display in this application running this code.
It uses a totally different display type - it's an array of pixels and decidedly not character oriented - and thus uses a different controller with a completely different display protocol (and enabling Python library) from the 20x4 displays...

Ha, trust me to pull the trigger before looking into enough. That's fine, it'll just be a project for a bit later down the teack.
 
After some further research, it seems there is an Arduino I2C (and SPI) librry for the above OLED's chipset (SSD1306) for their varying dimensions (128x32/64), a library for drawing images, and sample sketches available in the IDE. I found this info here, which goes into detail on how to write for sketch the Arduino to display an image on the OLED over I2C (or SPI).

https://create.arduino.cc/projecthub/najad/interfacing-and-displaying-images-on-oled-59344a

That's pretty great! I guess from here it's getting my head round a sketch that includes the required libraries and BrewPi Remix data. I have the BPR brewpi-arduino-uno-i2c-0.2.12.hex file, but obviously that can't be turned back into code.

I don't expect anyone to do anything for me, but any pointers into how I might go about getting the SSD1306 libraries and dependencies into the BPR sketch?

Edit: I realised I already had the source code from Github for brewpi-arduino-uno-revc-0.2.12.hex, and after having a look through I2cLcd.cpp in File Viewer Plus (which seems to be the file/program responsible for running a connected 20x4 LCD), this is well and truly beyond me being able to shoehorn something amongst the code. :eek:
 
Last edited:
I suspect that the libraries for the OLED is more involved than the LCD. Even going from the parallel to the I2C raised the size of the sketch to the point where I had to remove 26 individual letters from strings within the code. That was necessary to prevent crashes. I do not expect that adding OLED code would fit. The OLED code was only added after they started using the new controller.

In other words - unless you like doing things like cutting your grass one blade at a time, I recommend finding a 20x4 LCD. :)
 
I suspect that the libraries for the OLED is more involved than the LCD. Even going from the parallel to the I2C raised the size of the sketch to the point where I had to remove 26 individual letters from strings within the code. That was necessary to prevent crashes. I do not expect that adding OLED code would fit. The OLED code was only added after they started using the new controller.

In other words - unless you like doing things like cutting your grass one blade at a time, I recommend finding a 20x4 LCD. :)

Fair enough. Back to getting the RPi0W to running it then! Or a 20x4 LCD when I eventually give up :smh:
 
Haha, absolutely. I've looked over various parts of the code, but I lack a lot of fundamental understanding on how the multiple files go together. Ah well, my beer stays the right temperature!

I ended up getting and installing a 20x4 LCD (I2C backpack, 2004a) tonight - works nicely. It looks like the LCD screen backlight has a timeout - is there a way to adjust this, or preferably change it to a (hardware) switch? It seems once it times out, I can't get it back on again without a power cycle.
 
There is a backlight timeout. If you install the rotary encoder switch you can wake the LCD up by turning the switch.
Alternatively you can strap the LCD to never blank the screen...

Cheers!
 
Believe it or not, I’m not home right now. Guessing here but I think this is right:

There’s a pin (the rotary encoder PB) that needs to be grounded. Then when you restart the backlight will not timeout. 9 maybe? 7? I forget offhand. :)
 
It's IO7 - but I just confirmed by strapping that pin to GND that it won't work with any BrewPi firmware I've run on an Uno (up through 0.2.10) which look for transitions from the encoder switches.

On my I2C 20x4 displays there's a two position header that usually sports a jumper cap but can be used to hotwire the display backlight...

Cheers!
 
Interesting. You must be watching the encoder pins differently then.
Does your 0.2.12 work with BrewPi "Classic"? I might try it out...

Cheers!
 
Ok, thanks for that guys. Forgive me, but I'm a bit confused - why is a rotary encoder employed for the backlight? Is it just a method to generate a signal the Arduino can recognise that it uses to then switch the backlight?
 
The rotary encoder allows manipulating the mode and temperature settings remotely from the host system (assuming a remoted link ala the Bluetooth I use for all my Uno "minions". I can change temperature right at the chamber if desired; that change will be reflected back to the host for control and logging purposes.

The encoder switch also enables a sensible screen time-out function, as one can wake the backlight again just by twisting the encoder knob (which is otherwise a benign user action)...

Cheers!
 
Back
Top