http://www.engadget.com/2012/06/21/insteon-says-apps-are-better-than-switches/
This is really about the bulb and the protocols, not about the app.
While I do use Insteon because it is available it is clear we need new protocols that are true peer protocols. Insteon does provide devices with stable identifiers instead of transient network addresses as in IP but their protocols are tied to their silos and transport. I have other issues with the Insteon but that’s a topic in its own right. For now using Insteon is a valuable learning experience and it is useful.
This does make my standard example – connecting a light switch to a light easier. I have had to say “light fixture” because “everyone knows” you don’t send the message to the bulb. Now I can just say that you need a stable relationship between the light switch and the light bulb itself. Current Internet protocols can’t do this because there are no stable identifiers. V6 doesn’t solve this.
Instead we need peer protocols that start with the application needs and aren’t dependent upon service providers nor any particular networks including IP.
BTW, the idea of putting smarts into the bulb makes a lot of sense for LEDs because they last a long time so you can amortize the cost of the smarts. Of course, once we get volume, the costs will become trivial.
There is still a reason to make the fixture smart – you typically want to ask for light in a place rather than having a relationship to the bulb itself. This is another reminder that the end point isn’t a physical place but dependent upon the context and relationship. The end point is the fixture and the bulb beyond it is also an end point. We can go further and say that the real end point is “light this area so I can see my food but not see it too well” but now we’re getting into far deeper (darker?) issues which is why the question of “what is a light switch” has become so hard to answer. And why we can’t answer such questions in the network nor as a service. (http://rmf.vc/IPGENI).
