I would love to see an open API. This would give a lot of power to the end user if they wanted.
I would agree the price of tablets are low would love to setup my own frontend and use API's to control stuff.. that would give more functions then the keypad..
Thanks for the suggestion. This is something we have discussed internally and would appreciate more feedback on while we assess.
An open API is something that may be on the roadmap for Iris, although it's not currently a top priority for the business.
An open API would be key to getting other devices able to work with Iris, as well as allowing additional help with the development. Or at least a documented API even.
Changing the status to this suggestion to 'needs info' as we'd like to gather more information on use cases.
Here are a few "off the cuff" ideas:
It would be nice to have access to device list/status.
It would be nice to be able to register a web hook, or subscribe to a topic to see events for my places.
It would be nice to allow an external system to be defined as a virtual device and trigger events (contact, motion, safety, security) that could then be used in rules.
It would be nice to be able to subscribe to data values so the information could be used by other systems.
It would be nice to allow external system to set/clear presence.
It would be nice to be able to query Event History.
It would be nice to be able to set brightness and color for a collection of color bulbs.
+1 for everything mentioned, plus subscribing to triggers or being able to check or set status of home/away and unlocked/armed
Number 1 use case: Reaching parity with version 1. I used the API before all the time to interface with my other home automation systems (mainly UBP light switches). It allowed me to trigger actions with my light switches (controlled through my homeseer or OpenHAB server) based on various Iris sensors firing. At this point, I have to resort to crude email listeners to wait for an email to be sent from the iris system to my email address to trigger the events in question. With an API, it allows for a much more seamless interface and experience. If for no other reason, the API should be be created to allow better interfacing with non-Iris systems. There is so much fragmentation in the home automation space right now, and companies are realizing that and working to interface with each other better. If Iris can't do that, or make the platform exstensible enough for people to create their own custom integrations, then they are dead in the water.
Also, working in the insurance industry, and looking at ways to use smarthome hubs in loss mitigation (i.e. - leak detection, water shutoff, smoke detection, intrusion detection), we were very seriously interested in using Iris as the system for our insureds. That was with version 1. When version 2 was released, however, that all changed. The absolute main reason that was the case was that the API was scrapped from V1. There were a couple data analytics calls that we were looking at and planning to implement that relied on that API. With that hit, we started looking elsewhare and are now developing a system based on SmartThings. Lowe's draconian stance on an API and an open ecosystem for the Iris platform has lost them a fair amount of potential business, from homeowners to businesses alike. Hopefully, they are now realizing this and will begin to open the platform back up.