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

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.
Yes - good that's the right one.

One thing pops to mind for the sensors. Do you have them on A0 and not A4?

A4 feeds I2C so if you attached the sensors to A4 and not A0 it would probably kill both.
 
Last edited:
interesting - it was in A4 - I Just tried swapping the jump lead from A4 to A0 but still no luck - would i need to change the anything in fermentrack and reflash?

the I2C for the LCD is currently fed from the SDA and SCL pins though and not the A4 if that makes a diference
 
Ok thanks to some advice here I managed to put my ESP in an enclosure with XLR mini. I'm happy with it.

Then I decided to push the update of Dec 29, 2019 and seems to work. The display is working everything seemed to be fine.

Today luckily before this weekend I decided to test the actual regulation. Logging on my webpage dashboard it is as if the Pi and the ESP8266 were not connected... I restarted the Pi, waited a little and restarted the ESP...

I'm a little bit clueless cause the debugging just point on DNS and I cannot see why..
Edit : restarting my routeur helped on DNS but still Controller Response Test failed...

.
IMG_20200118_152638.jpeg
Screenshot_20200121-173552__01.jpeg
Screenshot_20200121-173906__01.jpeg
 
Last edited:
Ok thanks to some advice here I managed to put my ESP in an enclosure with XLR mini. I'm happy with it.

Then I decided to push the update of Dec 29, 2019 and seems to work. The display is working everything seemed to be fine.

Today luckily before this weekend I decided to test the actual regulation. Logging on my webpage dashboard it is as if the Pi and the ESP8266 were not connected... I restarted the Pi, waited a little and restarted the ESP...

I'm a little bit clueless cause the debugging just point on DNS and I cannot see why..
Edit : restarting my routeur helped on DNS but still Controller Response Test failed...

.View attachment 663085View attachment 663087View attachment 663090

This is with the beta firmware?
 
interesting - it was in A4 - I Just tried swapping the jump lead from A4 to A0 but still no luck - would i need to change the anything in fermentrack and reflash?

the I2C for the LCD is currently fed from the SDA and SCL pins though and not the A4 if that makes a diference
For some reason I can't explain right now, A4 is SDA and A5 is SCL on typical Uno setups. That's why I moved the OneWire to A0.

As I said, I can't answer why there are an SDA and SCL marked on the board elsewhere, but this is how the typical libraries work.

As for why the sensors still do not show up, you might try an EEPROM erase and see if that helps.
 
As for why the sensors still do not show up, you might try an EEPROM erase and see if that helps.

This seemed to work! i had tried this before with no success but i guess that was due to the sensor pins being in the wrong place. Thanks for your help @LBussy

thanks @Bigdaddyale for the link to the sensor check too - i'll be saving that sketch for suture projects for sure!

the next challenge is that the LCD screen turns off about 10 seconds after the Arduino fired up (or is reset by reset button)

any ideas anyone?
 
the next challenge is that the LCD screen turns off about 10 seconds after the Arduino fired up (or is reset by reset button)
Is it really 10 seconds? There is a screen blanking feature, but I think it’s more like a minute. Is the controller still responding to the script at that point?
 
No or at least I didn't asked for ;) for whatever reason now...it works. It is really strange.
That’s good, at least!

There is a potential ~3 minute delay for the mDNS support to come up with the beta “v0.12” firmware, but that isn’t supposed to happen if the callbacks work, and should only take place if a disconnect occurs. If the controller connects immediately at startup, mDNS should work fine from the moment it connects to the network.

I’ll make a note to check that section of code out regardless before “official” release.
 
Is it really 10 seconds? There is a screen blanking feature, but I think it’s more like a minute. Is the controller still responding to the script at that point?

well it was doing a lot of on off cycles every 10 seconds or so but a restart seemed to fix that. Now it it just turning off after 1min as you stated.

Is there a reason it does this other than power saving and is there a way to turn it on again or change the idle time?
 
Is there a reason it does this other than power saving and is there a way to turn it on again or change the idle time?
Every 10 seconds suggests a crash in the script. Now that that’s gone, it’s just the normal timeout.

The timeout is to prevent the LCD from burning in. It will wake when you press the rotary encoder button. If you don’t have an encoder, you can jump a pin to disable it but I forget which offhand. I’ll find it when I get stationary and let you know.
 
well it was doing a lot of on off cycles every 10 seconds or so but a restart seemed to fix that. Now it it just turning off after 1min as you stated.

Is there a reason it does this other than power saving and is there a way to turn it on again or change the idle time?
Ground pin 7 and reset/restart. If you leave it grounded it will disable the LCD timeout.
 
Hi
Is there a parts list and setup guide for using a esp8266 as the WiFi controller? How do u add the temp probes?

I’m new and looking to build.
 
Yeah I had a reed of the fermentrack guide. Just looking to order parts. I have a spare esp 8266 mounted to a twin relay.
I think I need a screen and some temp probes.
 
This is more of a general RPi3 issue, but it is affecting my BrewPi controllers staying connected to Fermentrack. I have my Arduino based controllers connected via RPi internal bluetooth to HC-05 modules on the controllers. I notice that periodically, after days of normal connection, the controllers are no longer connected. When I manually try to connect in bluetooth settings, it fails. A full reboot fixes this, but it will happen again days later.

1. Are there any logs I can check on the pi to troubleshoot the connection issue? I am new to RPi's so I don't really know where to look.

2. I had an issue in the past with the home network dropping connection, causing the Pi to have issues reconnecting. I run it headless so I rely on constant connection. I found a simple script online that checks for connection every 5 minutes, and if it doesn't ping back, it automatically reboots the Pi. Does anyone know of something similar that could do the same if specific paired BT modules are no longer connected? Either a reboot, or maybe just restarting bluetooth services or something?
 
This is more of a general RPi3 issue, but it is affecting my BrewPi controllers staying connected to Fermentrack. I have my Arduino based controllers connected via RPi internal bluetooth to HC-05 modules on the controllers. I notice that periodically, after days of normal connection, the controllers are no longer connected. When I manually try to connect in bluetooth settings, it fails. A full reboot fixes this, but it will happen again days later.
I think this may align to something the Tilt folks noticed.

1. Are there any logs I can check on the pi to troubleshoot the connection issue? I am new to RPi's so I don't really know where to look.
Yes, either:
Code:
systemctl status bluetooth
('q' to exit)

Or to view the entire syslog for Bluetooth errors:
Code:
journalctl -u bluetooth
Errors related to sap-server or privacy may be ignored.

If this is the issue, it might be addressed in the Fermentrack setup along the lines of how I did it in BPR. If you want to do it manually, check your /usr/bin/btuart file and change the baud rate to something lower. I use 460800 for Pi 4 but you can go lower yet.
2. I had an issue in the past with the home network dropping connection, causing the Pi to have issues reconnecting. I run it headless so I rely on constant connection. I found a simple script online that checks for connection every 5 minutes, and if it doesn't ping back, it automatically reboots the Pi. Does anyone know of something similar that could do the same if specific paired BT modules are no longer connected? Either a reboot, or maybe just restarting bluetooth services or something?
Lowering the baud rate should eliminate those errors and remove that need.
 
Here's what I got from systemctl status bluetooth
Code:
bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset
   Active: active (running) since Wed 2020-02-05 10:04:13 EST; 24h ago
     Docs: man:bluetoothd(8)
 Main PID: 534 (bluetoothd)
   Status: "Running"
    Tasks: 1 (limit: 2200)
   Memory: 1.8M
   CGroup: /system.slice/bluetooth.service
           └─534 /usr/lib/bluetooth/bluetoothd

Feb 05 10:04:13 raspberrypi bluetoothd[534]: Starting SDP server
Feb 05 10:04:13 raspberrypi bluetoothd[534]: Bluetooth management interface 1.14
Feb 05 10:04:13 raspberrypi bluetoothd[534]: Sap driver initialization failed.
Feb 05 10:04:13 raspberrypi bluetoothd[534]: sap-server: Operation not permitted
Feb 05 10:04:13 raspberrypi bluetoothd[534]: Endpoint registered: sender=:1.13 p
Feb 05 10:04:13 raspberrypi bluetoothd[534]: Endpoint registered: sender=:1.13 p
Feb 05 10:04:13 raspberrypi bluetoothd[534]: Failed to set privacy: Rejected (0x
Feb 05 10:04:18 raspberrypi bluetoothd[534]: Endpoint registered: sender=:1.22 p
Feb 05 10:04:18 raspberrypi bluetoothd[534]: Endpoint registered: sender=:1.22 p
Feb 05 10:04:18 raspberrypi bluetoothd[534]: RFCOMM server failed for Headset Vo
lines 1-21/21 (END)...skipping...
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-02-05 10:04:13 EST; 24h ago
     Docs: man:bluetoothd(8)
 Main PID: 534 (bluetoothd)
   Status: "Running"
    Tasks: 1 (limit: 2200)
   Memory: 1.8M
   CGroup: /system.slice/bluetooth.service
           └─534 /usr/lib/bluetooth/bluetoothd

Feb 05 10:04:13 raspberrypi bluetoothd[534]: Starting SDP server
Feb 05 10:04:13 raspberrypi bluetoothd[534]: Bluetooth management interface 1.14 initialized
Feb 05 10:04:13 raspberrypi bluetoothd[534]: Sap driver initialization failed.
Feb 05 10:04:13 raspberrypi bluetoothd[534]: sap-server: Operation not permitted (1)
Feb 05 10:04:13 raspberrypi bluetoothd[534]: Endpoint registered: sender=:1.13 path=/org/bluez/hci0/A2DP/SBC/Sourc
Feb 05 10:04:13 raspberrypi bluetoothd[534]: Endpoint registered: sender=:1.13 path=/org/bluez/hci0/A2DP/SBC/Sourc
Feb 05 10:04:13 raspberrypi bluetoothd[534]: Failed to set privacy: Rejected (0x0b)
Feb 05 10:04:18 raspberrypi bluetoothd[534]: Endpoint registered: sender=:1.22 path=/MediaEndpoint/A2DPSource
Feb 05 10:04:18 raspberrypi bluetoothd[534]: Endpoint registered: sender=:1.22 path=/MediaEndpoint/A2DPSink
Feb 05 10:04:18 raspberrypi bluetoothd[534]: RFCOMM server failed for Headset Voice gateway: rfcomm_bind: Address
~

Currently the two controllers are disconnected again, but from what I can tell Bluetooth is still active.

Do you think I should lower the baud rate?
 
See if the following command allows them to reconnect:
Code:
sudo systemctl restart bluetooth
That will tell us if a script could reconnect the devices automatically.

Yes, you can try to lower the baud rate and see if it helps. Backup the file first. It's certainly worth a try. I'm not sure when the btuart file is parsed so a reboot is the surest way of making that change take effect.
 
I'll check on the sudo systemctl restart bluetooth later, I unplugged the controllers earlier and forgot to plug back in.

I checked the /usr/bin/btuart file to change the baud rate, and I see the following. I just want to make sure I'm reading it right.

Code:
#!/bin/sh

HCIATTACH=/usr/bin/hciattach
if grep -q "Pi 4" /proc/device-tree/model; then
  BDADDR=
else
  SERIAL=`cat /proc/device-tree/serial-number | cut -c9-`
  B1=`echo $SERIAL | cut -c3-4`
  B2=`echo $SERIAL | cut -c5-6`
  B3=`echo $SERIAL | cut -c7-8`
  BDADDR=`printf b8:27:eb:%02x:%02x:%02x $((0x$B1 ^ 0xaa)) $((0x$B2 ^ 0xaa)) $((0x$B3 ^ 0xaa))`
fi

uart0="`cat /proc/device-tree/aliases/uart0`"
serial1="`cat /proc/device-tree/aliases/serial1`"

if [ "$uart0" = "$serial1" ] ; then
        uart0_pins="`wc -c /proc/device-tree/soc/gpio@7e200000/uart0_pins/brcm\,pins | cut -f 1 -d ' '`"
        if [ "$uart0_pins" = "16" ] ; then
                $HCIATTACH /dev/serial1 bcm43xx 3000000 flow - $BDADDR
        else
                $HCIATTACH /dev/serial1 bcm43xx 921600 noflow - $BDADDR
        fi
else
        $HCIATTACH /dev/serial1 bcm43xx 460800 noflow - $BDADDR

I see three different baud rates here, so I don't know what to change. Sorry, I'm still terrible at understanding code. Trying to learn!
 
Last edited:
The easiest thing would be to change all of those numbers to 115200 and see if there's any effect. I'd have to dig to figure out which line applies, but it doesn't really matter.
 
Hey,

So I'm experiencing a problem getting the Tilt (Blue V2) to play nicely with Fermentrack on a Pi4. It was working perfectly on a previous beer that was fermenting. I then brewed a new beer dropped the Tilt in and noticed Fermentrack wasn't updating the gravity and temp (was still showing the value for the old beer - I'd end logging on that beer and created a new log).

I deleted the Tilt config (from the Django admin panel) - and recreated it multiple times - but Fermentrack won't pick it up.

The weird thing is that Tilt app on my Android phone picks up the tilt with no issue - from the exact same distance away from the fermenter that the Pi is.

I've restarted the bluetooth service multiple times - run multiple
Code:
sudo hcitool lescan
commands and I don't see the tilt at all there.

I came across the TiltRPi project and have run the command
Code:
sudo php TiltPythonFind.php
several times - it seems to occasionally pick up the tilt and report temp and gravities and other times not.

I've tried to look in the fermentrack logs for any errors relating to the tilt but haven't found anything - however the tilt log files don't seem to be named correctly: they are
Code:
tilt--stderr.log tilt--stderr.log
and are both blank.

Here's the current status of the BT service on the Pi

Code:
pi@raspberrypi:/home/fermentrack/fermentrack/log $ systemctl status bluetooth

● bluetooth.service - Bluetooth service

   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)

   Active: active (running) since Sat 2020-02-08 06:30:39 NZDT; 13min ago

    Docs: man:bluetoothd(8)

 Main PID: 7242 (bluetoothd)

   Status: "Running"

    Tasks: 1 (limit: 4035)

   Memory: 596.0K

   CGroup: /system.slice/bluetooth.service

          └─7242 /usr/lib/bluetooth/bluetoothd --noplugin=sap


Feb 08 06:30:39 raspberrypi systemd[1]: Starting Bluetooth service...

Feb 08 06:30:39 raspberrypi bluetoothd[7242]: Bluetooth daemon 5.50

Feb 08 06:30:39 raspberrypi systemd[1]: Started Bluetooth service.

Feb 08 06:30:39 raspberrypi bluetoothd[7242]: Starting SDP server

Feb 08 06:30:39 raspberrypi bluetoothd[7242]: Excluding (cli) sap

Feb 08 06:30:39 raspberrypi bluetoothd[7242]: Bluetooth management interface 1.14 initialized

Linux version:
Code:
pi@raspberrypi:/home/fermentrack/fermentrack/log $ uname -a

Linux raspberrypi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

Does anyone have any idea what is going on here - and how I can get the tilt to play nicely with the Pi and Fermentrack - I've spent a long while googling and have yet to come across anyone having similar issues.

Thanks!
 
I have a similar problem. Recently installed fermentrack on a 3B+ with a fresh install of Raspbian Stretch. I'm currently building a controller for my fermentor but figured I would toss my new Tilt (Green) in there. However, it does not seem be to recognized by fermentrack but is recognized by my phone. The fermentrack is sitting on top of my fermentation fridge, which is closer to the Tilt than my phone is for receiving the data.

All of my outputs are pretty much identical as above. I'm going to try doing a fresh install of Buster to see if that changes anything.
 
I have a similar problem. Recently installed fermentrack on a 3B+ with a fresh install of Raspbian Stretch. I'm currently building a controller for my fermentor but figured I would toss my new Tilt (Green) in there. However, it does not seem be to recognized by fermentrack but is recognized by my phone. The fermentrack is sitting on top of my fermentation fridge, which is closer to the Tilt than my phone is for receiving the data.

All of my outputs are pretty much identical as above. I'm going to try doing a fresh install of Buster to see if that changes anything.

I had the same issue on Stretch, and after a clean install of Buster, Fermentrack sees it right away. I had sort of confirmed it was the Pi having the issue, not Fermentrack, by testing with Tilt Pi installed. My Pi couldn't see it in that app either until the new install of Buster.
 
I had the same issue on Stretch, and after a clean install of Buster, Fermentrack sees it right away. I had sort of confirmed it was the Pi having the issue, not Fermentrack, by testing with Tilt Pi installed. My Pi couldn't see it in that app either until the new install of Buster.
Perfect, thanks for the quick feedback. I had some issues with getting Buster on when I first played around but I think it was a corrupt image.
 
I have a similar problem. Recently installed fermentrack on a 3B+ with a fresh install of Raspbian Stretch. I'm currently building a controller for my fermentor but figured I would toss my new Tilt (Green) in there. However, it does not seem be to recognized by fermentrack but is recognized by my phone. The fermentrack is sitting on top of my fermentation fridge, which is closer to the Tilt than my phone is for receiving the data.

All of my outputs are pretty much identical as above. I'm going to try doing a fresh install of Buster to see if that changes anything.

It's looking like this is a bug in the software - I've created a fixed for this and submitted the fix on Github for review.
 
Alright, upgraded and installed Buster on my 3B. Here are the results of the hcitool scan. Interesting enough I have to restart bluetooth on a reboot. I'm not sure which one is my tilt. I do know the 04:69:F8 is my Mac, which is a floor away from my Pi.
Code:
pi@raspberrypi:~ $ sudo hcitool lescan
LE Scan ...
7E:69:0D:B2:4D:04 (unknown)
7E:69:0D:B2:4D:04 (unknown)
E8:D8:40:FF:AB:4B N04KP
E8:D8:40:FF:AB:4B (unknown)
04:69:F8:B1:46:32 (unknown)
F9:83:3B:CA:2B:18 (unknown)

According to TiltPi the MAC address is:
Code:
pi@raspberrypi:/var/www/html/TiltRPi $ sudo php TiltPythonFind.php
MAC = f9:83:3b:ca:2b:18, SG = 1.039, Temp = 67

However, if I do the hcitool scan again I get an IO error. TiltPi also does not work, both only resolves itself with a bluetooth reboot. I'm wondering if something is wonky with the bluetooth config.
 
What is point of a tilt WiFi bridge if you have fermentrack on a raspberry pi next to the fermenter?
In this case, there isn't one (unless you like the display). TiltBridge is a niche project, after all! ;)

Here's one use case though. I have two fermentation chambers at home that are across the room from one-another. If I'm using two Tilts, it helps being able to bridge one to WiFi to prevent the signal from being intermittently spotty. If I had an actual house they'd likely be even further apart, which would reinforce the idea of using TiltBridge to help "bridge" the gap.

Separately - I'll let you in on a little secret which is another use case: My main Fermentrack box isn't a Raspberry Pi. ;) It's a VM running Ubuntu (which means it doesn't have a bluetooth adapter). TiltBridge means that it can still receive Tilt readings even without being able to pick them up directly.
 
I upgraded and deleted the Tilt from my setup. Readding it I actually have info in tilt--stderr.log:
Code:
cat tilt--stderr.log
ERROR:asyncio:Fatal write error on socket transport
protocol: <aioblescan.aioblescan.BLEScanRequester object at 0x74bf9470>
transport: <_SelectorSocketTransport fd=8 read=idle write=<idle, bufsize=0>>
Traceback (most recent call last):
File "/usr/lib/python3.7/asyncio/selector_events.py", line 857, in write
n = self._sock.send(data)
PermissionError: [Errno 1] Operation not permitted
ERROR:asyncio:Fatal write error on socket transport
protocol: <aioblescan.aioblescan.BLEScanRequester object at 0x74b865b0>
transport: <_SelectorSocketTransport fd=8 read=idle write=<idle, bufsize=0>>
Traceback (most recent call last):
File "/usr/lib/python3.7/asyncio/selector_events.py", line 857, in write
n = self._sock.send(data)
PermissionError: [Errno 1] Operation not permitted

Looks like a permission error of some sort.
 
I upgraded and deleted the Tilt from my setup. Readding it I actually have info in tilt-
Looks like a permission error of some sort.

Are you sure your HCI0 (or whatever it is on your pi) is actually up?

try the following commands:

Code:
sudo hciconfig hc0 down
sudo hciconfig hc0 up
 
Hi,

I will firs start to say that Fermentrack is amzing, keep up the great job^^

After your update on 12.02.2020 i have a issu on the dashboard for my temprature controller. The tempratue wan't show and the control mode is empty. I have just done a test run for 12 hours. If i go back to master it works just fine. What to do??

screenshot 14.02.2020.jpg
 
Hi,

I will firs start to say that Fermentrack is amzing, keep up the great job^^

After your update on 12.02.2020 i have a issu on the dashboard for my temprature controller. The tempratue wan't show and the control mode is empty. I have just done a test run for 12 hours. If i go back to master it works just fine. What to do??

I'm seeing the same too - I think the script is having a hard time reading those values from the controller - for some reason - doing my best to figure out why.

Edit:

Found, and fixed, the issue - and have put up a PR on GitHub.

Edit again:

Merged with Dev
 
Last edited:

Latest posts

Back
Top