Send Data(Server) and Receive Data(Client)

[Vincent1218]

Hi, I'm new to BACnet and BACpypes.

Can I use BACpypes to simulate a BACnet Client device and send data (eg: random integer) to another client to be received?

The data might also be able to be received by other BACnet explorer that can be downloaded online.

[JoelBender]

Yes, you can send data (as a client) to another device (as a server) using an application like the sample RecurringWriteProperty.py application which writes a value at a regular interval and changing this to write a random value is very simple.

You can also create a server that regularly changes an object value to some random number and supports change-of-value (COV) notifications to clients that subscribe to the objects, like the COVServer.py sample. So in that sense the server is sending data as updates and it is up to the client to understand what to do with the new values, like the COVClient.py sample.

[Vincent1218]

Thank you for your quick reply!

But I have a question, shouldn't the device that sends data be a "server" and another application that can receive and check the data be a "client".

I'm currently running ReadPropertyMultipleServer.py in my machine. And I'm able to use a BACnet explorer downloaded online to connect and showing random value it sends, or perhaps , the value is only write to the device, and the explorer is able to get the value.(Please clarify if I'm wrong)

The question I have is how can I run a client in my machine and get the data (send by the machine)/ (assigned to the machine) running ReadPropertyMultipleServer.py.

I'm sorry if I mentioned anything wrong, appreciate your help!

[JoelBender]

I agree that this can be confusing. BACnet is a peer-to-peer protocol where devices are both clients and servers, and every once in a while they are "both" at the same time. A client is something that initiates a request, like a ReadProperty Request (see Clause 15.5) and sent to a server, that will send back a response that is a positive acknowledgement (every thing is fine, here is your data), or a negative acknowledgement (something is wrong with the request (error), the server can't do that (reject), something catastrophic happened (abort)).

The ReadPropertyServer.py application presents itself as a device that is a server because it's designed to not initiate any requests, it just sits there waiting for requests from other clients. The ReadProperty.py application is also a device, and it will respond as a server to requests from other devices as clients, it is just a very limited server containing only one object, its Device Object. You can see this by running the application on one machine and your explorer on another.

For an interesting example, let's say there are three devices on the network, X, Y, and Z. Assume X sends a request for the average zone temperature to Y which is calculated by Y "on the fly". In this request, Y is the server. Now Y sends out a request for zone temperatures to Z, turning Y into a client in this context. Z (as a server) responds to Y (as the client) with the values, Y calculates the average and sends the result back to X (as its client).

Supporting change-of-value is another interesting case. If X is the client interested in updates for values from Y without "polling" or reading the value at a regular interval, it sends a subscription request to Y with the object and property it is interested in. Y (as a server) sends the positive acknowledgement back to X. Now when Y has a change and recognizes that X needs a notification, it will send a COVNotification Request to X with the data, and X responds with a simple positive acknowledgement, "thank you very much." So Y remains a kind of server, it's the device that "has the data," but in the context of sending out notifications it becomes a kind of client. In this situation most of the time people gloss over the context switch between client and server, being more interested in the data flow part of the conversation rather than these details. Application code is more strict, as it has to be in a library that is going to be used for all kinds of peer devices.