Native Python BrewPi controller

[LBussy]

The uptime for the Pi last time before the PSU flaked out was 41 days. My Pi media centre is usually up for months. There were reliability problems with early Pis, but that is no longer an issue.

I have tried to make the code "multi-chamber" compatible. You can specify an .ini file at startup which contains a different set of GPIOs for the relays and a different set of addresses for the temperature sensors. So, you can do multi-chamber by running several instances of the software on the same Pi.

However, with the Pi Zero being so cheap you could run everything on one of those (web server, data logger, controller) and just have one Pi Zero for each chamber. All on wifi, no BT required. No central controller required.

A Pi is surely a reliable piece compared to let's say a computer desktop. Considering it's only doing the job of running a script and serving a web page or two, it should be. Still, it's not a controller, it is a computer with the ability to act as one. Does that make it a better choice, or does that make it a compromise? Most people who do this work for a living would say the latter.

I would not want to run multiple chambers from one device, because that is a single point of failure for X controlled points. Using a microcontroller per controlled device and then combining the information reduces that risk by quite a bit.

Running multiple Pi means I have multiple web servers to "visit" (and to administer), I'd prefer to have one.

Now combining that idea; using Pi Zero for each chamber and then using a single Pi as a hub to collect all of the information, maybe that has some merit. It's certainly cost effective. You'd have to extend the Python to be a web service rather than a local device (I think you have stubs in there to do that?).

Not arguing, just kicking around ideas.

 

[ame]

My current brew is at 1.021, which is one point above the target on the packaging, so I am turning it up to 21 °C, which is the high end of this yeast's range.

I have had a couple of problems with keeping the temperature constant. Firstly, it's really hot here now, and my Son of Fermentation Chiller is struggling. My ice bottles barely last for 24 hours, and I can't put more bottles in the freezer as it won't freeze them fast enough. Also I went away at the weekend and added a couple more bottles frozen elsewhere, but that was not quite enough for a 36 hour jaunt.

The second problem was a bug in the Arduino code that I reproduced faithfully. In the Arduino an uninitialised variable can be used (which is bad practice). In my code I initialised the variables to 'None' so that I would catch any attempt to use them without initialising them (the code would stop and throw an error). I got this error several times but I couldn't see where the variable was initialised in the Arduino code. I decided to initialise it to zero as it is a reasonable thing to do in this case.

In all, the temperature went up from 17 °C to 18 °C due to the bug and then to 19 °C due to my trip. Rather than bringing it down again I just set the new target temperature to whatever the beer had got to.

Another bug fixed. And another brew almost done. I'll stop after this one until September as I have a vacation in summer that I can't schedule my brewing/bottling around. Plus it will be cooler then.

 

[joebob296]

I saw on github that the last change was made 19 days ago. Has github been updated to reflect the recent bug change?

 

[ame]

Yes.

I also have a pending pull request which adds support for an I2C 4x20 LCD, and a draft setup script. That should be checked in in a couple of days.

 

[sandyeggoxj]

Will it support multiple i2c 20x4 LCD screen? Don't know of hardware limitations on that but I'd love to run a couple different things with their own small displays.

 

[ame]

Will it support multiple i2c 20x4 LCD screen? Don't know of hardware limitations on that but I'd love to run a couple different things with their own small displays.

No. There is no need. In fact, it's not really necessary to have an LCD as everything can be done via the web interface.

 

[Thorrak]

Will it support multiple i2c 20x4 LCD screen? Don't know of hardware limitations on that but I'd love to run a couple different things with their own small displays.

The short answer is "maybe".

I2C is an interesting interface, in that each device has its own address, but each address can only be occupied by one device. The majority of the I2C displays out there (the "Sainsmart" ones) are set to one of two addresses, however, which means that without serious tinkering, you're likely to only be able to support one of these devices at a time.

That said, nothing is preventing you from hooking up an I2C backpack with a different address to your own 4x20 display --- the code supports custom pinouts.

 

[illumina]

Late to the party, but can anyone link me to the github repo?

I have 3+ years in Python/Django land, have 3 different Raspberry Pis, and would love to help this project out..

 

[ame]

Late to the party, but can anyone link me to the github repo?

I have 3+ years in Python/Django land, have 3 different Raspberry Pis, and would love to help this project out..

Not at all. Thanks for your interest. I sent you a PM.

It's not a secret, but I'd rather get to know people who are interested, and get some feedback, rather than just notice someone downloaded the code.

 

[ame]

Hello again. I have the Headcracker sitting at 21 °C in the chamber. Airlock activity has pretty much ceased, but the SG has gone down to 1.018, giving me about 6% abv. I'll check it again in a couple of days, but I expect it's about done. It's hard to bottle stuff during the week, so I'll probably do it next weekend (by which time it really should be done).

The sample tastes delicious! In particular I noticed it doesn't have that ever-so-faint made-with-syrup-out-of-a-can taste.

 

[joebob296]

I've been using ame's software to monitor my beer temp and ambient temp. However, I've been using an stc-1000 to control my fermentation chamber for the previous 2 beers, So I could get used to brewpi. I have not had any bugs/crashes with the software. I ordered some longer sensors, which will be here today. My next beer will be solely using ame's software. I will report back with the results.

Thanks for the help along the way, and for the continuous support to both ame and thorrak.

Edit: just received my sensors and they were not as described, I will be returning them and ordering more. Once I receive them and hook them up I will be using brewpi to ferment.

 

[Bigdaddyale]

https://www.homebrewtalk.com/showthread.php?t=470442

 

[joebob296]

https://www.homebrewtalk.com/showthread.php?t=470442

While I don't have a problem extending them, it's more of an issue that I didn't get what I paid for. I purposefully bought longer sensors so I wouldn't have to do it.

 

[ame]

Hello again. My uptime is 28 days, and the filesystem is stable.

I finished bottling the Head cracker today. Final strength is about 6.3%.

That's the last brew until September. I can't do another before I go on vacation, and it's going to be too hot when I come back. In September I have two more kits to do, plus I can start drinking all this beer that I have made.

I also installed OWFS so that I can read a DS2423 1-wire counter chip, which I am using as a bubble counter. I can query it periodically to get an idea of airlock activity. Don't worry, I'll still check SG.

It would be nice to get the w1_ds2423 driver working, so that I don't have to use OWFS, but that doesn't seem to be the case.

Thank you to everyone who has tried the code. I hope it works for you as it has for me. And thank you to contributors of code- pull requests are always welcome.

Cheers!

 

[gezzanet]

Cool. Would like to see your install of the bubble counter

 

[ame]

I should probably make a new thread about that. I could integrate it with BrewPi, but first I have to get the counting working reliably. The bubbles coming through the airlock are too chaotic and I get 10s of counts when I should only get 3 or 4.

If I just look at the time between events, and ignore the number of counts, then I can get an idea of what's happening, but I'd like something a bit better.

My design is no different to any of the numerous examples on the web, but it's not clear how well they work either.

 

[Thorrak]

Running multiple Pi means I have multiple web servers to "visit" (and to administer), I'd prefer to have one.

Now combining that idea; using Pi Zero for each chamber and then using a single Pi as a hub to collect all of the information, maybe that has some merit. It's certainly cost effective. You'd have to extend the Python to be a web service rather than a local device (I think you have stubs in there to do that?).

Not arguing, just kicking around ideas.

I'm with you on this one - I would argue that one web server (with one/multiple "controller devices") is preferable to multiple web servers, but as it currently stands, the BrewPi software is designed to be one server per chamber.

That said, of course, there is nothing preventing a wholesale rewrite into another language - Python included. To do that, changes would need to be made to the other two components of BrewPi: The BrewPi python polling script and the BrewPi web interface. While I'd personally love to see BrewPi rewritten with Django (and it looks like Elco or a related party may have started down this path at some point) that's a bit more of a project than I have capacity for at the moment. Volunteers?


Separately I'm currently working on what you mentioned - extending the polling script to be a web service rather than only work with a local device. Someone else actually did all the heavy lifting about 6 months ago in an attempt to get WiFI support added for the spark devices, but the pull request was never accepted into the BrewPi master repo. The same code that allows for WiFi support is what is needed to poll internet sockets more generally. I was working on this as part of another project; assuming I can bring that project to a workable state I'll post links to both here.

 

[Manuel]

Did you came across this python based solution?

https://www.homebrewtalk.com/showthread.php?t=569497

 

[ame]

Did you can across this python based solution?

https://www.homebrewtalk.com/showthread.php?t=569497

Yes, I did see it. I chose to go with BrewPi because its behaviour is well-known.

 

[joebob296]

Hello, I just updated to the most recent version of the code using git pull origin master. The update went well, however I get the following errors when trying to start fuscus.py. I am not using an lcd display



Using config file 'fuscus.ini'

No 'calibration.ini' file or no calibration values present.

Traceback (most recent call last):

File "fuscus.py", line 37, in

import ui

File "/home/pi/fuscus/ui.py", line 23, in

import displayLCD as display

File "/home/pi/fuscus/displayLCD.py", line 25, in

from constants import *

File "/home/pi/fuscus/constants.py", line 57, in

port = config['network'].getint('port', 25518)

File "/usr/lib/python3.4/configparser.py", line 937, in __getitem__

raise KeyError(key)

KeyError: 'network'



Any idea as to how to fix this?

 

[ame]

Do you have a fuscus.ini file? There is a sample file you can copy and rename.

It looks like it is trying to read the network section of the ini file, but it's not present. I should make a more descriptive error message.

 

[joebob296]

Do you have a fuscus.ini file? There is a sample file you can copy and rename.

It looks like it is trying to read the network section of the ini file, but it's not present. I should make a more descriptive error message.

Yes, I have a fuscus.ini it has 2 DS18B20's. Does this file get overwritten upon updating? I can rename the sample file and input my sensor id

Edit: just created a new fuscus from the sample file and I get the same error.

 

[ame]

No, fuscus.ini should not be overwritten. There is no file of the same name in the repository (for that reason).

Do you have a 'network' section in fuscus.ini?

I am not in a position to check anything right now. Sorry for the inconvenience.

 

[ame]

Oh dear. It sounds like a bug. Very sorry about that. I'll have to look at it when I get home.

 

[joebob296]

Oh dear. It sounds like a bug. Very sorry about that. I'll have to look at it when I get home.

There is a network section but nothing is there. It's ok I'll install from scratch, isn't to hard.

 

[ame]

Ok. It should look like this:

[network]
# Define the TCP/IP port number to listen for incoming commands from
# the web interface. Default is 25518.
# Currently not implemented.
port = 25518

This setting is not used, but its presence is checked to make sure there is a fuscus.ini file present.

If you re-install from scratch then please do report any difficulties. It helps with bug-fixing and improvements. Thanks.

 

[joebob296]

Ok. It should look like this:

[network]
# Define the TCP/IP port number to listen for incoming commands from
# the web interface. Default is 25518.
# Currently not implemented.
port = 25518

This setting is not used, but its presence is checked to make sure there is a fuscus.ini file present.

If you re-install from scratch then please do report any difficulties. It helps with bug-fixing and improvements. Thanks.

That is exctly how it looks. I deleted the entire user of fuscus and started from step 7. At the end of the install I got the following.

Traceback (most recent call last):
File "/home/fuscus/fuscus/fuscus.py", line 37, in <module>
import ui
File "/home/fuscus/fuscus/ui.py", line 23, in <module>
import displayLCD as display
File "/home/fuscus/fuscus/displayLCD.py", line 25, in <module>
from constants import *
File "/home/fuscus/fuscus/constants.py", line 37, in <module>
from lcd_hardware import lcd2004_i2c
File "/home/fuscus/fuscus/lcd_hardware/lcd2004_i2c.py", line 24, in <module>
import smbus
ImportError: No module named 'smbus'

 

[ame]

Ok, the smbus module is installed by the new-but-rudimentary automated installer:

# python 3 and python3-pip for obvious reasons
# git-core (which is probably already installed) to download the actual Fuscus code
# python-smbus, python3-smbus, and i2c-tools to enable the use of certain LCD screens
sudo apt-get install -y python3 python3-pip git-core python-smbus python3-smbus i2c-tools || die
echo -e "\n***** Installing/updating required python packages via pip3... *****\n"
sudo pip3 install spidev RPi.GPIO pyyaml --upgrade
#sudo pip install pyserial psutil simplejson configobj gitpython --upgrade
echo -e "\n***** Done processing Fuscus dependencies *****\n"

There is no equivalent instruction in the manual setup documentation. Try this:

sudo apt-get install -y python3 python3-pip git-core python-smbus python3-smbus i2c-tools

Thank you for your patience.

 

[joebob296]

That removed the smbus errors. this is the new output of running fuscus.py

File "/home/fuscus/fuscus/fuscus.py", line 37, in <module>
import ui
File "/home/fuscus/fuscus/ui.py", line 23, in <module>
import displayLCD as display
File "/home/fuscus/fuscus/displayLCD.py", line 25, in <module>
from constants import *
File "/home/fuscus/fuscus/constants.py", line 225, in <module>
LCD = lcd.lcd(lines=6, chars=20, hardware=LCD_hardware)
NameError: name 'LCD_hardware' is not defined

 

[ame]

Another bug.

You have no LCD module.

The code around line 92 looks like this:
if lcd_module == 'None' or lcd_module == '':
lcd_module = None
print("No LCD module specified.")


Probably it should have this added:
LCD_hardware = None

So it looks like this:

if lcd_module == 'None' or lcd_module == '':
lcd_module = None
LCD_hardware = None
print("No LCD module specified.")


That's my first guess, but I can't test it. Sorry.

 

[joebob296]

Another bug.

You have no LCD module.

The code around line 92 looks like this:
if lcd_module == 'None' or lcd_module == '':
lcd_module = None
print("No LCD module specified.")


Probably it should have this added:
LCD_hardware = None

So it looks like this:

if lcd_module == 'None' or lcd_module == '':
lcd_module = None
LCD_hardware = None
print("No LCD module specified.")


That's my first guess, but I can't test it. Sorry.

What file would that be in?

Edit: Nvm it's under constants.py

Edit 2: This fixed the problem. Thanks for the help.

 

[ame]

Thanks for your patience. I will fix the main repository so the next person doesn't have a problem.

 

[joebob296]

How long does it take for brewpi to update itself after changing modes? Ive been waiting approximately 1 hr and have it set to beer constant mode. but the LCD display in the top left still says Mode: OFF and Temp. control: OFF I also updated to the most recent code.

EDIT: I attached a picture

 

[ame]

It should be instant.

 

[joebob296]

It should be instant.

To try to fix this, I did a complete install from step 7 creating fuscus user all the way to reinstalling brewpi and I got the same result. I'm restarting Rpi now to see if that helps. At this point of doing a fresh install, I don't know what else to try. And here is where my lack of coding comes into play. I'm at a loss.

Edit: This is the second time I have received this error.

TypeError: unsupported operand type(s) for -: 'NoneType' and 'float'

 

[joebob296]

After the reinstall here is what I get after running fuscus.py

This is the second time I have received this error.

TypeError: unsupported operand type(s) for -: 'NoneType' and 'float'

 

[ame]

Ok. Then it's another bug somewhere. Can you report the full error message please? It will give the module name and line number.

 

[joebob296]

Ok. Then it's another bug somewhere. Can you report the full error message please? It will give the module name and line number.

Sure, here it is

 

[ame]

Oh. That's a new one. I will have to look at it in detail. I am at work this morning, but I should have some time this evening.

 

[joebob296]

Oh. That's a new one. I will have to look at it in detail. I am at work this morning, but I should have some time this evening.

Ok no problem, in the mean time is there a way I can go back to the original github code?