datastream update( ) method bug

[rabarar]

when an aberrant network event occurs while running the datastream update method, the following failure message below occurs and the program terminates.

ds_sched.update()
File "/home/pi/xively_tutorial/xively-python-master/xively/models.py", line 234, in update
self._manager.update(self.id, **state)
File "/home/pi/xively_tutorial/xively-python-master/xively/managers.py", line 426, in update
response.raise_for_status()
File "/home/pi/xively_tutorial/.envs/venv/local/lib/python2.7/site-packages/requests/models.py", line 670, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 502 Server Error: Bad Gateway

[errordeveloper]

The user is expect to handle exception, as it is a question of what do you want to do when a network issue occurred.

For information on how to handle any exception in Python, take a look at the section 8 of the language tutorial.

Just to give an example, in some use cases the application may wish to either:

• carry on re-trying forever until successfully sent the data
• ignore the network issue as not every datapoint is critical
• report the error and buffer datapoints to try resending in a batch later

The 3 examples are very basic and there will be numerous other solutions for some particular use cases.
The library methods currently don't handle retries, it's is up to the user how they wish to implement it.

[rabarar]

Thanks -- makes sense

Is there any examples of code to provision and activate devices - the api documentation is a little scant

On May 16, 2013, at 9:18 AM, Ilya Dmitrichenko [email protected] wrote:

The user is expect to handle exception, as it is a question of what do you want to do when a network issue occurred.

For information on how to handle any exception in Python, take a look at the section 8 of the language tutorial.

Just to give an example, in some use cases the application may wish to either:

carry on re-trying forever until successfully sent the data
ignore the network issue as not every datapoint is critical
report the error and buffer datapoints to try resending in a batch later
The 3 examples are very basic and there will be numerous other solutions for some particular use cases.
The library methods currently don't handle retries, it's is up to the user how they wish to implement it.

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

[errordeveloper]

@rabarar device provisioning should be added in v0.2. If you do need an example to work with in the meantime, I should be able to help you with something simple. Are you planing to implement this on a Raspberry Pi or some other similar device?

[rabarar]

Thanks -- I can wait for the released version. I am just experimenting at this point...

On May 20, 2013, at 4:05 AM, Ilya Dmitrichenko [email protected] wrote:

@rabarar device provisioning should be added in v0.2. If you do need an example to work with in the meantime, I should be able to help you with something simple. Are you planing to implement this on a Raspberry Pi or some other similar device?

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

[errordeveloper]

I'm closing this in favour of #5.

[andig]

Is there any chance to get a python device activation API? Sample could could suffice- currently docs don't explain how to generate activation_code...

[rabarar]

Good luck :) if you find anything please share...

On Jun 22, 2013, at 10:05 AM, andig [email protected] wrote:

Is there any chance to get a python device activation API? Sample could could suffice- currently docs don't explain how to generate activation_code...

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

[errordeveloper]

@andig @rabarar it is on the todo list.

[rabarar]

Thanks :)

On Jun 22, 2013, at 12:02 PM, Ilya Dmitrichenko [email protected] wrote:

@andig @rabarar it is on the todo list.

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