In the openHAB concepts overview documentation the primary elements that are identified to introduce openHAB to new users are Things and Items.
When first thinking about your home automation system, it may be helpful to bear in mind that there are two ways of thinking about or viewing your system: the physical view and the functional view.
The physical view will be familiar to you. This view focuses on the devices in your system, the connections between these devices (e.g. wires, Z-Wave, WiFi hardware), and other physical aspects of the system.
The functional view might be a new concept for you. The functional view focuses on how information about the devices, connections, and so on, is represented in user interfaces. The functional view includes focusing on how rules affect representations of physical devices in software. Perhaps most important to you, the functional view focuses on how an action in a user interface affects the software associated with the physical device it represents.
It is a bit of an over-simplification, but you can think of the physical view as being a view of the ‘real world’, and the functional view being a view of the ‘software world’.
Things define the physical aspect of the system. Items define the functional (logical) aspect of the system. In the Unified Process the functionality that the system provides to end-users is the concern of the Logical View. UML diagrams are used to represent the logical view, and include class diagrams, and state diagrams. The 148Avenida Logical View is a subset of the EATSv5 Logical View, and the 148Avenida Physical View is a subset of the EATSv5 Physical View.
The distinction made in openHAB documentation and configuration needs to be understood in order to utilize the Eclipse SmartHome1OpenHAB formed the core of the Eclipse SmartHome project. The SmartHome project has been archived, but openHAB continues, and continues to use Eclipse as core infrastructure. artifacts as a framework for the 148Avenida home automation effort. However, in order to understand openHAB as a component within the EATS framework the Unified Process distinctions between physical and logical also need to be understood, as well as the how the two conceptual frameworks (openHAB documentation and Unified Process methodology) come together relative to EATSv5 home automation in the 148Avendia effort.
The distinctions made in the openHAB documentation is meant to help home automation makers who are not software engineers distinguish between the logical elements used internal to the system which are used in action scripting (Items) and the elements described in system configuration which can most closely be associated with the physical appliances and technology used to implement the automation (Things). The distinction in the documentation obscures a deeper understanding of the system engineering involved. Hypothetically something that casual users do not need to fully appreciate to utilize the software. In the Unified Process framework, the framework for this documentation, Things are as logical as Items, and software is as physical as hardware. This section of the documentation, 148Avenida Logical View, is concerned with communicating a logical understanding of the utility of the system to its users, which incorporates both the concepts of Things and Items, and the logical methods by which those concepts are related. The 148Avenida Physical View is concerned with the topology all elements of the system, software and hardware. From a systems engineering point of view the distinction made by the openHAB documentation is closer to a distinction between the physical appliances that implement (actualize) the peripheral devices connected to the core computing system, and the internal model of those appliances.
From the openHAB documentation:
Things in openHAB are entities that can be physically added to a system. Things may provide more than one function (for example, a Z-Wave multi-sensor may provide a motion detector and also measure room temperature). Things do not have to be physical devices; they can also represent a web service or any other manageable source of information and functionality.
Things expose their capabilities through Channels. Whether an installation takes advantage of a particular capability reflected by a Channel depends on whether it has been configured to do so. When you configure your system, you do not necessarily have to use every capability offered by a Thing. You can find out what Channels are available for a Thing by looking at the documentation of the Thing’s Binding.
Bindings can be thought of as software adapters, making Things available to your home automation system. They are add-ons that provide a way to link Items to physical devices. They also abstract away the specific communications requirements of that device so that it may be treated more generically by the framework.
Items represent capabilities that can be used by applications, either in user interfaces or in automation logic. Items have a State and they may receive commands.
The glue between Things and Items are Links. A Link is an association between exactly one Channel and one Item. If a Channel is linked to an Item, it is “enabled”, which means that the capability the Item represents is accessible through that Channel. Channels may be linked to multiple Items and Items may be linked to multiple Channels.
To illustrate these concepts, consider the example below of a two-channel actuator that controls two lights:
The actuator is a Thing that might be installed in an electrical cabinet. It has a physical address and it must be configured in order to be used (remember the physical view introduced at the beginning of this article).
In order for the user to control the two lights, he or she accesses the capability of the actuator Thing (turning on and off two separate lights) through two Channels, that are Linked to two switch Items presented to the user through a user interface.
- 148Avenida Use Case View
- 148Avenida Logical View
- 148Avenida Process View
- 148Avenida Physical View
- 148Avenida Configuration
- Security Configuration
- 148Avenida Developer View
- v2.5.5 Runtime Issues
- Development Setup Issues
- Eclipse SmartHome Framework
- Coding Guidelines
- Eclipse Community
- Framework Utilities
- Package Dependencies
- REST API
- Testing Eclipse SmartHome
- Textual Configuration