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

runs for 5 minutes and then dies #4

Closed
snyggapa opened this issue Jan 11, 2019 · 5 comments
Closed

runs for 5 minutes and then dies #4

snyggapa opened this issue Jan 11, 2019 · 5 comments

Comments

@snyggapa
Copy link

not sure if this is a wave plus thing or a code thing but it runs for 5 minutes and then dies with this every time:

Traceback (most recent call last):
File "read_waveplus.py", line 211, in
sensors = waveplus.read()
File "read_waveplus.py", line 135, in read
rawdata = self.curr_val_char.read()
File "/usr/local/lib/python2.7/dist-packages/bluepy/btle.py", line 197, in read
return self.peripheral.readCharacteristic(self.valHandle)
File "/usr/local/lib/python2.7/dist-packages/bluepy/btle.py", line 530, in readCharacteristic
resp = self._getResp('rd')
File "/usr/local/lib/python2.7/dist-packages/bluepy/btle.py", line 407, in _getResp
resp = self._waitResp(wantType + ['ntfy', 'ind'], timeout)
File "/usr/local/lib/python2.7/dist-packages/bluepy/btle.py", line 362, in _waitResp
raise BTLEDisconnectError("Device disconnected", resp)
bluepy.btle.BTLEDisconnectError: Device disconnected
pi@raspberrypi:~ $

@orjangj
Copy link
Contributor

orjangj commented Jan 11, 2019

Hi snyggapa,

Thank you for the detailed traceback.

From what I can understand, this looks like a connectivity problem. For instance due to low signal strength which inhibits the devices from maintaining proper connection.

I will add a method for reading the signal strength between your devices on monday.

In the meantime, you can try moving your raspberry pi closer to the wave plus to see if the problem persists.

Also, what sample period are you using?

EDIT: alternatively, you can install one of the apps "nRF Connect" or "simplelink sensorTag" on your phone to connect and read the RSSI value from wave plus. Typically, RSSI < -70 is poor, and RSSI < -90 is bad.

@snyggapa
Copy link
Author

pi to wave distance was about 10cm - can't get much closer!

sample period either 10 second or 60 seconds - either way it died after 5 minutes. Of course the 10 second poll made about 6x more reads although due to the wave data update frequency meant that the amount of different data I got back was the same :)

I forked it here to send data to an IoT service thingspeak

https://github.com/snyggapa/waveplus-reader

seems much more reliable taking one reading, disconnecting and running again in 10 minutes. If it's any help I had huge problems with the android app which only every synced once. I binned it before moving to the Pi.

@orjangj
Copy link
Contributor

orjangj commented Jan 12, 2019

Ok. Then it's not a signal issue :) I'll try to reproduce.

Either way, I think your suggestion regarding (connect - read - disconnect - wait - reconnect ... etc) procedure sounds like a more appropriate approach to communicating with the wave plus. Especially when we consider large sampling periods, and we're just holding the link without doing any transactions. So I'll most likely update the reader script for whomever it may concern after some testing of my own.

Thank you for your contribution.

@jmagnuson
Copy link

Especially when we consider large sampling periods, and we're just holding the link without doing any transactions.

That's where I'm thinking the issue is-- many (all?) BLE devices will automatically close the connection after some idle timeout, and it's possible that's happening here as well.

Alternatively, you could do something like:

while True:
    try:
        sensors = waveplus.read()
    except bluepy.btle.BTLEDisconnectError:
        print "Device disconnected-- reconnecting"
        waveplus.connect()
        continue
...

where you catch the disconnect error and immediately reconnect. @snyggapa's solution may be easier on the battery though.

orjangj added a commit that referenced this issue Jan 14, 2019
New release dated 14-Jan-2019
 - [bug] Fixed issue #4
@orjangj orjangj closed this as completed Jan 14, 2019
@orjangj
Copy link
Contributor

orjangj commented Jan 14, 2019

Tested the new release with a sample period of 10 minutes. The script was running without problems for 90 minutes before I manually ended the script. So I view this issue as closed.

I haven't implemented any top-level exception handling that the bluepy module may throw. In any case, you are welcome to reopen the issue (or make new ones) if needed.

Best regards,

Ørjan

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

3 participants