I need to develop an application with a bluetooth dongle that makes use of the thermometer profile. The thing is that, after succesfully pair and connect with the remote device, whenever I try to run the test-therometer file, I obtain the following error:
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "RegisterWatcher" with signature "s" on interface "org.bluez.ThermometerManager1" doesn't exist
I have also tested the test-heartrate, and I obtain something similar:
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "RegisterWatcher" with signature "s" on interface "org.bluez.HeartRateManager1" doesn't exist
I have successfully tested the dongle with bluetoothctl, so I can discard hardware compatibility issues. I'd like to know if I'm missing something while running the tests.
I'm working under ArchLinux x86_64.
Related
I'm trying to get a GATT client working on a Linux system that's running BlueZ 5.19. Unfortunately, neither Python or glib are available on this system, so my only choice is using libdbus. And did I mention that I've never used D-Bus before? I have a GATT server on another system that provides and advertises a custom service by its 16-byte UUID. I'm trying to get my BlueZ-based system to access this service. I've verified that I can discover the server by the UUID that it advertises, and I can get BlueZ to connect to it. My client app has successfully called Bluez's RegisterProfile method, passing the UUID advertised by the server, but BlueZ never calls my NewConnection method. In the options of the RegisterProfile call, I'm setting "Role" to "client", "AutoConnect" to TRUE, and both "RequireAuthorization" and "RequireAuthentication" to FALSE. I am running bluetoothd with the -E (experimental) option.
If I run bluetoothd in the foreground with both the -E and debug option, this is what I see when I start my client app:
bluetoothd[2126]: src/profile.c:register_profile() sender :1.20
bluetoothd[2126]: src/profile.c:create_ext() Created "myRemoteControlProfile"
bluetoothd[2126]: src/profile.c:ext_device_probe() myRemoteControlProfile probed with UUID 119649b6-b656-22ae-e611-ba85a04effc5
bluetoothd[2126]: src/service.c:change_state() 0x950d0: device 24:71:89:09:AD:09 profile myRemoteControlProfile state changed: unavailable -> disconnected (0)
"myRemoteControlProfile" is the name of the profile I registered with Bluez, "119649b6-b656-22ae-e611-ba85a04effc5" is the UUID that I passed in the RegisterProfile call and 24:71:89:09:AD:09 is the GATT server I'm trying to interact with, so BlueZ seems to know that this remote device provides the service I'm looking for. When I watch on the server device, I never see BlueZ connecting to it. Isn't BlueZ supposed to connect to a device when it sees that the device offers the service that I passed in RegisterProfile? Why don't I get a NewConnection method call? What does it mean that my registered profile never gets past the "disconnected" state? I know that the GATT API was still considered experimental in BlueZ 5.19; should I even expect this to work? Thanks!
BTW, this problem is nearly identical to the one described in https://stackoverflow.com/questions/36480516/bluez5-37-org-bluez-profilemanager1-registerprofile-cant-detect-green-throttle . Unfortunately, no answers were offered there.
I've been able to work around this problem by upgrading to BlueZ 5.43. I still don't get a NewConnection method call, but if I detect the remote device by the UUID of the service it advertises and connect to it manually, all of the characteristics of the service now appear when I do GetManagedObjects on org.bluez, which didn't happen in BlueZ 5.19.
I have wifi module as client that connected to my router (linux based firmware, Openwrt).
And sometime, i need to retrieve GPIO state from wifi module. It can be done simply by connect in to usb serial and type
print (gpio.read(1))
It will return value 1 or 0. Active or not.
The thing is, can i save the value of gpio to my openwrt through telnet?
Using ash or bash maybe?
I've succesfully connected to wifi module using telnet and execute command via telnet.
Many thanks :)
Note :
-my module wifi is esp8266-07,
-Router HW Echolife HG553 (openwrt,Debian based linux)
Linux doesn't provide us with any "standardtized" solution.
You would need to implement some kind of interface, e.g. service that will read data and make nicely structured JSON file, which is shared over HTTP, so you can read and parse it.
I'm trying to set up a connection to a Bluetooth 4.0 LE device on Linux using the BlueZ 4.X DBus interface.
To test this I use the following command:
dbus-send --system --dest=org.bluez --print-reply /org/bluez/<PID of bluetoothd>/hci0 org.bluez.Adapter.CreateDevice string:<MAC of BT device>
This command seems to work most times, giving a result like:
method return sender=:1.238 -> dest=:1.262 reply_serial=2
object path "/org/bluez/9652/hci1/dev_BC_6A_29_26_C2_1C"
and enabling me to interact with the device DBus object.
However, starting from yesterday, this seems to fail very frequently returning the following error:
Error org.bluez.Error.Failed: Operation canceled
When debugging the bluetooth daemon, (using bluetoothd -n -d) I notice the following things when executing the method call:
bluetoothd[340]: src/adapter.c:create_device() BC:6A:29:26:C2:1C
bluetoothd[340]: src/adapter.c:adapter_create_device() BC:6A:29:26:C2:1C
bluetoothd[340]: src/device.c:device_create() Creating device /org/bluez/340/hci0/dev_BC_6A_29_26_C2_1C
bluetoothd[340]: src/device.c:btd_device_ref() 0xb7ad8: ref=1
bluetoothd[340]: src/device.c:device_set_temporary() temporary 1
bluetoothd[340]: src/device.c:btd_device_ref() 0xb7ad8: ref=2
bluetoothd[340]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[340]: plugins/mgmtops.c:mgmt_event() Received 14 bytes from management socket
bluetoothd[340]: plugins/mgmtops.c:mgmt_connect_failed() hci0 BC:6A:29:26:C2:1C status 4
bluetoothd[340]: src/event.c:btd_event_conn_failed() status 0x04
bluetoothd[340]: src/device.c:device_remove() Removing device /org/bluez/340/hci0/dev_BC_6A_29_26_C2_1C
bluetoothd[340]: src/device.c:device_set_temporary() temporary 1
bluetoothd[340]: src/device.c:btd_device_unref() 0xb7ad8: ref=1
bluetoothd[340]: src/device.c:btd_device_unref() 0xb7ad8: ref=0
bluetoothd[340]: src/device.c:device_free() 0xb7ad8
As far as I can see, my Bluetooth dongle sends me an error event (status 4) when I try to connect to the device.
However, when I use hcitool ot gatttool to connect to the device, everything works perfectly.
I found that this happens mostly after I try to connect to the device using a different program (i.e cinnamon-settings), and cancel the connection prematurely. I also noticed this with other programs like bluetooth-properties on Angstrom.
My guess is that Bluez sends the wrong HCI commands to my bluetooth dongle in certain conditions. I think this is because the gui programs try to pair with the device instead of just connecting to it, which may cause BlueZ to think my device is a Bluetooth 2.0 device.
Thus far I seemed to be able to resolve this problem by connecting to my BT device using a gui application, waiting till it fails, and restarting my computer. However, the problem seems to reoccur occasionally, making this very painful.
I have seen this problem on systems running both BlueZ version 4.99 and 4.101.
Does anyone know how I can solve this correctly?
It seems like my predictions where more or less correct. After many hours of debugging the Bluetooth daemon I discovered that connecting to BT LE devices without a preliminary scan causes the daemon to try to connect to the device as a BR/EDR device. This is because the daemon's "internal cache" is filled with the EIR information at the time the device is discovered. If this information is not available when connecting to a LE device the CreateDevice method will fail.
A simple solution is to always make sure to discover devices before connecting to them.
The BlueZ 5 API introduction and porting guide also describes this problem, and how it is solved in BlueZ 5:
Bluetooth Low Energy essentially extended Bluetooth addresses with one extra bit, requiring one to always know whether an address is “random” or “public”. This caused issues with the BlueZ 4 API where the address was given to BlueZ in the CreateDevice and CreatePairedDevice calls. Since the parameter didn’t contain any of this extra random/public information bluetoothd had to maintain an internal cache to look up the necessary info. Another complication to the matter is that the BlueZ D-Bus API doesn’t differentiate between traditional BR/EDR devices and LE devices so there are essentially three possible address types: BR/EDR, LE public and LE random.
I am trying to create some scripts to discover and pair bluetooth devices on a embedded arch linux platform and seem unable to get any replies to dbus-send commands.
The error message is pretty much always the same (method does not exist), however the syntax of the send appears to be correct.
I have googled and searched here for the correct syntax and the errors, but have been unable to find any solutions.
[root#alarmpi ~]# dbus-send --system --dest=org.bluez --print-reply / org.bluez.Manager.GetProperties
Error org.freedesktop.DBus.Error.UnknownMethod: Method "GetProperties" with signature "" on interface "org.bluez.Manager" doesn't exist
[root#alarmpi ~]# dbus-send --system --print-reply --dest=org.bluez /org/bluez/134/hci0 org.bluez.Adapter.GetProperties
Error org.freedesktop.DBus.Error.UnknownObject: Method "GetProperties" with signature "" on interface "org.bluez.Adapter" doesn't exist
Bluez is installed, and I can use the hcitool and bluetoothctl utilities to manually discover and pair devices, however that method is not workable for an end-user and I need to create a web interface for them to perform the discovery and pairing.
It seems that dbus is the preferred method for doing this, as bluetoothctl does not accept command line arguments to allow it to pair a device address.
Any help / suggestions would be much appreciated.
Verify that bluetoothd is running,
Install a program called d-feet which is a D-Bus debugger and see if the org.bluez is present on the system bus tab,
If it is navigate to the destination Object, Interface and Method which is "/", "org.bluez.Manager" and "GetProperties" respectively,
Double click the method name (GetProperties) and click execute without any arguments
The output should be something like {u'Adapters': ['/org/bluez/709/hci0']}, if it's not - you have a problem with your bluetoothd,
Btw. your command is correct.
We have a custom embedded device that uses Roving Networks' RN240 bluetooth adapter on an RS232 port to communicate with another device via bluetooth. It is working well, but I am attempting to "bulletproof" the management of the bluetooth connection as there is an occasional hiccup and I need to handle these circumstances.
In the flow I'm working on, I put the adapter into Command mode and get back the proper response:
> CMD
< $$$
I am then able to issue commands to it to Get or Set information. One of the things we do is specify which bluetooth device to pair to using these commands. The device may already have a valid pairing, and is set to Auto Master mode. When the device powers up, it may automatically connect to our other bluetooth device (as designed). I need to know if the dongle has paired when I am attempting to perform certain functions.
The command set specification specifically says that when the Get command
> GK
< 1
is sent to the device (to obtain current connection status), it will respond with a "0" for "Not Connected" or "1" for "Connected"
I am occasionally getting a "4" when the device is either connecting or connected, and I've been unable to isolate why. Once I start getting a "4", I keep getting a "4" every time I inquire after that. I have to power down the dongle (ie: reset my test scenario) to get a different behavior.
I've poked through other Advanced User Guides on Roving Networks' website, and googled as many variations as I can think of to find what this status means. It seems when I get back "4", I can no longer control the Bluetooth Adapter as I need to. I would like to know what "4" means, and what I can do to recover the device so I can make it do what I want to!
Thanks! I appreciate any help.
(For reference, here's the page for this adapter, along with links for downloading the command set: Roving Networks RN240 Bluetooth Adapter)
EDIT: I have heard back from Microchip Engineering Support. Their answer was that "4" is an undocumented state, as it shouldn't be visible to the user. "4" means the chip in in a connecting state, and that if the module is getting into this state, it is recommended that the module be rebooted (with the "R,1" command).