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.
You need to edit the BrewPi config file to point to the rfcomm port that the BT module is paired to.

Eg: assumes your BT module connected to rfcomm0

Code:
$ sudo nano /home/brewpi/settings/config.cfg

scriptPath = /home/brewpi/
wwwPath = /var/www/brewpi/
port = /dev/rfcomm0
altport = /dev/null
boardType = uno

Save, exit, and restart the BrewPi script to see if it'll find the Uno via the rfcomm port...

Cheers!
How do I double check my BT module is connected to rfcomm0?
 
When you used the Bluetooth Gui, it would have told you which channel the module paired with.
I think you might be able to get that info from the gui again, but in any case, the first connection will always be to rfcomm0 unless you explicitly direct otherwise.

And to that end: there's a point back in this thread that @wbarber69 and I found a nifty utility that automagically reconnects a Bluetooth device to a given channel.
Ah - Thank Google - here it is.

Once you manually get the BT module working, you'll want to get this widget running for the long-term.
If you get a total power failure, once the power comes on everything will reconnect the right way and life will continue just like there never was a power failure...

Cheers!
 
They cross.

TX from the BT module goes to RX on the shield.

TX on the shield goes through a resistor divider with the output going to RX on the BT module.

Cheers!
 
Well I reprogrammed the uno with the usb cable and got it working.I tried to connect to another uno board with BT and no luck. I thought something might be screwy with my Chinese board but it's not .Next up is to hook up the Hc05 with out the shield and see what happens
 
Looks like everything is working after I programed the sob with the usb cable then hooked up the BT.Wonder why it wouldn't reprogram the uno over BT
 
You generally need to have some way to reset the Arduino to start the programming operation. With a hard-wired connection one of the serial control lines is hooked up to the reset line. With BT you only have Tx and Rx data lines.

One thing you can try (for BlueTooth) is to reset the Arduino then immediately try to program it. There is a short delay at startup when the Arduino decides if something is trying to program it, or if it should start normal operation. If your programmer-over-BT starts within that time it should work.
 
Yup, ^that's^ correct - and indeed somewhere around post #95 I realized that loading firmware over the BT link wasn't practical - considering it's a rare event and better handled over USB, before cutting loose with the BT module...

Cheers!
 
I'm going to use my daily stupid question quota on this thread: Does operation over bluetooth require support in the BrewPi hex?
 
No. The Bluetooth modules make a virtual serial port. So the Arduino behaves as if it was wired.
 
No. The Bluetooth modules make a virtual serial port. So the Arduino behaves as if it was wired.
Okay great. There's a brewpi hex file in day_trippr's archive so I was not sure if he had it there for the sake of completeness or if it was really needed.
 
Last edited by a moderator:
Okay having an issue I hope is an easy fix. I purchased the JBtek you linked for me. I made myself a voltage splitter harness and hooked it all up. the sketch uploaded fine but the LED never went to a slow blink; it stayed with a rapid flashing.

There was no "key" terminal, I guessed at that one. Probably incorrectly. :) Actuallt I tried both the one marked "EN" and the one marked "STATE" and got the same results.

I used 1K resistors, hopefully you can make out what I did with them. I drew over the top of one of the pics below showing where they are in that mess of wiring.

The only thing I did different is I used the PC-based Arduino IDE. It was set at 9600 though.

File_000.jpg


File_001.jpg


File_002.jpg


File_003.jpg
 
Easy fix. you want to just get into uart mode I assume. you have the button version. so disconnect power from the module and add it back while holding the button… this should enter auto uart mode. this, by the way, is not the module from the op.
 
Easy fix. you want to just get into uart mode I assume. you have the button version. so disconnect power from the module and add it back while holding the button… this should enter auto uart mode. this, by the way, is not the module from the op.

@day_trippr recommended this one up there in post 294 since the one in the OP was no longer available.

By using the button trick I got it into slow flashes.

I had various degrees of success getting "OK" back playing with newline, carriage return and both. The only one that really seemed to do anything was carriage return and that gave me all sorts of spam like it kept on repeating the same command.

Is this a parity or stop bit issue? I can't see how to set those in the serial port monitor. The top clipping is when I enter 'AT" and the bottom is when I enter 'AT+UART?'.

CaptureOK.JPG


CaptureUART.JPG
 
@day_trippr recommended this one up there in post 294 since the one in the OP was no longer available.

By using the button trick I got it into slow flashes.

I had various degrees of success getting "OK" back playing with newline, carriage return and both. The only one that really seemed to do anything was carriage return and that gave me all sorts of spam like it kept on repeating the same command.

Is this a parity or stop bit issue? I can't see how to set those in the serial port monitor. The top clipping is when I enter 'AT" and the bottom is when I enter 'AT+UART?'.

Just for kicks and giggles, swap your TX and RX connections. I'm sure that isn't the problem because you're getting some form of UART in your serial monitor, but that's what ended up working for me.
 
Just for kicks and giggles, swap your TX and RX connections. I'm sure that isn't the problem because you're getting some form of UART in your serial monitor, but that's what ended up working for me.
Tried that ... quickly so I did not let the magic smoke out powering the circuit with 5v instead of 3.3. No go. Back the other way and I still get my spam of "OK" so nothing changed.

I switched the purple lead from STATE to EN with no change. Not sure what KEY is ... but the purple is supposed to be connected to it. Either way, connected to either one of those, no change in behavior.
 
In your picture it seems the plastic condom is covering the button, could it possibly be getting slightly pushed in?
 
You know that got me to thinking. It acts more like something in the sketch is wrong. Maybe I'll have a look at that.

In your picture it seems the plastic condom is covering the button, could it possibly be getting slightly pushed in?
It does not feel like it. The button seems to push in/pop out like it should. Now that I know to hit the button, getting it into UART mode is pretty easy. It's just that spam.

Another thing I thought of. The purple wire to KEY is supposed to be the one that puts it in UART mode so I'll leave that disconnected in my next try.
 
Look up hc-05 with button on Google. as I remember I had to use a slightly different sketch wrt successfully changing devices names and such. its been a couple years now and if I remember correctly, for the most part all my w/button modules came with the correct baud rate already setup and all I really had to do was change the names.

Also these don't have a the ability to put them into uart like the op since all that circuitry is running to the button
 
Well, I did my "if all else fails" go-to and ignored the errors. I typed the baud rate commands anyway and proceeded.

The next issue I had was that the bluetooth utility did not see the adapter. I edited /etc/group and changed line 8 from “lp:x:7:” to “lp:x:7:pi”.

Now the adapter was there. I was able to pair, setup, and then had to "forward" the device to /dev/rfcomm0 in order for it to show up. Now I have an Uno happily beaming it's information to my Pi successfully.

It was not a flawless execution, nothing pretty about it, but I'm in business.
 
The biggest problem I've seen after a couple years is that subtle changes/fixes to rasbian or Python serial packages can dramatically break little one off projects like this
 
Good news great to here it's working. I had a similar module to you. Took a lot of googling but you had to do some funny things to get it all to register. I'm away at the moment so don't have my notes. I'll see if I can find them when I get back in a week or so.
If in range I've found them tone very bull let proof to resets etc.
 
Also glad to read you figured it out. I'm ensconced on The Cape Of Cod for the week and likely won't be particularly responsive 'til I return home next week...

Cheers!
 
Ah Cape Cod sounds nice. I'm headed to Galveston myself. By the time I get back I'll have forgotten my root passwords with any luck.
 
here's some notes I had when i was using them. Basically Daytripprs notes with a couple of points added to suit the modules i was using.

I added a picture of the ones i used.

FOR THE HC-05:
Tools - Serial Monitor to launch the Arduino terminal session
The Serial Monitor should be set to 9600 baud, 1 stop bit, no parity bit, no flow control

Both NL & CR and 38400 baud used

The BT/Serial Module LED should be blinking slowly.

Note: Dialogue commands and responses are framed with single quotes for clarity.
Do not use quotes in commands.

Change the HC-05 operating baud rate:

Check to see if HC-05 is alive:

Need to remove the “EN” pin after entering the UART mode in the serial interface in the arduino Ide otherwise you wont get a response when you type into the Arduino terminal session

Type: 'AT' and click the Send button Response should be 'OK'

Check the operating baud rate:

Type: 'AT+UART?' Response could be '+UART:9600,0,0' followed by 'OK'

Change the operating baud rate to 57600 1 stop no parity:

Type: 'AT+UART=57600,0,0' and click Send. Response should be 'OK'

You can check to see if the command "took":
Type: 'AT+UART?' Response should be '+UART:57600,0,0' followed by 'OK'

Optional: The "name" the HC-05 provides to inquiries can be displayed and changed:

Display the current BT/Serial module name:

Some commands dont work unless you follow this procedure with the board
type in the command then HOLD DOWN THE BUTTON ON THE hc05 BOARD then hit enter OTHERWIZE COMMAND WONT WORK


Type: 'AT+NAME?'
Response will be '+NAME: HC-05' followed by 'OK'

Change the module name to 'BT_AGENT1' Type: 'AT+NAME=BT_AGENT1'

See if it took:

Type: 'AT+NAME?' Response should be '+NAME: HC-05_2' followed by 'OK'

hope this helps. cheers gerry

btooth module.jpg
 
I added a picture of the ones i used.
Since this one now says "3.6v - 6v" I wonder if we still need the voltage splitter?

The Serial Monitor should be set to 9600 baud, 1 stop bit, no parity bit, no flow control
Any idea how to check/set the parity and stop bit on the Serial Monitor?

Need to remove the “EN” pin after entering the UART mode in the serial interface in the arduino Ide otherwise you wont get a response when you type into the Arduino terminal session
Interesting, I wonder if that was part of my issue. Ultimately I didn't end up using that at all.

Some commands dont work unless you follow this procedure with the board
type in the command then HOLD DOWN THE BUTTON ON THE hc05 BOARD then hit enter OTHERWIZE COMMAND WONT WORK
That seems really clunky and I hope unintended. I wonder what's at play there?
 
1.AFAIK you still need the voltage splitter as this is used for comms.
2. I used the arduino IDE and set it to Both NL & CR and 38400 baud. if it doesnt respond try other baud rates.
3. i found that it didnt work at all for this board unless i removed the EN pin.

4.Clunky but worked for me . I think this has to do with the firmware loaded to the board. Only really need it if you use some commands like renaming the unit and seeing if it loaded the changes.

just tried it again now and still works. some pics added

I since moved to wifi boards esp01

IMG_3728.JPG


IMG_3729.JPG


IMG_3730.JPG
 
So I have my bluetooth connected brewpi working perfectly under wheezy and and RPI 2b. How do I find the mac address and the device address so I can set this up to automatically reconnect when the RPI is rebooted?

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
 
So I have my bluetooth connected brewpi working perfectly under wheezy and and RPI 2b. How do I find the mac address and the device address so I can set this up to automatically reconnect when the RPI is rebooted?

Assuming you installed Wheezy with LXDE, you can use the Bluetooth Manager applet (when you find it, stick it on the desktop).
The "Devices" page will show all of the remote agents with their MACs readily visible.

The Device Address is the virtual COM port - in this case, an rfcomm(n) where n can be anything from zero on up...

Cheers!
 
Assuming you installed Wheezy with LXDE, you can use the Bluetooth Manager applet (when you find it, stick it on the desktop).
The "Devices" page will show all of the remote agents with their MACs readily visible.

The Device Address is the virtual COM port - in this case, an rfcomm(n) where n can be anything from zero on up...

Cheers!

Thanks. I hadn't seen the devices page on the applet.

I ended up disconnecting the bluetooth receiver and then doing hcitool scan and that showed me the device address. Then I used hcitool dev and that showed the MAC address of the dongle on the RPI. I followed your write-up and it worked like a charm. Kind of fun to have the RPI reboot and have the brewpi automagically reconnect to the bluetooth manager.
 
[...]Kind of fun to have the RPI reboot and have the brewpi automagically reconnect to the bluetooth manager.

Glad you got it working, it is very handy if your infrastructure isn't conducive to running USB cables.
But I wouldn't have gotten so hard-core into the wireless "minion" paradigm without this auto-reconnect thing. I mean, I actually need it all to work even if the ancient muni power company throws a momentary outage because of a break-before-make protocol...

Cheers!
 
Glad you got it working, it is very handy if your infrastructure isn't conducive to running USB cables.
But I wouldn't have gotten so hard-core into the wireless "minion" paradigm without this auto-reconnect thing. I mean, I actually need it all to work even if the ancient muni power company throws a momentary outage because of a break-before-make protocol...

Cheers!

My infrastructure sounds a lot like yours - a chamber on the other side of a doorway from the Pi that runs my Keezer and 'Pints. Bluetooth was the perfect solution, especially now that I have it automatically reconnecting.

Just have to force myself to make a backup of the SD card now that I have Pints and two brewpis working perfectly...
 
Sorry if this has already been asked, but I search for spark and saw nothing. Can this also be done for the official brewpi sparkv2?
 
I've been struggling with setting up the BT on my rig. I finally got it up and running last night on a single instance, with a second instance still (and will remain) hardwired. I was stuck at step 5 of the walk through, getting garbage characters returned in the Serial Monitor with "AT" commands.

Just to echo LBUSSY's "if all else fails" approach, I applied the mechanical engineer's method, and just hit it with a bigger hammer... repeatedly. In other words, I too ignored the problem and proceeded onward.

Any way I have 3 more instances I plan to set up on BT, hopefully tonight. I've seen the sketch for binding rfcomm ports and will be implementing that too. Question now, and it's preventative, is there an edit I need to make to the arduino.rules file I initially setup following the hardwired multiple instances method?
 

Latest posts

Back
Top