Introduction

While the use of KNX for most of the home automation logic means there is no fundamental requirement for a central ‘brain’ (each KNX device communicates directly with each other device via the KNX Bus network) there are some aspects that do effectively require a central ‘home automation engine’:

• The provision of a user interface, which can be accessed from a Smartphone App or Web Browser
• The implementation of ‘rules’ with more intelligence than is built into KNX – for example, changing what happens when a motion sensor is triggered depending on what time of day it is
• Integrating between multiple home automation technologies where it’s not practical to do this with KNX hardware

A lot of people have good success with Home Assistant and that’s a great solution in many cases but openHAB is a slightly better fit for Marsh Flatts Farm – mainly because of the combination of integration options available. At the time I originally picked openHAB it was the only solution with a robust KNX integration; Home Assistant now integrates with KNX too (but not yet with some other technologies).

Hosting

Note that a fundamental requirement is something which is hosted within the house – it is A Bad Idea to rely on Cloud-hosted solutions, not because the Cloud is fundamentally unreliable but because the communications links can be problematic and certainly add a lot of latency.

openHAB is able to run on a Raspberry Pi single-board computer but since I have a small server available it is more convenient to run on that, in a Docker container – especially since the openHAB Docker image is maintained by the central openHAB development team.

Change Control and Backups

It’s a good idea to keep previous versions of all of the configuration files and to maintain a backup copy off-site. Storing the files in a Private repository on github.com is a good way to accomplish both these objectives.

The main challenge with this approach is that the git client is not installed in the openHAB Docker container image by default.

File and Folder Structure

The Docker Container refers out to the host server for three folder structures:

• /opt/openhab/addons/ on the host server is mapped to /openhab/addons/ inside the container
• /opt/openhab/conf/ on the host server is mapped to /openhab/conf/ inside the container
• /opt/openhab/userdata/ on the host server is mapped to /openhab/userdata/ inside the container

openHAB Configuration

Over the years I’ve been using openHAB, the configuration process has evolved from being completely based on textual configuration files to being increasingly driven by auto-discovery and managed via the admin user interface. While the old-style configuration files still work I’ve found it problematic to mix-and-match the old and new approaches

Bindings

In openHAB terminology, integrations with other technologies are referred to as ‘Bindings’. I’m using the following:

Binding Name	MOSCoW	Available in Home Assistant?
BMWConnectedDrive	Should
InfluxDBPersistence	Must
KNX	Must
Miele Cloud	Should
MQTT	Must
NIBE Uplink	Should
RFXCOM	Must
SolarEdge	Should
Sony	Should
Squeezebox	Should
Unifi	Should

RFXCOM Binding

Oregon Scientific Sensors

The Oregon Scientific 433MHz sensors, measuring Temperature or Temperature & Humidity, get automatically detected by the RFXCOM USB Transceiver Bridge ‘Thing’ and automatically appear in the Inbox, as candidate ‘Thing’ records.

The configuration procedure for these is as follows:

1. Click on the candidate ‘Thing’ entry in the Inbox; this will be called something like TEMPERATURE_HUMIDITY-28673 or TEMPERATURE-1537
2. Click ‘Add as Thing’ on the menu that appears
3. Override the suggested name, with something like B2_OS_TH (for a Temperature & Humidity sensor, or _TS for a Temperature-only sensor)
   • Check for the correct location prefix by inspecting previous entries
4. Select the entry for the newly-created ‘Thing’ and click on the ‘Channels’ Tab; this will show 3-4 entries (Temperature; Signal Strength etc.)
5. Click ‘Add Equipment to Model’ in the menu
6. Select the Parent Group (‘Pick From Model’) and choose the Room for the sensor
7. Edit the suggested Name for the Equipment – this will be something like HOOSTS so change that to HO_OS_TS
8. Edit the suggested Label for the Equipment – this will be something like HO_OS_TS so change that to Home Office Temperature Sensor
9. Enter a Category – temperature
10. Change the Semantic Class from the generic Equipment to Sensor
11. Select all the Channels (Select All at the bottom works well)
12. Click ‘Add to Model’

MQTT Binding

Some devices that rely on MQTT publish ‘identification’ messages that permit them to be automatically Discovered and added as Things (e.g. those that follow the Homie conventions). Other devices need to be added manually, as ‘Generic MQTT Things’, with the relevant Channels and then mapped to an Equipment entry.

See also: MQTT on Openhab 3 Tutorial : 6 Steps – Instructables

Semantic Model

The ‘Semantic Model’ is new for openHAB 3 (or at least I didn’t notice it in openHAB 2 if it was there). It seems a good idea to populate this as faithfully as possible; I can see how it intends to be useful in terms of providing context, especially for voice commands that are annoying to have to fully-qualify.

Notes:

• Names cannot be edited after creation, whereas Labels can be – but Names are not permitted to contain spaces. The name should be the short-code
• The House and the Floors are of type ‘Group’ whereas the Rooms should be of type ‘Location’
• For the Rooms:
  • The ‘Label’ wants to be the full name, e.g. Bedroom 3, whereas the ‘Name’ wants to be the shorthand code, e.g. B3
  • The ‘Type’ wants to be Group
    • While Location seems tempting, this doesn’t permit Equipment items to be associated with the ‘Room’ as the ‘Parent Group’
  • The ‘Category’ wants to be e.g. bedroom (this selects the Icon to be used)
  • The ‘Semantic Class’ wants to be e.g. Bedroom
• If you want to create a Group that is not part of the physical structure (e.g. a group containing all of the Blinds) that is classed as a “Non-Semantic” thing so you need to tick the box at the bottom of the Model page to work with those
  • Note that if you want to send a Command like DOWN to all of the Blinds in a Group, you need to set the Base Type of the Group to a suitable value (so that Rules will work correctly).

Persistence

While most of the configuration for openHAB v3 is defined in the admin UI, it is not possible to define persistence strategies via the UI at this time. The workaround is to create a configuration file called persistence/influxdb.persist containing the following:

Strategies {
    everyHour : "0 0 * * * ?"
}

Items {
    *   : strategy = everyChange, everyHour
}

openHAB by Marsh Flatts Farm Self Build Diary is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.