Clarification of #157, SendOnChange updates UpdateRate (Core 3.2.2)

[sveitech]

In core 3.2.2, the subscription system was updated, so that a SendOnChange resets the the UpdateRate system.

Since the inception of RSMP, the subscription system has always operated on "nice" timestamps. For example, if a subscription is established to send something every 5 minutes, but the subscription is initiated at 15:02 for example, then RSMP would emit updates at:

15:05
15:10
15:15

and NOT like this: (15:02, 15:07, 15:12, e.t.c.)

i.e. the updates are aligned to "clean" times. This was a direct customer request, as it made it easier to show the counts in graphs for example.

This is not explicitly stated in the RSMP specification, but this is how it has always worked.

---

With the new change to RSMP Core 3.2.2, where the update interval must reset if a change-update is sent, should this existing way of making "nice" timestamps be abandoned? With the nice timestamps, the core 3.2.2 change cannot be fulfilled, other than by removing the next "nice" timestamp. For example:

15:05
15:10
15:12 <-- change!
(15:15) <-- skipped, because too close to change emission
15:20

What are your thoughts on this? Should we abandon the "nice" hour-adjusted timestamps, and just have the intervals align with the time of reception of the subscription message?

[otterdahl]

I see your point.
First off, I think the "nice" timestamps only applies to traffic counting (See discussion at rsmp-nordic/rsmp_validator#454). It is not really a requirement to use them anywhere else, but I don't think it is hurts if you do.

I think it is OK remove the next "nice" timestamp. After all, this update to the spec was to prevent too frequent StatusUpdates to be sent.