DigiFi optimisation

[jamiecockrill]

Hello all,

I've forked DigiFi to resolve some issues I was having in the following post in the support forum:

http://digistump.com/board/index.php/topic,1475.0.html

I was having issues with using DigiFi in client mode. I was regularly getting "400 - Bad Request" messages in my web-server logs and when I ran a packet-capture I found quite a lot of the AT commands leaking into my requests (see my support post for the long boring detail).

In the following commit (https://github.com/jdcockrill/DigiFi/commit/5e5909258925f2c1813e00300f8922850b9e059a) I made a number of changes that might want to be incorporated into the main library:

• I broke out the initial AT mode handshake into a separate private 'startATSequence' method and added validation to check the values returned by the Wifi module during the handshake were as expected (I just check for the 'a' character, not an '<ok>' at this point). I also added a timeout as the initial handshake is only supposed to last 3-4 seconds.
• the main startATMode method then  uses the startATSequence method in a do-while loop to ensure that the module is actually in config mode before we try and configure it
• get and post methods now return an int. If it's a positive number then it's the HTTP status code of the request. If it's negative then it'll be something wrong with the connection somewhere along the line (error codes are in the source)
• I also added a disconnect method at the end of get and post to force a TCPDIS=off (TCP disconnect) command to get issued to the Wifi module. Since we send a "Connection: close" header, the server is expecting us to disconnect, so now it actually does the disconnection within the method itself.

Usage of startATMode, get and post is just the same as before. Only difference is that get and post now return an int.

There are lots of things to do and some of those TODO's are listed in the code. However it'd be good to:

• be able to pass char arrays in to capture the HTTP headers and response body to the caller
• do loads more validation within the AT commands to check we are actually getting '<ok>' messages back from the module
• remove the force disconnect from the beginning of the connect method. With a public 'disconnect' method it should be possible for most users to just call 'connected' and getNetParams to check if they need to disconnect, reconfigure and connect to another host

I'm happy to contribute to some of this stuff. Would it be preferable if I created 'issues' in github and pushed commits against those on my fork? I've no idea how pull requests work.

[jamiecockrill]

PS I didn't make it entirely clear, but these modifications seem to have fixed the issues I was seeing previously.

Before I'd get a few minutes before starting to get errors, then after a couple of hours I would stop seeing requests. Now its been going to 3 days and seems pretty resilient to the server going up and down when I turn it off for a few hours.

[digistump]

please open issues and send the pull requests - that would be awesome!

Thanks this looks like great changes!

[jamiecockrill]

All done - no problem.

Added a couple more things in there as well. I was finding that the part which checks the content length and skips retrieving the Body if "Content-Length: 0" wasn't working properly. I don't know if it was expecting to compare a char against a String or something, but I've replaced it with a straight integer comparison and it works fine now.

I've also added a timeout to readResponse as I found that I could, if I tried a few times, send the DigiX into an infinite loop by restarting apache (or whatever web server it was reading data from) whilst it was in the readResponse method as it would get stuck in a scenario where it hadn't reached the end, but Serial is suddenly unavailable. I've just put the standard 15s timeout into the method (uses the timeout number in the header file).

It still needs the Serial port to go unavailable to hit the break in the loop, so If someone has a constant stream of data flowing for longer than 15s, they would be unaffected. Its only if your Serial connection flicks between available and unavailable that it might need to be extended.