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

[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.

 

[day_trippr]

Maybe there's a non-Belkin device programming app out there already?

"There are ways to interface with WeMo devices programmatically, though they primarily rely on the devices' underlying communication protocols rather than a formally published "developer API" from Belkin. Specifically, WeMo devices utilize the Universal Plug and Play (UPnP) protocol over HTTP. This allows for discovery of WeMo devices on the local network and communication using SOAP actions.

While Belkin doesn't provide a fully documented public API for general development, the community has filled the gap by developing libraries and tools that interact with WeMo devices using UPnP and SOAP:

• Libraries in various languages: You can find libraries in different programming languages that simplify communication with WeMo devices. For instance, there's a C# library called WeMosDef and a Python module called PyWeMo.
• UPnP Interaction: The devices themselves expose a SOAP API for retrieving data and controlling them. You can discover WeMo devices on the network using a UPnP broadcast and then access their services and actions.
• REST API Wrappers: Some projects have wrapped the UPnP/SOAP interactions into simpler REST APIs, making it easier to control WeMo devices with HTTP GET calls.
• Third-party Integrations: Platforms like Home Assistant have built-in integrations for WeMo devices, often leveraging the same underlying communication methods.

It's important to note that while these methods allow for programmatic control of WeMo devices, Belkin could potentially make changes to the device firmware in the future that could affect compatibility. "

 

[Lalo_uy]

Wifi BrewPi do not need Wemos, any ESP-12 will do.
Just add the voltage reg and a usb-ttl addapter for programming.

 

[Thorrak]

Maybe there's a non-Belkin device programming app out there already?

"There are ways to interface with WeMo devices programmatically, though they primarily rely on the devices' underlying communication protocols rather than a formally published "developer API" from Belkin. Specifically, WeMo devices utilize the Universal Plug and Play (UPnP) protocol over HTTP. This allows for discovery of WeMo devices on the local network and communication using SOAP actions.

While Belkin doesn't provide a fully documented public API for general development, the community has filled the gap by developing libraries and tools that interact with WeMo devices using UPnP and SOAP:

• Libraries in various languages: You can find libraries in different programming languages that simplify communication with WeMo devices. For instance, there's a C# library called WeMosDef and a Python module called PyWeMo.
• UPnP Interaction: The devices themselves expose a SOAP API for retrieving data and controlling them. You can discover WeMo devices on the network using a UPnP broadcast and then access their services and actions.
• REST API Wrappers: Some projects have wrapped the UPnP/SOAP interactions into simpler REST APIs, making it easier to control WeMo devices with HTTP GET calls.
• Third-party Integrations: Platforms like Home Assistant have built-in integrations for WeMo devices, often leveraging the same underlying communication methods.

It's important to note that while these methods allow for programmatic control of WeMo devices, Belkin could potentially make changes to the device firmware in the future that could affect compatibility. "

The issue isn’t controlling the devices once they’re on a network (I already control them completely locally using BrewPi-ESP) - it’s provisioning them. I think (but would be happy to be corrected if I’m wrong!) that the only way to attach them to a WiFi network is using their app.

I vaguely recall there being a method using a captive AP (similar to BrewPi-ESP and TiltBridge) back when the devices were first released, but don’t think this still exists. Again - it’s been awhile since I set one of these up, so happy to be proven wrong.

Wifi BrewPi do not need Wemos, any ESP-12 will do.
Just add the voltage reg and a usb-ttl addapter for programming.

This is certainly a possibility - but I’m hoping to keep a fully “solder free” (or said differently: “off the shelf, minimal work”) option for those who prefer it. The #1 benefit from the Wemos plugs was that they were almost plug and play for end users. Once they were on your network, BrewPi-ESP would see them and they would just work. Pair them with a M5 Stick C, Tilt, and Inkbird Bluetooth temperature sensor, and you had a complete BrewPi build that required zero “building” (soldering, mains wiring, plugging cables together, etc.) at all.

 

[Thorrak]

Uh.

I may be losing my mind.

Wemos isn’t Kasa. I confused my clouds.

BrewPi-ESP is fine. (But I would still love to find an open source option here)

In my defense: I saw this news while we were sitting at Alchemist about two heady toppers deep.

 

[LBussy]

Beer + complaining about "the man?" Say it ain't so.

 

[pers]

Is there any way to flash the S2? One of my 8266s died and I very stupidly bought a bunch of S2s as backups.

 

[Thorrak]

Is there any way to flash the S2? One of my 8266s died and I very stupidly bought a bunch of S2s as backups.

What do you mean? The ESP32-S2 is supported in BrewFlasher, so you should be able to just use it.

If you're having trouble flashing them, it's likely due to the fact that most modules rely on the ESP32-S2's built in USB support rather than bundling a separate USB-to-UART chip as is done with the ESP32. To use it, you have to hold the "Boot", "Flash", or "0" button as you plug the USB cable into your computer before flashing it. Once it's been flashed once you may not have to do this any more as the bootloader has a hack built into it to handle this, but it's good to remember as the hack doesn't always work.

 

[pers]

What do you mean? The ESP32-S2 is supported in BrewFlasher, so you should be able to just use it.

If you're having trouble flashing them, it's likely due to the fact that most modules rely on the ESP32-S2's built in USB support rather than bundling a separate USB-to-UART chip as is done with the ESP32. To use it, you have to hold the "Boot", "Flash", or "0" button as you plug the USB cable into your computer before flashing it. Once it's been flashed once you may not have to do this any more as the bootloader has a hack built into it to handle this, but it's good to remember as the hack doesn't always work.

Sorry, read about all the S2 flashing issues and when it didn't work first time, thought nothing could be done.

Did the button sequence and everything worked way it should.

Usually I read things more closely but planning to brew tomorrow and the 8266 not working anymore threw me into panic mode.

 

[Thorrak]

Sorry, read about all the S2 flashing issues and when it didn't work first time, thought nothing could be done.

Did the button sequence and everything worked way it should.

Usually I read things more closely but planning to brew tomorrow and the 8266 not working anymore threw me into rush mode.

If it makes you feel any better, I realized I had old firmware on my main BrewPi build last night at 1 am after what can only be described as a chaotic brew day. Normally not an issue, but given part of the point was to test some newer features, not a great discovery to cap the day off!

 

[michasol]

I built one of your AIO systems mentioned on your blog, and am currently using it to ferment a Blonde Ale with a newly finished glycol system I built. Everything is working fantastically, except after about 24ish hours the TFT screen goes completely white. Temp control is still happening and the unit is still active and changeable from Fermentrack.net and the local ip address. After power cycling the screen works correctly again for about another 24ish hours. I'm using the Lolin ESP32, TFT, and cable that you recommend as well as the latest ESP32 beta1 available on Brewflasher. What are your thoughts on this being maybe a hardware/heat issue (its been over 100 outside and in the garage since brewday on Sun) vs a potential software issue? Thanks for the help, and just wanna say I'm a big fan of everything youre doing in the homebrew hardware/software realm!

 

[Thorrak]

I built one of your AIO systems mentioned on your blog, and am currently using it to ferment a Blonde Ale with a newly finished glycol system I built. Everything is working fantastically, except after about 24ish hours the TFT screen goes completely white. Temp control is still happening and the unit is still active and changeable from Fermentrack.net and the local ip address. After power cycling the screen works correctly again for about another 24ish hours. I'm using the Lolin ESP32, TFT, and cable that you recommend as well as the latest ESP32 beta1 available on Brewflasher. What are your thoughts on this being maybe a hardware/heat issue (its been over 100 outside and in the garage since brewday on Sun) vs a potential software issue? Thanks for the help, and just wanna say I'm a big fan of everything youre doing in the homebrew hardware/software realm!

It’s a hardware issue that software can fix, in this case!

The problem is that when the relays toggle on/off, they’re electrically noisy and can cause the TFT to malfunction. If you log into the controller's web interface, on the Controller Settings screen there should be a toggle for "Reset Screen on Pin Toggle". Turn that on, and hit save.

The reason this is not on by default is that it will cause the screen to flash when heating/cooling turns on/off as the screen resets. If you need it, then it's there - but if you don't, it can be annoying.

 

[michasol]

It’s a hardware issue that software can fix, in this case!

The problem is that when the relays toggle on/off, they’re electrically noisy and can cause the TFT to malfunction. If you log into the controller's web interface, on the Controller Settings screen there should be a toggle for "Reset Screen on Pin Toggle". Turn that on, and hit save.

The reason this is not on by default is that it will cause the screen to flash when heating/cooling turns on/off as the screen resets. If you need it, then it's there - but if you don't, it can be annoying.

That's awesome, thanks so much for the reply!