Why do imps have to go through electric imps agent for tcp communication

So, I have an imp. Really great product! It took two minutes to setup, and 5 more for it to do exactly what I needed it to do, including url POST/Get calls to my web app via the agent code.
Now, thinking of commercializing, I hit a wall. What happens if for any reason, the electric imp server ceases to exist? This could have a devastating effect on a large install base?
I am sure this business related topic has been discussed internally. Maybe some field input can influence decisions.
In my humble opinion, what needs to be done, is simply to allow the imp device to communicate directly over TCP. This doesn’t make the imp server obsolete, and it surely will effect my decision on using the technology.

There are other little wifi solutions out there, some are open source. None however, function as smooth and simple as the Imp.

This is by design, and will not change

@Gadi The Imp is a great product because of the Imp servers, not in spite of it. Electric Imp is a platform, not just a device. There are other devices available that you can directly communicate with if that is what you want to do. If you build products with EI, I think you’ll likely realize the extensive benefits of the platform.

@Gadi …including, for example, how are you going to connect to the imp directly when it’s behind a firewall? If your answer is “open a port and set up dynamic DNS” then you’re probably looking for something that isn’t an imp as you can handle that complexity yourself :slight_smile:

The confusion often comes when people see the imp and assume we’re a hardware company; we’re not. We’re a cloud platform company that happens to provide some kick-ass hardware to access the platform with, as the close integration makes lots of things better.

@Gadi,

I know where you are coming from, I have a flip video camera that was bricked by Cisco buying them and shutting down the cloud it relied on.

However I don’t think this is the same, I work for a company that provides an exclusively cloud product, as good practice (and the insistence of our big clients) there is 3rd party provision if we go under .

Given that imp also have huge customers, I am sure similar provisions have been made.

This sort of provision has been tried (and tested) since the beginning of software so given they explicitly have said they have it covered I would take them at their word.

Guys I agree with Gadi. Understand the “commercials” and “managed services” aspects of providing a platform, however, you should also provide the alternative as well to give customers the flexibility to choose what works best for their solutions.

The case in point that I want to callout is that for the past few hours the “platform” has been sluggish and slow and has timed out several times. The imp is a fantastic product but it also needs to be backed up with a fantastic and reliable “cloud platform” with guaranteed levels of performance. Sadly my experience to date is that the platform is still too immature to be able to support near real time solutions.

I am not sure what has caused the cloud service to become unreliable today, however my guess is that there may be background maintenance going on with the servers given I am in Australia.

Great product, hope we see improvements in the platform performance!

I don’t mind the concept of an agent – I think it’s a good way to offload work better done by a general purpose processor. However, am I seriously expected to build and sell “internet of things” devices to my customers that will only talk to EI cloud servers? That leaves my business totally at the mercy of the viability and success of your business.

If I buy 10,000 imps, embed them in my own devices and sell those to my customers, and then you (heaven forbid) go out of business, all of my customers are going to want their money back because the devices they bought from me just stopped working – and, because I’m NOT going out of business, I don’t even have the option of falling back on the “investment failed” very-small-violin-catch-all answer. I have to come up with a general solution, or I go out of business too.

To put this situation into my context – all I want to do is build a temperature sensor that can communicate with a server on my own network. Frankly, an agent is overkill here. I should be able to just send http GET/PUT/POST requests directly to any server on the internet.

If that’s too heavy weight for the Imp OS, then at least allow me to send TCP or UDP data directly to my own service. I can write a process in python or bash script that converts that to HTTP just like the EI agent does.

A third alternative is to make your cloud platform available for private installations – then I can run the agent code (and the IDE) on my own internal cloud. This is comparable to the way other internet SAS providers work – e.g., look at maven’s repo1 cloud for instance; you can also download and install a maven nexus server to run your own master repository. That’s just one of a hundred examples of this business model.

In retrospect, since I’m building a device whose heart and soul is the Electric Imp, my business is already riding to a great degree on the success of your business. But with a custom cloud, I won’t worry about all of my existing customers being shafted by someone other than myself.

Thanks for the great product.

We’ve been through this discussion many times before, but here goes…

If you don’t like the idea of using our servers, buy a plain wifi module - there are plenty available that can post to arbitrary servers on the internet - and do it yourself. We concentrate on providing a solution for what we believe are the problems that most device vendors face when making connected products. That means we will never provide a wifi module that doesn’t use our service, because we are a platform company that happens to provide hardware, not a hardware platform that happens to want to sell you a cloud service on the side. The imp003 module, which is neither made not sold by ourselves is a pretty clear example of this.

We’re very well funded, and have shipped almost half a million imps - the overwhelming majority of which are in commercial products and hence are with paid service. There are a lot of people relying on us staying around. I know “others trust us, you should too” is not necessarily reassuring to everyone, but having paying customers is a good thing and a sign that our business model is viable.

As for enterprise servers that you operate yourself (with client access licenses much like other enterprise software products) - yes, absolutely possible in the future, and essential for certain categories of application, and ditto for other options for continuity of service.

On the service: we have a great team, and we’re working very hard on this; do bear in mind that the free developer service is not the same service that commercial devices use and does have more outages/issues - for example, all developer devices are using our new Erlang connection server, and wringing out the bugs there has caused some issues over the last few weeks. We have had service-wide issues from time to time, and each one has resulted in service improvements as hidden issues are found and addressed. We’re also improving our communication on issues with externally hosted status pages and automatic notifications in the coming months.

Glad you like the product, we’re enjoying building it :slight_smile:

It all comes down on being dependent on some 3th party whatever the promises i think. This is always the case when u invest or find a new solution.
What made me choose for the imp was, that its already being thought threw from start to end.

The question should be , how long until Electric Imp is swallowed by a known player, then we should worry i guess.

Until now i’am greatly impressed by the Imp team and supporting coders, and hope they will keep this great new innovation possibilities happening for me, because there is a major market to be have’d, for those who know how to implement this half fabric to a end product.

Sorry - but one question: why should I attach each EI to another WIFI module to be able to use the local network (e.g. to communicate fast under each other or when there is no internet connection) when there is physically a Wifi existing? Thats not economic…

For me the biggest advantage is the platform based programming with the possibility to update devicecode and getting back status information.

For some of the same reasons that your laptop has a WiFi adapter and a Bluetooth adapter. The imp solves the problem of being a WiFi internet gateway, its up to you to sort out communicating with other local devices.

@led-emotion that’s just what the product is I’m afraid. It’s not designed to work for every single application.

@led-emotion

The reason you may use an additional wireless technology to communicate to an end device could be

  • You need something that is very low-cost because the end because the end product is price sensitive such as a connected LED lamp
  • You need an connection method standard wifi does not do such as mesh