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

[Thorrak]

Hey Thorrak, did you end up running this comparison, or is it still in the works?

I haven't run this yet. My initial plan was to do all the devices at once, but I'm thinking I'm going to do the iSpindel/Tilt separately (once iSpindel support for Fermentrack is finished/working).

I need to get my closet cleaned out.

 

[Thorrak]

If you add or remove a onewire (DS18B20) sensor to/from the bus, is there a period of time in which it refreshes what's on the bus, or a way to manually scan and refresh (IE: adding or removing a fermenter)? Or is the only way to power cycle the ESP8266? While my chamber and room temp sensors won't change, I have three fermenters, each with its own DS18B20 device in the thermowell.

The OneWire bus rescans every few seconds, but there is a delay in when it reports back to Fermentrack. If you've added a device and you aren't seeing it in Fermentrack let me know and I can take a look.

That said - you'll need a separate ESP8266 for each fermenter. Not enough IO pins.

With BrewPi, there was a bar at the bottom of the graph that showed when it was heating or cooling. Basically, there would be blue when it was cooling, red when heating and nothing when idle. From looking at the graphing, it *appears* as if it cooled for about 10 minutes, stopped cooling for about 10 minutes, started cooling again and repeated that cycle twice so far. Is there something I missed that would add that to the graph, or is it not there? If it's not there, any chance it could be added in a later release?

I also note that there doesn't seem to be much related to the chamber door, which has a pin - perhaps a 'door status' line could be added to the panel on the right that has the temps and settings under the 'log interval/device settings' box (without something like that, how would you even test to see if it's working right?)?

Unfortunately, you're correct. That is a feature that is currently missing. There is a plan to add it at a later point, but it's not an easy add -- and I absolutely hate working with DyGraphs at the moment. The data is being logged, however, so once the display bit is fixed it should appear for both past and future fermentations.

For the chamber door, I believe it's working as intended at the moment. You should get annotations (little flags) when the door is opened/shut - but that's about it. At some point in the future this could be revisited if a case could be made as to how the data would be useful. (Side note - I actually don't use door sensors in any of my builds, hence why I haven't focused on it)

 

[Cougar281]

The OneWire bus rescans every few seconds, but there is a delay in when it reports back to Fermentrack. If you've added a device and you aren't seeing it in Fermentrack let me know and I can take a look.

That said - you'll need a separate ESP8266 for each fermenter. Not enough IO pins.

Cool - I'll be more patient next time I swap fermenter sensors

And of course, if you have a fermeting chamber big enough for multiple vessels, you could monitor the temps of all of the vessels on one ESP8266, but of course each chamber would need its own controller.

Unfortunately, you're correct. That is a feature that is currently missing. There is a plan to add it at a later point, but it's not an easy add -- and I absolutely hate working with DyGraphs at the moment. The data is being logged, however, so once the display bit is fixed it should appear for both past and future fermentations.

For the chamber door, I believe it's working as intended at the moment. You should get annotations (little flags) when the door is opened/shut - but that's about it. At some point in the future this could be revisited if a case could be made as to how the data would be useful. (Side note - I actually don't use door sensors in any of my builds, hence why I haven't focused on it)

Only reason I can think of to be able to see its status really is for testing. Is it supposed to be pulled high or low, and is that supposed to indicate opened or closed?

 

[Bigdaddyale]

https://www.raspberrypi.org/blog/gpio-expander/

 

[JWBC]

So i just install fermentrack and flashed my arduino uno and got a profile setup for what I am fermenting but for some reason the graph is not showing. When I inspect the page it shows that it can not find the csv. Any thing you can think of on what could be causing this?

 

[Thorrak]

Hi Thorrak,
Though I am happy using my ESP-8266 based system controlled by Fermentrack. However, I would like to use a Particle Photon Spark as a core system, and hence can you kindly provide an update as to what timescale you intend to add the Spark support to Fermentrack out please?
Thanks.

In my head, there’s three types of support for the Spark (or Spark-based devices) that could be built:

1. Support for “modern” (0.4 or 0.5.x line) controllers
2. Support for the official spark-based BrewPi controller
3. Support for flashing spark devices with firmware (similar to what exists with the ESP8266)

Right now, 1 and 2 are the same, as the only “modern” firmware is the one for the official BrewPi controllers - but this isn’t strictly true. We can build support for the 0.4.x line of firmware potentially without supporting wherever BrewPi lands firmware wise. This is especially true if I ever manage to finish my port of the 0.4.x line to the ESP8266.

That said, this is really what decides the timeline at this point. I don't own a spark-based BrewPi, and thus I don't have a test bed to test modern controller support against. If I finish the 0.4.x port then Fermentrack won't be too far behind. I don't see either of these happening within the next 3 months, however. There's still a few things left to do to complete support for legacy controllers.


For #3, honestly I don't see this happening any time soon - if ever. While supporting the modern line of firmware is something I'd be keen to do if there was a way to flash it to ESP8266/Arduinos, I'm not as personally invested in the Spark platform and haven't looked into developing for it. I'd be more than happy to help anyone that was invested in it to implement support for flashing, however.

 

[Thorrak]

So i just install fermentrack and flashed my arduino uno and got a profile setup for what I am fermenting but for some reason the graph is not showing. When I inspect the page it shows that it can not find the csv. Any thing you can think of on what could be causing this?

I'm assuming you've tried waiting a few minutes & hitting "refresh" on the dashboard page. If not, do that. You generally want at least two data points to be written, and that can take up to ~3x the log interval to occur if you happen to be particularly unlucky. If memory serves, the default log interval is 30 seconds, so this could take up to 1 minute 30 seconds,

How is the temperature control otherwise? Are you seeing temperature come into Fermentrack and be displayed on the dashboard panels?

 

[JWBC]

Everything else is coming in just fine. I've had it running for about 7-8 hours and it still comes up 404. I'll try creating a new profile and see if that one has an issue.

 

[Thorrak]

Everything else is coming in just fine. I've had it running for about 7-8 hours and it still comes up 404. I'll try creating a new profile and see if that one has an issue.

Hmm - Did you only create the profile, or did you start a beer logging also?

 

[JWBC]

I just mixed up my terms there. I'll create a new beer to log. It just started. But I created a profile for the fermentation and the started the beer and applied the profile.

 

[JWBC]

So it might have been user error. I created a new beer and now at least the graph show. It wasn't before. It shows a couple of data points. I'll blame beer and lack of sleep.

 

[Klooid]

Hi Thorrak,
Thanks for the update on the Particle Photon Spark version, much appreciated.

 

[sctcts]

So I'm trying to convert my brewpi-www setup to use fermentrack but I'm getting this error when I go to add my arduino:

I'm not actually able to choose anything on board type, it's filled in when I get to this page. On the previous page (Serial Controller Auto-detection, Step 3 - Identify controller), the type was listed is unknown. When I flashed the board, it showed the type listed as arduino uno.

For reference, this is a clean install of both raspbian and fermentrack. The arduino was already flashed with the brewpi firmware from my last brewpi install. Tried re-flashing, no change. I'm skeptical whether the re-flash actually worked since the arduino LCD is still displaying the same settings as before...

 

[Thorrak]

For reference, this is a clean install of both raspbian and fermentrack. The arduino was already flashed with the brewpi firmware from my last brewpi install. Tried re-flashing, no change. I'm skeptical whether the re-flash actually worked since the arduino LCD is still displaying the same settings as before...

Sorry about that!

I just pushed out an update that should fix this issue. Sorry about that. If you want to fix this tonight, you may need to trigger the update manually. To do this, just click the "Gear" in the upper right hand corner of Fermentrack, click "Update from GitHub", and follow the prompts on the resulting page to update.

To your point about flashing - Flashing the Arduino doesn't actually clear the EEPROM, so you will generally see your existing configuration options following the flash. I think there's an option somewhere in the Arduino IDE to trigger an EEPROM reset on flash, but you can also reset the EEPROM from the configuration page within either Fermentrack or BrewPi-www.

 

[JWBC]

So I'm trying to convert my brewpi-www setup to use fermentrack but I'm getting this error when I go to add my arduino:
View attachment 549360

I'm not actually able to choose anything on board type, it's filled in when I get to this page. On the previous page (Serial Controller Auto-detection, Step 3 - Identify controller), the type was listed is unknown. When I flashed the board, it showed the type listed as arduino uno.
View attachment 549368

For reference, this is a clean install of both raspbian and fermentrack. The arduino was already flashed with the brewpi firmware from my last brewpi install. Tried re-flashing, no change. I'm skeptical whether the re-flash actually worked since the arduino LCD is still displaying the same settings as before...

I got the same error but just switch to advance install in it worked.

 

[sctcts]

I just pushed out an update that should fix this issue.

Now that's what I call service, you had a new build up before I'd even gotten back to this after dinner! All up and running now, thanks for the quick fix.

Flashing the Arduino doesn't actually clear the EEPROM

Ahh I've worked with Arduinos enough that I should've known that, thanks for the info.

 

[Thorrak]

Now that's what I call service, you had a new build up before I'd even gotten back to this after dinner! All up and running now, thanks for the quick fix.

Thanks!

There's nothing I dislike more than bugs. If you find anything else that you have trouble with (or if anything is unclear) please let me know. Can't promise it will be addressed as quickly, but I'll try!

 

[sctcts]

I gotta say, installing Fermentrack is waaaaaaaaaay easier than the manual brewpi-www install I've done the last few times. I have three arduinos on one pi and have had to manually reinstall a couple times due to sd card corruption (yay for losing backups...). The last time I ran into a bunch of dependency errors trying to install on Raspbian Stretch, and it took some searching to figure out how to fix since Elco is no longer updating the legacy branch as far as I know.

Between the easy install and better UI, I'd 100% recommend anyone with an arduino brewpi use this instead of brewpi-www if they need to reinstall. Only problem is you're gonna cost me money because now I want to build/buy a gravity sensor... and I'll have to get one for each fermenter...

If you find anything else that you have trouble with (or if anything is unclear) please let me know. Can't promise it will be addressed as quickly, but I'll try!

I did run into some errors when renaming devices or renaming/deleting fermentation profiles. After trying to perform an action (rename, delete, etc.), I'd get kicked to an error page like this:

Traceback:

Spoiler: Traceback

Environment:


Request Method: POST
Request URL: http://192.168.1.216/devices/5/manage/

Django Version: 1.11.8
Python Version: 2.7.13
Installed Applications:
['django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'app.apps.AppConfig',
'firmware_flash.apps.AppConfig',
'gravity.apps.GravityAppConfig',
'constance',
'constance.backends.database',
'huey.contrib.djhuey']
Installed Middleware:
['django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware']



Traceback:

File "/home/fermentrack/venv/lib/python2.7/site-packages/django/core/handlers/exception.py" in inner
41. response = get_response(request)

File "/home/fermentrack/venv/lib/python2.7/site-packages/django/core/handlers/base.py" in _get_response
187. response = self.process_exception_by_middleware(e, request)

File "/home/fermentrack/venv/lib/python2.7/site-packages/django/core/handlers/base.py" in _get_response
185. response = wrapped_callback(request, *callback_args, **callback_kwargs)

File "/home/fermentrack/venv/lib/python2.7/site-packages/django/contrib/auth/decorators.py" in _wrapped_view
23. return view_func(request, *args, **kwargs)

File "/home/fermentrack/fermentrack/app/decorators.py" in _wrapped_view
27. return view_func(request, *args, **kwargs)

File "/home/fermentrack/fermentrack/app/views.py" in device_manage
614. active_device.restart_process()

File "/home/fermentrack/fermentrack/app/models.py" in restart_process
899. fc.restart(name=circus_device_name)

File "/home/fermentrack/fermentrack/lib/ftcircus/client.py" in restart
64. response = self._call("restart", name=name)

File "/home/fermentrack/fermentrack/lib/ftcircus/client.py" in _call
30. raise CircusException("Error: {}".format(res['reason']))

Exception Type: CircusException at /devices/5/manage/
Exception Value: Error: program dev-Lower Fermentor not found

The action always seemed to have worked when I navigated back, but there's definitely something going wrong.

 

[Thorrak]

I gotta say, installing Fermentrack is waaaaaaaaaay easier than the manual brewpi-www install I've done the last few times. I have three arduinos on one pi and have had to manually reinstall a couple times due to sd card corruption (yay for losing backups...). The last time I ran into a bunch of dependency errors trying to install on Raspbian Stretch, and it took some searching to figure out how to fix since Elco is no longer updating the legacy branch as far as I know.

Between the easy install and better UI, I'd 100% recommend anyone with an arduino brewpi use this instead of brewpi-www if they need to reinstall. Only problem is you're gonna cost me money because now I want to build/buy a gravity sensor... and I'll have to get one for each fermenter...

Glad you like it! That's interesting aboutthe dependency errors -- I know it was working relatively out-of-the-box as of Jesse, but I suppose something may have changed with Stretch. There's a lot of weirdness in the python/pip packages in Raspbian out of the box, apparently -- Just ask @Cougar281 about some of the issues he's encountered during install. One of the things I've been researching is how to improve the resiliency of the installation process given that it appears you can't assume a working copy of virtualenv/pip on every RPi. Hopefully that also prevents some of the dependency issues you've seen from afflicting Fermentrack.

I did run into some errors when renaming devices or renaming/deleting fermentation profiles. After trying to perform an action (rename, delete, etc.), I'd get kicked to an error page like this:

...

The action always seemed to have worked when I navigated back, but there's definitely something going wrong.

Thanks for the traceback - I think I see where the issue is and can take a stab at fixing it tonight. Given where the error is, while it will throw up an error on change, everything should work just fine after a minute or two. If it doesn't, it will definitely be resolved by restarting Fermentrack (or restarting the Pi if you prefer going down that route).

 

[sctcts]

That's interesting aboutthe dependency errors -- I know it was working relatively out-of-the-box as of Jesse, but I suppose something may have changed with Stretch

It definitely worked fine on Jessie, I had it running on that until the latest crash.

IIRC, the issues came up since Debian Strectch updated to php7, but all the old brewpi instructions call for php5. When I switched the commands to install php7, it didn't pull in some dependencies that brewpi was trying to use. Or something like that, I'm a bit of a linux noob to be honest.

 

[Cougar281]

I think something's broken with flashing again. I tried to flash another ESP device for my mock/test 'rig' and no matter what combination of setting or booting it with or without the 'flash' button pressed I tried (I know these devices I have don't like QIO mode, so one of the other methods should and did work), I would end up with the '504' message and probably about half the time or more, I would end up having to reboot the Pi to get the web interface working again. I flashed the firmware from CLI using these instructions (paths modified for Fermetrack and location of the firmware files of course) and it flashed 100% without issue once I corrected the memory size from the depreciated '-fs=32m' to '-fs=4MB'.

If it'll save anyone something, here is the command to flash from command line, with the proper path to esptool.py. the '/home/fermentrack/firmware' directory I created and placed the firmware files in.

python /home/fermentrack/venv/lib/python2.7/site-packages/esptool.py --port /dev/ttyUSB0 write_flash -fm=dio -fs=4MB 0x00000 /home/fermentrack/firmware/brewpi-esp8266.v0.9.wifi.bin

Oh, and it seems the Onewire bus isn't scanning for new devices. Once I got this device flashed, I tested this out - added one and powered it on, of course it was recognized. Added another and waited at least 5 minutes, nothing until I rebooted the ESP, and the third I added in and let sit overnight - Still no unassigned OneWire device there after a page refresh.

 

[pschnett]

Thorrak,

Thank you and your contributors for this great solution. I have my boards from BigDaddyale and waiting for my components from China. I wanted to suggest some features for using specific gravity. To follow faster Lager methods such as proposed by Marshall Schott at Brulosophy, which talks about changing the fermentation temperature at a percentage between original gravity and final gravity. This would involve copying a gravity profile and entering the OG and FG of the recipe. Instead of a step that uses time for holding a temperature, the profile step would move to the next based on achieving a percentage of difference between OG and FG.

 

[pschnett]

Thorrak,
As a follow on to my suggestion, I would be willing to help. I have been a developer for a while in C, C# and JavaScript but have no experience in Python. I can help with MD files and testing.

 

[Cougar281]

Theoretically, yes, but this isn’t currently supported and would require a lot of hacking outside of Fermentrack.

There might be a way to hack the iSpindel support (once that gets built) to do this - but someone would have to step up and code the missing pieces.

In looking around for options to log the Tilt, since it seems the TiltPi might be designed to be used with Google ONLY and doesn't have a WebUI on it (FAIL), I discovered this project. It looks like it's a simple python program that looks for Tilts and then forwards received Tilt data on to a specified server, I believe using JSON. How hard do you think it would be to add something to Fermentrack that listens for that data and posts it to where it belongs? Seems like that could potentially have more uses than just the tilt.

 

[pschnett]

In looking around for options to log the Tilt, since it seems the TiltPi might be designed to be used with Google ONLY and doesn't have a WebUI on it (FAIL), I discovered this project. It looks like it's a simple python program that looks for Tilts and then forwards received Tilt data on to a specified server, I believe using JSON. How hard do you think it would be to add something to Fermentrack that listens for that data and posts it to where it belongs? Seems like that could potentially have more uses than just the tilt.

I think that I saw Thorrak talk about sending this data to the Redis cache.

 

[pschnett]

Has anyone had any issues running with Raspbian Stretch?

 

[Cougar281]

Has anyone had any issues running with Raspbian Stretch?

Funny you should ask. If you recall Thorrak mentioning me and issues I've seen - here's what I found.

I tried installing Fermentrack on a RPi1B, RPi1B+, RPi2 and RPi Zero W, all using the exact same Raspbian Strech Lite image...

On a RPi1B, Fermentrack installed perfectly. At the end of the install, I have a perfectly functioning Fermentrack. Could access the web UI no problem.
On a RPi1B+, same thing.
On a RPi2, at the end of the setup, there was an error, saying a file wasn't present, I believe related to 'circus', and a NGINX error if I tried to browse to the web UI.
On the RPi Zero W, same as the RPi2.

All using the exact same image and steps to install Fermentrack. Figure that one out lol :scratchhead:.

 

[day_trippr]

Has anyone had any issues running with Raspbian Stretch?

[An OT PSA and only pertinent if one is interested in a digital tap list] Due to the deprecation of pHp Mysql 5 from the Stretch kit (replaced with version 7) RaspberryPints is non-functional with that Raspbian OS version...

Cheers!

 

[sctcts]

Has anyone had any issues running with Raspbian Stretch?

I just did a fresh install of Raspbian Stretch + Fermentrack on a RPi3 using the NOOBS image. Controlling a 3 chamber, serial-connected arduino setup. No problems apart from the error page I mentioned encountering a few posts back. The error page only popped up when changing settings, but the settings still got set appropriately.

On another note, I haven't had any display scrambling since updating to Fermentrack. Thorrak, did you implement a display reset on a set interval? Could just be a coincidence, I've only been running Fermentrack a few days but usually I'd have at least one scrambled display by now.

 

[stbernts]

On another note, I haven't had any display scrambling since updating to Fermentrack. Thorrak, did you implement a display reset on a set interval? Could just be a coincidence, I've only been running Fermentrack a few days but usually I'd have at least one scrambled display by now.

Same here, not one single scrambling observed since last update. This happend at least once a week on my displays (3 pcs)

 

[Bigdaddyale]

So, It looks like Jessie lite is the preferred image for RPI Zero?

 

[alexlark]

I'm running Jessie Lite on my Pi Zero.

If you are seeing no, or less, screen scramble it is because your chamber is mostly heating at this time of year instead of cooling due to ambient temperature. Mine is the same.

 

[Thorrak]

Same here, not one single scrambling observed since last update. This happend at least once a week on my displays (3 pcs)

I wish that I could claim that Fermentrack had anything to do with this, but unfortunately I think that @alexlark has the right of it - It's probably that you aren't tripping the compressor as often and therefore aren't seeing as much feedback to the screen.

 

[stbernts]

I'm running Jessie Lite on my Pi Zero.

If you are seeing no, or less, screen scramble it is because your chamber is mostly heating at this time of year instead of cooling due to ambient temperature. Mine is the same.

All my chambers are in a room with 19C steady temp all the year around.

 

[Cougar281]

I wish that I could claim that Fermentrack had anything to do with this, but unfortunately I think that @alexlark has the right of it - It's probably that you aren't tripping the compressor as often and therefore aren't seeing as much feedback to the screen.

Dumb question: What would cooling or the compressor have to do with the display? The compressor (I'd assume in all cases) is activated using a relay, and the ESP is (I'd assume) powered by an external power supply, so I'm not sure how the compressor could have any effect on the display.

Also, for grins, I did an install of Fermentrack on my RPi Zero W using Jesse, and that worked just fine - so whatever the issue is/was with the zero and the install (And I'd assume the Rpi2), it was something goofy with them and Stretch. That still has me scratching my head.

 

[day_trippr]

Dumb question: What would cooling or the compressor have to do with the display? The compressor (I'd assume in all cases) is activated using a relay, and the ESP is (I'd assume) powered by an external power supply, so I'm not sure how the compressor could have any effect on the display.[...]

The issue is the inductive "thump" on the AC in turn causes DC voltage sag to which the 20x4 display is notoriously sensitive...

Cheers!

 

[Cougar281]

The issue is the inductive "thump" on the AC in turn causes DC voltage sag to which the 20x4 display is notoriously sensitive...

Cheers!

But following that, wouldn't any similar load, such as your main fridge or maybe a chest freezer that happens to be on the same circuit (or maybe wouldn't have to be on the same circuit) have the same effect?

 

[day_trippr]

Lots of factors are in play: the compressor start-up draw, the AC wire gauge and length from the service panel, the hold-up capability of the power supply used, component variability of the display electronics, etc.

A distant load or one on a different branch will likely have no deleterious effect, but the fridge or freezer bring controlled by a device using the same AC circuit may whack the display every time in the pathological case...

Cheers!

 

[Mikmonken]

Bizarrely though the only two things that have stopped the scramble for me were.

Swapping the sainsmart relay for SSRs

And the other one was swapping the Arduino to and A Wemos Mini, coupled with the same Sainsmart relay that was scrambling the LCD.

Which makes me think it might be Arduino related, and not the relay as is first thought.

Don’t think I ever bought an original ardunio uno.

 

[Derp]

I'm fed up with my orphaned BrewBit controller. It's stuck on an old firmware version with a bug that causes the probes to read 999F if they drop below 32F, and I just froze 12 gallons of bitter. I've had all of the parts to build a BrewPi controller (RPis, SSRs, Arduino, etc.) so I'm ready to build it and chuck the BrewBit.

I use a Tilt, so I was happy to see that they are now supported. I was planning to use a Pi Zero W for the webserver, and I already have another Zero W that's running the TiltPi software that's reporting the temperature and gravity to brewstat.us.

1) Do I need two PZWs, or can a single Pi Zero W handle Fermentrack and the Tilt stuff?

2) If I only need one Pi, can I still upload the Tilt data to brewstat.us?

Thanks for any help you can offer!