Native Python BrewPi controller

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.
Hello. That's one way to do it.

Thanks for posting the error message. I think there is a typo or some other problem in your second fuscus.ini file. At the point where the heater relay is specified.

Can you post your second fuscus.ini file?
Thanks AME, I had just hashed out the heat and cool section which is what caused the error. thanks for your help.

If gpis 16 and 18 are used for chamber one which would you recommend for the 2nd and subsequent chambers?

Rich
 
Thanks for your report. I ought to fix the code to either use a sensible default or print a meaningful error message.

You can probably use any pair of GPIOs that are not being used for anything else, which depends on your specific construction and what you plan to add in the future. I chose the defaults almost at random. Only the display needs a specific set of GPIOs, and I chose a specific pin for the rotary encoder push switch because it has a pull-up and can restart the Pi from its reset state.

You should be able to specify only a heater, or only a cooler, if you only want to use one GPIO.
 
I started a new brew with my 'old' controller setup. A friend wanted to see how beer was made (from a kit) and his free time was limited so I just went with the setup I had. I meant to wipe everything and start from scratch, just to test the setup procedure, but I didn't. Sorry.

Anyway, new batch has started and it's working well. There's very little to be done to the software I think.
 
I just read/(skimmed the techy parts) through this. It is very interesting. Any chance a user friendly version will be available in the near future?
 
I thought it was quite user-friendly, but the whole topic is quite technical so it's hard to simplify it without losing a lot of important background information.

Probably what is needed is a detailed set of instructions like Fuzze Wuzze's "How to build a BrewPi controller for cheap".
 
Hi there,

I was reading over this thread today and am very impressed by the effort going into this! I've been meaning to check the spatial spread in temperature in my fermentation chamber, which is already controlled with the typical STC1000 set up, mainly from top shelf to bottom shelf for various reasons. It seems like this software would easily allow me to do it, as I have a raspberry pi laying around and can get the temperature sensors fairly quickly. I'm also familiar with Python/Linux so could hopefully contribute some to the overall project if need be. Let me know what the git project is and I'll start playing around!
 
Well, I bottled the Munton's Highland Heavy on Sunday. It has a very low alcohol, about 3.3%, due to a low O.G. I am not sure why the O.G. was low as I used two cans of extract made up to 23 litres as usual. Anyway, it tastes nice and will be ready to drink in a couple of weeks.

Yesterday I started Black Rock Oatmeal Stout (from New Zealand). I did not reset the Pi or the Fuscus software. Just stopped the Highland Heavy and started a new brew.

I only have one can of Oatmeal Stout extract (it was on special, and there was only one can left) so I made it up to 11 litres and pitched the yeast at 18 degrees Celsius. That'll be my last batch for a while.

I am still very happy with the software. It has only the minimum set of features to function, but it functions well. Thanks to everyone who has tried it and offered bug fixes and suggestions.
 
I am still very happy with the software. It has only the minimum set of features to function, but it functions well. Thanks to everyone who has tried it and offered bug fixes and suggestions.
I'm still planning on coming back to this once I get my ESP8266 remotes working properly. Thanks for sharing!
 
Until now I have asked people to PM me to get the location of Fuscus, just so that I could get to know who was interested and help out immediately if there were any problems. However, it's no secret, and the code has been on Github for about 9 months now. A quick Google search reveals all.

Anyway, for anyone else following this thread I think the software is good enough to try, without having to hunt for it, so here it is:
https://github.com/andrewerrington/fuscus
 
I think I've got this up and running OK although I can't test it yet. All the temperature readings show up and the relay gets triggered as it should.
One thing I wasn't sure about was that all the values in the control algorithm screen are zero and all the values in advance settings are blank and return to blank after a reboot. Should reload defaults enter values here or have I missed a step?
 
Hi there! Thanks for your comment. I am glad you have it going.

I may not have implemented the code that gets and sets the control parameters. I don't remember, sorry. I certainly have not tested it because I didn't want to mess up my brew by fiddling with the parameters.

I intended for Fuscus to report parameters when asked, and accept new parameters, and to write them to a file (representing an EEPROM) so that they would be persistent, but it's untested.

There's also the possibility that Fuscus (which implements the Arduino v2.11 code) is no longer fully compatible with the latest BrewPi code. I have been thinking of suggesting that it should only be used with the legacy branch for that reason.

I'm interested in other opinions. Although it's "finished" I'd like to tidy up a few of the loose ends. Pull requests welcome!
 
I currently have an uptime of 66 days on my Fuscus controller. Today I bottled my Black Rock Oatmeal Stout and set the mode to 'Fridge Constant' and 21°C for bottle conditioning. I'll leave the bottles in the chamber for about 10 days.
 
Hey, you mentioned LCD support, can you expand on that?

Sure. My original design used a Nokia cellphone display, because it was really cheap.

The software maintains a 6-line by 20-character array which represents the content of the LCD screen.

This code is a simple way to write to the display:
https://github.com/andrewerrington/fuscus/blob/master/fuscus/lcd.py

When the display contents are changed, the main code must call the "update" function, which copies the buffer to the actual LCD hardware. Obviously, that is hardware-specific, and will vary depending on what LCD is in use.

The hardware is supported by code here:
https://github.com/andrewerrington/fuscus/tree/master/fuscus/lcd_hardware

Originally I only wrote code to support the Nokia LCD module, but Thorrak added support for the ubiquitous 4x20 LCD module with I2C interface, which you can see in lcd2004_i2c.py

Thorrak also added a note to help other developers add support for other displays.

So, at this point in time you can specify:
1) No display
2) Nokia cellphone display
3) I2C 4x20 LCD module
 
I guess the real question is, what doesn't it do that the original does?

The LCD code should be a direct copy of the code for the legacy branch, with added support for the Nokia display. For other features, the only thing I can recall not working is the device manager. Devices are set up in the configuration file rather than the BrewPi web interface.

In other words, you should be good to go if you use it.
 
I'm assuming that the i2c backpack get wired SDA/SCL to GPIO SDA/SCL (Pins 3/5 Respectively.) Just checking before i do something stupid.

And if that's the case then is there a conflict with the "door switch" based on the schematic or is it a matter of changing pin for the door.
 
I'm assuming that the i2c backpack get wired SDA/SCL to GPIO SDA/SCL (Pins 3/5 Respectively.) Just checking before i do something stupid.

I don't have the pinout in front of me but yes - you should just need to connect GPIO SDA/SCL. You will probably need a logic level shifter though as GPIO runs on 3.3v and the I2C backpack runs on 5v
 
I'm assuming that the i2c backpack get wired SDA/SCL to GPIO SDA/SCL (Pins 3/5 Respectively.) Just checking before i do something stupid.

And if that's the case then is there a conflict with the "door switch" based on the schematic or is it a matter of changing pin for the door.

I can't comment on the LCD wiring, as I don't have that module, but the door switch can be moved. Change the pin number in fuscus.ini (or comment it out for no door detect switch).
 
can't you just wire to 5V instead of 3V? Pins 2 or 4 on GPIO

The Pi GPIO pins are not 5V tolerant. It is possible to damage the GPIO if you hook it up to 5V.

There are a number of webpages about the LCD I2C backpack problem however. Some say "it'll be fine", others say "don't do it!". I did find an elegant solution which allowed the LCD to run at 5V and the backpack to run at 3.3V, which I can probably find again.

It's up to you how you do it...
 
I guess i'm confused, can't you use pins 2 and or 4 to power the back pack (https://www.amazon.com/gp/product/B00NQB4BKK/?tag=skimlinks_replacement-20)

this is the backpack i'm talking about and it's wired to a 20x4.

Right, the LCD module needs 5V, but the backpack I2C chip will run at 5V or 3.3V. Originally they were for Arduinos, which supplied 5V to the backpack which then supplied 5V to the LCD.

If you run the backpack at 5V you will get 5V coming back on the I2C lines into the Pi GPIO.

If you run the backpack at 3.3V then you don't have enough voltage to run the LCD.

The solution is to get a 3.3V LCD (rare) or get a level shifter, or cut the LCD supply trace and feed in 5V separately, or to simply not care.

Here's the article I mentioned about modifying the backpack. It also explains why it's necessary:
http://www.instructables.com/id/Raspberry-Pi-Using-1-I2C-LCD-Backpacks-for-1602-Sc/step2/Explaining-and-fixing-the-incompatibility/

Some people don't think it's necessary.
 
Last edited by a moderator:
Last edited by a moderator:
well, that clarifies things... I think maybe my easiest approach is to de-solder the 5Vline to the LCD form the backpack, wire the backpack to 3V and run a separate line to 5V from the 5V source... amirigh? :)
 
well, that clarifies things... I think maybe my easiest approach is to de-solder the 5Vline to the LCD form the backpack, wire the backpack to 3V and run a separate line to 5V from the 5V source... amirigh? :)

I think that's essentially the same as described in the instructable.

Good luck.
 
As I'm looking at the schematic, don't I need to supply 5v to pin 2 and 15 of the lcd? Or just 2
 
alright, so i got through the installation notes up to the part where it says:
"Edit ~brewpi/settings/config.cfg to change the port setting to port = /dev/fuscus (or whatever you specify in fuscus.ini)"

when I go to config.cfg there is only a "wwwPath" entry... are you supposed to add the port or?
 
also: This, I just uncommented the LCD portion of it and it pooped all over me.

fuscus@brewpi:~/fuscus $ sudo ./fuscus.py
Using config file 'fuscus.ini'
No 'calibration.ini' file or no calibration values present.
Network port: 25518 (not implemented)
No rotary encoder specified.
LCD2004 /w I2C expander specified.
lcd_port = 1, lcd_address = 0x27, lcd_i2c_pin_reverse = 1
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 133, in <module>
LCD_hardware = lcd2004_i2c.lcd2004_i2c(addr=lcd_address, port=lcd_port, reverse=lcd_i2c_pin_reverse)
File "/home/fuscus/fuscus/lcd_hardware/lcd2004_i2c.py", line 148, in __init__
self.lcd_device_write(0x03) # Prepare to switch to 4 bit mode
File "/home/fuscus/fuscus/lcd_hardware/lcd2004_i2c.py", line 211, in lcd_device_write
self.lcd_device.write(tempcomm)
File "/home/fuscus/fuscus/lcd_hardware/lcd2004_i2c.py", line 68, in write
self.bus.write_byte(self.addr, byte)
OSError: [Errno 5] Input/output error
fuscus@brewpi:~/fuscus $
 
Furthermore I feel like the there is no documentation on configuration to make sure fuscus communicates with brewpi. Maybe I'm missing it but after it was done I was like "that's it?"
 
Furthermore I feel like the there is no documentation on configuration to make sure fuscus communicates with brewpi. Maybe I'm missing it but after it was done I was like "that's it?"

Ok, I'll address this point first, but if you set it up as described then really "that's it".

On the fuscus side, in fuscus.ini you specify the port name you want. By default this will be /dev/fuscus

So, in fuscus.ini you will have this:
Code:
[port]
# Define the path to communicate with this instance of fuscus
path = /dev/fuscus

When fuscus runs it will create this path, which, as you can see, is exactly analogous to /dev/ttyUSB0 or /dev/ttyACM0 or whatever an Arduino would appear as when you plugged it in.

So, in the brewpi.cfg file you have to specify the fuscus port instead of the Arduino port.

This is documented here:
http://brewpi.readthedocs.io/en/latest/manual-brewpi-install/config-files.html

Basically, you would edit brewpi.cfg to be:
Code:
port = /dev/fuscus

So, fuscus is listening on /dev/fuscus, and brewpi is talking to /dev/fuscus

Finally, you might have to edit the brewpi source code to properly deal with this kind of port (which is not a real serial port). It's number 17 in the notes file:
If you see an error [Errno 22] Invalid argument from BrewPi then edit BrewPiUtil.py. Add dsrdtr=True and rtscts=True to the ser = serial.Serial line, around line 132:
Code:
ser = serial.Serial(port, baudrate=baud_rate, timeout=time_out, write_timeout=0, dsrdtr=True, rtscts=True)
The background of this bug is here:
https://github.com/bewest/decoding-carelink/pull/171
 
also: This, I just uncommented the LCD portion of it and it pooped all over me.

fuscus@brewpi:~/fuscus $ sudo ./fuscus.py
Using config file 'fuscus.ini'
No 'calibration.ini' file or no calibration values present.
Network port: 25518 (not implemented)
No rotary encoder specified.
LCD2004 /w I2C expander specified.
lcd_port = 1, lcd_address = 0x27, lcd_i2c_pin_reverse = 1
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 133, in <module>
LCD_hardware = lcd2004_i2c.lcd2004_i2c(addr=lcd_address, port=lcd_port, reverse=lcd_i2c_pin_reverse)
File "/home/fuscus/fuscus/lcd_hardware/lcd2004_i2c.py", line 148, in __init__
self.lcd_device_write(0x03) # Prepare to switch to 4 bit mode
File "/home/fuscus/fuscus/lcd_hardware/lcd2004_i2c.py", line 211, in lcd_device_write
self.lcd_device.write(tempcomm)
File "/home/fuscus/fuscus/lcd_hardware/lcd2004_i2c.py", line 68, in write
self.bus.write_byte(self.addr, byte)
OSError: [Errno 5] Input/output error
fuscus@brewpi:~/fuscus $

Ok, this looks fine, but I suspect you do not have I2C support on your Pi. I recommend you get the LCD working independently, just to verify it does work and the Pi can talk to it. Then run fuscus.

The instructable I linked to, for modifying the backpack, has some test code and troubleshooting tips.
 
As I'm looking at the schematic, don't I need to supply 5v to pin 2 and 15 of the lcd? Or just 2

Pin 2 of the LCD module is power for the LCD. Pin 15 is power for the backlight. I think the backpack supplies power to the backlight, but I am not sure where that 5V comes from. Is it routed from the connector to pin 2, or is it routed from the VCC pin from the host (i.e. is it before or after the cut trace you made when modifying the backpack)?
 
Ok, another question. Is there a cron job that needs to be written for starting the fuscus.py every time the pi starts or is that a one time deal? Also, I pulled the pins at the header so I gave it 5v direct. Also, i enabled i2c in raspi-config. Not sure if i need to modify any other files
 
Ok, another question. Is there a cron job that needs to be written for starting the fuscus.py every time the pi starts or is that a one time deal? Also, I pulled the pins at the header so I gave it 5v direct. Also, i enabled i2c in raspi-config. Not sure if i need to modify any other files

After note 17 there is a suggestion for how to make fuscus run automatically at boot. There are many ways to do this, and a lot of people have their own preferred way, however, here's the suggestion:
Note that you can run fuscus in a screen session for experimenting, or you can add the command to start fuscus to the fuscus user's crontab in a @reboot entry. An example @reboot entry which discards normal output and logs everything sent to stderr is:
Code:
@reboot sudo //fuscus.py -c //fuscus.ini 1>/dev/null 2>>/home/fuscus/stderr.txt &

Regarding the LCD, if you can get it going with a test program then it ought to work with the routines in fuscus. There are no troubleshooting tools in fuscus as it is beyond the scope of the software.
 
Pin 2 of the LCD module is power for the LCD. Pin 15 is power for the backlight. I think the backpack supplies power to the backlight, but I am not sure where that 5V comes from. Is it routed from the connector to pin 2, or is it routed from the VCC pin from the host (i.e. is it before or after the cut trace you made when modifying the backpack)?

Ok, most of the backpacks are based on the same circuit, so let's assume this one is typical:
http://www.sunrom.com/p/i2c-lcd-backpack-pcf8574

The LED backlight is powered when the jumper (CON2) is present and the transistor Q1 is on. Q1 is connected to the I2C chip P3, so it would seem that the backlight can be controlled by software. There is a pull-up on the Q1 base connection which I assume will turn the backlight on if P3 is not configured.

The voltage on the Vcc pin of CON2 will depend on the PCB design, whether is comes directly from the Vcc input, or if it goes past pin 2 of the LCD header.

If the backlight LED does not take too much current it won't matter if it is fed by the Pi's 3.3V output or the 5V output.
 
Back
Top