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.
I checked the commit logs and found three pull request describing the scenario:
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.
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.
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!
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.
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:
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” }
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.
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.
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.
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?
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.
I would suggest to google for UDP multicast. And for a quick start consider watching one of the many videos like:
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:
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…
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.
