Lean status attributes

[emiltin]

Some status mesages include metadata that should not itself trigger a status message.

For example, when you subscribe to signal group status in a TLC, you want a status update whenever any of the signal groups change state. When that happen, you the current cycle counter should be included. See rsmp-nordic/rsmp_sxl_traffic_lights#21

But you don't want a status message each time just the cycle counter changes, but not the actual signal group status. This is already a problem when the cycle counter changes once per second, but it becomes much worse when we want to include the resolution of the cycle counter.

To support this, I suggest we distinguish between data and metadata in status attributes. Attributes marked as 'meta' should not trigger status updates.

[emiltin]

Instead of marking some attributes in the SXL as metadata, you could choose at subscription time which attribute should trigger an update. More flexible, but also maybe more complex to implement.

[emiltin]

Here's an example of a status subscription message:

{
     "mType": "rSMsg",
     "type": "StatusSubscribe",
     "mId": "d6d97f8b-e9db-4572-8084-70b55e312584",
     "ntsOId": "O+14439=481WA001",
     "xNId": "",
     "cId": "O+14439=481WA001",
     "sS": [
         {
             "sCI": "S0001",
             "n": "signalgroupstatus",
             "uRt": "5",
             "sOc": false
         },{
             "sCI": "S0001",
             "n": "cyclecounter",
             "uRt": "5",
             "sOc": false
         },{
             "sCI": "S0001",
             "n": "basecyclecounter",
             "uRt": "5",
             "sOc": false
         }
     ]
}

As shown, updateRate and sendOnChange are specified for each attribute.

Could we use these two existing flags to indicate that an attribute should only be send when other attributes change?

From https://rsmp-nordic.github.io/rsmp_core/3.2.2/applicability/basic_structure.html#structure-for-a-status-subscription-request-message:

It is not valid to set updateRate=0 and sendOnChange=false since it means that no subscription updates will be sent

A possibility would be change that definition to something like:

If updateRate=0 and sendOnChange=false then the attribute is considered metadata and will be send when another non-metadata attribute changes.

For example, when you subscribe to S0001, the cyclecounter could be subscribed to as metadata, so you only get a message when the signalgroupstatus attribute change, which will then include the cyclecounter:.

{
     "mType": "rSMsg",
     "type": "StatusSubscribe",
     "mId": "d6d97f8b-e9db-4572-8084-70b55e312584",
     "ntsOId": "O+14439=481WA001",
     "xNId": "",
     "cId": "O+14439=481WA001",
     "sS": [
         {
             "sCI": "S0001",
             "n": "signalgroupstatus",
             "uRt": "0",
             "sOc": true
         },{
             "sCI": "S0001",
             "n": "cyclecounter",
             "uRt": "0",
             "sOc": false
         }
     ]
}

The benefit of this would be:

• no fields added or removed, which avoids now flag combinations to consider)
• no new types introduces (still string for uRt and boolean for sOc)

[emiltin]

Added a PR #197 with the above idea of using uRt=0 and sOc=false to indicate lazy lean updates.

[emiltin]

I suggest using the word "lean" to describe attributes that don't trigger updates, but are send when other attributes trigger an update.