Telemetry plugin might get websocket server URL either dynamically or from a config?

[bryan-lunt]

Currently the code assumes the telemetry server is running on localhost, but that's not always a valid assumption.

[larkin]

@bryan-lunt What environment are you running this in where localhost is an invalid assumption?

For the purpose of this tutorial, we provide a fixed server so that people can focus on the contents of Open MCT first without having to think too much about deployment options. But maybe there's an edge case we can better communicate?

[bryan-lunt]

@larkin I am running my development server in Docker.

It's easy enough to make it work, and I guess I understand the reasoning here.

var dynamic_url = 'ws://' + window.location.hostname + ':8082'; var socket = new WebSocket(dynamic_url);

[RGD2]

@larkin Hi again. You must hate me already :)

This seems to silently break the tutorial for me too.

If I'm to run openmct, it's going to live on a headless server and be accessed from multiple clients over a lan.

So naturally, I evaluate openmct-tutorial on the server I have for the purpose, which is just a fairly ordinary Ubuntu LTS machine -- but it's not my desktop machine.

I just assumed that substituting my server's hostname + ':8080' will let me connect to OpenMCT.

And it does.

But all of the telemetry display is missing. Empty graphs and tables.

Yet, if I run the browser on the same machine, so your assumption about localhost is enforced, it works.

Perhaps this issue could be re-titled as "[Critical] All telemetry MIA unless hosted on localhost"

Personally, I'd have to say for any practical use of openmct, running it on localhost -- ie, same machine as the browser is the edge-case.

For something which is supposed to be server-side, I didn't even for a moment consider actually running it localhost, even as just a tutorial. How would I, if I were working on my chromebook?

I eventually got it to work with:

/**
 * Basic Realtime telemetry plugin using websockets.
 */

const host = window.location.hostname;

function RealtimeTelemetryPlugin() {
    return function (openmct) {
        var dynamic_url = 'ws://' + host + ':8082';
        var socket = new WebSocket(dynamic_url);
...

... But I really did expect it to work out-of-the-box, like any other nodejs example.

Anyway -- Sorry to seem overly critical. Keep up the good work!

[larkin]

@RGD2 I really appreciate your feedback!

We can improve this. While a dynamic solution would work, that's very specific to this telemetry server. I'd instead prefer to use this as an opportunity to demonstrate how plugins typically receive configuration information, so we'd change the index.html to be something like:

openmct.install(DictionaryPlugin({url: '/dictionary.json'}));
openmct.install(HistoricalTelemetryPlugin({url: 'http://localhost:8081/telemetry'}));
openmct.install(RealtimeTelemetryPlugin({url: 'ws://localhost:8082'}));

That make sense to you?

[RGD2]

You're welcome!

Ah, that's even better!

[larkin]

@bryan-lunt I noticed you're working on some kerbal integrations with krpc or otherwise. You should also check out the previous kerbal-openmct integration plugin which needs to be updated for the new APIs. At the very least, it might be helpful for your work.

[bryan-lunt]

I guess I mostly replied to this in the other issue/thread.
Yes, I've seen that. Thanks for the heads-up though.

In the long-term, I intend to (after re-reading licensing) pull some of the display code from there and Telemachus proper and make them available components for openMCT. If I remember properly, kerbal-openmct was basically one component panel, without much option for customization.

From a software engineering perspective, the ideal case would be a javascript kRPC client that could connect directly to the KSP game. However, I barely know javascript, but I do know Python quite well. My server was written to be drop-in compatible with the old telemetry tutorial, providing its own dynamically created dictionary.json , it was meant to be easily extensible.

[larkin]

@bryan-lunt the component in kerbal-openmct was composable (drag and drop editing) the same way as other Open MCT displays; I think the screenshot is based on what he created.

I think you're well served to write a python app-- personally I'd use flask and flask-sockets with gevent-- that connects to krpc for data and then exposes that over HTTP + WebSocket for an Open MCT adapter to talk to. Most of your effort would be on the python side and the Open MCT adapter code could be based on this tutorial.