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

Thanks!

That's the goal, but here's what I'm targeting first:

Features gained over BrewPi-www:
Single installation, Multiple controller (multi-chamber/device) support
Cleaner/semi-automated initial controller setup
Native WiFi support
Ability to export device configuration



Features lost vs. BrewPi-www:
Ability to flash firmware from within the GUI**
Random AJAX widgets


To be clear - the above is the minimum feature set I want before I post everything to GitHub.

The ability to flash from within the GUI is the primary feature that I want to complete between when the code goes up and when I start to post about it separately from the ESP8266 project. It's more important for the Arduino implementation in my opinion, but it's still an important feature!

 

"Django Unchained"?

Some uninspired ideas:

• BrewPi-Django
• BrewPi-Thorrak
• BrewPi-ESP8266
• BrewPi-Wireless
• BrewPi-MultiFi (multiple chambers + wifi)

I like the last one actually.

 

BrewPI-MutiFi rolls off the tongue best I think.

 

I understand the nod to the BrewPI roots (why a device for controlling fermentation was called BrewPI and not FerementPI, dunno) but there's not necessarily a PI involved here.

From: https://en.wikipedia.org/wiki/Theta

• 
  A variable indicating temperature difference in heat transfer.

How about ThetaPI or FermenTheta?

 

Because, like so many project names, FerementPI (or even FermentPI) is stupid.

Names are hard.

See?

Cheers!

 

True, but for this project - for better or worse - the controller really is designed to work within the BrewPi ecosystem.

That said, @pocketmon 's project does allow for the removal of the Pi -- but BrewPiLess is a pretty good name for it in that sense!

Yes. Yes they are.

 

Some without the "Brew" prefix:

• WiBrew
• WiPi
• WiChill
• WiFerment
• WiFerm
• WiControl
• WiStat
• WiBrewStat
• WiBother
• WiNameIt
• ESPPi
• ESPBrew
• MobiPi (mobility)
• MobiBrew
• GridPi
• NetPi
• PiNet
• BrewNet
• Labrynth
• NexusPi
• EtherPi
• MeshPi
• NetFerm
• FermNet

... does it feel like we might get better names by randomly connecting words?

 

Swapping the prefix for a suffix kind of sounds like cheating IMHO.

If I had any degree of artistic ability I might go for PrettyPi for the web app, but as it stands NotPHP-Pi is about the only claim I could make with a straight face.

 

Naming is really hard, maybe harder than programming.

I named BrewPiLess as BrewPiLite at the beginning because I thought it is a light weight version of original BrewPi. After a while, I found that it is not "lite" but in fact "Pi Less". "BrewPi Pi Less" then became BrewPiLess so that I honor BrewPi and at the same time point out the most important Pi-Less character.

A rose by any other name would smell as sweet.

It is true, sometimes. A good name does help, but what it is is more important. I can't help in naming, but I would suggest to have a short and easy name.

 

-FermCont
-FermentCtrl
-FermentControll
-FermSafe
-SafeFerm
-StableFerm
-FermStable
-IoTFerm
-FermIoT

 

I deliberately avoided any use of 'brewpi' in my project name so that there is no confusion whether it is officially supported by BrewPi or not (it's not).

liasis fuscus is the brown water python. So, my project is Fuscus. Python is the language, and brown water is beer. Yes, I took liberties with the adjectives and nouns.

 

Yup, names are hard

 

Here's my awful contribution
Vivipi
Django -> arouse -> vivify -> vivi pi

 

I'll.. uh. That's a hell of a train of thought!

 

How about BrewPiFi

 

Ok, I think I get it now. I ordered a set of screw terminal type boards from pcbs.io and then the level shifter boards from ali. I haven't finished the assembly yet, but I have all the components now.


On a side note, is anyone going to try and use the OLED screens on this setup? I have 3 20x4 I2C screens for a few of these but I would be interested in seeing the OLED screens become supported. Would be cool to get the 5th line of info. And the 1.3" screens are well priced on aliexpress.


For mounting my controllers I think I am going to laser cut some thin steel for the screens to replace the plastic covers on the grey plastic gang boxes at home depot.

 

Following. I ordered a few screens.

 

The case design you are talking about sounds interesting! If you end up going down that road, would you mind posting photos (and possibly the design)? I'd be curious to see how that turns out!


On the question of OLED screens -- I'm generally a pretty big fan of supporting as much hardware as possible (hence the attempt to port the firmware!) but I am a bit worried about the screen working the way you're talking about. BrewPi's firmware doesn't actually have a fifth line of data normally. I'm guessing the line you're referring to is the date/time added by Fuscus, but unfortunately that's entirely created by the Raspberry Pi. We could potentially add a fifth line of data to the ESP firmware, but I'm not sure what we would display on it. Also, 1.3" is... kind of tiny. I know. I have one of those displays sitting on my desk.


The other issue with adding support is that - as currently written - BrewPi uses singletons that are initialized at startup for virtually everything. The LCD "driver" that is used to typecast the singleton is defined at compile time which effectively precludes support (as written!) for a different hardware stack. By no means does this mean that support can't be added to the main line of firmware - just that it would be a somewhat chunky project in the current state.

Of course - nothing prevents you from simply compiling it in yourself if you're so inclined. One of the biggest benefits of switching to platformio is that developing is substantially easier than it was with the Visual Studio stack. Cheaper, too, given that platformio is free!

 

The OLED is nice, the 5th line in fuscus is likewise something that could be used here (IP address or date/time). I'm not sure I like them well enough to volunteer to do the coding for instance.

That reminds me, I still need to try the platformio environment. I never did get this to compile in VS.

 

Getting VS set up took me the better part of an evening if I recall - certainly more than 5 hours of work all in. Getting platformio set up took about 30 minutes - and that included figuring out what the hell it actually was doing.

I'm a huge fan of JetBrains IDEs so I got it set up with CLion, but you could set it up with a number of other IDEs if you have a preference (or even Atom which is free, though I wasn't a fan of it personally).

 

I just stumbled over this, great work! I will definitely test it out!
Any help needed? I checked to see if there was any TODO issues
to jump into but issue list was clean

 

I don't have a raspberry pi, and tried running this on several "LAMP" and "FAMP" servers, but kept getting this-
"AttributeError: 'TCPSerial' object has no attribute 'open'"
Has anyone else seen this?

Edit- some more details.. I am running the D1 mini on Thorrak's PCB (NO LCD version) with an "8 relay module" from Sainsmart. I have a single one-wire temp sensor connected. I can assign all the devices successfully, I see the temp, can set temp, etc. but keep getting this error after a few minutes of running. I run Thorrak's test firmware, and can see the relays switching on for 10 seconds, but have no LCD so temp does not display (although I get a reading via the brewpi web interface on the normal FW). I am using a 5v power supply that is 2A. I have re-flashed a few times on each disro i have tried. I always get this error, but the Debian seems to hold out longer. The Freebsd "FAMP" servers always gave the error shortly after sending a temp setpoint to the D1 mini... I am using the latest git pull on everything.
Hopefully this is something simple I am missing....

 

There's really not any at the moment within the firmware itself, aside from finishing up the v0.4.x line. Once that's done I have a side project I'd like to undertake within the BrewPi firmware, but that's not a TODO at this point.

There's a ton within the BrewPi-Django (BrewFi? Gotta decide on a name as well, I guess) codebase - but that's not quite to a point where I'm ready to release it on the world. Once I'm comfortable that it supports the basic features I'd expect (which hopefully will be later this week) then I'll post it. That's when I really could use the help!

Which step are you getting this?

 

I edited the post with more details, but it seems to be after sending commands (changing setpoints, modes, etc?)
With Debian it seems to be delayed, but with Freebsd (running in a jail) it happened every time I changed temp setpoint. The traceback has more info-
File "/usr/home/brewpi/brewpi-script/backgroundserial.py", line 99, in __listenThread
self.ser.open()
AttributeError: 'TCPSerial' object has no attribute 'open'
Everything I am trying is either a virtual or in a Jail, could that be something to do with it?
Thanks again

 

Admittedly, you're a step beyond my expertise on this one, I'm afraid. I don't know what you mean by "virtual" or "Jail" in this context, nor have I spent any appreciable amount of time in BSD to know what is triggering this.

That said -- You've definitely found a bug! The "open" method was never implemented in TCPSerial, but is used by backgroundserial.py.

I've added the missing method - this should work now (after refreshing from the repo, that is). Give it a shot & let me know what you find!

 

I'm ready to help where I can!

 

I'm not sure if anyone else has come across this, but this has happened with two of my ESP setups.

I'm not sure what's causing the issue but in short.

Whenever i apply either, Beer profile, fridge constant or beer constant it causes my ESP8266 to reset and then crash the brewpi GUI requiring an RPI restart.

I thought it might be isolated to one of my ESP set ups (i have the one Thorrak wired for me and the one i did myself) and bother appear to demonstrate the same issues.

I can tell the issue is an ESP reset as the blue light flashes, and also on the SMB board connected to an LCD it shuts the screen down and then reopens in desired profile.

Heres my log if it will help.

Code:

Dec 12 2016 12:23:00 Fresh start! Log files erased.
Dec 12 2016 12:23:12 Installed devices received: [{"a": "28FF15D662160423", "c": 1, "b": 0, "d": 0, "f": 5, "i": 0, "h": 2, "j": 0.0, "p": 12, "t": 1, "v": 16.0}, {"c": 1, "b": 0, "d": 0, "f": 2, "i": 1, "h": 1, "p": 16, "t": 3, "v": 0, "x": 0}]
Dec 12 2016 12:23:15 Available devices received: [{"a": "28FF66022E040099", "c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 2, "j": 0.0, "p": 12, "t": 0, "v": 16.0}, {"c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 1, "p": 14, "t": 0, "x": 1}, {"c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 1, "p": 13, "t": 0, "x": 1}]
Dec 12 2016 12:23:36 Device updated to: {"i":2,"t":1,"c":1,"b":1,"f":9,"h":2,"d":0,"p":12,"a":"28FF66022E040099","j": 0.000}
Dec 12 2016 12:23:50 Installed devices received: [{"a": "28FF15D662160423", "c": 1, "b": 0, "d": 0, "f": 5, "i": 0, "h": 2, "j": 0.0, "p": 12, "t": 1, "v": 16.0}, {"c": 1, "b": 0, "d": 0, "f": 2, "i": 1, "h": 1, "p": 16, "t": 3, "v": 0, "x": 0}, {"a": "28FF66022E040099", "c": 1, "b": 1, "d": 0, "f": 9, "i": 2, "h": 2, "j": 0.0, "p": 12, "t": 1, "v": 16.0}]
Dec 12 2016 12:23:51 Available devices received: [{"c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 1, "p": 14, "t": 0, "x": 1}, {"c": 1, "b": 0, "d": 0, "f": 0, "i": -1, "h": 1, "p": 13, "t": 0, "x": 1}]
Dec 12 2016 12:24:08 Notification: Beer temperature set to 17.0 degrees in web interface
Dec 12 2016 12:24:09 Controller debug message: INFO MESSAGE 12: Received new setting: mode = b
Dec 12 2016 12:24:14 Serial Error: [Errno 9] Bad file descriptor)
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "/home/brewpi/backgroundserial.py", line 99, in __listenThread
self.ser.open()
File "/home/brewpi/tcpSerial.py", line 127, in open
self.sock.connect((self.host, self.port))
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
File "/usr/lib/python2.7/socket.py", line 170, in _dummy
raise error(EBADF, 'Bad file descriptor')
error: [Errno 9] Bad file descriptor

 

The ESP resetting thing is problematic -- the BrewPi-www interface requiring a reset is (interestingly enough!) the same problem that @aknetman just discovered, per the trace you just posted.

If you update the brewpi-script code from the repo it should - as of last night - fix that issue.

 

From your repo or the brewpi repo? If the former it exhibits the same issues when I've made a clean install this afternoon

 

Well... crap. Give me a few minutes.

 

thought i'd gone nuts for a minute.

in terms of updating though (and excuse my ignorance) but to run the update i.e (assuming my brewpi tools i downloaded form your github is still the right one)

Code:

sudo brewpi-tools/updater.p

y

it then throws out this

Code:

######################################################
####                                              ####
####        Welcome to the BrewPi Updater!        ####
####                                              ####
######################################################

Checking whether the update script is up to date
/home/pi/brewpi-tools is up-to-date.



*** Updating BrewPi script repository ***

Stopping running instances of BrewPi
You are on branch develop
Your checked out branch is not master, our stable release branch.
It is highly recommended that you switch to the stable master branch. Would you like to do that? [Y/n]:

Do i switch at this point or stick to develop?

next up

Code:

The latest commit in /home/brewpi   is 104f42e070ed111966bb902d2742ac755fb8d986 on Mon, 12 Dec 2016 05:58:25
The latest commit on origin/develop is 104f42e070ed111966bb902d2742ac755fb8d986 on Mon, 12 Dec 2016 05:58:25
Your local version of /home/brewpi is up to date!


*** Updating BrewPi web interface repository ***
The path '/var/www' does not seem to be a valid git repository
What path did you install the BrewPi web interface scripts to?

mine is here /var/www/html so i change it

Code:

You are on branch master
The latest commit in /var/www/html is 1e0778703edbbd3ef33072ba0b260c491fba90cc on Mon, 11 Jan 2016 13:04:54
The latest commit on origin/master is 1e0778703edbbd3ef33072ba0b260c491fba90cc on Mon, 11 Jan 2016 13:04:54
Your local version of /var/www/html is up to date!

No changes were made, skipping runAfterUpdate.sh.
If you encounter problems, you can start it manually with:
sudo /home/brewpi/utils/runAfterUpdate.sh

The update script can automatically check your controller firmware version and program it with the latest release on GitHub, would you like to do this now? [Y/n]:

when i click y here is just seems to hang as it can;t find it via serial (its attached via USB but i actually connect to the ESP wirelessly) would that make a difference?

 

I am seeing the same thing with the updated tcpserial.py

The "virtual" and "jail" thing - basically everything I am trying is not on a physical device (like a RPI) but rather a virtual one. But I dont think this has any bearing on the issue as @Mikmonken is seeing the same thing on an RPI.

 

Well, crap. This is what I get for not testing code. I've got Sentry set up and logging - now just to wait and see.

Out of curiousity, how long does it take for you to get that error message? What are you doing right about the time it appears?

 

For me it's pretty much immediate after changing any setting. I've not got it in a live environment at the moment so can't see if it changes as new profile settings get sent to it

 

Ok. Sentry hasn't caught anything yet. I'll try tweaking settings when I get home and see what happens.

Thanks!

 

So are you not experiencing the same issues that we are if you move from way off to beer constant then?

 

After playing with this a bit, I think it's to do with an mDNS issue. I started to get the same error you were seeing after I left the ESP on for ~4 hours. Before the issue popped up I could telnet to the mDNS name, afterwards I couldn't.

I think I may have a fix for this, but in attempting to deploy it, I kind of nuked my Raspberry Pi's SD card. Don't buy cheap SD cards, kids!

I'm reflashing right now - should have a revised environment shortly.

No, but that's not surprising. The rig I have at home at the moment isn't running the version of brewpi-script that is on the repo, and it doesn't use mDNS.

That said, I need to build a test rig that does use both of these just to catch errors like this. That's on me - my apologies.

 

Just download the latest from GitHub and loaded it on to a new wemos setup. Seems to be chugging away merrily so far.

 

Ugh. I forgot how much I hate setting up new Raspberry Pis.

Given that the ESP8266 pretty much is entirely run over WiFi, would there be any interest in a VirtualBox image that had Ubuntu LTS + BrewPi installed? You wouldn't be able to run anything over serial, but hey - added bonus from the ESP...


Edit, because I don't want to post again: I think I've found a solution to the mDNS dropping out issue (I'll admit - it's a terrible solution, but it may work!). Testing overnight tonight. If it works, I'll post new firmware in the morning.

Still working on the related issue in BrewPi-script though.

 

I'll fresh install my RPI this afternoon and give it another shot. If there are any logs I can grab from my RPI let me know and I'll post with my results