wifi..http..but gprs

Posted on
  • maybe it's an stupid question... but i cannot find if it's possible or not to connect espruino to a gprs module to send data to internet..can anyone point me to the corrrect direction?


  • At the moment there's no 'built-in' support for GPRS modules, but they usually communicate over a serial port using the 'AT command set', so you can actually control them without needing any built-in support.

    I know @Hardware_Hacks was working on a (JavaScript module)[http://forum.espruino.com/conversations/­1712/#comment30998] that would send and receive SMS text messages, but as far as I know nobody has tried to get on the internet with one (they haven't asked on here anyway).

    Having said that, we've been doing some work on the ESP8266 module (WiFi over serial) and that seems to use an AT command set very similar to a lot of GSM modules. It looks a lot like (this code)[http://forum.espruino.com/conversations/­253943/?offset=25#comment11845968] would probably control the module just fine (once you'd added any commands needed to get the module connected to the network).

    Hopefully support for the ESP8266 will make it into the Espruino firmware in a month or so, and I'll try and make sure that it's flexible enough to work with GSM/GPRS too.

  • thanks gordon.. i'm looking forma device that connect to internet to send/receive data throuht http more than to send/receive sms.

    i will be looking for those updates

  • @user49225, are you thinking about something that would use the push/pull over http protocol, such as the CometD / Bayeux Protocol? See http://en.wikipedia.org/wiki/Comet_(prog­ramming) and http://svn.cometd.org/trunk/bayeux/bayeu­x.html.

    That would be a really cool thing!... sending JSON objects around between Espruino nodes.

    To apply it with Espruino as an http server, Espruino's http server implementation would need to support NIO - non-blocking IO (and multiple concurrent connections), and as a client, it would need to support multiple concurrent connections. Furthermore, the XMLHTTPRequest object - or Web Sockets - would need to be supported... Most modern Web Application servers support CometD/NIO - and Web Sockets. At that time - about 5+ years ago - I used the XMLHttpRequest long polling as implementation technique. For the server I used jetty:// (see http://www.eclipse.org/jetty/ and for clients any devices with http connecting browsers. On jetty:// server I ran a small java servlet which implemented access control (like a registering process) and and routing (forward publishing) written in Java, and on the browser enabled devices, I used - of course - JavaScript for the application (sometimes running in a 'hijacked' embedded browser for Apple iPhone iOS and Android Phone, and 'XUL' modified/hijacked FireFox on laptop/desktop). Today, for (non-Espruino) server, something like node.js could be used to stay within JavaScript language domain, and Web Sockets for simpler, more direct http implementation.

  • Espruino's http server implementation would need to support NIO - non-blocking IO (and multiple concurrent connections

    It does, as does the server. Multiple connections (including mixes of servers and clients) are fine. The only issue here is that calls to the CC3000 tend to block for a long time - WIZnet is much better about that.

    Websockets (or at least standard socket support) is planned - and Espruino is arranged such that when that is implemented it'll work over all supported devices (including GPRS if that is supported by then).

  • umm. maybe i did not explain very well... my english is bad.. i mean that i want to create an IOT device with espruino.. connect espruino to internet with a gprs module with a SIM... similar as what it can be done with the wifi cc3000 module.

  • @user49225 - I understood it that way - gprs connects over mobile network to Web where as CC3000 connects over wifi (lan) to Web. So much for 'basic connectivity'. The protocol question is still to be discussed. Since it is connectivity to Web and Web is (mostly) http/https and http/s is a pull and not a push protocol, something additional has to be done to have actually a 'send' in place. for that 'send'-matter I mentioned the NIO / CometD / Bayeux items. I welcome the post from @Gordon which shows that Espruino - HW and SW - is built to support multi-connections, but some other devices have to 'get there' as well... We used iOS and OS X - Safari browsers - as well a Android - Chrome browser - to run the html page with the javascript implementation/binding of Bayeux - and therefore, we know, that the browsers managed the multi connection aspect.

  • @allObjects I'm not convinced - it's trivial to 'push' data with HTTP, people have been doing it for years. I think saying you need to be able to support 'protocol X' instead of/on top of HTTP is just confusing the matter. Most developers would be entirely happy engineering their own solution on top of HTTP POST.

    @user49225 you explained fine. Basically:

    • You can do it right now, but it's more work as you have to read the datasheet for your GPRS module and write the code to interface to it.
    • Hopefully in the next month or so, support will get built in to Espruino for the ESP8266 and similar, and you'll be able to use most GSM modules a lot more easily.
  • @Gordon, I was not talking about pushing data with http to a server... I was talking pushing data to a client. Clients are by definition pullers.

    Agreed, with Espruino, every client can also easily be (made) a server and thus receive data from any other client through that client's push / post - directly or indirectly.

    To use this pattern of every node in a network being client AND simultaneously server requires managed IPs for every node, makes every node more vulnerable, and requires all nodes to be server-type hardened.

    No matter what pattern is applied, there has to be some designated admin node(s), that knows about the topology (of connected) nodes. An upcoming node registers with this admin node(s), and from then on, talking to any other node goes through (one of) the admin node(s) by logical name to target node for simplification of communication. Admin node(s) also enable easily broadcasting to all or some nodes.

  • --- never mind

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

wifi..http..but gprs

Posted by Avatar for user49225 @user49225