signalk-chiplog 2.0.0 → 2.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (51) hide show
  1. package/CHANGELOG.md +186 -37
  2. package/README.md +340 -134
  3. package/index.js +80 -40
  4. package/lib/api.js +109 -1
  5. package/lib/background-schedule.js +67 -0
  6. package/lib/crew.js +185 -0
  7. package/lib/database.js +103 -1
  8. package/lib/departure-forecast.js +150 -0
  9. package/lib/detection.js +45 -14
  10. package/lib/entries.js +96 -48
  11. package/lib/event-watcher.js +1 -3
  12. package/lib/events.js +64 -16
  13. package/lib/export.js +20 -1
  14. package/lib/landmark-finder.js +209 -0
  15. package/lib/landmarks.js +210 -0
  16. package/lib/logbook-pdf.js +368 -17
  17. package/lib/observation-recorder.js +11 -5
  18. package/lib/tide-forecaster.js +23 -116
  19. package/lib/weather-forecaster.js +147 -0
  20. package/package.json +2 -1
  21. package/public/app.css +212 -2
  22. package/public/entry/entry.css +71 -0
  23. package/public/entry/js/components/CrewDialog.mjs +200 -0
  24. package/public/entry/js/main.mjs +114 -0
  25. package/public/entry/sw.js +2 -0
  26. package/public/js/animation/camera.mjs +180 -0
  27. package/public/js/animation/formats.mjs +45 -0
  28. package/public/js/animation/mercator.mjs +50 -0
  29. package/public/js/animation/mp4.mjs +77 -0
  30. package/public/js/animation/player.mjs +120 -0
  31. package/public/js/animation/renderer.mjs +326 -0
  32. package/public/js/animation/schedule.mjs +49 -0
  33. package/public/js/animation/storyboard.mjs +195 -0
  34. package/public/js/animation/tiles.mjs +219 -0
  35. package/public/js/animation/timeline.mjs +186 -0
  36. package/public/js/components/AnimationExport.mjs +173 -0
  37. package/public/js/components/AnimationView.mjs +439 -0
  38. package/public/js/components/CrewCard.mjs +22 -0
  39. package/public/js/components/ExportView.mjs +3 -8
  40. package/public/js/components/PassageView.mjs +49 -19
  41. package/public/js/components/Timeline.mjs +30 -7
  42. package/public/js/components/WeatherCard.mjs +134 -0
  43. package/public/js/context.mjs +7 -0
  44. package/public/js/days.mjs +10 -0
  45. package/public/js/format.mjs +15 -0
  46. package/public/js/i18n.mjs +246 -0
  47. package/public/js/landmarks.mjs +128 -0
  48. package/public/js/main.mjs +8 -5
  49. package/public/js/weather.mjs +193 -0
  50. package/public/vendor/mediabunny-LICENSE +373 -0
  51. package/public/vendor/mediabunny.min.mjs +50 -0
package/CHANGELOG.md CHANGED
@@ -1,62 +1,196 @@
1
1
  # Changelog
2
2
 
3
- All notable changes to Chiplog are documented here. The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and the project uses [Semantic Versioning](https://semver.org/).
3
+ All notable changes to Chiplog are documented here. The format follows
4
+ [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and the project uses
5
+ [Semantic Versioning](https://semver.org/).
4
6
 
5
7
  ## [Unreleased]
6
8
 
9
+ ## [2.2.0] - 2026-09-18
10
+
11
+ ### Added
12
+
13
+ - **Landmark bearings (amers)** — every position in the log is now also given the way a paper logbook gives one: a
14
+ distance and a bearing from the nearest landmark, "2,3 M ENE (065°) — Phare de Chauveau", under the coordinates in a
15
+ lighter grey, on the passage page and in the PDF logbook. The coordinates themselves are unchanged. Landmarks —
16
+ lighthouses, capes, named towers, harbours — are fetched from OpenStreetMap area by area and kept, so past passages
17
+ fill in as soon as their area is known and the same waters are never asked for twice; the bearing is computed when the
18
+ page is drawn, never stored. The landmark quoted is the one closest relative to its own range, so a lighthouse three
19
+ miles off wins over a marina alongside, and offshore the coordinates stay alone. A new setting, **Read each journal
20
+ line against the nearest landmark**, turns it off.
21
+ - **Animation** — a new page that replays passages on the map. Pick a start and an end date and every passage between
22
+ them plays in sequence, the time spent in port skipped, so a week's cruise takes seconds. The map follows the boat at
23
+ a scale chosen for each passage — a short hop stays readable instead of being magnified, a long crossing gets a wider
24
+ view without leaving the boat crawling across empty water — and a bubble on the chart shows the speed, the distance
25
+ covered since the animation began and the date and hour. Play, pause, four speeds (×0,5, ×1, ×2, ×4 — an hour of
26
+ sailing per second at ×1) and a slider over the animation's own time. A passage page links straight to it with its own
27
+ dates filled in.
28
+ - **Save an animation as an MP4** — Mobile (9:16), Portrait (3:4), Square (1:1), Landscape (4:3) or Widescreen (16:9),
29
+ encoded in the browser: nothing is uploaded, and the Signal K server renders nothing. Each frame's map is downloaded
30
+ just before that frame is drawn, so the film is the same whatever the connection was doing and no range is ever too
31
+ long to export. Needs a browser with WebCodecs (Chrome, Edge, Safari 17, Firefox 130 and later); without one the
32
+ animation still plays on screen.
33
+ - **Delete an alarm** — a logged alarm can now be removed from a passage's log, like a crew-entered line already could.
34
+ Deleting either the alarm or the line that later cleared it removes both, so no orphaned half is left behind.
35
+
36
+ ## [2.1.0] - 2026-09-17
37
+
38
+ ### Added
39
+
40
+ - Crew list: a per-passage roster of who is aboard, shown as a compact list on the tablet's main screen and editable
41
+ from a dialog that picks from — and can extend — a global crew roster (name + optional role, e.g. skipper/crew),
42
+ without an admin login the same way a place name can be corrected. A name typed there is added to the roster and
43
+ picked at once, immediately correctable or permanently removable with its own icons, right alongside every other name.
44
+ A new passage starts with the same crew as the one before it, still adjustable. Shown read-only, one member per line,
45
+ in its own card on the webapp's passage page, and in the PDF logbook's departure line; included in the JSON export
46
+ (`GET /entries/:id`'s `crew`, `GET /crew`, `PATCH`/`DELETE /crew/:id`, `PUT /entries/:id/crew`).
47
+ - Marine weather forecast: fetched near the departure position for the next 24 hours when a passage opens (Open-Meteo
48
+ Forecast and Marine, free and keyless, can be turned off with its own setting), shown — titled with the departure
49
+ place — on the passage page as a table every 3 hours (sky and rain, wind as a Beaufort force with direction, speed and
50
+ gusts, waves, swell, pressure, visibility, air and sea temperature, and current), in a full-width block of its own
51
+ above the day's table in the PDF logbook, and in the JSON export (`GET /entries/:id/weather`). Far from the sea, the
52
+ atmospheric part is kept on its own.
53
+ - PDF logbook: the tide forecast's high and low times and heights, and the tanks and batteries noted as the passage
54
+ opened, now print side by side in a block of their own, below the weather forecast and above the day's table.
55
+
56
+ ### Changed
57
+
58
+ - A passage now closes as soon as the boat stops, instead of 30 minutes later: its arrival is named, its arrival reading
59
+ taken and the USB copy written straight away. Leaving again within that tolerance reopens the same passage, the stop
60
+ being kept on its timeline as a stopover line naming the place, as a merge does, followed by a departure line at the
61
+ time the boat set off again — with its instrument reading, and in the PDF as "Departure from" the stopover's place. A
62
+ passage closed from the webapp is never reopened. Casting off from the tablet within the tolerance of an arrival goes
63
+ to the passage that just ended, which carries on once the boat moves. The "Stop duration that ends a passage" setting
64
+ (`stopClosureMinutes`, unchanged) is now titled "Stop duration within which a new departure continues the passage".
65
+ - The "Tide service" setting is now titled "Marine service", since the weather forecast also reads the sea state and
66
+ current from it. The setting itself (`tideUrl`) is unchanged.
67
+
68
+ ### Fixed
69
+
70
+ - A new passage's tide and weather forecasts are fetched as soon as it opens, instead of up to a minute later — or up to
71
+ an hour later when an earlier passage's fetch had kept failing while offline, since the retry delay carried over from
72
+ one passage to the next.
73
+ - On a phone, the webapp no longer scrolls sideways: the top navigation wraps onto a second line when it does not fit,
74
+ and the cards shown side by side on a wide screen (tide, engine and sail, boat status) now shrink to the screen width
75
+ instead of staying 420 px wide.
76
+
7
77
  ## [2.0.0] - 2026-09-16
8
78
 
9
79
  ### Added
10
80
 
11
- - The passage page has a **Boat status** card: each engine's hour counter, at departure and arrival, and every tank's level (and volume) and every battery's charge, voltage and current as noted at departure. Tanks and batteries are noted once on the passage as it opens (`startTanks`, `startBatteries`), whether detection or the crew opens it, and included in the JSON export.
12
- - Merging two entries now keeps a record of the stop between them: a `stopover` line on the surviving passage's timeline, naming the place and its position previously that information was silently lost once the merge took the later entry's arrival as its own.
13
- - The passage page's track map now shows a small boat marker at the selected point, pointing along its heading, and a scrubber under the map to step back and forth through the track's history — it defaults to the latest point, doubling as the current position on a passage in progress. A band below it shows that point's time, SOG, COG, STW, TWS, TWD, TWA and AWA. Speed through water now rides along with every track point like wind and heading already did, not just the hourly instrument snapshot.
14
- - Retrospective analysis: a new **Retrospective** page reconstructs past passages for a date range from a [signalk-to-influxdb](https://github.com/tkurki/signalk-to-influxdb) history (InfluxDB 1.x, local or remote — a new recommended companion plugin), through the exact same detection pipeline used live rather than a separate implementation. Runs in the background with a progress bar, refuses a range that overlaps a passage already on record, refuses to run at all while a passage is under way (it would be driving that same live passage through the replay's detector at the same time), and can be cancelled mid-way without losing what it already reconstructed. Data is matched to this server's own vessel identity by default, overridable (`influxSelfContext`) for running it from a different Signal K server than the one that wrote the history; a mismatch fails with the vessel contexts actually found, rather than reconstructing nothing with no explanation. An InfluxDB that never answers — unreachable, or overloaded — fails after 30 seconds with the actual connection problem, rather than hanging indefinitely on a generic "fetch failed". A quick first pass reads one mean speed per minute to find when the boat moved, and only those stretches are then fetched — one value per track interval — and replayed, committing once per ten simulated minutes, and the page sums up what a run added (passages, distance, engine and sail time, track points, events): a month now takes seconds rather than the best part of an hour, and no longer holds every raw reading of the range in memory. Requests stay bounded (a week for the scan, six hours for a stretch) with a short pause between them, so a multi-week reconstruction cannot overwhelm a database sharing a resource-constrained host (a Raspberry Pi) with Signal K itself; cancelling works at any stage. A replay wakes the place-naming lookup immediately once it finishes, rather than leaving newly-reconstructed departures and arrivals waiting out whatever backoff that chain was already in. Signal K alarms are not reconstructed, since a typical InfluxDB history does not archive notifications the way it does a numeric reading, nor are weather events while the boat lay still between passages, nor the extra track points live recording adds on turns and speed changes.
81
+ - The passage page has a **Boat status** card: each engine's hour counter, at departure and arrival, and every tank's
82
+ level (and volume) and every battery's charge, voltage and current as noted at departure. Tanks and batteries are
83
+ noted once on the passage as it opens (`startTanks`, `startBatteries`), whether detection or the crew opens it, and
84
+ included in the JSON export.
85
+ - Merging two entries now keeps a record of the stop between them: a `stopover` line on the surviving passage's
86
+ timeline, naming the place and its position — previously that information was silently lost once the merge took the
87
+ later entry's arrival as its own.
88
+ - The passage page's track map now shows a small boat marker at the selected point, pointing along its heading, and a
89
+ scrubber under the map to step back and forth through the track's history — it defaults to the latest point, doubling
90
+ as the current position on a passage in progress. A band below it shows that point's time, SOG, COG, STW, TWS, TWD,
91
+ TWA and AWA. Speed through water now rides along with every track point like wind and heading already did, not just
92
+ the hourly instrument snapshot.
93
+ - Retrospective analysis: a new **Retrospective** page reconstructs past passages for a date range from a
94
+ [signalk-to-influxdb](https://github.com/tkurki/signalk-to-influxdb) history (InfluxDB 1.x, local or remote — a new
95
+ recommended companion plugin), through the exact same detection pipeline used live rather than a separate
96
+ implementation. Runs in the background with a progress bar, refuses a range that overlaps a passage already on record,
97
+ refuses to run at all while a passage is under way (it would be driving that same live passage through the replay's
98
+ detector at the same time), and can be cancelled mid-way without losing what it already reconstructed. Data is matched
99
+ to this server's own vessel identity by default, overridable (`influxSelfContext`) for running it from a different
100
+ Signal K server than the one that wrote the history; a mismatch fails with the vessel contexts actually found, rather
101
+ than reconstructing nothing with no explanation. An InfluxDB that never answers — unreachable, or overloaded — fails
102
+ after 30 seconds with the actual connection problem, rather than hanging indefinitely on a generic "fetch failed". A
103
+ quick first pass reads one mean speed per minute to find when the boat moved, and only those stretches are then
104
+ fetched — one value per track interval — and replayed, committing once per ten simulated minutes, and the page sums up
105
+ what a run added (passages, distance, engine and sail time, track points, events): a month now takes seconds rather
106
+ than the best part of an hour, and no longer holds every raw reading of the range in memory. Requests stay bounded (a
107
+ week for the scan, six hours for a stretch) with a short pause between them, so a multi-week reconstruction cannot
108
+ overwhelm a database sharing a resource-constrained host (a Raspberry Pi) with Signal K itself; cancelling works at
109
+ any stage. A replay wakes the place-naming lookup immediately once it finishes, rather than leaving
110
+ newly-reconstructed departures and arrivals waiting out whatever backoff that chain was already in. Signal K alarms
111
+ are not reconstructed, since a typical InfluxDB history does not archive notifications the way it does a numeric
112
+ reading, nor are weather events while the boat lay still between passages, nor the extra track points live recording
113
+ adds on turns and speed changes.
15
114
 
16
115
  ### Fixed
17
116
 
18
- - The arrival instrument snapshot (`entry_end`) is now dated from the moment the passage actually ended, not from the later tick that found out about it once the stop had held past the closure threshold (up to `stopClosureMinutes`) — it could otherwise sort after an hourly reading taken during that wait, even though the passage had already ended before that reading was taken.
117
+ - The arrival instrument snapshot (`entry_end`) is now dated from the moment the passage actually ended, not from the
118
+ later tick that found out about it once the stop had held past the closure threshold (up to `stopClosureMinutes`) — it
119
+ could otherwise sort after an hourly reading taken during that wait, even though the passage had already ended before
120
+ that reading was taken.
19
121
 
20
122
  ## [1.2.0] - 2026-09-15
21
123
 
22
124
  ### Added
23
125
 
24
- - The tablet app's handwriting pad now fills the whole screen and has a toolbar: fine pen, thick pen, highlighter, eraser, undo and a choice of colour (kept to the theme's colour in night mode). The eraser removes only the points it touches, splitting a stroke instead of deleting all of it; undo now steps back through erasing too, not just strokes. A stroke's colour and tool travel with it to the webapp's timeline and the PDF export, not just the tablet.
126
+ - The tablet app's handwriting pad now fills the whole screen and has a toolbar: fine pen, thick pen, highlighter,
127
+ eraser, undo and a choice of colour (kept to the theme's colour in night mode). The eraser removes only the points it
128
+ touches, splitting a stroke instead of deleting all of it; undo now steps back through erasing too, not just strokes.
129
+ A stroke's colour and tool travel with it to the webapp's timeline and the PDF export, not just the tablet.
25
130
 
26
131
  ### Fixed
27
132
 
28
- - The tablet app's stylus canvas now prevents the default action on every contact, not just the pen's — a resting palm's touch was left to the browser, which could hijack it as a gesture and cancel the pen's in-progress stroke, or show a native text-selection highlight over the canvas. iOS Safari's long-press selection callout on the canvas needed the whole entry app, not just the canvas, to opt out of selection to reliably stay away, plus blocking `selectstart`/`contextmenu`/`dragstart` directly since the CSS alone is unreliable on some iOS versions.
29
- - Quickly lifting and reapplying the pen could have its next stroke silently dropped: the previous contact's pointerup can arrive after the next one's pointerdown, which read as "still drawing" and refused to start the new stroke.
30
- - Worked around an iPadOS Safari/Scribble bug that could swallow a pen's pointer events mid-stroke, dropping strokes or having them mistakenly typed into the comment field, by also preventing the canvas's underlying touch events directly, not just the pointer ones.
31
- - An autopilot engagement, disengagement or mode change now takes an instrument snapshot like every other automatic event, instead of logging the change with no conditions attached.
133
+ - The tablet app's stylus canvas now prevents the default action on every contact, not just the pen's — a resting palm's
134
+ touch was left to the browser, which could hijack it as a gesture and cancel the pen's in-progress stroke, or show a
135
+ native text-selection highlight over the canvas. iOS Safari's long-press selection callout on the canvas needed the
136
+ whole entry app, not just the canvas, to opt out of selection to reliably stay away, plus blocking
137
+ `selectstart`/`contextmenu`/`dragstart` directly since the CSS alone is unreliable on some iOS versions.
138
+ - Quickly lifting and reapplying the pen could have its next stroke silently dropped: the previous contact's pointerup
139
+ can arrive after the next one's pointerdown, which read as "still drawing" and refused to start the new stroke.
140
+ - Worked around an iPadOS Safari/Scribble bug that could swallow a pen's pointer events mid-stroke, dropping strokes or
141
+ having them mistakenly typed into the comment field, by also preventing the canvas's underlying touch events directly,
142
+ not just the pointer ones.
143
+ - An autopilot engagement, disengagement or mode change now takes an instrument snapshot like every other automatic
144
+ event, instead of logging the change with no conditions attached.
32
145
 
33
146
  ## [1.1.0] - 2026-09-15
34
147
 
35
148
  ### Added
36
149
 
37
- - A summary above the logbook's day-grouped list: number of passages, total distance and total time, across every passage logged rather than just the pages currently loaded (`GET /entries/stats`).
38
- - Tide forecast: fetched near the departure position for the next 24 hours when a passage opens (Open-Meteo Marine, free and keyless, configurable and can be turned off), shown on the passage page with the departure's place, the date, time and height of each high/low tide, and the water height curve. Sits next to the engine/sail card, each taking about half the width on a wide screen instead of the full width. Heights are relative to mean sea level, not the chart datum nautical tide tables use, and the app says so (`datum: "msl"` in the API).
39
- - Editing and deleting logbook lines from the webapp's passage page: any line's comment can be corrected, and a manoeuvre or note the crew logged themselves can be deleted (automatic lines — alarms, autopilot, weather, corrections — can only be annotated).
40
- - Highest speed and wind seen on a passage, shown alongside the average speed on the passage page (`maxSpeed`/`maxWindSpeed` in the API). Wind (true and apparent) and heading now ride along with every track point, not just the hourly instrument snapshot, so a gust between snapshots is no longer missed.
41
- - Automatic engine/sail switches now show as a line in the passage log, not just on the engine/sail strip, with the conditions at that moment (`propulsion_change` event).
42
- - Facsimile PDF logbook: A4 landscape, a page per day in ship's time, with time, position, course, speed, wind, barometer, depth, engine or sail and remarks; departure and arrival lines with passage totals, day totals, handwritten notes drawn. Downloadable from the export page in the webapp's language and the device's time zone.
43
- - Engine hours of every engine: each engine's hour counter is recorded in readings, shown at departure and arrival with the hours run on the passage page and in the PDF, and exported as one CSV column per engine and in the JSON (`engineRuntimes`).
44
- - One PDF per passage in the USB copy, in the new logbook language and ship's time zone settings. Existing copies gain their PDFs at the next copy.
150
+ - A summary above the logbook's day-grouped list: number of passages, total distance and total time, across every
151
+ passage logged rather than just the pages currently loaded (`GET /entries/stats`).
152
+ - Tide forecast: fetched near the departure position for the next 24 hours when a passage opens (Open-Meteo Marine, free
153
+ and keyless, configurable and can be turned off), shown on the passage page with the departure's place, the date, time
154
+ and height of each high/low tide, and the water height curve. Sits next to the engine/sail card, each taking about
155
+ half the width on a wide screen instead of the full width. Heights are relative to mean sea level, not the chart datum
156
+ nautical tide tables use, and the app says so (`datum: "msl"` in the API).
157
+ - Editing and deleting logbook lines from the webapp's passage page: any line's comment can be corrected, and a
158
+ manoeuvre or note the crew logged themselves can be deleted (automatic lines — alarms, autopilot, weather, corrections
159
+ — can only be annotated).
160
+ - Highest speed and wind seen on a passage, shown alongside the average speed on the passage page
161
+ (`maxSpeed`/`maxWindSpeed` in the API). Wind (true and apparent) and heading now ride along with every track point,
162
+ not just the hourly instrument snapshot, so a gust between snapshots is no longer missed.
163
+ - Automatic engine/sail switches now show as a line in the passage log, not just on the engine/sail strip, with the
164
+ conditions at that moment (`propulsion_change` event).
165
+ - Facsimile PDF logbook: A4 landscape, a page per day in ship's time, with time, position, course, speed, wind,
166
+ barometer, depth, engine or sail and remarks; departure and arrival lines with passage totals, day totals, handwritten
167
+ notes drawn. Downloadable from the export page in the webapp's language and the device's time zone.
168
+ - Engine hours of every engine: each engine's hour counter is recorded in readings, shown at departure and arrival with
169
+ the hours run on the passage page and in the PDF, and exported as one CSV column per engine and in the JSON
170
+ (`engineRuntimes`).
171
+ - One PDF per passage in the USB copy, in the new logbook language and ship's time zone settings. Existing copies gain
172
+ their PDFs at the next copy.
45
173
  - Screenshots for the Signal K App Store listing (`signalk.screenshots` in `package.json`).
46
174
 
47
175
  ### Changed
48
176
 
49
- - The tablet app's comment and delete actions on a recent entry are now icon buttons, keeping the same touch target size.
177
+ - The tablet app's comment and delete actions on a recent entry are now icon buttons, keeping the same touch target
178
+ size.
50
179
  - Times are shown on the 24-hour clock in English too.
51
180
 
52
181
  ### Fixed
53
182
 
54
- - The log reading in instrument snapshots now comes from `navigation.log` (the total, non-resettable distance log), not `navigation.trip.log`, which a crew resetting the trip counter could zero out mid-passage.
55
- - Renaming a departure or arrival now also renames that place on every later passage that already reused it, as documented; an earlier passage keeps the name it recorded.
183
+ - The log reading in instrument snapshots now comes from `navigation.log` (the total, non-resettable distance log), not
184
+ `navigation.trip.log`, which a crew resetting the trip counter could zero out mid-passage.
185
+ - Renaming a departure or arrival now also renames that place on every later passage that already reused it, as
186
+ documented; an earlier passage keeps the name it recorded.
56
187
  - An alarm's message is no longer repeated as its comment in the passage log.
57
- - The arrival correction field no longer appears, and is refused by the API (`409 entry_active`), on a passage still in progress — it has no arrival yet, only a moving last-seen position.
58
- - A note or handwritten sketch logged live now takes an instrument snapshot too, like a manoeuvre already did, so the conditions it was written in show in the log.
59
- - The App Store icon (`signalk.appIcon`) pointed at a non-existent `icon.svg` at the package root; the icon has always lived at `public/icon.svg`.
188
+ - The arrival correction field no longer appears, and is refused by the API (`409 entry_active`), on a passage still in
189
+ progress it has no arrival yet, only a moving last-seen position.
190
+ - A note or handwritten sketch logged live now takes an instrument snapshot too, like a manoeuvre already did, so the
191
+ conditions it was written in show in the log.
192
+ - The App Store icon (`signalk.appIcon`) pointed at a non-existent `icon.svg` at the package root; the icon has always
193
+ lived at `public/icon.svg`.
60
194
 
61
195
  ## [1.0.0] - 2026-09-13
62
196
 
@@ -66,19 +200,29 @@ First release.
66
200
 
67
201
  #### Logbook
68
202
 
69
- - One logbook entry per passage, opened when the boat gets under way and closed when it arrives, with a configurable tolerance for short stops (30 minutes by default).
70
- - Under way or stopped decided from `navigation.state` published by [signalk-autostate](https://github.com/meri-imperiumi/signalk-autostate), or from speed over ground averaged over 3 minutes when it is absent. Departures and arrivals are dated from raw speed, so the passage starts where the boat actually left.
71
- - signalk-autostate's value is preferred when another source, such as the boat's own AIS transponder, also publishes `navigation.state`. When detection works from speed alone, the apps say why.
203
+ - One logbook entry per passage, opened when the boat gets under way and closed when it arrives, with a configurable
204
+ tolerance for short stops (30 minutes by default).
205
+ - Under way or stopped decided from `navigation.state` published by
206
+ [signalk-autostate](https://github.com/meri-imperiumi/signalk-autostate), or from speed over ground averaged over 3
207
+ minutes when it is absent. Departures and arrivals are dated from raw speed, so the passage starts where the boat
208
+ actually left.
209
+ - signalk-autostate's value is preferred when another source, such as the boat's own AIS transponder, also publishes
210
+ `navigation.state`. When detection works from speed alone, the apps say why.
72
211
  - Passages closed at their last movement after a power cut; passages split by a long stop can be merged back.
73
- - GPS track at a configurable interval (15 s by default), with extra points on turns and speed changes; distance from the track.
74
- - Engine and sail periods from engine revolutions, engine state, `navigation.state` or a configurable default, with manual correction.
212
+ - GPS track at a configurable interval (15 s by default), with extra points on turns and speed changes; distance from
213
+ the track.
214
+ - Engine and sail periods from engine revolutions, engine state, `navigation.state` or a configurable default, with
215
+ manual correction.
75
216
  - Instrument readings at departure, every hour on the hour (configurable), at arrival and with each live manoeuvre.
76
- - Automatic events: Signal K alarms and emergencies, autopilot changes, true wind crossing configurable thresholds, barometer falling over 3 hours.
77
- - Departure and arrival names from known places, then online geocoding (any Nominatim-compatible service, can be turned off); a renamed place is remembered for later passages.
217
+ - Automatic events: Signal K alarms and emergencies, autopilot changes, true wind crossing configurable thresholds,
218
+ barometer falling over 3 hours.
219
+ - Departure and arrival names from known places, then online geocoding (any Nominatim-compatible service, can be turned
220
+ off); a renamed place is remembered for later passages.
78
221
 
79
222
  #### Logbook webapp
80
223
 
81
- - Status bar, passages grouped by day, passage page with map (OpenStreetMap and OpenSeaMap), engine and sail periods, and the log of readings and events, handwritten notes included.
224
+ - Status bar, passages grouped by day, passage page with map (OpenStreetMap and OpenSeaMap), engine and sail periods,
225
+ and the log of readings and events, handwritten notes included.
82
226
  - Corrections: rename departure or arrival, switch an engine or sail period, close, merge and delete passages.
83
227
  - Export of the whole logbook or a date range as JSON, CSV (nautical units) or GPX.
84
228
  - English and French.
@@ -86,7 +230,8 @@ First release.
86
230
  #### Tablet entry app
87
231
 
88
232
  - Installable app at `/signalk-chiplog/entry/`, designed for gloves and wet fingers, with a red night mode.
89
- - Manoeuvre shortcuts, with the sail picked on a sail change; casting off or weighing anchor opens the passage before the boat moves.
233
+ - Manoeuvre shortcuts, with the sail picked on a sail change; casting off or weighing anchor opens the passage before
234
+ the boat moves.
90
235
  - Keyboard notes and stylus handwriting with pressure and palm rejection.
91
236
  - Undo and comment right after each entry; latest entries with edit and delete.
92
237
  - Entries kept on the tablet while the Wi-Fi is down and sent in order when it is back, never twice.
@@ -94,15 +239,19 @@ First release.
94
239
 
95
240
  #### Abandon-ship copy
96
241
 
97
- - One JSON, CSV and GPX file per passage on a USB drive, named to sort by date, written only when new or changed, with obsolete files removed.
98
- - Copied automatically every 15 minutes and at each arrival (both configurable), or on demand; a missing drive is reported in the plugin status and on the export page.
242
+ - One JSON, CSV and GPX file per passage on a USB drive, named to sort by date, written only when new or changed, with
243
+ obsolete files removed.
244
+ - Copied automatically every 15 minutes and at each arrival (both configurable), or on demand; a missing drive is
245
+ reported in the plugin status and on the export page.
99
246
 
100
247
  #### API and data
101
248
 
102
249
  - REST API under `/plugins/signalk-chiplog/api`, documented in [docs/API.md](docs/API.md).
103
250
  - Single SQLite database through Node's built-in `node:sqlite`: no native module to build.
104
251
 
105
- [Unreleased]: https://github.com/ricard33/signalk-chiplog/compare/v2.0.0...HEAD
252
+ [Unreleased]: https://github.com/ricard33/signalk-chiplog/compare/v2.2.0...HEAD
253
+ [2.2.0]: https://github.com/ricard33/signalk-chiplog/compare/v2.1.0...v2.2.0
254
+ [2.1.0]: https://github.com/ricard33/signalk-chiplog/compare/v2.0.0...v2.1.0
106
255
  [2.0.0]: https://github.com/ricard33/signalk-chiplog/compare/v1.2.0...v2.0.0
107
256
  [1.2.0]: https://github.com/ricard33/signalk-chiplog/compare/v1.1.0...v1.2.0
108
257
  [1.1.0]: https://github.com/ricard33/signalk-chiplog/compare/v1.0.0...v1.1.0