Writing feedback GAs to the KNX bus for non-KNX actuators

[binderth (Thomas Binder)]

I know, it’s perhaps not 100% openHAB-related. But…

• I have a TP-Link smart WiFi Plug, which I use to switch a Light on and off.
• The Light can be triggered via openHAB (UI, rule, whatever) and
• I’d like to also trigger the light with my KNX sensor (switch)

and that’s the part of my question: I like the LED on the sensor to indicate, whether the light is on.

So: I configured the TP-Link HS110 as a Thing and I linked the “switch”-channel to an item and I also linked the KNX-channel to the item:

The KNX-channel is configured as follows:

channels:
  - id: FlurKGDL
    channelTypeUID: knx:switch
    label: Flur Licht
    description: ""
    configuration:
      ga: 1.001:1/0/5+<1/0/3

1/0/5 => is the GA for the switch
1/0/3 => is usually the feedback GA I use for KNX actuators.

My thinking is, I use the sensor to provide the reading GA and the LED of the KNX switch uses that:

But how can I send the 1/0/3 to the bus via openHAB rules or something? I’m a bit blocked right now - or I’m just thinking in a dead end?

long story short: I’d like the following:

• Light switches on/off via
  ** TP-Link App
  ** openHAB UI
  ** KNX sensor
• KNX bus knows the status of the light (1/0/3)
• KNX sensor can show the status in the LED

[Oggerschummer (Thomas)]

How about a switch-control channel for the knx status (1/0/3) and linking it using the follow-profile to the TP-Link channel?
Something similar to this , except that the first channel ist you TP-Link switching channel.

[Confectrician (Jerome Luckenbach)]

Not sure if it is the best practice, but i have solved that with an additional channel just for the status LED of my switch, since i am always facing problems when trying to do this in one channel and more than one group adress configured.

My setup (which i think should be logically similar to yours):

• Light is connected via mqtt and configured via openHAB
• Switch is a configured KNX one and connected to openHAB
• Switch has Buttons and Status LEDs available via communication objects

I have a channel that is doing the usual “switch job” and one that is taking care of the status group adress.

- id: controlTaste12
    channelTypeUID: knx:switch-control
    label: Taste 1/2
    description: null
    configuration:
      ga: 1/1/10
- id: taste12Status
    channelTypeUID: knx:switch-control
    label: taste12Status
    description: ""
    configuration:
      ga: 1/1/13

Both are linked to the same group item and group adresses getting written, when something changes no matter where the command/update is coming from.

[binderth (Thomas Binder)]

@Oggerschummer

How about a switch-control channel for the knx status (1/0/3) and linking it using the follow-profile to the TP-Link channel?

hmm… I did the following with the item KNXFlurKeller_FlurLichtRuckmeldung:

the KNX channel is a switch channel with 1/0/3 and the TP-Link channel is with follow for the “Betrieb”-Channel:

But unfortunately, neither the item KNXFlurKeller_FlurLichtRuckmeldung changes according to the “real” items - and of course no telegram is sent to 1/0/3:

2021-01-31 15:49:41.849 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'KNXFlurKeller_FlurLicht' received command ON
2021-01-31 15:49:41.860 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'TPLinkPL12Keller_Betrieb' received command ON
2021-01-31 15:49:41.871 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'KNXFlurKeller_FlurLicht' predicted to become ON
2021-01-31 15:49:41.882 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'TPLinkPL12Keller_Betrieb' predicted to become ON
2021-01-31 15:49:41.889 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'KNXFlurKeller_FlurLicht' changed from OFF to ON
2021-01-31 15:49:41.893 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TPLinkPL12Keller_Betrieb' changed from OFF to ON
2021-01-31 15:49:43.950 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'KNXFlurKeller_FlurLicht' received command OFF
2021-01-31 15:49:43.956 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'TPLinkPL12Keller_Betrieb' received command OFF
2021-01-31 15:49:43.968 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'KNXFlurKeller_FlurLicht' predicted to become OFF
2021-01-31 15:49:43.974 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'TPLinkPL12Keller_Betrieb' predicted to become OFF
2021-01-31 15:49:43.980 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'KNXFlurKeller_FlurLicht' changed from ON to OFF
2021-01-31 15:49:43.986 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TPLinkPL12Keller_Betrieb' changed from ON to OFF

What did I miss?

[binderth (Thomas Binder)]

@Confectrician

Both are linked to the same group item and group adresses getting written, when something changes no matter where the command/update is coming from.

That would work also I guess, but if I finally find the time to integrate the “KNX” switch actuator for the cellar, then I have to rework everything… but on the other hand… Why do I need “KNX logic” for something “non KNX”…? need to think about it.

[Confectrician (Jerome Luckenbach)]

@binderth

Why do I need “KNX logic” for something “non KNX”…?

Maybe there was a misunderstanding.
I have no knx logic in place at all.
Just separate (openHAB/Thing) channels for status and command.
In my ets project i have configured the switch and its status led to one group adress like i would have done it anyway in my case.

[binderth (Thomas Binder)]

@Confectrician

I have no knx logic in place at all.

yes, I did thought so. I have the KNX logic in my head and in my config right now… and I’m asking myself, if this is that a good idea…