-
Notifications
You must be signed in to change notification settings - Fork 60
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
Comments
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. |
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. |
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. |
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. |
New release dated 14-Jan-2019 - [bug] Fixed issue #4
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 |
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:~ $
The text was updated successfully, but these errors were encountered: