I do, actually -- but only recently (and the case has only existed as of two weeks ago!)
I just uploaded the updated files to Printables and at some point I'll push a commit to GitHub with the update as well.
Fermentrack: Fermentation monitoring & BrewPi-www Replacement for Raspberry Pi
- Thread starter Thorrak
- Start date
Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:
I just uploaded the updated files to Printables and at some point I'll push a commit to GitHub with the update as well.
Why is this news to me? 
...Now I have to build one.
...Now I have to build one.
Derp
Well-Known Member
Thorrak,
Did you see the images I posted here?
https://www.homebrewtalk.com/thread...acement-for-raspberry-pi.649303/post-10261987
Any suggestions?
Did you see the images I posted here?
https://www.homebrewtalk.com/thread...acement-for-raspberry-pi.649303/post-10261987
Any suggestions?
I did, and I apologize as I thought I had replied, but apparently hallucinated that.
No - I don’t know offhand why that would happen. The same IDs used to populate the list of controllers (and LCD) on the main controller list are the IDs used to query/populate things such as the panels on the device dashboards. It’s possible that something weird is going on somewhere where I used an ID in a way I shouldn’t, but that seems very odd as it’s not something that I would think possible.
You did post a screenshot briefly that had an error about a device ID not being found — is that something you see often, or was it a one-off?
Derp
Well-Known Member
I do, but I deleted the screenshot because I assumed it was referring to the Tilt device I'd powered off after fermentation was complete, and didn't want to muddy the waters.
You shouldn’t see any error messages up at the top like that just because a device is turned off. Those error messages relate to some kind of internal error relating to Fermentrack itself.
My guess is that the error message & your issues are related. Can you check the following to help debug? Feel free to PM the screenshots to me if you prefer.
If you get error messages for any of the above, let me know. That is also helpful to debug
My guess is that the error message & your issues are related. Can you check the following to help debug? Feel free to PM the screenshots to me if you prefer.
- Log into Fermentrack, and click the "gear" in the upper right.
- Log in if necessary, and then click "Django Admin Panel"
- Under "App" you should see "BrewPi Devices". Click that.
- A list of your currently set up BrewPi devices should appear. Can you then post a screenshot of that list?
- Up at the top, under "Django Administration" click "Home" to go back to the main admin page, and then click on "Gravity Sensors" under "Gravity"
- You should see a list of your currently set up gravity devices. Can you take a screenshot of that list?
If you get error messages for any of the above, let me know. That is also helpful to debug
Derp
Well-Known Member
I saw the "Unable to load device with ID 1" error at the top at when I rebooted the Pi, but it's gone now. I also have the "Cannot receive LCD text from Controller/Script" message. I also see multiple instances of the following in syslog. Is this normal?
Jun 11 23:17:17 fermentrack kernel: [450477.788008] w1_master_driver w1_bus_master1: Attaching one wire slave 00.a32400000000 crc b7
Jun 11 23:17:17 fermentrack kernel: [450477.792915] w1_master_driver w1_bus_master1: Family 0 for 00.a32400000000.b7 is not registered.
Jun 11 23:17:53 fermentrack kernel: [450513.601414] w1_master_driver w1_bus_master1: Attaching one wire slave 00.632400000000 crc 7d
Jun 11 23:17:53 fermentrack kernel: [450513.606645] w1_master_driver w1_bus_master1: Family 0 for 00.632400000000.7d is not registered.
Jun 11 23:18:39 fermentrack kernel: [450559.675376] w1_master_driver w1_bus_master1: Attaching one wire slave 00.e32400000000 crc f1
Jun 11 23:18:39 fermentrack kernel: [450559.683633] w1_master_driver w1_bus_master1: Family 0 for 00.e32400000000.f1 is not registered.
Jun 11 23:19:27 fermentrack kernel: [450607.304825] w1_master_driver w1_bus_master1: Attaching one wire slave 00.132400000000 crc 85
Jun 11 23:19:27 fermentrack kernel: [450607.310168] w1_master_driver w1_bus_master1: Family 0 for 00.132400000000.85 is not registered.
Jun 11 23:20:13 fermentrack kernel: [450654.106537] w1_master_driver w1_bus_master1: Attaching one wire slave 00.932400000000 crc 09
Jun 11 23:20:13 fermentrack kernel: [450654.111807] w1_master_driver w1_bus_master1: Family 0 for 00.932400000000.09 is not registered.
I can search for other log events, if necessary.
Thanks for your help.
Last edited:
I have a Synology NAS and was wondering if Fermentrack could run on the Synology rather than a RaspberryPi.
Yes, but I don’t recommend it.
That said, I actually run my primary instance of Fermentrack in a Synology NAS, so take that with a grain of salt.
The issue you’re going to face is that support depends on which NAS you have
Ok thanks. I should probably stick to the Raspberry Pi as it is working well and quit messing with things.
The issue is just one of architecture. Newer Synology devices use modern (amd_x64) architecture. Older devices use i686 which is problematic, as upstream libraries have been dropping support (meaning that maintaining Fermentrack for it is incredibly painful). I currently try to target i686 builds when I can, but I can’t guarantee continued support, as Fermentrack is perpetually one dependency away from me just giving up on i686 entirely.
At home, I run my primary (brewing) instance on my NAS, my development instance on a server that I set up on one of those super tiny desktops you see in large offices, and a test instance on a RPi 4. I used to have a cluster of Pis that I used for building Python wheels for Fermentrack, but I have since switched to using virtualized builders on the same SFF server that I use for development builds.
For anyone who may run into this very niche scenario in the future.
I connected the power strip to a Kasa Wifi outlet. I just toggle the outlet power with the Kasa app and everything is back to normal. I'm sure any Wifi outlet would be fine too.
After staring at an unused Kasa for 6+ months the light bulb finally went off in my head.
We've got Kasa outlets running our "sprinkler" system right now. One minute of run time every morning, toggling a solenoid valve and a pump. Works great!
Amazon basically gives them away for free every year during Prime Day and Black Friday if you order through alexa or alexa app. They really do come in handy for all sorts of scenarios.
Last edited:
Just as a heads up, I've got some pretty major changes coming in the next release of Fermentrack that should hopefully resolve a number of bugs relating to BrewPi connection issues. If anyone is interested in seeing the change list before it's released, feel free to take a look at the PR on GitHub.
stbernts
Well-Known Member
- Joined
- May 20, 2016
- Messages
- 257
- Reaction score
- 43
Did an update last night, after reboot I am no longer able to connect to Fermentrack GUI. Pi is up, I can ping and login trogh SSH as normal.
URL states: 502 Bad Gateway
Any suggestions?
Re-run the install.sh script in the fermentrack-tools folder and let me know if you get any errors. If that doesn't work, then run
Code:
install.sh -i docker-dev...which will upgrade you to the development version that I'm currently working on. I don't recommend doing that unless the initial run of install.sh doesn't work as I'm still testing it, but it does contain some bug fixes.
stbernts
Well-Known Member
- Joined
- May 20, 2016
- Messages
- 257
- Reaction score
- 43
Got it up and running again with above tips (normal install.sh). Tried updating to Commit Date: June 18, 2023, 4:53 p.m. again, same failure as yesterday. Wil stay at current build as is.
Just 4 info to you Thorrak!
Last edited:
Thanks for letting me know!
I’m not sure if it is the issue you specifically are running into but one of the issues that the next upgrade seeks to address is removing the current, in-app upgrade workflow in favor of pointing people towards the install script. Although pulling from GitHub used to be the way to go, due either to changes in docker, issues with dependencies, or both, it seems to be causing more trouble than it’s worth these days.
Although it sucks that initiating an upgrade won’t be as easy as it used to be, if it becomes more reliable that’s the better choice in my opinion!
I’m not sure if it is the issue you specifically are running into but one of the issues that the next upgrade seeks to address is removing the current, in-app upgrade workflow in favor of pointing people towards the install script. Although pulling from GitHub used to be the way to go, due either to changes in docker, issues with dependencies, or both, it seems to be causing more trouble than it’s worth these days.
Although it sucks that initiating an upgrade won’t be as easy as it used to be, if it becomes more reliable that’s the better choice in my opinion!
stbernts
Well-Known Member
- Joined
- May 20, 2016
- Messages
- 257
- Reaction score
- 43
Would it be possible to force a "latest" from install.sh? If so, that route would be better, I guess. Or does it take lots of works on your part to prepare a new install with all the latest updates, each time you release fixes and such.
Must say, this has probably been one of the most reliable things I have ever used.
The way that Docker works is that you get a “box” (container) that contains a mini-virtual-machine that has the correct version of Python, required libraries, required dependencies, etc. already installed. The problem is that everything inside the container is trapped there, and can’t force an update to the container as a whole. The install.sh script, on the other hand, lives outside the container, and thus can.
The problem is that Docker has changed since I started using it, and where previously any changes made by Fermentrack to things “inside the box” would be persisted across reboots, now every time your Pi reboots the container gets reset to the state when you last ran install.sh. Your data is fine, because that is specifically persisted elsewhere — but the Fermentrack code gets reset to the previous version. As a result, all upgrades going forward must be triggered from outside the container to update the container as a whole.
Although in theory I could create daemons that would allow something inside the container to signal something outside the container to trigger the upgrade, I really don’t like the thought of something potentially messing up mid-brew and a user finding that their fermentation didn’t complete as expected.
stbernts
Well-Known Member
- Joined
- May 20, 2016
- Messages
- 257
- Reaction score
- 43
Agreed, seems like a lock-in situation. I never had any problems when it where outside docker, so I liked is at is where before the docker path aswell.
Anyway, the work you have done is amazing and realy apritiated
Major update - New release!
I've released the latest version of Fermentrack to GitHub and Docker Hub, which includes a number of upgrades/changes/fixes. This upgrade cannot be fully performed from the Fermentrack interface, and requires you to log into your Raspberry Pi (or other device) via SSH and run the following four commands:
Major Changes
BrewPi-Script Manager Rewrite
Since the early days of Fermentrack, [Circus](https://github.com/circus-tent/circus) has been used to launch & manage individual instances of brewpi-script for each individual BrewPi Device. Unfortunately, Circus imposes a number of upstream dependencies that make keeping Fermentrack up-to-date an extremely onerous task. This PR replaces Circus with a custom BrewPi-Script management daemon.
Backup/Restore Refactor
The original implementation of backup/restore relied on an internal Django management command to read the database and write out database object descriptions to a JSON file. Although this works in theory, in practice this means that the backup is fairly dumb given that it is not aware of the nuance of Fermentrack's object relationships.
This PR replaces the use of the internal Django management command with new logic that generates a "smart" backup, which includes a Fermentrack-generated (rather than database-driven) representation of Fermentrack objects in JSON.
*Changes from the previous logic when using newly-generated backups*
- Backup/restore no longer requires a fresh installation of Fermentrack for restoration to work
- Backup/restore will no longer restore user accounts
- Restoring controllers will no longer restart logging if they were logging when the backup was generated
- Restoring controllers will no longer trigger a temperature profile to be applied if one was applied when the backup was generated
UUIDs
As part of the backup/restore refactoring, I have added UUIDs to every object that is likely to be exported. These UUIDs allow Fermentrack to recognize when an object in a backup file already exists in the Fermentrack database, and will update that object (rather than attempting to install a second instance).
New Upgrade Workflow
Unfortunately, Docker resets containers to their "downloaded" state which means that the previous upgrade workflow no longer functions as intended. The ability to "upgrade from GitHub" has now been removed in favor of providing instructions on how to re-run the install script which pulls the latest image from Docker Hub.
TiltBridge Jr (New Tilt Bluetooth support)
The existing Tilt Bluetooth daemon has been removed in favor of a new, standalone bluetooth daemon called "TiltBridge Jr." This should hopefully allow for Tilt support to be upgraded/improved independently from Fermentrack while simultaneously providing a better experience.
Full Changelog (so far)
Added
Changed
Removed
I've released the latest version of Fermentrack to GitHub and Docker Hub, which includes a number of upgrades/changes/fixes. This upgrade cannot be fully performed from the Fermentrack interface, and requires you to log into your Raspberry Pi (or other device) via SSH and run the following four commands:
- cd fermentrack-tools
- git fetch
- git pull
- ./install.sh
Major Changes
BrewPi-Script Manager Rewrite
Since the early days of Fermentrack, [Circus](https://github.com/circus-tent/circus) has been used to launch & manage individual instances of brewpi-script for each individual BrewPi Device. Unfortunately, Circus imposes a number of upstream dependencies that make keeping Fermentrack up-to-date an extremely onerous task. This PR replaces Circus with a custom BrewPi-Script management daemon.
Backup/Restore Refactor
The original implementation of backup/restore relied on an internal Django management command to read the database and write out database object descriptions to a JSON file. Although this works in theory, in practice this means that the backup is fairly dumb given that it is not aware of the nuance of Fermentrack's object relationships.
This PR replaces the use of the internal Django management command with new logic that generates a "smart" backup, which includes a Fermentrack-generated (rather than database-driven) representation of Fermentrack objects in JSON.
*Changes from the previous logic when using newly-generated backups*
- Backup/restore no longer requires a fresh installation of Fermentrack for restoration to work
- Backup/restore will no longer restore user accounts
- Restoring controllers will no longer restart logging if they were logging when the backup was generated
- Restoring controllers will no longer trigger a temperature profile to be applied if one was applied when the backup was generated
UUIDs
As part of the backup/restore refactoring, I have added UUIDs to every object that is likely to be exported. These UUIDs allow Fermentrack to recognize when an object in a backup file already exists in the Fermentrack database, and will update that object (rather than attempting to install a second instance).
New Upgrade Workflow
Unfortunately, Docker resets containers to their "downloaded" state which means that the previous upgrade workflow no longer functions as intended. The ability to "upgrade from GitHub" has now been removed in favor of providing instructions on how to re-run the install script which pulls the latest image from Docker Hub.
TiltBridge Jr (New Tilt Bluetooth support)
The existing Tilt Bluetooth daemon has been removed in favor of a new, standalone bluetooth daemon called "TiltBridge Jr." This should hopefully allow for Tilt support to be upgraded/improved independently from Fermentrack while simultaneously providing a better experience.
Full Changelog (so far)
Added
- BrewPi-Script instances are now controlled via a custom process manager
- Officially added arm64v8 to supported platforms
- Added support for new versions of the BrewPi Firmware for certain ESP-based BrewPi Controllers
- Added support for extended settings on new BrewPi Firmware for certain ESP-based BrewPi Controllers
- Added board types for ESP32, ESP32-C3, and ESP32-S2
- Added examples for HTTPS support (Thanks @HuggableShark)
- Added UUIDs to most exportable objects to allow for easier import/export
- Added "TiltBridge Jr." (new Tilt bluetooth daemon) support
Changed
- Removed Circus support in favor of managing processes via Supervisord
- Removed libzmq requirement
- Removed environment tests for Tilt hydrometers (Obviated via Docker)
- Switch to use latest LTS version of Django
- Update to Python 3.9
- Changed most references to ESP8266 to reference ESP32 as appropriate
- Rewrote backup & restore functions to no longer rely on Django management code
- Changed restoration of legacy backups to explicitly utilize the staging folder
- Removed GitHub upgrade workflow from UI
Removed
- Removed Fermentrack-specific Bluetooth daemon - now handled by TiltBridge Jr.
I just pushed out a couple of bug fixes. Nothing major, but it should resolve issues with TiltBridges and get rid of erroneous “upgrade” messages on the dashboard.
ShaneB
Well-Known Member
I put together my brewpi-esp with a d32 pro and pcb from tindie. I can't figure out how to get my temp sensors working, I checked all my solder joints multiple times. The voltage on the esp32 board rj45 pinout was 0v but goes to about 1v when I plug in the ethernet cable to the sensor board. I testing the solder joints going directly to the temp sensor and one time it was 2.8 vs other times about 1v. I read "This PCB also includes user-selectable OneWire voltage, enabling a broad range of temperature sensors." How can I change the voltage between 3.3/5v? I didn't see an option in the software, do I need to use fermentrack? I'm just testing with the webserver on the esp32.
Thanks
Edit: oh! I see the OW select and 3.3v and 5v holes on the pcb. I'm assuming I need to solder pins and use a jumper for this? I couldn't find much documentation about the esp32 d32pro board.
Thanks
Edit: oh! I see the OW select and 3.3v and 5v holes on the pcb. I'm assuming I need to solder pins and use a jumper for this? I couldn't find much documentation about the esp32 d32pro board.
Yep! This.
There's two options - You can either solder bridge the specific voltage you want if you want to set it permanently (the square pads) or you can add a 3 pin male pin header and use a jumper to select the voltage.
Sorry about the lack of documentation -- I need to get a blog host up somewhere for things like builds.
ShaneB
Well-Known Member
Thanks for all your hard work, this all truly amazing to be open source. I managed to get the temp sensors working. I finally got everything hooked up and ready to test it out. So far I can't get my relays to switch on when testing in cooling mode. Will have to troubleshoot it tomorrow.
Edit: ahh so many little nuances, I was using a 5v relay board and the relay header supplies 3.3v, luckily there's a 5v pin nearby!
Last edited:
Derp
Well-Known Member
Did you ever have a chance to look at the screenshots you requested?
https://www.homebrewtalk.com/thread...acement-for-raspberry-pi.649303/post-10267044
My Fermentrack Pi was unreachable yesterday (seems to happen a lot), so I rebooted it. It came back up, and everything was working fine. I then installed the new update, and all was well. This morning I'm back to the same problem with no temperatures shown (although they're displaying correctly in the graph), "Unable to read LCD", and I also noticed the "Unable to load device with ID 1" error.
Any thoughts?
Been playing around more with my Synology DS416play NAS and trying to learn to use docker and other features. I may still try to run Fermentrack on it for fun unless you think this is a waste of time on this NAS. I guess I would use x386-64 image?
I have a lot of spare parts left over form controller builds such as ESP32-S2 and boards, LCD screen and connectors that I will organize and post pics. If anyone wants them I can mail them out.
| Intel Celeron N3060 | |
| CPU Architecture | 64-bit |
| CPU Frequency | Dual Core 1.6 burst up to 2.48 GHz |
I have a lot of spare parts left over form controller builds such as ESP32-S2 and boards, LCD screen and connectors that I will organize and post pics. If anyone wants them I can mail them out.
The fact that the Celeron N3060 is 64 bit means that it should actually work with Fermentrack. The way that I've been doing it is with their Virtual Machine Manager package hosting Ubuntu -- If you're a docker wizard, however, you may be able to get the compose stack running on their Docker package directly. If you decide to go down that route, let me know if it works!
No thoughts just yet, but this was actually part of the reason that I wanted to get the new backup/restore system up and running as I can now replicate your environment here on my side for testing. I'll shoot you a PM with instructions. We'll get this solved!
Derp
Well-Known Member
Thanks!
- Joined
- Aug 31, 2017
- Messages
- 120
- Reaction score
- 75
I ran the above commands, but the install failed due to lack of space. This is a recent (sometime this past spring) clean install, and I ran sudo apt-get clean, so I'm not sure what else there is to cleanup.
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 6.9G 5.9G 765M 89% /
devtmpfs 333M 0 333M 0% /dev
tmpfs 462M 0 462M 0% /dev/shm
tmpfs 185M 1.4M 184M 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
/dev/mmcblk0p1 255M 51M 205M 20% /boot
tmpfs 93M 20K 93M 1% /run/user/1000
This appears to only be an 8GB SD card, so perhaps I should just copy it to a larger one?
Try running
Code:
docker container prune
docker image pruneHopefully that will clean it up. If it doesn't, then you can try
Code:
docker image prune -a
Ugh. NVM, read that wrong...
Cheers!
Cheers!
- Joined
- Aug 31, 2017
- Messages
- 120
- Reaction score
- 75
Unfortunately, all three resulted in zero bytes reclaimed. I will pickup a larger SD card and try that.
If you want to take risks, you can
Code:
docker-compose down
Hi all,
Recently acquired a fridge and have a raspberry pi laying around gathering dust I’d like to put to use. I’m looking to have greater control of my fermentation but am getting stuck on a bill of materials I need to get started to really get into this. Can anyone point me in the direction of, or even have a list of items I need to acquire to get a controller set up?
Recently acquired a fridge and have a raspberry pi laying around gathering dust I’d like to put to use. I’m looking to have greater control of my fermentation but am getting stuck on a bill of materials I need to get started to really get into this. Can anyone point me in the direction of, or even have a list of items I need to acquire to get a controller set up?
I don't know if @Thorrak has a BOM anywhere. The documentation for Fermentrack is here.
First, you need to understand the difference between Fermentrack and the controller. Fermentrack is the UI you will access to set parameters on the controller. The Pi and the instructions are all you need for that part.
To control the fermentation temp, you need a controller. The venerable Arduino Uno is still supported and is probably the only choice if you do not want to solder. The ESP8266 or ESP32 is the easiest choice for a WiFi-based connection. Pretty sure John has some boards on Tindie (I don't have that address.) You can review the hardware choices further in the documentation.
You can also go to the GitHib repo for the ESP firmware and see some subjects surrounding the subject.
And welcome!
New Release
With the help of @RocketBrewer I was able to locate and squish a handful of bugs, most of which related to the ability of Fermentrack to remain connected to BrewPi devices. This update is recommended for all users.
To update, you will need to log into your Raspberry Pi (or other Fermentrack host), change to the fermentrack-tools directory, and run the install script. For most users who upgraded to the last release this can be accomplished with the following two commands:
Still need to upgrade to the June release?
Take a look at these instructions!
Happy Fourth, and happy brewing!
With the help of @RocketBrewer I was able to locate and squish a handful of bugs, most of which related to the ability of Fermentrack to remain connected to BrewPi devices. This update is recommended for all users.
To update, you will need to log into your Raspberry Pi (or other Fermentrack host), change to the fermentrack-tools directory, and run the install script. For most users who upgraded to the last release this can be accomplished with the following two commands:
Code:
cd fermentrack-tools
./install.shStill need to upgrade to the June release?
Take a look at these instructions!
Happy Fourth, and happy brewing!
