极客看过来，开源的家庭自动化方案——openHAB

http://www.iteye.com/news/27585

https://code.google.com/p/openhab/wiki/Architecture?tm=6

openHAB全称为open Home Automation Bus，即开放式家庭自动化总线，该项目旨在为家庭自动化构建提供一个通用的集成平台。 

openHAB是一个纯Java打造的开源项目，完全基于OSGi（Open Service Gateway Initiative），并使用Jetty作为web服务器。Jetty和Equinox OSGi运行时一起构成了openHAB的核心基础。 

openHAB的设计是厂商中立的，且与硬件/协议无关。 openHAB通过绑定，汇集了不同的总线系统、硬件设备和接口协议。这些绑定可以通过openHAB事件总线发送和接收命令，并更新状态。 开发者可以在openHAB的基础上设计独特的操作界面，以开发自己的家庭自动化系统，或者利用其他技术来创建设备的新的控制方式。 

目前openHAB的最新版本为1.2，据悉该版本目前绑定的家庭自动化设备和系统已经达到30种， 其中包括Homematic家居控制系统、飞利浦的Hue照明系统、DMX 照明系统、Koubachi植物养护系统等，并支持NFC（近距离无线通讯）功能。 

相关演示：  

openHAB项目在GNU GPL v3协议下开源，项目地址 ： https://code.google.com/p/openhab/  

Overview

The openHAB project is split into two parts

openHAB Runtime

The openHAB runtime is a set of OSGi bundles deployed on an OSGi framework (Equinox). It is therefore a pure Java solution and needs a JVM to run. Being based on OSGi, it provides a highly modular architecture, which even allows adding and removing functionality during runtime without stopping the service. Here is an overview over the main bundles and how they depend on each other:

Communication

openHAB has two different internal communication channels:

The event bus is THE base service of openHAB. All bundles that do not require stateful behaviour should use it to inform other bundles about events and to be updated by other bundles on external events.

There are mainly two types of events:

All protocol bindings (which provide the link to the real hardware devices) should be communicating via the Event Bus. This makes sure that there is a very low coupling between the bundles, which facilitates the dynamic nature of openHAB.

As a technical foundation, the OSGi EventAdmin service is used by openHAB. This is a light-weight and ready-to-use pub-sub implementation, which perfectly meets the requirements.

It is important to note that openHAB is not meant to reside on (or near) actual hardware devices and as thus to remotely communicate with many other distributed openHAB instances. Instead, openHAB rather serves as an integration hub between such devices and as a mediator between different protocols that are spoken between these devices. In a typical installation there will therefore be usually just one instance of openHAB running on some central server. Nonetheless, as the OSGi EventAdmin service can also be used as a remote service, it is possible to connect several distributed openHAB instances via the Event Bus.

Not all functionality can be covered purely by stateless services. Out of this reason openHAB also offers the Item Repository, which is connected to the Event Bus and keeps track of the current status of all items. The Item Repository can be used whenever it is necessary to be able to access the current state of items. E.g. a user interface needs to display the current state of items in the moment of the user access. Also the automation logic execution engine needs always needs to be informed about the current states. The Item Repository avoids each bundle to cache states themselves for there internal use. It also makes sure that the state is in sync for all those bundles and it provides the possibility to persist states to the file system or a database, so that they are even kept throughout a system restart.

The following diagram shows how these communication channels are used:

openHAB comes with a generic textual configuration for its user interfaces: The so-called Sitemap. The sitemap is a tree structure of widgets, which define the different pages of a UI and their content. Widgets can be associated to items, for which they should show the status and/or control elements.

The definition of the Sitemap is quite abstract by design; it is supposed to be a suitable UI model for different kinds of user interfaces, so that the user does not have to configure each of them in case he sets up multiple UIs. If a UI has further requirements on top of the sitemap, it is still possible to introduce additional configuration options which are then specific for the UI in question.

Item UI providers offer a dynamic way to configure the UI, so that not everything must be stored statically in the Sitemap. An item UI provider can for example define, what widget should be used for an item, if none is specified and can dynamically define icons and labels (which might depend on the current state of the item) for the widgets.

An important use case for this feature is the dynamic display of item groups - all that there is stored in the Sitemap is the information that a certain group should be displayed; the page is then dynamically assembled at runtime with whatever items are available at that time.

openHAB Designer

The openHAB Designer is an Eclipse RCP application for configuring the openHAB runtime. It comes with editors for configuration files like the sitemap. Its big advantage over simple text editors is the full IDE support like syntax checking, auto completion, highlighting and content assist. It is also meant to implement and deploy rules for automatic actions.