Support python 3.4 about bluepy

[IanHarvey]

Thanks, if you send a pull request I'll give it a test and merge it.

Ideally the code will work on both 2.7 and 3.x, but if it can't easily be fixed I'd like to avoid having to write shims for compatibility. The Raspberry Pi standard distro (where this all started) is still on 3.2.3, so it might be different again to 3.4. If it gets too bad I'll have to fork it.

[kalfa]

Hi Ian,
sure. I'm still working on it. I'm working to incorporate bluepy in a
asyncio transport, this is my ultimate objective, so I'll wait a bit for a
pull request.

I'll try to test it on 3.2.3 as well, although I don't have a sensor tag,
just a sensirion humitity/temperature chip, which behaves slightly
different from the one in the ST. So I'll add some classes.

I'll try to keep the changes for py3 and for some refactoring I'm doing
separate, so if you don't like the refactoring, you can still keep the py3
compatibility branch.

It might take some time, sorry. I just wanted to notify you I'm working on
it.

cheers,
Cosimo.

On 16 June 2014 18:08, Ian Harvey [email protected] wrote:

Thanks, if you send a pull request I'll give it a test and merge it.

Ideally the code will work on both 2.7 and 3.x, but if it can't easily be
fixed I'd like to avoid having to write shims for compatibility. The
Raspberry Pi standard distro (where this all started) is still on 3.2.3, so
it might be different again to 3.4. If it gets too bad I'll have to fork it.

—
Reply to this email directly or view it on GitHub
#5 (comment).

[BrianAtLonmed]

Hi guys,
I run btle.py on python 3.4.1(rPi+ bluez5.4) and the DBG as following:

---

pi@raspberrypi ~ $ python3 work/bluepy/bluepy/bluepy/btle.py e0:c7:9d:5e:4a:9c
Connecting to: e0:c7:9d:5e:4a:9c
Running /home/pi/work/bluepy/bluepy/bluepy/bluepy-helper
Sent: conn e0:c7:9d:5e:4a:9c

Got: '# bluepy-helper.c built at 13:33:00 on Sep 4 2014\n'

---

and it hung on there and bt dongle had no response ( LED light had no flash), but it run well on python 2.7 llke this , even had another error 📦

---

pi@raspberrypi ~ $ python work/bluepy/bluepy/bluepy/btle.py e0:c7:9d:5e:4a:9c
Connecting to: e0:c7:9d:5e:4a:9c
Running /home/pi/work/bluepy/bluepy/bluepy/bluepy-helper
Sent: conn e0:c7:9d:5e:4a:9c

Got: '# bluepy-helper.c built at 13:33:00 on Sep 4 2014\n'
Got: "rsp=$stat state=$tryconn dst='e0:c7:9d:5e:4a:9c mtu=h0 sec='low\n"
Got: "rsp=$stat state=$conn dst='e0:c7:9d:5e:4a:9c mtu=h0 sec='low\n"
<main.Peripheral instance at 0xb6ac6968>
Sent: svcs

Got: 'rsp=$ntfy hnd=h2A d=bA55A\n'
Sent: disc

Got: "rsp=$stat state=$disc mtu=h0 sec='low\n"
Stopping /home/pi/work/bluepy/bluepy/bluepy/bluepy-helper

(process:3227): GLib-CRITICAL **: g_io_channel_read_chars: assertion 'channel->is_readable' failed
Traceback (most recent call last):
File "work/bluepy/bluepy/bluepy/btle.py", line 399, in
for svc in conn.getServices():
File "work/bluepy/bluepy/bluepy/btle.py", line 262, in getServices
self.discoverServices()
File "work/bluepy/bluepy/bluepy/btle.py", line 248, in discoverServices
rsp = self._getResp('find')
File "work/bluepy/bluepy/bluepy/btle.py", line 219, in _getResp
raise BTLEException(BTLEException.INTERNAL_ERROR, "Unexpected response (%s)" % respType)
main.BTLEException: Unexpected response (ntfy)

---

any idea?!

[kalfa]

@BrianAtLonmed is the last trace for 2.7 or 3.4.1?

The first problem seems to be something I encountered while adapting the code to 3.4, I need to remember what it was though 😄 . I'll try it out on a device of mine later today, hopefully I'll be able to reproduce it.

The last issue seems, but I'm quite ignorant 😄 in that, that he received a notification which the helper 'passed up' to the script. Being it an async notification it got in the way of the normal state the automata was expecting. If it's the case I'll pass the ball to Ian for the last one.

[BrianAtLonmed]

@kalfa first problem trace is for 3.4.1, last one is for 2.7.

The issue for notification maybe I can resolve it , but it's for python2.7 and I prefer python3.

[IanHarvey]

It's looking like the second problem could be that the device is sending us a notification, which we're not expecting so report it as an error.

I'm out of the country at the moment so I can't do much now, but I can suggest a patch to just drop notifications when I get back.

Thanks,
Ian

Sent from my iPod

On 4 Sep 2014, at 02:05, Cosimo Alfarano [email protected] wrote:

@BrianAtLonmed is the last trace for 2.7 or 3.4.1?

The first problem seems to be something I encountered while adapting the code to 3.4, I need to remember what it was though . I'll try it out on a device of mine later today, hopefully I'll be able to reproduce it.

The last issue seems, but I'm quite ignorant in that, that he received a notification which the helper 'passed up' to the script. Being it an async notification it got in the way of the normal state the automata was expecting. If it's the case I'll pass the ball to Ian for the last one.

—
Reply to this email directly or view it on GitHub.

[jordy33]

Hi Ian
I have a problem, when i executed the sensortag.py the program hangs.
Doing DBG for debuggin, when the line 191 is executed for second time it hangs for ever.
The line 191 it reads:
rv = self._helper.stdout.readline()
so... The first time it reads the header:

bluepy-helper.c built at 16:15:35 on Sep 4 2014

The second time it hungs
If i execute directly the bluepy-helper and i manually type the commands the program connects ok
conn bc:6a:29:ac:29:31
rsp=$stat state=$tryconn dst='bc:6a:29:ac:29:31 mtu=h0 sec='low
rsp=$stat state=$conn dst='bc:6a:29:ac:29:31 mtu=h0 sec='low

Im running on a raspberry pi and the distro is arch linux.
Im also using an orico csr8510 dongle, for bluetooth le.
Can you help me?

[kalfa]

@Jord33 and @BrianAtLonmed , I created two issues, which probably have a reason in common: #10 and #11
I'll look at it as soon as I have I can, hopefully I'll be able to reproduce it or request some further info.

@IanHarvey would you mind to tag those issues "python3.4' or similar and assigning them to me, please?
Alternatively give me some powers to assigning and tagging so I can be autonomous 😄 cheers!

[jordy33]

Kalfa... thanks i found, the the bug.
Fix for no flush. File:btle.py, line 161 added flush()
Fix for no encode. File:btle.py, line 299 added str.encode.
look the code at git.

[IanHarvey]

So I've done a bit of work on Python3.4 issues, it now works for me with a sensortag on Python 3.4.1 (built from python.org's source tarball, on raspbian on a Pi). This was mostly the flush() fix, and a couple of str-vs-bytes issues.

I've also put in a trial fix for @BrianAtLonmed 's 'ntfy' exception problem, although I've not tested it's effective.

@kalfa - I've put you as a collaborator on the project, so if you want to make extra 3.4-related fixes, be my guest.

Have a good evening, all...

[kalfa]

thanks for the fixes and the collaborators bits, @IanHarvey , I would have had time to work on it just tomorrow evening.

[BrianAtLonmed]

@IanHarvey I've tested it and it works well , thanks

[IanHarvey]

I'm closing this for now, as it's now basically working. Any bugs in the 3.4-specific code should probably be raised as separate issues.