KNX Binding: tunneling request with invalid rcv-seq - sporadic dysfunction - help needed

Add-ons Bindings
,
1

Hello Community

I’m having an issue with my current OH2 setup. After searching on multiple internet platforms and forums for hours, I finally decided to request assistance here.

I have a small environment with OH2 KNX and DMX bindings, some KNX actors and wall switches, some DMX lights and a sitemap with +/- 10 items displayed. I made it to set up everything in order to turn on my DMX downlights in the corridor by the use of a KNX motion sensor. The same for KNX buttons to switch DMX-connected LED strips in bathroom, living room, etc.
A great thing, basically.

My issue from functional view:

However after well-running for maybe 1 day, 1 week, or sometimes just a few hours … KNX won’t be able anymore to switch DMX lights. Or in other words, OH2 does not recognize KNX telegrams anymore. From OH2 (UI) to KNX works but with an up-to 10 seconds delay.
Whenever this occurs, it mostly recovers after a few hours. It definitely recovers after a restart of OH2 services. (not confirmed yet: it seems that even a restart of the KNX binding via Karaf console recovers).

Technical details:
During the period of non-working KNX communication, I see the following log-entry approximately 5 times per minute in the log:

17:25:29.144 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 185, expected 243
17:25:29.144 [INFO ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: skip tunneling request with rcv-seq 185 (already received)

If I want to switch KNX hardware from UI in that period, I get the following in the log and the telegram is received on the KNX bus with a considerable delay:

17:25:31.128 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Value ‘ON’ could not be sent to the KNX bus using datapoint ‘command DP 1/1/11 SW_VH_DSchiene, DPT main 0 id 1.001, low priority’ - giving up after second try: no confirmation reply received for L-Data.req from 0.0.167 to 1/1/11, low priority hop count 6 repeat tpdu 00 81
17:25:31.128 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: response timeout waiting for confirmation
tuwien.auto.calimero.exception.KNXTimeoutException: no confirmation reply received for L-Data.req from 0.0.167 to 1/1/11, low priority hop count 6 repeat tpdu 00 81
at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:236)[180:org.openhab.binding.knx:1.10.0]
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:269)[180:org.openhab.binding.knx:1.10.0]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:149)[180:org.openhab.binding.knx:1.10.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:263)[180:org.openhab.binding.knx:1.10.0]
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:304)[180:org.openhab.binding.knx:1.10.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:240)[180:org.openhab.binding.knx:1.10.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:466)[180:org.openhab.binding.knx:1.10.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438)[180:org.openhab.binding.knx:1.10.0]
at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:158)[180:org.openhab.binding.knx:1.10.0]
at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveUpdate(KNXBinding.java:126)[180:org.openhab.binding.knx:1.10.0]
at org.openhab.core.binding.AbstractBinding.receiveUpdate(AbstractBinding.java:119)[181:org.openhab.core.compat1x:2.1.0]
at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:39)[181:org.openhab.core.compat1x:2.1.0]
at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415)[6:org.apache.karaf.services.eventadmin:4.0.8]
at org.apache.felix.eventadmin.impl.tasks.HandlerTask.run(HandlerTask.java:90)[6:org.apache.karaf.services.eventadmin:4.0.8]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_144]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_144]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_144]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_144]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_144]

Remarks:
The following was set in knx.config else than default (I’ll keep this short for the moment):
Type=TUNNELING, busaddr=1.1.65, ignorelocalevents=true, IP=192.168.0.46 and localIP=192.168.0.50
KNX IP interface is a Siemens n148/22

Something off-topic:
I feel sorry that I have to finally express some displeasure about OH2 in conjunction with KNX, but in fact I’m a little bit disappointed that everything looks that great on the official OH2 homepage but isn’t really working in real environments.
This does not necessarily refer to the above mentioned issue (it might be a fault at my end), but what I have anyway learned in the meantime is, that the KNX binding is still not working as supposed. I’m referring to basic things like non-working, additional listening addresses for items, or this annoying “KNX read (or even just a post-update) results in KNX telegram”.
I’m not so much disappointed about things not working, but I’m indeed disappointed that one have to learn about after setting up everything and during troubleshooting. At least some warnings on the official webpage – that would have saved me a lot of time and anger, or would have possibly influenced my decision which solution to go for. KNX is a must for (my) home automation without any doubt!
I noticed that some OH2-KNX2 bindings are in process, but this is long overdue in my point of view.

If someone could help me to resolve the above mentioned issue of sporadic dysfunction – I would be grateful.

On the one hand, I want to integrate much more things in my OH setup (Denon AVR, Astro, Siemens Logo, …) but as long as KNX is not working stable and reliable, I’m not willing to spend additional efforts.
(I’m volunteer at the local fire brigade; One fire alert at night where I would have to find shoes and key without light in the corridor- and I will immediately throw out OH2 and change back my hardware to KNX power supplies… :wink: )

Thanks in advance!
Stefan

2

Please post your setup so we can determine the possible problems!
The problems posted by you refer to a configuration in the KNX device (with regards to the flags for the communication object)!
I must disagree with many of your quotes/statements with regards to openHAB and KNX!
The KNX 2.x binding is not ready yet, that is true, but the 1.x is working flawlessly, and for this I can vouch indefinitely!
So, please be specific!

1 Like
3

Thanks for your reply, George

this is my knx.cfg file:

# KNX gateway IP address 
# (optional, if serialPort or connection type 'ROUTER' is specified)
ip=192.168.0.46

# Local KNX Binding bus address.
# Use it, when two or more openHAB Instances are connected to the same KNX bus.
# (optional, defaults to 0.0.0)
busaddr=0.0.167

# Ignore local KNX Events, prevents internal events coming from
# 'openHAB event bus' a second time to be sent back to the 'openHAB event bus'.
# Note: To send back events second time is a Bug, but for backward compatibility, the behavior is not changed.
# For new installations, its recommend to set "ignorelocalevents=true"
# (optional, defaults to false)
ignorelocalevents=true

# KNX IP connection type. Could be either TUNNEL or ROUTER (optional, defaults to TUNNEL)
# Note: If you cannot get the ROUTER mode working (even if it claims it is connected), 
# use TUNNEL mode instead with setting both the ip of the KNX gateway and the localIp.
type=TUNNEL

# KNX gateway port (optional, defaults to 3671)
# Note: If you use eibd, setting to 6720
port=3671

# Local endpoint to specify the multicast interface, no port is used (optional)
localIp=192.168.0.63

# Serial port of FT1.2 KNX interface (ignored, if ip is specified)
# Valid values are e.g. COM1 for Windows and /dev/ttyS0 or /dev/ttyUSB0 for Linux
#serialPort=

# Pause in milliseconds between two read requests on the KNX bus during
# initialization (optional, defaults to 50)
#pause=

# Timeout in milliseconds to wait for a response from the KNX bus (optional, 
# defaults to 10000)
#timeout

# Number of read retries while initialization items from the KNX bus (optional,
# defaults to 3)
#readRetries

# Seconds between connect retries when KNX link has been lost
# 0 means never retry, it will only reconnect on next write or read request
# Note: without periodic retries all events will be lost up to the next read/write
#       request
# (optional, default is 0)
autoReconnectPeriod=30

### Auto refresh feature
# Number of entries permissible in the item refresher queue. 
# (optional, defaults to 10000)
#maxRefreshQueueEntries=

# Number of parallel threads for refreshing items. (optional, defaults to 5)
numberOfThreads=1

# Seconds to wait for an orderly shutdown of the auto refresher's 
# ScheduledExecutorService. (optional, defaults to 5)
#scheduledExecutorServiceShutdownTimeoutString=

# Use NAT (Network Address Translation)
#  (optional; defaults to false)
#useNAT=true

my default.items:

Group gDimlightCorridor_DG

Switch SW_OUT_FluterN		"Aussenfluter Nord"		<light> 	{ knx="1/1/83" }
Switch SW_OUT_FluterS		"Aussenfluter Süd"		<light> 	{ knx="1/1/84" }
Switch SW_OUT_LBalkon		"Licht Balkon 2OG"		<light> 	{ knx="1/1/81" }
Switch SW_OUT_SteckdBalk 	"Steckdosen Balkon" 	<switch> 	{ knx="1/1/82" }

Switch SW_VH_Downlights		"Downlight Vorhaus"		<light> 	{ knx="1/1/10" }
Switch SW_VH_DSchiene		"Deckenschiene Vorhaus"	<light>		{ knx="1/1/11" }

Switch SW_TR_Downlight 		"Downlight Treppe"		<light> 	{ knx="1/1/12" }
Switch SW_TR_Orientierung 	"Orientierung Treppe" 	<light> 	{ knx="1/1/13" }

Dimmer VH_DL_1 "Downlight Vorhaus 1" (gDimlightCorridor_DG) { channel="dmx:dimmer:mybridge:CH27:brightness" }
Dimmer VH_DL_2 "Downlight Vorhaus 2" (gDimlightCorridor_DG) { channel="dmx:dimmer:mybridge:CH28:brightness" }
Dimmer VH_DL_3 "Downlight Vorhaus 3" (gDimlightCorridor_DG) { channel="dmx:dimmer:mybridge:CH29:brightness" }
Dimmer VH_DL_4 "Downlight Vorhaus 4" (gDimlightCorridor_DG) { channel="dmx:dimmer:mybridge:CH30:brightness" }
Dimmer D_LED_WC "LED Leiste WC" { channel="dmx:dimmer:mybridge:CH24:brightness" }

Remark:
I’m using a DMX 2.x Binding “from Github”, (https://github.com/eclipse/smarthome/pull/2704, not the final version, but from a JAR file provided beginning of the year) which has been working without any issue since installation in March.

and finally the KNX-DMX.rules file to follow changes on the knx-related item on the dimmer-items:

rule "DMX_Vorhaus"
when
	Item SW_VH_Downlights received command
then
	sendCommand(gDimlightCorridor_DG, receivedCommand)
end

Don’t get me wrong, I absolutely honor efforts spent by people in their free time, for bringing to life the great OH System. Sorry again for my unspecific complaints and I fully agree with you that it should be indeed possible to having KNX 1.x working flawless on a OH2.x system.
I just wanted to express that I had to learn about certain KNX-Binding-characteristics that are probably not intended in way they are. Anyway this is something that can be handeled once being aware about, thus it is no longer an issue for me.

The connection-problems however are a big issue and I’m grateful for any advice.
Thank you so much!

4

It looks like you have a main line device (backbone) with address 0.0.167 that does not get an ACK from the device listening for GA 1/1/11.

Here you declared openHAB KNX address 1.1.65. What is your KNX/IP router’s PA in KNX?
Can you post your KNX topology?

5

George
I just noticed a mistake, I’m sorry. the “busaddr=x.x.x” was set to 0.0.167 at the time when I took the posted extract from the log, however I changed back and forth the busaddr later on.
No matter which value I’m using, everything works fine for quite a while but after a certain period these two lines re-appear every ~10-20 seconds in the log

17:25:29.144 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq xxx, expected yyy
17:25:29.144 [INFO ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.46:3671: skip tunneling request with rcv-seq xxx (already received)

Actually the Siemens n148/22 gateway (no router!) is the suspect now as it seems to use different/unknown/random PAs at least for tunneling connections 2, 3, 4.
I don’t see a way to set the PA on that device else than by the integrated “auto-assign-function”. I was not able to determine which one (PA and connection No) it is using when I connect OH2 to the bus (how can I find out best way?)
If I connect the ETS3 bus (group) monitor at the same time, the “source address” of telegrams sent by OH, is always the value set in the KNX.config

On the other hand, I see no chance to assure that OH2 would be assigned to tunneling connection 1 definitely.

To make it short:
Can you recommend any KNX/IP Gateway (a Router is not required for OH, as I understand), which comes along with better suited setting options?

My KNX system consists of just one line with a power supply, the mentioned KNX/IP gateway, 4 aktors and 7 wall buttons and 2 motion sensors (mainly MDT). No line coupler, no RF nor any other special.

Thank you!!

6

Anyone who can recommend a KNX/IP Interface device (brand/type) that is working well with OH2? :fearful:

7

I would go for a router (if the budget allows it) from MDT - SCN-IP100.02, or a gateway SCN-IP000.02. I like these because they do not require a suplementary power supply!

8

George, thanks for your advise.
“if the budget allows” - basically yes, but I’d like to understand why this would be the better choice, if OH2 is supposed to be working with “cheaper” gateway just as well.

However, I have an update now.
I had some time left yesterday, and I decided to give it a last try before I additionaly spend €250++ for my home automation…
Thus I re-installed the latest Ubuntu 16.04.03 LTS, and the most recent OH2 snapshot version (apt-get). This snapshot comes with DMX Binding 2.x rather than DMX 1.x as the official release, and it comes with KNX 1.11 instead of KNX 1.10.
And for some reason, everything seems to be working well now. Probably it is too soon to say that, but it looks like something has changed indeed.
I still have the same warnings in the log, but something is different now. Even though the warnings appear, OH2 is working well from functional view.
BTW: could it be, that also the “KNX read results in bus telegram”-issue has been resolved with the 1.11 binding? :smiley:

I’ll observe it for a while and close the thread if applicable.

9

AFAIK, your problem has nothing to do with it!

When using a router, you can connect OH2 via router mode (with routing/filtering for telegrams) and connect ETS via tunneling mode in the same time! The router mode connection offers a not so intrusive method of connection (the devices can not be programmed via a router mode connection).

10

Update: KNX-Binding is still running well and stable with the latest snapshot-versions. I’m looking forward to the official releas of OH2.2 :grinning:

1 Like
11

Hi Stefan, George,

I have exactly the same issue and would appreciate your help in finding a solution. :slight_smile:

I am using a Siemens IP interface N148/22 (no router).
At first everything works fine, but after a while there is a sync issue. The cause is not really known.
I also updated manually my KNX binding from 1.10 to the latest version of the KNX binding (version 1.11.0.201708271339) but seemly the issue remains.

Here is a typical extract:

2017-11-26 18:04:56.462 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling xxx.yyy.zzz.www:3671: tunneling request with invalid rcv-seq 42, expected 45
2017-11-26 18:04:57.462 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling xxx.yyy.zzz.www:3671: tunneling request with invalid rcv-seq 42, expected 45
2017-11-26 18:04:58.462 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling xxx.yyy.zzz.www:3671: tunneling request with invalid rcv-seq 43, expected 45
2017-11-26 18:04:59.462 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling xxx.yyy.zzz.www:3671: tunneling request with invalid rcv-seq 43, expected 45

Strange that if the value corresponds (after 256 events), the sync is again established, but only for a while. :frowning_face:

Is there a newer version of the binding available I could use?
Any suggestions?

Thanks !
Filip

12

Hi Filip

I’m somehow glad that I’m not the only one with that issue, even though this is no help for either of us - sorry.

From my side, I can only tell that everything has worked well and stable, after I completely re-installed Ubuntu Server + OH2 snapshot release via apt-get, end of September.
I’m doing updates from time to time, but have never experienced this kind of dysfunction anymore. (Actually KNX has turned to the most stable binding in my environment.)
I’m not sure if this is related more to the re-installation, or snapshot- “upgrade”, but I think it is the second…

By the way, I should mention that I’m only using the “most basic” KNX function -> Switches, with only one GA assigned to (~40 of them).
Due to all the issues experienced before, I could not yet evolve trust to letting OH2 control blinds or roof window.

regards,
Stefan

13

Hi Stefan,

Thanks for your reply and your advise!

FYI: I am using OpenRemote for many years now (using the same infrastructure - Synology/PI) and I was interested to pass to OpenHab especially with the number of additional bindings and extended possibilities.
I installed about one year ago a version OH 1.8 on a PI but was a bit dissapointed about the stability (status of items) and the manual actions needed to get it running with KNX.
With OH2, I was surprissed to see the facility to install it and getting it running! I took very care with the configuration and the advise as mentioned on the openhab site and this forum.
Hower, still one blocking to go live - the sync issue… :frowning:

I also found an improvement patch for KNXD and hope the installation of this will improve the lower-levels behavior.

Regards,
Filip

14

Just a quick update:
OH2 is running 24/7 and has been running without any issue since my last post back in November, until end of 2017. However now I’m faced with the “invalid rcv-seq…” issue again (second time this year). I did really not do anything. No update, no changes, … just nothing! Really anoying.

Just a short excerpt from my log (sudden occurrence. Nobody has been at home that time, therefore actually no activity I could see relations to):

2018-01-06 00:11:55.360 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 131, expected 32
2018-01-06 00:11:56.360 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 132, expected 32
2018-01-06 00:11:57.360 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 132, expected 32
2018-01-06 00:11:58.360 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 133, expected 32
2018-01-06 00:11:59.360 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 133, expected 32
2018-01-06 00:12:00.360 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 134, expected 32
2018-01-06 00:12:01.360 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 134, expected 32
2018-01-06 00:12:02.360 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 135, expected 32
2018-01-06 00:12:03.360 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 135, expected 32
2018-01-06 00:12:04.360 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 136, expected 32
2018-01-06 00:12:05.360 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 136, expected 32
2018-01-06 00:12:06.359 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 137, expected 32
2018-01-06 00:12:07.359 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 137, expected 32
2018-01-06 00:12:08.359 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 138, expected 32
2018-01-06 00:12:09.359 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 138, expected 32
2018-01-06 00:12:10.359 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 139, expected 32
2018-01-06 00:12:11.359 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 139, expected 32
2018-01-06 00:12:12.359 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 140, expected 32
2018-01-06 00:12:13.359 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 140, expected 32
2018-01-06 00:12:14.359 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 141, expected 32
2018-01-06 00:12:15.359 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 141, expected 32
2018-01-06 00:15:07.040 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 142, expected 32
2018-01-06 00:15:08.040 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 142, expected 32
2018-01-06 00:15:09.040 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 143, expected 32
2018-01-06 00:15:10.040 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 143, expected 32
2018-01-06 00:17:21.168 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 144, expected 32
2018-01-06 00:17:22.167 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 144, expected 32
2018-01-06 00:17:23.167 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 145, expected 32
2018-01-06 00:17:24.167 [WARN ] [tuwien.auto.calimero                ] - KNXnet/IP Tunneling 192.168.0.46:3671: tunneling request with invalid rcv-seq 145, expected 32

Any advice… probably else than buying a “better/different” KNX router/interface just for testing, I would be much appreciating!!!

15

Sorry for a late reaction, but I don’t visit this site regularly.
I have had the same problem with missing rvc’s. I do not know the cause, but I also think it is the IP router (in my case a Hager TH 210).
Thanks to Boris Malinkowsky, developer of Calimero, I have a got workaround.
Calimero is a library inside the KNX-binding fort OpenHAB.
Calimero has an option to ignore missing rvc’s. The option is available since v2.3 of Calimero.
To use the option you have to set it in the EXTRA_JAVA_OPTS:
EXTRA_JAVA_OPTS="-Dcalimero.knxnetip.tunneling.resyncSkippedRcvSeq"
The line is the only line inside the file: /etc/default/openhab2

Sadly at the moment the knx-binding (vs. 1.9.0) is using Calimero version 2.3-beta.
So I renamed a download of calimero-core-2.3.jar to Calimero-core-2.3-beta.jar and replaced this version inside the knx-binding.
It worked; I see warnings when a rvc number is missing but the openhab2 keeps running.

Regards,
Anton

16

Hi Anton

thank you very much for your detailed explanation of your workaround. Glad to hearing that you found a solution.

I had the hope that this issue could be finally fixed for me as well now.
To be honest - my latest “unstable release version” has been running without too many issues the last weeks, but I anyway decided to spend another 4 hours for a complete re-install of Ubuntu+OH2, and to giving it another “last try”.

Well. I’m now at a point between hating myself - and hating the whole electronics/smart-home world.
After rebooting, everything works well for a few minutes (+/- 15), before the log is flooded with “tunneling request with invalid …” :rage:
Another sunny sunday afternoon for nothing.
It’s getting dark outside, no main light in my flat. Guess what my family is telling me (again) :fist_right:

I’m not against trying around, and playing with this stuff. Realy not! But I need a solution now before going crazy. So again: any recommendation, please???

17

PS: I ordered a router now (MDT, SCN-IP100.02.) €250 just to giving it a try … :sob:

18

Hi Stefan,

I hope things go better now.
The flooding of errors is caused by one missing rcv.
It took me a long time before I even found that out. I am not a specialist in hardware or software. I learned to use the Wireshark tool to see the network traffic (there is even a Protocol code voor KNXnetIP).

As I said the knx-binding in openHAB is still using Calimero version 2.3-beta. You need Calimero 2.3. If it helps I can send you my modified version of the knx-binding. But I think I need a mailadres to send it to.

Greetings
Anton

19

I guess I’m too stupid for OH. Installed the router now, and retried in TUNNELING mode. Well, the fault message is different but the outcome is the same. OH2 not receiving any command from KNX except the first 10 minutes, + log flooded with warnings and errors:

2018-02-19 21:44:23.946 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: connection state response status: server could not find active data connection with specified ID
2018-02-19 21:44:33.946 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: connection state response status: server could not find active data connection with specified ID
2018-02-19 21:44:43.946 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: connection state response status: server could not find active data connection with specified ID
2018-02-19 21:44:53.946 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: received disconnect response status 0x21 (no active data connection with that ID)
2018-02-19 21:44:53.948 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: close connection - no heartbeat response
2018-02-19 21:44:53.948 [WARN ] [nx.internal.connection.KNXConnection] - KNX link has been lost (reason: no heartbeat response on object tunneling link link (closed) 192.168.0.22:3671 TP1 medium, device 1.1.65, hopcount 6)
2018-02-19 21:44:53.949 [INFO ] [nx.internal.connection.KNXConnection] - KNX link will be retried in 30 seconds
2018-02-19 21:44:53.952 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Received detach Event.
2018-02-19 21:45:23.950 [INFO ] [nx.internal.connection.KNXConnection] - Trying to (re-)connect to KNX…
2018-02-19 21:45:23.956 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 192.168.0.22:3671 in mode TUNNEL.
2018-02-19 21:45:23.956 [INFO ] [nx.internal.connection.KNXConnection] - Connected to KNX
2018-02-19 21:45:27.025 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Value ‘24.3’ could not be sent to the KNX bus using datapoint ‘command DP 1/5/50 ‘N_WZ_Temperatur’, DPT main 0 id 9.001, low priority’ - retrying one time: no confirmation reply received for L-Data.req from 1.1.65 to 1/5/50, low priority hop count 6 repeat tpdu 00 80 0c bf
2018-02-19 21:45:27.025 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: response timeout waiting for confirmation
tuwien.auto.calimero.exception.KNXTimeoutException: no confirmation reply received for L-Data.req from 1.1.65 to 1/5/50, low priority hop count 6 repeat tpdu 00 80 0c bf
at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:239) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:269) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:149) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:263) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:304) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:240) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:466) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:149) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveUpdate(KNXBinding.java:126) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.core.binding.AbstractBinding.receiveUpdate(AbstractBinding.java:113) [215:org.openhab.core.compat1x:2.2.0]
at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:39) [215:org.openhab.core.compat1x:2.2.0]
at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415) [3:org.apache.karaf.services.eventadmin:4.1.3]
at org.apache.felix.eventadmin.impl.tasks.HandlerTask.runWithoutBlacklistTiming(HandlerTask.java:82) [3:org.apache.karaf.services.eventadmin:4.1.3]
at org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:104) [3:org.apache.karaf.services.eventadmin:4.1.3]
at org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks$TaskExecuter.run(AsyncDeliverTasks.java:166) [3:org.apache.karaf.services.eventadmin:4.1.3]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2018-02-19 21:45:39.026 [ERROR] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: close connection - maximum send attempts
tuwien.auto.calimero.exception.KNXAckTimeoutException: maximum send attempts, no service acknowledgment received
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:261) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:149) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:263) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:304) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:240) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.readFromGroup(ProcessCommunicatorImpl.java:486) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.read(ProcessCommunicatorImpl.java:422) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.binding.knx.internal.bus.KNXBindingDatapointReaderTask.readFromKNXBus(KNXBindingDatapointReaderTask.java:99) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.binding.knx.internal.bus.KNXBindingDatapointReaderTask.run(KNXBindingDatapointReaderTask.java:67) [214:org.openhab.binding.knx:1.11.0]
2018-02-19 21:45:39.032 [WARN ] [nx.internal.connection.KNXConnection] - KNX link has been lost (reason: maximum send attempts on object tunneling link link (closed) 192.168.0.22:3671 TP1 medium, device 1.1.65, hopcount 6)
2018-02-19 21:45:39.032 [INFO ] [nx.internal.connection.KNXConnection] - KNX link will be retried in 30 seconds
2018-02-19 21:45:39.037 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Received detach Event.
2018-02-19 21:45:39.038 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Cannot read value for item ‘N_BU_Temperatur’ from KNX bus: maximum send attempts, no service acknowledgment received: timeout
2018-02-19 21:45:39.039 [WARN ] [al.bus.KNXBindingDatapointReaderTask] - Autorefresh: Remaining retries for address ‘1/6/50’ = ‘2’
2018-02-19 21:45:39.039 [WARN ] [tuwien.auto.calimero ] - KNXnet/IP Tunneling 192.168.0.22:3671: send invoked on closed connection - aborted
2018-02-19 21:45:39.039 [ERROR] [tuwien.auto.calimero ] - calimero.link.192.168.0.22:3671: send error, closing link
tuwien.auto.calimero.knxnetip.KNXConnectionClosedException: connection closed
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:226) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:149) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:263) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:304) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:240) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:466) [214:org.openhab.binding.knx:1.11.0]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:438) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.binding.knx.internal.bus.KNXBinding.writeToKNX(KNXBinding.java:158) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.binding.knx.internal.bus.KNXBinding.internalReceiveUpdate(KNXBinding.java:126) [214:org.openhab.binding.knx:1.11.0]
at org.openhab.core.binding.AbstractBinding.receiveUpdate(AbstractBinding.java:113) [215:org.openhab.core.compat1x:2.2.0]
at org.openhab.core.events.AbstractEventSubscriber.handleEvent(AbstractEventSubscriber.java:39) [215:org.openhab.core.compat1x:2.2.0]
at org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:415) [3:org.apache.karaf.services.eventadmin:4.1.3]
at org.apache.felix.eventadmin.impl.tasks.HandlerTask.runWithoutBlacklistTiming(HandlerTask.java:82) [3:org.apache.karaf.services.eventadmin:4.1.3]
at org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:104) [3:org.apache.karaf.services.eventadmin:4.1.3]
at org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks$TaskExecuter.run(AsyncDeliverTasks.java:166) [3:org.apache.karaf.services.eventadmin:4.1.3]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2018-02-19 21:45:39.041 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Value ‘24.3’ could not be sent to the KNX bus using datapoint ‘command DP 1/5/50 ‘N_WZ_Temperatur’, DPT main 0 id 9.001, low priority’ - giving up after second try: link closed, connection closed

does anyone have a working KNX connection in tunneling mode? (except Anton)

20

just noticed another strange thing:

grafik
grafik.png1382×607 26.7 KB

two connections from OH2??