Hi, If we were to let the server control a minimum rate for change of state subscriptions then we could overload the client.
I think allowing a value of 0 would be a good idea in case you really do want to capture every change even if it is incredibly fast, but still defaulting to 1s. Ben On Mon, Mar 8, 2021 at 5:20 AM Christofer Dutz <[email protected]> wrote: > Hi all, > > yeah ... I wanted to say something to that too: > > Change of State shouldn't have a sampling interval (Perhaps a min interval > to prevent flooding an application with too many updates) > The use case seems a bit like a polling use case and we have a separate > set of subscription properties for that. For polling, there should be a > sampling interval and that's even included in the API. > > If we are "simulating" a change of state functionality on a protocol, that > doesn't support this (like S7, Modbus, ...) we should have a generic > property to control this sampling interval throughout all PLC4X drivers. As > I recall we currently don't have this subscription simulation layer ... not > yet ... > > Chris > > > -----Ursprüngliche Nachricht----- > Von: Łukasz Dywicki <[email protected]> > Gesendet: Montag, 8. März 2021 11:08 > An: [email protected] > Betreff: Re: [DISCUSS] Minimum sampling interval on change of state > subscription > > Hey Ben, > I began writing this answer shortly after you sent your mail but > eventually left it for a day or two to thing it through. > Looking at API I believe we have three major cases: > - polling/push interval > - change of value > - every value > > Looking at above change of value should not require any interval cause it > should be determined by device we subscribe to. It knows for sure that > value changed and should push an update to us. Same applies to event field. > For cases where we can specify update interval the first (cyclic) option > is intended. I know very little of OPC UA so above might be not entirely > valid in context of it. The real question is shall we fit OPC into our API > or our API into OPC. > > Looking closer at cyclic subscriptions we don't have a clear indication of > who does the time handling. Is it device (or server) who post updates back > to us at given frequency? Or we poll it given interval? How our API caller > will know who controls time? > > To sum all this - I would say that case you have seems to fit more into > cyclic subscription than change of state. > > Best, > Łukasz > > > On 06.03.2021 13:06, Ben Hutcheson wrote: > > Looking at the change of state subscription interface there's no > > explanation or way to modify the Duration parameter which defaults to > > one second. This is used in OPC UA as a minimum reporting time so will > > never report back faster than 1 second. > > > > What's everyone's thoughts on adding this as an optional parameter? > > > > I thought about changing the default but I think 1 second is a good > > value for it. > > I also think an absolute minimum value should be allowed of 5 or 10ms. > > > > * Adds a new field to the to be constructed request which should be > > updated as soon as > > * a value changes in the PLC. > > * > > * @param name alias of the field. > > * @param fieldQuery field query string for accessing the field. > > * @return builder. > > */ > > PlcSubscriptionRequest.Builder addChangeOfStateField(String name, > > String fieldQuery); > > >
