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.
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.
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
.Change the Request Acknowledgements
property to false
.
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.
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:
Transmit
flag set. This causes an unsolicited message transmission from the KNX device.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 Address
es are being polled, how often, and the amount of available RAM, you could try increasing the value to 1000 to overcome the
fault.