Data Filtering in the Adapters allows you to define what change in data must occur for the data to pass filtering and be egressed by the Adapter.

It would also be useful to employ filtering for data quality applications - such as if the value changes by too much it is considered invalid and don't pass filtering to be egressed.

This would allow the adapter to filter spikes in the data, incorrectly collected values, impossible values, etc. before they even get sent to PI.

As a specific use case for this is a customer who is monitoring pipe wall thickness erosion - which would never increase. If the value increased above a certain threshold they can be certain it is a mismeasurement and should be discarded.

As a system admin I would like to send mqtt messages from multiple devices to a single topic on an mqtt broker. Each message would contain data for the device along with a field to say which device the data has come from. Then I would like to use the mqtt adapter to read in the messages from this topic and to split the data into different streams depending on which device is referenced in the message. This is preferable to sending to individual topics per device since it would require less configuration on the mqtt broker since there could be 1000s of devices. In addition, I am working with a vendor that sends their data in this format.

In our process we wish to send a different set of data to different PI environments. For instance we would like all data to egress to the PROD environment while only egress a subset of data to the DEV environment, in which we don't need all the data.

By removing a PItoPI link between PROD and DEV, this would largely reduce the complexity of the setup (especially when you have > 50 sites) while keeping a lower more manageable volume of data for development purposes.

Currently when we setup PI Adapters, the OmfEgress component is configured for all instances on the host and sends all the data to all configured egress endpoints. We would like to see this OmfEgress component configured as part of the instance component instead.

We make use of strong naming convention for all our tags, using sets of prefixes/sufixes to properly position our PI tags in AF hierarchies.

We are making use of the PI Adapter against the PI WebAPI endpoint. Now with the PI Adapter health & diagnostic PI tags that are auto-created when 'EnableDiagnostics' is set to "True" in the auto-created AF DB for this purpose, the auto-naming of these PI tags does not permit a configuration of the naming using a set of prefixes that would help us locate better in our data landscape the position of the PI Adapter.

What we need is to be able to in further PI System Monitoring AF models to be able to re-use these PI Adapter health & diagnostic tags efficiently using substitution params in order to easily create analytics and visualization against AF Elem templates to monitor the whole PI Adapter fleet (potentially hundreds).

Without this prefix we have to map each PI tags manually to the correct AF attribute for our PSM purposes, which is absolutely against our good PI practice in terms of creation and maintenance.

We make use of strong naming convention for all our tags, using sets of prefixes/sufixes to properly position our PI tags in AF hierarchies.

We are making use of the PI Adapter against the PI WebAPI endpoint. Now with the PI Adapter health & diagnostic PI tags that are auto-created when 'EnableDiagnostics' is set to "True" in the auto-created AF DB for this purpose, the auto-naming of these PI tags does not permit a configuration of the naming using a set of prefixes that would help us locate better in our data landscape the position of the PI Adapter.

What we need is to be able to in further PI System Monitoring AF models to be able to re-use these PI Adapter health & diagnostic tags efficiently using substitution params in order to easily create analytics and visualization against AF Elem templates to monitor the whole PI Adapter fleet (potentially hundreds).

Without this prefix we have to map each PI tags manually to the correct AF attribute for our PSM purposes, which is absolutely against our good PI practice in terms of creation and maintenance.

When reading from a generic MQTT broker, we currently need to specify explicitly each key value pairs we want to collect inside the data selection json configuration file. This prevents us from really being agile at the time of the initial setup and for each new information we want to collect, as we need to explicitly define the information manually into the Adapter.

We would like the PI Adapter for (generic) MQTT to be able to capture automatically exposed key value pairs in the MQTT broker following a wildcard pattern. For instance take this example payload:
{
"EquipABC.Location": "0020121047111948",
"EquipABC.Status": "1",
"EquipABC.Flow": "3.14",
"TimeStamp": "2021-02-16T12:28:58.078Z"
}
We would like the PI Adapter to automatically capture [DataStream]:[Value] into the corresponding container using the given timestamp, like for instance the UFL interface/connector can be configured when parsing a file or json payload.