HOWTO - Make a BrewPi Fermentation Controller For Cheap

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.
Status
Not open for further replies.
Anybody want to do a group buy on the pcb and parts? We might be able to get the boards cheaper over at DirtCheap boards.
 
Check the log...

Cheers!

Seems to be doing it's thing, just not showing the graphical representation.

Not sure what the hell happened, has logged previous beers without a hitch. puzzled!

1.JPG
 
very strange. went through all the rPi and BrewPi updates and what not. Reset everything to factory defaults and started a new profile for my beer. 10 minutes in still not seeing the graphical representation.
 
Seemed lake someone had this problem a while back. Is the graph showing up but nothing in it. or does it always say wait and refresh?
 
Always wait and refresh button. Thinking the script is not pointing to the correct location? Or something got somehow misconfigured...
 
After the beer finishes you could try deleting and starting new profile
 
Yeah sometimes when you start a new profile you have to delete it and start it again. it's just a bug that some have from time to time. it may help you in this situation
 
If starting a new brew doesn't work try running the fix permissions script.
Perhaps the update left some files/folders with the wrong settings...

Cheers!
 
My pc is down so had to use the phone. There's an hour of my life I won't get back. When linking to a site that has 100s of products and no search function linking directly to the product may be more useful.

Looked couldn't find it.
Sorry Dude. Read the entire thread. The answer is there. Might want to block off more than an hour.
What's wrong with the PC? BSOD ?
 
It's alive! Everything you loved about the prior shield, this time without the pesky screen scramble. Here's the finished product, a BrewPi with LCD, three probes, a rotary encoder, all running over bluetooth.

Many, many, many thanks to day_trippr for the LCD and Bluetooth projects, and most importantly for all of the guidance while my 10 year old son and I took on building our first board. An equal amount of thanks to Fuzze for the BrewPi building project.

View attachment 349562

Here's the bare board:
View attachment 349563

Soldered up and mated to its UNO buddy:
View attachment 349564

View attachment 349565

View attachment 349566

For those interested in replicating this, here are the Eagle board and schematic files:

https://drive.google.com/file/d/0BwakCoACNDsmTnV2d1hxVFM0akE/view?usp=sharing
https://drive.google.com/file/d/0BwakCoACNDsmVW9XejY1OENXYW8/view?usp=sharing

Here's the corresponding BOM from Mouser. You can find this stuff cheaper if you look, but for someone who wants to click once and buy it all, here you go:

http://www.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=ceca4ae1f4

I should point out that this project wasn't designed to save money over the builds that are already listed here. If you go to oshpark.com to order a board, you'll spend $25 for three. At $8.33 each, plus the adafruit stackable headers, you're not saving any money over buying the UNO protoshield. I built this project because my son and I are having fun dabbling in electronics, and when I looked at day_trippr's protoshield soldering with all of the wires, I figured my chances of getting that right were not great.

You'll still need an LCD screen from Amazon or elsewhere and the bluetooth module if you want that connectivity.

I have one more to make but I'm probably a month or so away from doing that. I'll put together some soldering pics and a how-to for those who aren't familiar with this stuff (like me!) when I get around to building that one.

One caveat - the board does have headers for two LEDs that correspond to the heat and cool cycles as implemented by day_trippr in his build. I intend to put those on my next build with the switches. But since I didn't include them in the first build, I haven't tested the board for those LED headers yet. My apologies if anyone runs into trouble with those.

That looks awesome, great work! And thanks for sharing.

A couple changes I might think about for version 2:
1) screw terminals for the temp probe and relay wires, or at least female headers.
2) female headers for the Bluetooth module so you can just plug it in directly (this depends on your enclosure)
 
Nah, he doesn't want to do either of those.

- Ime, plugging male Dupont pins into female headers is much less reliable than slipping female Dupont sockets over male headers.

- The "Bluetooth" header as is will allow connecting any Bluetooth module regardless of the pinning - which varies from version to version, and it also supports the various esp WiFi modules - which again follow no real standard.

- I hate screw terminals on shields. Too much space used for no real benefit...

I think the board is just fine as is...

Cheers!
 
Nah, he doesn't want to do either of those.

- Ime, plugging male Dupont pins into female headers is much less reliable than slipping female Dupont sockets over male headers.

- The "Bluetooth" header as is will allow connecting any Bluetooth module regardless of the pinning - which varies from version to version, and it also supports the various esp WiFi modules - which again follow no real standard.

- I hate screw terminals on shields. Too much space used for no real benefit...

I think the board is just fine as is...

Cheers!

This ^ exactly.

In an early design, I actually had a female header on the underside of the board. My HC-06 was perfect and fit into it and hung between the shield and the UNO. It was a pretty cool footprint and saved on space in the enclosure and it was more secure than the jumper wires. But when I couldn't get my HC-06 to work (I'm 99% sure this is user error on my part) and ordered a replacement with a different pin layout, I realized the error of that design. You could still use jumper wires in that case, but then you're stuck with the female header and my goal in the first place was to have all male headers.

Version 2 will likely include a header for the rotary encoder. That's the only part that plugs into the female headers on the shield and day_trippr is right, it feels much less secure than the other connections.
 
Nah, he doesn't want to do either of those.

- Ime, plugging male Dupont pins into female headers is much less reliable than slipping female Dupont sockets over male headers.

I've had the opposite experience. The f/f jumper wires I've had tend to be pretty cruddy. I've traced many a circuit problems back to crappy jumpers.
[edit]Ehhrmm, wait a sec.. had to go back and think about when I said to use male Duponts. What I was thinking for female headers for the probes was to be able to hook up probe leads directly to the board, avoiding attaching a f jumper and adding another failure point. This was an offhanded suggestion as an alternative to using a screw terminal and screwing that sucker down tight![/edit]

- The "Bluetooth" header as is will allow connecting any Bluetooth module regardless of the pinning - which varies from version to version, and it also supports the various esp WiFi modules - which again follow no real standard.
Good call, didn't think about different pin outs for the hc's.

- I hate screw terminals on shields. Too much space used for no real benefit...

I love me some screw terminal action! No need to worry about jumpers (jumper problem again) slipping out every time you move or open/close the enclosure. Definitely do take up space though, you're right.

I think the board is just fine as is...

Agreed, but tinkerers can't leave well enough alone.
 
Has no-one tried the legacy_dev branch yet?

It will make flashing from the web interface and even from the install script work again. But I need verification that there a no other bugs before merging it into legacy.
 
Has no-one tried the legacy_dev branch yet?

It will make flashing from the web interface and even from the install script work again. But I need verification that there a no other bugs before merging it into legacy.

I will be doing a reinstall of wheezy and brewpi with the legacy_dev here in a couple days. Haven't had time yet.
 
For those with a heating element, what are you using? I bought a reptile heating cable, but at only 15W, it isn't strong enough. I'm thinking of switching it out for a 100W ceramic heating bulb. Ultimately, I would like to get the brewpi ferm chamber indoors, or at least in the garage, but for the time being it is on the screened in porch where it is subject to wild temperature swings.

Also, I've been trying to figure out the external page thing so I can monitor the temperature while away from the house, but I can't figure out how to access it. I have the index.php [public] and admin.php pages setup that I can access locally. I'm pretty sure I got the port forwarding done on the router by following Uverse instructions. But now I'm confused about how to access my router (?) from outside of my local network. I thought I read that you use some unique IP address which I thought I found, but I could never get it to load properly. I have a domain name that I'd like to push it to, but can't figure out the final step on how to get it there. Do I have to pay for a dyndns thing? Any help would be appreciated.
 
Port forwarding to the Internet is not instantaneous. sometimes it can take hours for your page to push through the router and the ISPs pipe. I don't have uverse so I can't comment on how easy or hard it should be. but in most cases you should see the page come up or at least a loading page that may take forever to load. until you get your server to transverse the router then you shouldn't even worry about a dyndns name. if they gave you a retail rapture to go along with your modem then giving us the model name or manufacturer could help. my netgear router comes with free dyndns service built right in so for me it's a breeze
 
Has no-one tried the legacy_dev branch yet?

It will make flashing from the web interface and even from the install script work again. But I need verification that there a no other bugs before merging it into legacy.

Hi Elkoe. I'm sure you get this a lot but I am super impressed by what you have built. I have a BrewPi I've been using for a few years and I love it. I just built a second one for a friend. I've been beating my head against the wall as I could not get the Arduino to work properly. I spent hours trying to get it to work. I just loaded legacy_dev and now it is FINALLY recognizing the UNO. I still have to configure devices but right now it is looking like whatever you did to legacy_dev has solved my problem at least. Thanks again for everything you've done. Adding the BrewPi to my brewing process has been the #1 biggest improvement to my beer that I have made to date.
 
Hi everyone. I currently have my 2nd brewpi up and running thanks to Elkoe's legacy_dev update. I have my temp probes in ice water. The beer temp is showing 31.7F and the fridge is reading 31.5. I don't have salt in the water and its not under pressure so I assume it can't be below 32F. Is there somewhere in the settings I can accommodate for the error with the temp probes?
 
Hi everyone. I currently have my 2nd brewpi up and running thanks to Elkoe's legacy_dev update. I have my temp probes in ice water. The beer temp is showing 31.7F and the fridge is reading 31.5. I don't have salt in the water and its not under pressure so I assume it can't be below 32F. Is there somewhere in the settings I can accommodate for the error with the temp probes?

If you search googles theres a way to calibrate probes, is it distilled water? Otherwise its likely to have SOME sodium in it...
 
Port forwarding to the Internet is not instantaneous. sometimes it can take hours for your page to push through the router and the ISPs pipe. I don't have uverse so I can't comment on how easy or hard it should be. but in most cases you should see the page come up or at least a loading page that may take forever to load. until you get your server to transverse the router then you shouldn't even worry about a dyndns name. if they gave you a retail rapture to go along with your modem then giving us the model name or manufacturer could help. my netgear router comes with free dyndns service built right in so for me it's a breeze


I was looking at my active IPs on the router and noticed the BrewPi was inactive...even though it's running fine. Then I realized the issue. I bought a plug-in net extender for the house wifi. So instead of being on the 2Wire123 network, the BrewPi is on the 2Wire123_2GEXT. I think if I switch the network on the BrewPi to the base 2Wire123 it will work. But I have it in a place where the base network is not very strong. Is there a way to keep it on the extended network but port forward it through the router?
 
As long as the extender isn't allocating addresses on a different subnet from the lan side of your router it should not cause port forwarding issues. I have three wifi beacons with my fleet of devices scattered among them, but everything is on the same 192.168.1.* subnet, so I can forward to any device regardless of the network topology to it.

One key to this working reliably is to assign fixed ip addresses to any device that you want to reach from the wan side...

Cheers!
 
Back to the shield design and connectivity...another reason I prefer male headers and female Dupont jumpers is the resulting height is at least a half inch lower (probably closer to an inch but I'm a long way from being able to measure it) than sticking male Duponts into female headers.

I would have had to go to a bulkier project box for my minions if I had used all female headers...

Cheers!
 
For reference, this is the extender I'm using. My static IP for the BrewPi is 192.168.1.92 which does not appear active on the router even though it's accessing the internet through the extender.

I'll look back through everything when I get back home tonight.
 
Last edited by a moderator:
I'm going to be moving a BrewPi from my house to my buddies house. I've seen some documentation on the BrewPi forum about how to change the IP but I'm a bit confused. How would I go about changing the IP that was auto-assigned to my BrewPi on my network to a static IP on my buddies network so it will work with his network. I'm not familiar with routers or networking so any newbie help anyone can provide will be GREATLY appreciated as always.
 
I'm going to be moving a BrewPi from my house to my buddies house. I've seen some documentation on the BrewPi forum about how to change the IP but I'm a bit confused. How would I go about changing the IP that was auto-assigned to my BrewPi on my network to a static IP on my buddies network so it will work with his network. I'm not familiar with routers or networking so any newbie help anyone can provide will be GREATLY appreciated as always.

This is from the Raspberry Pints install info, but because you're setting the static IP on the Raspberry Pi and not the BrewPi itself, it works here, too. Basically you have two options. Option 1 - Once the BrewPi is up and running and connected to the Pi, go into your buddy's router settings and have the router assign a static IP address to the Raspberry Pi. Option 2 -- Go into the settings on the Raspberry Pi and tell it what static IP address to ask for. Here're instructions for both methods.

Assign a Static IP

Typically, network devices are assigned an IP via a method called Dynamic DHCP. With Dynamic DHCP, the router assigns each device an IP address from a pool of available ones on a first-come-first-served basis. It’s very useful because it allows for seamless network connectivity. However, it also means that the IP is liable to change over time, which will make administering the Raspberry Pi remotely more difficult.

There are two methods for maintaining the same IP across multiple sessions: 1) Static DHCP on the router, or 2) assigning an IP on the device.

The first method is typically easier, prevents duplicate IP address conflicts, and the IP address is assigned to the network card. The second method is typically more difficult, does not prevent IP address conflicts, and the IP address is assigned to the operating system.

You should only perform one of these. We recommend the first method, if you have the ability do to so.

Method 1:

Open LX Terminal.

ifconfig wlan0

Notice that zero at the end, not an “o”.*Note the line beginning with “inet addr:”. The first set of four numbers if your Pi’s current IP address. Yours is probably similar to “192.168.1.104”, but it may vary a bit.

route

Look for the first line*not beginning with “default”. This line is typically the IP address of your router. For most home networks, this is the same as the IP above, but with a “1” in the last octet (ex: 192.168.1.1).

Open a browser window using any device connected to your network — your desktop, laptop, cell phone, tablet, or the Pi itself (on the Pi, the default browser is Midori). Type the router’s IP into the navigation bar and hit ‘Enter’. You should be welcomed with a login page.

If you purchased your own router, and you didn’t change the password yourself, it’s probably still set to the default. The default username/password varies from model to model, but you can easily look up the default for your model by typing “default password ” into Google. Often, friends or family will set these up for you, so be sure to ask them if somebody helped set up your network.

If your router is a loaner from your internet service provider (cable, fiber, DSL, or satellite company), then a password has probably already been set for you. Sometimes this is provided with a welcome paperwork packet when you signed up (e.g., Comcast); other times this is not provided unless you call and ask for it (e.g., Time Warner). This device resides on your home network, so you have every right to ask for the login/password. If asked why, tell them you want to set a Static DHCP entry — they may even walk you through it!

The location of the Static DHCP settings varies from model to model. You can find a guide to setting up by going back to our Google trick: search for “setup static dhcp ”. Alternatively,*here’s a generic guide.

Give your device an IP address that’s memorable to you. We recommend keeping the first three octets (sets of numbers) in the IP address the same as your router’s IP address.

If you cannot gain access to your router (e.g., on a college campus network), then you can manually assign the IP using the method below.

Method 2:

Open the Debian menu. It’s located in the same place where the Start Menu would be in Windows (bottom left corner of the desktop).

Click “Logout”.*Click “Logout” again on the verification dialog.

Once back at the command line, enter the following:

sudo nano /etc/network/interfaces


Look for the following line:

iface default inet dhcp

You’ll need to change that line, and then add a few after it.


iface default inet static

* *address 192.168.0.86
* *netmask 255.255.255.0
* *gateway 192.168.0.1

“address” is the IP address you want your Pi to have. “netmask” should be left alone unless you know how to subnet. “gateway” is the IP address of your router (see Method 1 to acquire it).

Reboot your Pi

sudo reboot
 
I used www.canyouseeme.org to check my port availability and every port I thought I had opened was still closed. I went through the steps listed here for my specific router. So, for now, the range extender isn't the bottle neck issue. I think I have to get this working first and then address issues with the extender (hopefully, there won't be any).
 
Status
Not open for further replies.
Back
Top