Announcement

Collapse
No announcement yet.

Xpico wi-fi ajax interface

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Xpico wi-fi ajax interface

    Hi,

    I first tried Lantronix help request - with no success. I am hoping that there is
    someone else that can possibly provide some more information on ajax and monitor data interface to web browers manipulation of user defined data.


    I need more information on how to present monitor data from serial port to a web page.

    I use the latest firmware available for the xpico.
    I managed to successfully overwrite and run the default web pages with my own custom web pages. However these pages are static in nature and no ajax xml data pull form server.

    I have managed to create data variables using the monitor interface to filter my data comming in from the serial port.

    My goal is to update data variables using monitor and then display and manipulate those data in my browser using javascript. I also would like to pull the latest data periodically from the web server using ajax. From my browser i would like to use XMLHttpRequest.

    I am having difficultly understanding how to get hold of the monitor data - how do i reference it from my browser html code. What is the name and path of the xml file containing the monitor data and what is the data path that i should use in my javascript code the reference the xml data. I assume this xml file to be dynamically updated by the browser monitor protocol/code to a specific directory so i can reference it from within my client browser - is this assumption correct?


    Is there maybe a more advance app note that explain how to retrieve the monitor data from a web browser?

  • #2
    The filtered User Data from Monitor is placed into volatile "Status" in the xPico WiFi. So while it's not saved into a file (you wouldn't want that many write/erase cycles on flash anyway), it can be accessed with an Export Status WebAPI call.

    Take a look at the first example in Appendix B of the Users Guide (page 100) on how to export the status. In short, you'd do this:

    var setRequest = new XMLHttpRequest();
    setRequest.open("POST", "/export/status", true);
    setRequest.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
    setRequest.send("optionalGroupList=Monitor?);

    This will return the portion of Status that relates to Monitor, in XML format. You can then parse the XML to find the statusitem with your data name.

    Comment


    • #3
      Thanks very much, I will try that. Yes you are right, the flash will indeed have failed, wear leveling and all if we wanna go that deep

      Comment


      • #4
        I have now successfully managed to use ajax to pull data in real time from the serial port to my web page. I am very impressed by how unambiguous turned out to be.

        One sticky point is the minimum of 1 second timer for monitor data polling on the serial port, I was hoping for a little faster interval scan times - something in the line of 100ms or less .
        Last edited by linktek; 06-09-2014, 09:35 AM.

        Comment


        • #5
          After furhter investigation on the Monitor custom data interface/protocol I am affraid to say that it is very clumsy and restrictive.

          The monitor only poll once a second - even though AJAX HttpRequest can be set to pull data at higher rates form the server. This really defeats the purpose of a interactive experience. What good is it to have ajax polling at sub second intervals while the monitor polls at max once per second.

          The second issue is that the monitor works only one way, you cannot interact from the browser sending commands with the ajax POST command plus some args. It would have been very helpfull if the args could have been directed to a subfolder (memory buffer array) that would send/spool the args straight to the client device on COM1 allowing some way of CGI bi-directional interface.


          Some suggestions;

          The Monitor web data extraction dont work for serious CGI interactions. I would suggest the device data on a poll to be dumped in a buffer and made accessible through HttpRequests via ajax. It is then up to the Browser client javascript code to extract data, no need to do it in the web interface firmware.

          Even better, the data from the client device can be formatted in simpe xml structure and passed to the browser via ajax and its xml parser. We need at least 1k of data buffering or more for decent response.

          The other problem is the one way uni-directional nature of monitor poll interface. For a proper CGI interaction it should allow ajax POST arguments to be relayed to COM1 for the user to interact with the received data.

          So what would be ideal is a bidirectional CGI type interface between the browser client ajax and the COM1.

          The alternative is to use Tunneling and that will defeat the purpose of allowing the customer to modify the web server pages.

          I hope my comments and recommendations are received in good spirit.
          Last edited by linktek; 06-20-2014, 09:30 AM.

          Comment


          • #6
            It seems like the Monitor string capture cannot do strings longer than 40 characters. Anything past 40 characters causes string framing errors.

            Comment


            • #7
              Thank you for providing comments on your experience with the xPico Wi-Fi. We at Lantronix are striving to improve and enhance the feature set of the product, so this type of feedback is positive and welcome.

              We will certainly tackle the issues of poll time and response string character length that you mentioned and have planned to address them and other enhancements to the feature in a future software release.

              Like you we recognize the benefit of having bi-directional web/server support in the xPico Wi-Fi and soon will be adding a feature that enhances the experience and management of the interaction between the device Webserver and the serial ports.

              Comment


              • #8
                Just wanted to mention that we are also looking forward to this feature (more sophisticated way of communication between Javascript and serial devices via the builtin web server), the limit of 4 polling options / commands is not enough to control our devices with a web page and Javascript imho is much more flexible in handling requests and responses anyways. Moving the "burden" of processing http requests and sending responses out of our microcontrollers into the xPico would simplify development very much!

                Comment


                • #9
                  So we are finally ready with our product based on the current Monitor interface.

                  We decided to use all 4 message commands and responses per second. That translates to 40x4 data per second from the client device.

                  In order to get more information out of the monitor protocol we decided to use one message formatted with our own custom sub headers so as to funnel more data via this particular message. We reserved the most critical data on a exclusive message that gets updated with each scan while statistical data is downloaded in the background over a coupala second.

                  It all turned out well even though its is only for data presentation use and post analysis and presentation.

                  We do not use the monitor to decode individual fields, we just capture the complete string and let the browser xml parser do the rest.

                  We found that any ajax interval smaller than 500ms can be disruptive to multiple connections.

                  If I can suggest any improvements to the Monitor system it would be ....

                  1)Slightly faster poll rates - currently 1000ms
                  2)Slightly larger string length limit per message.

                  Now I am aware that the module has limited resources to spend too much time capturing strings and so forth.

                  Lets say the message length limit was 1k in stead of 40 bytes per message. That means that I would have been able to only have one poll command per scan in stead of the data spread out over 4 message of 40 bytes each.

                  Other than that we are ready to wrap up our product and are ready for production.

                  The only worry I have is how to duplicate the setup from device to device. I would hate to have to manually configure a 1000 devices !!!
                  Last edited by linktek; 08-23-2014, 01:40 AM.

                  Comment


                  • #10
                    Originally posted by linktek View Post
                    The only worry I have is how to duplicate the setup from device to device. I would hate to have to manually configure a 1000 devices !!!
                    You don't have to do it manually. My recommendation is that you setup one device exactly how you want, and then use the WebAPI for copying that "golden unit" into others.

                    Take a look at the WebAPI documentation, but the basic steps will be:
                    - Create golden unit
                    - Use curl or Postman or some other HTTP generator to access /export/config

                    This will give you the full configuration in XML format. Then you can upload that XML to new units and they'll be configured as the golden unit.

                    You can upload that XML either via WebAPI or via the serial port.

                    Serial port 2 comes by default in CLI mode, so you can do it there (turn on software flow control first via the CLI). Serial port 1 is by default in Tunnel mode, so if you want to use serial port 1 do a Boot to CLI sequence (see page 71 of Users Guide).

                    Either of those, you end up in CLI and can dump the XML into it.

                    The other option is to do it via WebAPI by doing an HTTP POST to /import/config

                    In that case you need to be in the same network as the xPico Wi-Fi. One option would be to have a device (a computer or tablet) that automatically connects to the SoftAP of an xPico Wi-Fi and then does the HTTP POST.

                    Comment


                    • #11
                      I up this topic.

                      Does the new firmware allow to keep more than 40 characters per data ?

                      Comment


                      • #12
                        Not for the Monitor application due to the buffering that needs to take place in the (limited) RAM of the xPico Wi-Fi.

                        If you need to transfer data between AJAX transactions and the serial port, this firmware lets you do it without buffering in the xPico Wi-Fi by using the "None" protocol and the Web to serial feature.

                        See this documentation of that in the Wiki:
                        http://wiki.lantronix.com/developer/...WebAPItoDevice

                        Comment

                        Working...
                        X