MessageScope plugin

[seandepagnier]

I created a very simple plugin for viewing and inspecting internal json messages passed within opencpn. It can be useful for debugging, and I am finding already some problems with wasted messages.

http://github.com/seandepagnier/messagescope_pi

[nohal]

Sean...
Without looking at the code, does it do anything that https://github.com/nohal/ocpndebugger_pi/ doesn't?

Pavel

[seandepagnier]

I didn't realize this plugin was still developed, anyway it is using API 1.14 which doesn't exist in the master branch. The master branch of opencpn on github also didn't get the commit to VERSION.cmake to make it 4.4.0 etc: https://github.com/OpenCPN/OpenCPN/b.../VERSION.cmake

I don't know how to try this plugin.

Anyway, the message scope appears to give more useful information if there is a lot of message traffic. Perhaps this can be merged into the debugger plugin.

[nohal]

Sean...
Simply use the v1.2 tag with the current OpenCPN codebase - the v1.14 stuff is a WIP towards SignalK support not yet merged to the master.
And yes, I accept patches into the debugger plugin, of course.

Pavel

[seandepagnier]

the description has such a long line I cannot enable the plugin from opencpn. I am editing the config file to enable it.

[seandepagnier]

after trying the debugger, I think my message scope is much better but it only supports messages.

Maybe the message scope plugin as it is can replace the messages tab? What do you think?

[nohal]

Sean...
If it is much better, it sure could As I said - I haven't even looked at your code yet.

Pavel

[seandepagnier]

Pavel,

I made a pull request based off v1.2 to make the debugger a bit better in several ways. It could be improved substantially if it could recognize and parse nmea messages as well.


As for signalk, can we stick opencpn messages inside this? Could we then have opencpn emit messages:

1. creating deleting routes waypoints tracks etc..
2. when connecting to another opencpn instance, then syncronize waypoints routes and tracks

Opencpn could simply discover other instances on the local network perhaps allowing mesh networks, but we would then need to prevent messages from "looping" by checking the source field.

Plugins could also set a "retransmit" field or similar to indicate that the message is meant to be sent to external instances.

What do you think?

[nohal]

Sean...
Everything is possible... For now I have an implementation of mDNS service discovery for the SignalK reference server implementation and consumer code based on libwebsockets working on all our supported platforms. Emitting stuff is just natural next step, but my current focus is clearly on ironing out the consumer part. I'm not sure we want to implement (and maintain) our own SK server code, would certainly prefer to leave all this work to the SK server devs if for nothing else but interoperability reasons.

Will merge your stuff with my WIP shortly.

Pavel