Under Bluez V5+ (Linux) cannot set up serial profile

[jmfloyd]

I have tried a many different approaches outlined by various posters in google. The only success has been by implementing a full dbus setup of profiles as outlined in

https://ukbaz.github.io/howto/AppInventor.htm

I can supply my working code that integrated this into BlueDot, allowing the server_debug example to run as is. I needed to add and change some methods in utils, btcomm and threads. My work seems to be stable and reliable after many exploratory diversions. It basically removed all the interactions with sockets. Note I have not touched the BluetoothClient class to remove the socket operations but also expect it not to work. The version of bluez (v5.52) in my desktop linux is the same as the current raspbian. I will be using this on a raspberry-pi in the near future.

Are you interested in this work? Can I send you the changed files?

[ukBaz]

Hi @jmfloyd,

Nice to hear you found my notes useful. Although the URL above has an "L" missing off the end. The correct URL is: https://ukbaz.github.io/howto/AppInventor.html

The approach that BlueDot uses and my notes are the same so I am a little surprise to see you say one works and the other doesn't. Do you have an error message of the issue? Do you have a fork or a gist with your changes in?

Thanks, Barry

[jmfloyd]

Barry, A quick reply thanks. The following should indicate my problem area.

My problem was setting up the serial profile and the necessary callback. The original BlueDot code resulted in errors on allocating or accessing RFCOMM ports. These errors were reported through btmon.

The difference was your approach using the dbus method to define the serial profile and create the call back to get all the RFCOMM connection handles, whilst the BlueDot code creates sockets and I think relies on the rfcomm command to set up the watch of the port. Your method is what the Bluez developers recommend ... but it is very hard to find the info on how to implement it.
I had investigated numerous but similar approaches that did not use dbus for the profile creation that all failed. Years ago I had used the rfcomm command in conjunction with socket programming to get BT communication working but things have changed.

The dbus methods have not been described fully or documented (where I could find it), until I found your description. Knowing a few major dbus keywords would have led me there eventually.

Anyway it is all working and much thanks to you. And seems quite logical. I have been using a bt-terminal on android to do the debugging. I also use bt device properties to keep an eye on whether the device is connected which works relatively well.

I hope this is not too vague.

Cheers John

[ukBaz]

Ah! OK. I think you are referring to providing the XML for a manual SDP record versus using the DBus API.

[jmfloyd]

Partly, it is more the way to define the NewConnection and other methods callbacks.  The NewConnection call back that gets the fd and device settings back out to the python program.  I had not seen this any else detailed.

Cheers John

[martinohanlon]

Hi @jmfloyd thanks for raising an issue and @ukBaz for providing some clarity.

Have you seen scenarios where BlueDot fails? Or are you just seeing issues reported in btmon? I have tested with the latest version of Raspbian and I dont see any "user level" issues. Although Raspbian is reporting I have got Bluez 5.50, clearly different to you at 5.52.

I would be interested in seeing the changes you made. The simplest way would be if you forked the bluedot repository, made the changes and sent me a pull request.

[jmfloyd]

MartinThanks for the response.  Yes I will create a fork with my changes.  I was wondering what the best way to do this.The issues resulted in a non functioning server with out a direct failure.  btmon was used to try to find the problem.  cheers JohnOn 21 Dec 2019 04:09, martinohanlon notifications@github.com wrote:Hi @jmfloyd thanks for raising an issue and @ukBaz for providing some clarity. Have you seen scenarios where BlueDot fails? Or are you just seeing issues reported in btmon? I have tested with the latest version of Raspbian and I dont see any "user level" issues. Although Raspbian is reporting I have got Bluez 5.50, clearly different to you at 5.52. I would be interested in seeing the changes you made. The simplest way would be if you forked the bluedot repository, made the changes and sent me a pull request.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[martinohanlon]

Ok. I cant replicate an error using bluez 5.50 on the latest version of Raspbian.

If you need some guidance creating a fork and committing I would be happy to help.

[jmfloyd]

I am doing a rewrite at the moment using BlueZero (by ukbaz) which is much more object orientated. But the issue is relevant to the BlueDot approach.

[martinohanlon]

I am going to close this issue as I can't replicate any problems with the current approach in BlueDot. @jmfloyd if you have an alternative you could send as a PR I would be interested in seeing it.