Can someone share an OH2 multi-sensor .thing and .item examples?

Tags: #<Tag:0x00007f6173b2f850> #<Tag:0x00007f6173b2f6e8> #<Tag:0x00007f6173b2f620>

I’m not finding any example multisensor definitions with extensive searches, and the documentation is focused on things with a single item (while the Eclipse Smart Home Things page example has multiple channels, though the definition looks very different from the OpenHab Things page, which is confusing). Having to switch to Home Builder due to thing and item editing limitations in PaperUI and HABmin, and trying to figure out where to start with defining a multi item thing in OH2.2 (on Linux, if that makes a difference)

In particular, I am interested in an Aeotec DBS05, but will take any suggestions/leads

What I have so far from the following source pages, and I’m not sure which takes precedence;

<thing-type id="aeon_dsb05_00_000">
    <label>Master Bedroom 4 in 1 Sensor</label>
    <description>Motion, luminance, temperature, humidity </description>
      <channel id="sensor_binary" typeId="sensor_binary" />
      <channel id="sensor_relhumidity" typeId="sensor_relhumidity" />
      <channel id="sensor_temperature" typeId="sensor_temperature" />
      <channel id="sensor_luminance" typeId="sensor_luminance" />
<channel-type id="sensor_binary">
    <label>Binary Sensor</label>
<channel-type id="sensor_relhumidity">
    <label>Humidity Sensor</label>
<channel-type id="sensor_temperature">
    <label>Temperature Sensor</label>
    <state min="12" max="30" step="0.5" pattern="%.1f °C" readOnly="false">
<channel-type id="sensor_luminance">
    <label>Luminance Sensor </label>

There seems to be some information missing about the real channel ID, which should match with the information in the .item files. What is the true format of a .thing file?

Edit: don’t forget to use the development/security version of the zwave binding, textual config won’t work with any other binding version …

1 Like

Thank you, @sihui!

Further investigation has led me to find that there are 4 main approaches;

  1. Do everything in PaperUI, and edit the JSON file if tweaks are required

@hmerkHans-Jörg MerkFoundation member
…If you need to edit a thing, you still can do this outside PaperUI, as the JSON storage files are human readable and editable.

  1. Use PaperUI/HABmin for discovery, and things configuration, use .items and .rules for the rest. Some people copy/paste item info from PaperUI to build .item files


I’ve grouped my rules and items on files.
Items mainly targeting to bindings and rules targeting types (light, shutter, and heating…)

  1. The fully manual approach as you have helpfully referenced above

  2. Use Home Builder to define sitemap and items

I am currently leaning to #1, and will see if that is viable.

Option 1: is very rarely used and especially for zwave not necessary because you can do everything via HABmin (better option than PaperUI because designed for dealing with zwave devices)

Option 2: is most commonly used and the easiest one

Option 3: has the disadvantage that you cannot configure your devices via GUI anymore. You need to use the dev version of the binding. Mostly used by people how want version control via git.

Option 4: is a nice tool but does not link your items to the things channels, so a lot of manual work still has to be done.

Except option 3 you can use any 2.x zwave binding version but be aware that development is fast for zwave and if new devices are on the market you need to use a recent zwave binding, perferrable a snapshot version (or the dev version which has the same device support via database)

Option 2 works like this: include a new device, let it autodiscover, HABmin will show you the available channels, create your items and link them to the channels you want to use: that’s it.

Have fun :grinning:

1 Like

Thanks again, @sihui!

After learning from Matt the sequence of steps to delete/re-add zwave things in HABmin, I am going to center on HABmin for the current time, though will keep your explanations of the options in my back pocket for further mitigations if needed.

1 Like