GitHub user splatch added a comment to the discussion: Should we extend PLCValues with a map of Meta-Information?
I think that current way complicates handling of values, because collaboration with drivers will need to take into account this metadata. Any code which is a generic callback for plc read response or subscription callback intended to work across multiple drivers, will need to address it. And since metadata is driver specific and encoded by "string" keys we have no ways to keep this stuff simple. You also propose metadata at value level which means that it can be part of write request, and each of written values individually, as well. I see direction in which you went, however I still question myself if that's the right way. Is this metadata available always within the protocol and needed for decoded value? If so, we definitely need to describe such use cases and make a recommendation for drivers to keep some level of consistency. I know for example that M-Bus (and WM-Bus) have a concept of "tariff" and "register" which are encoded before value, effectively it is a divider between values which have same meaning such "energy consumption" or use registers as past hours, days or months. More over, it is not possible to determine available tariff and registers during discovery phase, cause it is part of regular readout. I think the metadata concept you brought fits there. Similar for OPC UA status codes and timestamps (ie. server timestamp) which might turn to be useful to some use cases. Last thing I can bring is CAN and probably other ethernet level protocols where driver might source hardware timestamp. Such information is not associated with any of the values delivered by encoded message, but all of them, independently of the message itself. This I believe is another level of metadata which do not fit value metadata and will cause confusion. Still, if we bring metadata for values we should be clear how to do it for frames/messages which is above decoded value. While there is no concrete usecase for that yet, I would want to keep awareness/perspective of that case. GitHub link: https://github.com/apache/plc4x/discussions/1086#discussioncomment-6886857 ---- This is an automatically sent email for dev@plc4x.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@plc4x.apache.org
