BrewPi Remix – What’s Old is New Again

Homebrew Talk

Help Support Homebrew Talk:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
BrewPi Remix Feature/Bug Release 0.7.0

When I decided to embrace semantic versioning, I knew I would have strange choices to make. I did not realize that it would be the very next release that caused my issues. While to the end-user, this release may seem more of a bug fix, on the inside this is a significant/feature release.

The most important aspect of this release is moving the Python3 pip environment to a venv and requirements.txt format rather than the original root install. The effect should be a much more stable environment and less potential impact from other packages and solutions.

Upgrading

Existing users of BrewPi Remix 0.5.3 and above may upgrade with:
Code:
sudo /home/brewpi/utils/doUpdate.sh
If you are not on version 0.5.3 or above (or if you have no idea what version you are on,) use the following command to upgrade to the latest version:
Code:
curl -L upgrade.brewpiremix.com | sudo bash
This must be run from within your /home/brewpi directory, or from each chamber directory in multi-chamber mode.

Combined Release

This release includes several changes across the repositories. Notable among these are:

Tools
  • Fix udev setup for multi-chamber installations
  • Skip flashing controller if none was detected during multi-chamber setup
  • Support Python3 venv setup
Scripts
  • Address logging errors/choices
  • Use Python3 venv setup. The venv must be activated if for some reason you wish to execute BrewPi or its Python tools from the command line. Execute . /home/brewpi/venv/bin/activate (pay attention to the leading ".") to activate the venv (or as user brewpi, you can just issue the command activate.) To deactivate, type deactivate.
  • Increase temp and SG resolution displayed on Tilt Pro
  • Add config items to clamp SG and temp values displayed. These can be set in the config.cfg and need to be entered in the current temperature format.
  • Move to public aioblescan library and re-write Tilt.py.
WWW
  • Re-format multi-index layout to match the functionality of the chamber index
  • Increase temp and SG resolution displayed on Tilt Pro
  • Externalize some common code blocks
One Release, Three Parts

As always: BrewPi Remix, like BrewPi before it, is made up of several different packages. Therefore, it is in separate GitHub repositories. The scripts I have provided abstract much of this from the end-user, but sometimes it is important to know.

Thank you!

Thank you to @bloombrews who pointed out an issue with the multi-chamber setup.
 
Just a little update: I am switching name registrars, DNS and web hosts so I am SURE I will screw that up somewhere. :p

If you notice any issues getting to any of the hosted or DNS options, post here.
 
0.7.2 Bugfix Release

This release addresses the following:
  • Clone all branches of a repo on install to allow switching between branches
  • Addresses a condition where users with a Tilt configured, but no Tilt present would experience a crash
  • Addresses a condition where Tiltbridge sending a NULL packet would crash the script
I'm also addressing an issue where the 0,7.0 tag was not applied correctly in the repos, which will result in a large number of changes seemingly part of this release.

Upgrading

Existing users of BrewPi Remix 0.5.3 and above may upgrade with:
Bash:
sudo /home/brewpi/utils/doUpdate.sh
If you are not on version 0.5.3 or above (or if you have no idea what version you are on,) use the following command to upgrade to the latest version:
Bash:
curl -L upgrade.brewpiremix.com | sudo bash
This must be run from within your /home/brewpi directory, or from each chamber directory in multi-chamber mode.

"Hey Lee, what about release 0.7.1??!"

... that's not important right now.
 
What's the command for a new installation? :D

[If I can ever finish up converting all of the peecees in the house to Windows 10 Pro I will get to ^this^]

Cheers!
 
Hi, I've been using an old brewpi for a few years. Thinking that one day I might have problems, I have searched for update information until I reached this thread. I also found threads about brewpisless and fermentrack. I am not very clear about the direction to follow and I wonder if I could guide myself with the basic doubts to follow one path or another. I do not extend myself further in case this is not the right place for these queries, if you think that this question should go elsewhere I will be happy to do it where you indicate. I thank you in advance for your attention.
blau
 
Welcome to the thread!

While derived from the original BrewPi, both Fermentrack and BrewPiLess are rightfully different products. BrewPi Remix is very close to the original and would feel most familiar to you.

While there are ways to "upgrade" I would caution against that. As a matter of fact, if you have an older installation I would suggest starting with a fresh version of the operating system as well. If you've forgotten how the Raspbian website has very good step by step instructions.

Keep in mind you will lose your old brew charts and anything else you have on your Pi. Unless those are important to you for some reason, BrewPi will not need them. You could also get a new SD card and start with that if you want to keep the old one for any reason.

Once you have Pi up and running, all you need to do is enter the following line in the terminal:
Bash:
curl -L install.brewpiremix.com | sudo bash
That will guide you through the installation.

There's no immediate need to upgrade your Arduino, and that will help ensure your devices stay set up correctly. If it's very old that might go sideways, so please feel free to post here with any issues.
 
Thanks for your interest. I extend myself a bit to better guide my position.
- Now my equipment is working correctly with a raspberri pi b + and 1 arduino uno. The operation is stable and I have a backup copy of the sd saved on my pc.
- With the system working, I think I could invest in a new team, work on it and once configured, use the old one for something different or to have a backup in case of disaster.
The first doubts are:
- I see the current team has a clock lag. When I do a fermentation I am careful to correctly update the time and check it if I have to make adjustments in long programs (lager). Is this still a problem or can new computers update the time via the internet?
- My team is not in my house. To check it I have to connect through another pc connected to the brewpi network through teamviewer (or vnc, anydesk ... etc). I should be able to install some of these software directly on the raspberry but I have not succeeded, I am inexperienced and the error messages I could not decrypt. I thought the system was too small and this is one of the reasons to think of a new raspberry. I'm right? What board and minimum memory would I need?
- Another reason for updating would be to also control 2 other freezers in which I do the rest of the processes. I saw a long time ago that I could do this with brewpi but users reported problems and I did not want risks. Today these other equipments work with 2 thermostats. I see that both brewpi remix and fermentrack manage different teams with a single Pi, but I can't see the difference between them to choose one path. Although fermentrack seems modern and uncluttered, the classic look of brewpi remix is not a bother for me, what is the strength of each one to decide what to install?
Well, I think that when I clear up these first questions, I can keep thinking about the next ones. So this does not become eternal.
By the way, excuse my English. I have to help myself with google to write well from my Spanish.
 
my equipment is working correctly with a raspberri pi b + and 1 arduino uno. [...] I thought the system was too small and this is one of the reasons to think of a new raspberry. I'm right? What board and minimum memory would I need?
I use a Pi 2B for testing. The Zero W works as well. That said, these are not expensive computers and many things are more enjoyable with a little more. I'd recommend the 3B+ as a basis for these projects, just because having the WiFi and Bluetooth on the board is easier, and after all, faster is faster, right?

I see the current team has a clock lag. When I do a fermentation I am careful to correctly update the time and check it if I have to make adjustments in long programs (lager). Is this still a problem or can new computers update the time via the internet?
If you set the timezone in raspi-config, it should update on boot. There are two choices to keep it synching, either ntp or systemd timesyncd. Check both of the following and see which one is running:
Bash:
sudo systemctl status ntp
or
Bash:
sudo systemctl start systemd-timesyncd
When you figure out which one, a little Googling should help figure out what's going wrong, or you can tell us what you find.

My team is not in my house. To check it I have to connect through another pc connected to the brewpi network through teamviewer (or vnc, anydesk ... etc). I should be able to install some of these software directly on the raspberry but I have not succeeded, I am inexperienced and the error messages I could not decrypt.
I recommend remote.it for the Raspberry Pi.

Another reason for updating would be to also control 2 other freezers in which I do the rest of the processes. I saw a long time ago that I could do this with brewpi but users reported problems and I did not want risks. Today these other equipments work with 2 thermostats.
Yes, BrewPi Remix can do this (as well as others). You still need a controller per chamber (but only one Pi.)

I see that both brewpi remix and fermentrack manage different teams with a single Pi, but I can't see the difference between them to choose one path. Although fermentrack seems modern and uncluttered, the classic look of brewpi remix is not a bother for me, what is the strength of each one to decide what to install?
I am biased of course, but I am pretty familiar with both. Fermentrak and BrewPi Remix will use the same controllers, so it is ultimately about which interface you prefer. BrewPi Remix will treat each chamber separately (although on the same Pi) and Fermentrack uses a completely different system.

Both systems will also run on the same Pi although you would need to install Fermentrack first and then BrewPI Remix, as otherwise, Fermentrack will clobber the installation.
 
I use a Pi 2B for testing. The Zero W works as well. That said, these are not expensive computers and many things are more enjoyable with a little more. I'd recommend the 3B+ as a basis for these projects, just because having the WiFi and Bluetooth on the board is easier, and after all, faster is faster, right?

-- Ok, I'm going to check prices. like you say, it's not a lot of money. Even between 3+ and 4 is little difference. I study it and start by buying one of them. As soon as the investment is made there is no going back. :)

If you set the timezone in raspi-config, it should update on boot. There are two choices to keep it synching, either ntp or systemd timesyncd. Check both of the following and see which one is running:
Bash:
sudo systemctl status ntp
or
Bash:
sudo systemctl start systemd-timesyncd
When you figure out which one, a little Googling should help figure out what's going wrong, or you can tell us what you find.

-- I test these commands and how they work. Thanks.


I recommend remote.it for the Raspberry Pi.

-- I study this service. I read it in an entry on your blog and had this pending issue.


Yes, BrewPi Remix can do this (as well as others). You still need a controller per chamber (but only one Pi.)


I am biased of course, but I am pretty familiar with both. Fermentrak and BrewPi Remix will use the same controllers, so it is ultimately about which interface you prefer. BrewPi Remix will treat each chamber separately (although on the same Pi) and Fermentrack uses a completely different system.

Both systems will also run on the same Pi although you would need to install Fermentrack first and then BrewPI Remix, as otherwise, Fermentrack will clobber the installation.

-- I had seen your collaboration with Fermentrak, and this helps to ask about both. It is important to try not to offend those who offer their work for free. The first idea was to buy two sd cards (today also its price is accessible and I can use it for something else) but perhaps a first basic installation of the two things will allow me a quick comparison. I already have new tasks to do. It's my fault for asking ... Thanks, I promise to keep bothering you.
 
Hello, Regarding the relays, I think I will use ssr. I have them in my current installation and although they may not be necessary they give me more peace of mind to act with the freezer compressors. Regarding the new equipment that will replace the arduino uno, if I need a recommendation. I see: NodeMcu, ESP 12E, ESP 32, ESP 12 MINI ... etc, can you put light on this? And about its consumption? I still have to think if I'm going to feed them individually or a feeder for the 3 that I'm going to use (I think the "Uno" from the old equipment will be used with the rest of that system for testing.) Thanks.
 
Your current choices are the Uno and the ESP8266 (generally the Wemos D1 Mini is used). The ESP8266 is, of course, WiFi capable, however, some soldering is necessary. It's easiest with one of the shields (the design for which is in the GitHub repos). The Uno can be done from start to finish without soldering, even with a rotary encoder and LCD. The ESSP8266 does not support the rotary encoder. You can make the Uno wireless either with WiFi or Bluetooth with some added hardware.

Most people would recommend that you supply power independently no matter what, but I run two Unos from my Pi with no apparent issues.

The SSR is fine, they have to be set up as "non-inverted" with a slightly different wiring configuration.
 
Your current choices are the Uno and the ESP8266 (generally the Wemos D1 Mini is used). The ESP8266 is, of course, WiFi capable, however, some soldering is necessary. It's easiest with one of the shields (the design for which is in the GitHub repos). The Uno can be done from start to finish without soldering, even with a rotary encoder and LCD. The ESSP8266 does not support the rotary encoder. You can make the Uno wireless either with WiFi or Bluetooth with some added hardware.

Most people would recommend that you supply power independently no matter what, but I run two Unos from my Pi with no apparent issues.

The SSR is fine, they have to be set up as "non-inverted" with a slightly different wiring configuration.
Hello, I have added the ESP8266 to my shopping cart, soldering is not a problem for me. As for the Rotary, I have never really liked it. An ldc if it could be necessary, I still doubt, the price is low. Do you need extra hardware or programming or just plug it in? Any specific model?.
by the way, can you upload some screenshots to see how the different cameras are chosen? or is it another browser tab with another address all in duplicate?
Thanks again.
 
Last edited:
As for the Rotary, I have never really liked it. An ldc if it could be necessary, I still doubt, the price is low. Do you need extra hardware or programming or just plug it in? Any specific model?.
The part number, and a small breakout if you prefer, is available here.
can you upload some screenshots to see how the different cameras are chosen? or is it another browser tab with another address all in duplicate?
I am not really following the question there, I think maybe the translator got it wrong. Can you try again, please?
 
The part number, and a small breakout if you prefer, is available here.

I am not really following the question there, I think maybe the translator got it wrong. Can you try again, please?
Of course, I will try again.
- The Rotary switch is not interesting to me. I prefer to change the parameters with the brewpi console. Even so, I think it would be good to install a display for each of the cold rooms. To be able to see the data of the moment while I do other things in my place. I see that now the displays are very cheap. If the installation does not complicate the system I would install it. If this generates, or can generate problems, it is a hardware that I can do without. Can you tell me the generic model of the display to find a correct one?
- I don't understand how I can see the data of the different refrigerators on my screen. Each camera has an IP address to open a browser tab with a browser (refrigerator 1, refrigerator2 ... etc), or do we have, on the main screen, any button or selector to switch between refrigerators?
I asked him for some capture of this, if your team moves several refrigerators.
If it is not understood say it, I will reformulate the question as many times as necessary.
Thanks.
 
I think I understand now.

When we say "display" of course there are two different methods. There is the LCD attached to the controller and the web user interface. If you mean the LCD, you need a 20x4 LCD with an I2C connection. Something like this.

For the web UI, there is an index page where the status of each chamber is displayed:

1613492755697.png

You can click on one to go to the familiar page for a more detailed view.

Is that what you meant?
 
I think I understand now.

When we say "display" of course there are two different methods. There is the LCD attached to the controller and the web user interface. If you mean the LCD, you need a 20x4 LCD with an I2C connection. Something like this.

For the web UI, there is an index page where the status of each chamber is displayed:

View attachment 718846
You can click on one to go to the familiar page for a more detailed view.

Is that what you meant?
Good Morning,
Now yes. The answers have been precise. I'm going to check that lcd screen, does it need extra code or is it plug and play? a simple switch on its power supply to turn it off when not necessary? P.S. I'm starting to wonder if I'm going to try "Fermentrack" ;-)
 
P.S. I'm starting to wonder if I'm going to try "Fermentrack" ;-)
I’m biased as to which one I prefer obviously, but that’s the thing that’s so great about the ecosystem at the moment - there’s multiple of options, and people can select the one that works best for them. You really can’t go wrong with either choice. ;)
 
does it need extra code or is it plug and play? a simple switch on its power supply to turn it off when not necessary?
With the Uno, the screen has a screensaver timer. It wakes when you depress the rotary encoder. If you do not use a rotary encoder, you have two choices:
  • Ground pin 7 and then at startup the timeout will be disabled
  • Use a momentary contact pushbutton between pin 7 and ground to turn the screen back on again
I've honestly forgotten whether the esp8266 firmware has a screensaver - I'll find out.

ETA: The ESP8266 firmware does not have a screen-saver. I believe you can pull the jumper on the back and use a switch there to turn it on and off. May have to experiment with that one.

Both versions are more or less plug-and-play. I'll never rule out the ability of the Chinese to change something, but I've not heard of any widespread issues (yet.)
 
Last edited:
Hello Thorrak, Obviously I will test both systems, I like each one for something and these doubts are only resolved with the tests. I guess since I'm used to the old brewpi (Bless you, Elco), I feel a little more comfortable migrating with brewPi remix. I am delighted with the idea of seeing two branches of work where I can continue. Oh, and do not suffer, I will try to torture you too with queries when I try Fermentrack. ;-)
 
With the Uno, the screen has a screensaver timer. It wakes when you depress the rotary encoder. If you do not use a rotary encoder, you have two choices:
  • Ground pin 7 and then at startup the timeout will be disabled
  • Use a momentary contact pushbutton between pin 7 and ground to turn the screen back on again
I've honestly forgotten whether the esp8266 firmware has a screensaver - I'll find out.

ETA: The ESP8266 firmware does not have a screen-saver. I believe you can pull the jumper on the back and use a switch there to turn it on and off. May have to experiment with that one.

Both versions are more or less plug-and-play. I'll never rule out the ability of the Chinese to change something, but I've not heard of any widespread issues (yet.)
Thank you, I will be attentive. It seems that there are several alternatives. This afternoon I have a meeting with 2 homebrewers. They were always afraid of the mountain of work that they thought the installation needed. I will try to explain your work to them and thus recruit two more soldiers. Thanks.
 
Most people would recommend that you supply power independently no matter what, but I run two Unos from my Pi with no apparent issues.
Good Morning, The first of my options is to use a 3A power supply(link). are 3A enough for 3 Wemos and 3 displays? Supplying power individually is another option, if I finally install the displays separately I will value it, although it is likely that I install everything in the same box. By the way, my two homebrewer friends are joining the project. More work for me and more consultations for you. ;-) At the moment we are buying parts and we will try brewPi remix and fermentrack. If you think that any of our tests can serve the community, do not hesitate to ask for it, I will be happy to contribute what little I can.
 
According to various empirical tests, an ESP8266 can consume up to ~435mA in spikes. Some of the LCD displays can draw up to 160mA. That's a theoretical peak of 595mA. With three of them running you are at 1.8A. On top of that, you have the relays and the probes. If it were me, I would have a separate power supply for each controller and its connected pieces. The Chinese power supplies are notoriously over-rated.
 
Hello again, I am getting some components and have been able to do some testing. This is the state of my tests and the doubts that begin to arise.

1- The linux installation on the Sd card is now very clean with the installer. Perfect.

2- the configuration of the files "ssh" AND 'wpa_supplicant.conf' with the application "HeadlessPi", works perfect. On the other hand, it is also very easy and the manual method is very well explained if you want to do so. Good work.

3- Connections via ssh via "Putty" and via "VNC" work correctly. Also very well explained. At this point I have a doubt. In this way, we do all the work via Wifi. I think that via ethernet the work of updates and subsequent installation is faster (I am a man of customs and when possible, I prefer ethernet to wifi). I see that when I connect a cable to the router, the ethernet configuration is automatic, but I do not know if with the two available possibilities, raspberry takes primarily ethernet or wifi. on the other hand, I am observing that the connection via "{servername} .local" sometimes refuses to connect, while via IP I can always access. I think that, after the first access, I would like to configure my static IPs. Can you tell me where and how to configure this? I think this must be in the same file that linux configured the wifi part, right? I would also need to know how to modify it. The Wi-Fi connection of my brewery is different from that of my house.

4- I have installed brewpi-remix on an SD card, without problems, and on another fermentrack without problems. I only mean the installation. I have not configured anything else yet (I am waiting for sensors and relays), but the two installations have been installed without giving any error (they have only asked me a question, I saw in the videos that this would happen).

5- I have installed and checked the external connections via remote.it. It works perfectly.
This video () explains how to do the job easily, in case someone needs help
 
I do not know if with the two available possibilities, raspberry takes primarily ethernet or wifi
There's no precise way of knowing which will answer, the IP stack decides on the better route. There are more complicated routing solutions, but unless you need both, I suggest you disable one or the other.
I am observing that the connection via "{servername} .local" sometimes refuses to connect, while via IP I can always access
If you have both Ethernet and WiFi connections, this can happen. Otherwise, I find Raspbian's implementation of Avahi very solid, so troubleshooting at the client computer would be my next suggestion.
think that, after the first access, I would like to configure my static IPs.
You can follow the instructions given by the Raspbian people for that.
The Wi-Fi connection of my brewery is different from that of my house.
I take this to mean they are on separate networks? If that is the case, mDNS (the *.local name) will not work anyway.
 
Thank you, I will follow your instructions. I will continue to report my progress and doubts.
 
My "wemos D1 mini" have just arrived, and moving forward thinking about the programming, I look at the documentation, I realize that I don't understand how to program them.
my old arduino was connected via USB and received a programming via Web interface, although I read in the documentation that it is not recommended. However, if I don't have a cable, how do I program it to talk to raspberry? Can you put me on a good path?
Thanks.
 
Flashing the ESP8266 is relatively easy. Use BrewFlasher and choose the firmware version you want. If you want to connect via serial as with the Arduino, that works with one version, WiFi works with another.

If you choose to use WiFi, there is a process you need to follow. From @Thorrak's pages:
After flashing an ESP8622 with the WiFi firmware image, open your host computer's WiFi network selector and look for an access point that begins with "ESP_" and then a string of numbers. Connect to this access point and navigate to any web page- you should be automatically redirected to the ES8266 configuration web page (If not, the configuration page usually runs at http://192.168.4.1). Select your LAN wifi network from the networks identified, as well as your wifi password and mDNS name (a text string to identify your ESP8622 board by). Click 'Save'. The ESP8622 will reboot and then connect to your LAN wifi network.

After that you will have to edit the /home/brewpi/settings/config.cfg file to use that port. It will look like this:
Code:
port = socket://192.168.168.143:23
.. where the IP address is the proper IP address for your controller. Port 23 must remain as-is. Remove any other "port" declarations" in that file.

One of these days I will ...
  1. Fix flashing within the UI
  2. Update the documentation
There are too much work and too few hours.
 
Hello,
updating my task status:
For some reason, my head was unable to understand that the work with the ESP8266 was via the usp cable and the PC. When I understood my mistake, I downloaded BrewFlasher ( Good work @Thorrak ) and tried flashing a module. I could not communicate the machines. After looking for possible problems, I found that the usb was not recognized as a serial port by my W10. Here I could download the driver that I needed. Once installed, I was able to flash without problems.
I have managed to connect via smartphone with the ESP8266 and access the configuration menu.
At this point, someone claimed my attention and the rest of the work has been postponed.
I will continue to report ...
Thanks for so much help.
P.S. LBussy, do not worry about your pending work, we will wait without problem.
 
Can anyone help me understand why when I attempt to display the output of brewpi in a frame it doesn't populate the graph?
I wanted to display brewpi and tiltbridge side by side. but all I can get is this.
Capture.PNG

if I hit the refresh button in the beer profile that will update and populate the bottom panel. but I can't find anything to populate the top panel.
 
Can anyone help me understand why when I attempt to display the output of brewpi in a frame it doesn't populate the graph?
I suspect the answer may be hidden deep in the bowels of the legacy code. You might try opening the console and watching for errors. On most browsers, that's shift - ctrl - k.
 
Back
Top