How To: BrewPi Over Bluetooth

[user 40839]

Noooooo worries. Wouldn't have gotten this far without your help. (None of us would!)

Alas, things are back to misbehaving at least on the Python side of things. Despite them sitting patiently all afternoon, the second minion is still showing as wanting to be updated. Out of curiosity, I swapped out the arduino with a spare I had - and am still having the same issue. BT board is showing up as paired in Pi, so if it's not the BT, and it's not the Arduino, then can surely only be something on the Pi side that I'm missing. Double checked the /home/brewpi/chamber2/settings/config.cfg file, and can't see an issue. Am somewhat stumped.

Will whack it with a hammer a bit later. Now have to figure out how to stuff these into Hammond 1550WK boxes.

 

[wbarber69]

Did you program the new arduino over USB? because like I said before, you will never be able to program the arduino over USB. You just program the arduinos first then connect them to the bt dongles.

 

[user 40839]

Did you program the new arduino over USB? because like I said before, you will never be able to program the arduino over USB. You just program the arduinos first then connect them to the bt dongles.

Yep, the new one was programmed via USB. Tried via BT, laughed a bit, and then busted out the cable.

But both Arduinos were already programmed, and working fine in a dual setup via USB. The bluetooth.... yeesh. To try and eliminate a variable, I swapped the BT modules between the Arduinos, and now neither of them are showing up in the web interface despite running for a couple of hours at this point. (Both instances showing the "Could not receive version from controller Please (re)program your controller" messages)

The new HC-05s I ordered just showed up... but were just the bare boards without the bluetooth module on them, derpa derp!

So now the current situation is that both HC-05 boards are paired with rfcomm to rfcomm0 and rfcomm1. rfcomm0 works sporadically, haven't gotten any response from rfcomm1. There's another HC-05 on the way, be here next week, and will try that in there.

 

[user 40839]

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

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

Dumb question of the day.

If the BT modules are supposed to be 57,000 1 stop no parity, shouldn't the command be 'AT+UART=57600,1,0'?

Anyways - pointless ubermick bluetooth update of the day. Received another HC-05, set up the baud rate (hence the question above!) and paired it up as rfcomm2. Changed the settings on chamber2 to read from rfcomm2, and same thing - Could not receive version from controller.

So nuked everything, and started from scratch. And I mean nuked. Full format of the Pi's SD card, reset the HC-05s back to factory default and went through the programming process, uploaded the barebones sketch to the Arduinos in case that had gotten corrupted.

Followed the multi-chamber setup on the Wiki to the letter. Got both Arduinos back up and running with completely new installs under USB. Unplugged the USB cables, paired the HC-05 units with Bluetoothctl, then connected them with rfcomm in the autostart file. Rebooted and...

 

[wbarber69]

Just grasping at straws here trying to help out, and this may be a dumb question, could you try to press the reset on the uno and let it reconnect on its own, to see if it's actually connecting or staying connected. it may also be a power issue. what kind of supply voltage are you dealing with?

 

[wbarber69]

Also could you try using a different browser or try connecting from a Windows machine if you have access to one

 

[froot]

The 'could not receive version number' issue has popped up before in the big thread. There was a simple fix, either reboot of the Arduino or maybe it was a brewpi update. Your so very close!!! And ya know ya just want to read that thousand page thread again. I'd be popping this in the main thread see if someone remembers the fix.

 

[Bigdaddyale]

The 'could not receive version number' issue has popped up before in the big thread. There was a simple fix, either reboot of the Arduino or maybe it was a brewpi update. Your so very close!!! And ya know ya just want to read that thousand page thread again. I'd be popping this in the main thread see if someone remembers the fix.

I think that has to do with the CH340 chip- not sure

 

[wbarber69]

He's using Bluetooth so no

 

[day_trippr]

One thought: verify the 1K and 2K resistors for the Uno TX signal level shifter are in the correct positions.
If they were swapped the high signal level would only make it to ~1.6V instead of 3.3...

Cheers!

 

[CadiBrewer]

One thought: verify the 1K and 2K resistors for the Uno TX signal level shifter are in the correct positions.
If they were swapped the high signal level would only make it to ~1.6V instead of 3.3...

Cheers!

Also try swapping the leads to the Bluetooth header for RX and TX.

 

[user 40839]

Also try swapping the leads to the Bluetooth header for RX and TX.

OH SON OF A...!

 

[CadiBrewer]

OH SON OF A...!

I go back and forth on how to label the pins on the header to avoid confusion. Without the shield, I think that most people know you need to connect the TX on the bluetooth module to the RX on the UNO and vice versa. However, when the shield is involved, the natural thought would be that the header pins are labeled so you just hook up the corresponding pins on the bluetooth module and don't worry about the crossover. If I have room on the board I'm working on, I may put a note there to help avoid confusion.

In any case, glad you got it working.

 

[day_trippr]

OH SON OF A...!

lol! Seriously?

 

[user 40839]

lol! Seriously?

Yep. Never assumed it was all Cadi's shoddy shield labeling that was the problem!

 

[wbarber69]

I go back and forth on how to label the pins on the header to avoid confusion. Without the shield, I think that most people know you need to connect the TX on the bluetooth module to the RX on the UNO and vice versa. However, when the shield is involved, the natural thought would be that the header pins are labeled so you just hook up the corresponding pins on the bluetooth module and don't worry about the crossover. If I have room on the board I'm working on, I may put a note there to help avoid confusion.

In any case, glad you got it working.

This is why I feel the bt header should line up directly to the pinout of the bt module…

 

[user 40839]

This is why I feel the bt header should line up directly to the pinout of the bt module…

The problem there is that there are different pinouts on different HC-05s.

 

[day_trippr]

Yes, but we established the hc-05's folks in our little group have been using have their RX/TX/5V/GND pins in the same order, so as long as the 4-pin header is positioned to allow an hc-05 to register at both extremes without bumping into anything it should work out...

Cheers!

 

[user 40839]

Yes, but we established the hc-05's folks in our little group have been using have their RX/TX/5V/GND pins in the same order, so as long as the 4-pin header is positioned to allow an hc-05 to register at both extremes without bumping into anything it should work out...

Cheers!

Hah. Mine are RX/TX/GND/5V! Personally I don't mind crossing wires around, I had to do it for the relay module as well. What tripped me up is that the LCD shields I got were labeled RX/TX/5V/GND, but seems that RX and TX were reversed on there, and had no reason to think they'd possibly be like that. My own fault in hindsight, as soon as I realized the HC-05s weren't the problem, I should have eliminated the shield in the equation rather than just assuming.

Mind you, don't want to come off as complaining and moaning at Cadi's efforts - the shield is still light years better than my DIY version with the soldered wiring underneath!

 

[day_trippr]

My bad, I wasn't providing an actual sequence, just listing the four pins we care about.
If you go back a couple of weeks in this thread you'll see my hc-05 which has those four pins in the same order, just shifted by a pin...

Cheers!

 

[wbarber69]

The problem there is that there are different pinouts on different HC-05s.

Nope they're all the same

 

[user 40839]

Rather than toss it into the bucket of wonks over on Raspberry Pi forums, thought I'd ask the resident geniuses here...

Just finished my first two minions (squeeeee!) and are running nicely. FINALLY. But if for whatever reason I need to power down one of them, is there a way to have it automatically repair without having to reboot the RPi?

 

[day_trippr]

I routinely power off my BT minions and they automatically reconnect in a minute or so when powered back up.

I thought you had that working? That was the thing I forgot to mention a few weeks back...

Cheers!

 

[user 40839]

I routinely power off my BT minions and they automatically reconnect in a minute or so when powered back up.

I thought you had that working? That was the thing I forgot to mention a few weeks back...

Cheers!

For the most part, I sort of have them working, with the occasional quirk - minion two will randomly report one of the sensors as 185 degrees when I turn it on, and will then gradually drop down to the correct temp. Also, if that one loses bluetooth connection, it'll ocasionally reset itself back to default on reconnect. Bloody weird. (And note the two digit decimal place in the beer temp, which is the one that dropped from 185 degrees.)

But neither will reconnect if I power cycle - I always have to reset the pi in order to get them paired again.

Here's some minion porn (!) tho...

 

[wbarber69]

How long did you wait, because it isn't instantaneous. the pi will try to start the script for the missing minion until it eventually causes rfcomm to reconnect to the unconnected minion.

 

[user 40839]

How long did you wait, because it isn't instantaneous. the pi will try to start the script for the missing minion until it eventually causes rfcomm to reconnect to the unconnected minion.

I've left it overnight without success.

I did revert back to CLI at one point - my wireless on the Pi is horribly spotty when it boots to desktop GUI mode - as soon as the screensaver kicks in for the first time, it can kill it. So I just had it boot to a command line, and set up a script/cron that pings google.com every five minutes, and if it can't find it, to reset the wireless connection. Which worked GREAT, suddenly SSH-ing in is super fast. But think that in bypassing the desktop, I also bypass the startup file which assigns the rfcomm channels.

Went back to the desktop, and sure enough, any minions that are RUNNING are connected on reboot. However if I turn a minion on after this, I get nada. Nosing around, I see that rfcomm files are only being created in the /dev/ folder for those running minions. If they're both on, a reboot on the Pi will see them both running. (Funnily enough, automatically switches their status to "off" as soon as they connect to the Pi)

So am thinking a script of something akin to the checking of wlan0 might work. Check every five minutes to see if rfcomm0 and rfcomm1 are connected, and if not reissue the command?

 

[day_trippr]

Just to re-iterate, for a reconnect to automatically happen, the BrewPi instance the minion is assigned to must be running a script.

It is the repeated attempts by BrewPi to connect to its assigned device that causes rfcomm to connect; if you stop the script the minion will never reconnect on its own...

Cheers!

 

[user 40839]

Nope, script is running in both cases. They're (right now) both set to beer constant, even though they're not connected to anything, and have disabled logging.

 

[CadiBrewer]

Could it have something to do with the way the native Bluetooth works on the RPI3 versus what the rest of us do with Bluetooth dongles on older versions?

 

[CadiBrewer]

This might work for your script to make sure it reconnects...ignore it if it is way off base.

The problem comes from the python script which does not close the serial port after the Android device has disconnected. One can implement a mechanism (doesn't matter how exactly you want to achieve it) that reacts to a Disconnected message received by rfcomm watch. Namely, when the disconnection occurs, you want to

Either close the port in python by calling Serial.close or kill the python process
Wait for the device to reconnect
Reopen the port or restart the python process
In detail

After calling rfcomm listen <dev> or rfcomm watch <dev>, the Pi is effectively waiting for a connection to be established on /dev/rfcomm0.

When the Android device initiates the connection, the endpoint /dev/rfcomm0 is created and will live forever unless the connection is broken by either of the parties.

In this situation, the python script referred in the question opens up the newly created serial interface (/dev/rfcomm0) via the Serial object abstraction.

Now when the Android device breaks the link, /dev/rfcomm0 is indeed removed but the python Serial object still lives in memory and keeps the port open even though the Android device is down. So when the Android device tries to reconnect after some time, rfcomm watch rightfully complains:

Can't create RFCOMM TTY: Address already in use
simply because the port hasn't been properly closed by the python script when the Android device first left.

To circumvent the problem, one can implement a mechanism (does not matter how exactly you want to achieve it) that reacts to a Disconnected message received by rfcomm watch. Namely, when the disconnection occurs, you want to

Either close the port in python or kill the python process
Wait for the device to reconnect
Reopen the port or restart the python process