Update the dashboard scrubber

[ezio-melotti]

The dashboard scrubber should be updated to work in live mode, where the total number of steps is not known in advance since it's endless. This can implemented in a way similar to the one used by YouTube to handle live streams.

[hiyaryan]

Before I start going over some potential designs for the scrubber I would like to take some time to go over how the scrubber in sim mode works. I was wondering if @ezio-melotti or @granawkins could provide some insights to the following questions.

1. What are the general high-level mechanics of the scrubber?
2. Where does the scrubber live within the code base?
3. How tied in is the scrubber to the components (i.e. how much control does it have over the components/how much power does it have on the Dashboard working)?
4. Is there anything else you think I should know about the scrubber?

[ezio-melotti]

1. In short, the scrubber updates the currentStepBuffer to indicate which step is currently being visualized by the panels. This is done through a timer that increments the currentStepBuffer (at 1s intervals, unless a different stepInterval is set in the dashboard store). Dragging the scrubber also updates the currentStepBuffer. The panels react to changes in the currentStepBuffer value and update the values/graphs accordingly.
2. The source of the scrubber is in src/components/dashboard/Timeline.vue. Note that the bottom bar is made of different pieces that can also be found in the src/components/dashboard dir.
3. The scrubber controls the currentStepBuffer and the panels update accordingly. Without a way to update currentStepBuffer -- either automatically through a timer or manually through the scrubber bar -- the dashboard would stand still at step 0.
4. By looking at the code, it seems to me that there's not much to change here. Currently it uses the totalMissionHours to know the total steps in advance, but with live mode we don't have/know that, so the simplest solution is to just replace that value with maxStepBuffer. You could add a totalSteps function (under computed I think) that returns either totalMissionHours or maxStepBuffer if we are in live mode, and use that in the updatePercentages and in the <input>. You would also have to update StepControls.vue to just display the current step (without the /total). You can use a v-if like:

   <span v-if="getCurrentMode === 'sim'">{{getCurrentStepBuffer}}/{{getTotalMissionHours}}</span>
   <span v-else>{{getCurrentStepBuffer}}</span>

   or something like this once we make the step timestamp available through a getter:

   <span v-if="getCurrentMode === 'sim'">{{getCurrentStepBuffer}}/{{getTotalMissionHours}}</span>
   <span v-if="getCurrentMode === 'live'">{{getCurrentStepBuffer}} ({{getStepTimestamp}})</span>

These changes should be enough to make the scrubber work in live mode, at least as a first iteration.

[hiyaryan]

Per the PR above the scrubber now updates the SCD30 panel. Thank you for the instructions and insights @ezio-melotti provided above.

One thing seems unusual with the "live" scrubber. I think the user shouldn't be able to scroll into a section of the scrubber where data is not available. So if the user enters the live dashboard at step 1000, they should not be able to scroll into 999 or below if no data is available for them to view. Right now if this happens the panel just doesn't display any numbers (with no error).

Also, the way the backend passes step objects to the frontend, the frontend doesn't receive the step_num until the first batch is received. I think we had already discussed this but perhaps the starting step should be sent when the backend sends a post to the hab-config endpoint of the socket connection. The reason for this is that the currentStepBuffer should only be set once initially, when the dashboard is first launched, else it'll keep updating the scrubber making it unusable. There's a temporary workaround (view lines 207:215 in DashboardView.vue) for this while we wait for backend to further develop its requests to the frontend.

[ezio-melotti]

I think we can just edit the server so that whenever you connect to the server, the first step you receive will have 0 as step_num. This should make everything simpler. If you start the socketio server first, then launch the live dashboard, then start the sensor, the dashboard should start receiving steps starting from 0, and you should be able to test that the scrubber works in that situation.

This means you probably won't need to set the min_step_num and initialLiveEntry.

[hiyaryan]

It works as expected when you start everything at the same time. If you do it this way you don't need the initLiveEntry Boolean. When I was coding this I was thinking about the user connecting to the server which has already been running for some time. Should I assume the user is always accessing SIMOC right as the server starts?

[hiyaryan]

I re-read your post and overlooked something. So the server will make the step number adjustment. If that's the case it makes it easier. I suppose the frontend could make that adjustment too so long as it receives the the initial step when the config is sent before the batch.

[ezio-melotti]

The server will be running already, and in theory it could start from 0 for every new client. However we haven't coded the bundling yet, so I'm not sure how it would work exactly. I was thinking that each client would start a separate loop, but the way it's implemented now is that it keeps a list of clients and each time a new batch is available it sends it to all the clients. Handling the step_num in the server, while possible, might not be the most efficient solution, since it would have to keep track of different step numbers for each clients and replace the step_num of each step in each batch before sending the batch to the client.

I'm now thinking that it might be easier handling it in the frontend. You could simply store the value of the first step you receive, and subtract it from all the steps in each batch. This should guarantee that you always start from 0.

[hiyaryan]

That's exactly how I was thinking it could be implemented on the frontend. Definitely seems more efficient as it's distributing the work having the client side calculate the step_num. If we do it this way then the initial config should contain the current step_num i.e. the first step_num in the batch of sensor readings. Another variable can be created in the livedata store called initStep that can be used to make the adjustment for each batch of readings while they're processed in the store.