Webduino - webserver library [PORTED]

the whole logic works now… sends back a nice json string…
BUT every 10 minutes or so the spark hangs … does not answer to curls or any contact from the spark site and has to be rebooted.

could this be an out of memory problem?

kw

Sounds like the same webduino instability as I encountered in my project. What helped me most was to disconnect from the cloud shortly after starting up. To allow flashing I added a connection status switch function to the mode button.

1 Like

Maxint,
could you be a bit more specific on how to do that?

If the spark is not stable, I will have to wait a bit more to do any real projects with it.

My arduino+wifi or +ethernet NEVER need a reboot…

KW

I seem to be bashing my head against the wall and decided it was time to reach out.

I am trying to use webduino for a project where I send a POST to the spark with the json formatted data in the message body.

I know that I can specify form-data, x-www-form-urlencoded, or raw in the message body (I’m using postman). I would like to send a json formatted data package. So I guess I need to use raw.

I don’t know how to get the data from webduino, in otherwords have it return to me a pointer to the text in the message body and let me parse the json myself.

Where I am at is by increasing the buffer sizes for name and value a call to readPOSTparam will get my data in the name field, however when the web browser sends the request webduino seems to block for 10-12 seconds after getting the header (debugging turned on) and then display the rest of the message body and after a few more seconds it will respond with 400 bad request response.

I am not sure what I am doing wrong.

In my project I’ve seen frequent time-outs of 20 and more frequently 60 seconds, most often after handling a request. I’ve added a watchdog function to track these events and log them to an SD-card. At the end of my setup() function I’ve added a Spark.disconnect() call to disconnect from the cloud. Without it my application won’t run for even half an hour without stalling. Disconnected it ran for many hours (60+) only stopped by me to flash new code.

Next to these long time-outs when connected to the cloud, I also see short time-outs when disconnected. These always occur a few seconds after handling a request from my webbrowser. Using the webduino serial debugging setting to 2, I can see that these are related to the clients connection:keep-alive header. That header triggers a connection time-out, which in my project results in a few seconds of non-responsiveness. I have no solution for this time out yet, but in my project it doesn’t seem fatal as the webserver is only serving a few separate requests per hour. I assume this behaviour may cause more issues on a busier server.

BTW. My server currently handles simple GET-requests, giving HTML response. I’ve not implemented any jason stuff yet.

1 Like

This is useful info, thanks for posting! Tracking these timeouts and hangs is on my radar hopefully in the next couple of weeks.

I’ve seen the short timeouts too, and presently don’t have any clue why they occur.

I got some clues from the webduino code by switching on the most detailed level of the webduino serial debugging setting. If you set the specific define to 1 you get basic debugging info. Set it to 2 (or higher) to get more detailed info on your serial port. The short time-out always occurred a few seconds after a page request and on the serial debugger I then saw the text “connection time-out”, which can be found in the webduino webserver.h file.

With regards to the longer time-outs, I found it most interesting to see that they were always either 20 or 60 seconds. These were precise durations: not 58 or 62, no 60.xxx seconds. Based on that I concluded that these time-outs were hardcoded somewhere in the CC3000 driver. From what I’ve read I understand that the current driver has a blocking implementation, allowing it to block running software from running.

Good luck!

2 Likes

@maxint -
Thanks for the information. I only tried a few GET requests and they did not seem to have any delays. Since I am sending data to webduino to be following proper protocol I should be sending POST, actually they should be PUT because I am only changing data. Unfortunately webduino does not support PUT and appears to not support any data in the message body of a POST or PUT.

@mdma -
I appreciate the initial port. I noticed from the WebIDE that over 200 people have references to the library. I wonder what they are using it for? Is it possible it’s in production somewhere?

@mdma, i think you need to hit the reimport button for this library in the Web IDE to pull in the changes to the library path.

Just tested it and the library worked fine expect that it was still on the old library path. :wink:

Hi @maxint, did you ever figure out a fix for these delays? I am encountering a similar issue (running the Webduino server on a Photon) with occasional delays of 2 - 10 seconds whereas commands sent to the webserver just prior had processed very quickly. I also believe it has to do with the client expecting the connection to stay open (due to “keep-alive” headers) but the Webduino library appears to close the connection after each request. If you found a solution it would be very helpful, thanks!

Hello @sddw. Unfortunately I did not have much more time to spend on this issue and actually I was hoping that this issue would have been resolved by now. My assumption that it was due to the CC3000 driver apparently doesn’t hold if you are encountering the same issues with the new Photon. Too many other things diverged me from the path, so I 'don’t even own a Photon yet. Are you using the latest libraries? Many issues I had in earlier stages resulted from lengthy operations that hindered timely handling of network events. Have you optimized your code for that?

My Spark Core based device is still running the same software that I assembled more than a year ago and the hacks I described above still keep it running, albeit with some watch-dog enforced resets every now and then. It serves its purpose, but I still had the plan to replace the Core by a Photon to allow better operation. Reading in your post that it still has network issues is not very hopeful. In the meantime I also got my Onion Omega delivered, so I’ve got even more alternatives to investigate (and still not enough time…)

Maybe others can elaborate on their experiences? Perhaps another library than Webduino yields better results?

Hi @maxint, yes I am using Webduino 1.7 which I believe is the latest version. And let me note that while I see delays in responses to GET requests (especially when sending several commands within a few seconds time), I rarely have the connection completely timeout where I don’t receive a reponse at my control app. It just sometimes takes much longer than I think it should.

@mdma I believe you were one of the contributors to porting the Webduino library over for Particle devices, maybe you have some input? Any suggestion for minimizing response delays from the Webduino server? Based on the symptoms I described in my previous post do you believe this is related to “keep-alive” headers or something else? Thanks!

Sorry to bump this up. But since this post is topmost the most relevant when you are searching on webserver. I was searching for a good and complete out-of-the-box example and had some trouble finding it in the forum. I thought it might be good to share this tutorial by Garrett Bartley with some good examples how to use the webserver library with mDNS.

I hope it helps others that stumble across this topic in the future.

2 Likes

I decided to do my own take on the tutorial of @wgbartley, mainly to learn a bit more about developing an app and the speed differences over communicating over the cloud and the local network.

On the road I’ve updated the Webduino library, because I noticed the fixmedelay slowed down communication significantly.

The library is now up on Github and I’ve also published it in the Particle build system.

See:


And the code and Quick Start on Github:

1 Like

@kasper

Thanks for the library. Does this library work with the W5100-based ethernet adapter connected to the Photon/Electron?

Thanks.

I think not, because it’s ported to make use of the TCPserver/TCPclient functions on the Photon.

Does anyone know how to get the values from HTTP headers request comes using this library?

I see there’s a processHeaders function but only obtains “Content-Length” and “Authorization” headers…

Thanks