PDA

View Full Version : BACnet controllers- question?



joellemeitav
12-11-2006, 07:23 AM
Hi!

Can anyone explain to me what is "peer-to-peer" communication when talking about BACnet controllers for the HVAC market (for a network of thermostats in a Building Management System)?

Thanks.

sysint
12-11-2006, 08:16 AM
That means individual devices that can intercommunicate on the same wire of the same type.

If you have an Alerton VAV box and a Automated Logic VAV box they are "peers" as in they are the same type of device.

Although, I've never seen that with bacnet on the device level so that is interesting.

Maybe the bacnet definition of peer to peer is rather loose.

control$
12-11-2006, 04:55 PM
It's as simple as it sounds. Just pick the point needed and send it to device that requests the infomation. No need for expensive third party software to bind points.

mackinaw
12-11-2006, 08:44 PM
I've heard the next version of Johnson will be peer to peer on bacnet. With that said, I would tend to agree with Sysint on this one. It's all in the definition. Just change the definition to match what you want it to be....and now it is.

Peer to peer devices pass information directly to each other, no head end required.

gmha9x
12-13-2006, 05:37 PM
The important thing to note is that a device must be able to initiate SubscribeCOV (and receive COVNotifications) or ReadProperty services in order to communicate in a peer to peer fashion. Often, the smaller MS/TP devices (like thermostats) do not support initiating these services, which are typically used by the workstation only.

leaflying
12-13-2006, 06:59 PM
gmha9x is right. And I've seen Bacnet controllers capable of initiating ReadProperty and WriteProperty. No thermostats yet though.

sysint
12-14-2006, 06:00 AM
Originally posted by gmha9x
The important thing to note is that a device must be able to initiate SubscribeCOV (and receive COVNotifications) or ReadProperty services in order to communicate in a peer to peer fashion. Often, the smaller MS/TP devices (like thermostats) do not support initiating these services, which are typically used by the workstation only.

How about vav box controllers?

gmha9x
12-14-2006, 07:02 AM
It is not very common for MS/TP unitary devices to have this kind of functionality. It is typically seen to be supported in plant level controllers that usually are IP based and have a much larger memory footprint and processor.

Controls$
12-14-2006, 09:19 AM
Has anyone actually used one? What would be the point to make a unitary device that can not talk to a unitary control?

gmha9x
12-14-2006, 06:06 PM
Usually it is the plant controller that communicates with the unitary controller. The plant controller will initiate a ReadProperty to the unitary controller and it will respond to this service. The unitary controller does not usually need to initiate a ReadProperty service to the other unitary controllers. If you think about a LonWorks system, how often do you need a VAV controller to read points in another VAV controller? It is probably not a common thing unless they are sharing a sensor.

mackinaw
12-14-2006, 10:49 PM
"If you think about a LonWorks system, how often do you need a VAV controller to read points in another VAV controller?"

It's nice to be able to....share PID's, CO2 sensors, temp sensors, temp occupancy commands, occupancy commands, setpoints, the list goes on and on.

sysint
12-15-2006, 06:57 AM
how often do you need a VAV controller to read points in another VAV controller?

I simply hate these type of questions. Either you CAN or you CAN'T.

If you CAN'T, then to my definition, there is no peer to peer. Doesn't matter if it's 2 VAV boxes or a VAV box and a soda dispenser, or WHY you want to have intercommunication or not.

So, I guess that bacnet VAV's really don't have peer to peer communication capability.

EDIT It is not very common for MS/TP unitary devices to have this kind of functionality. It is typically seen to be supported in plant level controllers that usually are IP based and have a much larger memory footprint and processor.

Again, CAN'T. There are Lonworks plant controllers that are/aren't/both IP based that still operate peer to peer.... with VAV boxes.....

gmha9x
12-15-2006, 08:12 AM
Each BACnet device supports different services. Some may be able to initiate ReadProperty, others may not. The device profile that a VAV should conform to does not mandate that it must initiate ReadProperty, but that does not mean that some manufacturers have not implemented this functionality. Therefore some VAV devices may support peer to peer communication and some will not.

sysint
12-15-2006, 08:17 AM
Which is my big problem with bacnet. You never know what's going on.

Much easier to have a real peer to peer system like Lonworks where communication is available whether or not you want to use it.

Great thing to have when you need to retrofit or replace.

No need to argue about what different devices "support" and which group of stuffed shirts mandate whatever.

control$
12-15-2006, 10:04 AM
Waiting for some paper work this morning so here we go.

"So, I guess that bacnet VAV's really don't have peer to peer communication capability"
The above is not at all true. IMO either the device (system) is crap or the tech. can't figure it out. It's really getting silly to argue about it.
Answer to the question.
Yes. Devices can talk peer to peer on the same bus. How do I know? See it in front of me right now.
Steps.
1) Wire device to existing bus.
2) Address device. Make sure the comm. is setup for the right type of bacnet and speed.
3) Find point to bind to. (From manufacture or network discover)
4) Enter point to bind to.(ex:bacnet://23/AV:1)
5) Done.

Example: This morning I'm adding a Petra unit to (3) existing Carrier units on a existing MSTP bus.
If needed I could bind from the Petra to the Carrier or to a vav control (or the other way around).
IMO it's easier to do bindings in the programs logic page (and then see it work right away) then to open a seperate program (lonmaker) and find the right bindings.

Question: Manufacture of this device will not bind on a Bacnet over MSTP/Arcnet/IP bus?

sysint
12-15-2006, 11:06 AM
3) Find point to bind to. (From manufacture or network discover)
4) Enter point to bind to.(ex:bacnet://23/AV:1)

What are you using for "binding"?

Is it actually another piece of hardware?

Can you intercommunicate and bind 2 bacnet manufacturers VAV boxes without another piece of hardware that will be required in the system?

Give me two manufacturers names that their VAV boxes that can communicate peer-to-peer without mapping through some form of a GC. Just a network of 2 VAV's and no other hardware or software. -TIA.

asdf;ljk
12-15-2006, 11:59 AM
I'm not sold on the benefits of peer to peer. I seen how it could offer benefits in other industries, but why is it so important in Commercial HVAC industry? Data sharing can be managed just as well from a supervisory class controller.

I realize that if a supervisory controller fails then the data sharing stops, until it is fixed. However, I don't know of many HVAC applications that require mission-critical, reliable communication between 2 VAV boxes. Plus, there is usually a fall back in the the controller in case the data sharing stops.

I don't have to pay credits to use a Supervisory controller. And I can use it to do other things like serve up a web-based UI, do scheduling, do system wide interlocks and control strategies, store data, integrate to legacy protocols, etc.

By the way, peer to peer with different mfgs BACnet MS/TP devices is certainly possible. The issue that usually prevents this is not the BACnet protocol, but the designer of the controller. Most BACnet controller designers don't intend for their controller applications to be put into a peer-to-peer network, but rather a hiearchal supervisory network.

sysint
12-15-2006, 12:40 PM
I guess I'll sum all that up by stating:

CAN'T

Thanks.

sysint
12-15-2006, 12:52 PM
I realize that if a supervisory controller fails then the data sharing stops, until it is fixed. However, I don't know of many HVAC applications that require mission-critical, reliable communication between 2 VAV boxes. Plus, there is usually a fall back in the the controller in case the data sharing stops.

That's hardly the point of the matter. What if I want to change out to manufacturer B? With your way, it is highly likely that it's a big deal rather than a one at a time replacement structure. Plus, it could be any two devices. I thought I'd go easy on stating something really simple like 2 VAV boxes.

I don't have to pay credits to use a Supervisory controller. And I can use it to do other things like serve up a web-based UI, do scheduling, do system wide interlocks and control strategies, store data, integrate to legacy protocols, etc.
Blah. Blah. Blah. I can do all that with available Lonworks devices and still be peer to peer.

By the way, peer to peer with different mfgs BACnet MS/TP devices is certainly possible. Possible Not probable, and not definitely.

The issue that usually prevents this is not the BACnet protocol, but the designer of the controller. Most BACnet controller designers don't intend for their controller applications to be put into a peer-to-peer network, but rather a hiearchal supervisory network.

And we all know why that is..... more $$$$$ and proprietary lockout under a supposed "open" and "peer to peer" network. Really seems like a bunch of lying.

sysint
12-15-2006, 12:58 PM
I don't have to pay credits to use a Supervisory controller.

This is a big winner. You have to buy something for the site. Or, the customer has to buy the specific bacnet vendors EXPENSIVE SOFTWARE package.

Meanwhile, I use the same network tool OVER and OVER again with multiple vendors and pay a very minimal fee for credits (if any) per device. It's a bargin for the customer compared to needing MANY software packages for a multi-vendor bacnet system, or a web based licensing system whereby the manufacturer tracks my every move. (also not inexpensive)

codewriter
12-15-2006, 02:22 PM
Originally posted by sysint
or a web based licensing system whereby the manufacturer tracks my every move. (also not inexpensive)

If your talking about AX, your misinformed.

qtip
12-15-2006, 02:49 PM
Here he goes again!!! http://www.jeepforum.com/forum/images/smilies/popcorn.gif

sysint
12-15-2006, 03:51 PM
Yea. I agree. It's fascinating to ask the simplest question and then get responses asking why it's necessary rather than simply say "NO" or "Can't".

Code - Anytime a manufacturer takes down licensing information there is a database created... whether or not they use it initially.

codewriter
12-15-2006, 04:00 PM
Not sure I follow you on that sys

I buy 10 jaces with the basic license, I then need to install 4 of them on one job. I only need one to be licensed with "User Interface", so I call them up, pay the fee to have the licensed changed on one of them to allow UI, and thats it. I give them the serial number of the jace of course, otherwise the license would not work. However, they still don't have a clue as to where its physically installed or anything. I don't see how this could be accomplished any other way?

control$
12-15-2006, 04:04 PM
Sysint--breath in...breath out.
Actually it turned out to be (2) Petra's.

Ok Sysint your a lon lover. I've worked years with the dark side too.
With bacnet you don't need a third party binding tool to bind Bacnet points,and don't need it for modbus either. At the program level I point I simple write the address and the point of the device I need to talk to.
Examples:
I need the outdoor air temp from a Carrier RTU-1 "bacnet://1/AV:3". Now I have the outdoor air at my VAV box.
Or I need sat at the vav box. "bacnet://23/AV:1".

Now I have both OAT and SAT at the vav box all on the same bus.
Guess it's magic!

sysint
12-15-2006, 04:21 PM
"I realize that if a supervisory controller fails then the data sharing stops, until it is fixed. "

I didn't make that statement... you guys got to get on the same page....

Anyway, yep I like Lontalk. Extremely effective. If there was a bacnet equivalent, I'd like that too. There's not an equivalent.

asdf;ljk
12-15-2006, 05:10 PM
Blah. Blah. Blah. I can do all that with available Lonworks devices and still be peer to peer.


Yeah? I bet you need another device other than the VAV box controller to serve up a Web UI and do system wide date archiving, etc. Whether or not that device is a peer to the VAV box controller or its parent, you still need it.


If you are stating that BACnet is inferior to Lon because you think that the protocol does not support peer-to-peer networking, then you are simply wrong.

You asked for real-life examples and I'm telling you that I don't know of any. The reason is not because it cannot be done. The reason is that there are simply not very many HVAC applications which would require such an architecture.

sysint
12-15-2006, 05:54 PM
First of all get off the sauce and read your very own posts:

I don't have to pay credits to use a Supervisory controller. And I can use it to do other things like serve up a web-based UI, do scheduling, do system wide interlocks and control strategies, store data, integrate to legacy protocols, etc.

So I answered - I can do all that with existing Lonworks controllers and still be peer to peer. With bacnet you would now be hierarchal. Distinct difference. Important difference to a customer.

If you are stating that BACnet is inferior to Lon because you think that the protocol does not support peer-to-peer networking, then you are simply wrong.

No. Just one of the many reasons bacnet is inferior to LON. Especially in fieldbus applications. And, you are right, bacnet really doesn't support peer to peer networking.

You asked for real-life examples and I'm telling you that I don't know of any. The reason is not because it cannot be done. The reason is that there are simply not very many HVAC applications which would require such an architecture.
Another classic non-response. Who CAN do it even if it's not required? And, BTW, it's required quite a bit IF you can actually DO IT. Quite flexible. I simply said two VAV boxes because most bacnetter manufacturers simply make HVAC devices. I'm trying to keep it simple for you.

It's like saying you have a NASCAR and since it only turns left you are going to not make it so it can turn right....

The option should be there whether you utilize it or not. Any well thought out protocol would have that covered.

asdf;ljk
12-15-2006, 07:05 PM
Prior to you calling me a drunk, I asked a simple question: Why is peer-to-peer networking important in a commercial HVAC control application? I'm not trying to pigeon hole you into a response. I am seriously interested in knowing what applications would benefit from this. That was the intent of my original post.

sysint
12-15-2006, 08:31 PM
I'm calling you out to pay attention to the things you type.

Retrofit.

Sharing VAV zones in a large space.
Integrating a smart switch with a VAV box.
Integrating an access control point with a VAV box.
Integrating a VAV box or radiant cooling zone with window sensors.
I/O expansion (remote over network)

"It's nice to be able to....share PID's, CO2 sensors, temp sensors, temp occupancy commands, occupancy commands, setpoints, the list goes on and on." This...

Doing any of these things with products from multiple vendors.

mackinaw
12-15-2006, 09:31 PM
"Why is peer-to-peer networking important in a commercial HVAC control application?"

To share information directly between devices without the need for a supervisory controller. Plenty of examples have been listed.

Once you've had the ability to share information this way...you will feel restricted when peer to peer is not available. You really have to "do it" to appreciated it.

codewriter
12-15-2006, 11:02 PM
Originally posted by gmha9x
Each BACnet device supports different services. Some may be able to initiate ReadProperty, others may not. The device profile that a VAV should conform to does not mandate that it must initiate ReadProperty, but that does not mean that some manufacturers have not implemented this functionality.

So much for the trashrae standards

leaflying
12-16-2006, 01:31 AM
I know at least one manufacturer provides peer-to-peer VAV controllers and am 99% confident that there are more than 2 manufacturers.

Both Bacnet and Lon have something I like and I don't like. There is no perfect system.

MS/TP to me is a bad designed low-end protocal, BACnet scientists expected ARCnet to fly at the earlier stage but engineers just like 2-wire network. Unfortnately, a protocal designed for 5% of usage is forced to take 95% of the installed systems.


Originally posted by sysint

Give me two manufacturers names that their VAV boxes that can communicate peer-to-peer without mapping through some form of a GC. Just a network of 2 VAV's and no other hardware or software. -TIA.

[Edited by leaflying on 12-16-2006 at 01:37 AM]

leaflying
12-16-2006, 01:36 AM
I like most part of Lonworks, but Lonworks scientists also designed a massy SNVT system (the existing SNVT types, not the way it works). And credit system is more Wall Street friendly than user friendly.

alerguy
12-16-2006, 02:32 AM
The latest Alerton field controllers support peer to peer communications - I have used this feature when 2 controllers are needed to control 1 piece of equipment etc.

dapper
12-16-2006, 09:17 AM
Not to belabor this too much more but lets get to the heart of the matter.

Mr.Customer has an Alerton system with 2 VAVs working away as a peer-to-peer network with Alerton network management sotware. Today, Mr.Customer and Mr.Alerton have a spat and Mr.Alerton gets the boot. Mr.Customer now hires Mr.Andover to service this two VAV system. What happens if one VAV fails?

Can Mr.Andover install an Andover VAV controller and use the existing software to configure and intergrate it into this peer-to-peer network?

My understanding is that Mr.Customer has two choices. Rip out both VAVs and software and install all new, or call back Mr.Andover, grab ankles and take a deep breath. Either way, the result is the same.

If I'm wrong, then by all means let me know. I am currently looking for a BACnet line to use in such situations but so far any BACnet manufacturer that we spoke with starts the conversation with, 'Bend over and relax, this won't hurt a bit'

alerguy
12-16-2006, 10:06 AM
Never tried it, but I don't see why Mr Andover could not install his VAV controller into Mr Alerton's peer to peer network(providing his controller supports peer to peer). Of course he cannot use Mr Alerton's software to configure/program his controller but he could use his own software. Mr Customer always has a 3rd option if he has a spat with Mr Alerton - use a differant Alerton contractor. If Mr Customer has a problem with the Alerton product, then ripping out Alerton and replacing with Andover should be welcomed.

dapper
12-16-2006, 10:37 AM
If you ever see this done, be sure to let us know.
On the software, I understand that Mr.Andover would need to 'configure' the controller with his software but whose software would be needed to 'bind' the two controllers, or could either be used?

As far as getting 'another' contractor goes, that is generally not that practical. Around here both Andover and Alerton territories are well protected and the factory keeps it that way. I know of only one case where a large manufacturer called one of those factories and said 'We want your product but not your local rep'. In that case they allowed an out of town rep to do the installation and service at a large facility. The second rep is within a hour or so away. Not too bad. In most cases that 'alternate' rep is a few hours away and the travel charges will kill you. Cheaper to rip out the system.

leaflying
12-16-2006, 10:49 AM
In this case, no common "BACnet network system" software is needed. If the new controller supports "read property", you just figure out which "property" you need in the existing controller and write it in the program. Well, this is the theory, I have to test it a little bit. In the lazy mode now, don't want to test it this year.


Originally posted by dapper
whose software would be needed to 'bind' the two controllers, or could either be used?

sysint
12-16-2006, 10:55 AM
Never tried it, but I don't see why Mr Andover could not install his VAV controller into Mr Alerton's peer to peer network(providing his controller supports peer to peer). Of course he cannot use Mr Alerton's software to configure/program his controller but he could use his own software.

..."Of course". You guys really can't answer the questions so why not just say NO, or CAN'T?

And, with Lonworks I can actually add manufacturer B's vav box and program it from the same software I already am using.... OF COURSE. That's the way Lon works. Peer to Peer.

Another classic bacnetter post where you can't defend the product. Rather than answer straightforward questions and scenarios there is misdirection.

I don't understand why you bacnet people have to misdirect and lie about claims. It's just a protocol, not a religion.

This seems like bacnet brainwashing 101.

EDIT: Another NON-ANSWER In this case, no common "BACnet network system" software is needed. If the new controller supports "read property", you just figure out which "property" you need in the existing controller and write it in the program. Well, this is the theory, I have to test it a little bit. In the lazy mode now, don't want to test it this year.

Sooner or later some "facts" would be nice.

leaflying
12-16-2006, 11:37 AM
Hi sys, don't put too much on my shoulder by quoting my post. I don't want to sacrifice my holidays just to find a BACnet fact earlier for somebody. Although I believe the system I am playing with will do the thing exactly like what I expect.

I am not a Bacneter, I just start to practice it couple month ago for fun. I've done far more Lon systems than Bacnet. So I don't mind if you beat the **** out of BACnet. Just don't understand why you SELECTIVELY reply posts. The fact is BACnet MS/TP protocol supports peer-to-peer although not mandatory. And there ARE real products support it.

What's you comments on my post of messy SNVT system.

alerguy
12-16-2006, 05:01 PM
dapper - you are right, Alerton territories are well protected but when a local rep cannot or will not perform for the customer an outside rep can step in.(with Alertons blessings) I currently have 2 accounts in another reps area. Sometimes I wish they would rip out there systems as one account is 3 hours and the second is 4.5 hours away - Still, it would take quite a few trips to justify replacing an entire system. Forgot to mention option 4 - Customer could attend Alerton school and service his own system.
Sys - I thought "Of course you CANNOT.." was pretty clear. I can rephrase - "NO you CANT.." Can you relax now and try to enjoy the holidays.

sysint
12-17-2006, 09:02 AM
What's you comments on my post of messy SNVT system.

I'm not overly encumbered by SNVT's. I always know what the parameters of the value are and don't have to ask the manufacturer.

Not too long ago a guy was asking how to operate a light switch on the bacnet board (how to present it)--- I was amazed at the replies from the bacnet message board (many and varied) For LON, it's a SNVT_switch --- problem solved every time.

leaflying
12-18-2006, 01:02 AM
Sys, I am very surprised to hear your BACnet story. Isn't the Binary Output object used for lighting point? Same point for overriding and monitoring. If you still have that link, could you show me?

To me, SNVT_switch itself is a bad design, an over-complicated model for a simple 2 state point. The original intention misfired completely. It's amazing there is no binary only SNVT. Say you program a non-application specific controller. What do you use for a fan alarm, I bet you it's not SNVT_alarm or SNVT_hvac_status, maybe still SNVT_switch. How do you override the fan, SNVT_override, SNVT_hvac_overid or SNVT_switch again? How do you report the valve position, SNVT_hvac_status or just SNVT_lev_percent? I know my answer, but what are those sophisicated SNVT doing there?


Originally posted by sysint
I'm not overly encumbered by SNVT's. I always know what the parameters of the value are and don't have to ask the manufacturer.

Not too long ago a guy was asking how to operate a light switch on the bacnet board (how to present it)--- I was amazed at the replies from the bacnet message board (many and varied) For LON, it's a SNVT_switch --- problem solved every time.

sysint
12-18-2006, 08:41 AM
Lighting--- not if you need a value and a state. It was the bacnet message boards --- one guy was from Loytec. Anyway, there is still SNVT_lev_disc if you simply want on/off.

....and yes I typically stay with the same state variable. The manufacturer I like to use typically has Override variables in the functional block so that works well but I understand your points.

I still think the ability to have the data parameters set so you aren't guessing/translating is better.

I think the sophisticated SNVT types are there to save on variables... but with newer LON controllers having thousands of variable capacity you could simply have override values for everything according to it's state. However, in the world of web display, it's more economical to get more information in a single request.

ctrlguy
12-20-2006, 06:52 PM
SNVT_level_disc is described as obsolete in the current snvt.pdf. Use switch, it says.

leaflying
12-20-2006, 07:13 PM
This is the opinion of "Lonworks scientist". SNVT_level_disc is still on the list.

SNVT_level_disc is a multi-stage point (as I said, there is no true binary only SNVT), but lighter than stupid SNVT_switch in terms of binary value transfer. And which SNVT will we use for a simple 3-stage value, SNVT_hvac_emerg?


Originally posted by ctrlguy
SNVT_level_disc is described as obsolete in the current snvt.pdf. Use switch, it says.

sysint
12-21-2006, 07:29 AM
There's always SNVT_state and SNVT_count.
And, you probably don't like this either but there is also 0 and 51201.

Why do you think there isn't a SNVT_binary?

leaflying
12-21-2006, 11:29 AM
I used SNVT_state a lot but it's not for multi-state points.

You are right, I don't like SNVT_count. Why should I use a 2-byte SNVT when 1-byte is more than enough?

SNVT_binary? Where do you see it? R u sure it's not UNVT_binary?

sysint
12-21-2006, 12:08 PM
...you misunderstand me.

I'm asking you why you don't see a SNVT_binary being utilized.

leaflying
12-21-2006, 04:17 PM
A binary value can be transferred anyways by this or that SNVT. I understand that and have used switch, state, lev_disc and others to fullfill the purpose.

But with hundreds of SNVT types invented, there is not a single one EXACT for binary values (for example, just the state part of SNVT_swtch)! That's what I want to say, I can live with the existing SNVT system but I am disappointed.

sysint
12-21-2006, 07:05 PM
"one EXACT for binary values" -- I'm looking for why you see the need for one exact binary SNVT.

Unregistered
12-22-2006, 12:18 PM
Compared to SNVT_switch, "one EXACT for binary values" provides eaiser programming interface and more efficient communications. Why should we take a detour when there is a shortcut?

SNVT_state is pretty good for multiple-binary-value monitoring. So I don't mind if it goes like this:

typedef struct {
signed state0;
signed state1;

signed state15;
} SNVT_binary;
0 .. 1, 0xFF 0 means off, 1 means on, 0xFF means undefined

And actually, for each state, 2-bits, instaed of 1-byte, is enough.

leaflying
12-22-2006, 12:21 PM
Opps, new system accepts anon posts.

Unregistered
12-22-2006, 04:47 PM
But, you can still use 0 and 51201 and get the results you want. It's just that 51201 isn't "1".

I would state that the intent is that you have some more definition..... it's a bacnet issue of mine that you don't necessarily know what a value is without a manual.....

sysint
12-22-2006, 04:48 PM
But, you can still use 0 and 51201 and get the results you want. It's just that 51201 isn't "1".

I would state that the intent is that you have some more definition..... it's a bacnet issue of mine that you don't necessarily know what a value is without a manual..... login issue. ANON.... not a good thing.

leaflying
12-22-2006, 10:07 PM
Yes. With resolution of 0.5 at value part, when state=true and value=100%, you got 100*2*256+1=51201. But that's not the ONLY correct answer. In fact, "state=true and value>0" is the requirement, there are 199 correct answers. That's why I said SNVT_switch is an over-complicated vehicle for binary values.

The "value" part does nothing but
--extra communication (It costs 16 bits. I just need 2 bits. If we don't count packet overhead, the traffic saving is 87.5%!)
--extra calculation (You have to do, at least once for yourself, calculation to know the "TRUE" value to be sent out in programmable controllers)

I can live with it but I just can't help thinking it's stupid. I know what you mean for the bacnet. But I am telling you, I saw bad examples of using SNVT. For example, using SNVT_volt_f, a 4-byte monster, to represent voltage inputs and transfer pressure, CO2 ..., double the traffic, triple the calculation. And I just hate it everytime I deal with it.

codewriter
12-22-2006, 10:40 PM
I must still be way behind here, as I never thought about this topic that leaflying and sys are discussing. I must say leaflying has a good point on the matter though. Personally I have never seen or had a problem, but if you want to get "perfect", I agree it is pretty stupid.