# KNX control item doesn't respond to read request from the bus **URL:** \ **Category:** Bindings\ **Tags:** oh2, knx, control-item\ **Created:** [March 4, 2019, 11:29am UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383 "2019-03-04T11:29:04Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![franks](https://community.openhab.org/user_avatar/community.openhab.org/franks/32/32317_2.png) [@franks](https://community.openhab.org/u/franks)\ **Post date:** [March 4, 2019, 11:29am UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/1 "2019-03-04T11:29:04Z")
Dear Community, I’ve setup a virtual item in OH2 and defined a switch-control to connect it to a GA that is connected to an MDT LED indicator on the knx site to light up an led, if the state is altered. If changing the state in OH2 the new state is written to the knx bus and my device changes its led indicator. So far so good. I’ve also configured the LED indicator to read the GA if bus or the device resets (e.g. if changing the application program). Currently it seems, that the knx binding is not responding to read request from the bus. Or did I miss something? As I understood the control items in the knx binding are exactly for this scenario. Kind regards, Frank. ---
**Author:** ![Udo\_Hartmann](https://community.openhab.org/user_avatar/community.openhab.org/udo_hartmann/32/70871_2.png) [@Udo\_Hartmann](https://community.openhab.org/u/Udo_Hartmann)\ **Post date:** [March 4, 2019, 11:41am UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/2 "2019-03-04T11:41:50Z")
answering to read requests was recently implemented, so this should work with the actual milestone build. ---
**Author:** ![franks](https://community.openhab.org/user_avatar/community.openhab.org/franks/32/32317_2.png) [@franks](https://community.openhab.org/u/franks)\ **Post date:** [March 4, 2019, 11:45am UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/3 "2019-03-04T11:45:10Z")
Thanks Udo. Good to know. I check the release plans than and wait for this to get into stable release. ---
**Author:** ![Udo\_Hartmann](https://community.openhab.org/user_avatar/community.openhab.org/udo_hartmann/32/70871_2.png) [@Udo\_Hartmann](https://community.openhab.org/u/Udo_Hartmann)\ **Post date:** [March 4, 2019, 12:24pm UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/4 "2019-03-04T12:24:12Z")
Did you know, that _stable_ is not for “no issues”, but for “won’t change”? ---
**Author:** ![franks](https://community.openhab.org/user_avatar/community.openhab.org/franks/32/32317_2.png) [@franks](https://community.openhab.org/u/franks)\ **Post date:** [March 4, 2019, 4:58pm UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/5 "2019-03-04T16:58:17Z")
I checked the commit logs and found three pull request describing the scenario: [https://github.com/openhab/openhab2-addons/pull/4257](https://github.com/openhab/openhab2-addons/pull/4257) [https://github.com/openhab/openhab2-addons/pull/4258](https://github.com/openhab/openhab2-addons/pull/4258) [https://github.com/openhab/openhab2-addons/pull/4369](https://github.com/openhab/openhab2-addons/pull/4369) According to these pull requests, they made it into OH 2.4. Therefore I wonder, why I don’t see them working. In the pull requests there is a discussion about the R-Flag (in German L-Flag) of the group address. I didn’t understand this part. Imho the R-Flag cannot be set on a group address but only on communication objects (connected to the GA). So I really lack the knowledge how to configure this and how I can test and see it working. ---
**Author:** ![Udo\_Hartmann](https://community.openhab.org/user_avatar/community.openhab.org/udo_hartmann/32/70871_2.png) [@Udo\_Hartmann](https://community.openhab.org/u/Udo_Hartmann)\ **Post date:** [March 4, 2019, 8:08pm UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/6 "2019-03-04T20:08:44Z")
> [@franks](#): > > In the pull requests there is a discussion about the R-Flag (in German L-Flag) of the group address. I didn’t understand this part. Imho the R-Flag cannot be set on a group address but only on communication objects (connected to the GA). The point is, there is no such thing as a communication object flag in openHAB at all, so the binding has to emulate the correct behavior. ---
**Author:** ![lewie](https://community.openhab.org/user_avatar/community.openhab.org/lewie/32/418_2.png) [@lewie](https://community.openhab.org/u/lewie)\ **Post date:** [March 5, 2019, 11:13am UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/7 "2019-03-05T11:13:07Z")
@franks, at the moment, there is no way to set R-Flag directly. But you can use Channel Type “\*-control” like: (since ~~2.5 Snapshot~~ 2.4 stable) ``` Thing device knx_read_examle "knx_read_examle" @ "knx" { Type switch-control : controlSwitch "Control Switch" [ga="7/0/200"] } ``` Items: ``` Switch controlSwitch { channel="knx:device:bridge:knx_read_examle:controlSwitch" } ``` Channel Type “\*-control” always respond to GroupValueRead requests with the current value of the control channel from openHAB with a GroupValueResponse object to the KNX bus. I find this somewhat unsatisfactory. So I’m working on a thing that only knows one kind of channels and where the flags CRTWUI can be set directly (as Udo\_Hartmann indicated). But I still need time… First the KNX binding modularity has to be taught and this is the harder part. ---
**Author:** ![franks](https://community.openhab.org/user_avatar/community.openhab.org/franks/32/32317_2.png) [@franks](https://community.openhab.org/u/franks)\ **Post date:** [March 5, 2019, 1:57pm UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/8 "2019-03-05T13:57:57Z")
Ah, ok. Got it. From the commit logs on GitHub I got the impression that this behaviour of control channels (answering read requests) made it into OH 2.4. If the next weekend spares me some time, I will try out with the 2.5 SNAPSHOT version. ---
**Author:** ![lewie](https://community.openhab.org/user_avatar/community.openhab.org/lewie/32/418_2.png) [@lewie](https://community.openhab.org/u/lewie)\ **Post date:** [March 6, 2019, 8:17am UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/9 "2019-03-06T08:17:09Z")
You’re right, we were able to finish the changes for 2.4! Since openHAB 2.4 stable all channel types “\*-control” answer with the value via a GroupValueResponse to the KNX bus. Please note, if the channel type “\*-control” has no value, there will be no response to the KNX bus! ---
**Author:** ![franks](https://community.openhab.org/user_avatar/community.openhab.org/franks/32/32317_2.png) [@franks](https://community.openhab.org/u/franks)\ **Post date:** [December 30, 2019, 1:49pm UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/10 "2019-12-30T13:49:15Z")
Now on holiday I’ve come back to this topic and did some further investigation. My current assumption is, that the problem is with the KNX IP router I use in my installation. It seems, that the router doesn’t forward GroupValueRead telegrams, if there is no status object connected to the corresponding GA on the KNX side. I checked this by connecting the calimero command line tools to the router. There is no trace or clue that the GroupValueRead makes it throught the router to the IP layer. To prove my assumption, I’ve written an email to the technical support of the IP router vendor. If I get a response I will update this thread accordingly. ---
**Author:** ![franks](https://community.openhab.org/user_avatar/community.openhab.org/franks/32/32317_2.png) [@franks](https://community.openhab.org/u/franks)\ **Post date:** [February 1, 2020, 6:40pm UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/11 "2020-02-01T18:40:16Z")
I’ve come closer to the solution and want to share what I’ve found out so far: The control items only seem to work in my installation when I configure the KNX bridge to be of type **“ROUTER”** using the ip multicast address. When using the type “TUNNEL” it will not work with the MDT router. When now generating a GroupValueRead telegram with the group monitor in ETS, the bus still gets no answer from OH but I can see the following entry in the event log: ``` ... - Item 'Wohnzimmer_Zwangsfuehrung_Status' received command REFRESH ``` So the GroupValueRead telegram is picked up in some way by OH, but OH doesn’t send a corresponding GroupValueResponse telegram. Edit: In the meantime I did some further investigations and wrote them down in my latest comments on the corresponding github issue. See there for details: > > > \## Prerequisites > 1. A configured knx thing with a channel of type \*-control (e.…g. switch-control) > 2. A link of the channel to an item in OH2 (e.g. Switch) > 3. A sitemap with an element type referencing the item (e.g. Switch) > 4. The state if the item is defined (e.g. ON) > > \## Expected Behavior > If the bus sends a read request to the main GA of the control channel, OH responds with a read response telling the current state of the item. > > \## Current Behavior > If the bus sends a read request to the main GA of the control item, there is no response from OH2. > > \## Use Case > The bus lost and regains power or the device the GA is connected to was reset. Most devices can be configured to send a read request to get the current state. > > \## Possible Solution > None. > > \## Steps to Reproduce (for Bugs) > 1. Configure a device to read from the main GA in ETS > 2. Configure OH and the knx binding as described in the prerequisites > 3. Start the group monitor in ETS > 4. Select the main GA of the control item > 5. Read from the address -\> A read request is seen on the bus > 6. Wait some 10 seconds > 7. Verify that there is no response to be seen on the bus > > \## Context > My context is that I want to implement the general use case mentioned above. > > In my case I use an LED indicator with 12 status LEDs build by MDT. One of the LEDs displays the status of an item owned by OH2. When I change the state the bus writes are OK and the LED displays the state accordingly. > > But if the LED indicator lost connection either by lost power on the bus or because it was reprogrammed, it tries to get the current state from OH by sending a read request but never gets an answer and therefore doesn't display a state at all. This is the default as given by the application program of the LED indicator. > > I followed the documentation of control items with the exception that there is only one channel (the knx channel) linked to the item. No second hardware is involved. I guess that this is called a virtual item in the OH2 terminology. > > \## My Environment > \* I'm using openHAB 2.4 running from a docker image on my NAS > \* The NAS (docker host) is running Ubuntu 18.04 LTS > \* For network connectivity I'm using a macvlan directly attached to the main ethernet interface > \* For programming and testing the knx installation I'm using the ETS5 professional version ---
**Author:** ![FCZ\_1896](https://community.openhab.org/letter_avatar_proxy/v4/letter/f/f9ae1b/32.png) [@FCZ\_1896](https://community.openhab.org/u/FCZ_1896)\ **Post date:** [April 12, 2020, 6:34pm UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/12 "2020-04-12T18:34:40Z")
Not sure, but i think i am struggling exactly with this problem. - ETS and the KNX bus do everything correct. They switch ON / OFF as expected. Leveraging the ETS diagnostic tool, all perfect and all as expected - When using openHAB 2.5.3 Release Build, and the iPhone App to switch ON, than the KNX bus reacts as expected, however, in the GUI the status of the Switch immediately jumps back to OFF (even the status in the KNX bus is ON). The same happens the other way around. If turning OFF, Openhab remains ON, whilst the KNX does the right thing and goes to OFF. - Reading in the ETS diagnostic tool the current value turns into Openhab immediately updating to the correct status (ON or OFF) ETS ++++ - GA with MDT Switch BE-GT08x.01 Glass Plus - connected to the GA (0/1/20) taste 3 and LED 3; There is no actor. Openhab +++++++ Things: > Bridge knx:ip:bridge [ > type=“TUNNEL”, > ipAddress=“192.168.200.1”, > portNumber=3671, > readingPause=50, > responseTimeout=10, > readRetriesLimit=3, > autoReconnectPeriod=30 //optional, do not set \<30 sec. > ] { > Thing device generic [ > address=“1.1.3”, > fetch=true, > pingInterval=300, > readInterval=3600 > ] { > Type switch-control : FerienAbwesend “Wir sind in den Ferien / Abwesend” [ga=“\<0/1/20”] > } > } Items: > Switch FerienAbwesend “Wir sind in den Ferien / Abwesend [%s]” (All, gTechnik, gUG\_Garage, gSQLAllChangesRestoreOnStartup) { channel=“knx:device:bridge:generic:FerienAbwesend”, autoupdate=“false” } ---
**Author:** ![franks](https://community.openhab.org/user_avatar/community.openhab.org/franks/32/32317_2.png) [@franks](https://community.openhab.org/u/franks)\ **Post date:** [April 13, 2020, 12:49pm UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/13 "2020-04-13T12:49:42Z")
Yeah, looks like you have hit the same problem. Funny that your use case (a flag indicating that you are on holiday) is exactly the same I’m also try to implement. You saw my hint that with my MDT KNXnet/IP interface only works in a router bridge configuration? Also, if you are interested in the technical background, follow my GitHub issue, I’ve opened for it. Maybe you can place a vote on it to raise attention. Stay healthy, Frank ---
**Author:** ![FCZ\_1896](https://community.openhab.org/letter_avatar_proxy/v4/letter/f/f9ae1b/32.png) [@FCZ\_1896](https://community.openhab.org/u/FCZ_1896)\ **Post date:** [April 13, 2020, 1:12pm UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/14 "2020-04-13T13:12:56Z")
Hi Frank, on GitHub, i have added the same information yesterday already. To your fact about the MDT KNXnet/IP interface: Unfortunately this does not help me, as I am using the enertex KNXnet/IP Router which for whatever reason works in TUNNEL mode only. I was unable to make it work in Router mode with OH. Given the fact that I am using another interface we can rule out that your MDT KNXnet/IP interface is the issue. To me it looks like a more fundamental problem of OpenHAB 2.x also because in OH 1.8 my intention does work. ---
**Author:** ![lewie](https://community.openhab.org/user_avatar/community.openhab.org/lewie/32/418_2.png) [@lewie](https://community.openhab.org/u/lewie)\ **Post date:** [April 13, 2020, 4:49pm UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/15 "2020-04-13T16:49:17Z")
Please test this for using ROUTER mode for enertex KNXnet/IP Router: > Bridge knx:ip:bridge [ > type=“ROUTER”, > localSourceAddr=“0.0.50”, //or any free KNX actuator address that you can freely assign > portNumber=3671, > readingPause=50, > responseTimeout=10, > readRetriesLimit=3, > autoReconnectPeriod=60 > ] {…} A router does not work over “ipAddress”. Make sure to delete this parameter in a ROUTER configuration!! (internally ipAddress=“224.0.23.12” is used then over udp, which is the official Multicast Address) > Thing device generic [ > readInterval=3600 //readInterval=0 only read at startup > ] { > Type switch-control : FerienAbwesend “Wir sind in den Ferien / Abwesend” [ga=“\<0/1/20”] > } Parameter “fetch” is dangerous for some actuators, they do not like the to be queried internals. “fetch” is already ignored if no “address” parameter is present or commented out. EDIT: Additionally be careful with autoupdate=“false”. A powerful parameter that can cause quite a bit of confusion. > [@Using autoupdate=false](https://community.openhab.org/t/using-autoupdate-false/55234/2): > > autoupdate = false was created to handle the case where you have a device that automatically report’s its state changes to OH. Imagine the following scenario. user clicks on sitemap to send ON command to an Item Item forwards the ON command to the binding If autoupdate=true, the Item changes state to ON. If autoupdate=false the Item remains OFF. There was an error and the device never turned OFF. If you are using autoupdate=true (which is the default) then the Item will be set to ON and every… ---
**Author:** ![FCZ\_1896](https://community.openhab.org/letter_avatar_proxy/v4/letter/f/f9ae1b/32.png) [@FCZ\_1896](https://community.openhab.org/u/FCZ_1896)\ **Post date:** [April 13, 2020, 6:00pm UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/16 "2020-04-13T18:00:46Z")
Thanks Helmut. Before i try, one question: My OH 2.5 sits in one network 192.168.X.Z whilst the KNXnet/IP Router sits in a network that is 192.168.200.0/24. Both are connected via a firewall that opens the port 3671. Considering this: > (internally ipAddress=“224.0.23.12” is used then over udp, which is the official Multicast Address) it would in my understanding then require that the OH 2.5 device can send towards 224.0.23.12 into the network where the KNXnet/IP Router device sits. Correct? Second question, I am very interested into your statement regarding 224.0.23.12 / udp / multicast. Is there any further documentation available? Do you know? ---
**Author:** ![franks](https://community.openhab.org/user_avatar/community.openhab.org/franks/32/32317_2.png) [@franks](https://community.openhab.org/u/franks)\ **Post date:** [April 14, 2020, 7:30am UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/17 "2020-04-14T07:30:41Z")
> [@FCZ\_1896](#): > > it would in my understanding then require that the OH 2.5 device can send towards 224.0.23.12 into the network where the KNXnet/IP Router device sits. Correct? It is not in the OH2 responsibility to make sure that the multicast packets reach their target. OH2 only sends the broadcast to the multicast group 224.0.23.12. Every member of the network that is interested in this multicast has to join the multicast group. This is what KNXnet/IP routers do. In other words, it is in the responsibility of the receiver to express their interest in receiving multicast packets. If routers are involved that connect different networks, it is their responsibility to forward the multicast packets to interested nodes in that networks. > [@FCZ\_1896](#): > > Second question, I am very interested into your statement regarding 224.0.23.12 / udp / multicast. Is there any further documentation available? Do you know? I would suggest to google for UDP multicast. And for a quick start consider watching one of the many videos like: [![](https://img.youtube.com/vi/fRiOOWJDcK8/maxresdefault.jpg "Lecture 1 - IP Multicast Basics and Addressing") ](https://www.youtube.com/watch?v=fRiOOWJDcK8) [![](https://i.ytimg.com/vi/AvbSMBKBZgY/hqdefault.jpg "Multicast Part 1 - Intro") ](https://www.youtube.com/watch?v=AvbSMBKBZgY) ---
**Author:** ![lewie](https://community.openhab.org/user_avatar/community.openhab.org/lewie/32/418_2.png) [@lewie](https://community.openhab.org/u/lewie)\ **Post date:** [April 14, 2020, 8:11am UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/18 "2020-04-14T08:11:19Z")
Complementary to @frank’s descriptions: Via VPN it is easier or more reasonable to connect the router via TUNNEL mode. Within one or the other side of a VPN, a router can communicate via 224.0.23.12:3671 in ROUTER mode or multicasting with other openHAB or KNX instances (ETS, other routers, interfaces, openHAB). Practical example: 1. A house with several floors. Each floor has a router. Within the house network, all KNX routers communicate via ROUTER mode. Via VPN I dial in to administrate. Via ETS I can now connect to each router via VPN in TUNNEL mode for administration etc.. 2. Again the house with several routers. An external location (weekend house) should be integrated into the KNX network via VPN. There is a permanent VPN connection between the locations. The external openHAB is now connected via VPN using TUNNEL mode to the fixed IP address of one of the routers. The used router can do both at the same time. So it can now communicate via multicast 224.0.23.12:3671 with all other routers in the house and additionally via the fixed TUNNEL mode connection with the openhAB at the external location. The basic advantage of the ROUTER mode is that no connection has to be lost and re-established. There is also no counterpart that can lose the connection. ROUTER mode is the more modern and robust version. It should also work to make multicast over VPN possible (But is it really needed?): [https://networkengineering.stackexchange.com/questions/44774/which-vpn-types-protocols-inherently-support-multicast-traffic](https://networkengineering.stackexchange.com/questions/44774/which-vpn-types-protocols-inherently-support-multicast-traffic) ---
**Author:** ![Udo\_Hartmann](https://community.openhab.org/user_avatar/community.openhab.org/udo_hartmann/32/70871_2.png) [@Udo\_Hartmann](https://community.openhab.org/u/Udo_Hartmann)\ **Post date:** [April 16, 2020, 9:03pm UTC](https://community.openhab.org/t/knx-control-item-doesnt-respond-to-read-request-from-the-bus/69383/19 "2020-04-16T21:03:47Z")
Multicast is per default not routed, you have to define the route in your router. It’s also possible that the firewall prevents multicast. The question is, how are the network segments separated?