Q: Eclipse SH stack runs on a gateway alone?
Eclipse SmartHome is a framework, which means it is effectively a set of modular OSGi bundles. Solution providers can pick and choose these bundles and build their own solution on top of it. The open-source project openHAB is an example of such a solution that is based on Eclipse SmartHome. What is needed on the gateway is an operating system, a Java7-compliant JVM and an OSGi framework (such as Felix or Equinox).
Q: How energy efficient is it to run Eclipse SH on,lets say an ARM device?
The minimum recommended target environment for an Eclipse SmartHome solution is the RaspberryPi. The typical energy consumption is around 3-4W, which is very efficient. Other ARM platforms have similar specifications, so you can usually expect the power consumption to be way below 10W.
Q: What sort of software runs on end nodes? Custom firmware with ESH defined protocols?
Eclipse SmartHome’s strength is to abstract from specific protocols and hardware and to allow integration of all sorts of end nodes. This is done through „bindings“, which are the connectors to specific systems or protocols. Eclipse SmartHome therefore does not impose any software or protocols for end nodes.
Q: Will this run a NAS like ones from QNAP?
Yes, any system which is capable of running a Java7-compliant JVM and has at least 256MB RAM should be able to run the Eclipse SmartHome stack.
Q: Is it compatible with DLNA devices?
It depends. DLNA offers many different features and it can depend on the specific device what functions should be made available for home automation purposes. Many bindings already use UPnP for device discovery and for accessing specific functionality. A general UPnP support that can then be used by bindings is planned for the next release. There is no generic DLNA support in Eclipse SmartHome though and media streaming and handling is not a primary focus of the framework.
Q: What can you say about Openremote? Very similar technology.
It might be interesting to know that OpenRemote was actually thoroughly evaluated before the openHAB project was started in 2010 as its functional ideas are indeed very similar. Nonetheless, at least at that time, the technical architecture didn’t seem to be thoroughly thought through and its focus was rather to be a software universal remote control than an automation system. Another important difference between the projects is that OpenRemote is actually backed by a company with commercial interest, which means that you cannot easily use the code for your own business. Eclipse SmartHome is instead provided by the non-profit Eclipse Foundation, which actively invites companies to use and to collaborate on open-source for everybodys benefit.
Q: Hi, can you tell me something about the security options? Only the options in the .cfg are available?
openHAB 1.x comes with rather basic mechanisms: The HTTP server (optionally) uses basic auth for authorisation to the system. Once authorised, the user has full access. On the roadmap for Eclipse SmartHome there are a couple of enhancements planned: Role-based authentication will be possible and the framework will provide hooks for security modules of the solution on top. Furthermore, it is planned to harden the code base, so that it is possible to use it on a JVM with an enabled security manager. Through this, access cannot only be restricted from the outside, but even from the inside, e.g. for dynamically installed code.
Q: Do you expect to ESH to grow into an industry standard?
We strongly believe that the Internet of Things and Smart Home technologies in particular evolve too quickly to be able to define standards upfront through a standardization organisation. So driven by the huge popularity of the openHAB project, we decided to further evolve the framework at the Eclipse Foundation to encourage industry collaboration. It simply does not make sense that everybody who wants to build a home gateway solution has to start from scratch and deal with all the different technologies that are out there. The competitive differentiators should be the ones that come on top of this technical communication layer. We therefore think that Eclipse SmartHome is a very attractive project for home gateways and we are confident that it will find adoption in the market. If it becomes a de-facto industry standard, only time will tell.
Q: I did see some port of ESH on BeagleBone. Is this something that will gain support from Eclipse community? Maybe Pandaboard too?
Such platforms are definitely all relevant target environments for Eclipse SmartHome and we will do our best to ensure compatibility with all of them. Due to the number of different boards on the market, it won’t be possible to prepare and maintain sd-card images for them. Instead, we envision container images (such as Docker) that can be used as a packaging for different platforms.
Q: I want to know more about "persistence" part in the Eclipse Designer. Thank you.
The idea about persistence services is to export data in a structured way. It should be configurable, which data (e.g. sensor values or switching events) should be exported or stored by the system and with what kind of strategies (e.g. regularly on a timer basis, only on changes, etc.). What exists in openHAB 1.x about persistence services is documented on the wiki.
Q: How does it scale up? Is it already or will it be a feasible solution to run on public and commercial buildings?
Eclipse SmartHome and openHAB are primarily designed for private homes. Nonetheless, there is no strict line between the sizes of private homes and commercial buildings. There are openHAB installations with more than 2000 items running smoothly, so in general there should be no issue to use it in larger installations. There are also many openHAB-powered demo Smart Homes from research institutes and universities, so it has proven to be a stable and reliable system.