org.bluez...ntMonitor(5)
β¨ NAME β¨
okay so welcome to the org.bluez...ntMonitor(5) page from the Linux System Administration manual πβ¨ this is literally your BlueZ D-Bus AdvertisementMonitor era, and we're gonna get through every detail together, bestie.
org.bluez.AdvertisementMonitor β BlueZ D-Bus AdvertisementMonitor API documentation π
π DESCRIPTION π
okay so this API lets a client specify a job of monitoring advertisements by registering the root of hierarchy and then exposing advertisement monitors under the root with filtering conditions, thresholds of RSSI, and timers of RSSI thresholds. no cap, that's the whole vibe.
Once a monitoring job is activated by bluetoothd(8), the client can expect to get notified on the targeted advertisements no matter if there is an ongoing discovery session (see StartDiscovery() in org.bluez.Adapter(5)). periodt π
π¦ INTERFACE π¦
Service
org.bluez
Interface
org.bluez.AdvertisementMonitor1 [experimental] β iykyk, it's experimental β¨
Object path
freely definable π«Ά
Used by
π οΈ METHODS π οΈ
void Release() [noreply]
This gets called as a signal for a client to perform clean-up when:
- Monitor cannot be activated after it was exposed
- Monitor has been deactivated.
not me being the clean-up crew π§Ήπ
void Activate() [noreply]
After a monitor was exposed, this gets called as a signal for client to get acknowledged when a monitor has been activated, so the client can expect to receive calls on DeviceFound() or DeviceLost(). slay, now you're officially in the group chat π
void DeviceFound(object device) [noreply]
This gets called to notify the client of finding the targeted device.
Once receiving the call, the client should start to monitor the corresponding device to retrieve the changes on RSSI and advertisement content. main character energy fr fr π
void DeviceLost(object device) [noreply]
This gets called to notify the client of losing the targeted device.
Once receiving this call, the client should stop monitoring the corresponding device. vibe check: device left the chat π
πΈ PROPERTIES πΈ
string Type [read-only]
The type of the monitor. See SupportedMonitorTypes in org.bluez.AdvertisementMonitorManager(5) for the available options. the way that this points you to the right place π
int16 RSSILowThreshold [read-only, optional]
Used in conjunction with RSSILowTimeout to determine whether a device becomes out-of-range.
Valid range is -127 to 20 (dBm), while 127 indicates unset. numbers stay exact, bestie β¨
int16 RSSIHighThreshold [read-only, optional]
Used in conjunction with RSSIHighTimeout to determine whether a device becomes in-range.
Valid range is -127 to 20 (dBm), while 127 indicates unset. highkey important π
uint16 RSSILowTimeout [read-only, optional]
The time it takes to consider a device as out-of-range. If this many seconds elapses without receiving any signal at least as strong as RSSILowThreshold, a currently in-range device will be considered as out-of-range (lost). Valid range is 1 to 300 (seconds), while 0 indicates unset. lost era, but make it timed β³
uint16 RSSIHighTimeout [read-only, optional]
The time it takes to consider a device as in-range. If this many seconds elapses while we continuously receive signals at least as strong as RSSIHighThreshold, a currently out-of-range device will be considered as in-range (found).
Valid range is 1 to 300 (seconds), while 0 indicates unset. found era, we love to see it πΈ
uint16 RSSISamplingPeriod [read-only, optional]
Grouping rules on how to propagate the received advertisement packets to the client.
Possible values:
0β All advertisement packets from in-range devices would be propagated.255β Only the first advertisement packet of in-range devices would be propagated. If the device becomes lost, then the first packet when it is found again will also be propagated.1to254β Advertisement packets would be grouped into100ms * Ntime period. Packets in the same group will only be reported once, with the RSSI value being averaged out.
Currently this is unimplemented in user space, so the value is only used to be forwarded to the kernel. important caveat, no cap π¨
array{(uint8, uint8, array{byte})} Patterns [read-only, optional]
If the Type property is set to "or_patterns", then this property must exist and have at least one entry in the array.
The structure of a pattern contains the following:
uint8 start_positionβ The index in an AD data field where the search should start. The beginning of an AD data field is index0.uint8 AD_data_typeβ See<https://www.bluetooth.com/specifications/assigned-numbers/>generic-access-profile/ for the possible allowed value.array{byte} content_of_patternβ This is the value of the pattern. The maximum length of the bytes is31.
patterns ate and left no crumbs ππ
okay bestie, that's the whole page, every option and property intact, no skips, no invented lore π«Ά
stay slay β this was BlueZ, October 2023, signing off πβ¨π
π¦ where this page comes from
- arch rolling: bluez-utils 5.87-2 Β· GPL-2.0-only
- nixpkgs unstable: bluez 5.87
- ubuntu stonking: bluez 5.87-4 Β· GPL-2.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms