VRF bacnet Integration with JACE

General
1

Has anyone experienced communication or performance issues with Daikin ITM, Samsung, or LG Smart 5 systems when integrating them with a JACE?

We’ve been running into similar issues with all three manufacturers, and it seems like the devices may not be able to handle the amount of traffic generated by the JACE.

Daikin:
The ITM would eventually freeze under the communication load. We had to change points to read-only and adjust the tuning policies to reduce the traffic. The Daikin vendor ultimately recommended keeping the points read-only after the other adjustments we tried did not resolve the issue.

Samsung:
We’ve experienced similar behavior. Samsung provided a list of recommended tuning policy settings, but we are still having to keep the points read-only.

LG Smart 5:
This one is behaving a little differently. It appears to be writing True/False to Boolean points at what seems to be a fixed interval. For example, an Occupancy command point that is set to “Occupied” will periodically tell the LG Smart 5 that it is “Unoccupied.” It stays unoccupied for roughly 10 minutes before going back to occupied. We’re seeing similar behavior with the other Boolean points as well.

So far, we’ve tried:

  • Changing tuning policies from polling to COV

  • Adjusting tuning policy timing to reduce the frequency of communication with the JACE

  • Reducing the amount of traffic where possible

  • Setting points to read-only

The only solution that has consistently worked so far is keeping the points read-only.

We’re currently waiting for LG tech support to get back to us, but I wanted to see if anyone here has run into similar issues with these systems.

Has anyone found a solution that allows write commands from the JACE without overwhelming or causing issues with the equipment/controller? Any suggestions for tuning policies, communication settings, or other things we may be overlooking would be greatly appreciated.

2

JACE8000 or JACE9000? Can you take a snapshot of your BACnet poll service so that we can see some of the data? My experience with these vendors is also isn’t great, particularly with LG and Samsung. I’ve integrated Daiken’s ITM to Delta Routers with success, and coincidentally I have a Daiken ITM I’m going to have to integrate with BACnet IP pretty soon onto a Honeywell Optimizer Advanced(JACE9000 with IO basically).

3

I went digging in the BACnet driver itself rather than guess, and what stands out is how little it adapts on its own. It changes behaviour in exactly three cases. A Reject of unrecognized-service turns ReadPropertyMultiple off for that device and falls back to single ReadProperty. A Reject of buffer-overflow shaves five bytes at a time off that device’s max APDU. And a transaction timeout read-fails every point in that request, because maxPollTimeouts is a hidden slot defaulting to 0. An Abort of segmentation-not-supported, or of “other”, gets no adaptation at all – those lines are commented out. Meanwhile a failed poll list gets split on the first failure, the threshold being another hidden slot defaulting to 0, so one request becomes more, smaller requests at the same rate. On a gateway that is already drowning, message count goes up after a failure, not down.

So the reduction has to be explicit. In order: add the bacnetUtil module and drop an RpmOverride under the offending device – useRPM defaults to false and the component rewrites that device’s claimed Protocol_Services_Supported, so the JACE reads one property at a time instead of trusting what the gateway advertised. Add an ApduSizeOverride (defaults to 480, floor 50), and a SegmentationOverride if you see Aborts. Then move points to slow poll: fast/normal/slow default to 1s/5s/30s, and each port has exactly one poll thread, so the cycle is hostage to the slowest device on it. On writes, minWriteTime is the throttle and defaults to 0, i.e. off, while writeOnStart, writeOnUp and writeOnEnabled all default to true, so every time a flaky gateway comes back, every write is re-sent at once. That module also has metrics components for messages, bytes and average latency.

The LG behaviour reads differently to me. Niagara’s fallback is not “don’t write”. When all sixteen levels go null the active level is fallback, and for a present-value point the driver writes with no priority, which BACnet treats as priority 16. With the default fallback status (null) that write is an ASN Null, i.e. relinquish at 16, and from there the gateway’s own Relinquish_Default decides what the indoor unit does. If Relinquish_Default on that BV is inactive, you get Unoccupied, and that is LG’s decision, not the JACE’s. Read it before blaming the station. On the Niagara side, add a boolean slot named ignoreFallback to the BACnet proxy extension and the driver relinquishes only the level it actually wrote, never the bare no-priority write.

One more trap: on a BV or AV, unlike a BO or AO, whether the driver ever writes with a priority is settled once, when the point is created, by a single ReadProperty of priority-array index 0. Any exception, including a timeout on a busy gateway, sets that flag false, and the point writes present-value with no priority forever. Spy the proxy ext to see it – it prints prioritizedPV and lastWriteLevel. Dropping a PriorityArrayDetector on the device or network and invoking detect re-runs the probe.

4

Jace 9000 for LG, Daikin and Samsung were 8000’s. It doesn’t seem to matter though.
I will share poll data once i get a chance. Remote access is very restricted for this site.
I did look at the poll service and numbers weren’t looking great, even after changing tuning policies to be much much slower.
For Daikin, it was simply a matter of too much traffic so i couldn’t really blame Daikin. We have one in our office and it works without issues. we even tested out comm settings in the office before deploying them on-site and still ran into issues. I wish there was a routing option available on the ITM that transfers data from vrf’s directly to JACE without going through the ITM. Similar to “BACnet Routing” option on NAE’s

5

I’m still unpacking that fallback line in your post. for example if we are using polling, the bacnet driver is writing occupied to the LG unit every 30 seconds. if we write using “in16” on the bacnet writeable point in the JACE, the LG unit has an occupied in its priority array (@ level 16). so unless some other device on network or the LG device itself writes to a higher priority the point should still be occupied.

are you saying that if we write using the “fallback” input on the bacnet writeable point in the JACE that in between polls the driver will relinquish control thus sending a null and the LG will then go to its relinquish default value? Will this also happen when the JACE is using “in16”?

Does this sound like simply writing at “in16” or higher will fix this issue?

6

On a gateway that is already drowning, message count goes up after a failure, not down.

Yeah, the system was running fine until we rebooted and all the point got written at once since tuning policies weren’t set up correctly. The LG 5 has been drowning in traffic since.

So the reduction has to be explicit. In order: add the bacnetUtil module and drop an RpmOverride under the offending device – useRPM defaults to false and the component rewrites…

I will give this a shot on the Daikin system. The site with LG has critical infrastructure so can’t be messing with it too much.

Then move points to slow poll: fast/normal/slow default to 1s/5s/30s, and each port has exactly one poll thread, so the cycle is hostage to the slowest device on it. On writes, minWriteTime is the throttle and defaults to 0, i.e. off, while writeOnStart, writeOnUp and writeOnEnabled all default to true, so every time a flaky gateway comes back, every write is re-sent at once.

Already handles this step, it didn’t help much. Setting are as follows:

MinWriteTime: 60 seconds, Max: 12 hours

writeOnStart, writeOnUp and writeOnEnabled are all false

StaleTime: 2 Hours. pollFrequency: Low.

These were recommended by Samsung.

On the Niagara side, add a boolean slot named ignoreFallback to the BACnet proxy extension and the driver relinquishes only the level it actually wrote, never the bare no-priority write.

okay

There’s a lot to unpack here. This might take a day or two of testing to see what each setting affects and if the changes are meaningful, harmful, or helpful.

I appreciate the time and effort put into this. This was the kind of answer i was hoping for.

7

Well that’s the thing, we are writing to a fallback value and the jace is still relinquishing control periodically.

Upon writing to in8 (Operator Override), the same issue persists even if there is also a fallback value. I was chalking it up to the controller being overloaded.

8

writing to priority 8 and still having that issue really perplexes me. maybe the timeouts are what’s causing the jace to relinquish the write points. an other option is to also write to the relinquish default property (if writeable) but that sounds more like a Band-Aid then a fix.

9

Glad it is useful. Two things to watch while you test, both of which can make a change look like it worked when it did not.

staleTime at 2 hours means a device that has gone away still reads its last value for two hours. During testing that is the setting most likely to fool you: judge each change on the device status and the ping monitor, not on whether the points still look sensible.

One poll thread per port means slow poll only helps if the slow device has the port to itself. If the LG gateway shares a network with anything else, moving its points to slow just moves where the queue forms — the cycle is still hostage to it. Splitting the misbehaving gateway onto its own network is usually worth more than any of the tuning numbers.

And test one change at a time, each for a full poll cycle. The RPM override and the write throttling both change the shape of the traffic, so together they are hard to tell apart.

Post the numbers when you have them if you like — I am interested in what the Daikin does with RPM off.

10

Boba — coming back to your post about writing a fallback and the JACE still relinquishing. As far as I can see there is no periodic relinquish in the driver. I went through the write path in the jars, and every Null it sends is tied to a level change — not to a timer, not to a poll, and not to a timeout.

BBacnetProxyExt.write builds one command and hands it to PointCmd carrying two levels: lvl, the level it is writing now, and clr, the level it wrote last time. PointCmd.run then does this, in order:

  • if lvl is between 1 and 16, WriteProperty at that priority;
  • otherwise, if there is a value, WriteProperty with no priority argument at all;
  • otherwise, if clr is 0, WriteProperty of Null, also with no priority;
  • and then, separately, if clr is non-zero and different from lvl, a second WriteProperty of Null to clear the old level — at priority clr, or with no priority if clr was 17.

Fallback is level 17, and 17 is not a BACnet priority. So when a point falls from in16 to fallback you get exactly the pair you are describing: the fallback value written with no priority, which the device takes as 16, immediately followed by a Null at 16 because clr (16) no longer equals lvl (17). Net effect at the LG is a relinquish, and it drops to its relinquish default. Nothing timed out. The point just stopped having an input at the level it was using.

Writing at in8 does not change the shape of that. It changes which priority gets the value, but the moment in8 goes null and fallback becomes active you get the same clear, a Null at 8 this time. If in8 is being driven by a schedule or a program object that nulls between cycles, that is the first place I would look.

There is also a case where the level does not matter at all. write only treats a point as prioritized if isPrioritizedPresentValue() is true. For AO, BO and MSO on present-value that is always true. For AV, BV, MSV and the newer value types it is discovered once by reading the priority array, and cached on the proxy in deviceFacets under priPV. If that read failed — busy gateway, device down when the points were discovered — the facet stays false, the write level is forced to 0, and every write goes out with no priority no matter which in slot you used. On the LG points that is worth confirming before changing anything else.

For the fallback pair specifically there is an escape hatch: a boolean slot named ignoreFallback on the proxy ext, or niagara.bacnet.point.ignoreFallback=true station-wide. With it set, a point going to fallback stops writing the fallback value and simply relinquishes the level it last wrote — one clean Null instead of a write followed by a clear.

One last thing for a gateway that is already struggling: every successful write calls pollNow on that point, so each write costs a read on top of it.