Hello,I have problems connexting OH2 to KNXD.
What I have:
KNX IP Interface 730 with local IP configured (192.168.133.200)
RPI2 with knxd and OH1:
KNXD_OPTS="–eibaddr=0.0.231 -DTRS -b ipt:192.168.133.200"
This working.
Now I try to set up a Rpi2 with OH2 and knxd. The configuration fron my Rpi2 does not work.
I tried some other stuff. For example:
/etc/knxd.conf :
KNXD_OPTS="–eibaddr=0.0.230 ipt:192.168.133.200"
and
knx.cfg :
KNX gateway IP address
ip=127.0.0.1
busaddr= 5.5.5
ignorelocalevents=true
type=ROUTER
localIp=127.0.0.1
knxd is running, I look with vbusmonitor1 what’s goin on. Messages from KNX (PIR, switches…) comming in to vbusmontor but not to OH2.
I can switch with
knxtool groupswrite ip:192.168.133.204 2/1/2 1
KNXD_OPTS="–eibaddr=0.0.230 ip:192.168.133.200"
is not starting at all:
Job for knxd.service failed. See ‘systemctl status knxd.service’ and ‘journalctl -xn’ for details.
OH2 log:
2016-11-10 21:31:47.345 [ERROR] [org.apache.felix.configadmin ] - [org.osgi.service.cm.ManagedService, id=289, bundle=188/mvn:org.openhab.binding/org.openhab.binding.knx/1.9.0.b4]: Unexpected problem updating configuration org.openhab.knx
tuwien.auto.calimero.exception.KNXIllegalArgumentException: non-valid routing multicast /127.0.0.1
at tuwien.auto.calimero.knxnetip.KNXnetIPRouting.(KNXnetIPRouting.java:121)[188:org.openhab.binding.knx:1.9.0.b4]
at tuwien.auto.calimero.knxnetip.KNXnetIPRouting.(KNXnetIPRouting.java:104)[188:org.openhab.binding.knx:1.9.0.b4]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.(KNXNetworkLinkIP.java:192)[188:org.openhab.binding.knx:1.9.0.b4]
at org.openhab.binding.knx.internal.connection.KNXConnection.connectByIp(KNXConnection.java:292)[188:org.openhab.binding.knx:1.9.0.b4]
at org.openhab.binding.knx.internal.connection.KNXConnection.connect(KNXConnection.java:179)[188:org.openhab.binding.knx:1.9.0.b4]
at org.openhab.binding.knx.internal.connection.KNXConnection.updated(KNXConnection.java:448)[188:org.openhab.binding.knx:1.9.0.b4]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1444)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1400)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
I also tried type=TUNNEL
2016-11-10 21:53:37.036 [ERROR] [nx.internal.connection.KNXConnection] - Error connecting to KNX bus: timeout connecting to control endpoint /127.0.0.1:3671
2016-11-10 21:53:37.038 [WARN ] [nx.internal.connection.KNXConnection] - Initial connection to KNX bus failed!
2016-11-10 21:53:37.039 [INFO ] [nx.internal.connection.KNXConnection] - KNX link will be retried in 15 seconds
2016-11-10 21:53:37.039 [ERROR] [tuwien.auto.calimero ] - [CM Configuration Updater (ManagedService Update: pid=[org.openhab.knx])] KNXnet/IP Tunneling 127.0.0.1:3671: establishing connection failed
tuwien.auto.calimero.exception.KNXTimeoutException: timeout connecting to control endpoint /127.0.0.1:3671
at tuwien.auto.calimero.knxnetip.ClientConnection.connect(ClientConnection.java:172)[188:org.openhab.binding.knx:1.9.0.b4]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.(KNXnetIPTunnel.java:117)[188:org.openhab.binding.knx:1.9.0.b4]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.(KNXNetworkLinkIP.java:180)[188:org.openhab.binding.knx:1.9.0.b4]
at org.openhab.binding.knx.internal.connection.KNXConnection.connectByIp(KNXConnection.java:292)[188:org.openhab.binding.knx:1.9.0.b4]
at org.openhab.binding.knx.internal.connection.KNXConnection.connect(KNXConnection.java:179)[188:org.openhab.binding.knx:1.9.0.b4]
at org.openhab.binding.knx.internal.connection.KNXConnection.updated(KNXConnection.java:448)[188:org.openhab.binding.knx:1.9.0.b4]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.provide(ConfigurationManager.java:1444)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1400)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
(And allways only running one Rpi at time, so the Rpi2 with OH1 was switched off during testing.)
O.K. I changed back to ROUTER an used Multicast Address (knx.cfg). OH2 log:
2016-11-11 08:16:18.650 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 224.0.23.12:3671 in mode ROUTER.
2016-11-11 08:16:18.684 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 5.5.5 for Group address 2/0/3.
2016-11-11 08:16:18.997 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 5.5.5 for Group address 2/4/1.
2016-11-11 08:16:19.031 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Ignoring local Event, received from my local Source address 5.5.5 for Group address 2/4/1.
In the startscript of Knxd (/etc/knxd.conf)ist still:
KNXD_OPTS="–eibaddr=0.0.230 ipt:192.168.133.200"
Thanks a lot! The direct connection to the EibMarkt Interface is working! Why I didn’t do that direct? I simply did not get the idea, because I use the KnxD/EibD for so long now. I started using it with Fhem, because direct connection to the Hardwareinterface wasn’t possible (at least I thought so).
And also, the Hardwareinterface (EibMarkt IP-Interface 730) can only handle one connection at a time. I know, it’s written different in the manual. Maybe my Interface is to old and has an old software?
When I connect the ETS3 first and then start OH2 I get this log:
2016-11-12 18:40:33.698 [ERROR] [tuwien.auto.calimero ] - [KNXnet/IP receiver] KNXnet/IP Tunneling 192.168.133.200:3671: could not accept new connection (maximum reached)
2016-11-12 18:40:33.701 [ERROR] [nx.internal.connection.KNXConnection] - Error connecting to KNX bus: error response from control endpoint /192.168.133.200:3671, could not accept new connection (maximum reached)
2016-11-12 18:40:33.704 [WARN ] [nx.internal.connection.KNXConnection] - Initial connection to KNX bus failed!
When I start OH2 first and then the ETS, the ETS does not connect to the Interface. So I’m quite sure, the Interface takes only one connection. I think, that was one of the reasons to use knxd/eibd. It is very nice to be able to program KNX-Hardware while working with OH or fhem. Also, the vbusmonitor is a nice tool to check what is going on on the bus, while OH or fhem or other hardware is working. So I still like to get the knxd working. If it is not possible, i will work like you suggest with OH2 direct connected to the Interface. I will resume the problem in the next post (will take some minutes ;))
Thanks again.
For the knxd: You should leave the configuration the same as you had it before (when it was working with OH1… by the way: what were your OH1 knx configuration settings?)
Then, configure OH2 to use Router mode in the KNX Binding to talk to knxd (which in turn will talk to the IP interface using tunnel backend):
I read your reference. I remember that I read that some time before and tried. It’s not working with my interface. Maybe to old. It’s from 2012.
The data of the Knxds:
Knxd from RPI1 (OH1):
Version: 0.10.13-3
Startparameter:
KNXD_OPTS="–eibaddr=0.0.231 -DTRS -b ipt:192.168.133.200"
I know, these parameters don’t make sense, but they are working. I checked again together with OH2:
RPI1: OH1 and the KnxD Version 10
RPI2: OH2 no Knxd running, OH2 should use knxd from RPI1. This is working.
Knxd from RPI2 (OH2):
Version: 0.11.9-1
KNXD_OPTS="–eibaddr=0.0.230 ipt:192.168.133.200"
starts not with: ip:… instead of ipt:…
I tried to copy the knxd from RPI1 (/usr/bin/knxd) to Rpi2 (and restart). I can use it then by knxtool, but not by OH2.
Tried with both startparameter (see above). I don’t know if it is O.K. to just change out the knxd file or if it has to be compiled on this RPI (both on Jessie)
The Parameter of OH1 (openhab.cfg):
knx:ip=127.0.0.1
knx:type=TUNNEL
knx:localIp=127.0.0.1
Right now I don’t know where to look further. Just to remember: I want the KnxD on Rpi2 with OH2 to work, because the Hardware-Interface does not accept more than one connection.
Your suggestion from last post: Should I let the knxd on RPI1 be running???
I tried it with the RPI1 switched of (to connect to the Hardware interface). This was not working.
No, don’t let knxd run on the RP1 when trying to configure it on the RP2.
You should try to make sure that knxd works properly on the RPI2. As soon as this is done correctly, OH2 will work also in router or tunnel mode (I believe ).
Unfortunately, I don’t know much about knxd because I don’t use it… Their community is not so active also
I checked a bit on https://github.com/knxd/knxd and I saw that (maybe) you should use: “-S ipt:192.168.133.200” to enable the knxd multicast server with an IP tunnel backend.
Try to play around with the knxd settings on RPI2 and test it with ETS also.
Leave the knxd alone (you really don’t need it). Connect OH to KNX in router mode and in this way you can always have ets in tunnel mode in the same time.
Unfortunately… He can’t… the IP Interface that he has (EibMarkt IP-Interface 730) does not directly support KNXnet/IP Routing…
For a direct connection between OH2 & KNX he must use tunnel (and this works)
Using knxd as an intermediate solution, he can enable multicast server (the knxd) and then connect to it using OH2 by setting the KNX Binding in Routing mode (as well as allow more connections to knxd for ETS or busmonitor)
The problem is knxd in this moment… I don’t know how to help because I don’t have experience with knxd
I would try to use the older version (0.10 - stable branch) on the RPI2 and replicate the configs from RPI1 to see if knxd will work correctly. I saw that there are some issues with the 0.11 - master branch of knxd.
now I changed the Knxd:
Rpi2 has Knxd 0.10, same as the Rpi1
OH2 connects to Knxd on Rpi2 (localhost). This working.
(Knxd on Rpi1 stopped)
ETS3 connecting to KnxD on Rpi2. Working!
Then Rpi1 OH1 set to TUNNEL to Knxd on Rpi2. Not working !?!?!!
Then, on Rpi1: knxtool on Rpi2: working.
Then, start Knxd on Rpi1 (just for fun). Knxtool on Rpi1 to Knxd on Rpi1, while Knxd on Rpi2 running and working: working.
Why???
Setting Knxd on both Rpis:
KNXD_OPTS="–eibaddr=0.0.231 -DTRS -b ipt:192.168.133.200"
vbusmonitor running on Rpi2, Knxd2:
when Oh2 writes to Knxd2, every command appears 2 times in the Vbusmonitor, both with pysical address 5.5.5 which is set in knx.cfg of OH2. Why? (ignorelocalevents=true)
when Knxtools ist written from Rpi1:
Command appears 2 times. First with 0.0.231 (knxd) and second 5.5.5. So OH2 repeats the command. why? (ignorelocalevents=true)
Writing on Rpi1 to knxd on Rpi1 by knxtool: working and command appears one time in vbusmonitor of Knxd on Rpi2 with 0.0.231.
next test: OH1 writing to Knxd1 (Rpi1): not working.
Then stopping Knxd2 on Rpi2. Again OH1 writing to Knxd1 (Rpi1): working (the only situation I actully understand)
I don’t understand what’s going on here, but I can live with it for the moment. Rpi1 (OH1) will do the daily work, while OH2 is beeing worked on
If anybody can explain what’s goin on here or has an idea how to solve it…
Thanks again!
Don’t worry too much about this one…
It’s a known (minor) issue and the developer (@lewie) is working on it (see: Link1 & Link2)
Soon, we will have (for OH2) a new KNX Binding from the 1.x world and maybe the 2.x binding will also appear
Are you connecting OH1 (on Rpi1) and/or OH2 (on Rpi2) with Routing or Tunneling to the Rpi2 knxd?
Maybe knxd 0.10 has a limitation on the number of concurrent tunnels that it supports (for forward facing connections)
Try to use Router type in both OH1 & OH2 to see if this works better.
This is strange… Since knxd uses Tunneling for the back-end (the communication to the IP interface), Rpi2 should have occupied the IP interface tunnel and knxd on the Rpi1 shouldn’t have worked…
Now that you got knxd 0.10 (semi) working on Rpi2… Try to make knxd 0.11 work on Rpi2 It seems that it solves many issues (maybe it will improve the situation)
By the way: Use different eibaddr for each knxd, especially if you run them in parallel
O.K., went on…
ROUTER is not working on nither of the two OHs. Went back to TUNNEL.
By the way: The OH2 is much faster in responding on a klick than the OH1. On OH1 there is a noticable delay on klickin, on the OH2 there is no delay at all.
I will make a backup an try again with Knxd 0.11
Both modes are working with KNX1.8 binding.
For ROUTER-mode you need a KNX-Router, it can work in TUNNEL- and ROUTER-mode.
A KNX-Interface only can work in TUNNEL-mode.
When OH2 writes every event twice, you can test this pre Version.
This is a nice info
It seems, I’m missing a lot of information and understanding what I’m actually doing here. My interface is not a KNX-Router, that might explain why knxd is not working in ROUTER-Mode
Right now I’m stuggeling with charts and homgear, so I will try the 1.9 Version later.
Thanks for the help and explanations.
)
).
