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.
  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. Migration from interface to connector

    Would like a way to migrate from interface to connector as easily as possible.

    7 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  BACnet  ·  Flag idea as inappropriate…  ·  Admin →
  2. 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.

    6 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  BACnet  ·  Flag idea as inappropriate…  ·  Admin →
  3. 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

    4 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  BACnet  ·  Flag idea as inappropriate…  ·  Admin →
  4. 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
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  BACnet  ·  Flag idea as inappropriate…  ·  Admin →
  5. 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.

    3 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  BACnet  ·  Flag idea as inappropriate…  ·  Admin →
  6. 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
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  BACnet  ·  Flag idea as inappropriate…  ·  Admin →
  7. 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.

    2 votes
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  BACnet  ·  Flag idea as inappropriate…  ·  Admin →
  8. 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…

    1 vote
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  BACnet  ·  Flag idea as inappropriate…  ·  Admin →
  9. 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
    Sign in Sign in with OSIsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  BACnet  ·  Flag idea as inappropriate…  ·  Admin →
  • Don't see your idea?

Feedback and Knowledge Base

Posted ideas will have one of the following statuses.
Full definition of these statuses can be found on the Home Page.
No status
NEEDS MORE DISCUSSION
RESEARCHING/EVALUATING
DECLINED
PLANNED
STARTED/IN DEVELOPMENT
IN BETA
COMPLETED