I’m using spark.publish() to send me an ID and I want to send some data back to the core to display on an OLED screen.
I’ve written a little python script https://gist.github.com/huslage/9742307 to go grab some info from an API and then POST it back to a function on the Core.
This has worked fine from a little webapp before, but something isn’t right now. I post back the data, the LED on the Core blinks cyan really fast for a second on the Spark and then I get a timeout from the API.
I started running into the same problem yesterday. I haven’t had time to do more testing, but it initially seems like Spark.function() works if you are using Spark.publish(). I couldn’t even get Spark.function() to work after commenting out the Spark.publish() stuff, but that’s about as far as I got. If I get some down time at work today, I will investigate farther.
I don’t think they are necessarily related at all. I’m getting the publish SSE messages just fine. The POST simply isn’t working for some reason. It works with curl, so I think it’s something dumb in my code.
My Python isn’t the best, but I’d suggest using something like RequestBin instead of the Spark api endpoint. Make the same request from CURL as you’re making from Python, and compare them for differences. That might help you track down the issue.
We’ve had some reports that Python and the CLI might both url-encode the arguments POSTed to your spark function. So instead of “Playa Guiones” you might get “Playa%30Guiones”. I need to look into this and see if it makes sense to urldecode these parameters or what. I think generally speaking variables passed via a POST shouldn’t be encoded, but I could be wrong about that. – Worth checking, or piping the arguments you receive in your function to serial.
Thanks Dave. The problem is that, according to the serial output on my Core, I’m not receiving anything but an empty string when I hit the URL with Python, but I do receive urlencoded data (that I decode on the core) when I hit it with Curl. Something on the server-side is eating the value when I hit it with Python.
Hmm… How long is the string you’re sending in the function call?
Just to check, was it working before and now it’s not? Have you changed firmware or your python script significantly? We haven’t made any significant changes to the function call endpoints I believe, so I’d want to start looking there first. Maybe try with something like Tinker and make sure you can call those functions, or maybe try watching the request with something like wireshark to make sure the parameters are coming through okay?
It depends on the content-type specified in the headers. Check out this post from StackOverflow. I know it's not official W3C/IETF/RFC documentation, but I do think it's generally correct.
@huslage My first guess is that your args string is too long—63 chars is the max by default. Try sending something really short like “test” and let us know whether that works.
After it’s URL encoded, the length would go over 63. The limit is to conserve memory on the Core, since most common use case messages are, like, a single number or word, e.g. a hex RGB color code or a 0-255 number to set a servo to or something of that nature.
If you look around the community, you’ll see lots of complaints that we’re already using too much memory. Sixty-four bytes is our “works for most people most of the time” balance choice.
If you’re building locally, you can absolutely change the limit though, here, defined as USER_FUNC_ARG_LENGTH:
I set the USER_FUNC_ARG_LENGTH to 92 and the board just flashes cyan really fast when I send it the exact same data. Runscope indicates that the payload length is 59, so I shouldn’t be hitting any limits anyway.
So something else is governing my limit and causing the thing to crash at 54 characters. I’m not sure how to debug this further or why the limit is 10 characters shorter than the default…or why my new parameter isn’t taking.
Maybe @zachary can chime in here, but I would think that can’t just set the core’s length to be longer–you would have to set both the core and cloud’s length to be longer to get it to work.
Your POST is still going through the cloud which seems to be assuming your core has the old limit which is a good and safe practice to not overflow the core’s buffer.
How do i know what the valid upper limit is for my application?
All I’m doing is receiving some data and putting it onto an OLED screen, then every once in a while publishing to the cloud to trigger new data to be sent to the screen again.
OK, so you the limit is that 63 chars works and 64 doesn’t, even after you bump up USER_FUNC_ARG_LENGTH to 92. My bad. @bko I said above that this would work. I know the Cloud doesn’t care about the length, but the communication library might. I’ll double check…