How To: BrewPi Over Bluetooth

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.
That's pretty cool. Your enclosure size will be driven by the IO more than the electronics inside.

I thought I'd post that I just proved that you can indeed power the Uno via its USB port with a 5VDC power supply (eg: a 5 watt cell phone wall wart) without causing issues with the Bluetooth/Serial module function. Works perfectly in fact.

So I'm betting if the USB PHY never trains to an upstream port the uart macro output is never enabled. A Good Thing for us.

It's not much of a game changer but it'd simplify a system designed around a single 5VDC power supply. I never got 'round to trying this out before so I actually hacked the Unos in my two BrewPints crates to run on 5VDC directly connected to the headers...

Cheers!
 
Cool now Im definitely happy I pushed the nano to the edge of the board. One usb cutout 2 rj12 cutouts and acoupke holes for relay wires. Im happy with the design. I did it all on the fly so there are things I could have done better. But its smaller than an stc1000 although the stc has a display.
 
It never ends! The BT dongle I ordered is lost in fedex somewhere. Time for attempt number 2.
 
Found a serial bluetooth app for android that will communicate with the hc05
 
Got the hc-05 from the original post in today. Believe it or not it was harder to get working than the off brand. For some reason I had to upload the sketch over and over again until I finally got it into at mode and could get it to respond. Don't know why. Had it in at mode multiple times. It just wouldn't respond correctly. Sometimes I got an error and sometimes not. Was about to give up, ran the sketch upload again and it started working. :). Now I have another minion to start building. Maybe I'll build a starter fridge with stir plates in it.
 
Day_tripper, I see that you have been able to successfully upload the hex from within brewpi over bt. But have you been able to do so successfully with an arduino that has not been programmed with brewpi before. I ask because (even though I don't have my dongle yet) I have had success using the nano, I might get some minis in to further this addiction for all things small. Since I'd need to get an ftdi board to program them, I was thinking about just using an uno to setup the BT boards then just BT into the minis with brewpi and upload the hex files. Then I wouldn't need the ftdi board and I could just start building minions as the parts show up.
 
I don't think it would make any difference whether an Uno was ever programmed with BrewPi before. If it's loaded with a different script, everything gets over-written with the new (except the AVR's bootloader, of course).

When I thought I programmed the BrewPi hex file over the BT link the Uno was already programmed with the same file. So I need to repeat that experiment with a different sketch resident.

I'm a bit wiped from managing our burgeoning snow farm today, and I have a stout that won't keg itself to deal with, but if I still have any gas left in the tank this evening I'll see what I can prove...

Cheers!
 
No hurry. Ill have 2 bt dongles by tomorrow evening. Ill be able to test this out myself. I guess I can wait that long to put in an order for a bunch of minis.
 
Well it appears that thekraken might be on to something wrt programming the Uno over a Bluetooth link.

With the famous "blink" sketch loaded I can see the BrewPi gui trying to program the board but fail with a "sync" error. And with the BrewPi hex file already loaded (same as my original attempt weeks ago) it flies right through just like it was working, but closer examination of the log shows essentially the same error actually occurred (bolded, below). I totally missed that the first time.

At the very least this would bear some research to see why what's supposedly a transparent "bridge", isn't. Whether it's something that can be made to work is not clear right now, that's for sure. But as there's a work-around (program over USB first) it's not going to be a high priority for me.

So, I guess I'd plan on picking up that FTDI adapter...

Cheers!

Code: 
**** Arduino Program script started ****

Settings will be restored if possible

Devices will be restored if possible

Checking old version before programming.

Found BrewPi v0.2.4, running commit 2a6f7f05 build 40, on an Arduino standard with a revC shield on port /dev/rfcomm2


Requesting old settings from Arduino...

Saving old settings to file oldAvrSettings-Feb-22-2015-20-47-40.json

Loading programming settings from board.txt

Checking hex file size with avr-size...

Program size: 25766 bytes out of max 32256

Programming Arduino with avrdude: /usr/share/arduino/hardware/tools/avrdude -F -e -p atmega328p -c arduino -b 115200 -P /dev/rfcomm2 -U flash:w:"brewpi-uno-revC.hex" -C /usr/share/arduino/hardware/tools/avrdude.conf

[B]result of invoking avrdude:
avrdude: stk500_getsync(): not in sync: resp=0x44

avrdude done. Thank you.[/B]

avrdude done!

Giving the Arduino a few seconds to power up...

Back up in 5...

Back up in 4...

Back up in 3...

Back up in 2...

Back up in 1...

Back up in 0...

Now checking which settings and devices can be restored...

Checking new version: Found BrewPi v0.2.4, running commit 2a6f7f05 build 40, on an Arduino standard with a revC shield on port /dev/rfcomm2

Resetting EEPROM to default settings

Arduino debug message: INFO MESSAGE 15: EEPROM initialized

Trying to restore compatible settings from 0.2.4 to 0.2.4

New version is equal to old version, restoring all settings

Trying to restore old control constants and settings

Restoring these settings: {"coolTargetL": -0.537, "tempSetMin": 33.8, "coolTargetH": 0.357, "tempSetMax": 86.0, "beerSet": 75.0, "beerSlowFilt": 4, "fridgeSet": 86.0, "iMaxErr": 0.898, "fridgeSlowFilt": 4, "fridgeFastFilt": 1, "maxCoolTimeForEst": 1200, "maxHeatTimeForEst": 600, "idleRangeL": -1.799, "pidMax": 18.0, "heatEst": 0.199, "lah": 0, "Kd": -1.5, "fridgeSlopeFilt": 3, "hs": 0, "Ki": 0.25, "Kp": 5.0, "coolEst": 5.0, "heatTargetH": 0.537, "heatTargetL": -0.357, "beerFastFilt": 3, "tempFormat": "F", "idleRangeH": 1.799, "mode": "b", "beerSlopeFilt": 4}

INFO MESSAGE 12: Received new setting: tempFormat = F

INFO MESSAGE 12: Received new setting: tempSetMin = 33.8

INFO MESSAGE 12: Received new setting: tempSetMax = 86.0

INFO MESSAGE 12: Received new setting: pidMax = 18.0

INFO MESSAGE 12: Received new setting: Kp = 5.0

INFO MESSAGE 12: Received new setting: Ki = 0.25

INFO MESSAGE 12: Received new setting: Kd = -1.5

INFO MESSAGE 12: Received new setting: iMaxErr = 0.898

INFO MESSAGE 12: Received new setting: idleRangeH = 1.799

INFO MESSAGE 12: Received new setting: idleRangeL = -1.799

INFO MESSAGE 12: Received new setting: heatTargetH = 0.537

INFO MESSAGE 12: Received new setting: heatTargetL = -0.357

INFO MESSAGE 12: Received new setting: coolTargetH = 0.357

INFO MESSAGE 12: Received new setting: coolTargetL = -0.537

INFO MESSAGE 12: Received new setting: maxHeatTimeForEst = 600

INFO MESSAGE 12: Received new setting: maxCoolTimeForEst = 1200

INFO MESSAGE 12: Received new setting: fridgeFastFilt = 1

INFO MESSAGE 12: Received new setting: fridgeSlowFilt = 4

INFO MESSAGE 12: Received new setting: fridgeSlopeFilt = 3

INFO MESSAGE 12: Received new setting: beerFastFilt = 3

INFO MESSAGE 12: Received new setting: beerSlowFilt = 4

INFO MESSAGE 12: Received new setting: beerSlopeFilt = 4

INFO MESSAGE 12: Received new setting: lah = 0

INFO MESSAGE 12: Received new setting: hs = 0

INFO MESSAGE 12: Received new setting: heatEst = 0.199

INFO MESSAGE 12: Received new setting: coolEst = 5.0
 
The minis don't have a boot loader on board so apparently you have to hold reset to program them every time. Perhaps because of the uart interface the hex file upload may need a similar set of steps to make it happen. Which would be quite a pain. Maybe the bt module isn't able to invoke the loader?
 
Also I see in your log there that avrdude is using a baud rate of 115200 and the bt module would be set to 57600 per your instructions. Wouldn't that cause the out of sync error?
 
Oh ferchrissakes - I didn't bother scrolling the log window to see the rest of that string! :smack:

Ok, when I get the urge I'll see where that command string emanated and see if fixing the obvious baud rate mismatch will make it work.

Jeeze, I can be a ******* when I'm gassed.

On a more positive note, I did get that stout kegged :tank:

Cheers ;)
 
is there a way to have debian auto connect to the bt devices and open the serial ports up if i have to reboot
 
wbarber69 said:
is there a way to have debian auto connect to the bt devices and open the serial ports up if i have to reboot
Click to expand...

I've been just launching the Bluetooth Manager and connecting to each device in turn - my RPI's don't get rebooted all that often so it's not a huge burden. That said, I've given thought to automating it, just haven't given that any time.

Take a look at this page. It seems comprehensive enough, and indeed I may play with this myself...

Cheers!
 
Well that was probably the easiest thing I've tried on an RPi so far.

I have a pair of HC-05s and an HC-06 connnected to my test crate right now, using rfcomm0 through rfcomm2.

First I set up the rfcomm file at /etc/bluetooth/rfcomm.conf and it looks like this:

Code: 
#
# RFCOMM configuration file.
#

rfcomm0 {
# Automatically bind the device at startup
bind yes;
#
# Bluetooth address of the device
device 98:d3:31:b4:49:ac;
#
# RFCOMM channel for the connection
channel	1;
#
# Description of the connection
comment "BPSAT_1";
}

rfcomm1 {
# Automatically bind the device at startup
bind yes;
#
# Bluetooth address of the device
device 98:d3:31:b4:4a:33;
#
# RFCOMM channel for the connection
channel	1;
#
# Description of the connection
comment "BPSAT_2";
}

rfcomm2 {
# Automatically bind the device at startup
bind yes;
#
# Bluetooth address of the device
device 30:14:09:02:06:22;
#
# RFCOMM channel for the connection
channel	1;
#
# Description of the connection
comment "HC-06_1";
}

I set up my PIN file in /var/lib/bluetooth/00:1A:7D:DA:71:0A/pincodes (<= my BT dongle MAC) and it looks like this:

Code: 
98:d3:31:b4:49:ac 1234
98:d3:31:b4:4a:33 1234
30:14:09:02:06:22 1234

Then I tried simply restarting the RPi Bluetooth service as described in the instructions:

Code: 
$ sudo /etc/init.d/bluetooth restart

But with a few tries, the only device that consistently connected was the first HC-05 using port rfcomm0. The other two devices would not connect on their own, both showing the same set of messages:

Code: 
Feb 23 2015 21:24:22 Notification: Script started for beer 'BrewPi3 Test11'
Traceback (most recent call last):
File "/home/brewpi/brewpi3/brewpi.py", line 333, in 
hwVersion = brewpiVersion.getVersionFromSerial(ser)
File "/home/brewpi/brewpi3/brewpiVersion.py", line 40, in getVersionFromSerial
ser.write('n') # request version info
File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 485, in write
raise SerialException('write failed: %s' % (v,))
serial.serialutil.SerialException: write failed: [Errno 107] Transport endpoint is not connected

Soo...I needed a smoke break so I went ahead and rebooted the RPi.
When I came back in all three BT minions were connected and happily scripting away!

That's killer! I'm a happy dude this evening!

Cheers! :D
 
ok using the data provided on that page i can automatically connect to one bt device.

im still trying to figure out why only one works. i can setuo rfcomm0 and rfcomm1 using 2 different hc-05 connections. but for some reason only rfcomm0 will automatically connect. im still trying to figure out why i cant just duplicate the code for each additional device. but im one step closer.

also for some reason after restarting the bt the arduino always reverts back to celcius for some reason
 
You were one minute behind me - check out my last post.

None of my BrewPi sessions went awry after the system restart and auto-connection. All of the settings were maintained...

Cheers!
 
Could it be that's second device isn't setup to use brewpi yet. It has the hex running on it but I haven't cloned a folder set for it yet. I've tried the smoke break thing and I still cannot get my second device to autoconnect.
 
Don't smoke - it's bad for you ;)

It takes about five minutes to set up another instance.

I'd give it a try, if only because all of mine are running BrewPi and working and I don't have a handy alternative answer...

Cheers!
 
day_trippr said:
Don't smoke - it's bad for you ;)

It takes about five minutes to set up another instance.

I'd give it a try, if only because all of mine are running BrewPi and working and I don't have a handy alternative answer...

Cheers!
Click to expand...

not what im smoking.

anyway i cloned another folderset with the write stuff. restarted cron and it instantly connected!

super stoked now
 
trying to settle why fixpermissions isnt working on second brewpi. i think the c startup problem may be fixed by a manual reprogramming. i might have done someting while i was sending commands over the android last night.

Im trying to remember how i fixed this before. i can read the logs manually and they say the second uno is working. but the website says the script isnt loaded and it cannot open the log files.....
 
That does sound like a web gui permissions thing.

In your fixPermissions.sh file for each instance, make sure you changed the target webpath variable which points to the corresponding instance folder under /var/www, like so:

webPath="/var/www/brewpi1"

Cheers!
 
thats all kosher. the permissions are correct and everything. the script is running.the website cannot see it for some reason.

EDIT: it was a stupid slash missing missing in a config file
 
Any forward momentum on getting the arduino to program over bt? Im doing all this testing on a vm, so I can't be sure just yet that what Im seeing is typical. When I attempt to program over bt it destroys the connection and restarted the bt module. Like I said, Im sharing my dongle over a vm connection so my setup could be all kinds of crazy.
 
wbarber69 said:
Any forward momentum on getting the arduino to program over bt? Im doing all this testing on a vm, so I can't be sure just yet that what Im seeing is typical. When I attempt to program over bt it destroys the connection and restarted the bt module. Like I said, Im sharing my dongle over a vm connection so my setup could be all kinds of crazy.
Click to expand...

I tried it many times with different settings and it never worked with the pro mini.

But why would you need to, just programm it once with a cable.

Its already a long time since the last stable release.
 
wbarber69 said:
Any forward momentum on getting the arduino to program over bt? Im doing all this testing on a vm, so I can't be sure just yet that what Im seeing is typical. When I attempt to program over bt it destroys the connection and restarted the bt module. Like I said, Im sharing my dongle over a vm connection so my setup could be all kinds of crazy.
Click to expand...

So far I think I'm actually losing ground. I can't even get to the same apparent baud rate failure that the first attempt seemed to indicate. As soon as I tell the BrewPi gui to upload the hex file the BT module disconnects and the gui complains about an unconnected endpoint. The automated connections I set up last night may actually be working against me on that, but even that isn't clear.

I dug all through the two BrewPi file hierarchies on the RPi for one instance (/home/brewpi/brewpi4 and /var/www/brewpi4) and for the life of me I cannot find how BrewPi invokes avrdude, or where it gets the parameters it passes.

I did find avrdude has a boards text file where it appears you can tweak upload parameters. I tried changing the Uno to use 57600 baud (no joy) then tried setting it to use the AlaMode protocol - strictly hardware serial (no joy).

I'd like to be able to trace the workflow from the gui to the AVR, even though right now I'm not sure that would reveal anything.

So I'd plan on the "normal" programming method...

Cheers!
 
It looks like avrdude is invoked from programarduino.py and uses 57600 baud for uploading sketches: https://github.com/BrewPi/brewpi-sc...e853d2508c4d88fc50ee7db239d/programArduino.py

The arduino's bootloader looks to accept a new sketch for the first second after it's powered on or restarted. When connected through a USB cable the arduino is automatically reset each time a serial connection is established. To reprogram with the bluetooth you will need a way to reset the arduino, if you push the reset button just after you click upload in the script you'll see it should work, but obviously you have to physically be at the arduino to push the reset button.

It's apparently possible to repurpose/reprogram the hc-05's state pin, wire it to the arduino's reset pin, thereby configuring the hc-05 to reset the arduino after a BT connection is established and making the arduino ready to accept a new sketch. http://forum.arduino.cc/index.php?topic=218049.0 I messed around with this a couple weeks ago and couldn't get it working.

I've googled around and found a couple examples of folks using the hc-05 to wirelessly reprogram arduinos, however none were using the breakout board we are using and I couldn't get working quite right. I could have spent more time on it, YMMV.
 
I've read this whole thread a few times now, and I'm slightly confused on which unit to purchase. Is the innogear HC-05 still the preferred bluetooth device? Or is the HC-06 now preferred?
 

Similar threads

D
remote pressure monitoring
Replies
19
Views
3K
DuncB
D
rkhanso
For Sale Completed/tested BrewPiLess-32 Controllers for sale. $40, shipping included
Replies
9
Views
2K
rkhanso
rkhanso
OkieNotFromMuskogee
A Brewpi Remix Build
2
Replies
52
Views
10K
bloombrews
bloombrews
garzlok
My Fermentrack Build
2
Replies
56
Views
17K
garzlok
garzlok
garzlok
My Bluetooth Repeater Build (Works with Tilts)
Replies
16
Views
6K
neoresin
neoresin
wps-hbt2

Latest posts

Back
Top