Telemetry table not populating

[DusterTheFirst]

I have setup openmct following the tutorial with my own backend, and have gotten it to plot telemetry in real time as well as to see historical telemetry data. Attached below is a video demonstrating the real-time telemetry as well as the historical telemetry. In the video, you can see that no errors show up in the console that would indicate a problem with the data/my code. The values logged from historical-telemetry.js are the count of telemetry values that were asked for, so the plugin is returning telemetry data.

linked is the data returned by the historical-telemetry.js: https://hatebin.com/ahmzqfwmjb
and here is what my composition provider loads: https://hatebin.com/nusvldppqo
and the object provider for this specific measurement: https://hatebin.com/ghwmungmzt

Demo-2021-04-11_13.33.55.mp4

[jvigliotta]

Hey @DusterTheFirst, it's a bit tough to determine what could be the issue here. To sum up the telemetry view in plots is working but not in telemetry table.

Without access to the code, I can give you some suggestions to try (you may have tried some of these already, but just covering bases):

• check the network tab to see what exactly is being requested and what's being returned in the response, make sure that it's happening for both views similarly (when you switch to telemetry table from plot, it should re-request)
• create a separate Telemetry Table and dropping your telemetry producing object in there to see if there are any issues
• logging out what's happing in the Telemetry Table plugin code to see if you can narrow down the point of failure

One other thing, in your telemetry values here: https://hatebin.com/ghwmungmzt I see the key for timestamp is uc_running_us, in our Telemetry Documentation it states, In order for the time conductor to work, there will always be an active "time system". All telemetry metadata must have a telemetry value with a key that matches the key of the active time system. This could be unrelated to your issue, but try changing that key to utc if your timestamps are UTC based.

Let me know if you've already made any progress or if you get any results from what I've suggested above.

[deeptailor]

Jamie, I believe you are correct. What seems to be happening is that the telemetry table is filtering out the values as out of bounds (because of the unavailable time system).

…

On Wed, Apr 28, 2021 at 11:06 AM Jamie V. ***@***.***> wrote: Hey @DusterTheFirst <https://github.com/DusterTheFirst>, it's a bit tough to determine what could be the issue here. To sum up the telemetry view in plots is working but not in telemetry table. Without access to the code, I can give you some suggestions to try (you may have tried some of these already, but just covering bases): - check the network tab to see what exactly is being requested and what's being returned in the response, make sure that it's happening for both views similarly (when you switch to telemetry table from plot, it should re-request) - create a separate Telemetry Table and dropping your telemetry producing object in there to see if there are any issues - logging out what's happing in the Telemetry Table plugin code to see if you can narrow down the point of failure One other thing, in your telemetry values here: https://hatebin.com/ghwmungmzt I see the key for timestamp is *uc_running_us*, in our Telemetry Documentation <https://github.com/nasa/openmct/blob/master/API.md#telemetry-api> it states, *In order for the time conductor to work, there will always be an active "time system". All telemetry metadata must have a telemetry value with a key that matches the key of the active time system.* This could be unrelated to your issue, but try changing that key to *utc* if your timestamps are UTC based. Let me know if you've already made any progress or if you get any results from what I've suggested above. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3801 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADFFPEEWX3WY2AEEUQUJSJLTLBFCFANCNFSM42X4YS4Q> .

[jvigliotta]

@deeptailor ahh, makes sense. Thanks Deep!

[DusterTheFirst]

Here is my openmct setup: https://github.com/DusterTheFirst/openmct-picopilot/tree/main/web

I do have a time system setup with the name uc_running_us which matches the key of the timestamp in the telemetry data.

• check the network tab to see what exactly is being requested and what's being returned in the response, make sure that it's happening for both views similarly (when you switch to telemetry table from plot, it should re-request)

I see the request, with what look top be valid timestamps as well as a solid amount of data fetched whenever I switch to the telemetry table:

I can be sure that historical telemetry data works properly for when I switch back to the plot view, the previous data points show up after being requested from the backend.

• create a separate Telemetry Table and dropping your telemetry producing object in there to see if there are any issues

Same exact problem. No data shows up in the table, while the plot updates just fine.

• logging out what's happing in the Telemetry Table plugin code to see if you can narrow down the point of failure

How would I do this? modify the openmct source's telemetry table plugin to insert console.logs?