Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support python 3.4 #5

Closed
kalfa opened this issue Jun 14, 2014 · 13 comments
Closed

Support python 3.4 #5

kalfa opened this issue Jun 14, 2014 · 13 comments

Comments

@kalfa
Copy link
Collaborator

kalfa commented Jun 14, 2014

I amended btle.py with some support for py3.4, I'll do a pull request at some point in the future.
Feel free to see my fork's branch "py3". I had to reformat many things, as they broke on python 3.4.
I took the chance to have them formatted as much I could with pylint, pep8 and pep257, as I'm planning to use the code later.

Back compatible with 2.7 in theory, I tried it out and it works, but there are no unit tests so it's hard to say.

@IanHarvey
Copy link
Owner

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
Copy link
Collaborator Author

kalfa commented Jun 17, 2014

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 notifications@github.com 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
Copy link

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
Copy link
Collaborator Author

kalfa commented Sep 4, 2014

@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
Copy link

@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
Copy link
Owner

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 notifications@github.com 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
Copy link

jordy33 commented Sep 11, 2014

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
Copy link
Collaborator Author

kalfa commented Sep 12, 2014

@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
Copy link

jordy33 commented Sep 13, 2014

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
Copy link
Owner

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
Copy link
Collaborator Author

kalfa commented Sep 16, 2014

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

@BrianAtLonmed
Copy link

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

@IanHarvey
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants