Базовая установка openhab на raspberry pi

# Additional features and settings

Apart from the storage configuration discussed above, the settings screen contains several settings kept as part of the panel configuration (meaning they are set separately):

*Note: the text-to-speech functionality featured in HABPanel is unrelated to the defined on the openHAB server, and they are not compatible (this is why a String item is required and the function cannot be used). However, HABPanel will play audio streamed through the , including spoken text.

# Optional Components

openHABian comes with a number of additional routines to quickly install and set up home automation related software.
You’ll find all of these in the

• Amanda Network Backup – A built-in backup solution for your valuables. Please continue reading here
• frontail – openHAB Log Viewer accessible from http://openHABianPi:9001
• openHAB Generator – Allows you to create Items, Sitemap and HABPanel dashboard for your home in no time
• Node-RED – “Flow-based programming for the Internet of Things”, with preinstalled openHAB2 and BigTimer add-ons. Accessible from http://openHABianPi:1880
• KNXd – KNX daemon running at
• Homegear – Homematic control unit emulation
• Eclipse Mosquitto – Open Source MQTT v3.1/v3.1.1 Broker
• OWServer – 1wire control system
• Grafana – persistence and graphing available from http://openHABianPi:3000

# Features

The following features are provided by the openHABian images out of the box:

• Hassle-free setup without a display or keyboard, connected via
• openHAB 2 in the latest stable version
• Zulu Embedded OpenJDK Java 8 (newest revision)
• including updater functionality
• openHAB Log Viewer (based on frontail)
• Samba file sharing with
• Useful Linux packages pre-installed, including
• Login information screen, powered by FireMotD
• Customized Bash shell experience
• Customized vim settings, including openHAB syntax highlighting
• Customized nano settings, including openHAB syntax highlighting
• Version control for by the help of etckeeper (git)
• Raspberry Pi specific: Extend to the whole SD card, 16MB GPU memory split

Additionally the openHABian Configuration Tool is included and provides the following optional settings and components:

• Switch over to the latest openHAB 2
• Install and Setup a with password authentication and/or HTTPS access (incl. Let’s Encrypt certificate) for self-controlled remote access
• Set up a Wi-Fi connection
• Bind the openHAB remote console to all interfaces
• Easily install and preconfigure of your choice
• … and many more
• Raspberry Pi specific:
  • Prepare the serial port for the use with extension boards like Razberry, SCC, Enocean Pi, …
  • Move the system partition to an external USB stick or drive
• Pine A64 specific:
  • Longsleep’s platform scripts
  • Assign

# Features

The following features are provided by the openHABian images out of the box:

• Hassle-free setup without a display or keyboard, connected via
• openHAB 2 in the latest stable version
• Zulu Embedded OpenJDK Java 8
• including updater functionality
• openHAB Log Viewer (based on frontail)
• Samba file sharing with
• Useful Linux packages pre-installed, including
• Login information screen, powered by FireMotD
• Customized Bash shell experience
• Customized vim settings, including openHAB syntax highlighting
• Customized nano settings, including openHAB syntax highlighting
• Raspberry Pi specific: Extend to the whole SD card, 16MB GPU memory split

Additionally the openHABian Configuration Tool is included and provides the following optional settings and components:

• Switch over to the latest Milestone or Snapshot release of openHAB 2
• Install and Setup a with password authentication and/or HTTPS access (incl. Let’s Encrypt certificate) for self-controlled remote access
• Set up a Wi-Fi connection
• Bind the openHAB remote console to all interfaces
• Setup for your system
• Easily install and preconfigure of your choice
• … and many more
• Raspberry Pi specific:
  • Prepare the serial port for the use with extension boards like Razberry, SCC, Enocean Pi, …
  • Move the system partition to an external USB stick or drive

# Concepts

Elements:
Sitemaps are composed by arranging various user interface elements.
A set of different element types supports a user-friendly and clear presentation.
The example above contains , and elements among others.
Elements present information, allow interaction and are highly configurable based on the system state.
One line of Sitemap element definition produces one corresponding UI element.
As shown in the example, each element generates a descriptive text next to an icon on the left side and a status and/or interaction elements on the right.

Parameters:
A certain set of parameters can be configured to customize the presentation of an element.
In the shown example , and are parameters.
Almost all parameters are optional, some are however needed to result in a meaningful user interface.
To avoid very long or unstructured lines of element definition, parameters can be broken down to multiple code lines.

Blocks:
By encapsulating elements with curly brackets, multiple elements can be nested inside or behind others.
The element type is often used in combination with element blocks.
Frames are used to visually distinguish multiple elements of the same topic on one interface page.
When using code blocks behind other element types such as , or , these UI elements will, in addition to their normal function, be links to a new view, presenting the nested elements.
In the above example, multiple Frames are defined and some elements are not visible on the main view but are accessible behind their parent element.
These are indicated by the “>” control icon on the right of an element.

Dependencies:
A typical sitemap contains dozens of individual elements.
A system state and possible interactions are however often closely dependent.
openHAB supports these dependencies by providing parameters for dynamic behavior.
Be sure to check out the chapter.

For the technically interested: The Sitemap definition language is an
Xtext Domain Specific Language and the sitemap file model can be found here.

Special Element ‘sitemap’

The element is mandatory in a Sitemap definition.
This element shall be the first line in the sitemap file, and the following code block comprises the entire Sitemap definition.

• shall always be equal to the Sitemaps file name, e.g. the in a sitemap file named must be “demo”
• is free text and will be shown as the title of the main screen.

(Note that the element is written with a lower case “s”.)

# Features

The following features are provided by the openHABian images out of the box:

• Hassle-free setup without a display or keyboard, connected via
• openHAB 2 in the latest stable version
• Zulu Embedded OpenJDK Java 8 (newest revision)
• including updater functionality
• openHAB Log Viewer (based on frontail)
• Samba file sharing with
• Useful Linux packages pre-installed, including
• Login information screen, powered by FireMotD
• Customized Bash shell experience
• Customized vim settings, including openHAB syntax highlighting
• Customized nano settings, including openHAB syntax highlighting
• Version control for by the help of etckeeper (git)
• Raspberry Pi specific: Extend to the whole SD card, 16MB GPU memory split

Additionally the openHABian Configuration Tool is included and provides the following optional settings and components:

• Switch over to the latest openHAB 2
• Install and Setup a with password authentication and/or HTTPS access (incl. Let’s Encrypt certificate) for self-controlled remote access
• Set up a Wi-Fi connection
• Bind the openHAB remote console to all interfaces
• Easily install and preconfigure of your choice
• … and many more
• Raspberry Pi specific:
  • Prepare the serial port for the use with extension boards like Razberry, SCC, Enocean Pi, …
  • Move the system partition to an external USB stick or drive
• Pine A64 specific:
  • Longsleep’s platform scripts
  • Assign

# Examples

Here are some examples of valid binding configuration strings.

Open a port on the openHAB server and listen for incoming connections (e.g. for a String Item that captures some state of a remote device that connects to openHAB):

Connect to a remote server, for a Switch Item where values are converted using the my.device.map:

Connect to a remote server and send any commands received.
Both of the following are equivalent.

Here’s a full item configuration:

The TCP Binding will open a port to remote host 10.0.0.4:7000. Any commands received on the item will be sent to the remote with pre and postfix specified by preamble and postamble.
The Item will get postUpdate on any data received from the remote via the TCP connection.
The data can be mapped via rules to virtual items such as MyVirtualLyngdorfPowerSwitch.

# A Deeper Dive: openHAB Structure for Advanced Users

openHAB 2 is developed in Java and uses OSGi for modularity.
Apache Karaf serves as a container with Eclipse Equinox as the OSGi runtime environment.
Jetty is included as an HTTP server.

openHAB is highly modular software that can be extended through “Add-ons”.
Add-ons give openHAB a wide array of capabilities, from User Interfaces, to the ability to interact with a large and growing number of physical Things.
Add-ons may come from the openHAB 2 distribution, the legacy openHAB 1 distribution or from any other external source.

If you are new to openHAB, we suggest you continue to the Concepts chapter where we introduce many fundamental ideas that are used throughout openHAB.

Caught a mistake or want to contribute to the documentation? Edit this page on GitHub

# Binding Configuration

This binding can be configured in the file .

Examples:

NOTE: While change in these global options is allowed at runtime it’s not advisable to do that. This is because only newly created pins will use the new values while currently existing pins will use the old one.

NOTE: These options are optional, in most circumstances you don’t have to specify them.

# Item Configuration

In order to bind an item to a Koubachi resource query you need to provide configuration settings. The easiest way to do this is to add some binding information in your item file (in the folder configurations/items`). The syntax for the Koubachi binding configuration string is as follows:

You can also bind to the action types in the Koubachi API using the keyword “action” and then the action type.

What actions can actually be performed on a specific plant depends on the type of Koubachi device used.

Here are some examples for valid item configuration strings:

for Device Resource type

• virtualBatteryLevel (Number)
• ssid (String)
• hardwareProductType (String)
• lastTransmission (!DateTime)
• nextTransmission (!DateTime)
• associatedSince (!DateTime)
• recentSoilmoistureReadingValue (String)
• recentSoilmoistureReadingTime (!DateTime)
• recentSoilmoistureReadingSiValue (Number) (available since 1.9)
• recentTemperatureReadingValue (String)
• recentTemperatureReadingTime (!DateTime)
• recentTemperatureReadingSiValue (Number) (available since 1.9)
• recentLightReadingValue (String)
• recentLightReadingTime (!DateTime)
• recentLightReadingSiValue (Number) (available since 1.9)
• recentSoiltemperatureReadingValu (String) (available since 1.9)
• recentSoiltemperatureReadingTime (!DateTime) (available since 1.9)
• recentSoiltemperatureReadingSiValue (Number) (available since 1.9)
• soiltemperaturePollingInterval (Number) (available since 1.9)
• recentIrlightReadingValue (String) (available since 1.9)
• recentIrlightReadingTime (DateTime) (available since 1.9)
• recentIrlightReadingSiValue (Number) (available since 1.9)
• hardwareProductGeneration (String) (available since 1.9)
• hardwareProductName (String) (available since 1.9)

for Plant Resource type

• name (String)
• location (String)
• lastFertilizerAt (!DateTime)
• nextFertilizerAt (!DateTime)
• lastMistAt (!DateTime)
• nextMistAt (!DateTime)
• lastWaterAt (!DateTime)
• nextWaterAt (!DateTime)
• vdmWaterInstruction (String)
• vdmWaterLevel (Number)
• vdmMistInstruction (String)
• vdmMistLevel (Number)
• vdmFertilizerInstruction (String)
• vdmFertilizerLevel (Number)
• vdmTemperatureHint (String)
• vdmTemperatureInstruction (String)
• vdmTemperatureLevel (Number)
• vdmLightHint (String)
• vdmLightInstruction (String)
• vdmLightLevel (Number)

Plant actions

• calibration.watered (Switch)
• calibration.is_dry (Switch)
• calibration.is_not_dry (Switch)
• calibration.restarted (Switch)
• water.performed (Switch)
• mist.skipped (Switch)
• mist.performed (Switch)
• fertilize.skipped (Switch)
• fertilize.performed (Switch)
• put_into_light.performed (Switch)
• put_into_shade.performed (Switch)
• heat_plant.performed (Switch)
• cool_plant.performed (Switch)

As a result, your lines in the items file might look like as follows:

# Platform Recommendations

1. You are new to openHAB 2 and want to give it a try? You are in luck:

   Set up openHAB 2 on your local PC or Mac in just a few steps.

2. You gained some experience and want to use openHAB to seriously control your home?
   Typical hardware and software requirements are:

   • 24/7 availability: A dedicated system connected by Ethernet and running continuously.
   • Energy and space efficient: A device capable of performing the task at hand without being exaggerated
   • Extendibility: Your system should be capable of running additional software like an MQTT broker or a persistence and graphing software.
   • Peripherals: Depending on your home automation hardware, you will need additional peripheral devices such as a WiFi interface or a special USB radio module.

Many devices are suited to host a continuous installation of openHAB 2.
Experiences with different devices and environments can be found in the community forum hardware section.

The Raspberry Pi as a minimal sufficient device is quite popular, especially as we offer a quick setup with openHABian.
A popular alternative is our solution for the Synology DiskStation, which many users already own in their homes.
The previously mentioned openHABian can also be used to kickstart your openHAB 2 experience on existing Debian/Ubuntu based Linux systems.

Please check the menu to the left for all available options.

# Insteon devices

Every Insteon device type is uniquely identified by its Insteon product key, a six digit hex number. For some of the older device
types (in particular the SwitchLinc switches and dimmers), Insteon does not give a product key, so an arbitrary fake one of the format
Fxx.xx.xx (or Xxx.xx.xx for X10 devices) is assigned by the binding.

Finally, each Insteon device comes with a hard-coded Insteon address of the format ‘xx.xx.xx’ that can be found on a label on the device. This address should be recorded for every device in the network, as it is a mandatory part of the binding configuration string.

The following devices have been tested and should work out of the box:

# Exposed lights

It is important to note that you are exposing Items not Things or Channels.
Only Color, Dimmer, Rollershutter, Switch and Group type Items are supported.
Group type items require the “Huelight” tag to be exposed as devices instead of Groups.

This service can emulate 3 different devices:

• An OSRAM SMART+ Plug,
• a dimmable white color Philips A19 bulb and
• an a Philips Gen 3 LCT010 extended color bulb.

The exposed Hue-type depends on some criteria:

• If the item has the category “ColorLight”: It will be exposed as a color bulb
• If the item has the category “Light”: It will be exposed as a switch.

This initial type determination is overridden if the item is tagged.

The following default tags are setup:

• “Switchable”: Item will be exposed as an OSRAM SMART+ Plug
• “Lighting”: Item will be exposed as a dimmable white bulb
• “ColorLighting”: Item will be exposed as a color bulb

It is the responsibility of binding developers to categories and default tag their available Channels, so that linked Items are automatically exposed with this service.

You can tag items manually though as well.

# Defining what to log

By default, openHAB comes with logging enabled for several standard packages.
In order to enable logging for additional packages, you need to define what should be logged and in which detail.

This can be done in Karaf using the following console command:

The what is defined by and is in most cases a binding (like ).
The detail of logging is defined by one of the following levels:

The levels build a hierarchy with ERROR logging critical messages only and DEBUG logging nearly everything.
DEBUG combines all logs from weight 100 to 500, while TRACE adds further messages in addition to what DEBUG displays.
ALL includes every log level from weight 100 to 600.
Setting the log level to DEFAULT will log to the level defined in the package.subpackage (in most cases a binding).

Following example sets the logging for the Z-Wave binding to DEBUG

Note that the log levels set using the commands are persistent and will be applied upon restart.
To modify the stored log levels, use the console or edit the .

# A note on Items which accept multiple state data types

There are a number of Items which accept multiple state data types, for example , which accepts and , , which accepts and , or , which accepts , and .
Since an Item has a SINGLE state, these multiple data types can be considered different views to this state.
The data type carrying the most information about the state is usually used to keep the internal state for the Item, and other datatypes are converted from this main data type.
This main data type is normally the first element in the list returned by .

Here is a short table demonstrating conversions for the examples above:

# Binding Configuration

The TCP and UDP bindings can be configured in the files and , respectively. Note that the parameters set in these files
will be common for all the TCP connections of this binding, both client and server connections.
It is thus not possible to have different postambles for two distinct endpoints.

The indicated default values apply to both bindings unless otherwise noted.

Use of certain parameters requires other parameters. If these dependencies are not satisified, warnings will be generated:

• bindingsharedconnections=true requires itemsharedconnections=true
• directionssharedconnections=true requires bindingsharedconnections=true

# Profiles

are a newly introduced, very powerful feature, which helps reducing the complexity of configurations for the Smart Home. In many homes there are some recurring patterns of how devices interact which each other: Buttons or rockers are for example often used to turn some other device on or off. Another common use case is that multiple devices (e.g. multiple bulbs within the same lamp) should always act together as if they were a single device. While it was already possible to fully cover these use cases with rules so far, it often resulted in numerous rules that do similar logic, but for different devices. Especially in large-scale setups, this could make it hard to keep the overview and maintain these rules.

A Profile describes the behavior of a link between a Channel and its associated Item (i.e. the raw function of a device and its logical representation within openHAB) and can thus completely replace simple rules. Through selecting an appropriate Profile, a wall switch can easily be assigned to toggle a light or to pause/resume a speaker. Likewise it is possible to offset a sensor value by a certain amount or to do any kind of more complex transformation on incoming values – all without writing a rule.

The Paper UI lists all applicable profiles when linking an Item to a Channel and only more advanced profiles require some additional configuration, which can all be done through the UI. More details and examples on how to use Profiles can be found in .

# Item Configuration

The syntax for the TCP & UDP binding configuration string is explained here:

Note: The examples here below are for the TCP protocol. UDP binding configuration are exactly the same, one only has to substitute with

The format of the binding configuration is simple and looks like this:

where is one of the following values:

• for outbound-triggered communication, whereby the openHAB runtime will act as a client and establish an outbound connection to the specified

is the openHAB command. can be omitted or have the value ‘*’. Omit the command if using generic mapping via transformations, or if no mapping is needed.

is the hostname or IP address in dotted notation of the remote host.

can be one of:

• a string in the form of , and then it goes through the transformation with the argument ;
• empty or the string , and then it returns the State or the Command as a String;
• anything else and it sends back the string itself.

# Prerequisites

• Linux-based OS with GPIO driver loaded (check whether exists directory ), usually it’s compiled into the kernel for all recent boards which exposes GPIOs

• Mounted pseudo file system, the mount point can be:

• Automatically determined if is mounted under path , this is the default path in almost all configurations

• Manually set in openHAB configuration file, key

• See https://github.com/java-native-access/jna for supported platforms

• root privileges, openHAB should be run under “root” account.

Alternatively you can add the user “openhab” to the usergroup “gpio”, if your distribution (like rasbian) does have such a group.

NOTE: Some boards may need additional pin configuration prior using them, for example OMAP-based processors are using pin multiplexing which require changing the mode for some of the pins. Please refer to board’s System Reference Manual for more information whether preliminary configuration is needed and how to do it.

Some manual configuration may be needed. The following edit to may be necessary (see discussion above in Prerequisites section). If needed, set:

The edit may not be necessary, and could cause openHAB to crash. If it does, simply undo the edit and restart openHAB.

If you chose above to add the openhab user to the gpio group, then you shouldn’t make the changes below to run as root. If you did not add the openhab user to the gpio group, make a further edit to :

And then edit and set the following:

# Item Configuration

The syntax for the HTTP binding configuration string is given below.

Receive repeated updates from a URL (“in” binding):

Send commands to a URL (“out” binding):

The section is optional, new in version 1.9.0, and only applies when is . The media type used is always . can be a literal string, the special keyword which means the string version of the command, or a transformation like .

For the “out” binding, there are two special commands available:

• – this means the following URL is called regardless of which command has been issued
• – this means the following URL is called whenever the state of the given item has changed

Here are some examples of valid binding configuration strings:

Here are full item examples of sending content in the body of a POST method (new in 1.9.0):

As a result, lines in the items file might look like the following:

Заключение или “кому оно подойдёт?”

Как итог, кому бы я советовал эту систему: 

• для людей, имеющих опыт в ИТ и желающих поэкспериментировать с технологиями УД;
• для тех, кто разочаровался в красивых нарядных обёртках и беспределе коммерческих решений (привет, Fibaro!);
• для тех, кому нужна максимальная гибкость и кто готов “залезать под капот и пачкать руки в масле”, получая на выходе именно то, что требуется, а не то, что навязывается кем-то;
• ну и для тех, кто строит системы автоматизации с повышенными требованиями к надёжности – архитектурно, openHAB очень близок к “энтерпрайз”-решениям и использует многие их принципы.

Среди спонсоров и активных сторонников openHAB и основанных на нём продуктов такие компании, как KNX, Enocean, Insteon, Deutsche Telekom, HomeMatic и даже сам консорциум Z-Wave (впрочем, после приобретения Silabs, они активно начали развивать собственные решения).

Список источников

• www.openhab.org
• sprut.ai