[Q} Send/simulate bluetooth headset button click from Gear to phone?

Search This thread

ulnah

Member
Oct 16, 2009
7
0
Is it possible to send/simulate a bluetooth headset button click from the Gear to the attached phone?


My goal is to have that click activate Google Voice Search on the phone, but all the options I've tried don't work well enough.

1) Sending bluetooth commands through rooted terminal like: echo -e "AT\r" > /dev/ttySAC0
sending any command to ttySAC0 would crash the bluetooth connection. I guess this is a serial interface and isn't designed to accept text commands (I don't have a full understanding of this, just conjecture). Other devices like 'uhid' and 'uinput' didn't work either (everything just returns 1, and I don't know what that means either), I tried all the ones that showed up under 'ls -l /dev/' with 'bluetooth' in their properties.

2) Using tasker+autoremote: works when bluetooth tethering is on but is slow (command going through internet and back), and works when bluetooth direct receiving is enabled on the phone, but this drains battery a lot (Autoremote always awake listening on bluetooth). Neither one of these is a palatable side effect (slow, or battery drain).

3) Using tasker to intercept a command from the Gear media controller app
Works sometimes, I usually use the 'previous' button, but the need to 'Grab' the media button interferes with using it for music playback, and using another tasker task to enable/disable this profile leads to erratic behavior (sometimes the media player, Winamp in this case, will start working immediately, sometimes not). The bigger issue is that the media controller app stops responding after an hour or two, requiring rebooting the phone, or killing some of the Samsung Accessory services running in the background, which then relaunch themselves. I think there's too much interaction here with Tasker, Winamp, and the Samsung Accessory stuff to know what's happening though. The delay is also highly variable, which is annoying, and sometimes when the Voice Search launches I do not get the initial 'ding' audio through the Gear, though there could be a ton of reasons for that as well.

Long story short, I'm hoping being able to simulate bluetooth headset button presses/commands would solve all of the above problems, getting faster response, no/minimal extra power consumption, and be very reliable. Also, this may sound dumb, but I don't actually have a normal bluetooth headset to test with either.

Thanks to everyone that's on xda-developers, this is my first post ever, but I've been coming to this site for stuff for years.
 
Last edited:

lopan2000

Member
Jun 11, 2010
28
10
Oops. Should have guessed that. Thank's for the quick reply.


A possible work around would be to activate Google Now on your phone, then goto gear manager and have it send notifications from Google search. Once you get some notifications from Google search, you can click the "show on device" button and it should open, and you can say "OK Google" to start start it up. (make sure you turn that feature on in the Google search settings )
 

mattytj

Member
Dec 27, 2006
29
2
My solution, for anyone interested...

I use AutoVoice rather than Google Now, although any command not matched by AV I have sent to Google Now for processing.

Anyway, there doesn't appear to be any faster way of communicating than via whatever it is that the Gear and my Note II communicate over by default. Not having the know-how to tap into this, I figured I would just use an existing method of communicating and use Tasker to intercept and pretend that was a BT button press instead.

So what I've done is just set it up so that when I use the dialer to run a USSD code that doesn't mean anything on my phone, this triggers what would ordinarily happen on a BT button press on autovoice - that is:

When variable %WIN matches "USSD code running" -> Perform task with actions: "Input - back" and then Plugin - State - Autovoice - Recognise... or whatever it is you want.

So that last action could be replaced by launching Voice Search if you want Google Now to take control.

I've probably not explained that well at all, will post a proper how to if anyone's interested.
 
  • Like
Reactions: manos78 and fOmey

fOmey

Recognized Developer
Mar 7, 2009
4,128
5,560
Sydney, AUS
I use AutoVoice rather than Google Now, although any command not matched by AV I have sent to Google Now for processing.

Anyway, there doesn't appear to be any faster way of communicating than via whatever it is that the Gear and my Note II communicate over by default. Not having the know-how to tap into this, I figured I would just use an existing method of communicating and use Tasker to intercept and pretend that was a BT button press instead.

So what I've done is just set it up so that when I use the dialer to run a USSD code that doesn't mean anything on my phone, this triggers what would ordinarily happen on a BT button press on autovoice - that is:

When variable %WIN matches "USSD code running" -> Perform task with actions: "Input - back" and then Plugin - State - Autovoice - Recognise... or whatever it is you want.

So that last action could be replaced by launching Voice Search if you want Google Now to take control.

I've probably not explained that well at all, will post a proper how to if anyone's interested.

This is actually quite a clever work around, great thinking.
 
  • Like
Reactions: mattytj

ulnah

Member
Oct 16, 2009
7
0
I can't get this to work. For example, when I use '*#111222#' and press 'dial' on my phone, it tries, then errors (this is good I think)

But when I tried to dial the same number from my Gear, I get '*#111222# not supported. Are you on null rom on your Gear?

I use AutoVoice rather than Google Now, although any command not matched by AV I have sent to Google Now for processing.

Anyway, there doesn't appear to be any faster way of communicating than via whatever it is that the Gear and my Note II communicate over by default. Not having the know-how to tap into this, I figured I would just use an existing method of communicating and use Tasker to intercept and pretend that was a BT button press instead.

So what I've done is just set it up so that when I use the dialer to run a USSD code that doesn't mean anything on my phone, this triggers what would ordinarily happen on a BT button press on autovoice - that is:

When variable %WIN matches "USSD code running" -> Perform task with actions: "Input - back" and then Plugin - State - Autovoice - Recognise... or whatever it is you want.

So that last action could be replaced by launching Voice Search if you want Google Now to take control.

I've probably not explained that well at all, will post a proper how to if anyone's interested.
 

mattytj

Member
Dec 27, 2006
29
2
This is actually quite a clever work around, great thinking.


Thanks mate, big fan of your work with the Gear, would have returned this thing after a day without you ROM. :)






I can't get this to work. For example, when I use '*#111222#' and press 'dial' on my phone, it tries, then errors (this is good I think)

But when I tried to dial the same number from my Gear, I get '*#111222# not supported. Are you on null rom on your Gear?

Are you using the phone app on your gear or the dialer app? I am running _null.

Using the dialer means it just passes the dialer digits to the phone to process, so I simply dial "2" on the dialer and call. 2 gets picked up as a ussd code, which does nothing, but tasker intercepts and Pepper, my phone, asks me what she can do for me. I speak into my watch and she proceeds to ignore or misunderstand me.
All operating as normal.

Sent from my GT-N7105 using xda app-developers app
 
Last edited:

ulnah

Member
Oct 16, 2009
7
0
For some reason I thought it would have to start with '*#' to be recognized as a code, but '2' works as well.

Some quick testing shows no problems, I hope it stays that way. I had tried something similar by dialing a dummy number, having it hang up, and then start, but that took a long time and was much worse than this. Thank you!
 

fOmey

Recognized Developer
Mar 7, 2009
4,128
5,560
Sydney, AUS
This works excellent !

Only thing I dont like is the "unknown code" error that pops up on my phone, once I figure how to terminate that, its perfect.
 

mattytj

Member
Dec 27, 2006
29
2
This works excellent !

Only thing I dont like is the "unknown code" error that pops up on my phone, once I figure how to terminate that, its perfect.


If it's an OCD type issue like me, trigger an overlay scene on the error message that destroys itself when the error isn't in focus, something like "Initiating...." . So mine does that, with a back action also triggered by the error. My attribute trends to lag so the error it's thrown before recognition. If after, adapt the scene to say, executing... or something. Point is, it of sight, out of mind!
 

fOmey

Recognized Developer
Mar 7, 2009
4,128
5,560
Sydney, AUS
If it's an OCD type issue like me, trigger an overlay scene on the error message that destroys itself when the error isn't in focus, something like "Initiating...." . So mine does that, with a back action also triggered by the error. My attribute trends to lag so the error it's thrown before recognition. If after, adapt the scene to say, executing... or something. Point is, it of sight, out of mind!

Iv attempted to simulate a back button press with tasker, works fine if the phone is unlocked.. although if the phone is locked, im presented with a "UNKNOWN CODE" error which frustrates me :p

Ill have to get back to the drawing board and figure it out..


EDIT: Shortly after writing the above I came up with this, works a treat:

Code:
Task: Phone Trigger (36)
	A1: AutoVoice Recognize [ Configuration:
Voice command with headset Package:com.joaomgcd.autovoice Name:AutoVoice Recognize Timeout (Seconds):0 ] 
	A2: Wait [ MS:0 Seconds:4 Minutes:0 Hours:0 Days:0 ] 
	A3: Run Shell [ Command:input keyevent 4 Timeout (Seconds):0 Use Root:eek:n Store Output In: Store Errors In: Store Result In: ]
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    My solution, for anyone interested...

    I use AutoVoice rather than Google Now, although any command not matched by AV I have sent to Google Now for processing.

    Anyway, there doesn't appear to be any faster way of communicating than via whatever it is that the Gear and my Note II communicate over by default. Not having the know-how to tap into this, I figured I would just use an existing method of communicating and use Tasker to intercept and pretend that was a BT button press instead.

    So what I've done is just set it up so that when I use the dialer to run a USSD code that doesn't mean anything on my phone, this triggers what would ordinarily happen on a BT button press on autovoice - that is:

    When variable %WIN matches "USSD code running" -> Perform task with actions: "Input - back" and then Plugin - State - Autovoice - Recognise... or whatever it is you want.

    So that last action could be replaced by launching Voice Search if you want Google Now to take control.

    I've probably not explained that well at all, will post a proper how to if anyone's interested.
    1
    I use AutoVoice rather than Google Now, although any command not matched by AV I have sent to Google Now for processing.

    Anyway, there doesn't appear to be any faster way of communicating than via whatever it is that the Gear and my Note II communicate over by default. Not having the know-how to tap into this, I figured I would just use an existing method of communicating and use Tasker to intercept and pretend that was a BT button press instead.

    So what I've done is just set it up so that when I use the dialer to run a USSD code that doesn't mean anything on my phone, this triggers what would ordinarily happen on a BT button press on autovoice - that is:

    When variable %WIN matches "USSD code running" -> Perform task with actions: "Input - back" and then Plugin - State - Autovoice - Recognise... or whatever it is you want.

    So that last action could be replaced by launching Voice Search if you want Google Now to take control.

    I've probably not explained that well at all, will post a proper how to if anyone's interested.

    This is actually quite a clever work around, great thinking.