Serial Web Services API and GET

[nick]

Hi --

I've been using IOBridge for almost a year, and for almost as long I've been grousing about the lack of an action to trigger an http command on an event.

So when I read about the Serial Web Services API I was thrilled, I could do it myself.  So I hooked up an arduino to my IOBridge and wrote a simple program to get get a page on my website, using the GET command.  I wired it all together and...

Nothing.  My web server is not reporting any hits in the log.

I can see the command in a serial monitor widget, and if I copy it and paste it into a browser I get the page, after stripping off the "[[[get|" part.

Is there something else I need to do to make it work?  The world will be my oyster if I get this working.

Thanks,
Nick

[iobridge]

In the few short months that the Serial Web Services API has been released, we have processed 1 million transactions thru it. Half of that are "gets". It's been a popular addition.

Here are some things that might inspiure a resolution:

How long is the URL you are getting?
Are you closing the command? [[[get|url]]]
Are you including http://?
Is it a local URL?
Try sending an email to make sure the API is doing something for you? [[[email|address|subject|body]]]

Lots of users are getting it working, so I think we can get it figured it out for you. You are going to like the feature.

[nick]

OK, I tried a few more things.  I hooked the IOBridge up directly to the serial port on my computer.  Simple commands like [[[date]]] and [[[time]]] work exactly as expected.  However, I can't get any response when I try [[[get]]].

This is the exact string I am trying to send: [[[get|http://www.nickkeenan.com/h.html]]]

But I can't get any response with any variation of site, page or syntax.

As an aside, it was a bit of an adventure hooking the IOBridge up to my serial port.  Using hyperterminal I set my end for 9600-n-8-1, no flow control, and set the iobridge for 9600-inverted.  I found I could send characters but not receive them.  I hooked up an oscilloscope to the tx pin on the iobridge and saw that when I did a [[[date]]] command there was a flash of activity, but no characters arriving.  So I set the iobridge for true rather than inverted, and put a Max232 inverter between it and the computer, and everything worked.  So I think the voltage levels on the iobridge are not enough for the serial port on my computer (a laptop, which are often more finicky that way).

Nick

[iobridge]

You are right, the serial voltage levels are not for computer serial port.

I have tried this and it works great.

http://iobridge.com/hello.html

See if you can get this URL? If you want to try this live, we can set up an IM so I can check the server logs.

Just send me a note at support@iobridge.com

[nick]

Is there a limit on the size of the file that can be returned?  The sample file you provided is only 14 bytes -- and it works.  I copied the file to my website, and it doesn't work.   However, my website appends a 412 byte javascript footer to any HTML page for tracking purposes.  If I rename the file with a .txt extension, the web server doesn't put the footer on -- and the get works.

I think I can do everything I want to do with PHP files, which don't get the footer, but it would be good to know what the limit is.

Thanks,
Nick

[iobridge]

That Yahoo tracking JS is likely the culprit. It's probably tripping up my rendering. I am getting files a browser would. I will check on the limits and see.

Glad to see it's working!

[nick]

I got it working with a minimal PHP file that returns 14 bytes, which is enough for my needs.

[iobridge]

I fixed the overall issue. Now I get the first 100 chars of the web document, instead of the whole document. I am not parsing any tags, so this would include html tags if they are there.

The way you are using it with PHP is still best, but at least now it does not break.

[noelportugal]

How long can the GET url can be?

Im trying to send this:

Code: [Select]

Serial.print("[[[get|http://xxxx.xxxxxx.com/abc/def/ghijklmn.api.updatequeue?track=");
Serial.print(track);
Serial.print("]]]");

[[[get|http://xxxx.xxxxxx.com/abc/def/ghijklmn.api.updatequeue?track=1.WAV]]]

But I only get parts on the listener..
track=1.WAV]]][[[get|http://xxxx.xxxxxx.com/abc/def/ghijklmn.api 

Sometimes I get the rest of the string and the command completes...but it takes a while.

Any toughts?

[iobridge]

We will take a look and let you know. I am not sure of a limit.

In the mean time, can you try a shorter URL and see if that works?

[noelportugal]

Thanks...I have tried a shorter url and it works     

I can try to shorten my api call and parameter to something like:
[[[get|http://xxxx.xxxxxx.com/abc/def/ghijklmn.api.a?p=1.WAV]]]

but before the .api. I don't have to much of an option

[nick]

The buffer on the serial smart board is 50 bytes.  The board will send a packet after either one second or when the buffer is full. I have found that the web services API works most reliably if your message fits into a single packet.  It's also good practice to send your request in a single block so it doesn't get split due to time.

[noelportugal]

Oh yes I read the wiki page where it mentions the 200 byte FIFO receive buffer and the 50 characters per second.

So Its fine with me if there is a one second delay (2 seconds) to send my full get command. The problem is that the even after 2 seconds I get inconsistent hits to my GET URL.

My mcu (arduino) will play a WAV file and it will do a Serial print every time that a new WAV file starts (evert 2-3 minutes). The GET command calls a REST api that updates a remote database that tracks the current WAV being played. I want this to be semi-realtime, so the 2 or 3 second delay would not be a problem as long as the GET gets send...

It seems that 50 first chars get in the buffer and it wont send until its full (200 bytes?) is this a correct assumption? This would be a problem since Im only sending about (77 -78) characters each 2-3 minutes.

Any ideas?

[iobridge]

We are investigating the issue. It should be transmitting regardless of the 200B buffer. We will let you know what we find.

[jason]

Ok, we found the problem.  The new firmware wasn't grabbing consecutive serial messages properly.  We've made the update available (C4.1).  That should fix it.