Native ESP8266 BrewPi Firmware - WiFi BrewPi, no Arduino needed!

[Thorrak]

Since there have been a few questions about this lately, I went ahead and drafted a more comprehensive blog post on the different controller options (ESP8266 vs. ESP32-S2 vs. ESP32).

The TL;DR is basically what I posted in response to @g_wood -- If you already have a build, keep it until you see a feature you want, and then upgrade. If you're starting fresh, go with an ESP32.

 

[wd16261]

One issue I see with this one - the dark red wire you show going from "VCC" on the lower pin of the relay board to "VIN" on the controller should actually go to "3v3" on the controller, and a separate wire should go from "JD-VCC" on the relay board to "VIN". It might work fine like this, but you could end up where the relay won't toggle.

Yeah I thought about that too but I've been working like this for years and never had a problem.
And you know what they say: if it ain't broke don't fix it

 

[g_wood]

I am having trouble accessing the controller's web interface. I am using a ESP8266 Wemos D1 Mini chip and brewflasher.

I can sucessfully flash the controller - v16-beta1 - wifi version, baud rate 115200. I can access the wifi configuration page, and the controller can connect to my wifi. After that is hard to access the web interface. It keeps loading the page, sometimes I can see the webpage but it seems very slow. I have succesfully connected it to fermentrack 2, however.

Is this expected, to have a slow connection with the controller? Not sure if this impacts the connection of the controller to fermentrack.

 

[Thorrak]

I am having trouble accessing the controller's web interface. I am using a ESP8266 Wemos D1 Mini chip and brewflasher.

I can sucessfully flash the controller - v16-beta1 - wifi version, baud rate 115200. I can access the wifi configuration page, and the controller can connect to my wifi. After that is hard to access the web interface. It keeps loading the page, sometimes I can see the webpage but it seems very slow. I have succesfully connected it to fermentrack 2, however.

Is this expected, to have a slow connection with the controller? Not sure if this impacts the connection of the controller to fermentrack.

That’s not too surprising, unfortunately. The ESP8266 doesn’t have all that much processing power under the hood, and the way that I pull the web interface from the device hits it with a number of requests all at once. If your browser caches some of the files you might notice subsequent hits are faster, but that’s very situational.

The nice thing is that from a temperature control perspective you’re fine. The slowness should only occur when loading webpages - all of the temperature control algorithms (and data sending!) are synchronous.

 

[g_wood]

That’s not too surprising, unfortunately. The ESP8266 doesn’t have all that much processing power under the hood, and the way that I pull the web interface from the device hits it with a number of requests all at once. If your browser caches some of the files you might notice subsequent hits are faster, but that’s very situational.

The nice thing is that from a temperature control perspective you’re fine. The slowness should only occur when loading webpages - all of the temperature control algorithms (and data sending!) are synchronous.

So, I connected it to Fermentrack 2, configured the pins and sensors and it looks like to be working perfectly. Thanks!

Two more questions

1 - the v16 version will not work with a OLED screen, right?
2 - Is it possible yet to connect Fermentrack 2 to Brewfather?

 

[playhouse]

That's why I'm working on it - it becomes your choice at that point!

The advantages to switching to an ESP32 are the removal of the need for a Raspberry Pi (if connecting to the BrewPi is the only thing you're using it for!), and the addition of a number of new features such as large screens, bluetooth temperature sensors, Tilt integration, and on-device controls. It's the device I target for new builds, and as such is where any new features that might get added will be found.

On the other hand, as you noted, the advantage of the Arduino is that you already have it built and sitting in your brewery -- which is abolutely not something to discount. If you don't care about any of those new features right now, then there's no requirement to upgrade right now. You can always come back and swap the controllers out at a future point.

The Serial-to-Fermentrack work is reasonably far along, but at the moment I don’t have an Arduino shield with temperature sensors, so it’s at least a week away from completion (depending on shipping!). Temperature sensors work perfectly with a serial ESP32-S2, so I’m not expecting any issues, but I’ve found one Arduino-specific bug, so there’s always a chance for more. Alpha testers are always welcome, but you’d have to both disconnect your BrewPi from BPR/Fermentrack and hook it to a dev copy of Fermentrack 2, so it’s not for the faint of heart.

I installed the 'Fermentrack 2 Arduino (Serial) Support' following this page on your site. However, when I run the installer, it fails when installing the Serial to Fermentrack wheel file into virtualenv. Is there a permissions issue I need to consider? When I re-run the installer, it keeps saying uv is not installed even though it looks like it was in previous runs of the installer. Maybe it is the Python version check you are running (should be 3.1.1 instead of 3.11? The installer says greater than 3.8.0 is compatible?) Here's a screen shot followed by relevant log file section:

::: [38;5;76mInstalling Serial to Fermentrack wheel file into virtualenv...(B[m
× No solution found when resolving dependencies:
╰─▶ Because the current Python version (3.9.2) does not satisfy Python>=3.11
and serial-to-fermentrack==0.0.1 depends on Python>=3.11, we can
conclude that serial-to-fermentrack==0.0.1 cannot be used.
And because only serial-to-fermentrack==0.0.1 is available and you
require serial-to-fermentrack, we can conclude that your requirements
are unsatisfiable.

 

[Thorrak]

So, I connected it to Fermentrack 2, configured the pins and sensors and it looks like to be working perfectly. Thanks!

Two more questions

1 - the v16 version will not work with a OLED screen, right?
2 - Is it possible yet to connect Fermentrack 2 to Brewfather?

Awesome - glad to hear it!

1. Correct: Unfortunately there is no OLED screen support.
2. Not yet. "External push" support (ie. Brewfather) is coming, but after gravity sensor support

I installed the 'Fermentrack 2 Arduino (Serial) Support' following this page on your site. However, when I run the installer, it fails when installing the Serial to Fermentrack wheel file into virtualenv. Is there a permissions issue I need to consider? When I re-run the installer, it keeps saying uv is not installed even though it looks like it was in previous runs of the installer. Maybe it is the Python version check you are running (should be 3.1.1 instead of 3.11? The installer says greater than 3.8.0 is compatible?) Here's a screen shot followed by relevant log file section:

View attachment 874830

::: [38;5;76mInstalling Serial to Fermentrack wheel file into virtualenv...(B[m
× No solution found when resolving dependencies:
╰─▶ Because the current Python version (3.9.2) does not satisfy Python>=3.11
and serial-to-fermentrack==0.0.1 depends on Python>=3.11, we can
conclude that serial-to-fermentrack==0.0.1 cannot be used.
And because only serial-to-fermentrack==0.0.1 is available and you
require serial-to-fermentrack, we can conclude that your requirements
are unsatisfiable.

Heh. That's on me -- I had the minimum version set incorrectly in both the install script (it should be 3.9, not 3.8) and in the wheel (it should be 3.9, not 3.11). This script should work on both Bullseye and Bookworm (which ship with 3.9 and 3.11 respectively) - not just Bookworm.

Try now.

 

[playhouse]

Awesome - glad to hear it!

1. Correct: Unfortunately there is no OLED screen support.
2. Not yet. "External push" support (ie. Brewfather) is coming, but after gravity sensor support




Heh. That's on me -- I had the minimum version set incorrectly in both the install script (it should be 3.9, not 3.8) and in the wheel (it should be 3.9, not 3.11). This script should work on both Bullseye and Bookworm (which ship with 3.9 and 3.11 respectively) - not just Bookworm.

Try now.

That worked, thanks for the quick update.

 

[playhouse]

Hmmm, configuring does not seem to be working right (do I need to literally connect the Arduino to my computer over serial versus doing it over WiFi?). I was able to configure the Fermentrack.net connection, I then tried to configure the device remotely and got this first question, not sure where the list of devices comes from, I don't see any data that matches what Fermentrack.net 'sees':

[?] Select a device to configure or go back:
> /dev/ttyACM0 - ttyACM0 (Location: 1-1:1.0) [Not Configured]
/dev/ttyAMA0 - ttyAMA0 [NOT CONFIGURABLE - No Location]

Wasn't sure which one to use, but I assumed the first given the 'Not Configured' message. Got the following (I am currently running BPR to control a fermentation which is where the garbage responses are coming from I assume?):

Connecting to device...
Requesting firmware version...
Device responded with:
Invalid response - retrying in 2 seconds...
Requesting firmware version...
Device responded with: :"ode Beer Const. ","Beer 69.7 67.0 �F","Fride5. 4. F""oln o 0m5]
Invalid response - retrying in 2 seconds...
Requesting firmware version...
Device responded with:
Response does not start with 'N:' - not a BrewPi device.

ERROR: This device did not respond to the version info command, and therefore does not appear to be a working BrewPi connected via Serial.

Only working BrewPi devices can be configured.
Configuration cancelled.

 

[Thorrak]

Hmmm, configuring does not seem to be working right (do I need to literally connect the Arduino to my computer over serial versus doing it over WiFi?). I was able to configure the Fermentrack.net connection, I then tried to configure the device remotely and got this first question, not sure where the list of devices comes from, I don't see any data that matches what Fermentrack.net 'sees':

[?] Select a device to configure or go back:
> /dev/ttyACM0 - ttyACM0 (Location: 1-1:1.0) [Not Configured]
/dev/ttyAMA0 - ttyAMA0 [NOT CONFIGURABLE - No Location]

Wasn't sure which one to use, but I assumed the first given the 'Not Configured' message. Got the following (I am currently running BPR to control a fermentation which is where the garbage responses are coming from I assume?):

Connecting to device...
Requesting firmware version...
Device responded with:
Invalid response - retrying in 2 seconds...
Requesting firmware version...
Device responded with: :"ode Beer Const. ","Beer 69.7 67.0 �F","Fride5. 4. F""oln o 0m5]
Invalid response - retrying in 2 seconds...
Requesting firmware version...
Device responded with:
Response does not start with 'N:' - not a BrewPi device.

ERROR: This device did not respond to the version info command, and therefore does not appear to be a working BrewPi connected via Serial.

Only working BrewPi devices can be configured.
Configuration cancelled.

Correct -- You can't have this set up at the same time as it's configured to work with BrewPi Remix (or legacy Fermentrack, for that matter). You might be able to sneak a configuration in if you're fast enough, but I wouldn't recommend it, as at best you'll encounter weird connection drops (and at worst you'll lose the ability to control your ferment from within BPR until you delete the FT2 tools configuration).

 

[playhouse]

Got it. So if I just stop the current brew in BPR (just pitched yesterday, so not an issue), reboot BPR just in case, and then run the configurator, it should work or do I need to do something else?

 

[Thorrak]

Got it. So if I just stop the current brew in BPR (just pitched yesterday, so not an issue), reboot BPR just in case, and then run the configurator, it should work or do I need to do something else?

You need to completely delete the controller from BPR so it won’t keep attempting to connect. Otherwise, yep. That’s it.

 

[playhouse]

Sorry, being dense, how do I delete the controller from BPR (I didn't see anything in the interface or in the BPR docs other than resetController)?

 

[Thorrak]

Sorry, being dense, how do I delete the controller from BPR (I didn't see anything in the interface or in the BPR docs other than resetController)?

Good question. I think there might be a configuration file somewhere you delete — @LBussy - any thoughts?

 

[LBussy]

It's sort of the reverse - if BPR doesn't see a controller it's mindless. If you had one attached via USB, just remove it. If you are using WiFi, the configuration for that is in /home/brewpi/settings/config.cfg.

 

[Thorrak]

It's sort of the reverse - if BPR doesn't see a controller it's mindless. If you had one attached via USB, just remove it. If you are using WiFi, the configuration for that is in /home/brewpi/settings/config.cfg.

Hmm. The goal is to prevent BPR from trying to connect via the USB Serial connection to an attached controller. Does BPR just try to blindly connect to all attached devices, or is there a configuration file somewhere that tells it what serial ports to attach to?

 

[LBussy]

I am on two phone calls right now so I may not be following - if you want to STOP BrewPi, then issue the command:

sudo systemctl stop brewpi
sudo systemctl disable brewpi

 

[playhouse]

Issuing the above commands, running the FT2 config for devices, and then reenabling/restarting BPR worked. Thanks guys for the help!

 

[Thorrak]

Issuing the above commands, running the FT2 config for devices, and then reenabling/restarting BPR worked. Thanks guys for the help!

Glad to hear it's all working now!

One thing -- I would recommend running the upgrade script (twice) for FT2 tools when you have a chance. I just released v0.0.2 of FT2 Tools to resolve an issue I found yesterday evening where one of my test rigs stopped communicating over serial with the controller. It had been working for a number of days before that, so this seems to be a relatively rare occurrence -- but it's still something I'd rather avoid if possible!

 

[playhouse]

Glad to hear it's all working now!

One thing -- I would recommend running the upgrade script (twice) for FT2 tools when you have a chance. I just released v0.0.2 of FT2 Tools to resolve an issue I found yesterday evening where one of my test rigs stopped communicating over serial with the controller. It had been working for a number of days before that, so this seems to be a relatively rare occurrence -- but it's still something I'd rather avoid if possible!

Funny you should mention that. When I got up this morning, I saw the following on the controller detail page:

I followed your guidance above and the installer noted some updates to components, however, I was still getting the message above after reloading the page. Rebooting the whole BPR/FT2S rig fixed it.

Separately, how do BPR and FT2S interact in terms of staying synced on settings? I was messing around a bit and see that the mode changes seems to stay in sync, but the Beer Profiles do not (looks like they are two separate entities - one set of profiles for BPR and one set for FT2S?)

 

[Thorrak]

Funny you should mention that. When I got up this morning, I saw the following on the controller detail page:

View attachment 875198

I followed your guidance above and the installer noted some updates to components, however, I am still getting the message above after reloading the page. Separately, how do BPR and FT2S interact in terms of staying synced on settings? I was messing around a bit and see that the mode changes seems to stay in sync, but the Beer Profiles do not (looks like they are two separate entities - one set of profiles for BPR and one set for FT2S?)

If your controller had already locked up, you will need to manually kill the process to get it to exit/reconnect. The easiest way is to just sudo shutdown -r now and reboot the Pi.


To answer your question about how things stay synchronized, it's important to understand that there's three components in your system right now:

• A physical controller running firmware of some kind (in your case, an Arduino controller running BrewPi-Remix Firmware)
• Web-based management software
• A script connecting the physical controller to the web interface

When you were using BrewPi-Remix's web interface, your stack looked like this:
Arduino --> BrewPi-Script --> BrewPi-Remix's Web Interface

Now that you're using Fermentrack 2 and S2F, your stack looks like this:
Arduino --> Serial-to-Fermentrack --> Fermentrack 2

BrewPi-Remix (the web interface) is replaced by Fermentrack 2, so they don't even attempt to stay in sync. Settings that are managed in the web-based management software - including temperature profiles - won't sync between the two.

To provide some background as to why: Historically, due to limitations in the capabilities of an Arduino, the temperature profiles have always been implemented by the web interface. The only things the controller knows are that the web interface is executing a profile (in order to display "Beer Profile" on the screen) and the exact temperature it is currently trying to hit. What this means in practice is that if you are partway through a temperature ramp from, say, 70F to 50F, and the point on that slope that the controller is currently at happens to be "64.5F", that is the only information it knows. It does not know that the next step would be "64.4F" - or that it will ultimately reach 50F. If you were to shut down your Pi at this stage (or terminate Serial-to-Fermentrack), you would notice that your controller would just stay at 64.5°F indefinitely.

Once you've rebooted the Pi, let me know how things get on. I've tested this release, but if you have any issues, happy to address!

 

[playhouse]

If your controller had already locked up, you will need to manually kill the process to get it to exit/reconnect. The easiest way is to just sudo shutdown -r now and reboot the Pi.


To answer your question about how things stay synchronized, it's important to understand that there's three components in your system right now:

• A physical controller running firmware of some kind (in your case, an Arduino controller running BrewPi-Remix Firmware)
• Web-based management software
• A script connecting the physical controller to the web interface

When you were using BrewPi-Remix's web interface, your stack looked like this:
Arduino --> BrewPi-Script --> BrewPi-Remix's Web Interface

Now that you're using Fermentrack 2 and S2F, your stack looks like this:
Arduino --> Serial-to-Fermentrack --> Fermentrack 2

BrewPi-Remix (the web interface) is replaced by Fermentrack 2, so they don't even attempt to stay in sync. Settings that are managed in the web-based management software - including temperature profiles - won't sync between the two.

To provide some background as to why: Historically, due to limitations in the capabilities of an Arduino, the temperature profiles have always been implemented by the web interface. The only things the controller knows are that the web interface is executing a profile (in order to display "Beer Profile" on the screen) and the exact temperature it is currently trying to hit. What this means in practice is that if you are partway through a temperature ramp from, say, 70F to 50F, and the point on that slope that the controller is currently at happens to be "64.5F", that is the only information it knows. It does not know that the next step would be "64.4F" - or that it will ultimately reach 50F. If you were to shut down your Pi at this stage (or terminate Serial-to-Fermentrack), you would notice that your controller would just stay at 64.5°F indefinitely.

Once you've rebooted the Pi, let me know how things get on. I've tested this release, but if you have any issues, happy to address!

Our posts (edited mine) crossed in the ether. Rebooting worked. So, to your above, I should stop using the BPR web interface and only use FT2, correct? Are there any feature deltas between the two I need to consider?

 

[Thorrak]

Our posts (edited mine) crossed in the ether. Rebooting worked. So, to your above, I should stop using the BPR web interface and only use FT2, correct? Are there any feature deltas between the two I need to consider?

Correct. The only feature delta I can think of that might matter to you is the lack of specific gravity sensor support. If you use a Tilt (or iSpindel) then you won't be able to use it with Fermentrack 2 for now.

Support is coming, but it's not here yet.

 

[playhouse]

Do I need to do anything to 'turnoff' the BPR web interface? Was concerned if I use Lee's:

sudo systemctl stop brewpi
sudo systemctl disable brewpi

that it would shut the whole thing down.

 

[Thorrak]

Do I need to do anything to 'turnoff' the BPR web interface? Was concerned if I use Lee's:

sudo systemctl stop brewpi
sudo systemctl disable brewpi

that it would shut the whole thing down.

Not unless you want to. The way BPR works is using Apache to manage the web interface, rather than a separate service. To shut it down, you would need to disable the Apache service. With that said, as long as the “brewpi” service is shut down, your web interface isn’t actually doing anything, so you’re good.

 

[playhouse]

Not unless you want to. The way BPR works is using Apache to manage the web interface, rather than a separate service. To shut it down, you would need to disable the Apache service. With that said, as long as the “brewpi” service is shut down, your web interface isn’t actually doing anything, so you’re good.

Hmmm, disconnected again (reboot brought it back). Do you think it could be because I started this brew monitoring with BPR interface (which is still running) and moved over to FT2S midstream?

Two feature requests - if possible, it would be good to show the name of the beer profile you are actually running in addition to the fact that you are in Beer Profile mode. Also, it would be good to see where you are holistically in the profile timeline in the progress graphic.

 

[Thorrak]

Hmmm, disconnected again (reboot brought it back). Do you think it could be because I started this brew monitoring with BPR interface (which is still running) and moved over to FT2S midstream?

Two feature requests - if possible, it would be good to show the name of the beer profile you are actually running in addition to the fact that you are in Beer Profile mode. Also, it would be good to see where you are holistically in the profile timeline in the progress graphic.

View attachment 875236

View attachment 875237

That shouldn’t matter as long as the BrewPi service is stopped.

If you log into the Pi, cd to the ft2_tools directory and run tail -50 on the two logs with data (the one with stderr in the name and the one with your device address) can you send those to me via a DM?

I’ll take a look.

 

[Nateb]

First off, Thanks to all the contributors of this project. I've been using the og fermentrack pretty much since it's release.
My old pi is getting a little flakey and I'm going to start a 2nd gen setup.

My first issue is my windows pc really doesn't like the desktop brewflasher (beyond the unknown author warnings), it sets off my anti virus as well. Is this correct?
Second. using the online brewflasher, trying to flash esp32 s2 mini. I can't get them to flash. The com port shows it, but firmware will not load. I've messed with the buttons in all the combos I can think of. Any suggestions?
I have successfully flashed a esp32 wroom.

 

[Thorrak]

First off, Thanks to all the contributors of this project. I've been using the og fermentrack pretty much since it's release.
My old pi is getting a little flakey and I'm going to start a 2nd gen setup.

My first issue is my windows pc really doesn't like the desktop brewflasher (beyond the unknown author warnings), it sets off my anti virus as well. Is this correct?

Unfortunately, blame Microsoft: https://github.com/thorrak/brewflasher/issues/2

BrewFlasher absolutely does work for Windows, but requires ignoring the smartscreen warnings/antivirus pop-ups because of the code signing requirement (and the way that PyInstaller apps bundle).

If you have a working Raspberry Pi (or working-ish, the code doesn't judge!) then you can use BrewFlasher Command Line Edition if you prefer, which can be easily installed via ft2_tools.

Second. using the online brewflasher, trying to flash esp32 s2 mini. I can't get them to flash. The com port shows it, but firmware will not load. I've messed with the buttons in all the combos I can think of. Any suggestions?
I have successfully flashed a esp32 wroom.

I just tried flashing an ESP32-S2 with BrewFlasher Web and had the same issue as you. There's some weirdness with the way that the ESP32-S2s work (the manufacturers of most boards got cheap and use the S2's onboard USB driver rather than bundling an explicit one as comes with the WROOM boards) which is why they require special treatment. I've raised an issue on the BrewFlasher Web to track, but can't promise a timeline to get this one fixed. Unfortunately, there's a few projects ahead of this one on the list.

 

[Thorrak]

So apparently Belkin is discontinuing support for Wemo products: https://www.belkin.com/support-article/?articleNum=335419#DevicesAffected

Although there are a thousand things they could do in order to keep the devices working, shutting down the app - which a few years back they made the only way to configure WiFi access - is what we refer to as a dick move.

BrewPi-ESP doesn’t rely on their cloud to work, so existing builds should be fine, but commissioning new builds could be problematic after this date.


If anyone has recommendations for alternatives, I’m open. I love the thought of Tasmota, but would lose the automatic detection, so it hasn’t been my preference. Absent an alternative, however, this may be the way I go.