This is the second of a series of post explaining the experience of the JEMMA and Energy@home community with the OpenHAB framework. Find below links to all posts of the series:
- JEMMA and OpenHAB: a nice match (publication date: 18/4/2016)
- OpenHAB in theory: a short overview (publication date: 22/4/2016)
- OpenHAB in action: a quick example (publication date: 26/4/2016)
- The JEMMA - OpenHAB remote binding (publication date: 29/4/2016)
- The JEMMA - OpenHAB local binding (publication date: 3/5/2016)
- Conclusions and future work (publication date: 9/5/2016)
OpenHAB in theory: a short overview
OpenHAB has quite good documentation to help you getting started. As new OpenHAB adopters, right after the first practical tests, were especially interested in more "architectural" documentation. Luckily, also on this topic a good amount of resources are available, split among the OpenHAB and ESH repositories. We give you a short summary of the most interesting aspects in the following.As anticipated in the previous post, one aspect that we like about OpenHAB is its model for abstracting devices resources.
From the application developers point of view, the whole framework relies on the concept of item (also explained here). Items are simple entities, which have a status and can be used through events. The overall amount of items is quite compact - and quite independent from any specific specific hardware capability. We did not have the chance to dig into the reasons for this design choice yet, but we can appreciate the fact that the amount of items is quite compact and generic, giving to application developers a controlled set of "virtual" objects to play with - which clearly simplifies the development of applications.
Going into more interesting models (at least from the device inter-operability perspective) the entity representing concrete devices (or services) is represented by a Thing component. Beyond keeping track of the status of the physical device (off-line, on-line, initializing, etc.) a Thing element models the device/service and its actual capabilities expressed by a collection of Channels. elements. Also in this case, the choice seems quite practical - and very similar to the OSGi Device Service/Device Abstraction Specifications, which we consider an example of a quite well-designed and flexible abstraction.
The communication "glue" among these two layers between these two components is provide by the OpenHAB *Event Bus * (see also here).
From the implementation view point, the life-cycle of Things and their respective capabilities are managed and exposed to the framework by implementing a Binding i.e. a bundle implementing a number of standard interfaces (normally ThingHandler, plus a separate channel interface for each specific capability, etc.).
Once the bindings have been imported into the OpenHAB framwork as addons, the mapping between Item and Binding can be defined just by providing proper configuration directives which looks like the following examples:
itemtype itemname ["labeltext"] [<iconname>] [(group1, group2, ...)] [{bindingconfig}]
Switch Light_Floor "Light at Floor" { knx="1/0/15+0/0/15" }
Switch Presence "I'm at home" { bluetooth="123456ABCD" }
Switch Doorbell "Doorbell" { serial="/dev/usb/ttyUSB0" }
Contact Garage "Garage is [MAP(en.map):%s]" { zwave="21:command=sensor_binary,respond_to_basic=true" }
String Error_Ventilation "Error in Ventilation %s" { comfoair="error_message" }
Number DiningRoomTemp "Maximum Away Temp. [%.1f °F]" { nest="<[thermostats(Dining Room).away_temperature_high_f]" }
The syntax may look complex, but actually it's just one line for each item following a rather simple syntax.
Rules and Actions !
At this point, the best way to proceed is to play with the demo environment provided by OpenHAB.After the demo environment is started, OpenHAB web interfaces should be reachable through at http://localhost:8080/openhab.app?sitemap=demo.
The framework provides a translation mechanism from the item configuration file to an HTML page making possible to interact with the several items in a more pleasant way. The shape given to the various items that populate the GUI is defined into proper .sitemap files.
The interaction with the GUI typically triggers different events, for example the on/off switching of a light sends a command and the associated status update over the event bus. If the items is bound to a Thing it is possible to receive the command together with the status update notification and behave accordingly, possibly by interfacing the the physical object and modifying its status.
One of the OpenHAB features we like best, it the possibility to define more complex behaviors or to trigger actions on specific time intervals by defining a specific Rule. Rules are written following a Xtend syntax and compliant with the following structure:
rule "rule name"
when
<TRIGGER CONDITION1> or
<TRIGGER_CONDITION2> or
<TRIGGER_CONDITION3>
...
then
<EXECUTION_BLOCK>
end
The rule body is executed any time the when clause is met. Several activation methods are possible and they can all be grouped into the following: - Item(-Event)-based triggers: They react on events on the openHAB event bus, i.e. commands and status updates for items
- Time-based triggers: They react at special times, e.g. at midnight, every hour, etc.
- System-based triggers: They react on certain system statuses.
The "then" clause contains actions to be performed when the rule is activated. Actions defined by the OpenHAB framework cover the majority of use cases, however actions with special purpose can be defined by extending the framework and implementing your own actions.
Nessun commento:
Posta un commento