Map KNX types to ioBroker

[Xyolyp]

I would love to see the built in data types from knx to be mapped including the options for values. For example the type for day or night in the ETS 6 offers me to write day or night by selecting from a list of values but in ioBroker I have to know which numeric value corresponds to day and which to night. It's more prevalent with occupancy and alarm system state types which in knx have built in values like occupied = 0, standby =1 and unoccupied=2. It would be a great quality of life improvement if these mapping were present at the data points in ioBroker.

[boellner]

Please describe where to create these values and how to interact with them, or give an example how it was resolved similarly.

[Xyolyp]

I'll try to explain it with a specific example: The KNX Type 20.002 building mode has the three possible values "Building in use", "Building not used" and "Building protection". The corresponding datapoint in ioBroker represents those values as 0, 1 and 2.

I would like to see the ioBroker datapoint to represent the values as selectable values. This can be accomplished by adding the following json to the common object of the data point:

"states": {
  "0": "Building in use",
  "1": "Building not used",
  "2": "Building protection"
}

By doing so it's no longer a "meaningless" number where one has to figure out which numeric value corresponds to which logical KNX value but it has a clear humanreadable meaning and is even selectable from a dropdown.

I'm not just pointing at this specific datatype but if possible I would love all datatypes which are similar to this (like 1.024 with the values "Day" and "Night" and so on) to have this "mapping" of what numeric value has what logical meaning.

[Xyolyp]

@boellner do you need further details to understand the feature request?

[boellner]

Thank you @Xyolyp , I understood the request and it is a good enhancement. I think what needs to be implemented is specified by the datatypes with contain n (enumeration) in chapter 2 of the https://www.knx.org/wAssets/docs/downloads/Certification/Interworking-Datapoint-types/03_07_02-Datapoint-Types-v02.02.01-AS.pdf You could support me by giving some listings that you might already have

[Xyolyp]

@boellner I'm not sure if I understood you correctly but I only did some research for it and created the one example by hand. While we are at it I'd like to point towards types like 1.008 (UpDown), 1.018 (Occupancy), 1.019 (Window_Door), 1.021 (LogicalFunction) and many similar types. If there already is a programmatically usable set of information where you could read all those mappings from I would appreciate it if you would map as many types as possible and don't artificially limit the mapping to the ones containing n in chapter 2.

[boellner]

Please have a look what is available so far. There are many combined types with enums like of this pattern N3N5r2N6r2N6 - which carry more than one signal information in one knx datagram. This doesn't fit in the IOB 'world' with one knx object mapped to one information.

[Apollon77]

ALternative beside "splitting it up into multiple states" is to convert it into a JSON and use this as value ... this has the "pro" that also all values are together. Yes "using "the info is a bit more complex, but this is always the topic in such cases

[boellner]

Hi @Apollon77 could you make an example how you would do this?

[Apollon77]

First of all you still need to define and write "type specific encoders and decoders". In fac the json option would simpyl generate a JSON string like (useing phantasy values like a color): "{red:0, green: 255, blue: 123}". The pro is that user provides also such a full struing and you parse all values together. r because of such a structure you create sub states like field.red, field.green and field.blue and so have the separated values, but then as soon as one changes you need to read all the others too to have all values for encoding