Some strange with app.subscriptionmanager.subscribe

[Владимир Калачихин]

So, I have two server plugins.

In one I subscribe to some path:

```

       app.subscriptionmanager.subscribe(    
            {
            "context": "vessels.self",
            "subscribe": [
                {
                    "path": "my.sample.path",
                    "format": "delta",
                    "policy": "instant",
                    "minPeriod": 0
                }
            ]
        },   
            unsubscribes, 
            subscriptionError => { },
            delta => {}
        );

```

In other -- sends delta:

```

app.handleMessage(plugin.id, {
                context: 'vessels.self',
                updates: [
                    {
                        values: [
                            {
                                path : 'my.sample.path',
                                value : 'new value'
                            }
                        ],
                    }
                ]
            });

```

Ok, it's works, the first plugin gets the "new value" by subscription.

But, if I say app.getSelfPath('my.sample.path') in a function that handles the delta update -- this return an old value of the 'my.sample.path', not the one by subscription.

What am I doing wrong?

[Teppo Kurki]

But, if I say app.getSelfPath('my.sample.path') in a function that handles the delta update -- this return an old value of the 'my.sample.path', not the one by subscription.

What am I doing wrong?

Nothing. The order of calling subscription handlers and updating the full model so that getSelfPath returns the value in the delta is not explicitly defined. The current implementation calls delta handlers first and then the handler that updates the full model, but this may change in the future.

Use the value in the delta if you want to act on that update.

[Владимир Калачихин]

Thus, due to this asynchrony it is not possible to exchange messages between two server plugins via data tree.

Is there another way to exchange data between server plugins?

четверг, 21 апреля 2022 г. в 21:17:18 UTC+3, Teppo Kurki:

[Teppo Kurki]

What are you trying to do?

[Владимир Калачихин]

четверг, 21 апреля 2022 г. в 22:20:39 UTC+3, Teppo Kurki:

What are you trying to do?

Strange as usual.

The GaladrielMap can dynamically display the gpx file currently being recorded.  There is a server-side procedure for this (the gpx may be very large). I also have a plugin, that logged track to gpx.

I want to switch  track recording on and off from server side - the client does not need to know anything about how the track is recorded.

It was all very easy to do on the PHP,  but there is always something wrong with the SignalK environment.

[Teppo Kurki]

The GaladrielMap can dynamically display the gpx file currently being recorded.  There is a server-side procedure for this (the gpx may be very large). I also have a plugin, that logged track to gpx.

I want to switch  track recording on and off from server side - the client does not need to know anything about how the track is recorded.

It was all very easy to do on the PHP,  but there is always something wrong with the SignalK environment.

If the plugins work so closely together should they be just one plugin? 

If plugin A sends delta for custom path, for example /vessels/self/track/recording/state and plugin B has subscribed for that path why would you not use the value you receive in your delta handler and instead want to retrieve the data with app.getSelfPath?

GaladrielMap readme says "Because SignalK not have a track logging tool, this possibility is missing.". This it not correct - you can record track with at least @signalk/tracks-plugin and signalk-to-influxdb plugin. Tracks plugin keeps a sliding window in memory (disappears on server reboot) but influxdb data is persistent. Both provide an API for retrieving track data. At least Freeboard and vesselpositions webapps retrieve and show the accumulated track and keep updating the track on the screen as new data arrives.

I thought we had some existing plugins for gpx handling, but there's just the ancient @signalk/simple-gpx that probably nobody uses.

I have some work in progress OpenAPI description for the tracks api around. The idea is that we would add the tracks api definition to the Signal K spec, so that clients & various track store plugins could work together.

Then there's https://github.com/tkurki/signalk-grafana, that includes a Grafana panel for rendering track information. This is a little different, as it uses a generic history data retrieval API. My plan for that is to add plotting data on the track, like depth, boat speed, wind speed, engine temp - whatever you feel like.

[Владимир Калачихин]

пятница, 22 апреля 2022 г. в 16:58:28 UTC+3, Teppo Kurki:

 

I want to switch  track recording on and off from server side

If the plugins work so closely together should they be just one plugin? 

 The aim is for these plugins to be completely independent of each other.

If plugin A sends delta for custom path, for example /vessels/self/track/recording/state and plugin B has subscribed for that path why would you not use the value you receive in your delta handler and instead want to retrieve the data with app.getSelfPath?

No problem getting the coordinates. It is a one-way data movement.

I was talking about exchanging a message to control from one plugin to another. I assumed that the SignalK data tree was consistent at all times, so it could be used for exchanging a control data. But it turned out not to be.

Of course, you can always come up with your own mechanism, but I wanted to stay in the SignalK.

 

GaladrielMap readme says "Because SignalK not have a track logging tool, this possibility is missing.". This it not correct - you can record track with at least @signalk/tracks-plugin and signalk-to-influxdb plugin.

Sorry Teppo, but the presence of a semiproduct does not mean there is functionality. The end user expects functionality similar to that found in OruxMaps, AlpineQuest, Locus Map, GPSLogger, etc., etc.

I haven't found anything similar for SignalK.

I thought we had some existing plugins for gpx handling, but there's just the ancient @signalk/simple-gpx that probably nobody uses.

It's quite difficult. I still don't understand what it was doing.

I have some work in progress OpenAPI description for the tracks api around. The idea is that we would add the tracks api definition to the Signal K spec, so that clients & various track store plugins could work together.

If you share your ideas, I can make my plugin in line with them.

 

Then there's https://github.com/tkurki/signalk-grafana, that includes a Grafana panel for rendering track information. This is a little different, as it uses a generic history data retrieval API. My plan for that is to add plotting data on the track, like depth, boat speed, wind speed, engine temp - whatever you feel like.

This is a very heavyweight. And it's  a little different, yes.

BTW, gpx spec has a "extensions" field for story any data. Garmin suggests a format for storing there depth, temperature, and something else.

[Владимир Калачихин]

четверг, 21 апреля 2022 г. в 21:17:18 UTC+3, Teppo Kurki:

The current implementation calls delta handlers first and then the handler that updates the full model

And I see the following:

For example, plugin A is subscribed to path a.b.c

Plugin B changes the a.b.c by app.handleMessage.

Plugin A reacts by subscription and receives a new value of the a.b.c, but the full model has not yet been changed at this time.

As a reaction to the subscription, plugin A changes the a.b.c by app.handleMessage too.

After this, firstly plugin A reacts by subscription and receives a self value of a.b.c, and after the full model is updated with data from plugin A.

After this the full model is updated with data from plugin B.

As a result, the later value of the a.b.c is lost.

Obviously, if you were treating the full model as a database, you would avoid such an unfortunate data lost. It is enough to update the data first and then do the rest.

[Paul & Diane Reeve]

Reverting to your original question re plugin intercommunication.

I had a similar timing issues implementing a plugin that populates SK meta data.

I just implemented a FIFO pipe for inter-plugin communication.

P

[Владимир Калачихин]

суббота, 23 апреля 2022 г. в 13:02:59 UTC+3, pdjr95...@gmail.com:

I just implemented a FIFO pipe for inter-plugin communication.

 How exactly, if I may ask?

I run a second change of the path by the event with some delay so that the data tree has time to update. So-so a crutch, of course.

[Paul Reeve]

There are a number of ways. Here's one.

https://www.npmjs.com/package/named-pipe

P

--
You received this message because you are subscribed to the Google Groups "Signal K" group.
To unsubscribe from this group and stop receiving emails from it, send an email to signalk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/signalk/ac39d4cd-27d4-46dd-abed-b84fb59a4272n%40googlegroups.com.

[Teppo Kurki]

You can avoid this by calling your delta handler with setImmediate or setTimeout(…., 0)

The way things work now is needlessly strange as you say. I’ll look into changing this so that 

(A) full model would be updated before subscription handling so that subscriptions would see updated full

(B) Calling handleMessage in subscription/delta handler does not mess up the order of updates

--

You received this message because you are subscribed to the Google Groups "Signal K" group.
To unsubscribe from this group and stop receiving emails from it, send an email to signalk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/signalk/214f2cdf-0cbb-44d3-99f5-780fa5111f60n%40googlegroups.com.

[Владимир Калачихин]

воскресенье, 24 апреля 2022 г. в 00:07:59 UTC+3, Teppo Kurki:

You can avoid this by calling your delta handler with setImmediate 

O!  I didn't know about setImmediate. It's a good crutch, thank you.

[Владимир Калачихин]

пятница, 22 апреля 2022 г. в 16:58:28 UTC+3, Teppo Kurki:

I thought we had some existing plugins for gpx handling,

Well, that's something like that: https://www.npmjs.com/package/naivegpxlogger