look int latest developments in bluepy to see if we can replace pexpect + gatttool

[roscopetracula]

the bluepy project has had a few updates since i last checked it out (dec 2014). at that time i couldn't get it working, but maybe the situation has now improved. https://github.com/IanHarvey/bluepy

[jef-pearlman]

I did a little work on directly integrating bluepy this Sunday, and got it connecting but couldn't successfully send messages. My current best bet is that I haven't got the right Characteristic for transmission. I may not try again for a bit, and when I do I'm going to start with a separate test program, so anyone should feel to give it a try. I can push what I've done on a branch, but frankly I think you'd be better off starting from scratch. Here are my observations, for my later recall or to help others:

• bluepy uses a natively-compiled helper app. It's essentially like gatttool except with more features and much more structured so its input/output can be from/to a library. So overall, I think it's still a net win over gatttool/expect, if it works.
• Connecting worked pretty easily out of the box. The RFduino saw the connection.
• Sending the first message (and the second, see below) generally produces no error, but the RFduino does not see it.
• Some combination of sending a second message and possibly other commands (I'm using status()) causes a crash. It appears to be a broken pipe in a write(), apparently sending the command to the helper app. This suggests that it is likely that the helper app has crashed. My current best guess based on the patterns I've seen is that the second write/send causes the app to crash and the connection to close, and the first command after that crashes the app when attempting to write the closed socket.
• The version of bluez (5.4) used by bluepy is two years old. Have not looked into whether you can just drop in a replacement or that is contributing to the problems.
• One thing I might try is getting the app to cause a core dump and try to debug it. Or I may instrument bluepy a little.

[jef-pearlman]

Update: I got transmission working, so it's more or less working the same as it did with gatttool. Who can I talk to about the best way to include a library like bluepy (particularly with an associated binary) both in python and in github?

Some more learnings:

• It seems like the easiest way to find the right characteristic in bluepy is the uuid ("2222" for transmission) rather than the value used with gatttool (0x0011, which I think is the handle).
• Unlike gatttool, the bluepy write() command takes raw binary data rather than hex encoded data.
• The source of the crash was the first message sent. Because I hadn't yet accounted for the hex encoding, sent messages were both incorrectly formed for the receiver and double-length (because the hex-encoded data is actually what got sent). That all said, I can't think of why the double-length message would cause a crash. I haven't dug into the code to look for a cause, so I'm just flagging it as something to watch out for as we play more and as messages potentially get longer.
• I'm working on getting notifications and reception working. As of now, no notifications are being received.
• Sometimes the helper app (bluepy-helper) does not die when the python interface closes. As a result, it stays connected, and subsequent python interface launches cannot connect and bail. Doing a "killall bluepy-helper" is a workaround, but this is not great in the long term and should be addressed.

[jef-pearlman]

Initial implementation d767837e696a6427fdef9646485cfba2a8603b6e. Subsequent additions and fixes are on using_bluepy branch.

[jef-pearlman]

Working and stable.