New Watchman Plugin

[seandepagnier]

Any reason this plugin cannot be released for general use? If not, I plan to in a few days.

[AISEAG]

Hi Sean,



This pluging has already answered to some of my needs

Very useful

Serge

[AISEAG]

Hi Sean,

I have been thru Features Requests and have oriented several alarms related demands to "Watchdog / Watchman project" into Tracker/ Flyspray.

Thanks for all


Tracker is here OpenCPN::Tracker All Projects: Tasklist

Login and Registration is here OpenCPN::Tracker All Projects: Tasklist at the top

Serge

[rgleason]

This should be the Watchdog Tracker List:
OpenCPN::Tracker pi - Watchdog / Watchman (Beta): Tasklist

It would be very helpful if users tested the plugin and advised which of the items in Watchdog Tracker were fixed and advised if there are any others.

[rgleason]

This plugin has these alarms now:
Landfall - GPS course crosse land in < x minutes
- GPS fix is < X nm from coastline
NMEA -Require nmea data similar to $IIDBT $IIGLL every X seconds.
Deadman - No user activity for x minutes
Anchor Watch - Sync to boat and Radius in meters.
Off Course -Off course by > x degrees, with course of xxx, Current Course button.
Under speed -Speed over ground < x knots
Over speed - Speed over ground > x knots
Depth - not implemented.
Wind - not implemented.

Please test them, as plugin is being released very soon by Sean.

[rgleason]

Can we close these?
FS#1093 http://opencpn.org/ocpn/flyspray/ind...093&project=34
FS#790 FS#790 : ALARM GPS - Trigger Alarm when GPS-connection is lost
FS#769 FS#769 : ALARM Sounds - Different warning sounds for different alerts.

[bcn]

Opening the context:
The technique applied here to watch for obstructions (or other parameters) would come handy to implement a "route checker" for the route manger:

In commercial software packages there are options to print a route plan from the designed route that alerts about obstructions or not complied parameters for a safe route (draught, minimum distance to shore, ...).
Some ideas are expressed already in FS#717 "waypoint warnings" and #594 "Play route".

Hubert

[cagney]

I can see some problems with this plugin i relation to the main code.

*Some features already exist in the main code, for example Anchor Watch. While this old hack could do with some updating and a better interface, it's not a good policy to re-implement it in a plugin, leaving the old code as is.
*The main code contains a few alarms with a careful thought through priority between them. What happens if a plugin and a main alarm are triggered at the same time? This is important as safety is involved.
*The main code alarms still only uses one alarm sound....

Some coordination is called for between Sean & Dave here, to decide on the best way forward in this area.


Thomas

[rgleason]

Sean fixed some Landfall and Rendering issues, so this has been recompiled.

I've also updated this file on Opencpn Beta File Thingie

[rgleason]

The Depth and Wind alarms are not implemented yet because Sean needs some instruments for testing. If you have some working unused Wind and Depth instruments please consider contributing them to Sean.

[seandepagnier]

Originally Posted by cagney

I can see some problems with this plugin i relation to the main code.

*Some features already exist in the main code, for example Anchor Watch. While this old hack could do with some updating and a better interface, it's not a good policy to re-implement it in a plugin, leaving the old code as is.
*The main code contains a few alarms with a careful thought through priority between them. What happens if a plugin and a main alarm are triggered at the same time? This is important as safety is involved.
*The main code alarms still only uses one alarm sound....

Some coordination is called for between Sean & Dave here, to decide on the best way forward in this area.


Thomas

Yes, well the plugin allows users to run external commands as well as multiple sounds, as well as display more information related to the alarm. From my point of view we could remove the alarms from the main code, but the issue is, Dave probably doesn't want to, at least not anytime soon as it will remove essential features from the base install.

With that said, I intend that users of watchdog_pi (like statusbar_pi) can simply not use the features in the main program in favor of the plugin. Eventually, who knows, maybe we can remove them from the main program and simplify things, but that cannot begin to happen until well after watchdog is released for general use and really put to the test by many users.

[rgleason]

Sean,
I have git pulled watchdog and tried standalone compile with MSVC++ again.
It seems to complete successfully... see attached output.
This is an improvement over before.
I find a new watchdog.dll under C:\o-plugin\watchdog_pi\Debug

Tried to use it under MSVC++ as a debug plugin, it had some problem with osc data. Then tried to use it with v3.3.1606 thinking it was actuallly a release version, that choked up opencpn on start.

Does the attached file give you any ideas for getting this to work?
Also how would I create a release version? It seems to be defaulting to creating a Debug version.

Thanks

[seandepagnier]

Originally Posted by rgleason

Sean,
I have git pulled watchdog and tried standalone compile with MSVC++ again.
It seems to complete successfully... see attached output.
This is an improvement over before.
I find a new watchdog.dll under C:\o-plugin\watchdog_pi\Debug

Tried to use it under MSVC++ as a debug plugin, it had some problem with osc data. Then tried to use it with v3.3.1606 thinking it was actuallly a release version, that choked up opencpn on start.

Does the attached file give you any ideas for getting this to work?
Also how would I create a release version? It seems to be defaulting to creating a Debug version.

Thanks

By adding

SET(CMAKE_BUILD_TYPE Debug)

to the cmakelist file?

Does the plugin work using it in release mode with the release built opencpn?

[rgleason]

Ok, I've been searching and I quit...watchdog_pi_manifest.rc has debug in it but I can't find the file.

[rgleason]

Found an email from Markus Elfing - You've probably already fixed this, but it gives clues to me for my problem:

Some parameters (like "${CMAKE_SOURCE_DIR}/build" and "${wxWidgets_USE_FILE}") are passed to CMake commands in your build scripts without enclosing them by quotation marks. I see that these places will result in build difficulties if the contents of the used variables will contain special characters like spaces.
I would recommend to apply advices from a Wiki article.