Still asking about BLE devices and gatttool.
I'm able to send a char-write-cmd in interactive mode, but I'm not able to do the same in non-interactive.
This is what I send in interactive mode :
gatttool -I
[]> connect BTADDR
[BTADDR]> char-write-cmd 0x0040 01
[BTADDR]> exit
In this way I start the Alert service, which in my case makes the buzzer sounds.
In theory, the non-interactive mode should be:
gatttool -b BTADDR --char-write -a 0x0040 -n 01
But this do not send the request command event to the board, I'm checking it using a dev board.
The manual (non-interactive) way to read or write to your BLE peripheral:
To write and receive reply once: (depending on how you configure your BLE device)
sudo gatttool -i hci0 -b xx:xx:xx:xx:xx:xx --char-write-req -a 0x0025 -n ff
To write and receive reply indefinitely: (Until you disconnect from BLE device or stop your Bluetooth client)
sudo gatttool -i hci0 -b xx:xx:xx:xx:xx:xx --char-write-req -a 0x0025 -n ff --listen
Notice I only added the --listen option at the end. This mechanism only works if you configure your BLE node (sensor or actuator) to read and reply.
sources::
How to use gatttool non-interactive mode
Bluetooth Low Energy: listening for notifications/indications in linux
All that said, I still do not think it is best to control or get values from a BLE device. My direction is to move forward and use an API (maybe in python) to do the job for you.
https://github.com/peplin/pygatt
This API has been proven to work with Raspberry Pi Jessie destro.
Related
Getting status of serial ports (ttyS*) via linux terminal is simple:
sudo cat /proc/tty/driver/serial
Then it shows serinfo with list of all uarts with info about status and buffers. When I call
sudo cat /proc/tty/drivers
then I can see that rfcomm drivers are available:
rfcomm /dev/rfcomm 216 0-255 serial
And, of course, reading data comming from paired bluetooth device is not a problem.
The question is: how to get status of rfcomm serial ports (e.g. Blueotooth SPP devices)? Is this information available somewhere in the /proc directory like for ttyS* or could I use totally different way?
It depends what status you are looking for. The "rfcomm" command that comes with bluez does have some status info. It depends if that is adequate for you.
% rfcomm -h
RFCOMM configuration utility ver 4.101
Usage:
rfcomm [options] <command> <dev>
Options:
-i [hciX|bdaddr] Local HCI device or BD Address
-h, --help Display help
-r, --raw Switch TTY into raw mode
-A, --auth Enable authentication
-E, --encrypt Enable encryption
-S, --secure Secure connection
-M, --master Become the master of a piconet
-f, --config [file] Specify alternate config file
-a Show all devices (default)
Commands:
bind <dev> <bdaddr> [channel] Bind device
release <dev> Release device
show <dev> Show device
connect <dev> <bdaddr> [channel] Connect device
listen <dev> [channel [cmd]] Listen
watch <dev> [channel [cmd]] Watch
I've just got a smart led bulb from Zengge and want to control it from my Linux machine with Bluetooth 4.0. I've installed latest bluez 5.x package, so I have a gatttool available. I am able to connect to my bulb and list it's services. But I have no ideas how to control it. Maybe someone have already done that (I was unable to Google for ready solution)? Or have some developments in this area? Or maybe someone have the specs?
For those who are interested, here are my findings about the bulb protocol.
1) Check if your bluetooth device is up: hcitool dev
2) If device is down: hciconfig hci0 up
3) Scan for bluetooth le devices: hcitool lescan
4) Turn on device: gatttool -b YOUR:LE:DEVICE:MAC:ADDRESS --char-write-req -a 0x001a -n 04
5) Turn off device: gatttool -b YOUR:LE:DEVICE:MAC:ADDRESS --char-write-req -a 0x001a -n 63
6) Dim warm light: gatttool -b YOUR:LE:DEVICE:MAC:ADDRESS --char-write-req -a 0x0013 -n 56000000ff0faa where ff is the hex code for the intensity.
7) Colored light: gatttool -b YOUR:LE:DEVICE:MAC:ADDRESS --char-write-req -a 0x0013 -n 56e92fff99f9aa where e9 is hex red intensity, 2f is hex green intensity, 2f is hex blue intensity
(I'v got the codes by turning on the Bluetooth HCI-snoop-log in Android wile using the Magic Light app and analysing it with Wireshark)
Hello is there any way to get the signal strength of near by bluetooth le devises in linux? Or any good libraries for nodejs, php or mono (I do know some c++ or python but would prefer to say away from them) if a tool does not exisst but would be fairly easy to write.
On Linux, the way to do this is with the hcitool command. However, you have to be connected to get the rssi of a device. If you want to achieve this from the command line, try:
#hcitool rssi AA:BB:CC:DD:EE:FF
If you want to see the actual C code to achieve this, take a look at the bluez tools/hcitool.c file, under the cmd_rssi function.
static void cmd_rssi(int dev_id, int argc, char **argv)
{
...
}
For Bluetooth Low Energy, I only know one way to do this, and that is using the #btmon command. Run btmon in the background then scan for Bluetooth Low Energy devices:
#./btmon &
# hcitool lescan
The results displayed on the monitor should be similar to this:
> HCI Event: LE Meta Event (0x3e) plen 12
LE Advertising Report (0x02)
Num reports: 1
Event type: Scan response - SCAN_RSP (0x04)
Address type: Public (0x00)
Address: AA:BB:CC:DD:EE:FF (<Vendor Name>)
Data length: 0
***RSSI: -34 dBm (0xde)***
AA:BB:CC:DD:EE:FF <Device Name>
Note that when using btmon you do not have to connect to get the rssi of a BLE device.
No need to connect when using btmgmt
$ sudo btmgmt find
Discovery started
hci0 type 7 discovering on
hci0 dev_found: 50:8C:FD:99:0A:EC type LE Random rssi -80 flags 0x0000
AD flags 0x06
eir_len 23
…
The relative signal strength indicator is rssi -80, but the list is much longer containing more information about this and other devices.
To spy on your Bluetooth neighbourhood showing only unique MAC addresses with their strongest RSSI, run the following command:
$ sudo btmgmt find |grep rssi |sort -n |uniq -w 33
hci0 dev_found: 40:43:42:B3:71:11 type LE Random rssi -53 flags 0x0000
hci0 dev_found: 44:DA:5F:EA:C6:CF type LE Random rssi -78 flags 0x0000
hci0 dev_found: 7F:7D:08:6B:E0:37 type LE Random rssi -74 flags 0x0000
hci0 dev_found: A4:58:0F:21:A1:8C type BR/EDR rssi -79 flags 0x0000
You can use a combination of:
sudo hcitool lescan --duplicates & ;
sudo hcidump --raw
that will provide you the raw dump of all the bluetooth packets which contain all relevant information you must be interested in such as : UUID, Major, Minor, RSSI, TxPower. You will have to run some kind of script to parse and filter LE packets and make them into readable form.
One of the scripts written with Bash and S editor was provided by jjnebaker here with the problem and solution discussed here
The Other option is to use PyBluez using the example code here
But you might find the solution provided by Switchdoc labs useful according to your needs as well. here
This works for c language, but has an error when casting the bytes that have the information about de rssi signal.
https://github.com/glock45/intel-edison-playground/blob/master/scan.c
this line 121:
printf("%s - RSSI %d\n", addr, (**char**)info->data[info->length]);
should be:
printf("%s - RSSI %d\n", addr, (**int8_t**)info->data[info->length]);
I found these by looking inside bluez-version/monitor/*.c, where btmon program is. You can see the data types and structs, hcidump.c is very useful and packets.c, and main.c too, but there are many to learn about the hci sockets.
I also found a program I was able to edit to do what I wanted as well
I through it up on my github account
https://github.com/tholum/bluez/blob/master/blue.py
i found several solutions, but most were too slow for my needs to use as a tracking function.
check out https://github.com/abandonware/noble containing some examples.
my standalone scanner is also based on abandonware's module and can be found here:
https://github.com/efeuentertainment/BLE-continuous-RSSI-scan
node index.js BLEMAC
continuously lists the RSSI with an update frequency of about 2 per second / depending on BLE device.
also fast updates based on bash is:
sudo hcitool lescan --duplicates &
combined with one of the following lines:
continuous updates
sudo hcidump | grep "E6:4E:57:09:74:E4" -A 4
sudo btmon | grep "E6:4E:57:09:74:E4" -A 7
only the next received update
sudo hcidump | grep -m 1 "E6:4E:57:09:74:E4" -A 4 | grep "RSSI"
sudo btmon | grep -m 1 "E6:4E:57:09:74:E4" -A 7 | grep "RSSI"
hope that helps. it's an old thread but my search engine lead me here anyway.
try :
$ bluez-test-discovery
output :
[ 18:7A:93:05:E4:B1 ]
Name = AMIYJ_E4B1
Paired = 0
LegacyPairing = 0
Alias = AMIYJ_E4B1
Broadcaster = 0
UUIDs = dbus.Array([dbus.String(u'0000fff0-0000-1000-8000-00805f9b34fb')], signature=dbus.Signature('s'), variant_level=1)
Address = 18:7A:93:05:E4:B1
RSSI = -65
Class = 0x000000
gives you : RSSI = -65
For connected devices you can use btmgmt conn-info
e.g.
$ sudo btmgmt conn-info -t 2 E4:0C:E6:59:B6:FC
Connection Information for E4:0C:E6:59:B6:FC (LE Random)
RSSI -78 TX power 0 maximum TX power 0
(You have the code for that command at https://github.com/bluez/bluez/blob/150bbff449c787f26b7de3e6006bdb2ea6365b08/tools/btmgmt.c#L3984-L4030 ).
I think you may also be able to use BlueZ's DBus RSSI property of the org.bluez.Device1 interface :
int16 RSSI [readonly, optional]
Received Signal Strength Indicator of the remote
device (inquiry or advertising).
but that didn't work for me:
$ dbus-send --print-reply=literal --system --dest=org.bluez /org/bluez/hci0/dev_E4_0C_E6_59_B6_FC org.freedesktop.DBus.Properties.Get string:"org.bluez.Device1" string:"RSSI"
Error org.freedesktop.DBus.Error.InvalidArgs: No such property 'RSSI'
Maybe because the property is optional. Some other properties did work for me:
$ dbus-send --print-reply=literal --system --dest=org.bluez /org/bluez/hci0/dev_E4_0C_E6_59_B6_FC org.freedesktop.DBus.Properties.Get string:"org.bluez.Device1" string:"Name"
variant eono BTC 01
Within a bash script, I use the following:
$ stty -F /dev/ttyUSB0 921600 raw
$ echo -n "some test data" >/dev/ttyUSB0
and it works as expected.
Using a PL2303 USB to RS232 adapter:
$ lsusb
...
Bus 006 Device 010: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 006 Device 011: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Now I tried to do the same with 1 MBd, but got an error:
$ stty -F /dev/ttyUSB0 1000000 raw
stty: /dev/ttyUSB0: unable to perform all requested operations
Also the same message when I try with 500 kBd. Trying 250 kBd the error message is different:
$ stty -F /dev/ttyUSB0 250000 raw
stty: invalid argument `250000'
Try `stty --help' for more information.
As seen here, it's a problem in the PL2303 linux driver.
I'm working on Kubuntu 12.04, 32 Bit. Unfortunally, I don't know how to fix that driver on my system (getting driver source, patch em, compile, install … hmm, maybe I learn a bit and give it a try - advice is welcome).
But maybe there is an updated driver avaliable which is easy to install?
Or does someone know an alternate USB to RS232 adapter which works at 1 MBd (hardware flowcontrol via rts/cts is needed, which works pretty well with the PL2303)?
After the realization that »Prolific and FTDI are competitors«, I bought Ftdi US232R-10 which is a FT232R based device and specified for 1 MBd transfer rate.
With this adapter I'd successfully tested communication at 1 MBd by transfering some GiB data without any error (including usage of Rts/Cts hardware flow control).
Configuring this device using stty like:
$ stty -F /dev/ttyUSB0 1000000 raw
works successfully.
I'm trying to communicate with a BLE module through a Linux machine (the module is running a heart rate profile). So far, I've been able to do everything I need except listening for Notifications and indications (e.g. listening for the Heart Rate Measurement Notification). I'm using kernel version 3.5 and bluez-5.3.
Succcessful commands used so far:
hcitool lescan
hcitool lecc
gatttool -b <Mac Address> --primary
gatttool -b <MAC Address> --characteristics
gatttool -b <MAC Address> --char-read
gatttool -b <MAC Address> --char-desc
gatttool -b <MAC Address> --interactive
Failed commands:
gatttool -b <MAC Address> --listen
Any help is greatly appreciated.
Try this...
Run gatttool -b <MAC Address> --interactive like you did before. You'll get a prompt and then you type connect. You should see a CON in the prompt indicating that you've connected to the device. Then type char-read-uuid 2902. You should get a list of all CCC (Client Characteristic Configuration) attributes on the device. You can try setting them all to 0100 to get notifications, 0200 for indications, 0300 for both, or 0000 for everything off. Type help to see all the commands and their arguments.
EDIT:
The use of the --listen argument requires you to couple it with other commands to turn on the notifications and/or indications. So here's an example that works in Bluez 4.101:
gatttool -b <MAC Address> --char-write-req --handle=0x0031 --value=0100 --listen
Obviously you need to change the handle to the handle of the CCC that you want to turn on notifications for. However, I still find it way easier to just use the interactive mode.
Looks like the older version of Bluez (hcitool & gatttool) don't allow you to write to Bluetooth Low Energy devices. I ended up installing a newer version (5.17 as of this writing) in order to enabled notifications, etc.
To get a list of all your handles you can run the following:
char-desc
You can then read from a handle:
char-read-hnd 0x000e
(the above handle is for my nrf51822 battery level)
Where the handle is one from the list you got from char-desc.
Just like Tim said above, you can write to the notification related handle to get indications or notifications. (in my case my device only had notifications)
char-write-req 0x000f 0100
(the above handle is for my nrf51822 battery level notification)
In my case the battery notification shouldn't send anything until the battery level has changed.
I wrote a pretty lengthy blog post on getting setup with Bluez. You can find it here: Get Started with Bluetooth Low Energy Feel free to check it out!
Final answer for reading heart rate on Mio Alpha :
gatttool -b xx:xx:xx:xx:xx:xx -t random --char-write-req -a 0x0025 -n 0100 --listen
Characteristic value was written successfully
Notification handle = 0x0024 value: 10 4b 33 03
Notification handle = 0x0024 value: 10 4b 33 03
Notification handle = 0x0024 value: 10 4b 33 03
Notification handle = 0x0024 value: 10 4a 3e 03
Notification handle = 0x0024 value: 10 4c 28 03 28 03
Notification handle = 0x0024 value: 10 4c 28 03
Notification handle = 0x0024 value: 10 4b 33 03
Notification handle = 0x0024 value: 10 4a 3e 03 3e 03
to retain the CCC value you need to pair the two device. once they are paired you do not need to set the CCC again. on next reconnection it will find the setting , which will be saved in thec FLASH of Key fob. try to configure after pairing via SMP.