Fermentrack: Fermentation monitoring & BrewPi-www Replacement for Raspberry Pi

SSBrew - 728
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.
OK @Thorrak that seems way better - cheers!

I needed to remove and re-add my iSpindel but it looks to be pretty slick now!

There are separate lines for the numbers and the Celcius C but I can live with that as it doesn't readjust the entire screen as I track along the graph!

1608234859352.png
 
Noob Question: How much of the Fermentrack system/processes needs to remain running to work properly with a beer in progress? To elaborate...

I’m running the front-end on an old laptop sitting on the ferm chamber out in the garage, instead of on an RPi. I leave the browser running full time out there and just update the page anytime I want to check on it.

But what if I want to pull up a browser window on the PC in my office? And maybe change a setting from there? How does this impact the system running in the garage? I’m just not sure what should be left running on that garage system in order to control the front end on a different system’s browser. How should I be doing this?
Did that make sense?
 
It's the host that runs the show. Your visibility into the goings on doesn't affect dialog between host and controller. So as long as Fermentrack is still running whatever was set up will be executed...

fwiw, if Fermentrack follows the same paradigm as its BrewPi predecessor, a controller will maintain the last settings even if the host dies.
Having four units controlled by a single RPi here in the boonies where power isn't guaranteed, that's important to me :) The one implication with this is a "slope" will not happen with a dead host. Whatever the last temperature Set Point was issued will be maintained until the host comes back to life.

In any case, you can connect and change settings from wherever. I don't think there's anything to prevent that - just to prove it I pulled up one of my controllers on my desktop and laptop and changed settings from both. It just works.

Cheers!

[edited for clarity 'cuz I really messed up the first attempt ;)]
 
Last edited:
day_trippr said:
fwiw, if Fermentrack follows the same paradigm as its BrewPi predecessor, a controller will maintain the last settings even if the host dies.
Having four units controlled by a single RPi here in the boonies where power isn't guaranteed, that's important to me :)

The one implication with this is a "slope" will not happen with a dead host. Whatever the last temperature Set Point was issued will be maintained until the host comes back to life.

So unless you're running a Profile, there's no need to keep a connection open. I probably should have said that first ;)

In any case, you can connect and change settings from wherever. I don't think there's anything to prevent that - just to prove it I pulled up one of my controllers on my desktop and laptop and changed settings from both. It just works.

Cheers!
Click to expand...
Right. That temp profile scenario is one consideration I was wondering about.

Can I log off the browser in the garage? Or does that kill brewpi script and the profile that in effect?
 
Sorry about that - I totally botched my response (tried to fix it after you grabbed it).
In my defense I've been enjoying adult beverages ;)

You only need to keep whatever is actually running the Fermentrack host application going. Connecting into it with a browser or not doesn't change the execution, so you can connect and disconnect as desired to take a look or change whatever.

Cheers!
 
I've managed to get it all up and working over the weekend and sat it in a newly brewed beer last night.

Still receiving data although fermentation hasn't kicked off with anger yet!

Thanks again for sorting it so quickly!
 
Thorrak said:
What do you want to know (or do with it)?
Click to expand...

I have my own script running on RPI to gather tilt and one-wire readings. I'd like to post the tilt data "to" fermtrack so it can be displayed on the GUI. I'd also like to be able to "fetch" the one-wire sensor readings and all the other data (chilling, heating, temps, etc) that will now have a fermtrack one-wire sensor where i can't put two sensors (like thermowell in a fermenter). I currently log this data to influxDB and use grafana with other tools for alerting and data gathering.

The main reason I don't want to use Fermentrack to read the tilts is because it can't due to range... I use stainless fermenters inside a chest freezer and found that the only way to read them was to run an external usb-bluetooth dongle on the end of a long usb extension cord. I tried the tilt repeater and it worked so-so... and the commercially avail one only repeats only one color (i have two fermenters in each chamber). I instead wrote my own python script to read via bluetooth and announce results to influxDB similar to tilt-bridge. I also have 2 chest freezers, each with a usb-dongle style bluetooth hanging inside via a long usb extension cable. I don't think the rpi could handle the moisture inside the freezer... and i don't want it there anyway due to accasional blow-outs that require cleaning with a water hose. Putting a tilt bridge or RPI inside the freezer also causes problems with wifi reception.

Anyway, i'm sure some (probably not a lot) of people want to gather their sensor data themselves then post to various things... it would be nice to at least be able to do a "manual" gravity sensor and update fermtrack as well. Alternatively, since i'm now removing the one-wire from my old setup and using a brewpi wired one... I'd like to be able to grab that data again as well. I saw the docs are "todo" so i peaked at the github and found the django URLs to guide me in finding some data endpoints. I think i could probably view the source for the "manual entry" page and figure out how to post directly there but i suspect it'd just be easier to use a rest-endpoint since django is already in use.

I found these endpoints which provide me with data:
/api/gravity/ = dumps gravity readings, doesn't appear to have "post/put" endpoint
/api/lcd = displays what's on the LCD, unstructured data but does have sensor readings
/api/panel/1 = reading of sensors in structured json, i can pull one-wire readings here
/devices/1/backlight/toggle/ = doesn't appear to actually toggle backlight, would be useful for flashing if an alarm is present

Really just looking for an endpoint to post manual gravity readings and i'd be square.
 
postalbunny said:
I have my own script running on RPI to gather tilt and one-wire readings. I'd like to post the tilt data "to" fermtrack so it can be displayed on the GUI. I'd also like to be able to "fetch" the one-wire sensor readings and all the other data (chilling, heating, temps, etc) that will now have a fermtrack one-wire sensor where i can't put two sensors (like thermowell in a fermenter). I currently log this data to influxDB and use grafana with other tools for alerting and data gathering.

The main reason I don't want to use Fermentrack to read the tilts is because it can't due to range... I use stainless fermenters inside a chest freezer and found that the only way to read them was to run an external usb-bluetooth dongle on the end of a long usb extension cord. I tried the tilt repeater and it worked so-so... and the commercially avail one only repeats only one color (i have two fermenters in each chamber). I instead wrote my own python script to read via bluetooth and announce results to influxDB similar to tilt-bridge. I also have 2 chest freezers, each with a usb-dongle style bluetooth hanging inside via a long usb extension cable. I don't think the rpi could handle the moisture inside the freezer... and i don't want it there anyway due to accasional blow-outs that require cleaning with a water hose. Putting a tilt bridge or RPI inside the freezer also causes problems with wifi reception.

Anyway, i'm sure some (probably not a lot) of people want to gather their sensor data themselves then post to various things... it would be nice to at least be able to do a "manual" gravity sensor and update fermtrack as well. Alternatively, since i'm now removing the one-wire from my old setup and using a brewpi wired one... I'd like to be able to grab that data again as well. I saw the docs are "todo" so i peaked at the github and found the django URLs to guide me in finding some data endpoints. I think i could probably view the source for the "manual entry" page and figure out how to post directly there but i suspect it'd just be easier to use a rest-endpoint since django is already in use.

I found these endpoints which provide me with data:
/api/gravity/ = dumps gravity readings, doesn't appear to have "post/put" endpoint
/api/lcd = displays what's on the LCD, unstructured data but does have sensor readings
/api/panel/1 = reading of sensors in structured json, i can pull one-wire readings here
/devices/1/backlight/toggle/ = doesn't appear to actually toggle backlight, would be useful for flashing if an alarm is present

Really just looking for an endpoint to post manual gravity readings and i'd be square.
Click to expand...

That makes sense. Right now, there isn't an API endpoint for this, but I've got no objection to creating one. If you want to throw an issue up on GitHub so I don't forget, I'll try to get one added - though unfortunately it may be a bit.


To your comment about just pushing through the form handler, the code for processing posted manual endpoints is here: thorrak/fermentrack

The issue you will run into just posting the data is the CSRF protection - you'd have to get a token from the page prior to posting to make that work.
 
Thorrak said:
That makes sense. Right now, there isn't an API endpoint for this, but I've got no objection to creating one. If you want to throw an issue up on GitHub so I don't forget, I'll try to get one added - though unfortunately it may be a bit.


To your comment about just pushing through the form handler, the code for processing posted manual endpoints is here: thorrak/fermentrack

The issue you will run into just posting the data is the CSRF protection - you'd have to get a token from the page prior to posting to make that work.
Click to expand...

No problem.. created Create API endpoints for posting manual gravity data · Issue #557 · thorrak/fermentrack just for an endpoint to do manual gravity readings. I'll take a look at the CSRF tokens, haven't had to do that in the past but there is a first time for everything.
 
qq, what's the "Controller Response Test"? Everything seems to be working swimmingly but if I do a 'debug device connection' it fails at the Controller Response Test. I'm running the i2c arduino uno with an esp8266 bridging serial... so i'm curious if this test involves trying to reset the uno for programming, or if there is a response "version" coming back to fermentrack that it doesn't understand/recognize.
 
postalbunny said:
qq, what's the "Controller Response Test"? Everything seems to be working swimmingly but if I do a 'debug device connection' it fails at the Controller Response Test. I'm running the i2c arduino uno with an esp8266 bridging serial... so i'm curious if this test involves trying to reset the uno for programming, or if there is a response "version" coming back to fermentrack that it doesn't understand/recognize.
Click to expand...

Is your controller working? I wouldn't worry about errors in the debug workflow - those only matter if you can't connect.

The controller response test checks that a connection from Fermentrack can be made to the controller and that the controller responds with the standard BrewPi headers. There's a couple of "gotchas" in this as the model the controllers use only support a single connection at a time. If you were using the BrewPi-ESP8266 port then the controller would disconnect the second connection to accept the debug connection - I'm guessing that with your setup the bridging ESP just doesn't accept the second connection if it already has one established.

In short: You're (probably) good. Carry on. ;)
 
Found the issue... something with py3 and the changes to how ascii/encoding works and telnetlib. If I change the test_telnet() to specify "b" for ascii I get a Pass with the full reply. Otherwise the telnet.write() ends up tripping an exception and I get "None". I'm running this in a docker composed from ubuntu(latest, so 20.xx)... I'm not sure if I've violated the intended scenarios, or if I've found something that will be exposed when RPi ends up upgrading to buster w/py3, etc.

Code: 
def test_telnet(hostname, port):
    # This attempts to test the validity of a controller
    # It returns a tuple (probably not the best way to do this) which is in the format:
    # Initial Connection Test (bool), Version Response Test (bool), Version Response (str)
    try:
        tn = telnetlib.Telnet(host=hostname, port=port, timeout=3)
    except socket.timeout:
        return False, False, None
    except ConnectionRefusedError:
        return False, False, None

    try:
        tn.write(b"n\r\n")
        version_string = tn.read_until(b"}",3)
    except:
        return True, False, None
    return True, True, version_string
 
postalbunny said:
Found the issue... something with py3 and the changes to how ascii/encoding works and telnetlib. If I change the test_telnet() to specify "b" for ascii I get a Pass with the full reply. Otherwise the telnet.write() ends up tripping an exception and I get "None". I'm running this in a docker composed from ubuntu(latest, so 20.xx)... I'm not sure if I've violated the intended scenarios, or if I've found something that will be exposed when RPi ends up upgrading to buster w/py3, etc.

Code: 
def test_telnet(hostname, port):
    # This attempts to test the validity of a controller
    # It returns a tuple (probably not the best way to do this) which is in the format:
    # Initial Connection Test (bool), Version Response Test (bool), Version Response (str)
    try:
        tn = telnetlib.Telnet(host=hostname, port=port, timeout=3)
    except socket.timeout:
        return False, False, None
    except ConnectionRefusedError:
        return False, False, None

    try:
        tn.write(b"n\r\n")
        version_string = tn.read_until(b"}",3)
    except:
        return True, False, None
    return True, True, version_string
Click to expand...

WELP. That's a bug. Thank you for finding that.

The bugfix is committed on the docker branch and will be merged into dev when that gets added. Sorry about any confusion from that - I appreciate the fix!
 
Update

I've just pushed the changes I've been working on behind-the-scenes to support Docker into the dev branch. This update is a significant one, and carries with it quite a few changes. The changelog thus far is as follows:

Added
  • Added support for Docker installations
  • Added environment/container version number to GitHub page
  • Tilt "version" is now displayed on the Tilt Configuration page (Bluetooth only)
  • Tilt battery level now shows on the Tilt Configuration page (Bluetooth v3/Tilt Pro only)
  • "Last Check-in" time now added to Tilt configuration page (Bluetooth only)

Changed
  • Removed instances where BrewPi-Script would write to the database
  • Adjusted feedback loop for Circus to eliminate a potential race condition with transactional databases
  • Redesigned available firmware list to reduce confusion
  • Stale gravity check-in points will now not be displayed in the gravity dashboard panels
  • Added support for latest TiltBridge firmware


Fixed
  • Fermentrack now works with properly transactional databases (e.g. Postgres)
  • Resolved issue causing false failures of the connectivity test (Thanks postalbunny!)

Although this update allows for Docker-based installations, the default will remain non-docker until this gets merged into master. Given that it's late here and I have to work tomorrow, I'll post a note tomorrow on how the intrepid can install the containerized version of Fermentrack.
 
With the push of the docker support to dev, new installations can now be performed either using the containerized version of Fermentrack or the existing, non-containerized version. Due to the number of environmental issues solved through containerization, my goal is to nudge as many people as possible in the direction of using Docker, but I anticipate continuing to support both types of installation well into the future.

To install the existing, non-containerized Fermentrack simply use the existing installation method - that is, log into your pi and run curl -L install.fermentrack.com | sudo bash

For now - until this code is pushed to master - if you want to install the Dockerized version the command is slightly longer, but just as easy: curl -L https://raw.githubusercontent.com/thorrak/fermentrack-tools/docker/automated_install/auto-install.sh | bash

This script will:
  • Download the fermentrack-tools repo
  • Install docker
  • Install and set up Nginx
  • Download the necessary containers
  • Set up/install the docker-compose stack needed to run Fermentrack
Note for future readers - This new command is only temporary. As soon as this code is pushed from dev to master, I will update the fermentrack-tools repo as well, and installations run using curl -L install.fermentrack.com | bash will begin to default to docker-based installations.
 
garzlok said:
would you recommend us “non containered” users to consider moving towards the Docker version?
Click to expand...

Longer term, absolutely -- but there isn't yet a pathway to migrate to the Docker version and retain all your data. If you don't care about your data then switch when you can -- if you want to retain your past ferments, though, I'm working on a pathway to do so (though admittedly it may be 2H21 before that comes)
 
I've had my Fermentrack off for around a month while I moved houses interstate, set it all back up again and all works. Except that it no longer sends data to Brewfather, I have checked the address again, all seems right.
Has anyone had this issue?

TIA
 
Note for anyone out there using the Docker install -- I just pushed a few changes that change how Redis is installed. To install these changes you will need to re-run install.sh within the fermentrack-tools directory.

Previously, Redis was running bound on all interfaces with no password. This forces it to bind to the loopback interface only. This shouldn't be an issue for users that have a firewall turned on, but I know someone out there at some point will try to run Fermentrack in a DMZ and then wonder why their Pi suddenly is mining bitcoin...
 
I've found a couple relays burnt out despite lack of handling/use. Wondering if it's a bad batch/manufacturer or if its potentially expected that the relay goes out? Any recommendations for manufacturer?

I had gotten a couple sainsmarts but those have both blown, one on my own fidgeting and the other now randomly. The replacement generic chinesium brand seems to work great.


Tested all the logic and the voltages, it even showed the led lit as of it was working but no click and no working relay. Popped in a new one without even resetting the controller and good as new.
 
fwiw, all four of my BrewPi minions use the dual channel Sainsmart relay board, with the oldest now 6 years running, youngest 3 years. Zero failures to date.

I would check the manufacturer's plate on whatever is being driven to see what the start-up current might be...

Cheers!
 
Relays do burn out, but it seems that they follow the people and not the project. By that I mean I echo Dave's suspicion that your equipment exceeds the relays' reasonable capabilities.

You can always swap in an SSR rated higher.
 
Thanks - yea i run a 60w fermwrap then a small pump through the glycol. but seemingly the cool side always runs fine. not sure if a resistive heater really has a large 'startup'?

Edit 4 Disregard me I'm an idiot
 
Last edited:
Thorrak said:
For now - until this code is pushed to master - if you want to install the Dockerized version the command is slightly longer, but just as easy: curl -L https://raw.githubusercontent.com/thorrak/fermentrack-tools/docker/automated_install/auto-install.sh | bash
Click to expand...

Saw this post just as I wanted to get Fermentrack up and running and I thought great. I have an old Atom powered netbook that is running Lubuntu 18.04 and ran the above script. Things went well until I got this message:
Code: 
Pulling django (jdbeeler/fermentrack:latest)...
latest: Pulling from jdbeeler/fermentrack
ERROR: no matching manifest for linux/386 in the manifest list entries
Pulling django (jdbeeler/fermentrack:latest)...
latest: Pulling from jdbeeler/fermentrack
ERROR: no matching manifest for linux/386 in the manifest list entries
::: Waiting for Fermentrack install to initialize and become responsive.

Any ideas? I suspect one of the containers doesn't like i386 architecture....
Thanks
 
thestealth said:
Saw this post just as I wanted to get Fermentrack up and running and I thought great. I have an old Atom powered netbook that is running Lubuntu 18.04 and ran the above script. Things went well until I got this message:
Code: 
Pulling django (jdbeeler/fermentrack:latest)...
latest: Pulling from jdbeeler/fermentrack
ERROR: no matching manifest for linux/386 in the manifest list entries
Pulling django (jdbeeler/fermentrack:latest)...
latest: Pulling from jdbeeler/fermentrack
ERROR: no matching manifest for linux/386 in the manifest list entries
::: Waiting for Fermentrack install to initialize and become responsive.

Any ideas? I suspect one of the containers doesn't like i386 architecture....
Thanks
Click to expand...
Heh. I only had it compiling for x64 and armv7. Let me add an i386 target - give me a few.
 
thestealth said:
Saw this post just as I wanted to get Fermentrack up and running and I thought great. I have an old Atom powered netbook that is running Lubuntu 18.04 and ran the above script. Things went well until I got this message:
Code: 
Pulling django (jdbeeler/fermentrack:latest)...
latest: Pulling from jdbeeler/fermentrack
ERROR: no matching manifest for linux/386 in the manifest list entries
Pulling django (jdbeeler/fermentrack:latest)...
latest: Pulling from jdbeeler/fermentrack
ERROR: no matching manifest for linux/386 in the manifest list entries
::: Waiting for Fermentrack install to initialize and become responsive.

Any ideas? I suspect one of the containers doesn't like i386 architecture....
Thanks
Click to expand...

Done. The Fermentrack image now will be cross-compiled for i386 as well going forward.

I am pretty sure the other containers in the stack are compiled for i386 as well - if anything fails, let me know and I can see if I can determine why.
 
I've got a D32 Pro with TFT tiltbridge setup and working; I can see it's working by seeing the tilt values. It also is accessible via my network. However, I can't seem to get readings in my fermentrack dashboard. I've added the sensor via add gravity sensor> tilt hydrometer > add values (already added tiltbridge) > create sensor. It'll show the sensor in Fermentrack, but it's blank. I've tried to ensure all packages are installed, all updates are done, and reboots. I've ensured that the fermentrack can reach the tiltbridge by pinging it. It seems I have the same issue with my OLED variant now as well. Any suggestions on how to fix this?

*Edited*

Found this in the web application's logs via the help page. Maybe this helps shed some light.


0.0.0.0 - - [04/Jan/2021 20:46:02] "POST /tiltbridge/ HTTP/1.0" 500 124147
0.0.0.0 - - [04/Jan/2021 20:46:12] "GET /api/log/text/fermentrack/stderr/ HTTP/1.0" 200 7706
0.0.0.0 - - [04/Jan/2021 20:46:34] "GET /api/log/text/fermentrack/stderr/ HTTP/1.0" 200 7706
Internal Server Error: /tiltbridge/
Traceback (most recent call last):
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/core/handlers/exception.py", line 34, in inner
response = get_response(request)
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/core/handlers/base.py", line 115, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/core/handlers/base.py", line 113, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/home/fermentrack/venv/lib/python3.7/site-packages/sentry_sdk/integrations/django/views.py", line 67, in sentry_wrapped_callback
return callback(request, *args, **kwargs)
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
return view_func(*args, **kwargs)
File "/home/fermentrack/fermentrack/gravity/views_tilt.py", line 394, in tiltbridge_handler
raw_temp = int(tiltbridge_data['tilts'][this_tilt]['temp'])
ValueError: invalid literal for int() with base 10: '69.0'
ERROR:django.request:Internal Server Error: /tiltbridge/
Traceback (most recent call last):
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/core/handlers/exception.py", line 34, in inner
response = get_response(request)
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/core/handlers/base.py", line 115, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/core/handlers/base.py", line 113, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/home/fermentrack/venv/lib/python3.7/site-packages/sentry_sdk/integrations/django/views.py", line 67, in sentry_wrapped_callback
return callback(request, *args, **kwargs)
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
return view_func(*args, **kwargs)
File "/home/fermentrack/fermentrack/gravity/views_tilt.py", line 394, in tiltbridge_handler
raw_temp = int(tiltbridge_data['tilts'][this_tilt]['temp'])
ValueError: invalid literal for int() with base 10: '69.0'
 
Last edited:
Thorrak said:
Done. The Fermentrack image now will be cross-compiled for i386 as well going forward.

I am pretty sure the other containers in the stack are compiled for i386 as well - if anything fails, let me know and I can see if I can determine why.
Click to expand...

Seems to be working OK so far.

I will be getting a USB Bluetooth dongle to add to my netbook soon. Will I be able to get this to work with the Docker install to read my Tilt? Or will I need to build a TildBridge?
 
jlaframboise said:
I've got a D32 Pro with TFT tiltbridge setup and working; I can see it's working by seeing the tilt values. It also is accessible via my network. However, I can't seem to get readings in my fermentrack dashboard. I've added the sensor via add gravity sensor> tilt hydrometer > add values (already added tiltbridge) > create sensor. It'll show the sensor in Fermentrack, but it's blank. I've tried to ensure all packages are installed, all updates are done, and reboots. I've ensured that the fermentrack can reach the tiltbridge by pinging it. It seems I have the same issue with my OLED variant now as well. Any suggestions on how to fix this?

*Edited*

Found this in the web application's logs via the help page. Maybe this helps shed some light.


0.0.0.0 - - [04/Jan/2021 20:46:02] "POST /tiltbridge/ HTTP/1.0" 500 124147
0.0.0.0 - - [04/Jan/2021 20:46:12] "GET /api/log/text/fermentrack/stderr/ HTTP/1.0" 200 7706
0.0.0.0 - - [04/Jan/2021 20:46:34] "GET /api/log/text/fermentrack/stderr/ HTTP/1.0" 200 7706
Internal Server Error: /tiltbridge/
Traceback (most recent call last):
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/core/handlers/exception.py", line 34, in inner
response = get_response(request)
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/core/handlers/base.py", line 115, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/core/handlers/base.py", line 113, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/home/fermentrack/venv/lib/python3.7/site-packages/sentry_sdk/integrations/django/views.py", line 67, in sentry_wrapped_callback
return callback(request, *args, **kwargs)
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
return view_func(*args, **kwargs)
File "/home/fermentrack/fermentrack/gravity/views_tilt.py", line 394, in tiltbridge_handler
raw_temp = int(tiltbridge_data['tilts'][this_tilt]['temp'])
ValueError: invalid literal for int() with base 10: '69.0'
ERROR:django.request:Internal Server Error: /tiltbridge/
Traceback (most recent call last):
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/core/handlers/exception.py", line 34, in inner
response = get_response(request)
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/core/handlers/base.py", line 115, in _get_response
response = self.process_exception_by_middleware(e, request)
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/core/handlers/base.py", line 113, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/home/fermentrack/venv/lib/python3.7/site-packages/sentry_sdk/integrations/django/views.py", line 67, in sentry_wrapped_callback
return callback(request, *args, **kwargs)
File "/home/fermentrack/venv/lib/python3.7/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
return view_func(*args, **kwargs)
File "/home/fermentrack/fermentrack/gravity/views_tilt.py", line 394, in tiltbridge_handler
raw_temp = int(tiltbridge_data['tilts'][this_tilt]['temp'])
ValueError: invalid literal for int() with base 10: '69.0'
Click to expand...
Are you running the master or dev branch of Fermentrack? If dev, have you updated recently?

This was an issue with the upgrade to support the new Tilt Pros - it's currently fixed in the dev branch for sure.
 
thestealth said:
Seems to be working OK so far.

I will be getting a USB Bluetooth dongle to add to my netbook soon. Will I be able to get this to work with the Docker install to read my Tilt? Or will I need to build a TildBridge?
Click to expand...

It definitely works with the built-in Bluetooth adapters on the RPis, so I'm guessing it will work in your case as well.

Bluetooth support is a primary reason I ended up going the "net=host" route for the docker containers. I am not a fan of that approach, but it's the best option that was out there.
 
Sorry Noob Question. Running Fermentrack on Raspberry Pi 3 B+, running in the garage. I set the freq_list to only connect to 2.4ghz wifi, best available in the garage. I'm currently Reading a couple tilt hydrometers as I finish the build on some esp8266 controllers.

Fermentrack at 192.168.1.65 will work perfectly for about 24 hours or more and then when I pull it up to refresh and take a look I will get an error "site can't be reached" ? I can reboot to get it to come back, or I have tried and it works to clear the cache in chromium? Is there an issue or something I can set, to keep it always active or force the cache to clear, etc.

Looking to get the controllers completed in a month or so and want to make sure I have my wifi as stable and the fermentrack as stable as possible before I turn it loose on temp control. I had it set to 5ghz originally and the fall off issues was worse.

Appreciate any ideas.
 
Site can't be reached is not a Fermentrack thing. You might look at a WiFi repeater for that area or an external WiFi dongle with an antenna.

Sometimes a software solution can help. I've removed part of BrewPi Remix which is intended to help with this and made it available as a stand-alone daemon:

https://github.com/lbussy/rpi-wifi-checker
It might help, I guess it can;t get much worse :)
 
Thorrak said:
It definitely works with the built-in Bluetooth adapters on the RPis, so I'm guessing it will work in your case as well.

Bluetooth support is a primary reason I ended up going the "net=host" route for the docker containers. I am not a fan of that approach, but it's the best option that was out there.
Click to expand...

Got my Bluetooth adapter today and can read my Tilt without any problems.

However, I do seem to have a problem where I cannot access the user interface after rebooting. If I run docker-update.sh I can access it once a again. I suspect there is something not getting put into he startup programs or the crontab. Can you point me in the right direction on what I need to add so Fermetrack works after rebooting.
 
Last edited:
thestealth said:
Got my Bluetooth adapter today and can read my Tilt without any problems.

However, I do seem to have a problem where I cannot access the user interface after rebooting. If I run docker-update.sh I can access it once a again. I suspect there is something not getting put into he startup programs or the crontab. Can you point me in the right direction on what I need to add so Fermetrack works after rebooting.
Click to expand...

That's strange. The restart policy of the containers is "unless-stopped" which should work.

How did you install Docker itself? It sounds like there's a bug with certain installation types where Docker shutting down gracefully and stopping the containers makes it think that the shutdown was a user-requested stop.
 

Similar threads

duncan.brown
Brewery Dashboard
Replies
18
Views
2K
suprchunk
suprchunk
T
Homebrew interface built in Qt for Raspberry Pi
Replies
9
Views
3K
nordork
N
M
Replacement firmware for iSpindel (GravityMon)
10 11 12
Replies
450
Views
29K
dtashmore547
D
LBussy
BrewPi Remix – What’s Old is New Again
22 23 24
Replies
925
Views
61K
LBussy
LBussy
S
My fermentrack/brewpi-esp8266 Build
Replies
24
Views
5K
bcowmoo
bcowmoo

Latest posts

Back
Top