I have a BLE device which has a bunch of GATT services running on it. My goal is to access and read data from the service characteristics on this device from a Linux computer (BlueZ version is 5.37). I have enabled experimental mode - therefore, full GATT support should be available. BlueZ's DBUS API, however, only provides the org.bluez.GattManager1 interface for the connected device, and not the org.bluez.GattCharacteristic1 or org.bluez.GattService1 interfaces which I need. Is there something I'm doing wrong? The device is connected and paired, and really I've just run out of ideas as how to make this work, or what may be wrong.
If it helps, I'm using Python and the DBUS module to interface with BlueZ.
A system update resolved this problem.
Related
I have a device that I want to be able to communicate with serially. On Linux, I can see that when I plug in the device to my computer, I see that /dev/ttyUSB0 pops up, which I know to be the device; however, what I am not sure about is how would I go about finding out what port my device is connected to in the general sense? Say if I were to go to another machine and plug it in, or if I had multiple serial devices already plugged in to this computer; I wouldn't be able to rely on it always being /dev/ttyUSB0.
I plan on using PySerial to be communicate with the device (I couldn't find any other officially supported method with python to communicate with a serial device), and when you open a serial connection, you of course must specify the path to the device. On Windows it would be COM something, and Linux /dev/tty something. I want to be able to automatically find this out through the program. What is the best method to go about this?
Working with an Adafruit FTDI 232H Breakout assembly. I've already asked at Adafruit and FTDI and I'm still clueless. Writing in Python using the Adafruit-provided libraries and the FTDI libraries. Very new to Python and the FTDI 232H device...
Using Windows 10 Pro
I am able to successfully install the 'drivers' for the Adafruit based on this tutorial (specifically the Windows portion):
https://learn.adafruit.com/adafruit-ft232h-breakout?view=all
In the end, the interface will work, but what happens is that the device seems to be locked to a physical USB port. If I move the device to another USB port on the same machine, it is not recognized.
Based on some reading I've done, it seems like the driver, although installed in Windows, can only associate with the device on one port. Some say that Windows uses the serial number to keep track of what device uses what driver.
I have observed, using USBDView, that this device is not displaying a S/N. I have other devices that do not display a serial number and they can move from port to port without issue. This leads me to believe that the S/N tracking may not be 100% true in Windows. The Adafruit board does have a S/N in the EEPROM, but for some reason that information is not being provided to Windows / USBDView. I've not been able to successfully access the EEPROM via the FTProg utility.
I suspect that this might have something to to with the libusbK library that is installed via Zadig tool (again in the instructions) but I am not sure. FTDI says that there should not be any issue using the libusbK library.
Can anyone out there give me some pointers on:
Is it accurate that Windows uses the S/N to keep track of what driver goes with what device?
If so, how to get the FTDI device to display the S/N?
Is there some other setting in Windows that needs to be changed to allow this device to be used on other physical ports?
Is there any other utility like FTProg that could be used to work with the EEPROM?
Am I just missing something simple, Noob-style?
Thank you in advance,
I seem to recall a similar case related to COM port enumeration and Windows where the COM port enumeration is a hash of assorted variables including the PCI bus #, device #, etc. We witnessed this through the Microsoft devcon utility which is priceless and is a command line version of Device Manager.
https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon
https://blogs.technet.microsoft.com/deploymentguys/2009/12/16/where-to-find-devcon-exe/
If you google around, you can find the compiled version of this invaluable tool. With confidence, believe this tool will assist you to debug your USB port mystery. Good luck.
I have a python script to get plugged in device details. I am using udev library to manage the connected devices.
From my python script I want to check whether the plugged in device is hotpluggable or not. How can I find this using udev library.
Earlier I was using HAL library to manage device. In HAL I was able to get this information from 'storage.hotpluggable' property of HAL device.
Please help. Thanks in advance....
I'm implementing Bluetooth on an embedded device and have a few questions about the BlueZ protocol stack. I'm using BlueZ-4.101 (do not have the option to upgrade to BlueZ-5), and do not have Python available.
Here are my questions after spending some time looking into BlueZ:
Is bluetoothd needed in my situation? As in, is it just a daemon that handles Python dbus messages between user-space and the kernel, or is it more? I've looked through the source and can only find mostly dbus related calls
How does one determine the value of DeviceID in /etc/bluetooth/main.conf? I found these instructions (section 3.4), but they are for a different platform using BlueZ 5
Will sdptool work without setting the DeviceID value? I've tried the following command and receive timeouts every time (only for my local device):
# sdptool browse local
Browsing FF:FF:FF:00:00:00 ...
Service Search failed: Connection timed out
Is it viable to replace all of the python simple-agent scripts with libbluetooth instead, or do I need to try and port them over to a supported scripting language?
Any help would be greatly appreciated!!!
If more logs are needed I can try and get them.
I would like to write a driver to talk to my Suunto t3 watch in Python on a Mac. My day job is doing basic web work in C# so my familiarity with Python and developing on a Mac is limited.
Can you suggest how one would start doing driver development in general and then more specifically on a Mac. I.e. how to easily see what data is being transmitted to the device? I have Python 2.5 (MacPorts) up and running.
The Mac already has the underlying infrastructure to support USB, so you'll need a Python library that can take advantage of it. For any Python project that needs serial support, whether it's USB, RS-232 or GPIB, I'd recommend the PyVisa library at SourceForge. See http://pyvisa.sourceforge.net/.
If your device doesn't have a VISA driver, you'll have to deal with the USB system directly. You can use another library on SourceForge for that: http://pyusb.berlios.de/
If the watch supports a standard USB device class specification such as HID or serial communication, there might already be a Macintosh driver for it built into the OS. Otherwise, you're going to have to get information about the vendor commands used to communicate with it from one of three sources: the manufacturer; reverse engineering the protocol used by the Windows driver; or from others who have already reverse engineered the protocol in order to support the device on Linux or BSD.
USB is a packet-based bus and it's very important to understand the various transaction types. Reading the USB specification is a good place to start.
You can see what data is being transmitted to the device using a USB bus analyzer, which is an expensive proposition for a hobbyist but is well within the reach of most businesses doing USB development. For example, the Catalyst Conquest is $1199. Another established manufacturer is LeCroy (formerly CATC). There are also software USB analyzers that hook into the OS's USB stack, but they don't show all of the traffic on the bus, and may not be as reliable.
I'm not a Mac expert, so take this paragraph with a grain of salt: Apple has a driver development kit called the I/O Kit, which apparently requires you to write your driver in C++, unless they also have some sort of user-mode driver framework. If you're writing it in Python, it will probably be more like a Python library that interfaces to someone else's (Apple's?) generic USB driver.