KNX2 binding OH3: devices per room or per actual hardware?

Add-ons Bindings
1

Just revisiting my configuration and more questions open than ever… :wink:

I’m using OH3 with KNX2 binding and I am about to wrap it up finally. So I have two major options

  1. using KNX2 binding with “one thing per KNX device”
  2. using KNX2 binding with “one thing per room”

ad 1
At least in my case (using a Weinzierl 730 IP Interface), I can add things like my GIRA Actuators with the KNX addresses (like 1.1.2 for my 5038 00 GIRA blinds actuator) I don’t get the GAs associated with the device using the “Fetch”-option ( Read out the device parameters and address/communication object tables). so I have to add them manually to the device

ad 2
so, I can easily add a “virtual” device per room and add the GAs to that room and ignore the “hardware” aka devices…

So, what’s best to maintain? What’s “best practise” and where do I don’t get into trouble with future versions of KNX-binding…?

2

Well, Things are Things. :slight_smile:

As a matter of fact, it’s possible to use knx as “one” hardware, which then is the whole bus. But the idea of Things is, to set up one Thing per Device. Same goes to mqtt, where you could think of the broker as “one” Hardware and only create many channels under one Thing. But in real life the broker is only to communicate with the hardware.

Another point: I have some knx devices, and I have multiple devices which are identical (e.g. 2 pieces of HAGER TYA628A, 4 pieces of HAGER TXA663A and so on). Instead of mixing their Channels to per-room-individual “virtual Devices” I use them as they are.

I have to admit that I reorganized my GA some years ago, so that all Devices are very similar configured, i.e. the GA middle part 0 to 7 is sort of “Type of product”, each Switch is a 4 , each Dimmer is a 5, each rollershutter is a 6, each measurement is a 7… the first part of GA is the room, and as I have less than 16 rooms, I even have a number free for outdoor functions. :slight_smile: (in fact I could use from 0 to 31…) and the last part is organized like the CO, so I have a 0 for control, a 2 for status and so on. When I have more than one “Thing” of the same type in one room, I simply add 10 to the last part, so up to 24 (or 25) identical functions per room.

This way, same type of device is mostly identical configured. I’m using common names for the channels, i.e. ch1, ch2, ch3 and so on. But I use individual Names in the Channel Label, so I have “speaking Names” in the Things list in VSCode. It’s straight forward to create Items from this Channels and the Items are grouped per room.

I don’t need a per-room-grouping for Hardware, I even don’t see any benefit, that’s not the way knx nor openHAB is organized.

Sure, I have some GA which don’t fit to the model completely, these aren’t “owned” by a specific device but are central functions like Clock, Outdoor Temperature (which is used in the thermostat units) or knx scenes to control shading or light. These are configured to a virtual knx device.

3

Matter of fact, very similar here! :wink: (except for GIRA, not HAGER)
but as my electrician had the idea to “mix” the actuators and the fuses, to avoid being completely in the dark in rooms or hallways, there’s even two distinct, but same model actuators (dimmer, blinds, …) per room.

And my goal is to have not only a “all lights on one page”, but also “all information/actions for one room”, so that’s where my “virtual device per room” idea came from. But on the other hand my GAs are sorted in indoor/outdoor and levels/parts of garden/garage, … I can say from the looks of a GA, where it’s located; so from that perspective it doesn’t matter, from which thing the items get their GAs from.

On the other hand: if I even don’t get “auto discovery” of some sorts, why re-order in OH3 anyways? :wink:

But then again: perhaps it’s best to re-order now, and benefit from future architectural developments of openHAB, because one thing is for sure: Things are normally for “real devices”, not virtual ones… :wink:

so, perhaps I should just do it and complain later…

4

Ok, just trying to start and understand your approach! :wink:
I have three GIRA blind actuators 16-gang (ArticleNo 503800) and I already have some questions:

1- same channels

  • all three of them use alarms (0/4/0 for wind Channel 3 and 0/4/4 for frost channel 7)
  • Do I represent all KNX channels as Thing channels?
  • so I do get three identical alarm pairs on all three actuators?

2- multiple GAs per one object

  • let’s say I have an rollershutter
  • each rollerschutter consists of those channels:
    ** long-time press (e.g. channel 88)
    ** short-time press (e.g. channel 89)
    ** position blinds feedback (e.g. channel 102)
    ** position blinds (e.g. channel 106)
  • If I get one Thing channel per actuator channel, how do I combine them to one actual “thing” like the living room’s rollershutter?
5

A channel of a thing is bound to its function. A blinds actuator 503800 is able to control 8 blinds, so it has eight main channels for eight blinds. in question of the alarm, this is NOT a channel of the actuator. Instead, the actuator reacts to the alarm.
Never use incoming GA twice! Only one Channel is updated via incoming GA. Also, there is no need at all.
0/4/0 and 0/4/4 seem to be part of weather station, so they belong to this device.

A blinds actuator (for simple blinds) needs exact 4 GA for full function, this is MOVE (1 Bit Up/DOWN), STEP (1 Bit, UP/DOWN, used as STOP), absolute Position Control (8 Bit, DPT5.001) and absolute Position status (8 Bit, DPT5.001). These are the four CO (Communication Objects) you’ve listed anyway)
Sure, you can add more than one GA to the control COs, but please do NOT add these additional GA to openHAB. You don’t need them. On the other hand, the status CO should only have one GA, and this CO shall be the only CO to send via this GA.
So, there are exact four GA for one Channel. Please ensure that all GA are “exclusive” for this channel, so that the Channel is for exactly one actuator channel.
There may be additional functions like a scene channel (per actuator channel). BUT 1) this is not an exclusive channel for that actuator Channel (at least not necessarily) so the actuator is not “owner” of the GA and 2) it’s a different function. As the 503800 has additional CO for positions fully open and fully closed, these two may be additional channels if you want that information as Bit (but it’s in tha main channel anyway, so you won’t need them either.

The Thing is eight Channels for eight blinds. :wink:
Grouping in openHAB is only via Items, there is no such thing as grouping for Channels nor Things.

1 Like
6

Thanks, that clears it up a bit. Not much different from my “virtual device per room” approach, but more device-centric.
So, I’ll give it a try.

side question: What information is the “fetch”-function supposed to give out? I found out, that after a while, I got these

grafik
grafik738×304 5.11 KB

…but no address/communication object information?d

7

Yes, fetch is just to get some info about the hardware.
I’m not aware of a simple option to get any GA information from knx devices (other than via ETS)

fetch is useless :slight_smile: but nonetheless it’s nice to be able to get this sort of information from within openHAB.

1 Like