Open ezio-melotti opened 2 years ago
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.
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.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.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.
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.
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
.
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?
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.
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
.
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.
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.