Could not find enum for class 'li.pitschmann.knx.core.cemi.APCI' and code: 960

[StefanOltmann]

Hi Christoph,

I got that exception again using knx-core 0.3.0:

13:29:46 [li.pitschmann.knx.core.communication.queue.DefaultInboxQueue] (pool-287-thread-1) Error while processing KNX packets.: li.pitschmann.knx.core.exceptions.KnxEnumNotFoundException: Could not find enum for class 'li.pitschmann.knx.core.cemi.APCI' and code: 960
    at li.pitschmann.knx.core.cemi.APCI.lambda$valueOf$1(APCI.java:113)
    at java.base/java.util.Optional.orElseThrow(Optional.java:408)
    at li.pitschmann.knx.core.cemi.APCI.valueOf(APCI.java:113)
    at li.pitschmann.knx.core.cemi.CEMI.<init>(CEMI.java:162)

But this time I also got the requested knx-audit.log. I hope this helps to track the problem.

Here is the full stacktrace.

Kind regards,

Stefan

[pitschr]

Hi Stefan.

Thanks for reporting one.

I have checked the KNX Specification what 960 stands for. According to the 3.3.7 Application Layer paper the 960 represents in byte format 1111 000000 (4 APCI, 6 APCI/Data) which stands for: A_Open_Routing_Table_Req-PDU and relates to the Coupler specific service. So it is not a part of expected KNX/Net IP traffic we want to get and listen to.

Given point, I would say that the error or exception is correct and works as expected:

13:29:46 [li.pitschmann.knx.core.communication.queue.DefaultInboxQueue] (pool-287-thread-1) Error while processing KNX packets.: li.pitschmann.knx.core.exceptions.KnxEnumNotFoundException: Could not find enum for class 'li.pitschmann.knx.core.cemi.APCI' and code: 960
    at li.pitschmann.knx.core.cemi.APCI.lambda$valueOf$1(APCI.java:113)
    at java.base/java.util.Optional.orElseThrow(Optional.java:408)
    at li.pitschmann.knx.core.cemi.APCI.valueOf(APCI.java:113)
    ... lines omitted ...

BUT I am more worried why the KNX client has been closed. Are you closing it by yourself? When we receive such packet I expect that: 1) the exception should be printed in the server.log -> WORKS 2) the knx-audit.log should have the error logged and I also do not see a DISCONNECT request before closing it -> NOT WORKING 3) the KNX client shall continue and ignore/drop the packet (instead of closing) -> NOT WORKING

So let's tackle for points 2 and 3.

Point 2 I see the first entry in knx-audit.log is 1615552192.429145000 (Fri Mar 12 2021 12:29:52 GMT+0000) and last one is 1615587283.979054000 (Fri Mar 12 2021 22:14:43 GMT+0000).

Did you send the correct knx-audit.log file? Or has knx-audit.log been overwritten?

Point 3 Do you have a logic mechanism closing the knx client by yourself in case you get an exception. When you get a Throwable in li.pitschmann.knx.core.plugin.ObserverPlugin#onError(Throwable) then it is not meant that you shall close the KNX client by yourself. In this case I may have to update the JavaDoc . It is designed to inform the plugin that there was an unexpected paket arrived. Althought here is a Throwable provided, the KNX client shall continue work.

Can you please confirm if you didn't closed the KNX client by yourself?

[StefanOltmann]

I have checked the KNX Specification what 960 stands for. According to the 3.3.7 Application Layer paper the 960 represents in byte format 1111 000000 (4 APCI, 6 APCI/Data) which stands for: A_Open_Routing_Table_Req-PDU and relates to the Coupler specific service. So it is not a part of expected KNX/Net IP traffic we want to get and listen to.

I'm not quite sure what that means. The thing is that this kind of traffic occurs and I would like to filter it out without Exceptions.

BUT I am more worried why the KNX client has been closed. Are you closing it by yourself? When we receive such packet I expect that:

I use the client with try-with-resources as your usage sample shows and the exception reaches that point. So the client gets closed and I need to restart it.

3. the KNX client shall continue and ignore/drop the packet (instead of closing) -> NOT WORKING

I suggest you make that an logger.warn() or something and let it not reach the try-with-resources block.

Did you send the correct knx-audit.log file? Or has knx-audit.log been overwritten?

There were a lot and I send the latest as the exception occured also in this time frame. I guessed that you may find the "invalid paket" this way.

Point 3 Do you have a logic mechanism closing the knx client by yourself in case you get an exception. When you get a Throwable in li.pitschmann.knx.core.plugin.ObserverPlugin#onError(Throwable) then it is not meant that you shall close the KNX client by yourself.

My onError(Throwable) only logs that problem:

https://github.com/StefanOltmann/smart-home-server/blob/master/src/main/kotlin/de/stefan_oltmann/smarthome/server/knx/KnxServiceImpl.kt

In this case I may have to update the JavaDoc . It is designed to inform the plugin that there was an unexpected paket arrived. Althought here is a Throwable provided, the KNX client shall continue work.

I think a KnxEnumNotFoundException really looks like as if something internal broke. Maybe you want change that into something like an 'PacketNotSupportedException' that goes into onError(Throwable). It should make a clear statement like "Yes, I recognize this package and I drop it because it's coupler specific.".

Can you please confirm if you didn't closed the KNX client by yourself?

It's closed due to the occurance of that exception.

[pitschr]

I'm not quite sure what that means. The thing is that this kind of traffic occurs and I would like to filter it out without Exceptions.

This means, the packet which was sent by your KNX Router was not suitable for the KNX Net/IP traffic. In my understanding it is a bug of your KNX IP device as such packet should not be sent at all; at least not to KNX Net/IP.

I suggest you make that an logger.warn() or something and let it not reach the try-with-resources block. This is what I am doing more&less already. That is why I am worried that it is not working as expected. I need to reproduce this issue on my machine. So it takes some time for that.

See line: https://github.com/pitschr/knx-core/blob/main/src/main/java/li/pitschmann/knx/core/communication/queue/AbstractKnxQueue.java#L93

There were a lot and I send the latest as the exception occured also in this time frame. I guessed that you may find the "invalid paket" this way.

As you restarted the KNX Client the knx-audit.log might rotated already. Can you check if you 2nd last file contains the error? If not, then it looks like that the knx-audit.log file has been ovewritten which is not intended. Here we may have hit a bug and I need to look at it then. Please let me know first if you see an entry with shutdown pattern.

I think a KnxEnumNotFoundException really looks like as if something internal broke.

Yes, I may improve this part and will provide a separate Exception class for that case. And will change it to warn log level with a better message like Error while processing KNX packet and will be ignored.

[pitschr]

I changed my code temporarily to reproduce the issue every 10th packet arrival, and I can confirm that the KNX client is ignoring the packets, and remain stable without closing itself. The knx-audit.log also logs the error.

I can confirm that the knx-audit.log will be overridden, when KNX Client is restarted with the audit plugin again. This is not intended and I am going to fix it.

Anyway I made some changes like better error handling and an own exception class for unsupported APCI code. https://github.com/pitschr/knx-core/tree/main-2021-03-13

Since I am not able to reproduce the issue what stops the KNX client, I propose you if you can start your application with a debugger: 1) start your application in debug mode 2) add a breakpoint at CEMI constructor (e.g. line nr 161) 3) add a breakpoint at InternalKnxClient#close() (e.g. line nr 262) 4) as soon it enters the breakpoint nr 1 then modify the 9th index of bytes variable to e.g. 127. Press Resume. APCI will read this bit and this will throw the APCI Code Exception which should notify the audit plugin. And when I am not wrong, then in your case the KNX client will be closed. 5) it should enter the breakpoint nr 2 then and you should see the stacktrace who invoked the InternalKnxClient#close() method.

Please provide the full stack trace for further investigation. Thanks.

[pitschr]

Hallo.

Issue with Audit & Statistic Rollover has now been fixed. After start the log file should be appended rather overwritten. Furthermore, I also added "Date & Time" (ISO 8601 format) for better traceability. This, however, won't solve the issue you are facing with "KNX client closed" issue. Therefore, I do not published it to maven yet.

Let me know if you were able to reproduce the issue with your application.

[StefanOltmann]

Hi Christoph.

I'm quite busy right now, but I will as soon as possible follow your steps to track that problem.

Kind regards,

Stefan

[StefanOltmann]

In investigated further and noticed that the logger.error() in my catch is never printed. So there is indeed no exception escaping the try-with-resources. I was wrong here.

It's restarting because after the exception occurs client.isRunning returns false here:

knxClient.use { client ->
    while (client.isRunning)
        Sleeper.seconds(1)
}

That's why it's restarting.

Connected to the target VM, address: '127.0.0.1:50374', transport: 'socket'
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2021-03-19 18:59:23,760 INFO  [io.qua.arc.pro.BeanProcessor] (build-36) Found unrecommended usage of private members (use package-private instead) in application beans:
    - Bean constructor void <init>() on de.stefan_oltmann.smarthome.server.Main
2021-03-19 18:59:24,761 INFO  [io.quarkus] (Quarkus Main Thread) Quarkus 1.12.2.Final on JVM started in 1.741s. Listening on: https://localhost:50000
2021-03-19 18:59:24,762 INFO  [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated.
2021-03-19 18:59:24,762 INFO  [io.quarkus] (Quarkus Main Thread) Installed features: [cdi, kotlin, resteasy, resteasy-jackson]
2021-03-19 18:59:24,762 INFO  [de.ste.sma.ser.Main] (Quarkus Main Thread) Quarkus is starting...
Started with 31 devices.
2021-03-19 18:59:51,539 INFO  [de.ste.sma.ser.Main] (executor-thread-1) Staring KNX service...
2021-03-19 18:59:51,566 INFO  [de.ste.sma.ser.knx.KnxServiceImpl$GroupMonitorPlugin] (pool-5-thread-2) Initialized by client: li.pitschmann.knx.core.communication.DefaultKnxClient@ef6be2
2021-03-19 18:59:51,566 INFO  [li.pit.knx.cor.plu.PluginManager] (ForkJoinPool.commonPool-worker-15) Plugin initialized and added in 2 ms: de.stefan_oltmann.smarthome.server.knx.KnxServiceImpl$GroupMonitorPlugin@2bd0230a
2021-03-19 18:59:51,566 INFO  [li.pit.knx.cor.plu.aud.FileAuditPlugin] (pool-5-thread-1) Initialized 'li.pitschmann.knx.core.plugin.audit.FileAuditPlugin' with: [path=knx-audit.log, format=JSON]
2021-03-19 18:59:51,572 INFO  [li.pit.knx.cor.plu.PluginManager] (executor-thread-1) Plugin initialized and added in 8 ms: li.pitschmann.knx.core.plugin.audit.FileAuditPlugin@7b62262a
2021-03-19 18:59:51,572 INFO  [li.pit.knx.cor.plu.PluginManager] (executor-thread-1) All Plugins: [de.stefan_oltmann.smarthome.server.knx.KnxServiceImpl$GroupMonitorPlugin@2bd0230a, li.pitschmann.knx.core.plugin.audit.FileAuditPlugin@7b62262a]
2021-03-19 18:59:51,573 INFO  [li.pit.knx.cor.plu.PluginManager] (executor-thread-1) Observer Plugins: [de.stefan_oltmann.smarthome.server.knx.KnxServiceImpl$GroupMonitorPlugin@2bd0230a, li.pitschmann.knx.core.plugin.audit.FileAuditPlugin@7b62262a]
2021-03-19 18:59:51,573 INFO  [li.pit.knx.cor.plu.PluginManager] (executor-thread-1) Extension Plugins: [li.pitschmann.knx.core.plugin.audit.FileAuditPlugin@7b62262a]
2021-03-19 18:59:51,646 INFO  [li.pit.knx.cor.com.InternalKnxClient] (executor-thread-1) Remote Endpoint (KNX Net/IP)     : 192.168.0.2:3671
2021-03-19 18:59:51,646 INFO  [li.pit.knx.cor.com.InternalKnxClient] (executor-thread-1) Local Endpoint  (Control Channel): 192.168.0.21:61358
2021-03-19 18:59:51,646 INFO  [li.pit.knx.cor.com.InternalKnxClient] (executor-thread-1) Local Endpoint  (Data Channel)   : 192.168.0.21:61359
2021-03-19 18:59:51,646 INFO  [li.pit.knx.cor.com.InternalKnxClient] (executor-thread-1) Routing Enabled                  : false
2021-03-19 18:59:51,646 INFO  [li.pit.knx.cor.com.InternalKnxClient] (executor-thread-1) NAT Enabled                      : false
2021-03-19 18:59:51,675 INFO  [li.pit.knx.cor.com.InternalKnxClient] (executor-thread-1) Channel ID (Tunneling)           : 3
2021-03-19 18:59:52,556 INFO  [de.ste.sma.ser.Main] (executor-thread-1) KNX service started.
2021-03-19 19:01:02,866 ERROR [li.pit.knx.cor.com.que.DefaultInboxQueue] (pool-14-thread-1) Error while processing KNX packets.: li.pitschmann.knx.core.exceptions.KnxEnumNotFoundException: Could not find enum for class 'li.pitschmann.knx.core.cemi.APCI' and code: 896
    at li.pitschmann.knx.core.cemi.APCI.lambda$valueOf$1(APCI.java:113)
    at java.base/java.util.Optional.orElseThrow(Optional.java:401)
    at li.pitschmann.knx.core.cemi.APCI.valueOf(APCI.java:113)
    at li.pitschmann.knx.core.cemi.CEMI.<init>(CEMI.java:162)
    at li.pitschmann.knx.core.cemi.CEMI.of(CEMI.java:272)
    at li.pitschmann.knx.core.body.TunnelingRequestBody.<init>(TunnelingRequestBody.java:90)
    at li.pitschmann.knx.core.body.TunnelingRequestBody.of(TunnelingRequestBody.java:118)
    at li.pitschmann.knx.core.body.BodyFactory.of(BodyFactory.java:93)
    at li.pitschmann.knx.core.body.BodyFactory.of(BodyFactory.java:72)
    at li.pitschmann.knx.core.body.BodyFactory.of(BodyFactory.java:57)
    at li.pitschmann.knx.core.communication.queue.AbstractInboxQueue.action(AbstractInboxQueue.java:90)
    at li.pitschmann.knx.core.communication.queue.AbstractKnxQueue.run(AbstractKnxQueue.java:79)
    at li.pitschmann.knx.core.utils.Executors$MdcRunnable.run(Executors.java:136)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
    at li.pitschmann.knx.core.utils.Executors$MdcRunnable.run(Executors.java:136)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
    at java.base/java.lang.Thread.run(Thread.java:832)

2021-03-19 19:01:02,868 ERROR [de.ste.sma.ser.knx.KnxServiceImpl$GroupMonitorPlugin] (pool-5-thread-10) KNX client error.: java.lang.Throwable: Error while processing KNX packets.
    at li.pitschmann.knx.core.communication.queue.AbstractKnxQueue.run(AbstractKnxQueue.java:95)
    at li.pitschmann.knx.core.utils.Executors$MdcRunnable.run(Executors.java:136)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
    at li.pitschmann.knx.core.utils.Executors$MdcRunnable.run(Executors.java:136)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
    at java.base/java.lang.Thread.run(Thread.java:832)
Caused by: li.pitschmann.knx.core.exceptions.KnxEnumNotFoundException: Could not find enum for class 'li.pitschmann.knx.core.cemi.APCI' and code: 896
    at li.pitschmann.knx.core.cemi.APCI.lambda$valueOf$1(APCI.java:113)
    at java.base/java.util.Optional.orElseThrow(Optional.java:401)
    at li.pitschmann.knx.core.cemi.APCI.valueOf(APCI.java:113)
    at li.pitschmann.knx.core.cemi.CEMI.<init>(CEMI.java:162)
    at li.pitschmann.knx.core.cemi.CEMI.of(CEMI.java:272)
    at li.pitschmann.knx.core.body.TunnelingRequestBody.<init>(TunnelingRequestBody.java:90)
    at li.pitschmann.knx.core.body.TunnelingRequestBody.of(TunnelingRequestBody.java:118)
    at li.pitschmann.knx.core.body.BodyFactory.of(BodyFactory.java:93)
    at li.pitschmann.knx.core.body.BodyFactory.of(BodyFactory.java:72)
    at li.pitschmann.knx.core.body.BodyFactory.of(BodyFactory.java:57)
    at li.pitschmann.knx.core.communication.queue.AbstractInboxQueue.action(AbstractInboxQueue.java:90)
    at li.pitschmann.knx.core.communication.queue.AbstractKnxQueue.run(AbstractKnxQueue.java:79)
    ... 8 more

2021-03-19 19:01:14,153 WARN  [li.pit.knx.cor.com.com.ConnectionStateCommunicator] (pool-16-thread-3) Connection State Request to be sent again, last heartbeat was received at 2021-03-19T17:59:51.676768400Z: 82476 ms.
2021-03-19 19:01:14,153 INFO  [li.pit.knx.cor.com.InternalKnxClient] (ForkJoinPool.commonPool-worker-7) Client will be stopped.
2021-03-19 19:01:14,154 WARN  [li.pit.knx.cor.com.InternalKnxClient] (pool-12-thread-1) Wrong Channel ID received for body: ConnectionStateResponseBody{channelId=3, status=Status{name=CONNECTION_ID, friendlyName=No active connection with specified id, code=33}}
2021-03-19 19:01:14,154 WARN  [li.pit.knx.cor.com.que.DefaultInboxQueue] (pool-12-thread-1) KNX packet with wrong channel retrieved: Wrong channel id '3' received, expected channel id is '-1': ConnectionStateResponseBody{channelId=3, status=Status{name=CONNECTION_ID, friendlyName=No active connection with specified id, code=33}}
2021-03-19 19:01:14,155 ERROR [de.ste.sma.ser.knx.KnxServiceImpl$GroupMonitorPlugin] (pool-5-thread-1) KNX client error.: li.pitschmann.knx.core.exceptions.KnxWrongChannelIdException: Wrong channel id '3' received, expected channel id is '-1': ConnectionStateResponseBody{channelId=3, status=Status{name=CONNECTION_ID, friendlyName=No active connection with specified id, code=33}}
    at li.pitschmann.knx.core.communication.InternalKnxClient.verifyChannelId(InternalKnxClient.java:469)
    at li.pitschmann.knx.core.communication.queue.AbstractInboxQueue.action(AbstractInboxQueue.java:93)
    at li.pitschmann.knx.core.communication.queue.AbstractKnxQueue.run(AbstractKnxQueue.java:79)
    at li.pitschmann.knx.core.utils.Executors$MdcRunnable.run(Executors.java:136)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
    at li.pitschmann.knx.core.utils.Executors$MdcRunnable.run(Executors.java:136)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
    at java.base/java.lang.Thread.run(Thread.java:832)

2021-03-19 19:01:14,270 INFO  [li.pit.knx.cor.com.InternalKnxClient] (ForkJoinPool.commonPool-worker-7) Plugin Manager closed.

The stack trace to closed() looks like this:

But sometimes also like this:

[pitschr]

Thanks for checking it. Far as I see:

2021-03-19 19:01:14,155 ERROR [de.ste.sma.ser.knx.KnxServiceImpl$GroupMonitorPlugin] (pool-5-thread-1) KNX client error.: li.pitschmann.knx.core.exceptions.KnxWrongChannelIdException: Wrong channel id '3' received, expected channel id is '-1': ....

This is OK, because we got "ConnectionStateResponseBody" from your KNX/Net IP device with channel ID = 3 which became invalid meanwhile. The expected channel ID in the KNX Client was "-1" because it has been reset in the finally statement of InternalKnxClient#stopServices() method which is a part of the client stop procedure:

2021-03-19 19:01:14,153 INFO  [li.pit.knx.cor.com.InternalKnxClient] (ForkJoinPool.commonPool-worker-7) Client will be stopped.

Before the close it was "3", see:

2021-03-19 18:59:51,675 INFO  [li.pit.knx.cor.com.InternalKnxClient] (executor-thread-1) Channel ID (Tunneling)           : 3

The client.isRunning becomes false as soon the state of InternalKnxClient is not STARTED anymore, this is triggered only when the KNX Client is stopped, which sets the state to STOP_REQUEST and finally NOT_STARTED when close has been completed.

To complete the picture when isRunning becomes false, the lifecycle of state is following:

1. NOT_STARTED (initial)
2. START_REQUEST (as soon the method start() is invoked)
3. STARTED (as soon the communciation has been established and start() is completed)
4. STOP_REQUEST (as soon the method close() is invoked) ==> HERE !!!!
5. NOT_STARTED (as soon the close() is completed, initial state again)

The second screenshot where the close is invoked via DisconnectRequestTask is triggered, when your KNX Net/IP device asks the KNX Client to close the communication for some reasons. Examples where the remote KNX Net/IP device may request for connection close are:

• When there were no response after 3 packet requests to KNX Client (frequently happens when we're debugging and threads of KNX Client are suspended)
• When there were too many connections established quickly and connections are not closed properly (also happens from time to time during development, where I often simply kill the thread 😈 )

During the debugging (with breakpoints). I am quite sure that your KNX Net/IP device sent Tunneling Requests, but the KNX Client was suspended without any responses and therefore the DisconnectRequest frame was sent. This invokes the close of KNX Client. So given the log lines I do not see an issue.

============

I'm not familiar with Kotlin what Thread { ... and knxClient.use { client -> are doing ... . If the knxClient.use statement is subject to be executed in parallel, please check if client.isRunning might be called BEFORE the connection is established. If yes, here the InternalKnxClient may still have the START_REQUEST state, which may return false for isRunning. That would be an explanation why the KNX Client is stopped unexpectedly.

You can easily check that with breakpoints:

• li.pitschmann.knx.core.communication.BaseKnxClient#isRunning at method entry
• li.pitschmann.knx.core.communication.InternalKnxClient#start at line #127 (where this.state = State.STARTED;)

Try to start your application multiple times, and check which breakpoint is triggered in which sequence.

[StefanOltmann]

* When there were no response after 3 packet requests to KNX Client (frequently happens when we're debugging and threads of KNX Client are suspended)

Yes, that must be the case in this debugging scenario.

I'm not familiar with Kotlin what Thread { ... and knxClient.use { client -> are doing ... .

It's just the try-with-resources equivalent.

Actually I copied your Java code sample into my project and IDEA automaticly converted it to this form. The Kotlin converter really is a nice way to learn that language. ;)

If the knxClient.use statement is subject to be executed in parallel, please check if client.isRunning might be called BEFORE the connection is established.

Yeah, there was never any startup issue.

If yes, here the InternalKnxClient may still have the START_REQUEST state, which may return false for isRunning. That would be an explanation why the KNX Client is stopped unexpectedly.

If it would sometimes not boot up I would suspect that.

The thing I overlooked until today was that it never was an exception that reached the try-with-resources/use block because that would have been logged.

The correlation I see is that some time after starting the service (and usually these are several days) that cause an KnxEnumNotFoundException and these somehow lead to client.isRunning. And if they don't directly lead to that I clearly see that it happens some time after that exception got logged.

Can you check that even if exceptions like the KnxEnumNotFoundException or others occur the client keeps running?

If not it's not a too big problem because I can restart the knx client after that. This works stable. It just looks strange in the logs to have an exception like this.

[pitschr]

All my exceptions like KnxEnumNotFoundException extends KnxException which extends RuntimeException.

All communications are going through li.pitschmann.knx.core.communication.queue.AbstractKnxQueue#run() (inside ChannelCommunicator) which catches all exceptions, except

• the IOException because that would be a severe issue, here we should see a message with IOException in ....
• the InterruptedException when queue should be gracefully closed, here we should have seen a message with Channel is interrupted.

Places invoke the close() method:

• DisconnectRequestTask --> when remote KNX Net/IP device asks for close
• ConnectionStateCommunictor -> when there is no communication response coming from KNX Net/IP after 120 seconds (according to KNX Specification)
• When something went wrong during start-up / establishing the connection (e.g. KNX Net/IP not supporting Tunneling/Routing, No free connection slots available on KNX Net/IP device, ...)
• Or direct call of DefaultKnxClient#close() or BaseKnxClient#close() --> when closing application (either manually or via JVM shutdown hook)

I do not remember other cases.

====

When you get the packet with unsupported APCI again, can you check if you get such request 3 times from your KNX Net/IP device? The KNX Client won't respond on this request, and if the things goes stupid then a disconnect request is sent by the KNX Net/IP device which asks the KNX Client to close the communication gracefully.

I know the knx-audit.log wont have this information anymore due overwriting (this has already been fixed, but not in maven yet). But perhaps you see something like that in the knx.log ? It should happen shortly before the client is closed. According to the KNX Specification, there should be 3 failed requests and the request timeout for tunneling request is 1 second. Check if you see a disconnect request frame in the log file.

[StefanOltmann]

Yes, maybe we get closer to the root cause.

I will watch out if there will be a disconnect request due to not responding to that package.

By the way: My service and companion apps, despite having not many features, are stable enough that I documented how to get started with it. You may want to check it out.

I also think that knx-core comes closer to be mature enough that someone might write a OpenHAB integration.

[pitschr]

Cool. I just invoked the release procedure for 0.4.0 and should be available soon; for knx-core and as well for plugins which should solve the append issue (e.g. audit and statistic plugins). Our next investigation should be easier, hopefully.

Yes, the library might get a public version soon. According to maven repo, more than 200 unique visitors downloaded my library from maven repository. I still miss some feedbacks from others. Based on my experience, I know only few percent of consumers are reporting the issues pro-actively. I appreciate your reports and your proposals! THANK YOU!

At least I consider knx-core as mature enough; in approx. 1 week I expect my 1st million request 💪 (running since release 0.3.0 on 15th Feb)

I'm not familiar with OpenHAB, but I doubt that they need my integration as they already have KNXD which is well known, but I also have not worked with KNXD directly, to be honestly. Do you see a significant benefit for integration of knx-core library there? How can knx-core be more improved? I have no further ideas how to improve knx-core further (apart from adding more DPTs 😅 )

I'll check out your application! If you feel your software ready for broader public, you may register (if not done yet) & introduce your project on https://knx-user-forum.de . You'll find me there under username "pitschr".

[StefanOltmann]

I appreciate your reports and your proposals! THANK YOU!

You are welcome. :-)

I'm not familiar with OpenHAB, but I doubt that they need my integration as they already have KNXD which is well known, but I also have not worked with KNXD directly, to be honestly. Do you see a significant benefit for integration of knx-core library there?

KNXD is really crappy and the main reason I investigated in alternatives. It often crashes down or does not even start. And it's hard to get running anway. I would say I hate that thing.

OpenHAB uses calimero-project together with KNXD as far as I know. At least I saw calimero in the stack trace if KNXD stopped in my old installation. knx-core is way more stable, well tested and just needs only Java without any unrealiable old C projects. That's a big benefit to me. Also the API is after you did the requested tweaks very easy to use in contrast to calimero.

But of course I don't know what people that use it without an IP interface think here.

How can knx-core be more improved? I have no further ideas how to improve knx-core further (apart from adding more DPTs 😅 )

Convert it to Kotlin. ^^

No, I don't have any ideas either. It must not improve further. It does what it should.

I'll check out your application!

Nice. :)

[StefanOltmann]

I close the issue for now as I don't think it's a bug anymore. I will investigate further with v0.4.0.