Troubleshooting

This topic covers some issues and how to resolve them.

Can I have both the KNXnet/IP driver and EIBnet/IP driver running in my station?

No. There is an absolute certainty of conflict between the KNXnet/IP driver and the older EIBnet/IP driver if they are running concurrently. If there is an EIBnet/IP driver in the station, delete it before you enable the KNXnet/IP driver.

Why, when discovered points are added to the Database, are they in {fault}?

Image

One of the many reasons why points can go to a {fault} condition, relates to the R1 firmware revision of the Siemens N 148/22 KNXnet/IP Interface device. It may also occur with other KNXnet/IP Interface devices.

The problem is caused by the KNXnet/IP Interface device failing to respond with an acknowledge message although message confirmation has been requested by the KNXnet/IP driver.

You may also observe that the Fault Cause property of the point proxy extension indicates Read fault: confirmation — Confirm Timed Out.

Image

One way to overcome this problem is to upgrade the R1 firmware revision level of the Siemens N 148/22 KNXnet/IP Interface device (or any other KNXnet/IP interface device). It is beyond the scope of this document to detail the steps to accomplish this, but manufacturers of KNXnet/IP interface devices may provide tools and guidance to upgrade their firmware.

Another way to overcome the problem is available within the KNXnet/IP driver. To do this, configure the KNXnet/IP driver not to request an acknowledgement to its messages. To configure this use a hidden property in the tunnel connection of the KNXnet/IP driver.

Unhide the requestAcknowledgements slot of the KnxNetwork > KnxDevice > Comms Connections > Tunnel Conn.

Image

Change the Request Acknowledgements property to false.

Image

Why do some points randomly change state between {stale} and/or {fault} and {ok}?

Image

If, after appropriate time-outs, the KNXnet/IP driver fails to receive requested data from the KNX device, points go to a {fault} and/or {stale} state.

If the KNX device subsequently transmits data, for example a change of state or value, the KNXnet/IP driver receives this unsolicited message thereby causing a change of proxy point status.

Why, when discovered points are added to the Database, some are {stale} and some are not?

Image

One of the many reasons why points can go to a stale state relates to the ETS project file.

When points are added to the database from a ETS project file, their subscription properties are automatically configured based on the communications flags set in the ETS project. These are the flags for the KNX device's group objects, which are associated with the point's Group Address.

If a group address has at least one KNX device group object associated with it that has its Read Communication Flag property enabled, the Poll once on subscribed, Poll once on operational and Poll until answer after poll once properties are set to true. This triggers an immediate poll of the Group Address (because this view is itself subscribed to the point).

If a Group Address has no associated KNX device group objects that have their Read Communication Flag enabled, its subscription properties are all set to false by default. The value, however, may be updated (and become not stale) in the KNXnet/IP driver when any subsequent unsolicited messages regarding the Group Address are received from the KNX system.

Here are the Read Communication Flag settings for some of the points in the example shown above:

 
NOTE: The Control Output (Control value) object has its Transmit flag set. This causes an unsolicited message transmission from the KNX device.
 
Image
Image
Image

Please explain the Read fault: The ‘Read’ queue is full.

This fault occurs when an attempt is made to enqueue (add an item to a queue) a read request of a particular Group Address, where the queue is already full and the Group Address in question is not already in the queue. The queue in question is the Group Data Operation Queue, which holds a list of group data operations (Group Address reads or writes) waiting to be started as soon as the communications stack is able.

The Group Data Operation Queue has its size exposed under the hidden L Data Worker child of the Group Data Manager, immediately preceding the Hop Count property and can be seen in the example below. The default value of the Group Data Operation Queue is 50.

Subject to how many Group Addresses are being polled, how often, and the amount of available RAM, you could try increasing the value to 1000 to overcome the fault.

Image