BACnet | simple Telegraf go plugin

.js

Figured it out. The IP address was correct. But there was another software that starts automatically and runs in the background. It also uses BACNet. As a result the port 47808 was getting used by this software. Wireshark was capturing the communication to the device via this software, since the software has a discovery tool for BACnet devices. BAC0.connect works now.

Please try the following thing inside your virtualenv.

I wouldn't be able to say from this, but could it be the case that you are retrieving/enumerating the objects from the structured-object-list rather than the object-list?

(It's a possibility that the structured-object-list has less objects than the object-list - therefore possibly excluding your Binary-Output objects?)

I get the feeling that the question might still be slight vague/open-ended (- possibly open to interpretation), but if you're talking about exposing some custom (/additional?) objects via BACnet, then to be compliant with a BACnet 'client' - such as the BMS, you'd have to include those objects within the Device's/device-object's 'Object-List' property, so that the BACnet clients would recognise it's availability.

(One day someone could try to be clever - for security reasons and support the Read-Property service for objects without having them available/advertised within the Object-List but 1) it would only work if they were also developing the client too - with knowledge of this, and 2) it would not be compliant with the standard.)

maybe it's just my interpretation of your question, but it seems a little open-ended - so I shall respond in a similar vein - general (& I'll try to keep it short).

First, you need the list of info for targeting each device in-turn; i.e. it might consist of just a IP(v4) address (for the physical device) & the (logical) device's BOIN (BACnet Object Instance Number) - or if the request is been routed/forwarded on by/via a BACnet router/BACnet gateway then maybe also the DNET # & the DADR too.

Then you probably want - for each device/one at a time, to retrieve the first/0-element value of the device's Object-List property - in order to get the number of objects it contains, to allow you to know how many objects are available (including the logical device/device-type object) - that you need to retrieve from it/iterate over; NOTE: in the real world, as much as it's common for the device-type object to be the first one in the list, there's no guarantee it will always be the case.

As much as the BACnet standard started allowing for the retrieval of the Property-List (property) from each & every object, most equipment don't as-yet support it, so you might need your own idea of what properties (/at least the ones of interest to you) that each different object-type supports; probably at the very-very least know which ones/object-types support the Present-Value property & which ones don't.

One ideal would be to have the following mocked facets - as fakes for testing purposes instead of testing against a live/important device (- or at least consider testing against a noddy BACnet enabled Raspberry PI or the harware-based like):

• a mock for your BACnet service
• a mock for the BACnet communication stack
• a mock for your device as a whole (- if you can't write your own one, then maybe even start with the YABE 'Room Control Simulator' as a starting point)

Hope this helps (in some way).

Device instances are mapped in the PlatformDriver by the portion of the topic following devices/ - so in this instance self.topic = 'devices/slipstream_internal/slipstream_hq/29' should be self.topic = 'slipstream_internal/slipstream_hq/29' (this is why you see the KeyError above). It might be worth checking out the original CsvDriverAgent and it's config file to get a better feel for that pattern. Your point topic looks good, given the examples above. Additionally, I strongly recommend that you use vpkg --init to create a new control agent, that way you don't have any relics of the CsvDriverAgent to distract you as you develop. The CsvDriverAgent was created to demonstrate driver communication from the standpoint of the agnet, but it is not a very good basis for an agent as the configuration, and control algorithm are intentionally overly simple and not practical. Additionally, going through the agent creation process start to finish is likely to help you build out a stronger foundation of understanding, both of VOLTTRON Core, but also of your own product. And just to have another reference tool, here's our instructions on BACnet router addressing (what you have here does appear correct, but references are nice!)

If you look at the ./start-volttron.sh script within the volttron repository you will see the line

Just because your client can (supposedly) support segmentation for "Both" directions - transmit & receive, the server/device/AHU doesn't.

So in order to read the full object-list, you have to fallback to looping thru the Object-List array - one element at a time.

Element/array-index 0 of the array (- the first element), contains the count of the number of data elements; for each element that you want to read - including the first one/element, you have to specify the target/desired element/index that you wish to read.