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

[trav77]

Hi guys

I recently put together this arduino based brewpi hardware setup from the thread:
https://www.homebrewtalk.com/forum/...wpi-fermentation-controller-for-cheap.466106/

Here's the schematic:

Now that I've come across this thread and realized it will integrate my tilt hydrometer, I'd like to give fermentrack a shot. I noticed arduino is supported... will this hardware setup work with fermentrack? I'm running Jessie on the rpi but can always change to a different OS if necessary. Other than that, haven't done anything yet on the software end.

Thanks!

 

[Thorrak]

Hi guys

I recently put together this arduino based brewpi hardware setup from the thread:
https://www.homebrewtalk.com/forum/...wpi-fermentation-controller-for-cheap.466106/

Here's the schematic:

Now that I've come across this thread and realized it will integrate my tilt hydrometer, I'd like to give fermentrack a shot. I noticed arduino is supported... will this hardware setup work with fermentrack? I'm running Jessie on the rpi but can always change to a different OS if necessary. Other than that, haven't done anything yet on the software end.

Thanks!

Yep - should be supported out of the box. Jessie or Stretch should work just fine.

 

[trav77]

Yep - should be supported out of the box. Jessie or Stretch should work just fine.

Awesome. Thanks so much for all the work you and others have put into these projects.

 

[Nikodemos]

I guess it's my turn to post a couple issues.

First issue: I've been trying to add a second fermentation chamber. Got everything built and wired up, just need to get the ESP866 ready to go. I've flashed, reflashed with the wifi reset, and back to Brewpi with Wifi, but the 8266 will not setup it's own AP. So I can't get the 8266 connected to my home wifi.

Second: After I upgraded Fermentrack to the latest version, it's no longer connecting to my original ESP8266. At least not well anyway. It'll start with this:

But then it all goes to blanks and "Cannot receive LCD text from controller"

The log before it starts repeating:

return codecs.charmap_decode(input,errors,decoding_table)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2591' in position 45: ordinal not in range(128)

Mar 23 2018 22:49:45 Error: controller is not responding to new data requests. Exiting.
Mar 23 2018 22:49:51 Connection type WiFi selected. Trying TCP serial (WiFi)
Mar 23 2018 22:49:51 Connecting to BrewPi esp10465863.local (via 192.168.86.75) on port 23
Mar 23 2018 22:49:57 Successfully connected to controller.
Mar 23 2018 22:49:57 Notification: Script started for beer 'Bohemian Rhapsody'
Mar 23 2018 22:50:08 Checking software version on controller...
Mar 23 2018 22:50:08 Found BrewPi v0.2.4, running commit 00000000, running on an ESP 8266 on port 192.168.86.75:23

Mar 23 2018 22:50:08 BrewPi version received was 0.2.4 which this script supports in 'legacy' branch mode.
Mar 23 2018 22:50:08 Bound to TCP socket on port 2967, interface localhost
Mar 23 2018 22:50:09 Installed devices received: [{"a": "28FFD2AFB117050C", "c": 1, "b": 1, "d": 0, "f": 9, "i": 0, "h": 2, "j": 0.0, "p": 12, "t": 1, "v": 49.998}, {"a": "28FFA9E2B1170432", "c": 1, "b": 0, "d": 0, "f": 5, "i": 1, "h": 2, "j": 0.0, "p": 12, "t": 1, "v": 53.486}, {"c": 1, "b": 0, "d": 0, "f": 2, "i": 2, "h": 1, "p": 16, "t": 3, "v": 0, "x": 1}, {"c": 1, "b": 0, "d": 0, "f": 3, "i": 3, "h": 1, "p": 14, "t": 3, "v": 0, "x": 1}]
Mar 23 2018 22:50:10 Available devices received: [{"c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 1, "p": 13, "t": 0, "x": 1}]
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
File "/home/fermentrack/fermentrack/brewpi-script/scriptlibs/backgroundserial.py", line 117, in __listenThread
self.buffer = self.buffer + new_data.decode(encoding="cp437")
File "/home/fermentrack/venv/lib/python2.7/encodings/cp437.py", line 15, in decode

 

[Thorrak]

I guess it's my turn to post a couple issues.

First issue: I've been trying to add a second fermentation chamber. Got everything built and wired up, just need to get the ESP866 ready to go. I've flashed, reflashed with the wifi reset, and back to Brewpi with Wifi, but the 8266 will not setup it's own AP. So I can't get the 8266 connected to my home wifi.

Second: After I upgraded Fermentrack to the latest version, it's no longer connecting to my original ESP8266. At least not well anyway. It'll start with this:

View attachment 563393

But then it all goes to blanks and "Cannot receive LCD text from controller"

The log before it starts repeating:

I will take a look later to see if I can get that fixed - it appears to be a Python 2 issue.

Run the update script to Python 3, and things should work for the second issue.

For the first issue, that’s weird. You should be able to run the WiFi reset script, have it delete the settings, and then get it connected after it pops up in AP mode — but you’ve done that and it didn’t work. So... yeah. I don’t know. I would say try another ESP8266 if you have one, but that’s the only idea I have at the moment.

 

[Nikodemos]

I will take a look later to see if I can get that fixed - it appears to be a Python 2 issue.

Run the update script to Python 3, and things should work for the second issue.

Done. Works. Thanks.

For the first issue, that’s weird. You should be able to run the WiFi reset script, have it delete the settings, and then get it connected after it pops up in AP mode — but you’ve done that and it didn’t work. So... yeah. I don’t know. I would say try another ESP8266 if you have one, but that’s the only idea I have at the moment.

Unfortunately, I figured a bad ESP8266 was probably the culprit, so I already got another one. I can't get either one to broadcast WiFi. I might try to play more tomorrow but I'm mostly out of ideas.

 

[Thorrak]

Unfortunately, I figured a bad ESP8266 was probably the culprit, so I already got another one. I can't get either one to broadcast WiFi. I might try to play more tomorrow but I'm mostly out of ideas.

Ever had something that you've told people forever, and then finally realized way after the fact just wasn't true? Things like "The WiFi reset firmware both tests your build and resets the WiFi/EEPROM on your device"?

Yeeeahhh. About that. Apparently I was wrong. I'm really sorry about that. The Wiring Test firmware didn't have the WiFi reset code in it, but it does now.

To flash this, from within Fermentrack, click the "Refresh Firmware List from Fermentrack.com" button on the flash page, and it should give you the option of flashing revision 0.2 of the firmware.

 

[Nikodemos]

Ever had something that you've told people forever, and then finally realized way after the fact just wasn't true? Things like "The WiFi reset firmware both tests your build and resets the WiFi/EEPROM on your device"?

Yeeeahhh. About that. Apparently I was wrong. I'm really sorry about that. The Wiring Test firmware didn't have the WiFi reset code in it, but it does now.

To flash this, from within Fermentrack, click the "Refresh Firmware List from Fermentrack.com" button on the flash page, and it should give you the option of flashing revision 0.2 of the firmware.

Hahaha. In other news, I now have PlatformIO and can load code onto the 8266 that way (I was trying to figure out if there was a way to preset the wifi configuration...never got there).

But updating the firmware list appears to have completely removed the wifi reset from Fermentrack?

 

[Thorrak]

Hahaha. In other news, I now have PlatformIO and can load code onto the 8266 that way (I was trying to figure out if there was a way to preset the wifi configuration...never got there).

But updating the firmware list appears to have completely removed the wifi reset from Fermentrack?

Sorry - there was a firmware validity test that I forgot to reset which caused the firmware to tag as being in error. It's fixed now.

There is definitely a way to preset the WiFi configuration if you're so inclined, though it would require a custom flash of the firmware. You would just need to add a call to WiFi.begin() with all the arguments provided in place of the code that triggers the captive portal.

Not recommended to do that, though, if you can avoid it

 

[Nikodemos]

Sorry - there was a firmware validity test that I forgot to reset which caused the firmware to tag as being in error. It's fixed now.

There is definitely a way to preset the WiFi configuration if you're so inclined, though it would require a custom flash of the firmware. You would just need to add a call to WiFi.begin() with all the arguments provided in place of the code that triggers the captive portal.

Not recommended to do that, though, if you can avoid it

Welp. I give up. Best I can tell I've either killed both ESP8266's or they both got to me dead... Wrote a program where all it did was connect to wifi and it just sits around printing out periods waiting to connect. I've got two more on the way now...

 

[Bigdaddyale]

Welp. I give up. Best I can tell I've either killed both ESP8266's or they both got to me dead... Wrote a program where all it did was connect to wifi and it just sits around printing out periods waiting to connect. I've got two more on the way now...

Try wiping your ESP8266 following the instructions from post-https://www.homebrewtalk.com/forum/threads/brewpi-esp8266-no-need-of-rpi-and-arduino.587425/page-14#post-8138321

 

[leftcontact]

Is there a sticky somewhere of what hardware you would need to do this if starting from scratch? Micro Center down the street is selling Raspberry Pi zero W's (builtin wireless & BT4.0) for 6$; would that work for this?

 

[Thorrak]

Raspberry Pi 3 B+ Note

Is there a sticky somewhere of what hardware you would need to do this if starting from scratch? Micro Center down the street is selling Raspberry Pi zero W's (builtin wireless & BT4.0) for 6$; would that work for this?

Yep!

For the ESP8266 build, you'll probably want to choose a PCB from this list and then pick up the associated bill of materials. PM me if that list is confusing at all, I'm working on a different project on the side to help demystify it but that's ~2 months away at the moment.

For the Fermentrack build, you'll need a Raspberry Pi (Zero W works!) & the associated stuff to make it work (USB power supply, SD card, etc.). Thats about it.

 

[CadiBrewer]

Now that everything is working again with the pip upgrades, etc. my Tilt isn't showing up in Fermentrack. I can see it on my phone from the Tilt app, so I know it is working.

Here's the error log entry I'm getting:

Traceback (most recent call last):
File "/home/fermentrack/fermentrack/gravity/tilt/tilt_monitor.py", line 22, in <module>
import TiltHydrometerFermentrack
File "/home/fermentrack/fermentrack/gravity/tilt/TiltHydrometerFermentrack.py", line 8, in <module>
from TiltHydrometer import *
File "/home/fermentrack/fermentrack/gravity/tilt/TiltHydrometer.py", line 16, in <module>
import blescan
File "/home/fermentrack/fermentrack/gravity/tilt/blescan.py", line 25, in <module>
import bluetooth._bluetooth as bluez
ImportError: No module named 'bluetooth'

The other log has this in it:

ERROR: Accessing bluetooth device whilst scanning: TiltConfiguration matching query does not exist.
Resetting Bluetooth device

 

[Thorrak]

Now that everything is working again with the pip upgrades, etc. my Tilt isn't showing up in Fermentrack. I can see it on my phone from the Tilt app, so I know it is working.

Here's the error log entry I'm getting:

Traceback (most recent call last):
File "/home/fermentrack/fermentrack/gravity/tilt/tilt_monitor.py", line 22, in <module>
import TiltHydrometerFermentrack
File "/home/fermentrack/fermentrack/gravity/tilt/TiltHydrometerFermentrack.py", line 8, in <module>
from TiltHydrometer import *
File "/home/fermentrack/fermentrack/gravity/tilt/TiltHydrometer.py", line 16, in <module>
import blescan
File "/home/fermentrack/fermentrack/gravity/tilt/blescan.py", line 25, in <module>
import bluetooth._bluetooth as bluez
ImportError: No module named 'bluetooth'

The other log has this in it:

ERROR: Accessing bluetooth device whilst scanning: TiltConfiguration matching query does not exist.
Resetting Bluetooth device

I see the issue. Again, python 3 thing. Working on figuring out a fix now. Stay tuned.

 

[CadiBrewer]

Thanks! I'm mashing in right now, so it will be cool if i can have the Tilt tracking from the time i pitch to when i keg. This is my first Tilt batch.

 

[Thorrak]

Thanks! I'm mashing in right now, so it will be cool if i can have the Tilt tracking from the time i pitch to when i keg. This is my first Tilt batch.

Oof, tight deadline!

That said, the fix is deployed - but will require manual intervention. You have two choices. You can either log into your pi via ssh and run

sudo apt-get install libbluetooth3

...and then update Fermentrack from GitHub, or you can just re-run the Python 3 upgrade script. Either will work.

If you happened to update from GitHub prior to installing libbluetooth3 you may need to restart circus (or just restart the Raspberry Pi) before it will work.

 

[CadiBrewer]

@Thorrak, thanks for jumping on this, but do it at your leisure, not at my deadline. New errors this time after running the above steps. Also, sudo apt-get install libbluetooth3 command result was that I already had it installed, so no packages installed or updated.

Unhandled exception in thread started by <bound method TiltHydrometerManager.scan of <TiltHydrometerFermentrack.TiltHydrometerManagerFermentrack object at 0x738b3f30>>
Traceback (most recent call last):
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 484, in connect
sock = self._connect()
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 541, in _connect
raise err
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 529, in _connect
sock.connect(socket_address)
ConnectionRefusedError: [Errno 111] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/client.py", line 667, in execute_command
connection.send_command(*args)
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 610, in send_command
self.send_packed_command(self.pack_command(*args))
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 585, in send_packed_command
self.connect()
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 489, in connect
raise ConnectionError(self._error_message(e))
redis.exceptions.ConnectionError: Error 111 connecting to 127.0.0.1:6379. Connection refused.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 484, in connect
sock = self._connect()
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 541, in _connect
raise err
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 529, in _connect
sock.connect(socket_address)
ConnectionRefusedError: [Errno 111] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/fermentrack/fermentrack/gravity/tilt/TiltHydrometer.py", line 406, in scan
reloaded = self.reloadSettings()
File "/home/fermentrack/fermentrack/gravity/tilt/TiltHydrometerFermentrack.py", line 119, in reloadSettings
if self.obj.check_redis_reload_flag():
File "/home/fermentrack/fermentrack/gravity/models.py", line 652, in check_redis_reload_flag
reload_flag = r.get('tilt_reload_{}'.format(self.color))
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/client.py", line 976, in get
return self.execute_command('GET', name)
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/client.py", line 673, in execute_command
connection.send_command(*args)
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 610, in send_command
self.send_packed_command(self.pack_command(*args))
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 585, in send_packed_command
self.connect()
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 489, in connect
raise ConnectionError(self._error_message(e))
redis.exceptions.ConnectionError: Error 111 connecting to 127.0.0.1:6379. Connection refused.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/fermentrack/fermentrack/gravity/tilt/TiltHydrometer.py", line 410, in scan
print("ERROR: Accessing bluetooth device whilst scanning: " + e.message)
AttributeError: 'ConnectionError' object has no attribute 'message'
Unhandled exception in thread started by <bound method TiltHydrometerManager.scan of <TiltHydrometerFermentrack.TiltHydrometerManagerFermentrack object at 0x73996ff0>>
Traceback (most recent call last):
File "/home/fermentrack/fermentrack/gravity/tilt/TiltHydrometer.py", line 399, in scan
blescan.hci_enable_le_scan(sock)
File "/home/fermentrack/fermentrack/gravity/tilt/blescan.py", line 74, in hci_enable_le_scan
hci_toggle_le_scan(sock, 0x01)
File "/home/fermentrack/fermentrack/gravity/tilt/blescan.py", line 83, in hci_toggle_le_scan
bluez.hci_send_cmd(sock, OGF_LE_CTL, OCF_LE_SET_SCAN_ENABLE, cmd_pkt)
_bluetooth.error: (100, 'Network is down')

 

[Thorrak]

@Thorrak, thanks for jumping on this, but do it at your leisure, not at my deadline. New errors this time after running the above steps. Also, sudo apt-get install libbluetooth3 command result was that I already had it installed, so no packages installed or updated.

Unhandled exception in thread started by <bound method TiltHydrometerManager.scan of <TiltHydrometerFermentrack.TiltHydrometerManagerFermentrack object at 0x738b3f30>>
Traceback (most recent call last):
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 484, in connect
sock = self._connect()
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 541, in _connect
raise err
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 529, in _connect
sock.connect(socket_address)
ConnectionRefusedError: [Errno 111] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/client.py", line 667, in execute_command
connection.send_command(*args)
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 610, in send_command
self.send_packed_command(self.pack_command(*args))
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 585, in send_packed_command
self.connect()
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 489, in connect
raise ConnectionError(self._error_message(e))
redis.exceptions.ConnectionError: Error 111 connecting to 127.0.0.1:6379. Connection refused.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 484, in connect
sock = self._connect()
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 541, in _connect
raise err
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 529, in _connect
sock.connect(socket_address)
ConnectionRefusedError: [Errno 111] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/fermentrack/fermentrack/gravity/tilt/TiltHydrometer.py", line 406, in scan
reloaded = self.reloadSettings()
File "/home/fermentrack/fermentrack/gravity/tilt/TiltHydrometerFermentrack.py", line 119, in reloadSettings
if self.obj.check_redis_reload_flag():
File "/home/fermentrack/fermentrack/gravity/models.py", line 652, in check_redis_reload_flag
reload_flag = r.get('tilt_reload_{}'.format(self.color))
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/client.py", line 976, in get
return self.execute_command('GET', name)
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/client.py", line 673, in execute_command
connection.send_command(*args)
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 610, in send_command
self.send_packed_command(self.pack_command(*args))
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 585, in send_packed_command
self.connect()
File "/home/fermentrack/venv/lib/python3.5/site-packages/redis/connection.py", line 489, in connect
raise ConnectionError(self._error_message(e))
redis.exceptions.ConnectionError: Error 111 connecting to 127.0.0.1:6379. Connection refused.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/fermentrack/fermentrack/gravity/tilt/TiltHydrometer.py", line 410, in scan
print("ERROR: Accessing bluetooth device whilst scanning: " + e.message)
AttributeError: 'ConnectionError' object has no attribute 'message'
Unhandled exception in thread started by <bound method TiltHydrometerManager.scan of <TiltHydrometerFermentrack.TiltHydrometerManagerFermentrack object at 0x73996ff0>>
Traceback (most recent call last):
File "/home/fermentrack/fermentrack/gravity/tilt/TiltHydrometer.py", line 399, in scan
blescan.hci_enable_le_scan(sock)
File "/home/fermentrack/fermentrack/gravity/tilt/blescan.py", line 74, in hci_enable_le_scan
hci_toggle_le_scan(sock, 0x01)
File "/home/fermentrack/fermentrack/gravity/tilt/blescan.py", line 83, in hci_toggle_le_scan
bluez.hci_send_cmd(sock, OGF_LE_CTL, OCF_LE_SET_SCAN_ENABLE, cmd_pkt)
_bluetooth.error: (100, 'Network is down')

Uhhhhhhhhh. Try restarting the Pi, and if it is still broken run:

ps -xauf | grep redis

...and post what you see.

It’s acting like redis is down which makes no sense.

 

[CadiBrewer]

Here's the output of ps-xauf | grep redis

pi 881 0.0 0.0 4380 544 pts/0 S+ 16:07 0:00 \_ grep --color=auto redis
redis 403 0.4 0.3 29692 3152 ? Ssl 16:05 0:00 /usr/bin/redis-server 127.0.0.1:6379

 

[leftcontact]

Raspberry Pi 3 B+ Note


Yep!

For the ESP8266 build, you'll probably want to choose a PCB from this list and then pick up the associated bill of materials. PM me if that list is confusing at all, I'm working on a different project on the side to help demystify it but that's ~2 months away at the moment.

For the Fermentrack build, you'll need a Raspberry Pi (Zero W works!) & the associated stuff to make it work (USB power supply, SD card, etc.). Thats about it.

Awesome, thank you!

 

[Thorrak]

Another day, another round of updates! Big ones this time. Let's start with what's been going on with Fermentrack.


Python 3 Update

The past week we've had a lot of issues as a result of the Python 3 conversion. Anyone that encountered any downtime as a result of this deserves my apologies - it was the potential for issues that was the main driver for why I wanted to go ahead and get the conversion out of the way rather than postpone it and suffer the same fate months/years down the line. Thankfully at this point I think most of the issues have been resolved (with the possible Tilt support issue @CadiBrewer noted - still looking at that) - but I'd be shocked if there weren't still a few bugs still out there. If you encounter any, please either post here or send me a PM.


Raspberry Pi 3 B+ Testing/Support

I picked up a Raspberry Pi 3 B+ this weekend and managed to get Fermentrack installed on it with minimal difficulty. There is one thing to be aware of, however - Unlike the 3 or Zero W, the Raspberry Pi 3 is designed to completely lock down WiFi on first boot if you don't provide it a working wpa_supplicant.conf file with the "country" directive. I've updated the Raspberry Pi installation notes to include this as it wasted a good hour of my Saturday and I'd rather nobody else suffer from the same fate.


Huey Support

One of the things I've been grumbling about for almost a year now is how there are certain things I'd prefer to be done automatically/asynchronously rather than waiting on user input (or locking up the user's web browser). Perhaps most critical amongst these is firmware flashing. Due to the way that the firmware flash process works, if a firmware happened to be too large (or your device was too slow, or you got really unlucky, or...) Django could time out before the process was complete potentially causing the flash to fail. This would (obviously!) not be good.

To correct for this, back when Gravity support was added I also added support for a new task manager called Huey. With the latest release Huey is now responsible for handling the process of actually flashing controllers once you finish the firmware flash workflow. What this means is that after you actually click the "Flash Firmware" button Fermentrack will queue the flash in the background and take you to a flash status page. Once the flash is complete, this page will report the full output from the flash process. This should hopefully make things flash more reliably and provide additional feedback on what happened during the flash.


Of course, it wouldn't be nice to release new firmware flash support without also providing something to flash with it, and that brings me to my next update...

 

[Thorrak]

BrewPi-ESP8266 Update

It feels like much of my focus has been on Fermentrack lately, but the original point of this thread was to showcase the ESP8266 port of the BrewPi firmware. While it works pretty well, there still are a few bugs to fix and changes to make, and to that end I've just released revision v0.10 of the BrewPi-ESP8266 firmware. This release aims to address a few of the bugs that have been outstanding the longest:

• WiFi Reconnection - One of the bigger complaints is that controllers wouldn't automatically reconnect to WiFi if the connection got interrrupted for any reason. This was especially problematic in mesh network environments where controllers at the boundary between nodes could find themselves periodically being disconnected. This has now been fixed.
• LCD Screen Scramble - Thanks to the hard work of @alexlark , this firmware release also contains a fix for the LCD screen scramble issue. Although it doesn't happen to everyone, for some people (myself included as of yesterday) the LCD will periodically "scramble" and display gibberish. It still works to control temperatures, but who wants to stare at that if they don't have to? @alexlark added a fix which periodically resets the LCD, so things should hopefully work a bit more smoothly going forward.
• Persistant AP - One thing I noticed is that sometimes my controllers would continue broadcasting their "ESPXXXXX" access points well after they had been set up. This was annoying, as it made them appear to be unsecured WiFi networks (and could possibly lead to some kind of issues with the controllers if too many people tried to connect to them). This update should prevent this from happening.

To see the updated firmware options in Fermentrack, just click the "Refresh Firmware List from Fermentrack.com" button. The old versions of the firmware will remain available (the v0.9 versions) until someone other than myself has had a chance to confirm that things are working as expected. As always - when updating the firmware, I highly recommend disconnecting the ESP8266 from everything. You don't want the flash process triggering your heater/cooler and destroying something.


New PCBs

One of the issues I've struggled with in each of my builds is splicing the wires from the DS18b20 temperature sensors to make them fit an RJ-11 connector. Where other people have chosen to use different connectors (XLR jacks, for example) I tried to solve the problem by creating an RJ-11 breakout board. Unfortunately, I ran into two problems with this design:

• RJ-11 cables come in straight-through and crossover, and it's not easy to tell at a glance which style cable you have. Inevitably, this means the cable you have lying around is the wrong style of cable.
• The screw terminals on the PCB never managed to capture the leads on the sensors well, resulting in them falling out. Finally, I gave up on the screw terminals and soldered the sensors directly to the breakout board which seemed to work well.

To this end, I ended up creating two new boards to help solve this problem. The first is a variation of the SMD PCB, but swapping the RJ-11 jack with an RJ-45 jack. The second is a variation of the RJ-11 breakout board, but swapping the RJ-11 jack for an RJ-45 jack, and replacing all of the screw terminals with places where the sensors can be directly soldered to the board. Now, rather than hunting for a decade-old phone cable that may or may not work, you can put that ethernet cable you have lying around that came with your router to use since everything in your house/apartment runs on WiFi anyways.

I haven't received mine yet, but for anyone who wants to take the plunge early (recognizing that I may have screwed and they may not work at all!) the boards are available here:

SMD Controller Board - https://PCBs.io/share/8DDk0
RJ-45 Sensor Breakout Board - https://PCBs.io/share/zMjYO

Once my first order arrives and I've had a chance to test them, I'll post more about them and let everyone know how they work.

 

[leftcontact]

@Thorrak , Just watched the overview videos and that makes sense. Thank you for posting them.
However, I have one minor gripe about video 1. For the love of all that is hoppy, *please* recommend people change the default user password as soon as you get the pi up and on the network (if you can't do it before). Internet of Things devices are a common source of botnets these days, and leaving a device suggestively named something-pi with the default password in place is practically begging for it to be hacked.
Thanks again for what you do.
-- Leftcontact

 

[Thorrak]

@Thorrak , Just watched the overview videos and that makes sense. Thank you for posting them.
However, I have one minor gripe about video 1. For the love of all that is hoppy, *please* recommend people change the default user password as soon as you get the pi up and on the network (if you can't do it before). Internet of Things devices are a common source of botnets these days, and leaving a device suggestively named something-pi with the default password in place is practically begging for it to be hacked.
Thanks again for what you do.
-- Leftcontact

HAH! Good timing! I actually tested some code this past weekend that would annoy the user until the default password was changed. The only issue with it is that the check for the default password appears to be triggered when the user logs in via SSH. If the user changes the password and doesn't log out & back in the message will keep getting triggered.

Also it only appears to work under Stretch, but I'm OK with that.

 

[stbernts]

@Thorrak Is it possible to do a OTA upgrade and keep the settings on the Vmos units?

 

[Thorrak]

@Thorrak Is it possible to do a OTA upgrade and keep the settings on the Vmos units?

OTA upgrade, no - @rocket4x4 was working on it last year, but we haven’t had a chance to sync up to finish it just yet.

Keep the settings on flash, yes. I flashed my controller a few days ago and didn’t have to re-enter any settings. Connected to WiFi and went straight back to work.

 

[hampa22]

I keep having the same issue over and over again, I have 2 ESP8266 set up with Fermentrack, and all of the sudden the text on the dashboard says ”cannot receive LCD text from controller/script” and when I try to access the device I get this message - ”Unable to reach brevpi-script for device xxxx”. Then all of the sudden it works again (or not)... I’ve tried reflashing the ESP8266 and reinstalling it but it’s Groundhog Day all over again... Anyone have any tips?

Edit: and it seems like the Controller Response Test is failing too..

 

[Mikmonken]

I had this too but it was resolved with the latest upgrades, including moving to stretch

 

[hampa22]

I had this too but it was resolved with the latest upgrades, including moving to stretch

I’m also on stretch and the latest update, but still not working...

 

[Bigdaddyale]

I keep having the same issue over and over again, I have 2 ESP8266 set up with Fermentrack, and all of the sudden the text on the dashboard says ”cannot receive LCD text from controller/script” and when I try to access the device I get this message - ”Unable to reach brevpi-script for device xxxx”. Then all of the sudden it works again (or not)... I’ve tried reflashing the ESP8266 and reinstalling it but it’s Groundhog Day all over again... Anyone have any tips?

Edit: and it seems like the Controller Response Test is failing too..

Can you disable one of the esp8266? maybe they are competing with each other and see what happens.

 

[jangevaa]

I couldn't get around bad gateway issues with upgrading on jessie last night. Didn't feel like messing around, nor did I care about saving configuration as I only have a single controller running at the time being so I did a fresh install with stretch lite and all is well. Just flashed the latest firmware on my ESP8266, thanks for your continued hard work on this!

Something I've wondered if possible... could the ESP8266 be used to store temperature and state data, such that if a connection to the ESP8266 was lost, that upon reconnection, it could sync this with the fermentrack server? Cheers!

 

[stbernts]

I’m also on stretch and the latest update, but still not working...

Well, in my expirience this happens due to poor wifi coverage.

 

[jangevaa]

I keep having the same issue over and over again, I have 2 ESP8266 set up with Fermentrack, and all of the sudden the text on the dashboard says ”cannot receive LCD text from controller/script” and when I try to access the device I get this message - ”Unable to reach brevpi-script for device xxxx”. Then all of the sudden it works again (or not)... I’ve tried reflashing the ESP8266 and reinstalling it but it’s Groundhog Day all over again... Anyone have any tips?

Edit: and it seems like the Controller Response Test is failing too..

Hmm. I just got this as well. ESP8266 on v0.10 became non responsive after trying to start a beer with it. Maybe just a coincidence, reflashing v0.10 again now, will go back to v0.9 if this repeats.

 

[Thorrak]

I keep having the same issue over and over again, I have 2 ESP8266 set up with Fermentrack, and all of the sudden the text on the dashboard says ”cannot receive LCD text from controller/script” and when I try to access the device I get this message - ”Unable to reach brevpi-script for device xxxx”. Then all of the sudden it works again (or not)... I’ve tried reflashing the ESP8266 and reinstalling it but it’s Groundhog Day all over again... Anyone have any tips?

Edit: and it seems like the Controller Response Test is failing too..

I'm assuming that you mean that it works for awhile, stops and displays the messages you cite, then a few minutes/some time later begins working again spontaneously?

If so - assuming you're on v0.10 of the firmware - I'm apt to agree with @stbernts - that sounds like a WiFi connectivity issue. There is a potential bug that @alexlark and I were discussing awhile back that could cause a controller to become unresponsive after ~90 days or somewhere in that realm, but having had a controller running far longer than that, I don't think it manifests quite like we initially imagined it could.

The reason v0.10 is important is that prior versions would just hang and never reconnect to BrewPi-script in that scenario.

I couldn't get around bad gateway issues with upgrading on stretch last night. Didn't feel like messing around, nor did I care about saving configuration as I only have a single controller running at the time being so I did a fresh install with jessie lite and all is well. Just flashed the latest firmware on my ESP8266, thanks for your continued hard work on this!

Something I've wondered if possible... could the ESP8266 be used to store temperature and state data, such that if a connection to the ESP8266 was lost, that upon reconnection, it could sync this with the fermentrack server? Cheers!

Sorry to hear about the upgrade issues, but glad to hear everything is working now! All of my testing at the moment is done on Stretch Lite - but that's because my test build is on a Pi 3 B+ which requires Stretch to function. Everything should continue to work perfectly on both Stretch and Jessie (and the Lite versions don't have the same issues that the full-flavor versions do with regards to pip and python3).

To answer your question about storing data locally: In theory, yes it could be added. In practice, it's a bit strange to implement given the BrewPi architecture/model.

The issue with implementing it really is a legacy one. The BrewPi model has everything except the temperature control being done from the Raspberry Pi. The Raspberry Pi sends each request for the data to be logged, timestamps it, and logs it. The Pi tracks where a beer is in a fermentation profile, and calculates the next time/setting to send to the controller. While the controller knows what is going on around it - that is, it knows if it is currently receiving profile-like temperature control requests, that's about all it keeps track of.

The reason for this is because the Arduino really just didn't have the power necessary to do anything else. The Uno has 32k of flash (used for the BrewPi software itself), 2k of ram, and 1k of EEPROM (where things like temperatures could be stored). By contrast, the ESP8266 has 4MB of flash, 40x+ more ram, and uses the flash space for user storage rather than dedicated EEPROM. The end result is that while you could expect an Arduino to run out of memory after ~10 minutes or so of logging by my estimates with a 30 second log frequency, it's not unreasonable to expect an ESP8266 to be able to continue to log for weeks doing the same. This is a big part of the reason behind @pocketmon 's wonderful BrewPiLess project which adds this kind of functionality, but doesn't connect to centralized software like Fermentrack or brewpi-www.

In short - it's not something that would be easy to add/change at this stage, without major rewrites to brewpi-script that wouldn't end up being backwards compatible with Arduino-based controllers.

 

[Thorrak]

Hmm. I just got this as well. ESP8266 on v0.10 became non responsive after trying to start a beer with it. Maybe just a coincidence, reflashing v0.10 again now, will go back to v0.9 if this repeats.

Now that's interesting. Let me know if that happens again, and I'll poke it a bit.

That said - no code changed that should have had anything whatsoever to do with a beer being active on the controller - that sounds like a Fermentrack issue. If it happens again, can you check the logs and send me a PM with what they say?

 

[hampa22]

I'm assuming that you mean that it works for awhile, stops and displays the messages you cite, then a few minutes/some time later begins working again spontaneously?

If so - assuming you're on v0.10 of the firmware - I'm apt to agree with @stbernts - that sounds like a WiFi connectivity issue. There is a potential bug that @alexlark and I were discussing awhile back that could cause a controller to become unresponsive after ~90 days or somewhere in that realm, but having had a controller running far longer than that, I don't think it manifests quite like we initially imagined it could.

The reason v0.10 is important is that prior versions would just hang and never reconnect to BrewPi-script in that scenario.

I tried disconnecting one of the ESP8266, still not working. I put it right next to my router and still the same thing happening. Controller response test still failing. I am on v0.10. And yes, it’s reconnecting spontaneously after a few minutes.

Another thing I can’t get to work is Ispindel with Celsius, it starts logging with Fahrenheit no matter what my settings are.

 

[Thorrak]

I tried disconnecting one of the ESP8266, still not working. I put it right next to my router and still the same thing happening. Controller response test still failing. I am on v0.10. And yes, it’s reconnecting spontaneously after a few minutes.

Another thing I can’t get to work is Ispindel with Celsius, it starts logging with Fahrenheit no matter what my settings are.

That's really strange. Can you check the log for your controller and see if it is throwing out any errors when it disconnects/stops responding?

The iSpindel logging in celsius issue is also a strange one, as I have the exact opposite issue (everything gets saved in Celsius). Out of curiosity, is your iSpindel set as a standalone device, or is it attached to a temperature controller? If it's set as a standalone device, is it logging a "beer"? If it's attached to a temperature controller, is that temperature controller logging a "beer"? Additionally - if it's attached to a temperature controller, is that controller set to log in Fahrenheit or Celsius?

 

[Thorrak]

I tried disconnecting one of the ESP8266, still not working. I put it right next to my router and still the same thing happening. Controller response test still failing. I am on v0.10. And yes, it’s reconnecting spontaneously after a few minutes.

Another thing I can’t get to work is Ispindel with Celsius, it starts logging with Fahrenheit no matter what my settings are.

I just pushed out a fix to Fermentrack that I think will help fix the issue with controller responsiveness. I also pushed out a fix to a bug with iSpindel temperature formats - but I don't think it fixes this bug. Let me know how your device is configured and I can take a look.

 

[hampa22]

That's really strange. Can you check the log for your controller and see if it is throwing out any errors when it disconnects/stops responding?

The iSpindel logging in celsius issue is also a strange one, as I have the exact opposite issue (everything gets saved in Celsius). Out of curiosity, is your iSpindel set as a standalone device, or is it attached to a temperature controller? If it's set as a standalone device, is it logging a "beer"? If it's attached to a temperature controller, is that temperature controller logging a "beer"? Additionally - if it's attached to a temperature controller, is that controller set to log in Fahrenheit or Celsius?

My Ispindel is used as a standalone device, and I’ve been using it to log a beer. Everything is set to log in Celsius.

This is my stderr log:

Apr 02 2018 04:51:06 BrewPi version received was 0.2.4 which this script supports in 'legacy' branch mode.
Apr 02 2018 04:51:06 Bound to TCP socket on port 2540, interface localhost
Apr 02 2018 04:51:07 Installed devices received: [{"v": 18.688, "a": "28FFD706A31704BF", "t": 1, "c": 1, "h": 2, "i": 0, "p": 12, "d": 0, "f": 5, "j": 0.0, "b": 0}, {"v": 0, "t": 3, "c": 1, "h": 1, "x": 0, "i": 1, "p": 14, "d": 0, "f": 3, "b": 0}, {"v": 0, "t": 3, "c": 1, "h": 1, "x": 0, "i": 2, "p": 16, "d": 0, "f": 2, "b": 0}]
Apr 02 2018 04:51:08 Available devices received: [{"t": 0, "c": 1, "h": 1, "x": 1, "i": -1, "p": 13, "d": 0, "f": 0, "b": 0}]
Apr 02 2018 04:51:40 Controller debug message: WARNING 2: Temperature sensor disconnected pin 0, address 28FFD706A31704BF
Apr 02 2018 04:51:40 Controller debug message: INFO MESSAGE 0: Temp sensor connected on pin 0, address 28FFD706A31704BF
Apr 02 2018 04:56:04 Lost connection to controller on read. Attempting to reconnect.
Apr 02 2018 04:56:09 Lost connection to controller on write. Attempting to reconnect.
Apr 02 2018 04:56:09 Serial Error: [Errno 9] Bad file descriptor)
Apr 02 2018 04:56:11 Unable to connect to BrewPi 10.0.1.15 on port 23. Exiting.
Apr 02 2018 04:57:13 Error: controller is not responding to new data requests. Exiting.
Apr 02 2018 04:57:34 Connection type WiFi selected. Trying TCP serial (WiFi)
Apr 02 2018 04:57:34 Connecting to BrewPi esp4988489.local (via 10.0.1.15) on port 23
Apr 02 2018 04:57:40 Successfully connected to controller.
Apr 02 2018 04:57:40 Notification: Script started, with no active beer being logged
Apr 02 2018 04:57:50 Checking software version on controller...
Apr 02 2018 04:57:50 Found BrewPi v0.2.4, running commit 00000000, running on an ESP 8266 on port 10.0.1.15:23