# openHAB Glossary **URL:** \ **Category:** Tutorials & Examples\ **Tags:** openhab3\ **Created:** [December 13, 2021, 8:55pm UTC](https://community.openhab.org/t/openhab-glossary/130036 "2021-12-13T20:55:43Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![JustinG](https://community.openhab.org/user_avatar/community.openhab.org/justing/32/55948_2.png) [@JustinG](https://community.openhab.org/u/JustinG)\ **Post date:** [December 13, 2021, 8:55pm UTC](https://community.openhab.org/t/openhab-glossary/130036/1 "2021-12-13T20:55:43Z")
Perhaps it is just my years of experience teaching a vocabulary heavy subject, but it seems to me that many of the beginner questions that show up on the forums (and even some of the more advanced ones) result from struggles with all the terminology. Many beginning users stumble when attempting to use docs and even users who have read the help docs sometimes come away with only partial understanding unless they are already fully steeped in the language of openHAB. With the goal of alleviating some small measure of that confusion, I am starting this openHAB glossary. **THINGS THIS IS NOT:** - **This is not intended as a replacement for the help docs.** Nearly all of this is information is available somewhere in the docs in greater detail, but here it is summarized and collated for the sole purpose of developing a user’s vocabulary. - **This is not a place for non-openHAB specific terminology.** This glossary tries to focus on those new words or concept that are part of openHAB or required for a fundamental understanding of openHAB’s usage. This is not the place for glossaries about other concepts tangential to openHAB such as advanced networking, container management, linux commands, etc. **THINGS I HOPE THIS IS:** - **This glossary is full of definitions that are quick, simplified (sometimes overly simplified) ideas**. The goal is to help users feel that they can better read and understand the fuller concepts as presented in the docs or to just help parse a little better the answers provided by the more veteran/fluent users in the forum. - **This is intended to be a link that eliminates a lot of forum repetition.** A measurable percentage of answers to questions in this forum start with (or eventually wrap around to) basic descriptions of openHAB vocabulary in order to facilitate user understanding or improve the clarity of a question. I hope this glossary helps smooth over that stage and lets users get their answers more quickly and easily. **CATEGORIES:** - [Overall Structure](https://community.openhab.org/t/openhab-glossary/130036#overall-structure-1) - The basic design of openHAB and some related applications - [Release Cycle](https://community.openhab.org/t/openhab-glossary/130036#release-cycle-2) - The different types of openHAB releases and changes that may occur - [Core Concepts](https://community.openhab.org/t/openhab-glossary/130036#core-concepts-3) - The hierarchy of concepts that form the basis of openHAB’s function - [Items](https://community.openhab.org/t/openhab-glossary/130036#items-4) - The fundamental openHAB unit, the item - [User Interfaces](https://community.openhab.org/t/openhab-glossary/130036#user-interfaces-5) - The different applications for allowing users to interact with openHAB - [Semantic model](https://community.openhab.org/t/openhab-glossary/130036#semantic-model-6) - The optional information layer for openHAB items that parallels physical arrangement and real-world use - [Rules](https://community.openhab.org/t/openhab-glossary/130036#rules-7) - The systems for user defined openHAB actions ## Overall Structure | Term | Definition | | --- | --- | | **Event-driven** | A non-linear mode of operation where a program’s execution is idle until some stimulus (or event) requires a response | | **Karaf** | The internal console for the control and administration of openHAB, typically recognizable by the `openhab>` prompt | | **Marketplace** | A section on this forum where users and third party developers can post bindings, UI Widgets and rule templates for installation through MainUI. | | **Messaging bus** | Software architecture that handles the receiving and routing of small digital communication packets between other applications | | **openHAB** | The core software: an _Event-driven_ _Messaging bus_ for home automation | | **openHABian** | A feature-rich framework to aid in the installation, setup, and administration of openHAB and several other useful, related programs | | **RestAPI (API)** | A request and response system for external programs to gain access to the functions and information of a program | ## Release Cycle | Term | Definition | | --- | --- | | **Breaking Change** | An intentional change in a new version of an application that is incompatible with the function of previous versions and will require modification on the user’s part to restore proper function: these will always be listed in the documentation about the version release | | **Milestone** | The monthly variant of the openHAB release cycle, Milestones offer a balance between access to new features and the probability of undiscovered _Regressions_, new bugs, or _Breaking Changes_ and are probably a good choice for most uses and use cases | | **Regression** | A change in a new version of an application that accidentally results in an malfunction of a previously working feature and must be corrected in an application update to restore proper function | | **Release** | The least frequent of the openHAB release cycle variants, a Release represents a major revision in openHAB over the previous Release with changes that have been added and tested throughout the last 6 months: _Regressions_ and new bugs are expected to be at a minimum and these are the versions most often recommended for use in environments where system crashes and errors are least tolerable | | **Snapshot** | The most frequent of the openHAB release cycle variants, Snapshots are created nightly (or roughly so) and come with the newest features that therefore have the least breadth of testing: expect the highest frequency _Regressions_ and new bugs and avoid use in systems where errors cannot be tolerated | ## Core Concepts | Term | Definition | | --- | --- | | **Binding** | An add-on to openHAB that allows some 3rd party service or device(s) to communicate with the core software | | **Channel** | One single attribute of a _Thing_ which openHAB can read and/or write | | **Event** | An occurrence such as a change in _Item_ _State_ or the triggering of a _Channel_ with the potential to trigger a reaction. See events.log. | | **Item** | The openHAB object associated with a single point of information or datum | | **Link** | A defined connection between a _Channel_ and an _Item_ such that information from the channel changes the item’s state and/or changes of the item’s state pass through the channel to the _Binding_ for control of the device or service | | **Name** | A unique identifier for any object within openHAB used for referring unambiguously to that object (for example in rules or widgets): this is not the same as an object’s label which is usually a more human-readable and descriptive (but not necessarily unique) property | | **Profile** | A procedure applied to a _Link_ that converts data passing between the _Channel_ and the _Item_ and therefore resulting in potentially different item _State_ | | **Quantity** | A numerical value with associated units which allows openHAB to do unit intelligent conversion and comparison tasks | | **Rule** | A user created openHAB action that executes in response to one or more selected _Events_ | | **Semantic Model** | A structured method for relating _Items_ and adding information about them for openHAB UIs that reflects more closely how human language would refer to items and their relationships | | **State** | A special type of information that is the functionally important value of an _Item_, often the value of the property of a device or service the item represents | | **Thing** | The digital representation of a device or service as defined in a _Binding_ | | **Transformation** | An add-on to openHAB that defines a method for converting values, usually _Item_ states, in some way | | **Trigger Channel** | A special kind of _Channel_ found in some things that is not linked to an item but can trigger events (and therefore rules) directly | | **UID** or **Unique ID** | See _Name_ | | **Unit of Measure** | See _Quantity_ | ## Items | Term | Definition | | --- | --- | | **Aggregation Function** | A function by which a _Group_ can be configured to have a _State_ that is one of a select number of summaries of the states of the member _Items_: these are only available for certain item _Types_ | | **Command** | An openHAB specific term that is sent to an item and may result in a _State Change_ | | **Group** | A special type of _Item_ which holds a list of other items and distributes any _Command_ it receives to all its members | | **Metadata** | A structured set of data that can be applied to an _Item_; used by some bindings, the UI, rules and 3rd party integrations (e.g. Google Assistant, Alexa) to define more information about an item. | | **Proxy Item** | An _Item_ that is not linked to a _Channel_ but stands alone and holds a value useful in some other context such as a rule or user interface | | **State Change** | _Event_ in which something modifies the _State_ of an _Item_ to a different value | | **State Update** | _Event_ in which the _State_ of an _Item_ receives a value which may or may not be different than the current value and may not trigger the same downstream events as a _State Change_ | | **Tag** | An extra, arbitrary identifier attached to an item which may include information about the item’s role in the _Semantic Model_ or just general/custom information for searching and conglomerating | | **Type** | The designation that determines what kinds of information an item is associated with and the values its _State_ can have | ## User Interfaces | Term | Definition | | --- | --- | | **HABPanel** | Long-standing openHAB interface with an emphasis on tablet display and extreme customization | | **MainUI** | A web-based interface newly developed for openHAB3 covering both openHAB administration and the design and deployment of highly-customizable, responsive user interface pages | | **Overview Page** | In MainUI, the default page one sees when first bringing up the UI. It consists of a custom defined overview tab and three automatically generated tabs based on the semantic model. | | **PaperUI** | An unfinished, experimental, web-based interface from openHAB2 no longer available in openHAB3 | | **Sitemap** | A very basic form of user interface with a simple list format of control elements and minimal possibility of customization: sitemaps have been available for a long time and remain available in openHAB3 | ## Semantic Model | Term | Definition | | --- | --- | | **Equipment** | A _Group item_ with one of the equipment type semantic _Tags_, an equipment is meant to represent a physical device that a person might interact with (e.g., a thermostat or garage door). Mostly commonly equipment will be all the items associated with one configured _Thing_. | | **Location** | A _Group item_ with one of the location type semantic _Tags_, a location is meant to represent a physical location. It is not uncommon to find a nested hierarchy of locations to represent a home (e.g., House, Floor, Room) | | **Point** | An _Item_ of any of the standard types with one of the point type semantic _Tags_, a point is meant to represent one information or control aspect of an equipment item. These items are most likely _Linked_ to the _Channel_ of a _Thing_ | | **Property** | An additional semantic _Tag_ added to a _Point_ to further classify the kind of information associated with that point | ## Rules | Term | Definition | | --- | --- | | **Global Variable** | Any variable in a text based config that is defined outside the scope of a rule (i.e. at the top of the file). UI Based rules do not support global variables. | | **JSR223** | An old standard since renamed Java Scripting, which allows for the use of a number of other languages to develop openHAB Rules. Even though it has a specific meaning, it’s common to see it used to mean “any rules language that isn’t Rules DSL.” | | **Rules DSL** | A Domain Specific Language created by and for use in openHAB for the creation of rules. | | **Text Based Rules** | Any set of rules written in any language using text files. | | **UI Based** | Rules defined and written using MainUI. | ---
**Author:** ![JustinG](https://community.openhab.org/user_avatar/community.openhab.org/justing/32/55948_2.png) [@JustinG](https://community.openhab.org/u/JustinG)\ **Post date:** [December 13, 2021, 8:57pm UTC](https://community.openhab.org/t/openhab-glossary/130036/2 "2021-12-13T20:57:41Z")
I have made this topic a wiki, so please everyone feel free to contribute other relevant definitions or improve on mine. Whether this belongs in the docs in the long run or should remain here is a discussion that is worth having, I can see pros and cons of both sides. ---
**Author:** ![system](https://community-openhab-org.s3-eu-central-1.amazonaws.com/original/2X/6/6a52f2ac5d00e4c7b50471a354b3a9221188be90.png) [@system](https://community.openhab.org/u/system)\ **Post date:** [January 24, 2022, 12:58pm UTC](https://community.openhab.org/t/openhab-glossary/130036/3 "2022-01-24T12:58:11Z")
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.