Octoprint plugin Fails to function correctly for some users

[docdawning]

One Illuminatrix user has reported the plugin doesn't seem to correctly command the firmware.

From his octoprint log, we see a key clue:

2017-03-13 11:40:31,809 - tornado.access - ERROR - 750 GET /plugin/illuminatrix/yellow (127.0.0.1) 55.09ms
2017-03-13 11:40:32,883 - tornado.access - ERROR - 750 GET /plugin/illuminatrix/cycleon (127.0.0.1) 37.30ms
2017-03-13 11:49:40,489 - tornado.access - ERROR - 750 GET /plugin/illuminatrix/on (127.0.0.1) 34.87ms
2017-03-13 11:49:44,347 - tornado.access - ERROR - 750 GET /plugin/illuminatrix/cycleon (127.0.0.1) 61.89ms
2017-03-13 11:50:48,544 - tornado.access - ERROR - 750 GET /plugin/illuminatrix/on (127.0.0.1) 63.94ms

I've managed to rule out things I suspected before I saw this, mainly the user's running Octoprint version 1.3.1, on top of OctoPi. His permissions appear to be correctly configured and the firmware is working when commanded manually.

I've tried to reproduce this error by doing a fresh install of OctoPi. I then ran the update to get Octoprint to version 1.3.1. Then I installed Illuminatrix. It worked as expected. Could not reproduce the error.

[docdawning]

The problem reporter has since tried a fresh install. The problem still occurs. He's confirmed he's accessing his octoprint over wifi too. He's now sending me an image of his installation so I can run it up on my own gear, hopefully to reproduce the issue.

[docdawning]

The reporter has since tried another Arduino and the plugin now works as expected. Hopefully I can find out what causes this type of failure so that I can handle it better.

[docdawning]

Turns out, I'm a jack-ass. Here's output from a healthy setup that's fully working:
2017-03-17 15:22:40,752 - tornado.access - ERROR - 750 GET /plugin/illuminatrix/lightblue (127.0.0.1) 82.24ms

Foosel pointed out I'm returning 750, from here: https://github.com/docdawning/Illuminatrix/blob/master/Illuminatrix-octoprint-plugin/octoprint_illuminatrix/__init__.py#L31

She suggests invoking command-line actions through Sarge: http://sarge.readthedocs.io/en/latest/

She also says:

09:25 <+foosel> but another heads-up - the single return in case of an error will produce a problem when you actually enter that catch block
09:25 <+foosel> because flask doesn't like it when your methods don't return anything
09:26 <+foosel> you could raise a 500 error there by simply not catching the exception (then flask will take care of the 500)
09:26 <+foosel> or if you want more control, return some other response
09:26 <+foosel> but return something