Openhab-addons: [knx] Support for transformations

[JonasMH]

The problem

I have a bunch of door contacts/sensors connected through KNX, but each of the contacts outputs true when closed and false when opened, which is opposite of how OpenHAB stores CLOSED/OPENED as seen in the following table:

| Actual door state | KNX signal | OpenHAB State |
|-------------------|------------|---------------|
| Opened | 0 | Closed |
| Closed | 1 | Opened |

So what I want to do is to invert the state in OpenHAB without altering the KNX setup/device.

Current solution

Right now I have two items, one receiving the raw state, which in turn triggers a rule which writes the inverted state to the actual item like so:

knx.things:

[...]
Type contact        : R09_16_Opened         [ ga="<4/3/13" ]
[...]

r09.items

Contact R09_16_Opened "Door status [%s]"
Contact R09_16_Opened_Raw "Door status raw" { channel="knx:device:bridge:r09:R09_16_Opened" }

r09.rules

rule "R09 Door Invert"
when
    Item R09_16_Opened_Raw received update
then
    if(R09_16_Opened_Raw.state == CLOSED) {
        R09_16_Opened.postUpdate(OPEN)
    } else if (R09_16_Opened_Raw.state == OPEN) {
        R09_16_Opened.postUpdate(CLOSED)
    } else {
        R09_16_Opened.postUpdate(R09_16_Opened_Raw.state)
    }
end

But as evident by the amount of lines required to do so, it's pretty cumbersome and clutters the code when there's multiple door contacts.

Suggested solution

Allow for a transform for each read/write, for example the modbus binding has transforms with the following syntax:

Thing data outdoor_temp [ readStart="0", readValueType="int16", readTransform="JS(divide10.js)" ]

I would imagine this would shorten my code to something similar to the following:

knx.things:

[...]
Type contact        : R09_16_Opened         [ ga="<4/3/13", readTransform="JS(invertDoor.js)" ]
[...]

r09.items

Contact R09_16_Opened "Door status [%s]" { channel="knx:device:bridge:r09:R09_16_Opened" }

Completely eliminating the rule

So if something similar was available for the KNX binding it would fix this and similar easy of use issues.

[J-N-K]

What about profiles for the channels? I don‘t know if we have an appropriate profile at the moment, but inverting a Boolean seems to be a good idea (we already have adding offsets, which is quite similar I think). But that would belong to ESH.

[JonasMH]

Are you thinking of something like the following?

knx.things:

[...]
Type contact        : R09_16_Opened         [ ga="<4/3/13" ]
[...]

r09.items

Contact R09_16_Opened "Door status [%s]" { channel="knx:device:bridge:r09:R09_16_Opened:inverted" }

Where 'inverted' has been appended to the channel string.

EDIT:
Disregard this comment, didn't know about profiles on channels, they're pretty new I guess. :) But that seems like a good solution

[J-N-K]

I don‘t know from memory how this is configured in DSL. In PaperUI you can select a „Profile“ when linking a channel to an item (such as applying a MAP or adding an offset). You could try a MAP which maps CLOsED to OPEN and vice versa. Or we could add a „invert“ profile.

[JonasMH]

Seems like the 'invert' profile would be the correct solution for most items, I did run into another problem though where the KNX status object is inverted in relation to the KNX control object, which is only solvable without rules if each group address can be transformed somehow.

[J-N-K]

Please add an issue for that in the ESH repository and link this issue. I‘m willing to implement that if the ESH maintainers agree that this is a mergable feature.

[davidgraeff]

Most profiles are implemented in the openhab-core and openhab2-addons bundles of the transformations. The invert profile could be added to the map transformation, I think.

[ssalonen]

As discussed here, profiles might be elegant solution when reading data, however not suitable for writing (pointed out by @JonasMH ) as far as I know?

[davidgraeff]

MQTT and Modbus are using transforms for input and output (unfortunately that means converting to java String back and forth). The coming http 2 binding is also using transformations that way, so I do not see a reason why the knx binding would not use transformations as configuration parameters for channels.

[vguna]

Hey. Any news on this? I started to use Openhab with my KNX system and I also have my contacts returning 1 for closed and 0 for open in KNX. This is mainly to reflect the status according to an alarm. If someone cuts the wire, it will end up in 0 and triggers the alarm. Because I will attach an alarm system later based on that value, I would like to avoid inverting in the KNX system but doing it on Openhab side. Any plans with those transformers?
I would like to avoid having to write all that boilerplate rule code mentioned above to get this done for all my contacts :).

[aximut]

Same, changing it on the KNX side would mean a significant effort for a feature that could be changeable in OpenHAB by a simple parameter. Also, the elegance in the code gets lost if such an overhead as a proxy contact is required.