Wireless Brewpi Via Wifi

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.

thekraken

Well-Known Member
Joined
Aug 18, 2014
Messages
1,957
Reaction score
449
Location
DFW
Rather than make a definitive how to guide I wanted to start sort of a discussion/development thread on getting the brewpi's arduino wirelessly connected to the pi (or linux machine) via a wifi adapter. I'm specifically referring to the new(ish) and popular esp8266.

This assumes that your are familiar with wiring up uControllers. Don't forget that the esp8266 needs a steady 3.3v power supply with 500 - 800 milliamps (if I remember correctly), and your 5v+ power supply to your arduino will fry your esp8266. I'll leave wiring diagrams and circuits for another post. I suggest looking into the LD1117 voltage regulator.

A few months ago I had the chance to play around with this and had a mostly working prototype.

The first thing I had to do was acquire an esp8266 module. These modules come several different variants. While any variant will work (I think), a variant with GPIO12 broken out is very convenient in that you can hook it up for wirelessly reprogramming the arduino. I chose to use variant esp-03. Variant esp-01 already has header pins on the breakout board and if you are not worried about wirelessly reprogramming the arduino this may be the easiest variant to get up and running. I assume that most people aren't re-flashing their arduinos after initial setup anyway.

The next thing to do is find some firmware that will allow the esp8266 to act as a "transparent serial bridge". In other words, all it does is act as a wireless serial communication relay sending and receiving serial data over your wifi network. There are a few different projects out there, I chose to go with the esp-link project as it had the wireless flashing feature mentioned in the last paragraph.

If you used the esp-link firmware and followed the setup instructions from it's project page you should be able to access your esp from an ip address like http://192.168.1.70 for example, and to access it as a serial relay you would go to port 23 (http://192.168.1.70:23). I believe that the firmware has since been updated to give the esp a host name so you can name your esp to something link esp-brewpi and access it like http://esp-brewpi:23, refer to the github project for more info.

After you've confirmed that your esp is up and running and connected to your network you need to setup the brewpi scripts on the raspberry pi (or what ever your server is) to access the arduino via wifi instead of serial.
To do this you will need to adjust a couple lines of code in the brewpi scripts. The first thing is to change the line in BrewPiUtil.py:
Code:
ser = serial.Serial(port, baudrate=baud_rate, timeout=time_out)
to
Code:
ser = serial.serial_for_url(port, baudrate=baud_rate, timeout=time_out)
That will be around line # 130.

And the second is to change the port variable in the config.cfg file from this:
Code:
port = /dev/ttyACM0
To something like this (this depends on your setup):
Code:
port = 192.168.1.70:23

After you make those adjustments and reset your brewpi scripts it should be good to go.

At this point I had some issues with periodically dropping the wireless connection but I think it had more to do with a poor power supply to my esp8266.

For those of you wanting to try to use the esp8266 with your brewpi setup I hope the above information will be helpful in at least steering you in the right direction.

esp8266 variants: http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family
esp-link: https://github.com/jeelabs/esp-link
brewpi-script/BrewPiUtil.py: https://github.com/BrewPi/brewpi-script/blob/21caa7a408a7fe0ede08b544c8768b9d8c902d7d/BrewPiUtil.py
brewpi-script/config.cfg: https://github.com/BrewPi/brewpi-script/blob/015e5c7040672af9e0dc3045ac1b681036c372d6/settings/config.cfg.example
 
Last edited by a moderator:
Thats great work thekraken, thank you.

I wonder how difficult it would be to adapt the brewpi code to run entirely on the ESP8266. Mabe with a small I2C OLED display. :)
 
Thanks for this, it motivated me to give it a go.

I needed to add socket:// to get it to work.
ie.
port = socket://192.168.1.70:23

I can start it up and it gets the version but I can't discover devices, really don't get much past that, I am using an esp-01 and getting a lot of packet loss just idle to esp-link, which I think is the issue. Might try a esp-12.
 
How are you powering the esp? Also, have you had the esp up and running reliably before for any other project? If you can't get passed the version check that's not very useful.
 
I have a 12v 1a power supply feeding both the arduino and a voltage regulator for the esp. I was using a $1 ebay adjustible unit but I replaced that with a ld33v regulator & caps with no difference.

ESP appears fine otherwise.

I get the feeling the pings are just the esp and a bit of a red herring. If I do them every second I get a lot more packet loss than every 5 seconds.

root@brewpi-test:~# for i in $(seq 1 10); do ping -c 30 10.69.69.26 | grep "packet loss"; done
30 packets transmitted, 22 received, 26% packet loss, time 29037ms
30 packets transmitted, 22 received, 26% packet loss, time 29075ms
30 packets transmitted, 27 received, 10% packet loss, time 29042ms

root@brewpi-test:~# for i in $(seq 1 10); do ping -i 5 -c 30 10.69.69.26 | grep "packet loss"; done
30 packets transmitted, 30 received, 0% packet loss, time 145159ms
30 packets transmitted, 30 received, 0% packet loss, time 145153ms
30 packets transmitted, 30 received, 0% packet loss, time 145166ms
30 packets transmitted, 29 received, 3% packet loss, time 145153ms

If I telnet to the port, it will work for a few commands then stop responding, brings me back to the packet loss. Might try another ESP to be sure.

Do you have any issues around esp-link dumping the last 1k of buffer when you connect? I can see how this is nice for a console but it feels a bit loose if you want true serial over IP behaviour.

Cheers!
 
I can tell by your terminal command skills that your probably better at this than I am. I hadn't run a packet test like that, I can't imagine that when I was up and running that I was losing that many packets. Also, in other projects, iv run telnet sessions with the esp-link for several hours without a hitch. I'm sorry that I'm not in a position at the moment to run those command along with you.

What's the physical separation from your WiFi router like?
 
Thats great work thekraken, thank you.

I wonder how difficult it would be to adapt the brewpi code to run entirely on the ESP8266. Mabe with a small I2C OLED display. :)

I don't know. truthfully, I hadn't even written my own firmware for an esp. Iv just been using them as a cheap way to make my arduino projects wireless. Off the top of my head I think you would be limited by too few gpio pins.
 
Not to minimize the effort to port the BrewPi AVR code to ESP8266, but on the hardware side all you really need for a bare-minimum BrewPi minion is one pin for the One-Wire "bus" for the probes, and two pins for relays - and one more if you're switching a fan...

Cheers!
 
1. The esp8266 was roached, luckily another arrived from China :) no packet loss.
2. the serial.inWaiting() appears to not work with socket://, I'm no python expert. The subroutine that gets the version uses serial.readline() and works.

So with this in mind, in addition with the config change;
BrewPiUtil.py ~ line 129
- ser = serial.Serial(port, baudrate=baud_rate, timeout=time_out)
+ ser = serial.serial_for_url(port, baudrate=baud_rate, timeout=1)

brewpi.py ~ line 345
- inWaiting = ser.inWaiting()
+ inWaiting = ser.readline()

- newData = ser.read(inWaiting)
+ newData = inWaiting

Appears to be working :)
 
1. The esp8266 was roached, luckily another arrived from China :) no packet loss.
2. the serial.inWaiting() appears to not work with socket://, I'm no python expert. The subroutine that gets the version uses serial.readline() and works.

So with this in mind, in addition with the config change;
BrewPiUtil.py ~ line 129
- ser = serial.Serial(port, baudrate=baud_rate, timeout=time_out)
+ ser = serial.serial_for_url(port, baudrate=baud_rate, timeout=1)

brewpi.py ~ line 345
- inWaiting = ser.inWaiting()
+ inWaiting = ser.readline()

- newData = ser.read(inWaiting)
+ newData = inWaiting

Appears to be working :)

Interesting. It worked for me without having to make these changes. So before this change you were getting nothing after the version?
 
forgive my total ignorance on what's going on here, but I need a little clarification

so, what this $5 doohickey does is change the configuration from the top figure in this pic to the bottom?

wireless brewpi.jpg
 
That's about right. But the rpi could be swapped for a desktop in the next room, and then multiple arduinos (wirelessly) attached to it. For example you could have 1 rpi that controls your kegerator in your kitchen and your keezer in your garage without having to buy an additional rpi.

How to set up multiple instances on a single rpi is beyond the scope of this thread though.
 
You could run the brewpi in the cloud :)

Anyway my test setup is a debian wheezy 32bit vm, everything up to date, python modules, os packages, brewpi stable from the git repo dated Aug 5th.

If I change dumpSerial to True in BrewPiUtil.py and run brewpi.py I saw the commands get pushed but no replies after the version subroutine;

Code:
root@brewpi-test:/home/brewpi# sudo -u brewpi python /home/brewpi/brewpi.py
Oct 14 2015 11:53:38   Opening serial port
 Oct 14 2015 11:53:38   Notification: Script started for beer 'My First BrewPi Run'
 Oct 14 2015 11:53:48   Checking software version on controller...
nN:{"v":"0.2.4","n":40,"c":"2a6f7f05","s":2,"y":0,"b":"s","l":"1"}
 Oct 14 2015 11:53:48   Found BrewPi v0.2.4, running commit 2a6f7f05 build 40, running on an Arduino Uno with a revC shield on port socket://10.69.69.25:23

sctttt

The first difference that would probably hold the answer is that you do did not need socket:// but this is quite well documented in the py serial docco and would not work for me.

I'm running Python 2.7.3 and pyserial 2.7.
 
I just installed a fresh Ubuntu 14.04 LTS 64bit VM, installed brewpi via the guide and made the changes as I described, and can confirm it's the same result.
 
Last edited:
just have the one arduino controlling the fermenation fridge, so we're good there.

with all the restrictions on my setup, this sounds like a great solution.
 
just have the one arduino controlling the fermenation fridge, so we're good there.

with all the restrictions on my setup, this sounds like a great solution.

Check out the Bluetooth brewpi thread too.
 
It's worth reporting that the ESP-01 also works with avrdude when you set the pin assignment to esp-01(AVR) and connect gpio0 to the arduino reset.
 
I had problems with that if I powered the esp off and back on. (At the time) it seemed to need gpio0 for it's own purposes while powering up.
 
Parts finally arrived and I've cobbled together an esp-03 based module with an LDO 3.3V regulator.
It's 1.125" x 1.75" overall, not too bad.

esp03_module.jpg

Checked out the regulator before wiring in the esp, but I haven't powered the whole thing up yet - mostly because I haven't figured out what to expect from an "out of the box" esp module yet.

Turns out the current versions of esp-link (pretty much everything from 2.0 on) requires a minimum of 1MB of on-board flash, while the esp-03 only has .5MB. The last working version that supports the esp-03 is 1.04(b1) which fortunately still has a home on Github, but a lot of documentation has moved past the esp-03.

Also looks like the programming environment only runs under Linux?
Not that huge a deal - I can use one of my RPi boxes I suppose.

And it seems I can't pull a full MAC address out of this thing all that easily. Obviously it needs to show up on my network - which normally has MAC filtering enabled. At the minimum I'll have to turn that off until I can get this thing to talk to me somehow.

Anyway, more as I stumble through this :)

Cheers!
 
I didn't know they have outgrown the 03. I went with the 03 as that was what the developer was working with at the time. Maybe there are other wifi serial bridges that will get the job done? FYI, in case you don't already know, with the 03 I had to connect pin15 to ground with a 1k resistor.

[Edit] For the initial flashing of the 03 module I had to used a windows application called ESP Flash Download Tool V1.2, this was the first flashing software I came across that would work reliably. At that point I could follow the instructions from the esp-link wiki to upload its firmware. Of course, once you get an initial version of the esp-link firmware running you can upload updated versions wirelessly with the included scripts.

I dual boot, a flavor of *nix is usually my primary os, I'm sorry it didn't occur to me to mention this from the beginning. You can use a virtual machine on your windows machine if you don't want to mess with your pi for development, I like virtualbox for this. I guess I figured if you're using a pi your using linux.

I may be wrong but I think the developer provides the compiled binaries for the firmware, you can upload this using the windows software I mentioned earlier. If you want to hack the esp-link code or flash the firmware remotely that may require a *nix machine.
 
I hope this is of help. I used this firmware which is very basic when compared to esp-link.
https://github.com/beckdac/ESP8266-transparent-bridge
Hence my assumption that it is small enough for your module. I programmed the firmware in the windows environment. There are a host of programing tools out there that run on windows, most don't seem to work. I will find out, which ones I used and post them here, when I program the next one expected in the post soon. I gave up on the bluetooth modules because of stability issues, and poor range. The blue tooth modules work great, but I found I had to reboot the pi whenever there was a problem which was about 2 or 3 times a day. The wifi modules seem to be more robust at staying connected. I am also migrating the whole environment off the pi and onto wheezy running in virtual box, in the hope of having a more stable environment. I will add more info soon. Hope this is some help.

http://www.byvac.com/index.php/BV107. I think this is what I ended up using, based upon the above firmware. I must try documenting what I do, to stop going round in circles.
 
Last edited:
esp-link 1.0.4 is stable/fine, I've done a few brews on wifi now. I'm running ubuntu 14.04 lts for brewpi on a vm as wheezy is old as the hills.

I used a cheap logic converter like this one, if you use the tx/rx off the arduino you will toast the esp with 5v.

I just stuck it all on a prototype board and used it as is.

Also in this pic is the cable i made to program the esp-01, guess I'm lucky my $1 ttl adapter can supply enough 3.3v to do this.

wifipi.JPG
 
esp-link 1.0.4 is stable/fine, I've done a few brews on wifi now. I'm running ubuntu 14.04 lts for brewpi on a vm as wheezy is old as the hills.

I used a cheap logic converter like this one, if you use the tx/rx off the arduino you will toast the esp with 5v.

I just stuck it all on a prototype board and used it as is.

Also in this pic is the cable i made to program the esp-01, guess I'm lucky my $1 ttl adapter can supply enough 3.3v to do this.

So its been working stable for 3 fermentations? Any issues to speak of?
 
This is an awesome project. I think I'm going to order one of these (http://www.adafruit.com/product/2471) esp8266 breakout boards. Comes with a built in voltage regulator. I could get a voltage regulator and wire it up myself but I'm lazy.

Just wanted to clarify one thing, you are just wiring up the TX and RX from the esp to the arduino, correct? The TX of the esp to the RX of the arduino and vice versa?

Edit:
Just answered my own question by looking at the esplink page. Gonna set this up as soon as my fermenter clears up. Don't want to be messing with it while I have stuff fermenting in it :D
 
I used a voltage divider circuit for the rx/tx, you could also use a logic level converter or just use a 3v arduino. You don't want to wire a 5v arduino directly to the esp.
 
So its been working stable for 3 fermentations? Any issues to speak of?

None, just works :) Actually better than before as I ran the old set up on a powered usb hub and had the occasional communications issue over USB to the arduino, and now I use a 9v 1a plug pack and no USB.

On the topic of 3.3v arduinos, I believe the relays like 5v.

mahbrew.JPG
 
I used a voltage divider circuit for the rx/tx, you could also use a logic level converter or just use a 3v arduino. You don't want to wire a 5v arduino directly to the esp.

Yeah the breakout board I linked to has a level shifter built in so you can just wire 5V straight into it. If you're not using the breakout board, you'll need to bring it down to 3.3V.
 
I have a fundamental question about bringing up a brand new esp (an esp-03, in this case): if it's powered up (and has the apparently required 1K pull-down on GPIO15) how does one actually talk to it?

It's not going to be able to connect to any wifi network that requires credentials - it doesn't have any credentials to offer. And if there are a number of strong wifi beacons in range, how's it going to decide which one to even try to connect to?

If it can't connect to an actual network, does it generate an ARP address and go with that - and you have to peer with it?

A little insight would be appreciated, thanks!

Cheers!
 
Yep, you'll need to wire it up to your computer the first time and use AT commands to give it a network and key. If you get esp link firmware on there it can boot as its own wifi access point, you then find its network with your device/computer and change its settings via web browser interface instead of AT commands.

I use a usb-bub II to talk to it over wire.

(Edit) also, I had a hard time getting any kind of meaningful response out of my esps until I realized the preloaded firmware was crap and updated to the latest firmware. After I figured out I needed to do that things progressed much smoother. (Keep in mind this was several months ago for me )
 
Oh, ffs.
That probably should have been obvious but not having seen word one about needing an FTDI adapter I blanked :drunk:

I wonder if I can use the serial port on an RPi instead...

[edit] looks like that'll work.

[edit2] I was able to get my esp-03 talking to one of my idle RPi Model B boards using minicom.
With that I discovered the module was shipped set for AP mode (ie: a host instead of a client).
Changed that to Client mode, then was able to connect to one of my WAPs - once I turned off MAC filtering.
Once I was connected successfully I was able to fetch the esp-03 MAC address, add that to my MAC white list, and re-enable filtering on that WAP.

Things were pretty flaky though. Half the time a random AT command would cause the RPi to reboot.
SWAG was insufficient power with the esp drawing current from the RPi, and indeed the 5V rail on the RPi was dropping as low as 4.2V.
I suspect the wall wart for the RPi isn't making its rated output current - I'll have to do some load testing on it - but meanwhile I fed the esp with its own 5V supply and that squared things up nicely.

Hopefully I'll have time this weekend to figure out how to flash this thing with this setup.
It's possible the Arduino IDE will do the trick...

Cheers!
 
So I have my esp-03 flashed with esp-link, it happily automatically connects to the appropriate WAP, and I am able to communicate through it in both directions without issue.

I was ready to hook it up to the UNO, but then I ran into this quagmire...

1. The esp8266 was roached, luckily another arrived from China :) no packet loss.
2. the serial.inWaiting() appears to not work with socket://, I'm no python expert. The subroutine that gets the version uses serial.readline() and works.

So with this in mind, in addition with the config change;
BrewPiUtil.py ~ line 129
- ser = serial.Serial(port, baudrate=baud_rate, timeout=time_out)
+ ser = serial.serial_for_url(port, baudrate=baud_rate, timeout=1)

brewpi.py ~ line 345
- inWaiting = ser.inWaiting()
+ inWaiting = ser.readline()

- newData = ser.read(inWaiting)
+ newData = inWaiting

Appears to be working :)


I have a feeling you guys are running a newer version of BrewPi, as those edits don't line up with anything (or, they are ambiguous enough that I can't find a match).

For instance, my BrewPiUtil.py is 133 lines long, and no lines look like:
ser = serial.Serial(port, baudrate=baud_rate, timeout=time_out)

Instead, there are two instances of this fragment (at line 107 and line 112):
ser = serial.Serial(port, 57600, timeout=0.1)

And the real killer, my brewpi.py file doesn't have anything remotely close to what's shown above.
Indeed, there's no occurrence of "inWaiting", and the "newData" line references a json command.

Of course there are no file versions in sight (Bad coders! Bad BAD coders!).

Sigh...

I suspect I'm going to have to update to a more recent vintage BrewPi release.
This sounds epically horrible to me, but I'm not sure I have an option.

Anyone ever do an actual update from one installed BrewPi version to another - successfully - that can tell me what's required?

Cheers!
 
So I have my esp-03 flashed with esp-link, it happily automatically connects to the appropriate WAP, and I am able to communicate through it in both directions without issue.

I was ready to hook it up to the UNO, but then I ran into this quagmire...




I have a feeling you guys are running a newer version of BrewPi, as those edits don't line up with anything (or, they are ambiguous enough that I can't find a match).

For instance, my BrewPiUtil.py is 133 lines long, and no lines look like:
ser = serial.Serial(port, baudrate=baud_rate, timeout=time_out)

Instead, there are two instances of this fragment (at line 107 and line 112):
ser = serial.Serial(port, 57600, timeout=0.1)

And the real killer, my brewpi.py file doesn't have anything remotely close to what's show above.
Indeed, there's no occurrence of "inWaiting", and the "newData" line references a json command.

Of course there are no file versions in sight (Bad coders! Bad BAD coders!).

Sigh...

I suspect I'm going to have to update to a more recent vintage BrewPi release.
This sounds epically horrible to me, but I'm not sure I have an option.

Anyone ever do an actual update from one installed BrewPi version to another - successfully - that can tell me what's required?

Cheers!

Whoa, before you go to the trouble of updating your brewpi scripts just try swapping the ser.serial commands you did find for ser.serial_for_URL or whatever the command is. Serialforurl is backwards compatible to .serial so if your using a IP address or a USB port it won't (shouldn't) break anything. And you can just change port to your IP address or try and find where port is defined in your config and change it there.

...I have a feeling your right on the cusp of getting it working.
 
Whoa, before you go to the trouble of updating your brewpi scripts just try swapping the ser.serial commands you did find for ser.serial_for_URL or whatever the command is. Serialforurl is backwards compatible to .serial so if your using a IP address or a USB port it won't (shouldn't) break anything. And you can just change port to your IP address or try and find where port is defined in your config and change it there.

...I have a feeling your right on the cusp of getting it working.

That's encouraging enough to try :)

I was trying to rationalize the differences between what you apparently changed that worked, and what dibbz had to change to get his setup to work. No joy there - but the bottom line is I can't make all of dibbz changes anyway.

So, I suppose I could try changing the two instances of

ser = serial.Serial(port, 57600, timeout=0.1)

to

ser = serial.serial_for_url(port, 57600, timeout=0.1)

and ignore what dibbz did, and see what happens.

Tomorrow, maybe. I'm a bit too far into my cups to deal with that right now - and I planned a double brew day for tomorrow. Priorities ;)

Anyway, I went through the alleged "update" script and it's essentially a complete wipe and git-clone, plus every friggin' package that BrewPi touches gets re-installed or updated. That's massive - and exactly what I really would rather not have to attempt unless that's the only way out. Frankly I wasn't impressed with the original installation procedure, either, and this looks like a sledge hammer approach to updating.

Because I run four instances of BrewPi on my "production" system, I'll have to shut down all four script instances, do the update to one instance, then assuming I get that one running, clone it to the others (rather than repeat the hellacious list of package updates three more times).

It's times like this that I'm really, REALLY happy I have a backup/development system to use for this. Right now I have three batches of beer between two ferm chambers, another fridge full of carbonating/conditioning kegs, and a keezer, all being controlled by BrewPi. Taking THAT system down for this update ain't gonna happen. Once I have its clone working perfectly (fingers crossed) I'll clone its SD card...

Cheers!
 
Another shot at this.

After adding CONN and SER LEDs to my ESP module, I changed the two ser commands in BrewPiUtil.py
from ser = serial.Serial(port, 57600, timeout=0.1)
to ser = serial.serial_for_url(port, 57600, timeout=0.1)

then changed the port definition in config.cfg
from port = /dev/ttyACM0
to port = 192.168.1.230:23

and saw zero serial activity through the ESP.

Then I changed the config.cfg entry
to port = socket://192.168.1.230:23

and saw BrewPi attempting to talk to the ESP.

It tried 16 times before giving up with the "Could not receive version from Arduino Please (re)program your Arduino" message.

Also tried changing the baud rate to 115200 with the same results.

I suspect upgrading is in my future...

Cheers!
 
Just out if curiosity, and to troubleshoot, have you tried running a test sketch to confirm serial comms? The arduino IDE probably has some example scripts that would work.

Or have you opened a terminal window to see what/if the brewpi avr is spitting out? You should see human readable json. For example if you send h{v:1} to the brewpi avr via serial it should return sensors.

*IF* your not getting anything here then outdated brewpi script shouldn't be the issue.
 
The ESP works fine in both directions when connected to an RPi hw serial port at 115200 baud. The target UNO has been running a BT radio for months - but at 57600 baud. I'm wondering if this is the root of the problem.

In any case, I backed up the SD card on my test system, cloned all of the brewpi folders locally, edited the upgrade scripts for the 4th instance that corresponds to the particular UNO I'm trying to fit the ESP to, then ran the upgrade.

Amazingly, it completed successfully (aside from updating the AVR firmware - which I skipped as it won't work over BT). After fixing some problems the upgrade induced in the cron script and the config.cfg file, and setting the configs for the 4th instance, BrewPi was up and running on that instance.

Interestingly, the upgrade borked the other three instances, so I cloned the working 4th instance to the other three and they all came up just fine (three instances running over Bluetooth and one direct-connected via USB).

Then I made the exact edits that dibbz made to the files for my 4th instance, and while I could see the serial LED flashing, BrewPi was unable to communicate with the UNO successfully.

So I thought the ESP would auto-baud, but it appears it doesn't.

I just tried connecting with the RPi serial port again, this time launching minicom at 57600 baud and a Putty session through the Wifi side, and while the SER LED would flash when either end was sending data, the characters received at either end were garbage. With the RPi end set to 115200, it works perfectly.

What that tells me is I can't rule out a baud rate mismatch when connecting with the UNO.

I have a feeling I'm missing something basic wrt the ESP firmware...

Cheers!
 
What a *******.

I never even looked at the uC Console tab on the ESP web server - where you can change the *&%^#@! baud rate!

Back in a few minutes...

Cheers! :drunk:
 
Ever closer. Now, BrewPi finds the UNO and apparently can read the firmware version

Nov 30 2015 01:40:03 Opening serial port
Nov 30 2015 01:40:03 Notification: Script started for beer 'RPINTS BrewPi4 Test7'
Nov 30 2015 01:40:13 Checking software version on controller...
Nov 30 2015 01:40:13 Found BrewPi v0.2.4, running commit 2a6f7f05 build 40, running on an Arduino Uno with a revC shield on port socket://192.168.1.230:23

The UNO is happily sending packets that can be displayed in the esp-link uC Console. But the BrewPi gui can't fetch the device configuration, or load settings from the UNO, and "Script Starting Up" is still displayed the whole time (the gui never displays what's on the actual LCD).

Also, the stdout pane in the log display remains blank the whole time, so it seems like data is being dropped on the floor.
I have a feeling that's significant - like maybe stdout is being misdirected.

I tried just using the changes in the original post, but that didn't work at all.
I definitely needed the other changes dibbz made to get this far.

Could someone with a working ESP post the contents of their /etc/cron.d/brewpi file, please?
I'm wondering if mine is messed up somehow...

Cheers!
 
Back
Top