I just found the Imp site today, very interesting but I have a question about the agent piece. As I understand it an electricimp.com account is required to program the Imp for the BlinkUp.
But once that is done can I just run the device over WiFi and talk to my other devices on the local LAN… without going out to the 'net large? Is there some other reason that I must still connect back to the electricimp.com servers?
Am I missing something?
The agent is an integral part of the Electric Imp platform, and is a very powerful tool. The device and the agent communicate on a scheduled basis, and the agent can constantly be performing operations while the device sleeps and saves power. Having a managed platform allows Electric Imp to instantly update device firmware, and you to update code very easily. It was for these an many other reasons that MakeDeck focuses heavily on Electric Imp development. If you decide to purchase an Electric Imp and join the community, take a look at our new designs. I don’t think you will be disapointed. Electric Imp is a platform like no other.
This video demonstrates how powerful the agent can be.
It is important to know that you can’t get access to and from your local network directly with the Imp. Every connection is managed by the Impservers in the cloud (and no, you can’t run a local impserver).
@krowden - I think we all start out just wanting devices to talk to each other and think that that should be simple. But in reality it is quite complex, and developers have to understand a lot to make wireless device-device communication happen. Not everyone can roll their own TCP/IP communication libraries that work 24x7, and few understand the creation of a central server that can broadcast events to all interested devices. Creation of thread pools, multi-threaded synchronization, programming in C++ etc. all make for interesting diversions but do little to solve the application level problem.
I guess what I’m trying to say is that even as little as 5 years ago, you had to do a lot of work to create the infrastructure. You had to understand a wide range of different technologies to make devices talk to each other reliably over WiFi.
What the imp does is simplify this considerably. You abstract away the layer of complexity that is required to make things work. You can call it dumbing down, but when you can, in a single day, create a system whereby 5 imps can reliably talk to each other and to web services of your choosing, I call that progress. You get to focus on your application on day one - you don’t have to develop the infrastructure first.
I too was a big skeptic and the fact that the imps needed to call home to the mothership was a giant concern. But I got over it pretty quickly and started drinking the cool aid once I saw how easy it was to achieve things that had previously been very complex and time consuming.
I do like the emperors new clothes!
@deonsmt elegantly put @krowden I’m with you, how I covet the e.imp platform for Lan based projects. It just WORKS you don’t have worry about OS updates, message delivery when your code crashes it’s re-starts gracefully the device run’s on 2 AA it’s in door WIFI range is way better than supposedly, better, low frequency wireless I used in commercial buildings.
Role your own: I’ve recently started using the Raspberry PI and node.js for integrating serial & ip based building automation devices and web services. I’ve spent weeks writing start-up scripts, getting a run time monitor that didn’t kill the PI, compiling dependent libraries, working through different node modules that didn’t corrupt my JSON store, finding socket.io sucks. And it works most of the time but that said I’m not a pro programmer. But I wish I had the imp for this task.
As the Auzzies say “no worries” that’s what you get and much more with the e.imp and boy is it worth it.
Its a easy and fairly good system for solutions where you dont mind internet connectivity being a absolute requirement, and you dont mind your data being sent to a 3rd party, nor that you will have absolutely no alternative during downtime (we recently had a 6hour downtime on the development server), and of cause that your investment is lost if the company were to shutdown.
You can still make some control with the imp in offline mode, over serial port for example, and it can still control projects, but theres no networked connectivity if the internet is down, or the mothership is not working.
It may sound like a turnoff, but the limitations are somewhat outweighted by the simplicity, you can have a wifi controlled device up and running in less than an hour including assembly of your breakout board.
The development console still needs some work with versions and modules, it gets messy fast, and I would like better control over when the imp can reboot for upgrades and when it cant, but that may just be because I didnt figure out how yet.