From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: Mike Ryan <mikeryan@lacklustre.net>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: Automatically connect via DBUS Device API
Date: Wed, 12 Sep 2018 12:52:56 +0300 [thread overview]
Message-ID: <CABBYNZKOS1-654KQ_aUmOBChnBxbi9M3XRx3cemu3_gpkPiMBw@mail.gmail.com> (raw)
In-Reply-To: <20180911174520.g6mw2low6tcm7cvx@lacklustre.net>
Hi Mike,
On Tue, Sep 11, 2018 at 8:45 PM, Mike Ryan <mikeryan@lacklustre.net> wrote:
> It would be useful to have a way to automatically connect to previously
> discovered devices via the DBUS Device API.
>
> Current use case: I have BLE devices that become discoverable once they
> have a measurement available. Upon connecting, the measurement is
> notified/indicated and then the connection drops. Some of the devices
> with this behavior support/require pairing, and some do not support
> pairing/encryption.
>
> At present, the only options are to manually connect via DBUS or set the
> device to auto connect via the management API (using Add Device with
> Action set to 2). Since management is root-only, it would be useful to
> move this into DBUS.
Device.Connect should actually set the device to auto connect with use
of Add Device if there is a profile setting the auto_connect flag:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/device.c#n4305
Perhaps there is no matching service or you had not registered the
profile with RegisterApplication:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt#n355
> Possible workflow:
>
> 1. Discover devices as usual using StartDiscovery() on the adapter
> 2. Pair (if necessary)
> 3. Set new property AutoConnect = true
> 4. bluetoothd scans in background, connects when device becomes
> available
>
> One concern: a binary AutoConnect may not be sufficient considering the
> management API has three defined actions: background scan (generates an
> event, could be handled via a new Connectable property that generates a
> ProptertiesChanged event), allow incoming connection (connects on
> directed advertising), and auto-connect (connects even on indirect
> advertising).
Is there a use case where you would only connect when it is a directed
advertising vs connectable advertising?
--
Luiz Augusto von Dentz
prev parent reply other threads:[~2018-09-12 9:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-11 17:45 Automatically connect via DBUS Device API Mike Ryan
2018-09-12 9:52 ` Luiz Augusto von Dentz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABBYNZKOS1-654KQ_aUmOBChnBxbi9M3XRx3cemu3_gpkPiMBw@mail.gmail.com \
--to=luiz.dentz@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=mikeryan@lacklustre.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).