BrewPi@ESP8266, no need of RPI and Arduino.

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Update:
1. I was wrong about the rotary encoder. Now the rotary encoder is not supported by direct connecting to ESP8266.
2.To support the rotary encoder, an additional PCF8574 board is necessary. Please check the source code for detail information. (I don't recommend to do this. Therefore, I am going to save some typing about it.)
Given the change @Thorrak just made with his project to allow auto-detection of the LCD, do you see a conflict here with this? Seems like having two I2C devices would remove the ability to auto detect those devices unless they respond with unique information when queried. I don't know a lot about I2C so maybe there's a way around the various addresses that seem to be used by manufacturers.

I've been messing with my Arduino and shield a bit and can see where having the encoder might become a more firm need with the LCD - without a timeout the screen will likely burn-in. Without an encoder there's few choices to be able to wake the screen back up.
 
fwiw, I2C commands encode a Device Type and a Device Address in the 7 or 10 bits of a transaction sequence (depends on the Device Type whether 10-bit addressing applies).
Only a Device of the requested Type is allowed to respond, and the base I2C spec provides a 4-bit Type and 3-bit Address.
So you can have at least 8 Devices of a given Type on a bus...

Cheers!
 
Unfortunately, most I2C LCD are in fact normal LCDs with IO expanders. I found the I2C board of my LCDs are made of PCF8574 which is exact the same as the one I use for rotary encoder. Therefore, it is not possible to distinguish them.
What I can think of is to assume the ranges of addresses of them.
 
Unfortunately, most I2C LCD are in fact normal LCDs with IO expanders. I found the I2C board of my LCDs are made of PCF8574 which is exact the same as the one I use for rotary encoder. Therefore, it is not possible to distinguish them.
What I can think of is to assume the ranges of addresses of them.

Easily solved: presuming the LCD uses Type/Address code of 040 (base8), on your rotary encoder implementation, tie one of the Ax pins to VCC (I suggest A0, so your target would then be 041)...

Cheers!
 
btw, how were you planning on "reading" the encoder switch?
Does the esp8266 have an interrupt pin/function so you can use the INT output from the PCF8574?
I imagine simple polling would be a hit-or-miss strategy...

Cheers!
 
Yes. I use GPIO 0(or 2 ) as the interrupt input from PCF8574. The INT pin is in fact inverted and required to be pulled up. I have played rotary encoders and found that it's not smooth by simple polling.
 
I was told about this tiny OLED LCD. It is too cheap to pass. $4 from eBay.
Too lazy to write a new testing sketch, I just did a dirty adaption to BrewPi.
It might be good for someone who wants a smaller controller.

The LCD has 128x64 pixels and sizes at 0.96". I use a fixed font of size 6x12, which makes 5 lines and 20 letters per line. The BrewPi uses only 4 lines, so I am thinking about using the extra space for IP address or something else.

The code works but is kind of dirty. Therefore, I will check in only if someone needs it.

BTW, this LCD works pretty good under both 3V3 and 5V.

OLED.jpg
 
That's an awesome little display, I like it!

How are you handling the (seemingly) random addresses in the I2C devices?
 
That's an awesome little display, I like it!

How are you handling the (seemingly) random addresses in the I2C devices?

Well, as long as you know how to use Arduino IDE, you know how to SCAN the addresses.

In fact, I was too lazy to scan. I just tried the few possible addresses.
For 20x04 LCD, 0x27 or 0x3F. (I believe it can be decided by checking the IC and address selection PINs on the board, but I have bad eyes.)
For this OLED LCD, 0x3C-0x3D.
For the PCF8574, I decided it by connecting the jumpers.


FYI,
You can find the information about the I2C LCD here:
https://arduino-info.wikispaces.com/LCD-Blue-I2C
 
Well, as long as you know how to use Arduino IDE, you know how to SCAN the addresses.

In fact, I was too lazy to scan. I just tried the few possible addresses.
For 20x04 LCD, 0x27 or 0x3F. (I believe it can be decided by checking the IC and address selection PINs on the board, but I have bad eyes.)
For this OLED LCD, 0x3C-0x3D.
For the PCF8574, I decided it by connecting the jumpers.
I mean does the code need to be recompiled each time, or are you using external configuration of some sort?
 
I mean does the code need to be recompiled each time, or are you using external configuration of some sort?

I just recompile it.

The address detection can be done by assuming you can control one of them or at least in a range. It might be difficult if you are buying those from eBay like me.
For example, I preferred to set all addresses to LOW because I don't see any pull-up resistors on the boards. The IO Expander board I bought was described and pictured as PCF8574/PCF8574T. However, I got PCF8574AT. Setting A0-A3 to low will make PCF8574 at address 0x20 but PCF8674A at 0x38.
According to the URL I posted two post before, there are some LCDs with 0x20 address, although most of them are 0x27 or 0x3F.

BTW, I can do the scanning in a dirty but easy/simple way, or structural but lousy way. I can't figure out clean and structural way. (Using one one I2C device is another story.)
 
Yeah, recompiling is beyond the ability of most casual users. I'm not a software engineer but probably more capable than most casual users and I'm still having issues with some of the libraries on one of the other projects. In order to "put it within reach of the masses" if that's a goal, some way of allowing a non-technical person to configure it probably needs to be considered.

I'd love to see a merge between the two ESP8266 projects myself, but until that little chip grows a new I/O or two, divergent paths may be inevitable.

I say all this not having installed this one yet. As soon as the slow boat from China makes it here I may give it a go and see what I can do with it.
 
Yeah, recompiling is beyond the ability of most casual users. I'm not a software engineer but probably more capable than most casual users and I'm still having issues with some of the libraries on one of the other projects. In order to "put it within reach of the masses" if that's a goal, some way of allowing a non-technical person to configure it probably needs to be considered.

I'd love to see a merge between the two ESP8266 projects myself, but until that little chip grows a new I/O or two, divergent paths may be inevitable.

I say all this not having installed this one yet. As soon as the slow boat from China makes it here I may give it a go and see what I can do with it.

Point made.I've built some images with auto addressing ability.

The goals of Thorrax and me are different. He wants to use ESP8266 to replace Arduino and get WiFi connectivity. I wanted to replace RPI, and I merged the Arduino code after learning Thorrax already did the porting. I think I can merge the code for WiFi link to RPI from Thorax's code, but why bother? If you need the full power of BrewPi by deploying a Raspberry Pi, go with Thorrax. If you want to save a RPI and feel that the functions of my code is enough, then take it. Taking the web related part from my code, it has nothing more than Thorrax's. Regarding the rotary encoder function, it is very easy and my code is available on-line. However, needing additional hardware and the fact that it is not very useful ( I would rather get the setting done via web interface), I think Thorrax might put it in the low priority list even if he considers doing it.
(When typing this, one idea comes to me for solving your issue of waking up the LCD. Since you don't need the real rotary encoder as input, one "wake-up" button might do the job. The button should usually be pull-up, so D3 or D4 can be used.)

BTW, allow me to ask how do you flash the image without Arduino IDE? Is it easier than using Arduino IDE?
 
BTW, allow me to ask how do you flash the image without Arduino IDE? Is it easier than using Arduino IDE?
I missed this questions - so sorry! I used NodeMCU's flasher:

https://github.com/nodemcu/nodemcu-flasher

Yes, very much easier than the Arduino IDE. It's somewhat possible for a mere human to use where I've always had some issue or another with the Arduino IDE.
 
I was told about this tiny OLED LCD. It is too cheap to pass. $4 from eBay.
Too lazy to write a new testing sketch, I just did a dirty adaption to BrewPi.
It might be good for someone who wants a smaller controller.

The LCD has 128x64 pixels and sizes at 0.96". I use a fixed font of size 6x12, which makes 5 lines and 20 letters per line. The BrewPi uses only 4 lines, so I am thinking about using the extra space for IP address or something else.

The code works but is kind of dirty. Therefore, I will check in only if someone needs it.

BTW, this LCD works pretty good under both 3V3 and 5V.

Can i have your dirty code? :) I just received the same oled LCD (only 2.59 euro here https://www.aliexpress.com/item/new...-IIC-SPI-Serial-new-original/32389025950.html ) It would be really fun (and COOL!) to have this working with brewpi on the esp8266

Jan
 
I missed this questions - so sorry! I used NodeMCU's flasher:

https://github.com/nodemcu/nodemcu-flasher

Yes, very much easier than the Arduino IDE. It's somewhat possible for a mere human to use where I've always had some issue or another with the Arduino IDE.

Thank you for the information. Not aware of that, I thought the only ways to flash are IDE, command line, and awkward Espressif official flasher. IDE is the easiest one of all.
 
I have one of those displays too (0.96" OLED), so I mocked up a sample on the Pi Zero. I could probably write a driver for Fuscus quite quickly, but I don't like having too many additional packages. I suppose it doesn't matter really.

I used a 6x12 bitmap font which gives a 21x5 display. The bottom line is a clock and spinner.

IMG_20161127_101032.jpg
 
Good idea. Displaying time seems to be a better idea than IP.

Well, at startup I display the IP address, although I can access the computer by name (brewpi.local). Then during operation I show the local time, followed by a spinner (|/-\|/-\) to show that the main loop is still alive. I suppose I could scroll the bottom line with other info, or cycle through a few status items.

I hacked together a quick cheat- my main code dumps the LCD content into a file, then another program reads the file and dumps it to the display. Later I'll add native support (maybe).

I think the 0.96" display is a little small. I might buy a 1.3" version and see how it looks.
 
I bought a 1.3" module, but it is the pale blue one, which I don't really like (white was not available for fast delivery). I set it up with rmhull's excellent library and mocked up a quick display. I am not sure if bigger is better actually.

IMG_20161212_222130.jpg
 
I bought a 1.3" module, but it is the pale blue one, which I don't really like (white was not available for fast delivery). I set it up with rmhull's excellent library and mocked up a quick display. I am not sure if bigger is better actually.

IMO, 1.3" is not bigger enough. Something like 2.8" or 3.5" might be. However, the 20x4 hd44780 LCD is cheaper and big enough.
Since BrewPi, or my mod, can be accessed via network, the LCD is just good when walking by the fermenter. I think a small and cheap Lcd will do its job.
 
IMO, 1.3" is not bigger enough. Something like 2.8" or 3.5" might be. However, the 20x4 hd44780 LCD is cheaper and big enough.
Since BrewPi, or my mod, can be accessed via network, the LCD is just good when walking by the fermenter. I think a small and cheap Lcd will do its job.

I agree. In my original design I used the Nokia 5110 surplus LCD module. It was the cheapest I could find (about $3.50) and gives me a 6 line by 17 character 1.6" display. I think it's good enough, but I wanted to try the OLED modules as they are cool, but more expensive.
 
Check this shameless BrewPi knockoff.
Given the fact that NodeMcu has 4MB flash, not to use the space might be a waste.
Although I intended to make it look like BrewPi, the result makes me feel a little embarrassed (yet satisfied) because it look like a cheap knockoff, (yep, it is).
Per my calculation, 3MB file space of 4MB flash will last over half a year before running out. However, I don't have such confidence on the robustness of ESP8266 system.

[Edit] The local logging function is not yet on GitHub. I will push the code after running it for at least one week or two. BTW, I am not fermenting anything but putting a keg in my fermenting fridge, so the chart doesn't look quite right.

brewpiless.new.jpg
 
Some folks are using them on their chambers. As with anything it's worth exactly what you pay for it so you might want to test in your own situation first.

I thought I read about someone using an SSR but I'm not sure who that is. Maybe they will speak up.
 

Both of them should work just fine.
I've used both.

Thanks Is it in stable condition now? ok to use on fermentation and storage chambers?
Anyone used SSR with these?

I've deployed in two fermentation chambers made from mini fridges and have run it since I release the code. It has been at least as stable as or maybe even better than my old Arduino BrewPi builds. I have to admit that I don't know if the system had crashed or not because there was no log before the temperature log feature is implemented. The latest code with logging feature has run since 12/28 without any issues. (I re-started it for fix a small glitch today.) I believe the old code without logging feature should be more stable.

SSR might work fine. I've tried connecting SSR directly to the PIN of NodeMcu, and it worked. (That was for my other project, BrewManiacEx.) You might have different result for different SSRs.
SSR is better because mechanical relays might generate EMI to cause the scrambled LCD display. However, it is more expensive and bulkier.
 
Some folks are using them on their chambers. As with anything it's worth exactly what you pay for it so you might want to test in your own situation first.

I thought I read about someone using an SSR but I'm not sure who that is. Maybe they will speak up.


Yeah I used and SSR for a mini sous vide works fine.
 
Both of them should work just fine.
I've used both.



I've deployed in two fermentation chambers made from mini fridges and have run it since I release the code. It has been at least as stable as or maybe even better than my old Arduino BrewPi builds. I have to admit that I don't know if the system had crashed or not because there was no log before the temperature log feature is implemented. The latest code with logging feature has run since 12/28 without any issues. (I re-started it for fix a small glitch today.) I believe the old code without logging feature should be more stable.

SSR might work fine. I've tried connecting SSR directly to the PIN of NodeMcu, and it worked. (That was for my other project, BrewManiacEx.) You might have different result for different SSRs.
SSR is better because mechanical relays might generate EMI to cause the scrambled LCD display. However, it is more expensive and bulkier.

Thanks a lot :) I will give it a go then, the Arduino is ok, but has caused som freezing issues which gave both a hot chamber and a cold one. I fixed this issu by making a scheduled reboot on the Pi.

I actually have some good SSR`s @ home (Kyotto) - it`s just laying around. Might give them a go then :)
 
Thanks a lot :) I will give it a go then, the Arduino is ok, but has caused som freezing issues which gave both a hot chamber and a cold one. I fixed this issu by making a scheduled reboot on the Pi.

I actually have some good SSR`s @ home (Kyotto) - it`s just laying around. Might give them a go then :)

My Arduino builds also had freezing issues, and I solved it by adding a watchdog timer. One of the build usually had a scrambled LCD after around a day or two. Therefore, I knew it had hanged and restarted when I saw the LCD turned normal.
After replacing Arduino with ESP8266, the one that had scrambled LCD still has the issue but after a longer time, around 2-4 days. However, the LCD never turns "NORMAL" after that. Therefore, I conclude that BrewPiLess on ESP8266 might be stabler than Arduino build.

The watdog timer fix is easy if you know how to build the code.

In Main.cpp (platform/avr/Main.cpp or brewpi-avr/Main.cpp)
Add "#include <avr/wdt.h>" in the beginning.

Code:
#include <avr/wdt.h>
#include "Brewpi.h"

// setup and loop are in brewpi_config so they can be reused across projects
extern void setup(void);
extern void loop (void);

Enable the timer and kick it in the loop.

Code:
void main(void)
{
	init();

	#if defined(USBCON)
		USBDevice.attach();
	#endif
	
	setup();
	
       wdt_enable(WDTO_8S); // set to 8 seconds
        for (;;) {
                wdt_reset();  // kick the timer
	
	       loop();
		if (serialEventRun) serialEventRun();
	}
}

The down side of this fix is that when edit the setting by rotary encoder, you have to finish the editing in 8 seconds. The menu handling code uses another loop, and I was too lazy to find and fix it since I can live with it.
 
@pocketmon - thanks a lot :)

oh. I forget to mention that some old version of Arduino nano bootloader won't reset the system on watchdog timeout.

Check this link:
https://forum.arduino.cc/index.php?topic=412315.0

I happened to use a nano on my second build, and the system hang when I was in Vegas. It took me a while to find out this. After updating the boot loader, it worked fine.
 
@pocketmon Run into some problems installing the BrewPiLess

This is the message.

Arduino: 1.6.9 (Windows 10), Board: "NodeMCU 1.0 (ESP-12E Module), 80 MHz, 115200, 4M (3M SPIFFS)"

In file included from sketch\DisplayLcd.h:33:0,

from sketch\Display.h:29,

from C:\Users\Stig Berntsen\Documents\Arduino\BrewPiLess-master\BrewPiLess\BrewPiLess.ino:14:

sketch\IicOledLcd.h:13:21: fatal error: SSD1306.h: No such file or directory

#include "SSD1306.h"

^

compilation terminated.

exit status 1
Error compiling for board NodeMCU 1.0 (ESP-12E Module).

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

I first tried with all the libs linked in the Guide on http://vito.tw/brewpiless/ step 3. Then I got a message stating there where no version for the ESP8266HTTPUpdateServer - then I found your package from dropbox and went for that one.

Any clue what is wrong?
 
It's my fault. I will fix it ASAP. Please open Config.h

comment out 224, and uncomment 225, like this

//#define BREWPI_OLED128x64_LCD 1
#define BREWPI_IIC_LCD 1
 
Back
Top