@jeremyh said:
If the point itself is set to log 'log when value changes', would this mean that - even if the publisher is set to 'all updates' - the change is only sent when the point value itself changes?
And would it follow then that if the receiving/listening point is set to 'log all data', it would only log when a change is received?
Not quite. If a point is set to 'log on change' it will still receiving values that will go into the cache and cause a certain type of update event. If a publisher is set to publish 'all updates' it will send this new value in the cache regardless of the points' logging settings. So, if the receiving point were set to log all data, it would insert the duplicate values into the database. This situation will cause problems with the historical sync.
@jeremyh said:
My goals in this exercise are to:
- Minimise unnecessary network traffic (so I only want to send updates on point value changes)
- Ensure that every time the state changes, it is logged in the listening Mango (using historical syncing)
- Reduce point value 'clutter'; I don't want to fill up the database with unnecessary repeating values, only the changing value.
With that in mind, what configuration would you suggest, that will not introduce historical syncing problems?
It sounds like you're going to want to set all values to log on change and the publisher to publish 'Changes Only'
You could get by with the receiving point logging all data if the publisher only publishes changes and not encounter problems, but there is no benefit to having the logging properties different between the instances, with perhaps that exception that interval logging of a receiving point doesn't function ideally in situations of network disconnection.
In the second goal, you reference the historical syncing, but I read the first part of that as concerning the live data. That might need to be expanded upon...