Can we create a simple home automation system where i need to control things(fan/light) ( without an internet connection) using IMPees .??
You can, @saikiran, but there’s not much value in doing so. imps are designed specifically to talk to the Electric Imp cloud, which mediates their interaction with the wider world, whether through apps or web pages. Without the cloud connection, the imp itself can only do what it’s has been programmed to do, and can connect to physically - which kind of defeats the object of smart, connected devices.
You might connect imp to your fan or lights, and to a Bluetooth module, and control it that way. But that’s a lot of code you have to write that you get for ‘free’ using imp agents.
And of course you’ll still need to connect the imp to WiFi and the cloud to download the firmware you’ve written; imps can’t be programmed directly.
Not only that but using the web as a front-end allows you make use of lots of existing website code for making a great looking, functional app.
It also makes connectivity testing as easy as asking “can you open your favourite website”
Can I make a wireless network within the home where i can have a central controller (which creates a local wifi “again without internet” ) which can control other IMPees in the network ( inside house ) wirelessly … switching ON/OFF from my mobile … Also a bit of sense&send work.
Actually my entire system(network) would generally have internet access but I want a system that should work if the controller is within its range. ( not necessarily via internet)
Thank you so much for your time … 
@back_ache @smittytone
Sorry, but that’s not really possible at the moment, @saikiran. An imp’s wireless communication is currently mediated solely through the server:
app -> server agent -> imp, and imp -> server agent -> app
It might seem odd to do that when app (or, rather, the phone running the app) is on the same WiFi network as the imp - ie. the system you want to set up - but it does mean the imp can be contacted by the app when it’s remote and connected to the Internet by cellular not WiFi. But, yes, it may become an issue if your Internet connectivity is intermittent.
You could add a bluetooth module to your Imped devices and have your app and devices communicate both locally through that, and use the Imps as controllers and an internet gateway. You could actually set up a bit of redundancy that way. It is probably a good idea for home automation where you wouldn’t want to strictly rely on WiFi.
For example, my garage door is Imp-enabled and I prefer to use an internet connection to control it, as it allows me to do so from anywhere. However, if my WiFi network were down for some reason, I could have my app configured to fail over to using bluetooth.
The Imp was very specifically designed to be used for internet connectivity, but that doesn’t mean you can’t add components to your design to also communicate locally in some way.
My Two Cents:
I too have been wanting this capability - a way for imp to imp communication locally for when the internet is down/slow.
I envision that Electric Imp (or one of the partner users, like Quirky) could make an "imp aware WiFi router’ that would be able to download ‘server code’ from EI that would run on this ‘router’. EI could provide an API such that the active agent code knows if it is running on the EI server or on the local ‘router’ (and act accordingly). Any interaction from your Phone/Computer App that is performed ‘thru’ the ‘router’ (i.e. you are at home) would be ‘intercepted’ by the ‘router’ and performed by the ‘local agent’ (with maybe message updates sent to ‘remote’ agent). When out side the home (or communicating via 4G/3G, i.e. not WiFi) the messages would go thru ‘remote’ agent (as they do now).
In addition, this ‘EI router’ could also have the ability for a ‘master control program’ (i.e. maybe it would have it’s own Imp) that could ‘monitor/intercept/manage/initiate’ communication between Imps in the house (connected to this ‘EI router’) - this would allow programming of if/then type of interaction as well a scheduled actions, etc.
The whole power of the emerging ‘Internet of Things’, in my opinion, is connectivity (i.e. the interaction of my connected things to help me out). But the EI structure is more about ‘this one thing’ and my interaction with it than ‘these many things’ all interacting with each other (and me). If I/we get to the point of having 30+ items in the home that are internet enabled I certainly do not want them all communicating among themselves by sending messages outside my home, needlessly using internet bandwidth when the devices are on the same node of my intranet.
The way things are now (with EI) is like having to go thru an external server to print a document from my Laptop to the printer sitting in the next room. Or watching a movie from my server computer on my TV connected computer but having that movie have to go out to an external internet server and back in to my home…
I understand EI’s business model in having communication go through an agent on their server, but I think that they could devise a scheme to give us the best of both worlds.
There are a lot of controllers you can use with that functionality. Why use an Imp for that?
@wfidrock In general, I’m a believer in two core concepts:
-
people’s internet connections getting faster and more reliable. Latency, for most users (esp. for our users in the US), is already at a point where a round trip to the cloud is imperceptible. As we deploy servers around the world, this’ll be the case for more and more people. Bandwidth use by imps is negligible and will become more and more so over time.
-
devices just won’t be able to function effectively without internet data. “Local control” is not where IoT adds value - that’s simple home automation. You can see this with things like Rachio or Nest, where their ability to do a good job depend on access to weather data.
We could absolutely add local comms APIs. However, this is not something to be taken lightly, because it could result in attack vectors from the cloud - a device whose manufacturer account was compromised (even just by social engineering, or a disgruntled employee of the device company) could have code pushed that launched attacks within people’s firewalls. Right now, that’s not possible.
As for integration between devices, this is a way off because manufacturers generally are not at the stage where they welcome this - see nest’s very late open API as an example. It exists for white-label ODM goods (see smartthings) but to most manufacturers launching their first connected products and concentrating on user experience, the thought of “losing” their end user interactions to a third party service is fairly scary. Over time, it’ll come, but everyone has to get comfortable with the concept first.
@Hugo we know your busy but would love to see the odd post by you just like this one e.g. nothing you will be held to like a release date just how your seeing things from time to time.
You need something like the flyport … the wifi version …
http://store.openpicus.com/openpicus/prodotti.aspx?cat=9
It is it’s own embedded web server with wifi. It controls I/O from it’s own webpage that you create. No cloud. Learning curve is harder than the imp.
@controlCloud the problem is that I keep promising things then I get beaten up by the people who have to implement them
@Hugo - Ha! Reminds me of my recent past as an Applications Engineer for Semicon. Test company; sales kept promising customers what the equipment ‘could / might’ be able to do and then Apps. had to make it happen!
I do see your points, about security, control speed. The biggest issue / concern I have is that EI based products become pretty useless when my internet goes down… Yes, ISP service is pretty reliable for many folks, especially those in highly populated centers / cities, but for quite a number of folks this is not always the case.
As for security, why wouldn’t an EI designed/specified ‘gateway’, that was using an EI internally for it’s internet/intranet communication, not be as secure as any other EI? The ‘internal OS’ would just expose an API for communication messages between devices registered to the same account.
And although I agree with your statement about many IoT devices needing data from ‘the cloud’ there are many use cases where the interaction between devices do not require this. A simple example involving a ‘smart thermostat’; the thermostat has already queried the ‘cloud’ for a weather forecast and has a temperature measurement from it’s built-in probe, it now wants to query some remote temp. sensors in the home, and then turn on some local ceiling fans to help in air circulation. All this would break down if the internet connect gets lost (so the fans continue to run even when not needed anymore). If there was direct communication between local devices then the only ‘loss’ in the above scenario is the ‘cloud’ data for weather forecast - the internal system could still query temperatures from other devices around the home and control items like fans, etc.
I still contend that the real power of the internet of things is the interaction of those things.
Thanks for your insights Hugo!