Do we need a status subscription mechanism?

[emiltin]

Some thoughts in https://github.com/orgs/rsmp-nordic/discussions/112

[emiltin]

It's a balance between performance and simplicity.

Always sending everything would be simple, but would probably use excessive bandwidth and result in unacceptable performance.

On the other hand, allowing each supervisor to select arbitrary update intervals, etc. might be complex to implement.

So we probably need to find simple solutions to avoid sending data that's not needed

Aggregation periods In real world use, standard aggregation periods like second, minute, hour and days are always used. We've never seen use og e.g. 63s. We would define these as standard aggregation periods, which devices can provide. They could be published to different topic paths, so supervisor can subscribe to the aggregation(s) they need:

status/sensor/1/live/df38/dl/1                # no aggregation (send on change)
status/sensor/1/minute/df38/dl/1
status/sensor/1/hour/df38/dl/1
status/sensor/1/day/df38/dl/1

Configuration Which status and/or agreggregations are published by a site could be configurable:

tlc/1: off
tlc/2: off
sensor/1: off
sensor/1/minute: always
sensor/1/hour: on
sensor/1/day: off
sensor/1/week: never

• Always: always publish
• On: publish by default, but can be disabled
• Off: don't publish by default, but can be enabled
• Never: never publish (not supported)

Enabling If a status is on, you just subscribe to the topic and receive data, there's no need to enable it first.

If a status is off, but can be activated, a supervisor publishes to e.g. enable/sensor/1/day/df38/dl/1 to make the site start publishing to status/sensor/1/day/df38/dl/1.

You could perhaps activate multiple data streams with e.g.:

enable/sensor/1/live/df38/dl               # sensor/1 status for all detector logics
enable/sensor/1/hour/df38/dl            #sensor/1 aggregated by hour for all detector logics
enable/sensor/1,3,5,7/live/df38/dl/1         #sensor status 1,3,5 and 7 for detector logic 1
enable/sensor/all/hour/df38/dl/1           #all sensor status for detector logic 1 aggregated by hour
enable/sensor/all/live/df38/dl           #all sensor live status for all detector logics

Disabling Activation could include a timeout and/or a subscriber id. If a timeout is used, you need to renew the subscription before the timeout, otherwise the site stops publishing. The benefit is that you don't need remember to turn it off.

If a subscriber id is used, you could disable the data stream with disable/sensor/1/day/df38/dl/1. The site would maintain a list of subscribers and stop publishing once there are no more subsribers.

[emiltin]

Chunking could be used to send the history of events that happened within the last e.g. minute. This could be very useful, because you still get detailed data, but you reduce the number of messages send, and there the overhead. The downside is that you introduce lag, so it might not be good for cases where you want low latency.

[emiltin]

The idea of providing a fixed set of aggregation periods could be expanded to a set of "stream" configured on the device that each define update rate, chunking, set of attributes. This set of streams is what clients can choose from when they want status data.

Like with the aggregation periods, each channel could be activated/deactivated as needed, or turned on by default, depending on what's practical depending on use-case, network, etc.

We could provide an api that an admin can use to change the set of stream available to clients, but this is still different from client choosing any setting at subscription time.

Let's consider some example stream for some TLC statuses, based on how they are typically used:

S0001 signal group status

• live: { chunking: off, signalgroupstatus: live, cyclecounter: lazy }
• historic: { chunking: day, signalgroupstatus: second, cyclecounter: lazy }

S0002 Detector logic status

• live: { chunking: off, status: live}
• historic: { chunk: day, status: second}

S0201 Traffic counts

• live: { chunking: off, status: live}
• minute: { chunking: off, count: minute, speed: minute }
• chunked: { chunking: minute, count: second, speed: second }
• historic: { chunking: week, status: hour, speed: hour }

[emiltin]

Presence messages could be used for smart disabling of streams, since they tell you when clients go online/online. When a subscriber has been offline for too long, it's removed the subscriber list. When no subscribers are left the channel is disabled.