Hi Lukasz, Having the timestamps in a completely separate API separated from the normal read-requests or subscriptions? I think I’m not quite understanding you.
You could whip up a PR where you simply change the interfaces (doesn’t have to compile) … guess dissussing it there makes more sense. Chris Von: Łukasz Dywicki <l...@code-house.org> Datum: Mittwoch, 3. Juli 2024 um 14:59 An: dev@plc4x.apache.org <dev@plc4x.apache.org> Betreff: Re: AW: [DISCUSS] Metadata for responses / source time Hey Chris, I propose to introduce new part in API used for read/write/subscribe responses (or events). It is not discovery, its runtime information. You are right that usually timestamp is set for entire message. This is the case for CAN transport. However once we start playing with aggregation (optimizers/decorators) it is not a case any more. I think that in case of OPC UA server we can get different timestamps for every field (scalar value), as their sample time can be different. Best, Łukasz On 3.07.2024 07:58, Christofer Dutz wrote: > Thinking more about it, I do think that this makes more sense for protocols > such as KNX, where there’s loads of metadata alongside the actual values. > Currently we simply return a PLCStruct for that case, but having attributes > would be nicer as one could concentrate on the actual “value”. > I know in general a “per-value” timestamp is rather seldom under the > industrial protocols as usually it’s on a per-message basis. > > However, we sometimes break up large requests into multiple ones. So, we > technically don’t have a timestamp per request but per-group of values. > Because of this I would argue, that only a per-value is really reliable. > > Chris > > > Von: Christofer Dutz <christofer.d...@c-ware.de> > Datum: Mittwoch, 3. Juli 2024 um 07:03 > An: dev@plc4x.apache.org <dev@plc4x.apache.org> > Betreff: Re: [DISCUSS] Metadata for responses / source time > You propose something like the "attributes" on discovery items, where its > generally a map of plc values added? Or something more integrated into the > api? > > Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> > ________________________________ > From: Łukasz Dywicki <l...@code-house.org> > Sent: Tuesday, July 2, 2024 11:06:13 PM > To: dev@plc4x.apache.org <dev@plc4x.apache.org> > Subject: [DISCUSS] Metadata for responses / source time > > Dear PLC4X followers, > I would like to bring back 3 year old discussion we had on stuff related > to "source time", but not only: > https://lists.apache.org/thread/r3g4y6p7kst7z5bdpmccd8538h3hl80f > The "metadata" term was coined by Ben, kudos for him! :) > > For these who missed earlier topic - it was an inquiry of how to acquire > source time for plc values returned by our API. Because this kind of > features is not always present in protocols at the time it was brought, > it was heavily influenced by OPC-UA. For OPC-UA it comes from > application layer, thus we can (relatively easily) propagate it from > driver to our API callers. > Over time we got another case. We have a transport which can do similar > - CAN, if used with socketcan, can provide message level metadata. The > most common metadata there is hardware or software level timestamp of > message. First comes from microcontroller which deals with CAN > transceiver, second one is (AFAIK) assumed at driver level. > > Reason why I bring this topic back is plain - we miss API for "source > time", and I would like to bring implement it. I know this idea got > stuck before because of driver level differences and multiple languages. > > To be clear - I intend to bring this only for java, because this is > where we have functioning OPC-UA and CAN drivers. Other languages, as > far I know, do not have these, hence benefit of new API there is > non-existent. > This topic was partially touched when we meet in Frankfurt to discuss > 1.0 and expected/speculated API changes we are aware of. Given that we > are still before 1.0 release, and new features interesting for 1.0 (i.e. > subscription emulation) might benefit from it I would personally > prioritize this work over other. > > Given that we might have metadata for two levels - entire response as > well as individual field/event I wish to provide metadata API for both. > Primary objective for both places is making it possible to enumerate all > available metadata keys (if any), or lookup by predefined key (i.e. > timestamp), as well as let drivers easily define their own metadata keys. > > Let me know if you have any notes, intent or suggestions for this API. > > Cheers, > Łukasz >
