I’m now preparing a paper on the recommended IoT solutions for a relatively big project and need to list few alternatives to EI. Have anyone compared current leading solutions by ease of implementation, security, level of support by various M2M services, etc?
The application assumes the solution doesn’t have to have a powerful processor or be extremely low-powered on other side.
Personally, EI is my favorite, but It would be very interesting to see what is the current list of rivals to it…
I’m (very very obviously) biased, but I believe imp is quite unique; there are lots of other services that connect things to the internet, but when you get down to actually needing to ship things, the competition often turns out to be lacking which tends to cause projects to stall or fail.
For evidence, look at the number of commercial devices that have actually shipped (vs just being announced) on the imp platform vs the others. Anyone who has shipped a product knows the difference between announcing and shipping… that’s where the real work happens. The design support we provide is second to none, and the platform keeps getting better with every release… there’s a lot more great stuff in the pipeline!
I can only speak from a hobbyist perspective, but I have tried other I’m devices, and always came back to getting an Electric Imp for the job.
The problem i had with other devices, was problems getting them to accept new code, too easy to corrupt their connection, and that way make it impossible to control and upload new code to.
The next that made me come back every time, was the agent. Being able to handle all requests and such to the outside world, without having to have the device do it, is just amazing and so nice to work with.
What I have seen people say, when they compare an Electric Imp with other devices, is their memory and such is much lower, which is also true. But the difference is that the Imp does not need all that memory, because all the memory heavy stuff, is done by the agent, and comparing the agent memory to the other devices, it is larger. And not only that, it also allows you to do multiple things at the same time. The device can do something that requires it to only do that one thing, meanwhile the agent can serve previous collected data, or fetch new that needs to be acted on.
The biggest problem I had with Electric Imp, was in the early days, where blink-up was very sensitive and caused a lot of unsuccessful blink-up’s. But as it is right now, I got close to 100% successful blink-up’s.
When formulating an assessment, I am biased by what I am familiar with in terms of development environment rather than just functionality and capability of a wifi module. All new wifi modules have steep learning curves first time round, so would suggest sticking to what you know if you have a tight budget / deadline, unless of course you are preparing to hire in specialised project development expertise.
A key step in determining options is to formulate core requirements as this will rule in / out many options. For example if there is a core requirement to have localised access to a device via device web server then the Electric Imp will not be suitable. If on the other hand there is no requirement for other devices to communicate with it via LAN and/or you require secure remote control of a device and/or seamless data transfers with a secure cloud server then the Imp is the one for sure.
So if you are able to list out some core requirements and this should enable some short listing.
Thank you, Hugo and everyone for the replies! The project is run by non-engineers and therefore all sorts of options are discussed: ANT, Zigbee-type of stuff, TI IoT gateway, Beaglebone, Raspberry, MBed, etc. My favorite is definitely EI, that’s why I wanted to list a few viable solutions and highlight all the pros and cons, so the right decision can be made without pushing.
My work colleagues look at the IMP as hardware when I demo my projects, but I explain it’s a platform to connect IO pins with web URL’s. It’s a platform with the security and O/S updates transparently done. Unbrickable with remote code push and can run for ages on batteries. That’s a lot of pros.
Anything that isn’t native IP (ANT, Zigbee, etc) needs a gateway to operate. That’s another box which takes power, needs firmware updates, and may have security issues
Linux boxes (Beaglebone, Raspberry) are fine if you want to do serious processing and are willing to put the time in to build the tools you need to maintain them… but most of the time, people use them because they’re cheap and familiar. Security requires thought, SD cards as root filesystems suck, and how do you update devices you have no physical access to? (some people are working on this problem, but I’ve not seen anything that goes down to the kernel layer and is fail-safe at this point).
If you’re deploying lots of these, you’re going to want signed & encrypted updates. Going to visit them or expecting the end users to update them really isn’t realistic.
Also, don’t fixate just on the device. Any device needs a server to talk to (especially if you want two-way low-latency comms and the device is behind a firewall or NAT). You need to work out what you’re doing there, and who is responsible for keeping this server up-to-date, secure, and operational.
Sorry I missed this thread earlier.
I have been doing the same thing as you @mym for over a year and have one set of experience already to work from.
Ditto @gerriko comment about local LAN and everyone’s comments about security.
I want to add that we have learned the hard way that we do not want to support our own cloud service. Our IT department has their own problems, putting some sort of cloud server inside their DMZ or asking them to manage a third part service causes many many hours of issues and is PAINFUL.
This is all caught up when you analyze the situation where your company stops selling the product (EG: Its not making money, or just its EOL). How will those customers who bought that product continue using it? How long will your product actually work in the field vs how long will the platform you have picked continue to be supported vs how long will your company have expertise to support the services. And how will all this be done if there is no money for the product (because its not making any).
Yes I’m mister glass half empty this morning! But that’s what experience does to you.
The imp platform, agent concept, price point and HW form factor is hard to matched as far as I am concerned. My only thing is Squirrel language (I am still trying to get my head around it) , whilst Squirrel has its obvious lean advantage and some would argue that it is better than slice bread, if an alternate imp language (C or other more common generic language) is made available it would attract more users. I am not sure what the strategic intent is for the imp market, but to further develop mass market, I believe a more generic language would certainly help. Keep it simple!
Ken
I think it is worth unwrapping this thought. In getting used to the imp one has to learn an extended version of C (but you don’t have to use the extensions), and to accept that it is interpreted by the host VM, and gain the wonderful richness of the event-driven environment. If you want to go back to pure C as a compiled language, you would be back to an Arduino-like environment, losing the event-driven beauty of the imp. I happy to learn a richer language to get the event-driven environment, as learning a new language is a normal part of life for developers. There is a lot of gain for the pain!
In terms of strategic futures, that lies in the use of the imp as an embedded processor in commercial projects at enterprise scale. We humble makers are a test bed and feedback forum, but not significant for revenue. For a commercial project or product to succeed, the time and cost of code development and test are paramount, and these have been shown to be much reduced on the imp platform. One developer makes a product that sells in its thousands, and whether the language is pure C or Squirrel makes no difference. What makes all the difference is the power of the event-driven platform.
My background is embedded C and assembly, with a dash of Java. I’ve found Squirrel a pretty easy transition. I still make plenty of mistakes with development and deployment and I’m grateful for a VM that allows me to recover from those mistakes. I’ve had imp units at client sites for a year. They have been remotely upgraded over a hundred times and I couldn’t have been so confident that I wouldn’t f**k it up if I’d done it in C. I work in parallel with web developers using node.js and I wouldn’t be able to keep up with them if I were working in a lower level language.
The performance of Squirrel on the device is a bugbear. We are somewhat beholden to electric imp to provide us with a suitable API for real-time access to I/O on the device. The Sampler and PWM are a start but it would be good to see more.
@gerriko are you looking for math.floor()? (ok, it’s not round to nearest int, but that’s just math.floor(x+0.5)
Some of what you desire can be done with libraries, but in terms of incorporating native code into our system, we’re pretty protective about that. Stability is very important for an OS deployed in the field - as @coverdriven says, you want to have some level of confidence that you’re not going to unintentionally brick a device. If people add good stuff to upstream squirrel then we’ll definitely look at incorporating it into future impOS releases - plus, it improves squirrel for everyone else. We feed back our bugfixes too.
Well over 95% of imps go into commercial products; as of the end of last year, we had shipped over half a million of them and there are many more going into the field every day.
Squirrel is indeed a bit different, but the things the VM enforces (event driven design, hard OS/application separation etc) are generally good things to have for embedded devices. One thing that picking a different language did - intentionally - was prevent people pulling old code (and hence design assumptions) into a new environment.
@coverdriven suggestions for HW APIs are encouraged
I think for Squirrel to be a real power house it needs to adopt the PHP approach of opening it up to the community to build in more powerful functions. Then simple things like, for example, having an inbuilt function that rounds float values gets incorporated quicker. I am sure there are many more math and common utility functions that could and should be incorporated into Squirrel.
Now that I think of it, Squirrel for Imp has to be rather unique in that it has to wear two hats. It needs to have broad functionality like PHP for the agent while compact and powerful enough for device such as maybe LUA.
Overall, once familiar with the documentation (it is the quality of documentation that often helps / hinders learning, not the language syntax), I find Squirrel a very good language with the some very handy features.
@gerricko, don’t forget, Squirrel is open source (MIT Licence) so it’s entirely possible for folk to contribute to the core language.
I’d also say that for adding functionality, this is also where Electric Imp’s libraries can come into play: write an advanced maths library, say, and share it with us so we can make it accessible to every imp user right in the IDE. We’re not yet at the stage where we can open up the sharing mechanism, but we can certainly share the code itself.
Yes (note to self) don’t make comment early in the day before checking facts… http://squirrel-lang.org/
I suppose what I meant to say is that it is about having the critical mass within a community to make something a power house like PHP or Linux - mind you it does take time.
Imp’s rational of using object orientated event-based Squirrel as coding base rather than something else is certainly valid. However, with these newer and smaller high-level programming languages there is always the dilemma of maybe dealing with slower than liked language enhancements from Squirrel(dot org) versus the ease of coding requests / application functionality pull from Imp & Co. and its clients. Either way I think the library solution (as noted by @smittytone) is a great plus and once fully implemented will improve things considerably. Hopefully Imp themselves are actively work with Squirrel dot org to continue to improve the performance of the coding engine / compiler down the line for embedding more optimised code on device side too.
Otherwise forgot to add that I agree with @coverdriven’s comment about how Imp really helps with speed of development and the ease of resolving problems especially during those early field testing phases. This is where the Imp ecosystem really makes life easier and saves considerable time and effort.
I’d be happy to make some suggestions. I’m not sure if the “Feature Requests and Bug Reports” part of the forums is the best place though. It’s dominated by posts about things that don’t work or pleas for help.
Regarding libraries, I also have a few things to put forward. As our code base has increased, I’ve used a queue class more and more. Queues are essential in real-time event driven systems and their use should be encouraged. My class is nothing special but fits most applications I’ve required.
@coderdriven - We are working on a formal process for external developers to suggest libraries (either libraries they’ve written that they think would be useful to the community, or libraries they would like to see us write).
Is your queue class OSS / can you point me to it? I’d be happy to take a look at it! We have somewhat strict requirements for code style, etc… but happy to work with you on that
I am commenting from a hobbyist perspective, and learning Squirrel is a challenge, a lot of it has to do with the quality and lack of quantity of documentations, guides and examples out there compared with other generic languages. The imp staff have certainly helped with some improved documentations recently.
The biggest strength with imp from the support perspective is without doubt the community and this forum. Since the beginning the forum is active, responsive and helpful (to novices alike), both from the community and the staff. This is one reason why I keep coming back. May the forum thrive.
Ken
In a spirit of enquiry - and because it might lead to new areas of documentation - what are folks’ concerns with Squirrel as a language? From my perspective, its barrier is more psychological than actual. People haven’t hear of it, so assume it must be esoteric or difficult. But as a C and Objective-C programmer, it found it very straightforward. So what conceptual issue do people here have? The use of callbacks? This is done on lots of platforms. The event-driven aspect? Ditto. The object-orientation? That’s just Java, C++, Objective-C etc.
As I say, I’m not trying to be disputatious here. I’m genuinely interested in the difficulties people have, as that’s the first step in working out how to help them out.
Barriers you refer to have more to do with individual’s having different learning styles, hence a one size fits all approach seldom works.
Documentation needs to incorporate better structure to help people navigate from knowing very little (I know I initially struggled with the “getting started guide”) through to searching info on more complex aspects (e.g. use of bindenv() - I have still to figure this one out). It also needs to include a range of different examples from the really simple to the more obscure. Too often in your documentation the same example permeates through a range of different imp functions which does not offer variety (I know I need to see a few examples before the penny drops).
Not everyone grasps textbook explanations immediately and hence suggest mixing it up a bit with a range of media options such a videos (Jeremy Blumm Arduino youtube series spring to mind as an example that helped get many up and running with Arduino quickly) and possibly short webinars / a walk through guide (I know pubnub had a webinar very recently and it really helped frame how their system works). On a plus point I think your blogs giving more detailed explanations on particular aspects (e.g. explanation of how to round values) and applications have been top class.
Anyhow hope you find these suggestions worthy of consideration.
