BrewPiLess release v2.4

BrewPiLess release v2.4

  • Brew and calibrate iSpindel
  • Use iSpindel temperature reading as Beer Sensor.
  • Display tilt value of iSpindel.
    This is part of the “Brew and calibrate” functions.
  • Enhance SSE re-establishment
  • Default configurable minimum cooling/heating time & back-up sensor. (That is, Glycol supported.)
  • HTTP Port settings in Config page.

    Please note: you will have to run Device Setup to setup temperature sensors and PIN usages if you are upgrading from old version other than glycol option. 

I really like the new “Brew and Calibrate” feature. My iSpindel works great. However, every time I open the cap to charge it, the stuff inside moves a little, and the readings will drift a little bit. The result of using this method is better than that of calibrated one.

BTW, the working principle of iSpindel is exactly the same as a hydrometer. Therefore, temperature correction is necessary.

In the following chart, Purple line is temperature-corrected reading and green line is non corrected readings. Without correction, the gravity reading rises when the temperature drops. The corrected reading also rises a little bit, though.

The gravity readings used to calibrate iSpindel should be NOT temperature-corrected. The way of deriving gravity values from TILT values is using a function(formula) having a single parameter, the tilt value. We assume that there exists such a function exists and try to find one that is approximate to the perfect one.

The physics principle of iSpindel is the same as a floating hydrometer. A hydrometer will show different values for wort at different temperatures.

For example, wort of 2.6% BRIX will be measured as 1.010@20C, 1.011@4C, and 1.009@24C. The Specific Gravity, which is the value after temperature correction applied, will all be 1.010, calibration to 20C.

The TILT values should be different in the same wort at different temperatures because the density of the liquid is different. Let the TILT values of 1.009, 1.010, 1.011 be x1, x2, x3. It’s not possible to have a function, f(x), so that f(x1) = (fx2) = f(x3) = 1010. Obviously, finding a function, f(x), so that f(x1) = 1.009, f(x2) = 1.010, f(x3) = 1.011 is possible. Applying the temperature correction, the correct Specific Gravity can be derived.

BrewPiLess for Glycol

BrewPi is derived from BrewPi v0.2.x, which is designed for fermentation chambers made by fridges. The latest BrewPi v0.4.x has evolved to be a general temperature control unit. The code is very different from v0.2.x, and porting v0.4.x might not be an easy job. Instead, I implemented two main features that might make glycol possible: fallback sensor and adjustable minimum time.

In addition to using binary for glycol or building with “EnableGlycolSupport” defined, there are setups and settings that must be tweaked.


  • Don’t use Fridge Sensor. The “fallback” feature will use the reading from Beer Sensor as Fridge reading.
  • (optional) Use second sensor as Room Sensor to monitor glycol temperature.
  • Beer Constant or Beer Profile mode is preferred.


  • minimum times: including minCoolTimeminCoolIdleTimeminHeatTimeminHeatIdleTime,and deadTime
    All except deadTime are self-explanatory. deadTime defines the minimum idle time between heating and cooling, and the waiting time at power-up. 10 seconds seems to be good for all of the values.
  • idleRangeHidleRangeL
    The values define the temperature range to stay in idle. That is, no action will be performed if the fridge temperature(from Beer Sensor) stays in this range. The default values are 1.0, so it will start cooling when the temperature reaches 21 degree if the set temperature is 20.
  • maxHeatTimeForEst & maxCoolTimeForEst
    After cooling or heating, the algorithm expects the temperature to go lower or higher. Usually the temperature won’t go too far in glycol setup. Therefore, set a smaller value for these two, so that it won’t wait too long for detecting peaks.
  • PID settings. Kp, Ki, Kd
    If all of them are set to zero, the FridgeSet will be equal to BeerSet.
  • (optional) filter settings: fridgeFastFilt, fridgeSlowFilt, fridgeSlopeFilt, beerFastFilt, beerSlowFilt, beerSlopeFilt
    Even the data is from the same sensor, the temperature readings of beer and fridge sometimes differ. It is because that they use different filters. The temperature of fridge is volatile, while the beer temperature changes slowly. If you want them to be strictly the same, the filter parameters should be set to same same.

After setting, you can use “c” (single lower case c) to read back the setting for verification.

My testing

This is my initial test by filling 6 gallons of water in my newly purchased Spike CF10 with coil.


My test was conducted with a cooler with frozen PET bottles. The room temperature is  the temperature of water in the cooler.

I set all minimum times to 10 seconds, idleRangeH to 0.1. maxCoolTimeForEst to 30 seconds. PID parameters are left untouched. The result seems acceptable except that more PET bottles (or, a glycol chiller) are needed.

BrewPiLess v2.1 available

By using the word “available”, I mean that it is not well tested, and I don’t have enough confidence of it.

New Features

The major improvement of this version is about gravity stability and beer profile handling.

  • More flexible, and complicated, beer profile.  Detail@Github
    • New stable gravity condition by checking the gravity differences between current reading and up-to 72 hours ago.
    • Specifying gravity condition by apparent attenuation(%), which makes it easier to reuse beer profile. OG must be provided.
  • Fermentation progress indication
    • It is just a simple indication that the gravity change within last few hours is less than the specified gravity stable threshold.
  • Low pass filtered gravity reading
    • To filter out wrong readings by bumping, a simple low pass filter is applied, and filtered data is used in beer profile algorithm. The filtered data is shown in this version. (check Github for more detail.)
  • (LogViewer) Exporting data to CSV format

Bug Fixes

  • Wrong auxiliary temperature( temperature reading from iSpindel) display
  • beer profile related bugs
  • (Utility) iSpindel Calibration utility showing the same line for both polynomial.

Information of BrewPiLess v1.2.6 and V2.0

I used to think that BrewPi already has everything for fermentation temperature control and there isn’t much to be done. It had been true before release v1.2.5, in which the basic functions of BrewPi are implemented.

Well, there are always fresh ideas, and now I am working on gravity related features. Two main related feature are

  • gravity recording/logging
    • manual input
    • updated by other device, iSpindle.
  • gravity-based temperature schedule

The logging function is trivial but the gravity-based schedule is not. In my opinion, the way to specify beer profile in BrewPi is a good design, but I couldn’t figure out a way to extend it. Therefore, a new way to specify the schedule is created, and I would like to put it in version 2.0 because I regard it as a break through. The gravity logging will be available in version 1.2.6 with original time only beer profile.


My current design of new beer profile:


  • “days” specify the duration of the step. It’s different from “Day” in original beer profile
  • The condition to finish a rest step can be
    • longer than a specified time
    • less than a specified gravity
    • both conditions meet (time AND gravity)
    • either one meets (time OR gravity)
  • A “ramp” step is necessary in the transition of two rest steps.
    • this design allow specifying the speed of temperature change
  • For steps that use gravity as condition, the “days” field is still necessary
    • to draw the chart
    • under certain conditions, it can be used to derive current steps.
  • Changing the profile while beer profile is running will have undetermined result when gravity is involved.


The logging with manual input is available in “preview” branch. The input of iSpindle hasn’t been implemented yet. Currently, only manual input of gravity is available.

An issue I would like to highlight is that the gravity values are more concrete than temperature especially when it is manually input. In my option, a line between two gravity  values is meaningless, but it helps to track the values. It would be very difficult to find the points of gravity values without connected them by a line.

BrewPiLess Release 1.2.5

  • Showing temperature chart when it is not being recorded
    • The data is saved in a circular buffer good for around 2-3 hours.
  • Moving the temperature control to main page.
  • Temperature chart for beer profile editing
  • Fast loading setting for temperature management control page(now main page)
  • Reload the temperature chart after start/stop saving log
  • Showing name of current saving log, blank if not saving
  • Fix bugs of not showing room temperature in legend area


(The BrewPiLess is running “Beer Constant” mode, and the Beer profile displayed is the saved one. )

BrewPiLess Release 1.2.3

This release is to solve one issue.

Under certain circumstances, the log chart will not shown.



The cause is that the reading from SPIFFS returns zero. I suspect it has something to do with resources for file handle of SPIFFS. According to an advice I googled, I kept file handle opened and reused it to read the log. The solution is to close re-open the file when reading fails.

Release v1.2.2

The major enhancement is on the format of “remote logging”.

  • Add PUT method
  • Use printf-like format
  • Data Type.(Content-type)

The printf-like format and specification of content type provides maximum flexibility. You can use any format with your own “field name” or “variable name”. So far, form type ( and JSON format ( have been tested and verified. I hope to test XML format if I can find one.

You can find the example in at GitHub.


Temperature Logs for BrewPiLess

BrewPiLess now supports data log LOCALLY. Given the fact that there is 3M space of 4M flash on NodeMcu or WEMOS D1 min, it seems to be a waste not to use the space, not to mention that WEMOS D1 pro has 16M flash.


Some fact about the log:

  • The log won’t start automatically. You have to start it at log setting page.
  • The temperatures are logged every minute.
  • A 30 day log will take around 350k bytes. That might imply that 3M space can record around 6 month data. However, there is no guarantee of the robustness of SPIFFS.
  • Changing temperature when logging will result in wrong data interpret.
  • Maximum 10 logs. The logs will not be deleted automatically. Manual deleting is necessary.
  • Internet access is required to view the chart. To save some more space and to alleviate the loading of ESP8266, the library is not put in the ESP8266.
  • Off-line viewer is available.

General Brew Controller

I had thought that ESP8266 might not be as stable as Arduino because it is more complex and performs a lot of networking related jobs. It turns out that ESP8266 is stable enough for my purpose, though lacking of documentation and immature libraries are still issues.

I have bought some Arduino boards for BrewPi builds and BrewManiac. Now they are all replaced by ESP8266. I am happy about it. However, my setup isn’t solid enough:

  • The buzzer is not loud enough
  • The driving voltage and current of SSR might be out of specification.
  • The LCD contrast is not good under 3V3
  • The extra IO Expander board and DUPON lines look messy.

I have limited knowledge about circuits, but I tried my best by referencing other circuits to create this schema which can be used in both BrewManiac and BrewPiLess. It is simple by just using transistors to control actuators, PCF8574 for input via I2C, and 5V-3V3 level shift logic.


The design goals:

  • Input can be 4x keypad or rotary encoder module.
    • BrewManiac: 4x membrane keypad, connecting GND,P0-P3
    • BrewPiLess: rotary encoder, connection 5V,GND, P0-P2
  • Buzzer driven by 5V, controlled by a transistor.
  • Direct connect to SSR and relay.
    • BrewManiac:connect heater SSR to Act1. SSR or relay module to ACT2.
    • BrewPiLess: 2 way relay board or SSRs by your choices
  • Act3 is optional.
  • 5V power. As far as I know, power isn’t a easy topic. Therefore, I avoid regulator.
  • 5V interface for I2C LCD.

SSR is good for AC devices, but the relay modules are very cheap and small, and it’s easier to find the whole module than to find the sole relay. It would be perfect if the same terminal can be used to connect both SSR and relay module, but I don’t how to do that by using the same terminal. Therefore, the PINs output is directly connected to the auxiliary header PINs.

Any opinions are welcome.

BrewPiLess under AP mode

BrewPiLess now can run in AP mode, which enables it to run stand alone. The newly modified WiFiManager has a new option, “Soft AP Mode”. Soft AP mode will also be entered if the network setting is not configured in three minutes (and previous connected network doesn’t exist, or there is no previously connected network.) This design is to enable recovery from power shortage or system reset. Without this feature, BrewPiLess will hang at the network setting state and won’t perform temperature management funcitons.

For scheduled temperature management, aka Beer Profile mode, the “time” information is needed to manage the temperature, but NTP server will not be accessible without internet connection. Therefore, manual setup of “time” is necessary in this mode. In page of “Temperature Management”, aka /control.htm, a SET TIME button will be shown when the time of ESP8266 is far away from the computer/phone. Pressing that button will set the time of ESP8266 to the time of the computer/phone, or the browser to be exact.

To enable automatic recovery from power shortage or system reset, the time informatoin is saved periodically and restored at boot-up if NTP is not accessible, which means the duration of power shortage is assumed to be zero. If the power shortage lasts too long, the shedule will not be on track. For example, if the power shortage lasts 8 hours, the schedule will be off for 8 hours since that 8 hours is missing for ESP8266. Without a RTC, this might be the best I can do.

mDNS doesn’t work under AP mode. Therefore, “brewpi.local” can not be used under AP mode, but “” will do the job. In fact, all domain names except those in Apple’s Captive Portal checklists will do.

Known issues:

  1. Sometimes, under AP mode, the web server cannot be connected. I don’t have any idea about the reason. ESP8266 is not well documented, and we don’t have full access to the source code. I am guessing that it might because of timing issue.
  2. Sometimes, on Apple platforms, the setup page can’t be closed because of the “done” button does not show, but the “cancel” button persists. This might be the same issue as previous one.