Imp to Imp Communication question

In the community blog post: Imp to Imp Communication the Agent URLs are hard-coded. Just to get a feel for how this might play out in a commercial application, how would devices be identified and introduced to each other?

For a commercial app the way I would tackle it is a three-tier approach, I would keep the front-end light and just about the user, the hardware tier just about abstracting out the underlying hardware and my core logic in the middle tier.

Both the middle and front-end tier I would host myself and the imp as the hardware layer, so the end user will never know know their imp ID

That’s my two-cents but people though that are actually doing it commercially I’m sure will have their own ideas

OK, I’m finding it tricky getting a foot-hold here. Assuming I could create an Android and iOS app to integrate the imp SDK (currently a minimal requirement for commercial deployment) after blink-up how might a user identify their own gadgets - each of which will presumably coexist along with numerous others in a database held on my server?

It looks to me as though a unique token representing the device ID has to be presented to the user in order for them to manage their gadgets - the presentation of which still necessitates a display of some kind (cementing the smartphone requirement ever more solidly).

Or might it be possible to identify the user’s IP such that the user can see their own devices when they log-in to their CP (running on my company server) from the same LAN as the device(s) they own? At this stage they could “claim” the devices and secure them thus acquiring access permission from any IP addresses. This would require my agent code to be able to read and forward-on the IP address to code running on my company server - but I couldn’t spot anything like this in the documentation.

I don’t know about how a unique id of a commercial imp is reported but am sure you want to avoid a customer seeing it, I would think you would want your back-end server to manage the mapping and have the user login with your own or (ideally) an existing 3rd party id they have such as facebook or google

I would think as much a possible you want to keep the front-end light and have the “heavy-lifting” done by your back-end

Using an IP address as an identifier is problematic as the net’s heavy use of network address translation will mean often people will report exactly the same address range!

I get the problem with dynamic IP but I was trying to imagine the initial device claim as happening with the user browsing to the gadget CP on the same LAN as the unclaimed gadget and somehow being able to detect this at some level. Once again it looks as though the application-specific smartphone app is the only practical way to achieve this.

@iceland - The BlinkUp SDK does a bit more than the BlinkUp app provided by Electric Imp - namely, it returns some extra information includes the device’s Agent URL.

There are two general approaches that we’ve seen:

  1. Create an app that interacts directly with the device through it’s agent (by making requests to the agent URL).

  2. Create an app that interacts through your servers using the agent url as a primary key / token in your system to identify the device.

Personally, my favourite approach is to use Firebase to map a user (this could be a facebook or twitter account) to a set of devices s/he has collected. If you aren’t building a commercial app and all the devices are “yours” then its even easier with Firebase as you only have one user.

Check out this post. This is mostly targeted at application developers (i.e. with the BlinkUp SDK) but it really doesn’t matter.

If you’re using an app, you can also use the app to link devices together.

eg, I blink up a sink device. The phone gets the agent URL and the agent says “I’m a sink of type X”. Then, you blink up a source device. The phone gets the agent URL, the agent says “I’m a sink of type Y”.

The phone can then ask the user if the devices want to be introduced. It can then call the appropriate APIs on each agent and pass the other’s agent URL and tokens if necessary.