JCI FC Bus Health Index correlating to device offline/online events WBT900 wireless
I have some sewer lift stations I'm monitoring via metasys. I'm using a WBT900 MSTP server at the NAE and two WBT900 MSTP clients at the stations. Each client has a single FEC hanging off it to monitor/control the sewer lift station.
I'm having an issue with the FECs going offline sporadically. The WBTs have an excellent signal strength on them so I don't think that's the issue. The FECs only go offline for 10-20 seconds at the most.
I started a trend on the Bus Health Index and the offline events seem to correlate to when ever the index number is greater than 1.
Currently the WBT900s baud rates are set to 38400 and the NAE & FECs are set to auto. Would bumping up the baud rate on the WBTs help this out at all? they were originally set at 38400 per the recommendation from the JCI MSTP Lit-12011034 file.
AIC is saying there device is working fine and JCI isnt much help because I'm using another vendors device so I'm sort of not sure where to go form here.
Any suggestions? I've attached some screen captures showing the offline events and the bus health index trend.
Lowering the baud rate will be of some help.
If there aren't any competing wireless networks, lock the WBTs to a single channel.
I would guess there are some tuning policies that could be adjusted.
UA LU 562
I was wondering if you had any luck clearing this up? I'm trying to set up a pretty extensive wireless network using the WBT900 talking to ABB Drives and sending that data to our JCI BAS. I can get 4 drives to come up but as soon as I try to put any more online, it's taking the entire trunk down.
No and AIC seems to be apart of wattstopper now and basically their support staff stopped responding to my calls/emails....
I'm in the same boat now, I've sent emails, left Voicemails anything and everything I know to do and can't get them to give me any support. So frustrating.
Good to hear I'm not special
Sounds like it's time for the WBT900-RPR kit.
Increase the MSTP time
Originally Posted by nasaguyjoe
Try and increase the MSTP bus times -> go under the focus tab and adjust the following;
APDU Timeout is the length of time the NAE will wait before sending a retry if no reply to the request has been received.
APDU Retries is the number of times the NAE will to get an answer for a request. If no reply is received after all retries Device is tagged offline and request is discarded.
Periodic Update is the frequency the NAE will request information for objects that are being Polled. Typically any mapped 3rd Party BACnet device/objects will have to be polled for updates. When >75 objects are mapped from a FEC Family device, the NAE will have to poll for some of the objects. If the polling list gets too large the NAE may not be able to complete one poll cycle of all the objects in the amount of time allowed (Periodic Update). This can cause the NAE to buffer or queue messages for the next poll cycle before it has completed the last one. If trunk performance is slow and the objects that are mapped can be updated less frequently, increase the Periodic Update to 30 or even 60 seconds. This will help prevent the NAE from loading up on poll requests to go out on the trunk, when it doesn't really need for the objects to be updated that often.
Post Likes - 2 Likes, 0 Dislikes
Now this, THIS is the kind of info I was looking for, thank you!
So, my question would be, for the Timeout and Retries, what sort of intervals would you try bumping them to?
Looks like the Timeout defaults to 6000 ms, the Retries Default to 3. Would upping them to 9000 and 6 be too big of a jump, you think? Or would that be close to a decent increase?
Basically, what we've got out here is an overloaded, long-ass FC-Bus that, on top of already having a bunch of TECs (29 of them)on it as well as a few FECs with a BUS repeater on it, we are trying to add a bunch of ABB drives using the WBT900-K to it. We have 8 Drives per floor, with 4 floors and a single WBT900 server per floor. I can get 4 drives to talk but as soon as I attempt to bring the rest of the 1st floor online it takes the entire trunk down. Getting super frustrating.
I can't get AiC or Wattstopper to call me back, just like NASAguyJoe, so any help or guidance would be appreciated at this point.
The values you propose aren't out of line.
Originally Posted by code-vii
You have a seriously overloaded bus it sounds like.
Look at the focus tab on the FC trunk. What is the count?
Also what are your token loop times?
You should set all the covs to as big as number that you can get away with too
OK, The Count for this bus is 693
and the Token Loop Times are:
Token Loop Time: 125 ms
Predicted TLT: 500 ms
Max TLT: 1510 ms
In fact, I'll attach a screenshot of the Diagnostic tab:
I've just noticed that I have a few TECs offline that have been on, so that is probably why my Bus Health Index is currently so high.
Here's the Focus Tab:
Originally Posted by code-vii
First I would increase the APDU etc. Then as JCIMAN mention, "MAKE SURE" all of your objects are COV which will elimiate the polling on the MSTP bus.
If you still have issues, we can change couple more things.
*what type of NAE is this? Can you tell me how many TEC and 3rd party devices you have on this bus? From the NAE, what is the CPU \ Flash usage etc and Object count. Does the NAE go offline?? or is it just the MSTP bus.
Post Likes - 1 Likes, 0 Dislikes
Yeah, it's a NAE5510-2.
And when you say "MAKE SURE all of your objects are COV" are you talking about the actual AI/BI setup? Or is there a parameter on the FC Bus or in the NAE itself that can be set to COV? I'm trying to think and the only time I can remember setting a poll increments like that is in setting up trends, and fortunately none of these device inputs are being trended.
We have 28 TECs, which are "Technically" JCI devices but I don't think they are actually counted as such. I know that they are a complete PITA to get and keep online and always reek havoc on my networks in 1 way or another.
Here's a screencap of my NAE Diagnostic:
Looks like 9% for both CPU and Flash. There isn't a lot of LCT or anything in these, they are mostly monitoring systems.
Then we have the Drives, all ABB but only 3 of them are directly landed on the trunk. The rest, of which there are 32, are all going through these wireless WBT900 devices. These are passive devices and only act as bridges. So, while the WBT900 "Server" does sit on the trunk, it doesn't actually have an address and the NAE doesn't communicate with it directly. There are 8 WBT900 "Clients" connected to 8 ABB Drives that send each drives data wirelessly to the WBT900 "Server", which then just pushes the data to us on the FC Bus.