+1 for Łukasz‘s metadata approach, it would avoid having to create duplicate PLcValue classes and give us a lot of flexibility in the future.
On Mon, Mar 8, 2021 at 5:14 AM Christofer Dutz <[email protected]> wrote: > Hi all, > > sorry for being late to the party ... KNX is currently consuming all my > cycles. > Just wanted to add my thoughts to the discussion. > > Initially I thought about adding this sort of information to the API, but > then I thought that we have so little protocols supporting this sort of > concept that blowing up every PLCValue with this time information just > would waste CPU time and Memory. > > When it comes to simulating subscriptions by polling in the background, I > thought it would be a valid solution to provide a default age a value can > have in the cache and to make it possible to override this in the > connection string options. If a value is too old, a return code of: > STALE_DATA could be returned. > > Also, we do have an option of adding an additional set of PlcValue types. > If a driver supports this quality-of-service type of data, we could return > special versions of PlcValues, that have these properties? > > This way we don't have to waste the CPU time and Memory for protocols that > don't support this concept (We could even implement the methods on the > default PlvValues to simply return some constants to the PlcValues all have > the same API. > > Chris > > > -----Ursprüngliche Nachricht----- > Von: Łukasz Dywicki <[email protected]> > Gesendet: Montag, 8. März 2021 10:43 > An: [email protected] > Betreff: Re: Source Time of PLC Value? > > Looking at issue we could utilize marker interfaces. > At least in Java we could define Qualified and Timestamped types. > > Yet looking at present state of API we are unlikely to make each and every > PlcValue in each and every variant (qualified and timestamped, timestamped, > qualified). It would force quite a lot of wrapping. > Safest option I see is to extend subscription/response API with additional > method to retrieve all markers. For most of drivers it would return just an > empty set. It leaves us also an open door for future drivers (or devices) > to ship additional piece of metadata which does not fit into present API. > > Best, > Łukasz > > > On 08.03.2021 04:30, Otto Fowler wrote: > > So, maybe the extension is timestamp *and* timestamp source. > > > > uint64_t timestamp; > > typedef enum { > > /* timestamp was generated by the source device */ > > SOURCE, > > /* timestamp was generated by plc4x on receiving */ > > GENERATED, > > } TimestampQuality; > > > > > > > >> On Mar 5, 2021, at 18:04, Ben Hutcheson <[email protected]> wrote: > >> > >> We do have some error codes, but it would just need to be extended a > >> bit. I don't think we have one for BAD (we still receive data but the > >> source has marked it bad). > >> > >> Timestamps I think are definitely a good idea, especially if we > >> eventually DNP3. > >> > >> On Fri, Mar 5, 2021 at 5:39 PM Łukasz Dywicki <[email protected]> > wrote: > >> > >>> You have response code for each individual field which allows you to > >>> determine state (OK, REMOTE_ERROR etc.). Same information should be > >>> available also for subscriptions. > >>> > >>> Best, > >>> Łukasz > >>> > >>> On 05.03.2021 21:04, Andreas Vogler wrote: > >>>> Ah, forgot: and is there a status available? Valid/invalid/good/bad > >>> indicator of a plc value? > >>>> > >>>>> On 05.03.2021, at 21:02, Andreas Vogler > >>>>> <[email protected]> > >>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> How can I get the source time of a PlcValue? > >>>>> > >>>>> a) from a subscription PlcSubscriptionEvent > >>>>> b) from a read request PlcReadResponse > >>>>> > >>>>> Best regards, > >>>>> Andreas > >>>> > >>> > > >
