make a dashboard updatable

[andreh12]

Does this still ensure that we can see what the DAQExpert actually showed to the shifter at a given point in time ?

I'm asking because we had one case where the shifter claimed that the DAQExpert said 'do XYZ' but in fact we did not see any signs of suggesting XYZ neither in the dashboard nor in the archive. We should be sure that if there is no such evidence in the dashboard/archive that such a message was not shown.

If it is just about updating values such as deadtime I'm not worried but we should avoid updating other things like FED numbers or subsystem names in the same message.

[gladky]

@andreh12, thanks for pointing this out. The idea is to update the values of deadtime, rates etc in real time without tracking them as individual new archive or browser entries.

The second issue is to update and track the 'significant' changes like new FED ID, new Subsystem meeting given condition. For this we have 2 possible solutions (see #100).

In the meantime please have a look at new dashboard demo:

http://daq-expert.cern.ch/dashboard-demo.html

I was using this auto-generated version for developing purposes but I thought that (1) it could be used to discuss the new features of the dashboard (how we display updates, how we attract attention etc), (2) for explaining the dashboard to new shifters. As oppose to dashboard on real data (pro or dev instances) with this auto-generated data version you can now quickly see some 'action'. Please note the following new features:

1. There is a duration counter on ongoing conditions. Instead of 'ongoing' label you now have a updating duration counter.
2. There is a duration indicator on finished conditions. Instead of 'finished' label you now have a duration of the condition.
3. New entries are highlighted and then faded out. Previously they were highlighted and then after some time instantly the highlight was turned off. Fade out has an advantage of showing the relative age of the conditions - if multiple are highlighted you clearly see which is older.
4. The condition in main panel will remain in main panel after it's completed for some time if no other conditions are active. This was suggested by one of the shifter. He complained that after he takes first action he no longer see the suggestions in main panel - he has to look for it in 'recent suggestions' panel
5. The actions are not shown by default in conditions in 'recent suggestion' panel - there is a toggle show them and hide.
6. You can adjust the number of shown suggestions and events. By default there is 5 suggestions and 10 events
7. There is a warning message that we can trigger during deployment to indicate the need of hard reloading the scripts in the browser.

[mommsen]

HI @gladky,

looks very nice, and the demo mode is very handy. Although it changes a bit too fast for me (:

I have a couple of comments, mostly more generic than for the demo:

• [ ] Is the AllOk gone? IMHO, displaying the old (finished) issue can be confusing. Maybe you could rename 'Conditions' to 'Previous problems'. This would make it clearer that the resolved issues can be found there, e.g. for documenting it in the elog.

• [ ] It would be nice to be able to navigate from the previous conditions to DAQView, e.g. by clicking on the time stamp.

• [ ] I'd extend the 'TTCP CSC- of CSC subsystem is in warning 80, it may affect rate.' a bit to make it clearer, e.g. 'TTC partition CSC- of CSC subsystem is in warning 80%, it may affect the trigger rate.

BTW: does the message and the steps shown for previous conditions corresponds to what was shown to the shifter, or do they correspond to the latest version? I think it would be good to know for any condition what the shifter has seen when it happened, even if the instructions have been updated in the meantime.

[gladky]

@mommsen, thanks for feedback. I slowed down the peace of condition generation after first few seconds.

1. 'All ok' is still there. It will be displayed after 20 seconds of inactivity (meaning there is no condition ongoing). 20 seconds is for the demo. I thing for the production it should be much higher. We should keep the last suggestion at least for the average duration of recovery time.
2. 'Previous problems' may be misleading as there may be multiple ongoing conditions and the less important will be displayed in this section - but it's not previous problem. I suggest 'Recent problems'
3. I agree, I will add the link
4. I will update the description as you suggested
5. The message is displayed is ALWAYS the most recent one. But note that this is true only for the parameters like deadtime percentage, rate etc.. We need to discuss what solution we want to implement in case of critical parameters update (list of FEDS, subsystems etc). There is a separate issue for this #100