Autoscale creates weird plots if the min and max are very close

[ozyx]

Summary

Certain aggregate members which always emit a constant value are losing precision right before they are plotted, which leads to weird plots.

Notice that the same telemetry point on yamcs graph does NOT display incorrectly, so this is something Open MCT is doing.

Expected vs Current Behavior

The value coming in should be the value plotted. I.e:
If we receive the value 3.1456, we should plot that value at the same precision it was received.

Steps to Reproduce

Environment

• Open MCT Version:
• Deployment Type:
• OS:
• Browser:

Impact Check List

• Data loss or misrepresented data?
• Regression? Did this used to work or has it always been broken?
• Is there a workaround available?
• Does this impact a critical component?
• Is this just a visual bug with no functional impact?
• Does this block the execution of e2e tests?
• Does this have an impact on Performance?

Additional Information

[unlikelyzero]

Setting as blocker given the context in which this was found

[scottbell]

FWIW, if I override the websocket callback and add:

if (this.isTelemetryMessage(message)) {
                    let values = message.data.values || [];
                    let parentName = subscriptionDetails.domainObject.name;

                    values.forEach(parameter => {
                        let datum = {
                            id: qualifiedNameToId(subscriptionDetails.name),
                            timestamp: parameter[METADATA_TIME_KEY]
                        };
                        let value = getValue(parameter, parentName);
                        if (parameter?.engValue?.type === 'FLOAT') {
                            value = 3.31456;
                        }
...

it seems to display properly:

Screen.Recording.2023-12-21.at.9.51.09.AM.mov

[ozyx]

Yeah, I went on a whole wild goose chase yesterday afternoon. I think the issue is that telemetry from yamcs sent over websocket/json has lower precision than historical data fetched from the API

[ozyx]

I'm leaning towards this being a yamcs bug now? @unlikelyzero lets sync today when you have a minute

[ozyx]

According to Mark R, these two values are identical and thus it's up to the client to display them in a non-confusing way. I'm inclined to agree, which would make this an Open MCT / plotting / autoscale issue

[akhenry]

According to Mark R, these two values are identical and thus it's up to the client to display them in a non-confusing way.

@ozyx @merose 3.1456 might be 3.31455984 rounded, but it might also be 3.31455983. They're not necessarily the same number, and I can guarantee that treating all values within a certain precision as the same number will break functionality for other users who may care about differences at that precision. So I'm not convinced that changing how auto-scaling works is the right way to fix inconsistent precision from Yamcs.

I think if Yamcs is inconsistent with its precision when reporting real-time vs historical values, and they don't want to change that behavior, then we should just force all telemetry values to the lowest level of precision in the adapter, so in this case we round to 3.31456. We will have to confirm what strategy Yamcs uses for rounding to make sure we're consistent.

[ozyx]

@akhenry its worth mentioning that using protobufs doesn't have this issue, it's just the yamcs json that sends telemetry with different precision

[unlikelyzero]

Closing to be tracked in akhenry/openmct-yamcs#406