Roger - Is there a plugin that will remember th...
Is there a plugin that will remember the last good value for a signalk variable? When I'm away from the boat, I tend to turn off the GPS and AIS which stops all the navigation paths from updating. I would like to continue to log environment data but there's a couple of navigation paths that are required to calculate true and ground wind data. I'm looking for a plugin that would automatically update these paths when the live source isn't available.
26 Replies
I guess that would be trivial to do with node-red. My node-red skills are super rusty, though...
Can you give an example? I think the proper solution would be tweaking how true and ground wind data are derived in absence of live navigation data, not republishing stale data
The two that are required are navigation.speedOverGround and navigation.magneticVariation. Both of these would be static when the boat is stationary. Speed would be 0, so setting a default value would be easy. Variation is dependent on location so is a bit more difficult.
It would also be good to have a default value for position that isn’t {0,0}.
Blasphemy! Where are we going to meet then, if not on Null island?
https://en.wikipedia.org/wiki/Null_Island
Null Island
Null Island is the location at zero degrees latitude and zero degrees longitude (0°N 0°E), i.e., where the prime meridian and the equator intersect. The name is often used in mapping software as a placeholder to help find and correct database entries that have erroneously been assigned the coordinates 0,0. Although "Null Island" started as a jok...
I still don’t quite understand your problem. If one of the source values stops updating derived-data keeps using that value. So why would the latest value need resending?
Not sure but if there's a GNSS source that keeps updating but provides null,null or 0,0 as location, then yeah, it would make sense to have the last valid location somehow available.
For that the mechanism would be maybe to send the latest valid value after a delay (no valid values for x seconds) with a virtual source. Or always at another path like navigation.latestValidPosition
A different path came to my mind as well. Not sure what would be optimal.
Any sources that stop updating will disappear completely if signalk is restarted. This prevents the derived-data plugin from doing its calculations. What I was looking for is some way to persist the latest value for specific paths so that if the source is not updating, they will still exist after a restart. If the source does start again later, then that should take precedence. Derived data needs speed and deviation to calculate true and ground wind, and these would be static if at anchor or tied up to the dock. The values don't need to update continuously, they just need to be available.
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
Ha. So you are talking about data surviving restarts, not exactly periodic republishing. That is another kind of feature, persisting latest values. Would be useful also for other use cases, when sources are off and you need to restart
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
Mqtt has the mechanism for this, but the core server is not using mqtt
@Teppo Kurki, now we're on the same page 😀 . I assume nothing exists currently, but would it be a useful plugin or a core feature?
IMO, it would be a valuable feature. Probably could be implemented as a plugin with the help of InfluxDB? Or does InfluxDB store sufficiently complete set of data to recreate the SK data?
depends on your InfluxDB settings. but would not want to make this influxdb-dependent, more like persist the latest (self?) values every minute and boostrap data from that on start. maybe more logical to have it in the server than a plugin, but could be either
Either way, I think it would need to be configurable to be able to remove paths if no longer needed.
I can take a crack at writing a plugin to do what I think needs to be done.
would it make sense that it would restore only data when the persisted file's modification date is not too old? survive quick restarts, but restart pause over 10 mins would ignore the persisted data
Not sure. The way I was thinking of doing it was to maintain a list of paths to persist, and then use a priority mechanism so live data would take precedence.
Fair enough. OTOH, even though I'm not very hands-on with the server development and frankly don't know the internals very well, I have a gut feeling that if some functionality could be easily delegated to a plugin, it should. Keep the core message handling as simple and small as possible.
the problem with functionality in plugin is that it is not very discoverable. unless you know (1) the functionality exists (2) you can guess what the author named the plugin you may never happen to find it
@Roger if the problem you are solving is "certain paths need to have the latest valid value available through server restarts" then all you need to do is
- persist the latest valid values (avoiding nulls and possibly [0,0]) with source information
- upon startup emit them as deltas with the original source via server.handleMessage once, preferably with the original timestamp
no need for a priority mechanism - when the sensors come available their data will automatically be "the latest data from that source"
Ok, thanks for the info. It’s very useful. I’ll have a look at putting it into the server if you think it would be a useful feature for everyone.
maybe it is easier for you to get it to working shape in a plugin, then we can haul the code over to the server
@Teppo Kurki ,
>upon startup emit them as deltas with the original source via server.handleMessage once, preferably with the original timestamp
Is there an example somewhere for calling
handleMessage with a delta having a different source name and timesatmp? The only examples I see are for setting the path and value. If I try to set a different source name or timestamp, those are ignored and my delta has the name from my plugin and the current time.Ah forgot that part. This will probably drive moving this over to server proper, but this should not prevent you from solving your use case
I figured this part out. I just needed to add the $source variable and source object to the json to make it work. Without these, I ended up with duplicate values when the live source started. Now, the live value replaces the persisted value, which is what I need.