PI Connectors
Welcome to the
PI Connectors feedback page!
We created this forum to hear your ideas, feature suggestions and feedback on PI Connectors. Please suggest your most important features and design change ideas on this site, and vote for your favorite ideas.
Please note that your ideas and comments posted here are visible to all other users.
- For bugs, please open a case with OSIsoft Tech Support through myOSIsoft Customer Portal (https://my.osisoft.com) instead of sharing them on this site.
- For documentation feedback and bugs, please report to documentation@osisoft.com instead of sharing them on this site.
-
Add failover capability for the BACnet Connector.
Failover similar to the UFO available for UNIint interfaces. Warm failover would be sufficient, although I'm sure there are some who would like cold and hot as well.
7 votes -
Migration from interface to connector
Would like a way to migrate from interface to connector as easily as possible.
7 votes -
trend log objects (BACnet object type 20) available from the connector
BACnet trendlog object present the opportunity to buffer at the edge where the data is collected and to gracefully recover from comms outages if data collection has been impacted.
I would suspect the trendlog object could be handled similarly to the OPC connector HDA approach
5 votes -
Program objects (BACnet object type 16) also bought through by the connector
The program object description is often very useful to understand what the various object instances relate to. At our site the description holds the Asset designation and that would allow correct assignment of the analogue and binary object instances to the correct asset.
5 votes -
Make the connector a BACnet Device (get a BTL listing)
Some devices can only send COV notifications to other BACnet devices. Since the Connector is not a device and does not respond to who-is messages (and does not listen on port 47808), the connector is unable to utilize COV subscriptions for these devices.
4 votes -
Log device information when the Connector receives errors from a device
Currently the Connector logs when it receives errors, but does not print information that can be used to determine which device is reporting the errors.
We currently need to perform a wireshark trace to look at the individual packets to determine which devices are sending errors.
4 votes -
Suppress the creation of "Status Flag" PI Points
The end-user would like to suppress the creation of the "Status Flag" PI Points, as they wish to keep their point count to a minimum due to the license-enforced point limit.
3 votes -
Distribute-Broadcast-To-Network broadcast for Discovery Tool and Connector
When running the discovery tool from a subnet with no BBMD to query BACnet devices on a separate subnet, it seems like the auto discovery tool is seen as a ‘foreign device’, so the devices do not respond correctly.
When analyzing a Wireshark trace, the discovery tool sends an ‘Original -Broadcast-NPDU’ Who-Is request to the BBMD on the other network, because it is seen as a foreign device, the request is not forwarded onto the sub-devices by the BBMD on this separate subnet. We can see that no I-am requests are sent back to the discovery tool.
As the discovery…
2 votes -
Auto discovery on a separate subnet (as foreign device)
When running the discovery tool from a subnet separate from the BBMD and BACnet devices, it seems like the auto discovery tool is seem as a ‘foreign device’, so the devices do not respond correctly. There is no BBMD on the subnet the connector is on.
When analyzing a Wireshark trace, the discovery tool sends an ‘Original -Broadcast-NPDU’ Who-Is request to the BBMD on the other network, because it is seen as a foreign device, the request is not forwarded onto the sub-devices by the BBMD on this separate subnet. We can see that no I-am requests are sent back…
1 vote
- Don't see your idea?