What is the strategy for complex channels/items in openHAB

HI there,

I’ve switched from openHAB 1.x to 2.x and getting used to the concepts. In my case I’m using the knx binding to control my smart home. So far nothing new, but still I miss some higher level functions.

As I got it right, the things are the physical connection to the devices. They expose channels (physics) that get linked to items (generic representation in openHAB). So a channel is more or less a function to read/write a value to the device. The value can be of some basic type like on/off, number, string, etc.

This is cool and you can build complex functions with single value building blocks. For currently two channel types the core developer team decided that a single value is not enough for a good handling of the device. These two channel types are the dimmer and the rollershutter.

I would like to see more of this channel types that makes it easier to handle the functions of the device. Particularly I would like to see a channel type for hvac controller devices bundling the hvac mode, nominal value adjustment and maybe alarms.

Is there any plan to do so? If not, can I get involved? And how much efford is to be calculated to introduce new complex channels?

Kind regards,

Frank.

Perhaps a less ambitious proof of concept might be a simpler device to model. A thermostat, say - current temp, thresholds, switching, frost ?

This where you get the concept a bit mixed up.
The HVAC is the thing
The thing provides channels like a mode (String), set temp (Number), target temp (Number), Filter Dirty (Switch)…

So there is no need for complex channels once the thing is broken down in simple elements

Capice?

There has been done some work on a pidcontroller binding I’ve picked up on that as a binding doesn’t seem the right way and started developing a pidcontroller as a Trigger/Action based on the new rule engine. As I’m not a real expert on pidcontrollers and have been busy with other parts this has been slowed down somewhat. Also because I’m not completely sure what the best way to implement this is I’ve done some conceptual implementation. The basic implementation is a working pidcontroller. But the initial idea was also to make a smarter one with automatic configurations options. You can find the source of this work-in-progress here: https://github.com/Hilbrand/openhab2-addons/tree/pidcontroller

I don’t think it requires a new data type, but can be implemented using different channels. This seems conceptually also logically. There will just be some kind of rule that can be configured with different channels and some configuration options for more static values.

2 Likes

I think this is mostly correct, but it isn’t fully fleshed out and I think, as Vincent point’s out, some of the details missing are important to the discussion.

A device has one or more actuators and sensors. An actuator is something that you can send a command to to cause something to happen. A sensor is a value that the device reports.

The device is represented in OH 2 as a Thing. Each one of the actuators and sensors are individually represented as a Channel.

Items are the model that represents your home automation. Items is where “zwave:node7:blah:blah:blah” gets identified as “LivingroomLamp” and how it is displayed and interacted with by OH. One or more Channels can be linked to a single Item.

So my questions would be how would you link a more complex HVAC Channel to an Item? What Item would/could represent the full range of HVAC functions?

There currently is no Item type capable of handling that. And the bundling you are talking about is already handled by the Thing. So it is not clear to me what it is you are proposing.

This where you get the concept a bit mixed up.
The HVAC is the thing
The thing provides channels like a mode (String), set temp (Number), target temp (Number), Filter Dirty (Switch)…

So there is no need for complex channels once the thing is broken down in simple elements

This is my point exactly. You could do a dimmer and a rollershutter with several simple channels also. Nevertheless the architects decided to have the dimmer and the rollershutter as a channel type and as an item type.

If you begin this, there are two questions arising:

  1. Why did they come up with dimmer and rollershutter?
  2. Why did they stop there?

I can take a guess on the first question and this is usability. The most common device types must be supported for the non technical user. A dimmer and a rollershutter are getting more easy to handle if they present what they are. A composition of elements in functionality as well as in the graphical user interface.

You also can buy tires, motors and other stuff and build your car from it. But who wants to do that if you are not a car engineer.

The architects decide to have the items as this back in OHv1
The channels only derive from this.

These two devices are 1 device a dimmer or a simple motor, nothing else.
They accept simple commands UP, DOWN, STOP, ON OFF or a value. That’s it.

Before OH2, if you had a roller shutter with down and up trigger switches, they woud have to be added as separate items. Now in OH2, the 3 channels are in 1 thing.
1 device = 1 thing
3 sensors/actuators = 3 channels

Before OH2, if you had a roller shutter with down and up trigger switches, they woud have to be added as separate items. Now in OH2, the 3 channels are in 1 thing.
1 device = 1 thing
3 sensors/actuators = 3 channels

It doesn’t look like this. Here is a sample configuration for a rollershutter as a knx thing:

Thing device d279f904 "Jalousieaktor D2.3A" @ "Technikraum" [
    address="1.0.12"
] {
    Type rollershutter : A "Rollladen Schlafzimmer" [
        upDown="6/3/2",
        stopMove="6/3/3",
        position="6/3/4"
    ] 
}

The thing is the knx actor and the channel is named A. So no three channels but a combined channel. The corresponding item:

Rollershutter Schlafzimmer_Rolladen "Rollladen Schlafzimmer" { channel="knx:device:bridge:d279f904:A" }

So the rollershutter is one channel with combined functionality.

No, it is one channel with the commands for a rollershutter UP, DOWN, STOP, MOVE, POSITION
Because it is KNX the commands to send to the bus are different for each command and need to be specified just as with the old binding but in another binding it may be just a rollershutter channel without the breakdown of commands