Need the IMP to accept an HTTP put/post directly (not through a cloud based agent)!

Device Code
1

I need to send local HTTP commands to the IMP to do very a few simple relay operations (close for X number of minutes, then open). For security, latency and reliability reasons I need to send the commands directly to the IMP from the local subnet it is sitting on.

It seriously confuses me why this isn’t a very obvious option. I will be quite disappointed if this isn’t possible (there really is no reason) and if not it will force me to use another solution all together.

I don’t care if I can only monitor a single HTTP put type variable, just need it to happen locally (IP address of the IMP is totally fine). Much like the Agent call format you can use…
https://192.168.1.55/AbCdEfGh123?relay=1

Any input is much appreciated. Thank you - Ryan

2

Sorry, Ryan, but this isn’t a supported mode of operation on the imp. All device communications go through our cloud service, for reasons of security, among others.

3

You can do this sort of thing with the Spark Core, and that is the only communication option with the Core - that is why I dropped the Core and prefer to use the electric imp. Your Core device code has to handle all http comms.

I find the imp’s ability to use the agent code to do all the internet comms, offloading from the device which is handling the real world, to be a superb design for most of my purposes, as I never want to talk to my imps locally. I talk to my imps from a PC, iPhone or iPad, and I am happy to go via the agent as the latency is a fraction of a second.

If you really need to talk locally over http to your device, the imp is the wrong choice for this project. But hang on to it for other projects, eg. a device at home that you need to monitor and control remotely over the internet.

4

I find it very strange that as an IoT device this can’t talk IP to a ‘thing’. For IoT devices that natively use TCP/IP (or HTTP) for communication, your telling me you can not use the IMP (something native to it’s WiFi hardware layer for the most part)? That seems as crazy as requiring a secondary device to connect a single wire to the cloud to talk to the IMP for a pin state.

I can see many applications for the IMP without this functionality but I think what is most confusing to me is why the limitation??? As more and more devices have native Wifi built in and will be connected to the local network, the need for wiring to a device to make it IoT or enhance it lessens every day. Requiring the cloud based agent is only limiting the TAM this device applies to.

About security - I do not consider non-expiring, non-authenticated linkbacks for triggers in a cloud service to be secure. Is there a good post or FAQ somewhere that might convince me connecting an imp to a locking mechanism for a residence front door and actuating it through the cloud based Agent model is completely (I know nothing is absolute here, but I think you understand the ask) secure?

I would think it would be much easier to allow local TCP/IP comm (even unauthenticated) as opposed to incorporating a real security model in to the existing Agent structure. Again, why not give the dev the option. This can be extremely simple, very much like the Agent link back structure in place today, even limited to simple variables or integers.

A good example here is iTach - an IR to Wifi gateway. I can send TCP/IP commands directly to the iTach to transmit IR codes. I could NEVER use the imp with it as the latency would be ridiculous and unacceptable (and I have 100Mbps internet service).

Reliability is also a critical area here. How is one expected to make a robust product that people can rely upon but their upstream internet provider is the weak link? I mean the home automation market / home security market alone is huge here and I can’t imagine allowing certain aspects of that to be cloud dependent or cloud operated.

The best part is with the cloud based IDE model, you guys should easily be able to make this an object that dev’s can include, so those that don’t want the overhead of local / direct TCP/IP support don’t need to add it to a project.

Sorry for what might look like a rant. Don’t get me wrong, I really like the imp, just disappointed to see somethings potential be intentionally limited, especially with a massively growing natively connected market.

Is this something that is at least on the roadmap? As a very early adopter of all things tech and someone with a passion for hardware integration, I would be more than willing to talk with someone at imp if they want more of my thoughts in this area. Just let me know :slight_smile:

Thank you,

-Ryan

5

I can understand your perspective, Ryan, but I think you’re missing the key point: the device in which the imp is contained is the ‘thing’. The imp turns a non-‘thing’ into a ‘thing’. It’s the very device (we hope) that will be used to give devices WiFi and compute power. It’s not somehow separate from all these WiFi-connected devices, it’s the very thing that’s bringing them WiFi connectivity.

BTW, we have never said the imp is the solution to every IoT application.

Broadband reliability, incidentally, is an issue for all IoT applications. Even cellular isn’t 100% reliable. But these weak points can only improve as technology develops. And there’s nothing to stop the developer of an imp-based device building in a secondary connectivity mechanism for back-up.

PS. I’m sure Hugo will chip in on your security concerns.

6

I got a Spark Core, and a few Electric Imps, and I don’t see myself getting another spark core.

With the Spark Core, I am forced to learn how to make it GET a url and handle the data, without making it drop offline (which I worked quite some time on getting to work). At the same time I also had to make sure not to use too much memory with the stuff it got from the page it made the GET request to.

When pulling data out of it through their api I ran into problems again, because I could only make it show one value for each request I made to it, if I wanted more, I had to come up with a format so I could put them all into one string and show that. The problem with this is that I could no longer use some of the pages I used, because they could only decode json. If I wanted the same amount of readings out of a spark core, as I get out of my weather station imp, I would have to make 15 calls to the spark core… yes 15, every 2 seconds… At the same time there is a token needed to read from the api, which expires every 90 days. That would mean I would have to go to the different pages I use the readings on, and update the token. The next problem is that the same token is used for controlling functions through the api to the spark core, so giving read access, also gives write access. So while it is secure with a token, it isnt secure at all because it is also used to access the functions.

In my weather station project, the agent shows json with the different readings, and then I made my own token system for when functions are tried to be accessed.

So with Electric Imp you are more in control over what kind of security you want, and how it should work. :slight_smile:

7

@systemone we made certain decisions with the imp, and one of them was no local communications.

This reduces the attack surface, means there’s no error-prone (and security-bug-prone) parsing happening on the device, and generally makes the product simpler and more robust. We’re trying to do one thing well.

Bear in mind that we were absolutely NOT trying to make a standard wifi module; there are plenty of those already. The aim was (and is) to make a platform that allows devices to become true peers on the internet - not on a local network.

You can, in an agent, implement any amount of authentication you want. You can enforce HTTPS requests only, HMAC sign each request, etc etc. This is purposely left to the developer as each application is different, and there may be needs for a mixed security model. There are several commercial companies using imps to power access control systems (locks and door releases).

Are you sure the latency is intolerable? Admittedly, I’m on the same coast as the imp developer servers, but I see <100ms.

8

Engineering is like a series of trade-offs. One of the trade-offs here was to go through Imp servers in order to save lots of headache with end-user firewalls, security, and just improve end-user experience in general.

There are other products that do what you like, and can access the web directly in either direction. I use one of just about everything for some reason or another, be it that one product is a better solution for a given problem, or just because I haven’t used a certain product and want to give it a try. All of them chose different trade-offs in their products.

It doesn’t really make sense to get mad about it. It is what it is.

9

I appreciate the feedback and I am not mad at all (trust me, I very well understand engineering tradeoffs). I just see a lot more opportunities to solely use the imp if local comm was an option.

@Hugo - I should clarify that my latency concern is more of a perception issue when it comes to direct feedback / control of a local object. RTT to the agent makes interaction seem sluggish under circumstances when the user is expecting immediate response to input. Local comm would overcome that.

Thank you all for the input and feedback :slight_smile: