Thanks for that impressive tool.
Using that nice tool inside a company network behind a proxy connecting an IoT device in the internet is not possible at the moment. For such an scenario, connecting to an outside WebSocket server using standard http ports would be a fine solution to receive realtime data from a device - without to configure a fixed IP of the TelemetryViewer host in the device.
In a new branch (ws-client) in my fork of your famous application I have done a first implementation to add an optional WebSocket client connecting a configurable WebSocket server. It is working fine, but it has a small design beauty mistake at the moment: It uses currently an additional (non-jetty) WebSocket library :-(, ... because I was already familiar with that one. This could be approved later. My interest is to hear your opinion about such a new connectivity feature.
In the repo dist directory an all-in-one jar file can be used for testing.
Kind regards.
Thanks for that impressive tool. Using that nice tool inside a company network behind a proxy connecting an IoT device in the internet is not possible at the moment. For such an scenario, connecting to an outside WebSocket server using standard http ports would be a fine solution to receive realtime data from a device - without to configure a fixed IP of the TelemetryViewer host in the device. In a new branch (ws-client) in my fork of your famous application I have done a first implementation to add an optional WebSocket client connecting a configurable WebSocket server. It is working fine, but it has a small design beauty mistake at the moment: It uses currently an additional (non-jetty) WebSocket library :-(, ... because I was already familiar with that one. This could be approved later. My interest is to hear your opinion about such a new connectivity feature.
In the repo dist directory an all-in-one jar file can be used for testing. Kind regards.