I want to achieve the next feature with imp: get periodically some data from a public webserver (xml or other custom feed) and do some actions based on it. What is the recommended way to do it?
The current http get/put vimp is a end-user nightmare - good for tests but not good at all in a product. Also I don’t want to involve a dedicated webserver in this - would prefer to run everthing on the IMP servers and the imp itself exactly as Hugo likes
And here are some vimp questions (connected to this issue):
Does the imp will be able to gather web data (through imp servers) but without a vimp? (through squirrel api calls)
Does a future vimp be able to gather the required info periodically, parse it and send it to imp?
Will it be possible to automatically load a vimp together with a given type of impee and connect them automatically without user interaction? Right now the http vimp has to be added manually, the arrow has to be dragged and all this thing is the perfect end user nightmare. I understand the necessity of this interconnections in many cases but in some cases the extended vimp functionality should be automatically loaded with the impee to which it belongs …
When the custom vimp possibility will be available? One of our first devices is ready, just the code is a question so I would need a good solution for this kind of extended functionality …
Yes, the current in/out are not designed for products. They were just placeholders - simple for us to implement and enough for people to get I/O in a pinch.
“Vimps” are now called “agents”.
No, the imp cannot talk to the web at all. It can only talk to its counterpart agent. The agent has squirrel APIs to both send and receive HTTP requests, but the imp does not. This allows for a cleaner embedded implementation.
Yes, they can do this.
The counterpart agent to an imp automatically gets loaded. There is no “planner” environment for end-users, the end users do not even need an electric imp account. Both the imp firmware and agent can send each other named commands which will call handlers in the code.
We’re soon entering testing, but the beta group (already selected) will get this functionality first. When we’ve worked out all the wrinkles - including with the new IDE which allows you to work seamlessly on both imp firmware and agent - then it’ll be rolled out to the general userbase. When we’ve started the betatest then we’ll have a better idea of how close this is to release.
So the imp’s counterpart agent will be the best way to get/parse web data and send it to the imp.
Now I have only one question left - can my developer account get into that beta tester group?
It would be nice releasing some kind of flowchart about counterpart agents, external agents, imps, GUI - where it’s squirrel, where it’s something else, how they interact …
I do not need exact stuff which will be final probably only at release time, just to have an idea how the agents and also the user gui (also very important) will work, interact to not design something which goes in opposite direction …
We have prototypes ready (on my desk, hardware already working) so it would really important to know as much as possible about this things … If You want the signature of some NDA or whatever else we can work that out as well just let me know what we can do to get things better …
There will be documentation showing how this works, but here’s a quick rundown…
There’s no user GUI for the M2M product at all; the end user never sees the electric imp site. The flow is something like this:
The vendor enrolls devices at the end of their production line, using an enrollment imp (any number of imps can be nominated for this task by the vendor). This associates a hardware revision with each device’s unique ID. The enrollment code can perform factory tests, calibration, etc, and the vendor can monitor the factory process, pass/fail rates, and so on through their imp dashboard.
The user gets the device, and uses the vendor’s app to blink it up (the vendor has built our blinkup libraries into their app). The vendor can pass a 64 bit ID during the blinkup process which can uniquely identify the user doing the blinkup (this makes it easy for the vendor to associate a device with a user’s account on their server, for example). This bit is called registration.
The device connects to the imp service, and loads the appropriate software release for that hardware revision (the vendor can roll out updates by hardware revision as needed during the product’s lifetime). The imp service can call a webhook on the vendor’s server, passing the unique ID from blinkup along, closing the loop with the vendor.
The counterpart agent is automatically started, which also knows the unique ID for communication with the vendor’s server or app. As noted before, the agent can make and receive HTTP requests, execute periodic tasks, cache small amounts of data (eg: the agent might cache 24 hours of temperature data for an environmental sensor imp that’s sleeping most of the time, so that an associated app can always view the latest data… without the vendor needing to run a server at all).
The vendor can see how many of their devices are online, registration rates, etc on the imp dashboard.
The vendor can view connection history, signal strength, etc either using the imp console or via API calls. This helps the vendor with customer support tasks, allowing them to see if a device has been having problems with connectivity, last connected time, etc.
As you can see, the UI you provide to users is totally up to you, as this is very application-specific… but we provide all the behind-the-scenes stuff to ensure you can build pretty much any type of application quickly and easily.
At a certain point was a possibility to have user GUI made like the vimps/agents hosted on your servers. Now as I understand this will not happen (or at least not in the close future).
This means all of the user interaction has to be done via a dedicated webserver maintained by us or via some kind of custom Android/iOS app. Right?
Example: a relay might need some interface to switch it on/off. Or could have a simple scheduling configurable by the end user. For this we either maintain a dedicated web service either we write apps on every OS we wan’t control. Right?
Sorry for bugging You with all this questions but we need to see the complete picture to know what part of the development will sit on us, and what will be given by Your solution. Ty.
Correct. The agents are for data I/O, not to replace a webserver. You require a custom iOS/android app to do the custom blinkup, though we provide sample code for this.
So beside the custom GUI (where it’s necessary) we will need a custom blinkup app …
I think You should consider to make a common version of the blinkup app since many of us might not want to deal with google store/apple store painfull process if there is any other way …
The GUI can be made as a web service which runs on every platform but the blinkup app is a different story unless You give a browser based version of it …
Thanks for the details about Agents.
I was wondering about the enrollment imp you mention. If I understand you correctly it’s intended to be the last step at the end of the production line… and is has to be connected to the internet?
None of the EMS suppliers I’ve used in the past (in Denmark, Sweden, Scotland and China) have allowed internet access in any form on the production floor, and especially wifi has been a big no-no, so I fear this will be a problem for many of your users.
Or did I misunderstand the intention behind the enrollment imp?
Happy Christmas to all of you on the imp-team!
They need wifi on the production floor, yes, though obviously it can be seriously restricted (secured with a password, allows only one port, one IP) and has incredibly low bandwidth requirements.
We’ve not had any issues with factories in China managing that for any of the products that have been produced so far, though as you say it’s an unusual request right now. Not likely to be very unusual in the future though!
On the upside, you get to see what the factory is doing… that’s often something that vendors would like to know
Thanks Hugo. I hope it won’t be a problem for anybody. Just wanted to rise the awareness.
And, yes. The further away from you the EMS is, the nicer it is to have some inside insights.
Looking to the imp dashboard idea remembered the business model of monthly fee payed by the vendor (instead of user).
This model is great for big suppliers who sell many thousands of devices where the monhtly fee is covered in the price of the device itself and having the infrastructure with custom webserver, custom apps, even collecting monthly fee is not an issue.
But what will happen with small batch of devices (pilots, exotic fun stuff) where we would not like to create the infrastructure for supporting monthly fee, our own blinkup app etc. just rely on Your functionality. Is it possible to have some kind of cards where all this pain is done as it is now with the developer cards? Maybe prebuy a certain time of support directly when buying the card or any other solution which doesn’t push so many functionality on our head for relative small batches …
What are the business models You want to follow? I know it was some chit chat here on the forum but everything changes and there were no clear statements. For example the missing user GUI support which was in plan with a “maybe” few months ago does hurts (or maybe I missunderstood something). I understand the product is new so nothing can be stamped since it’s developing and changing but we would still need some guidelines about our possibilites. The answers You gave here are cleaning up things but I still need some cleansing around the business models
There’s an option to pre-buy 5 years of service, which helps smaller suppliers or those who just want to roll service cost into the BOM.
More information will be up on the website before CES.
Not sure what you mean by “missing user GUI support”?
The 5-year prebuy is a good news indeed …
At a certain point was some discussion about user GUI. Example: a relay is needed to be switched on/off from the web - this needs a user GUI either via app, either via browser based gui.
At that time You said there might be a new tab in planner or the ios/android app containing some sort of gui with some graphical components. Here it is the discussion (one of them):
Or this is still in the plans?
That cross platform interface what You mentioned there was one of the good things what we are waiting for …
That “user GUI”, which allows integration between various vendors devices and also gives vendors options if they don’t want to do the whole app thing, is coming later in 2013. It’s a phone-centric app though, not a planner tab.
There will be more of that later next year