Status subscriptions and updates on change+interval

[otterdahl]

We've observed that sometimes the supervision system doesn't show the recent status of the TLC correctly.

Upon investigating the cause for this issue we have found that in some situations the supervision system detects a communication disruption but the TLC hasn't. This may cause the supervision system to show a communication disruption as the last known status of the TLC, but the RSMP connection can be restored without the need for a new RSMP handshake.

Due to the fact that many StatusSubscribes only updates on change - and some statuses changes very seldomly - may cause the supervision system to show incorrect or missing status for a TLC during a long time.

Currently StatusSubscribe supports update on change (uRt=0) or at a given interval (uRt>0).

I think that StatusSubscribe should be updated to support update on change and update on given interval at the same time. It doesn't need update on interval if it has changed since last interval.

This feature is present in other similar protocols.

[emiltin]

Suggestion: add a boolean field 'sendOnChange'.

uRt=0: send on change
sendOnChange=true: send on change
uRt=60: update every 60 sec
uRt=60,sendOnChange=true: send on changes, but also every 60 second if no change
uRt=60,sendOnChange=false: ?
uRt=0, sendOnChange=false: ?

[emiltin]

In a perfect world, this would not be needed, and we could rely on interval=0. But in reality, special situations can arise that cause a status message to be missed. Other protocols include similar functionality.

[emiltin]

It might be important to know if a status mesage was sent due to an actual change, or just due to the fixed interval.

[otterdahl]

Suggestion added with commit c8af9c3

[otterdahl]

Added in 3.1.5