Let’s try to troubleshoot.
First of all: which IP/KNXnet gateway are you using?
Does it support routing?
Did you try tunnel mode also?
1 Like
Apologies,
I use knx gira x1 ip gateway.
It should support routing.
the ip i use is an multicast adres for the gira x1.
I wasn’t able to connect over tunnel mode even if i specified the ip of the gira x1.
Thanks for the fast reply
Hello,
As a first glimpse on what you have posted, I can identify a number of configuration errors, such as:
- if the connection type is router, you need to make sure your KNX/ip device supports it, if not, change the connection type to “TUNNEL” and set up the ip of the gateway.
- having “bussaddr=” without any address specified and uncommented will not help you much. You can comment it back again, will default to 0.0.0, or set your own physical address (KNX).
Best regards,
George
1 Like
Unfortunately, this log entry is misleading. You will get this message every time you use type=ROUTER (even if there no connection established)
The GIRA X1 is a new product that I haven’t tested (yet)…
I checked quickly online and I saw that it may have some security settings… (reading some more now on this one)
What I found is this:
“The Gira X1 can also be used as KNX interface as it supports both tunnelling and multicast connection to the KNX bus.”
Sources:
Link 1, Link 2, Link 3, Link 4
Have you tried to use the GIRA Project Assistant to connect to the X1? Does this work?
For OH2, I would try (again) the Tunnel mode and enable some logging to see what is going on.
From the openHAB2 console (ssh openhab@localhost -p 8101 with password: habopen)
log:set DEBUG org.openhab.binding.knx
log:set DEBUG tuwien.auto.calimero
and monitor /var/log/openhab2/openhab.log for entries
1 Like
Hi Dim,
Yes i’m able to connect GPA to conect to the x1 and this worked. i was able to tun the lightbulb on.
I didnt know about the connection log.
And i will try to connect using tunnel and i will also try to log the entry.
thanks for your help.
I have a Gira KNX/IP Router.
These are my settings:
ip=224.0.23.12
busaddr=1.0.2
ignorelocalevents=true
type=ROUTER
port=3671
localIp=192.168.1.2
autoReconnectPeriod=10
I followed this HowTo, and the binding works great.
Do you have the ETS KNX software? Can you use it to connect to your Gira X1 and change GA’s?
Hi,
If you managed to use the router connection type, then that’s the way you should go, tunelling is a little more resourceful, you will have denial of connection if too many clients are connected (depending on the gateway)!
Of course, the ets configuration should be a must in terms of routing!
Best regards,
George Erhan
Hi Dries,
yes i do have the ETS KNX software. i’m going to try it.
One more question. Is my items file and sitemap file correct? or did i make a mistake there?
thanks for all the reply’s
They are correct.
It seems to me that if we fix the IP to KNX Bus connection, everything will work
Remember to fix your /etc/openhab2/services/knx.cfg file as @george.erhan said.
Leaving busaddr= unset might? be the root cause of your problem.
Either comment it out using # or set it to something free in your KNX address space.
Post also please the output of the following console command:
config:list "(service.pid=org.openhab.knx)"
1 Like
Hi,
So i assigned the individual addres of the gira.
Also when i make a change to knx.cfg do i need to restart the pi? restart something?
Here is the log after setting commenting out the busaddres.
2017-05-30 20:21:13.700 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2017-05-30 20:21:14.220 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 224.0.23.12:3671 in mode ROUTER.
2017-05-30 20:21:24.814 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item ‘licht_test’ from KNX bus: timeout waiting for group read response: timeout
2017-05-30 20:21:24.816 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address ‘0/0/18’ = '2’
2017-05-30 20:21:34.870 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item ‘licht_test’ from KNX bus: timeout waiting for group read response: timeout
2017-05-30 20:21:34.871 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address ‘0/0/18’ = '1’
2017-05-30 20:21:44.925 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item ‘licht_test’ from KNX bus: timeout waiting for group read response: timeout
2017-05-30 20:21:44.927 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address ‘0/0/18’ = '0’
2017-05-30 20:21:54.980 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item ‘licht_test’ from KNX bus: timeout waiting for group read response: timeout
2017-05-30 20:21:54.982 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Give up, could not read address ‘0/0/18’ after ‘3’ retries.
2017-05-30 20:23:19.243 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x20b - ignored
2017-05-30 20:23:19.244 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x20b - ignored
2017-05-30 20:23:22.582 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x20b - ignored
2017-05-30 20:23:22.583 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x20b - ignored
2017-05-30 20:23:26.604 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x20b - ignored
2017-05-30 20:23:26.607 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x20b - ignored
2017-05-30 20:23:30.848 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x20b - ignored
2017-05-30 20:23:30.851 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: received unknown frame, service type 0x20b - ignored
2017-05-30 20:24:44.681 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'switch.items’
2017-05-30 20:30:58.170 [INFO ] [nx.internal.connection.KNXConnection] - Closing KNX connection
2017-05-30 20:30:58.248 [INFO ] [panel.internal.HABPanelDashboardTile] - Stopped HABPanel
2017-05-30 20:30:58.304 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Stopped HABmin servlet
2017-05-30 20:30:58.362 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Stopped Paper UI
2017-05-30 20:30:58.391 [INFO ] [assic.internal.servlet.WebAppServlet] - Stopped Classic UI
2017-05-30 20:30:58.513 [INFO ] [basic.internal.servlet.WebAppServlet] - Stopped Basic UI
2017-05-30 20:30:58.641 [INFO ] [.dashboard.internal.DashboardService] - Stopped dashboard
2017-05-30 20:31:31.798 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'switch.items’
2017-05-30 20:31:34.895 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'demo.rules’
2017-05-30 20:31:36.647 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'demo.sitemap’
2017-05-30 20:31:36.801 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'demotest.sitemap’
2017-05-30 20:31:38.673 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at /start
2017-05-30 20:31:40.631 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
2017-05-30 20:31:40.844 [INFO ] [assic.internal.servlet.WebAppServlet] - Started Classic UI at /classicui/app
2017-05-30 20:31:41.266 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2017-05-30 20:31:41.559 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2017-05-30 20:31:41.663 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2017-05-30 20:31:42.125 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 224.0.23.12:3671 in mode ROUTER.
2017-05-30 20:32:17.177 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: Boolean (main type 1) loaded
2017-05-30 20:32:17.179 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: Boolean controlled (main type 2) loaded
2017-05-30 20:32:17.179 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: 3 Bit controlled (main type 3) loaded
2017-05-30 20:32:17.180 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: 8 Bit unsigned value (main type 5) loaded
2017-05-30 20:32:17.181 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: 8 Bit signed value (main type 6) loaded
2017-05-30 20:32:17.181 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: 2 octet unsigned value (main type 7) loaded
2017-05-30 20:32:17.182 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: 2 octet float value (main type 9) loaded
2017-05-30 20:32:17.183 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: Time (main type 10) loaded
2017-05-30 20:32:17.183 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: Date (main type 11) loaded
2017-05-30 20:32:17.184 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: 4 octet unsigned value (main type 12) loaded
2017-05-30 20:32:17.185 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: 4 octet signed value (main type 13) loaded
2017-05-30 20:32:17.186 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: 4 octet float value (main type 14) loaded
2017-05-30 20:32:17.186 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: String (main type 16) loaded
2017-05-30 20:32:17.187 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: Scene number (main type 17) loaded
2017-05-30 20:32:17.188 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: Scene control (main type 18) loaded
2017-05-30 20:32:17.195 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: Date with time (main type 19) loaded
2017-05-30 20:32:17.195 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: UTF-8 string (main type 28) loaded
2017-05-30 20:32:17.196 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: 64 Bit signed value (main type 29) loaded
2017-05-30 20:32:17.197 [DEBUG] [tuwien.auto.calimero ] - DPTXlator: RGB color value (main type 232) loaded
2017-05-30 20:32:17.198 [INFO ] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send message to 0/0/4, wait for confirmation
2017-05-30 20:32:17.199 [INFO ] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send message to 0/0/4, wait for confirmation
2017-05-30 20:32:17.200 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 5.3.4 to 0/0/4, low priority hop count 6 tpdu 00 80
2017-05-30 20:32:17.200 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 5.3.4 to 0/0/4, low priority hop count 6 tpdu 00 80
2017-05-30 20:32:17.206 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 5.3.4 to 0/0/4, low priority hop count 6 tpdu 00 80
2017-05-30 20:32:17.207 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 5.3.4 to 0/0/4, low priority hop count 6 tpdu 00 80
2017-05-30 20:32:17.208 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame seq 0, non-blocking, attempt 1 (channel 0) 06 10 05 30 00 11 29 00 bc e0 53 04 00 04 01 00 80
2017-05-30 20:32:17.208 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value ‘OFF’ to datapoint 'command DP 0/0/4 licht_test, DPT main 0 id 1.001, low priority’
2017-05-30 20:32:17.209 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send to 0/0/4 succeeded
2017-05-30 20:32:17.213 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value ‘OFF’ to datapoint 'command DP 0/0/4 licht_test, DPT main 0 id 1.001, low priority’
2017-05-30 20:32:17.213 [DEBUG] [tuwien.auto.calimero ] - process 224.0.23.12:3671: group write to 0/0/4 succeeded
2017-05-30 20:32:17.214 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 5.3.4 to 0/0/4, low priority hop count 6 tpdu 00 80
2017-05-30 20:32:17.215 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame seq 0, non-blocking, attempt 1 (channel 0) 06 10 05 30 00 11 29 00 bc e0 53 04 00 04 01 00 80
2017-05-30 20:32:17.216 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 5.3.4 to 0/0/4, low priority hop count 6 tpdu 00 80
2017-05-30 20:32:17.217 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send to 0/0/4 succeeded
2017-05-30 20:32:17.218 [DEBUG] [tuwien.auto.calimero ] - process 224.0.23.12:3671: group write to 0/0/4 succeeded
2017-05-30 20:32:17.495 [INFO ] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send message to 0/0/4, wait for confirmation
2017-05-30 20:32:17.495 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value ‘ON’ to datapoint 'command DP 0/0/4 licht_test, DPT main 0 id 1.001, low priority’
2017-05-30 20:32:17.496 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 5.3.4 to 0/0/4, low priority hop count 6 tpdu 00 81
2017-05-30 20:32:17.496 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 5.3.4 to 0/0/4, low priority hop count 6 tpdu 00 81
2017-05-30 20:32:17.497 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame seq 0, non-blocking, attempt 1 (channel 0) 06 10 05 30 00 11 29 00 bc e0 53 04 00 04 01 00 81
2017-05-30 20:32:17.497 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value ‘ON’ to datapoint 'command DP 0/0/4 licht_test, DPT main 0 id 1.001, low priority’
2017-05-30 20:32:17.498 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send to 0/0/4 succeeded
Do you see something that can help.
Thanks for the help
In /etc/openhab2/services/knx.cfg you should set an unused bus address that will be used by the Binding.
Don’t use the actual bus address of the GIRA gateway since this may cause a conflict.
So, in case of type=ROUTER, you should have:
ip=224.0.23.12
busaddr=2.2.2
ignorelocalevents=true
type=ROUTER
port=3671
localIp=192.168.0.112
No need to restart something. OH2 will re-read the knx.cfg file and apply the changes immediately.
There is an issue with the config options and you should do the following to be on the safe side:
- Stop OH2 service (
systemctl stop openhab2) - Remove file
/var/lib/openhab2/config/org/openhab/knx.config - Fix your
/etc/openhab2/services/knx.cfgand start OH2 service
2017-05-30 20:21:54.980 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item 'licht_test' from KNX bus: timeout waiting for group read response: timeout
2017-05-30 20:21:54.982 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Give up, could not read address '0/0/18' after '3' retries.
The KNX Binding is sending the message but it is failing to get a reply from the GIRA X1 Gateway…
How is the X1 configured? Is it set as a Line Repeater (PA type of x.y.z) or as a Line Coupler (PA type of x.y.0) ?
If I am not wrong, your GIRA X1 bus address is currently 5.3.4 and this should be changed to another one of Line Coupler type (x.y.0)
This is another problem and we will solve it but I don’t think that it is a blocking issue.
So: Try to change the knx.cfg (delete knx.config first) and check the logs again to see if the situation improves.
(sidenote… don’t spend too much time on this 
) Actually… I don’t like this at all…
The official KNX Specification (v2.1) defines KNXnet/IP Service Type Identifiers for KNXnet/IP protocol version 1.0 (Core) in the range of 0200 to 020F hex.
So this identifier (0x20b) belongs to the KNXnet/IP Core action.
But… the KNX Standard (volume 3 (System Specifications), part 8 (KNXnet/IP), chapter 1) has only 10 Service names used until now (up to 0x20a)… 020B until 020F are unused.
So… it seems to me that GIRA has implemented another Service Type Identifier (outside the KNX standard) for their X1 product (0x20b)…
They have done it before also with Service Type Identifier 0x538 to me…
Boris is treating this here: https://github.com/calimero-project/calimero-core/blob/master/src/tuwien/auto/calimero/knxnetip/KNXnetIPRouting.java
// newer Gira servers have a "reliable communication" option, which uses the
// following unsupported service type; not part of the knx spec
private static final int GiraUnsupportedSvcType = 0x538;
Simple version: The calimero library which is used by the KNX Binding has all the KNX Standard service types implemented. The GIRA X1 is broadcasting some UDP datagrams with an unknown (by calimero) service type identifier. In theory, this warning can be ignored since it shouldn’t block the regular (standard) communications.
You could try to disable “Reliable Communications” in your GIRA X1 using ETS to see if this message disappears.
From my experience, they use these “extended” service types to establish communications between their Gateways and their other solutions (software, etc)
…The good news from all of this is: openHAB2 is receiving multicast messages from the GIRA X1 gateway on your network. If we fix the configs, it will work
Hi Dim,
with an unused basaddres, you mean just a number that i dont use?
what does the knx.config do ??
how do i know if it is an Line Repeater or Line Coupler? Can i look it in ets5 or does it involve the wiring?
What i will do is delete the lknx.config
check if it is inproved.
I will check the config.
One more question.
So i should slide the slider to on and the lightbulb/ maxinbox switch (0/0/4) should change to on?
thanks
Yes. Some new address that does not exist currently in your KNX topology. This bus address will be used by the KNX Binding.
The knx.config is generated and stored automatically by internal openHAB2 processes after reading your knx.cfg.
Yes. When the communications problem will be fixed, you will be able to flick the switch in your sitemap and then the light will react (to ON or OFF)
i did stop the openhab2 service deletet the knx.config and restarted openhab2.
I did change the busaddr to 2.2.2
this is the log file.
2017-05-31 19:15:00.844 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value ‘OFF’ to datapoint 'command DP 0/0/4 licht_test, DPT main 0 id 1.001, low priority’
2017-05-31 19:15:00.844 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 2.2.2 to 0/0/4, low priority hop count 6 tpdu 00 80
2017-05-31 19:15:00.849 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 2.2.2 to 0/0/4, low priority hop count 6 tpdu 00 80
2017-05-31 19:15:00.851 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame seq 0, non-blocking, attempt 1 (channel 0) 06 10 05 30 00 11 29 00 bc e0 22 02 00 04 01 00 80
2017-05-31 19:15:00.852 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send to 0/0/4 succeeded
2017-05-31 19:15:00.853 [DEBUG] [tuwien.auto.calimero ] - process 224.0.23.12:3671: group write to 0/0/4 succeeded
2017-05-31 19:15:00.855 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 2.2.2 to 0/0/4, low priority hop count 6 tpdu 00 80
2017-05-31 19:15:00.857 [INFO ] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send message to 0/0/4, wait for confirmation
2017-05-31 19:15:00.857 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value ‘OFF’ to datapoint 'command DP 0/0/4 licht_test, DPT main 0 id 1.001, low priority’
2017-05-31 19:15:00.858 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 2.2.2 to 0/0/4, low priority hop count 6 tpdu 00 80
2017-05-31 19:15:00.860 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 2.2.2 to 0/0/4, low priority hop count 6 tpdu 00 80
2017-05-31 19:15:00.863 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame seq 0, non-blocking, attempt 1 (channel 0) 06 10 05 30 00 11 29 00 bc e0 22 02 00 04 01 00 80
2017-05-31 19:15:00.865 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send to 0/0/4 succeeded
2017-05-31 19:15:00.867 [DEBUG] [tuwien.auto.calimero ] - process 224.0.23.12:3671: group write to 0/0/4 succeeded
2017-05-31 19:15:00.869 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 2.2.2 to 0/0/4, low priority hop count 6 tpdu 00 80
2017-05-31 19:15:01.598 [INFO ] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send message to 0/0/4, wait for confirmation
2017-05-31 19:15:01.599 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value ‘ON’ to datapoint 'command DP 0/0/4 licht_test, DPT main 0 id 1.001, low priority’
2017-05-31 19:15:01.599 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 2.2.2 to 0/0/4, low priority hop count 6 tpdu 00 81
2017-05-31 19:15:01.603 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 2.2.2 to 0/0/4, low priority hop count 6 tpdu 00 81
2017-05-31 19:15:01.604 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame seq 0, non-blocking, attempt 1 (channel 0) 06 10 05 30 00 11 29 00 bc e0 22 02 00 04 01 00 81
2017-05-31 19:15:01.605 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send to 0/0/4 succeeded
2017-05-31 19:15:01.606 [DEBUG] [tuwien.auto.calimero ] - process 224.0.23.12:3671: group write to 0/0/4 succeeded
2017-05-31 19:15:01.607 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 2.2.2 to 0/0/4, low priority hop count 6 tpdu 00 81
2017-05-31 19:15:01.614 [INFO ] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send message to 0/0/4, wait for confirmation
2017-05-31 19:15:01.615 [DEBUG] [.binding.knx.internal.bus.KNXBinding] - Wrote value ‘ON’ to datapoint 'command DP 0/0/4 licht_test, DPT main 0 id 1.001, low priority’
2017-05-31 19:15:01.618 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: cEMI L-Data.ind from 2.2.2 to 0/0/4, low priority hop count 6 tpdu 00 81
2017-05-31 19:15:01.621 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: add to multicast loopback frame buffer: L-Data.ind from 2.2.2 to 0/0/4, low priority hop count 6 tpdu 00 81
2017-05-31 19:15:01.624 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: sending cEMI frame seq 0, non-blocking, attempt 1 (channel 0) 06 10 05 30 00 11 29 00 bc e0 22 02 00 04 01 00 81
2017-05-31 19:15:01.626 [DEBUG] [tuwien.auto.calimero ] - calimero.link.224.0.23.12:3671: send to 0/0/4 succeeded
2017-05-31 19:15:01.629 [DEBUG] [tuwien.auto.calimero ] - process 224.0.23.12:3671: group write to 0/0/4 succeeded
2017-05-31 19:15:01.632 [DEBUG] [tuwien.auto.calimero ] - KNXnet/IP Routing 224.0.23.12:3671: discard multicast loopback cEMI frame: L-Data.ind from 2.2.2 to 0/0/4, low priority hop count 6 tpdu 00 81
logs look clean
does it work?
Hi Dim,
No it’s still not working 
What can be wrong??
2 things:
a) The X1 device should be configured as a Line Coupler (x.y.0 address)
b) You need a dummy application configured in ETS in order to allow the routing of telegrams via the filter table
If you need help with (a) and/or (b) let me know
Hi Dim,
Sorry but i need help with a and b.
I dont know anything about line coupler
What is it ?
Check this out:
There is a lot of info in that thread related to this topic.