Wiser for KNX BACnet Subscriptions

[sesa189449]

Hello I am hoping someone can digest the below comment from a client and let me know whether this is our issue or there.

The current setup on site is our Wiser for KNX is send BACnet points to a Crestron touch screen panel however it appears to be lagging over a period of time see below there comment.

Thie issue appears to relate to an aspect of BACnet that is referred to in its abbreviated term ‘COV’ (Change of Value). COV is a property or a property within an object that relates to the value of ‘something’ – example – setpoint value.

When any client (in this case Crestron) is integrating with the BACnet protocol, the Client has pre-knowledge of what objects to expect on the BACnet server (In this case the Wiser Controller). We preconfigure the Client (Crestron) with the data supplied to us in the BACnet export tables.

We then have the ability to tell the BACnet Server to notify the Client of and Change of Values in the form of a subscription. Devices on the BMS side do need to support COV Subscriptions, but the Server will allow us to subscribe whether the BMS hardware is capable or not.

The purpose of this subscription is for the server to broadcast to any client that is interested (Subscribed) that a value has changed. As an extra level of checking, the client also polls the server to query all of the data, but this is on a circa 30 second cycle and is there as a backup.

An example of this;

User increments the setpoint from the Crestron touchpanel, this tells the Crestron processor (the client) to send a request to the BACnet Server (Wiser Controller) to raise the temperature. The Server then requests this change on the HVAC hardware via the KNX Bus. This completes the request phase.

As a result of us subscribing to the Setpoint COV, the Wiser box should then send an event message back to subscribed clients (Crestron Processor) to say the value has changed, this in turn will update the touchpanel.

What is actually happening is the BACnet Server (Wiser Controller) is not sending event messages back and because of this, the touchpanel is not instantly updating. It then waits for a poll cycle, which requests the data and updates based upon that server response.

The reason a reboot of the Crestron Processor resolves it for a period, is because this is forcing a fresh subscription to the COV events, but in time this subscription then fails. And we are back to a ‘laggy’ system. In fact the changes are instant, it is purely the update to the Userinterface that is lagging based upon not receiving the change.

There is a property on the BACnet Server known as COV Lifetime, this is important when there are a lot of updates to broadcast, to prevent the message queue overflowing, the lifetime value will allow the server to dispose of these messages if they have not been dispatched from the queue within the defined expiry time. So if this value was too low, the server could be disposing of them and not sending them. Thus making it appear that the subscription has failed.

[Erwin-vd-Zwart]

On what value did you set the COV offset? Default is 1 so a setpoint change needs to be at least 1 degree or more before COV is updated, a poll will update eventually the value as described, another question is how many COV points are you subscribed to and did you change the COV limit accordingly?

it sounds to me the COV settings needs to be checked.. 

[Erwin-vd-Zwart · Accepted solution]

Another reason could also be time syncing, when using COV correct time in both devices is mandatory to make subscriptions work properly, make sure both devices are using the same NTP server or use BACnet time sync from the client, in this case Creston if they support that.

Please check COV settings in the Wiser first and if that does not help please check if possible time differences between BACnet client and W4K are causing COV to fail.