[SOLVED] Knx2: binding coupling doesn't work anymore

staehler67 · December 28, 2018, 8:29am

Hi,
yesterday I migrated from KNX1 to KNX2. I have some coupling between bindings like (KNX binding and squeezbox binding and others …)

The items-File couples the knx binding with the squeezebox binding:

Switch sq_wohnen_power "Wohnzimmer Lautsprecher" { channel="knx:device:bridge:Steckdose:Ch_E", channel="squeezebox:squeezeboxplayer:bebaee7f:wohnen:power" }

KNX-things-File:

Thing device Steckdose "20fach Schaltaktor Steckdosen" [ address="0.1.6", fetch=false, pingInterval=600, readInterval=0 ]
{
    Type    switch-control  :   Ch_E    "Verstärker WZ"	                    [ ga="1/5/2+<3/5/2" ]
}

squeezebox-things-File:

Bridge squeezebox:squeezeboxserver:bebaee7f [ ipAddress="192.168.2.1", webport=9001, cliport=9090 ]
{
    Thing squeezeboxplayer wohnen[ mac="00:04:20:06:21:aa"]
    Thing squeezeboxplayer schlafen[ mac="00:04:20:06:21:6d"]
    Thing squeezeboxplayer bad[ mac="00:04:20:17:44:8d"]
    Thing squeezeboxplayer gaeste[ mac="00:04:20:1e:e7:12"]
}

which worked with KNX1 fine. When I switched ON my Squeezebox, the corresponding KNX GA switchend ON. When I switched ON the KNX GA, the Squeezebox starts.

With KNX2 this does not work anymore. Is this a bug, a feature or did I miss anything?

I know, that I can solve this with rules, but this would be a mess and in my opinion this binding coupling should work, as this example comes from the docu:

Switch demoSwitch "Light [%s]" <light> { channel="hue:0210:bridge:1:color", channel="knx:device:bridge:generic:controlSwitch" }

Hope anybody can help. Thank you.

BTW: it seems, that couplings with other binding doesn’t work, too

curlyel · December 28, 2018, 9:09am

Use thing type "switch" instead of “switch-control”, e.g.:

Thing device Steckdose "20fach Schaltaktor Steckdosen" [ address="0.1.6", fetch=false, pingInterval=600, readInterval=0 ]
{
    Type    switch  :   Ch_E    "Verstärker WZ"	                    [ ga="1/5/2+<3/5/2" ]
}

staehler67 · December 28, 2018, 11:51am

Thanks for the hint. I forgot to mention, that I’ve already tried switch and switch-control. Both don’t work

curlyel · December 28, 2018, 12:20pm

Just tried myself…

Use case:
Zigbee motion detector is switching a KNX actor. This works, meaning that if the Zigbee motion detector sends “ON/OFF” to the the KNX actor listening for 1/0/4:

KNX thing:

Thing device motiondetectors "KNX Bewegungsmelder Zigbee" @ "Zentral"
    {
        Type switch-control : ti01 "Melder TI01"                    [ga="1/0/4"]
    }

Item:

Switch   KNX0022_KanalH   "Büro Deckenlicht"              {channel="knx:device:bridge:motiondetectors:ti01", channel="zigbee:philips_sml001:fdxxxxxx:001788xxxxx:motion"}

Two observations:

It worked only, if I had just the sending ga configured (notice: no additional listening ga’s)
when changing the channel from switch to switch-control I had to restart openHAB (not just dropping the file or restarting the binding).

So could you try removing the listening ga’s from your channel and then restart openHAB?

openHAB-log:

2018-12-28 13:29:21.617 [vent.ItemStateChangedEvent] - KNX0022_KanalH changed from OFF to ON
2018-12-28 13:29:21.618 [vent.ItemStateChangedEvent] - Zigbee_TI01_Occupancy changed from OFF to ON
2018-12-28 13:29:35.679 [vent.ItemStateChangedEvent] - KNX0022_KanalH changed from ON to OFF

ETS groupmonitor:

|#|Zeit|Dienst|Flags |Prio|Quell-Adresse|Quell-Name|Ziel-Adresse|Ziel-Name|Rout|Typ|DPT|Info|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|5|28.12.2018 13:29:25,248|vom Bus||Niedrig|0.0.255|IP-Schnittstelle N 148/22|1/0/4|OG Decke Büro|6|GroupValueWrite|  1.001 Schalten|$01|
|17|28.12.2018 13:29:37,742|vom Bus||Niedrig|0.0.255|IP-Schnittstelle N 148/22|1/0/4|OG Decke Büro|6|GroupValueWrite|  1.001 Schalten|$00|

BTW: Just noticed, that this syntax is working too to link channels from different bindings:

Switch   KNX0022_KanalH   "Büro Deckenlicht"              {channel="knx:device:bridge:motiondetectors:ti01, zigbee:philips_sml001:fdxxxxxx:001788xxxxx:motion"}

staehler67 · December 28, 2018, 2:38pm

Thanks a lot for your investigations, that helped. At least my sqeezebox is able to switch on my amplifier again. I’ve to look now, which other items suffer from this “feature”.
I’m not sure if this is now a bug? I’ld prefer to read the GA state from KNX (listening GA), which regarding to the docu should be possible.
What do you think?

curlyel · December 28, 2018, 3:09pm

Might be
Pinging @sjka: Is it intended or should we file a issue for it?

But I think you can circumvent for the time beeing with having two different channels - one for the “real” actor channel and one just for replicating commands from your Squeezebox binding:

Thing device Steckdose "20fach Schaltaktor Steckdosen" [ address="0.1.6", fetch=false, pingInterval=600, readInterval=0 ] 
{ 
      Type switch: Ch_E "Verstärker WZ" [ ga="1/5/2+<3/5/2" ] 
}
Thing device Steckdose-control-channels
{
      Type switch-control: verstaerker "Verstärker WZ" [ga="1/5/2"]
]
[/quote]

The separation of control-channels from “common” channels is related to preventing duplicate commands on the KNX bus. So it might be o.k. that we need a separate channel here.

Why this channel is just working (sending commands to the bus) as long as no listening ga is configured is still unclear to me. Same applies to the fact that we have to restart openHAB once we change a channel from type “switch” to “switch-control”.

Btw.: If my former post solves your initial issue, mind you marking it as solution to enable others to find it quicker?

staehler67 · December 28, 2018, 4:00pm

Thanks again for you help. I closed this post as solved.

curlyel · December 29, 2018, 10:34am

Hi again,
I had to reconsider the idea of “regular” and “control” channels in KNX2 binding in combination with openHAB 2.4.

I had to learn, how state changes are processed in multi-channel item binding:
If one channel gets updated, then the other channel(s) get this state change too. This is the default behaviour.

BUT: This is just a state change. None command is sent to the other channel(s). In our KNX case, no telegram is sent out to the KNX bus if we have a regular channel like “switch”.

If we want to issue a command to a “foreign bindings channel” instead of just updating the state, then the newly introduced Link Profiles come into play. If we use the follow-profile like this:

Switch   KNX0022_KanalH   "Büro Deckenlicht"  {channel="knx:device:bridge:actor-22:kanal-H" [profile="follow"], channel="zigbee:philips_sml001:fdxxxxxx:001788xxxxx:motion"}

Every state change of the Zigbee channel is triggering a command send out to the KNX channel which in turn generates a GroupWrite on the KNX bus. At the end this is what we want - right?

Refer to:

https://www.openhab.org/blog/2018-12-17-openhab-2-4-release.html
https://www.openhab.org/docs/configuration/items.html#profiles

Why was it working with the control-channels without the follow-profile?
Well, this is more a “side-effect”. If we think about what control-channels are meant for, then it’s clear, that every state change generates a telegram on the bus e.g. to propagate actor or sensor states of a “virtual” KNX device which lives inside openHAB instead of on the bus itself.

Conclusion:
Although it’s working with KNX control channels, it’s likely not the “right” way of doing it. This has introduced unnecessary complexity (separate thing).
So I’d prefer the

[profile="follow"]

stuff from now on

Now I’m quite sure: No! This works exactly as it was (well!) designed for. Just needed to re-consult the documentation and some minutes of thinking to better understand.

So - Sorry @sjka for the noise.

staehler67 · December 29, 2018, 4:21pm

Thank you again for your detailed explanation, that helped much. I need to spend some time to read and understand the documentation, but at least I followed your recommendation and it works