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

[day_trippr]

Good luck with that. There may be esp applications with built-in network awareness and support for static addressing but for my fleet of esp32s I could not find an alternative to using the DHCP Address Reservation function on my router. Same applies to my Smart Plugs - they're not exactly brilliant at network management so Address Reservation for those as well...

Cheers!

 

[kissmurphy]

Hi day_trippr,
Thanks for the quick reply.

Good luck with that. There may be esp applications with built-in network awareness and support for static addressing but for my fleet of esp32s I could not find an alternative to using the DHCP Address Reservation function on my router. Same applies to my Smart Plugs - they're not exactly brilliant at network management so Address Reservation for those as well...

Cheers!

Yes, I couldn't see any obvious way to manually configure a "true" static IP address.

Sure, I understand the default should be DHCP as the general public want a simple, from their point of view, path to success but I think it would be handy for debugging connectivity issues, as It would take the DHCP network infrastructure out of the equation. It would also reduce battery usage, less network traffic and a shorter uptime per reported reading. However, the developer sure has a lot of his plate and this probably falls into the "nice to have basket".

Thanks for sharing your experience, much appreciated.

Cheers!
Rob

 

[day_trippr]

I think it would be handy for debugging connectivity issues

It totally is!

The only thing I actually use DHCP for is guests. Every other entity on my LAN has an assigned IP address, one way or the other. For the vast majority, the devices support static addressing directly. The rest live under the kind auspices of Address Reservation.

I maintain a spreadsheet with node information - device name, type, make & model, MACs for enet/wifi/Bluetooth where applicable, the assigned LAN IP address, and their external reference from the WAN side of my NAS (the NAS enables IP tunneling). One of the network apps I run eyeballs the entire multi-segmented LAN looking for rogue entities and will yak up a console message if it spots a "newcomer". I installed a new Smart Plug today and it was cool to see that "bird dog" alert to an unrecognized device

Cheers!

 

[kissmurphy]

...
I maintain a spreadsheet with node information - device name, type, make & model, MACs for enet/wifi/Bluetooth where applicable, the assigned LAN IP address, and their external reference from the WAN side of my NAS (the NAS enables IP tunneling). One of the network apps I run eyeballs the entire multi-segmented LAN looking for rogue entities and will yak up a console message if it spots a "newcomer". I installed a new Smart Plug today and it was cool to see that "bird dog" alert to an unrecognized device
...

Sounds like you really know what's happening on your LAN.

 

[LBussy]

Sounds like you really know what's happening on your LAN.

Yet, he still doesn’t update his software

 

[day_trippr]

Now now. You should be happy I got rid of allll the port forwarding here, and use my NAS as a tunnel endpoint vectored through Synology.
And what I'm running in my brewery for taplist and chamber controls are the moral equivalent of toasters. And there's no need to replace a toaster unless the toaster dies...

Cheers!

 

[LBussy]

Now now. You should be happy I got rid of allll the port forwarding here, and use my NAS as a tunnel endpoint vectored through Synology.
And what I'm running in my brewery for taplist and chamber controls are the moral equivalent of toasters. And there's no need to replace a toaster unless the toaster dies...

Small victories.

 

[kissmurphy]

Hi BrewPi-esp8266 Peers,

I've logged a feature request for selectable network configuration options.

Ideally all the following would be available to the user, and so also to the developer to help with the debugging of network issues:

1) "Automatic Network Configuration" - current controller network configuration method
2) "Manual Network Configuration" - user enters network parameters
3) "Automatic *Initial* Network Configuration" - see below

With option (2) the user manually enters not just the SSID and WiFi key, but also the IP Address, Network Mask, Default Gateway, and DNS server(s).

With option (3) the controller gets it's network configuration as it currently does, automatically from, say a DHCP server, but then continues to use that configuration as if it were manually entered, without ever having to contact the DHCP server again. This way is should get configured correctly in the first place but then not have to rely upon that DHCP server being available, and working correctly, in the future.

Please see the feature request for further details:

Option to manually configure a "true" static IP address, no automatic DHCP network configuration infrastructure required #112

Cheers!
Rob

 

[Thorrak]

Hi BrewPi-esp8266 Peers,

I've logged a feature request for selectable network configuration options.

Ideally all the following would be available to the user, and so also to the developer to help with the debugging of network issues:

1) "Automatic Network Configuration" - current controller network configuration method
2) "Manual Network Configuration" - user enters network parameters
3) "Automatic *Initial* Network Configuration" - see below

With option (2) the user manually enters not just the SSID and WiFi key, but also the IP Address, Network Mask, Default Gateway, and DNS server(s).

With option (3) the controller gets it's network configuration as it currently does, automatically from, say a DHCP server, but then continues to use that configuration as if it were manually entered, without ever having to contact the DHCP server again. This way is should get configured correctly in the first place but then not have to rely upon that DHCP server being available, and working correctly, in the future.

Please see the feature request for further details:

Option to manually configure a "true" static IP address, no automatic DHCP network configuration infrastructure required #112

Cheers!
Rob

Hey there! Thank you for your interest in the project - as well as for the feature request on GitHub. GitHub Issues are absolutely the best way to track things as I have the memory of a goldfish.

Unfortunately, I use an external network library to manage the initial WiFi configuration and am somewhat limited by the options it presents. For option 2, I’m happy to see if there is a better “static” option that can be exposed which might make things easier for a user who wants to manually control settings.

For option 3, unfortunately that’s against best practices for a DHCP-controlled network. If the device with the “static” assignment is ever turned off or otherwise disconnected, the DHCP server could assign the IP to a new device since it would be in the DHCP range, and it wouldn’t know not to. Any users who would want to set this likely are savvy enough to also be able to set a static DHCP assignment on the server which is the better way to go about doing this.

I’ll post a response in the GitHub issue as well just so anyone searching there can find it, and will use that to track against Option 2.

Thanks again!

 

[Chris parks]

I hate asking what are stupid questions but between this 100 page thread, the documentation Dow loaded via the Web page and Github I get lost trying to work out where to self help nowadays (must be getting old )

Shifting from a 8266 to a D32 pro with TFT implementation and all works fine. But the back-light appears to time out?
What's the best way to 'wake' the display?

 

[Thorrak]

I hate asking what are stupid questions but between this 100 page thread, the documentation Dow loaded via the Web page and Github I get lost trying to work out where to self help nowadays (must be getting old )

Shifting from a 8266 to a D32 pro with TFT implementation and all works fine. But the back-light appears to time out?
What's the best way to 'wake' the display?

Ah, hm -- there isn't a timeout in the firmware for the backlight -- it should just remain on.

You might want to double check the connections between the board and the screen Are you using the D32 TFT with the D32 Pro (with the LoLin cable)?

 

[Chris parks]

Ah, hm -- there isn't a timeout in the firmware for the backlight -- it should just remain on.

You might want to double check the connections between the board and the screen Are you using the D32 TFT with the D32 Pro (with the LoLin cable)?

Yes to all question, I used the 3 links you used on GitHub so genuine boards as far as I can tell.
Works for a while (I don't know exactly as I don't watch it, but somewhere between 10 and 30 hours I'd say) then just goes full white (so actually, the backlight obviously isn't turning off). I've just reseated the cables both end but they did both appear fully inserted before.

Don't sweat it if it's just me
I think I'll go back to the 20x4 LCD anyway as I find the text, particularly the 'mode' easier to read from a distance (which is usually where I glance from) - when did i get old?

 

[Homebrewer58867]

Hi all, i recently made the change from a very old version of BrewPi, to Fermentrack. I've noticed that with Fermentrack, the fermenting chamber is constantly heating and cooling, almost working against itself? When i was using Brewpi it didn't seem to have this issue and seemed to wait after heating and cooling to see where the temperature "levelled out" before deciding whether to heat or cool again. The room temperature is only a few degrees below my beer setting, so really it should just heat every so often instead of heating and cooling every ~30 minutes.

My beer temp probe is in a thermowell, so it is a surprise to see such quick and wild fluctuations in the beer temperature - although i appreciate that isn't a Fermentrack question

I can't see how to attach an image to this post? There is an "Insert Image" button but that only allows my to insert a URL of the image (if somebody could recommend the best place to upload an image please let me know)

Thanks in advance.

 

[day_trippr]

Try the other " buttons" to find the one that let's you browse your computer for images...

Cheers!

 

[kpietro22]

Hey all, I have two of these controllers built and they are fantastic! Thank you @Thorrak for this!

I do have an "upgrade" question. Is it possible to utilize 2 solid-state relays rather than the typical 5V modules? I am asking simply because I realized over the weekend that my chamber got all the way up to 72F after being set for 40F via Fermentrack. I think I have narrowed my issue down to the relay module and the BeverageAir merchandiser fridge I use for my chamber drawing too much current when the fridge is kicked on. This seems to cause a surge, which in turn also scrambles the controller's display. Long story short, I think this has inadvertently shortened the lifespan of the module and I am hoping I could possibly upgrade it to something a bit more "beefy". Thanks in advance for any and all advice!!

Cheers!

 

[rkhanso]

Hey all, I have two of these controllers built and they are fantastic! Thank you @Thorrak for this!

I do have an "upgrade" question. Is it possible to utilize 2 solid-state relays rather than the typical 5V modules? I am asking simply because I realized over the weekend that my chamber got all the way up to 72F after being set for 40F via Fermentrack. I think I have narrowed my issue down to the relay module and the BeverageAir merchandiser fridge I use for my chamber drawing too much current when the fridge is kicked on. This seems to cause a surge, which in turn also scrambles the controller's display. Long story short, I think this has inadvertently shortened the lifespan of the module and I am hoping I could possibly upgrade it to something a bit more "beefy". Thanks in advance for any and all advice!!

Cheers!

I've used 40Amp SSRs instead of mechanical relays many times. It'll work just fine.
Be aware that there are reports of fake Fotek or other relays that are over-rated. I'm not sure how to tell the difference, but never had any issues.

 

[kpietro22]

I've used 40Amp SSRs instead of mechanical relays many times. It'll work just fine.
Be aware that there are reports of fake Fotek or other relays that are over-rated. I'm not sure how to tell the difference, but never had any issues.

@rkhanso thanks for your feedback. I will make sure to buy a reputable relay. Just out of curiosity, are the Fotek/Omron SSRs isolated from the output voltage? I am drawing a blank on the exact wording, but I remember reading while I was building my controllers that one of the pros to using the smaller Arduino relay modules is that they can be powered independently and are thus isolated from the output voltage. Am I off base? Thanks!

 

[rkhanso]

I'm not knowledgeable enough in electronics to answer that question. Sorry.

 

[Thorrak]

@rkhanso thanks for your feedback. I will make sure to buy a reputable relay. Just out of curiosity, are the Fotek/Omron SSRs isolated from the output voltage? I am drawing a blank on the exact wording, but I remember reading while I was building my controllers that one of the pros to using the smaller Arduino relay modules is that they can be powered independently and are thus isolated from the output voltage. Am I off base? Thanks!

I'd defer to @day_trippr here as he has actual knowledge in this space, but I'm guessing that what you're referring to is the fact that the Sainsmart-style 2-channel relay modules have two separate circuits that can be driven independently to switch the relays. One controls the optoisolator and the second is controlled by the optoisolator and actually drives the relay.

The idea is that optoisolators themselves have relatively low current requirements and therefore can be driven directly off the GPIO pins from an Arduino/ESP. The relay, on the other hand, consumes far more current when being switched on/off as there is a magnetic coil that needs to be driven to move the hardware and complete switching the circuit. For an SSR this isn't necessary (for an Arduino*) as the relay itself contains the optoisolator and doesn't have a power-hungry coil to drive.

There are two problems to be aware of with SSRs, however:

First - the reason for the asterisk above - Arduinos use 5v on the GPIO pins while ESPs use 3.3v. For the Fotek SSRs, the input voltage to switch the SSR is 4-32v DC, with "switch off" voltage being <3.5v. This means that if you drive a Fotek SSR directly off an ESP's GPIO pin, even when "high" the signal to the SSR is below the "off" threshhold. Fixing this isn't difficult -- but effectively involves manually building the same optoisolator-controlled 5v circuit that is on the Sainsmart board.

Second, SSRs by their nature produce a fair bit of heat. You'll want to make sure you have proper cooling available to ensure the SSR doesn't fail -- as well as some kind of backup control mechanism (or risk tolerance), as most SSRs typically fail closed.

 

[BrewdyQuah]

One simple solution is to use a breakout board that supports external power. Just make sure your ESP32 is compatible. This will give you the option of 5v output.

 

[kpietro22]

I'd defer to @day_trippr here as he has actual knowledge in this space, but I'm guessing that what you're referring to is the fact that the Sainsmart-style 2-channel relay modules have two separate circuits that can be driven independently to switch the relays. One controls the optoisolator and the second is controlled by the optoisolator and actually drives the relay.

The idea is that optoisolators themselves have relatively low current requirements and therefore can be driven directly off the GPIO pins from an Arduino/ESP. The relay, on the other hand, consumes far more current when being switched on/off as there is a magnetic coil that needs to be driven to move the hardware and complete switching the circuit. For an SSR this isn't necessary (for an Arduino*) as the relay itself contains the optoisolator and doesn't have a power-hungry coil to drive.

There are two problems to be aware of with SSRs, however:

First - the reason for the asterisk above - Arduinos use 5v on the GPIO pins while ESPs use 3.3v. For the Fotek SSRs, the input voltage to switch the SSR is 4-32v DC, with "switch off" voltage being <3.5v. This means that if you drive a Fotek SSR directly off an ESP's GPIO pin, even when "high" the signal to the SSR is below the "off" threshhold. Fixing this isn't difficult -- but effectively involves manually building the same optoisolator-controlled 5v circuit that is on the Sainsmart board.

Second, SSRs by their nature produce a fair bit of heat. You'll want to make sure you have proper cooling available to ensure the SSR doesn't fail -- as well as some kind of backup control mechanism (or risk tolerance), as most SSRs typically fail closed.

@Thorrak thank you very much for this information! Yes, your quote is correct, but you also have provided me with the information I was looking for insofar as the SSR contains the optoisoloation.

I understand that the ESPs use 3.3v, as I have had to workaround this before. I have a few logic level shifters left over from a previous project. While it complicates the design a little more by essentially rebuilding the Sainsmart board, I suppose I could connect the output from your ESP32 pcb to a logic shifter to boost the voltage up to at least 5v for the SSR. What do you think? This is essentially the same as @BrewdyQuah recommendation.

Secondly, I was thinking that the SSR would not generate that much heat, given the 'relatively' small duty cycle of my refrigerator for fermenting lager/ales. Am I incorrect? These will create more heat that the Sainsmart mechanical relays? I have a 30A Auber brewing controller, so I have certainly figured out how hot an SSR (even with a heatsink) can get on a brew day, but the operation for fermentation is different than controlling a much higher power source, right? I have 3D printed your enclosure for this project, and everything fits nicely. But a traditional SSR heatsink will certainly not fit inside, nor work as it should inside the controller.

The fridge I am currently using is a True GDM10, which is rated at 5A for the first load. I suspect this is actually higher since I can see lights dim when it kicks on. Would you recommend using a different relay board instead? Something such as: Grove - SPDT Relay (30A) ?

Thanks again for your help!

 

[RocketBrewer]

I also use GDM-10 refrigerator's and was having occasional relay failures. The solution I came up with was using an AC triggered SSR like this and just controlling it via the relay board. Not sure it was necessary, but my enclosure was big enough to handle the SSR with a heat sink, so I used it. I've had no issues since

 

[kpietro22]

I also use GDM-10 refrigerator's and was having occasional relay failures. The solution I came up with was using an AC triggered SSR like this and just controlling it via the relay board. Not sure it was necessary, but my enclosure was big enough to handle the SSR with a heat sink, so I used it. I've had no issues since

@RocketBrewer Thanks for your input! Your fermentation setup looks sweet! Do you happen to have a schematic or image of this solution? I'm kind of a visual person haha. Thanks!

 

[Thorrak]

In the interest of cleaning off my desk - both physical and proverbial - I'm going to try to release/clear out as much stuff as I can over the next few weeks leading into year end. The first of these is currently live, and may be of interest to some of you -- I've got 13x 9x BrewPi-ESP PCBs available for free on the "For Sale" forum. Link is here.

I previously had these available for anyone who didn't want to buy/(fully) solder their own boards, but have been moving away from the design in favor of the ESP32 design. Although these are a legacy design originally intended for an ESP8266, I plan to maintain support for these in future firmware releases when powered by a Lolin ESP32-S2 Mini.

If you're interested (or have friends/a homebrew club/whatever) that you think might be interested, they're free - just cover shipping!

This includes ONLY the "base" PCB and "sensor" PCB. This does NOT include things like the relay board, power supply, 3D printed case, etc.

 

[RocketBrewer]

@RocketBrewer Thanks for your input! Your fermentation setup looks sweet! Do you happen to have a schematic or image of this solution? I'm kind of a visual person haha. Thanks!

Quick disclaimer.... I am not an electrician, don't take this as advice, just explaining what I did. If you're not familiar with electrical wiring, I recommend enlisting someone who is! Also assuming that you are in the USA with 120v single phase AC power.


Sorry, I don't have a diagram, but wiring the AC controlled SSR was fairly simple. Instead of wiring the AC "hot" lead directly from the cooling relay to the fridge, It becomes the "trigger" for the SSR and got connected to terminal 3 on the SSR. Terminal 4 got an AC "neutral" (white) connection. Terminal 2 got a AC "hot" supply connection. And terminal 1 is now the switched AC "hot" going to the fridge.


The biggest problem that I’ve had with using the GDM-10 is these fridges cool so fast, it can cause wild overshooting and cycling between heating and cooling, especially the closer the setting is to the room temperature. Through a lot of trial and error, I’ve managed to reduce that quite a bit with the controller settings. If you have issues, just PM me and I can try to help identify the changes I’ve made

 

[Thorrak]

For today's release, I've pushed out an update to my hardware repo on GitHub. Mostly minor stuff, but a few things of note:

• Added build information for the PCBs I have available for free on the "For Sale" forum
• Added a new lid design for LoLin D32 Pro builds which allows a LoLin D32 v1.1.0 LCD screen to be used instead
• Renamed the "All-in-One" PCB to "One Size Fits Most" to more accurately represent what it actually is
• Released some PCB designs for breaking out RJ-11 and RJ-45 jacks

That repo definitely needs some additional work - we'll see how the next few weeks fare!

 

[Thorrak]

Alpha Release Announcement - BrewPi-ESP v16-alpha2

Today is a fun one. I've just released BrewPi-ESP v16-alpha2 which adds expanded support for @inkbird 's IBS-TH1 Plus and IBS-TH2 Plus temperature sensors. The "plus" line of devices have two sensors -- an onboard "internal" sensor and a temperature probe. Previously, BrewPi-ESP would only use the external temperature probe -- now, you can use both.

Why is this awesome? A single IBS-TH2 Plus can simultaneously serve as both the beer and fridge sensor in a "solder free" build. Stick the IBS-TH1 Plus itself inside your fridge to serve as the fridge sensor, and use the probe in a thermowell as your beer sensor. No Tilt? No problem.


Some notes on how this was implemented

BrewPi-ESP assumes that every Bluetooth device provides a single sensor, and tracks it via the device's radio's unique MAC address. In order to support a single device having multiple sensors, I am fudging the MAC address for the external sensor. In the on-device web interface the UI will detect that this is happening and correct the MAC address it displays but Fermentrack.net does not yet have this built in. For now, if you see two devices with their first octet one apart (e.g. 45:00:00:00:00:01 and 46:00:00:00:00:01, or 49:00:00:00:00:01 and 4a:00:00:00:00:01) the one with the higher first octet (46: and 4a: in my examples) is the external probe.

Why the external sensor? The internal sensor is always present, but since the external sensor is connected with a headphone cable it can become disconnected. If this happens, the device will continue to report a temperature on its actual MAC address. In alpha1 this could lead to a scenario where the ambient temp would be reported as the probe temperature, leading to improper heating/cooling.


Oh, and one more thing

This alpha also adds German, Spanish, Portuguese, and Dutch language support to the on-device web interface. More languages to come - if you have requests, let me know!

 

[Thorrak]

Managed to something finished up today that I've been working on since ~January. There is now support for eSPI screen types based on ESP32 controllers.

Support for these is particularly nice for solder-free builds as they are commonly sold as a prepackaged unit. With these, a solder-free build can also become a screwdriver-free one!

Available now on BrewFlasher.

 

[bloombrews]

Managed to something finished up today that I've been working on since ~January. There is now support for eSPI screen types based on ESP32 controllers.

View attachment 864493

Support for these is particularly nice for solder-free builds as they are commonly sold as a prepackaged unit. With these, a solder-free build can also become a screwdriver-free one!

Available now on BrewFlasher.

@Thorrak , all of your hard work for us Brewers, is really appreciated, even if you do not hear this every day.
Your Fermentrack have been working in my Brewery, along with Tiltbridge, for years now, with great success!
Thanks a Million Toasts!

 

[bloombrews]

@Thorrak
With all of your "free time", is it easy for us non-programmers, to edit our Dashboard from saying "Beer Profile" to Wine or Meade, Profile ? Also applies to Wine Constant.... etc.
No biggy, just mentally strange using Fermentrack on a Wine, that says "Beer ......"
Edit.....
Sorry, wrong Forum here. Can not figure out how to "Edit" and delete this post here.