Hi Dojo - while documenting future integration scenarios, I've come come across a device exposing data over the BACnet protocol [UDP port 47808 - ASHAE Standard 135-2024 (SSPC 135) / https://www.iso.org/standard/92057.html ]
Would this be something for which a "Generic BACnet" DM protocol could be created, rather than a device-specific driver?
This standard is not an IETF one, it has some similarity to SNMP - but ISO standardized.
This is how I'm currently mapping the concepts around it:
SNMP: Agent + MIB → OIDs → GET/SET
BACnet: Device + PICS(*)/object model → Objects/Properties → Read/WriteProperty
(*)PICS stands for:
Protocol Implementation Conformance Statement (seems similar to a MIB to me)
It's essentially a manufacturer's declaration of what BACnet functionality their device implements
Given that a Generic SNMP was implemented in the past, I'm just looking for advice if an attempt for a Generic BACnet could be viable - anyone aware of any BACnet integrations already done in DM?
Thanks
Hi Alberto,
Thank you for your question.
We have implemented BACnet communication in DataMiner connectors before, so we can confirm that BACnet-based integrations are technically feasible and that successful polling of BACnet devices can be achieved.
Regarding a generic BACnet connector, the approach is certainly conceivable, similar to how a Generic SNMP connector exists today. However, from a user experience and maintainability perspective, we generally recommend implementing connectors around the functional intent of the device or solution being integrated.
A fully generic approach typically lacks the domain-specific context that enables richer visualisation, alarm handling, and operational workflows. This is comparable to generic SNMP integrations, where alarms and data are available, but their meaning and context are often less clear to operators.
We'll reach out to discuss your specific scenario and explore the most practical way forward.