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); >
