Enhance Omnicomm to make it easier for protocols to work with sub-remote status indicator.

Request that either sub-remote status indicator be enhanced, or, at least that Omnicomm provide protocols the information to know which points are status indicators and need to be polled first.

Ideally the sub-remote status indicator would postpone processing data values until the end of an RTU poll cycle, but understand that is likely difficult.

Alternatively, could Omnicomm record whether the point is a data quality used to trigger bad sub-remote status in the hash array that is presented to the protocol? Alternatively, each protocol needs to lock points again in order to determine if the point is a status indicator. This is inefficient.

To facilitate common configuration, it would be best if there was a standard way for protocol to intereact with the sub-remote status indicator feature.

It is important that the protocol do this so as not to create an improper situational awareness of the operator who is relying on the sub-remote status indicate to be correct all of the time.

Having this done in omnicomm or elsewhere in the platform reduces the complexity of the individual protocol drivers.