"The cards will be on sale to developers by the end of June for $25 each"
"When the $25 card is installed in a slot and powered up, it will find the ID number and automatically transmit the information to Electric Imp’s servers."
I don't like the idea of a central server as default. Although that's a very good functionality (together with SSL and auto-update) one of the first things serious developers will look for is how to switch it off or mod it - I'm assuming I won't have the choice to switch this off. It will also spark development of open-hardware alternatives that don't dial home. The price is very low and the design is very compact, which makes me believe that the income will be generated by an online subscription to push/process data at the central server. That is not a bad model, but it also means that I won't be using it to control anything in my house because some day the connection will be lost for an amount of time. This scenario is normally caught by a local gateway, but I don't see them in this setup.
The concept is that groups developing internet-enabled devices provide a slot for this imp card, which takes care of the heavy lifting of getting online and connected.
It would be very easy to put the power supply to this card under software control on the final host platform.
Yeah, "no thank" is the answer that comes to mind. The fact that they all dial home to a central server is a giant security risk, not to mention a single point of failure.
Given that none of the cable companies are exceedingly capable at keeping a connection up 24/7, this makes the imp useless for any devices in a typical home.
The module certainly looks neat, but being designed to use the manufacturer's "secure, reliable, distributed internet service" makes it appear to be useless for disconnected applications. Not every application of Wifi involves networks connected to the Internet.
Can some one give me some info/pointers on what kind of stack would such a M2M effort need? I just joined a nascent venture which is trying to do something similar - but a bit more ambitious ... make it device/protocol agnostic. I'm trying to find more resources to read, but haven't been making much progress in terms of selecting robust open source technology.
Take a look at http://www.axeda.com/ .. these guys seem to be doing pretty neat stuff!
This looks like fun, I wonder what type of connections, sensors and such are available for the card in order to connect it with your devices? I wouldn't mind making some kind of monitoring system for my fish tank (they already exist but it would be fun to build my own)
ARM controllers like this Cortex-M3 come in a range with flash capacity going from 8 to 512 KiB and up. TCP/IP stacks in embedded go from ~7KiB for uIP to 256KiB compiled depending on strictness/flexibility of implementation. The controllers can probably upgrade to IPv6 because of the nature of wireless firmware upgrades in embedded systems. The firmware is spread over different packets, so to assure a successful firmware download it's always written to a reserved region of progmem and checked before doing the actual code upgrade. If they did their homework they have flash space that is (2 + margin)*code size. My bet's on yes, it'll upgrade to IPv6.
http://edn.com/electronics-news/4373185/Former-Apple-Google-...
"The cards will be on sale to developers by the end of June for $25 each"
"When the $25 card is installed in a slot and powered up, it will find the ID number and automatically transmit the information to Electric Imp’s servers."
I don't like the idea of a central server as default. Although that's a very good functionality (together with SSL and auto-update) one of the first things serious developers will look for is how to switch it off or mod it - I'm assuming I won't have the choice to switch this off. It will also spark development of open-hardware alternatives that don't dial home. The price is very low and the design is very compact, which makes me believe that the income will be generated by an online subscription to push/process data at the central server. That is not a bad model, but it also means that I won't be using it to control anything in my house because some day the connection will be lost for an amount of time. This scenario is normally caught by a local gateway, but I don't see them in this setup.