Skip to main content
T
Tanquen12-Amethyst
12-Amethyst
August 5, 2025
Solved

KEPServerEX 6.17 - BACnet - Quality is shown as good timestamp updates but value is old.

  • August 5, 2025
  • 2 replies
  • 645 views

In the BACnet software WebCTRL the value is 65.88 but in KEPServerEX the value is 66. 

 

I forced to read and the timestamp updated but the value remained the same. I thought it was rounding it or something. I changed address to a different temperature that did show decimal places and it updated to that point's value and showed decimal places. I then switched the address back and only after doing so did it show a current value with decimal places.

 

It's a little concerning that the value was shown as good and the timestamp having updated but the value  seems to be old.

 

Is there a bug in the BACnet driver or possibly some weird dead band?

 

In WebCTRL the value is currently 65.71 and is fluctuating a tenth of a degree every 5 or 10 seconds. In KEPServerEX it's just stuck at 65.86 and no longer seems to update. The polling rate is very slow but again if I force that one value to read or wait for the normal polling the timestamp updates but the value doesn't update.
I just tried doing it again and my trick of changing the address to another point didn't seem to work. That must have been coincidental.
Currently in the OPC Quick Client it shows 65.86 

Tanquen_0-1754414449369.png

But in the BMS application it's 66.06.999

Tanquen_1-1754414509848.png

 

Best answer by MKhatri

Thank you for the detailed observations and screenshots regarding the BACnet value update issue in KEPServerEX 6.17.

After reviewing your case and cross-referencing with Kepware’s official documentation, here are a few key points that may help clarify the behavior you're seeing:


Understanding the Behavior
 

  • Good Quality with Stale Value: This can occur when the driver receives a valid timestamp, but the value remains unchanged due to either a stale cache or polling logic. This is a known behavior in OPC/BACnet drivers and can be mitigated by forcing a refresh, rebind, or adjusting polling settings .
  • COV (Change of Value) Settings: KEPServerEX supports multiple COV modes:
  • Use Unconfirmed COV (default): Receives updates without acknowledgment.
    Use Confirmed COV: Requires acknowledgment for each update.
    Do Not Use COV: Forces polling even if COV is supported 2.
    If your BACnet device has a COV threshold (e.g., 0.5), and the value change is below that threshold, the driver may not receive an update unless polling is used. Switching to "Do Not Use COV" forces polling but may still rely on cached values unless explicitly refreshed.
  • Polling vs. COV: If the polling rate is slow and the value change is minor, the timestamp may update while the value remains unchanged. This could be due to the driver reading from cache updated by COV notifications rather than directly from the device

Recommended Actions


  • Force a Refresh: As you’ve already tried, changing the tag address temporarily can trigger a fresh read. Alternatively, you can use the “Force Read” option or restart the channel/device.
  • Adjust COV Settings: Try setting the COV mode to “Do Not Use COV” and monitor if polling retrieves the updated value more reliably.
  • Enable Logging: Turn on detailed driver logging to capture read/write behavior and identify if fallback values or failed reads are occurring.
  • Check Device-Specific COV Behavior: Some devices treat SPID=0 as a shared subscription. If applicable, adjust SPID settings to ensure unique subscriptions

     

2 replies

S
SlidingDownhill12-Amethyst
12-Amethyst
August 5, 2025

Is there a deadband involved ?

T
Tanquen12-AmethystAuthor
12-Amethyst
August 5, 2025

I don't see one associated with any of the points. No scaling or anything. Not something I've ever tried to add in KEPServerEX. The BACnet pulling is slow enough, I want it to read a new value whenever it does.

Tanquen_0-1754415727405.png

 


There are a few more settings on the device itself like timing and scan mode but I'm not aware of anything that would be telling it to ignore a change in value.

T
Tanquen12-AmethystAuthor
12-Amethyst
August 5, 2025

Not sure if it's real but here's what chat GPT had to say. I did want to try to run YABE but I don't know how to do it without taking KEPServerEX offline.

KEPServerEX most likely showed the wrong value for AV201 due to a stale fallback value from a failed or incomplete initial read. Changing the address caused the driver to re-fetch and update correctly. This is a known behavior in OPC/BACnet drivers and can be mitigated with refreshes, driver logging, or rebinds.

Let me know if you'd like help setting up YABE or interpreting raw BACnet logs — that can pinpoint these subtle bugs quickly.

T
Tanquen12-AmethystAuthor
12-Amethyst
August 18, 2025

Out of many points it only randomly happens on occasion with a few points.

 

I did notice that the points in the BMS application have a COV of 0.5, is it possible that KEPServerEX is updating the values outside of that change of value dead band?

 

I tried changing the COV mode from the default of `Use Unconfirmed COV` to `Do Not Use COV` and the value remained the same.

I guess that should be expected if KEPServerEX is polling the BACnet devices more often than the building management system.

M
MKhatri15-MoonstoneAnswer
15-Moonstone
August 26, 2025

Thank you for the detailed observations and screenshots regarding the BACnet value update issue in KEPServerEX 6.17.

After reviewing your case and cross-referencing with Kepware’s official documentation, here are a few key points that may help clarify the behavior you're seeing:


Understanding the Behavior
 

  • Good Quality with Stale Value: This can occur when the driver receives a valid timestamp, but the value remains unchanged due to either a stale cache or polling logic. This is a known behavior in OPC/BACnet drivers and can be mitigated by forcing a refresh, rebind, or adjusting polling settings .
  • COV (Change of Value) Settings: KEPServerEX supports multiple COV modes:
  • Use Unconfirmed COV (default): Receives updates without acknowledgment.
    Use Confirmed COV: Requires acknowledgment for each update.
    Do Not Use COV: Forces polling even if COV is supported 2.
    If your BACnet device has a COV threshold (e.g., 0.5), and the value change is below that threshold, the driver may not receive an update unless polling is used. Switching to "Do Not Use COV" forces polling but may still rely on cached values unless explicitly refreshed.
  • Polling vs. COV: If the polling rate is slow and the value change is minor, the timestamp may update while the value remains unchanged. This could be due to the driver reading from cache updated by COV notifications rather than directly from the device

Recommended Actions


  • Force a Refresh: As you’ve already tried, changing the tag address temporarily can trigger a fresh read. Alternatively, you can use the “Force Read” option or restart the channel/device.
  • Adjust COV Settings: Try setting the COV mode to “Do Not Use COV” and monitor if polling retrieves the updated value more reliably.
  • Enable Logging: Turn on detailed driver logging to capture read/write behavior and identify if fallback values or failed reads are occurring.
  • Check Device-Specific COV Behavior: Some devices treat SPID=0 as a shared subscription. If applicable, adjust SPID settings to ensure unique subscriptions

     
Terms & ConditionsCookie settingsAccessibility statement