@mxtommy/kip 4.5.0-beta.1 → 4.5.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.
- package/.github/copilot-instructions.md +19 -6
- package/.github/instructions/project.instructions.md +42 -6
- package/CHANGELOG.md +13 -0
- package/README.md +11 -7
- package/package.json +8 -5
- package/plugin/duckdb-parquet-storage.service.js +1206 -0
- package/plugin/history-series.service.js +439 -0
- package/plugin/index.js +670 -15
- package/plugin/openApi.json +253 -3
- package/plugin/plugin-auth.service.js +75 -0
- package/plugin-config-data/kip/historicalData/kip-history.duckdb +0 -0
- package/plugin-config-data/kip/historicalData/parquet/chart-1/1772344583976-1772344583976.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-1/1771408800000-1771408890000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-1/1771412400000-1771412490000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-1/1771419600000-1771419650000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-1/1772344584154-1772344584154.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-1/1772344584191-1772344584191.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-1/1772344584268-1772344584268.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-2/1771502400000-1771502400000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-3/1771408800000-1771408890000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-3/1771412400000-1771412490000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-3/1771419600000-1771419650000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-3/1772344584268-1772344584268.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-4/1771408800000-1771408890000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-4/1771412400000-1771412490000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-4/1771419600000-1771419650000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-5/1771412400000-1771412490000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-5/1771419600000-1771419650000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-6/1771419600000-1771419650000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-prefixed-1/1771408800000-1771408890000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-prefixed-1/1771412400000-1771412490000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-prefixed-1/1771419600000-1771419650000.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-prefixed-1/1772344584191-1772344584191.parquet +0 -0
- package/plugin-config-data/kip/historicalData/parquet/live-prefixed-1/1772344584268-1772344584268.parquet +0 -0
- package/public/assets/help-docs/chartplotter.md +5 -18
- package/public/assets/help-docs/community.md +0 -3
- package/public/assets/help-docs/configuration.md +1 -1
- package/public/assets/help-docs/contact-us.md +0 -4
- package/public/assets/help-docs/dashboards.md +20 -18
- package/public/assets/help-docs/datainspector.md +7 -5
- package/public/assets/help-docs/history-api.md +116 -0
- package/public/assets/help-docs/menu.json +18 -6
- package/public/assets/help-docs/nodered-control-flows.md +125 -0
- package/public/assets/help-docs/putcontrols.md +101 -60
- package/public/assets/help-docs/welcome.md +6 -7
- package/public/assets/help-docs/widget-historical-series.md +66 -0
- package/public/assets/help-docs/zones.md +5 -10
- package/public/{chunk-KFFAA7DL.js → chunk-2ICAVOT2.js} +8 -8
- package/public/chunk-6XFWUUDD.js +3 -0
- package/public/chunk-A6DQJFP4.js +16 -0
- package/public/chunk-B75MT7ND.js +1 -0
- package/public/{chunk-T6TFVZVM.js → chunk-CEB42O2C.js} +1 -1
- package/public/chunk-CHGXAEKT.js +2 -0
- package/public/chunk-D7VDX7ZF.js +5 -0
- package/public/chunk-DD4F6F4S.js +9 -0
- package/public/{chunk-ZQER6AIQ.js → chunk-DEGYRCMI.js} +1 -1
- package/public/{chunk-M2B5OYGO.js → chunk-DEM56G4S.js} +1 -1
- package/public/chunk-DYTBBUMI.js +4 -0
- package/public/{chunk-YIYYVDFO.js → chunk-EDNYYQIZ.js} +2 -2
- package/public/chunk-FNF7M3AE.js +1 -0
- package/public/chunk-IHURI4IH.js +5 -0
- package/public/chunk-J3LDKVIS.js +50 -0
- package/public/{chunk-5FEX27I4.js → chunk-JB4YVVNW.js} +1 -1
- package/public/chunk-KPHICV76.js +5 -0
- package/public/{chunk-QZKCRH3H.js → chunk-KZ5DUKAX.js} +1 -1
- package/public/{chunk-HMOOTAEA.js → chunk-LQDSU4WS.js} +3 -3
- package/public/{chunk-IXQ7KIFY.js → chunk-MGPPVLZ7.js} +1 -1
- package/public/{chunk-QVCLOCEC.js → chunk-R7RQHWKJ.js} +1 -1
- package/public/chunk-S72JTJPN.js +6 -0
- package/public/chunk-UYIJND2R.js +1 -0
- package/public/chunk-YCEXTKGG.js +1 -0
- package/public/chunk-YKJKIWXO.js +6 -0
- package/public/index.html +1 -1
- package/public/main-EG2WF4EO.js +1 -0
- package/tools/schematics/create-host2-widget/files/readme/README.md.template +1 -1
- package/public/assets/help-docs/datasets.md +0 -95
- package/public/chunk-2OB7ZJBR.js +0 -3
- package/public/chunk-6GGJZDRE.js +0 -1
- package/public/chunk-6V4GGGXE.js +0 -2
- package/public/chunk-A5BW6BUM.js +0 -1
- package/public/chunk-DGE5YFPU.js +0 -5
- package/public/chunk-G6M3Z3BY.js +0 -53
- package/public/chunk-GMGZLXY7.js +0 -4
- package/public/chunk-GUZ3BDVZ.js +0 -2
- package/public/chunk-ICDGHQFP.js +0 -6
- package/public/chunk-JCNE4QHQ.js +0 -15
- package/public/chunk-K6XYUNG4.js +0 -8
- package/public/chunk-LGCQEN7V.js +0 -4
- package/public/chunk-O3JH7UTR.js +0 -1
- package/public/chunk-Q3USFT4F.js +0 -2
- package/public/chunk-VIKU7BH7.js +0 -1
- package/public/chunk-XMQPXXLW.js +0 -8
- package/public/main-4URMGBQS.js +0 -1
- package/rm-npmjs-beta.sh +0 -50
|
@@ -1,9 +1,8 @@
|
|
|
1
1
|
## Managing Dashboards
|
|
2
2
|
Dashboards let you group widgets by task—navigation, engines, energy, weather, racing, night watch, and more. This guide covers creating, organizing, and editing dashboards, plus an overview of available widget types.
|
|
3
3
|
|
|
4
|
-
---
|
|
5
4
|
|
|
6
|
-
##
|
|
5
|
+
## Dashboard Pages Panel
|
|
7
6
|
Open the Actions menu and select Settings.
|
|
8
7
|
|
|
9
8
|
Here you can:
|
|
@@ -24,9 +23,8 @@ Choose icons that reflect each dashboard’s purpose (e.g. compass for navigatio
|
|
|
24
23
|
| Duplicate | Long press → Duplicate | Long click → Duplicate |
|
|
25
24
|
| Delete | Long press → Delete | Long click → Delete |
|
|
26
25
|
|
|
27
|
-
---
|
|
28
26
|
|
|
29
|
-
##
|
|
27
|
+
## Editing Dashboard Layouts
|
|
30
28
|
1. Navigate to the dashboard you want to change (swipe or use dashboard selector).
|
|
31
29
|
2. Open the Actions menu.
|
|
32
30
|
3. Tap the Unlock/Lock button at the bottom to toggle edit mode.
|
|
@@ -42,11 +40,18 @@ In edit mode, widgets show dashed outlines.
|
|
|
42
40
|
- Delete a widget (long press → Delete, then confirm)
|
|
43
41
|
- Save changes (Check button) or discard (X button) in the lower right
|
|
44
42
|
|
|
45
|
-
Tip
|
|
43
|
+
>**Tip:** If you can’t add a widget, free up space by resizing or moving existing ones first.
|
|
46
44
|
|
|
47
|
-
|
|
45
|
+
## Viewing Widget History on Locked Dashboards
|
|
46
|
+
When a dashboard is locked (normal viewing mode), you can open a history chart for a widget without entering edit mode:
|
|
48
47
|
|
|
49
|
-
|
|
48
|
+
- **Desktop / mouse:** right-click on the widget
|
|
49
|
+
- **Touch device:** two-finger tap on the widget
|
|
50
|
+
|
|
51
|
+
KIP opens a history chart dialog and loads historical series data for that widget using the History API.
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
## Workflow: From Idea to Dashboard
|
|
50
55
|
1. Define the purpose (e.g. “Night Nav” = heading, COG, SOG, depth, wind, batteries, minimal brightness)
|
|
51
56
|
2. Create or duplicate a dashboard similar to what you want
|
|
52
57
|
3. Enter edit mode and add required widgets
|
|
@@ -54,9 +59,8 @@ Tip: If you can’t add a widget, free up space by resizing or moving existing o
|
|
|
54
59
|
5. Arrange and size for readability at your viewing distance
|
|
55
60
|
6. Exit edit mode and test switching at real brightness/environment
|
|
56
61
|
|
|
57
|
-
---
|
|
58
62
|
|
|
59
|
-
##
|
|
63
|
+
## Widget Gallery (Overview)
|
|
60
64
|
KIP widgets turn Signal K data into readable visuals and controls. Available widget types:
|
|
61
65
|
|
|
62
66
|
- **Numeric** – Displays numeric data in a clear and concise format, with options to show min/max values and a background minichart for trends.
|
|
@@ -65,9 +69,9 @@ KIP widgets turn Signal K data into readable visuals and controls. Available wid
|
|
|
65
69
|
- **Position** – Displays latitude and longitude for location tracking and navigation.
|
|
66
70
|
- **Static Label** – Add customizable labels to organize and clarify your dashboard layout.
|
|
67
71
|
- **Zones State Panel**: Monitor the health/state of path data. Each panel control displays path data severity and status messages (driven by Signal K metadata zones).
|
|
68
|
-
- **Switch Panel** – Group of toggle switches, indicator lights, and press buttons for digital switching and operations.
|
|
69
|
-
- **Slider** – Range slider for adjusting values (e.g. lighting intensity).
|
|
70
|
-
- **Multi State Switch** - Lists all available device/path operating modes/states (e.g., On, Off, Charge Only, Invert Only), highlights the current state, and lets you select a new state to send to the device and see the result.
|
|
72
|
+
- **Switch Panel** – Group of toggle switches, indicator lights, and press buttons for digital switching and operations. See [Digital Switching and PUT Path Setup](putcontrols.md).
|
|
73
|
+
- **Slider** – Range slider for adjusting values (e.g. lighting intensity). See [Digital Switching and PUT Path Setup](putcontrols.md).
|
|
74
|
+
- **Multi State Switch** - Lists all available device/path operating modes/states (e.g., On, Off, Charge Only, Invert Only), highlights the current state, and lets you select a new state to send to the device and see the result. See [Digital Switching and PUT Path Setup](putcontrols.md).
|
|
71
75
|
- **Compact Linear** – Simple horizontal linear gauge with a large value label and modern look.
|
|
72
76
|
- **Linear** – Horizontal or vertical linear gauge with zone highlighting.
|
|
73
77
|
- **Radial** – Radial gauge with configurable dials and zone highlighting.
|
|
@@ -87,9 +91,8 @@ KIP widgets turn Signal K data into readable visuals and controls. Available wid
|
|
|
87
91
|
- **Racer - Start Timer** – Advanced racing countdown timer with OCS status and auto dashboard switching.
|
|
88
92
|
- **Countdown Timer** – Simple race start countdown timer with start, pause, sync, and reset options.
|
|
89
93
|
|
|
90
|
-
---
|
|
91
94
|
|
|
92
|
-
##
|
|
95
|
+
## Performance & Layout Tips
|
|
93
96
|
- Favor clarity over cramming: leave space around high‑priority values
|
|
94
97
|
- Group related widgets (navigation, energy, engines, environment)
|
|
95
98
|
- Use consistent units per dashboard (e.g. all speeds in knots, all temps in °C or °F—don’t mix)
|
|
@@ -99,19 +102,18 @@ KIP widgets turn Signal K data into readable visuals and controls. Available wid
|
|
|
99
102
|
- Know your device’s hardware limits and adjust widget count per dashboard accordingly
|
|
100
103
|
- Avoid embedding too many external webpages—each adds load
|
|
101
104
|
|
|
102
|
-
---
|
|
103
105
|
|
|
104
|
-
##
|
|
106
|
+
## Troubleshooting
|
|
105
107
|
| Issue | Possible Cause | Fix |
|
|
106
108
|
|------------------------|---------------------------------------|---------------------------------------------------------------------|
|
|
107
109
|
| Data shows “—” or blank| Path missing/not configured/null value | Open widget config, verify Signal K path exists and updates. Use Data Inspector and Signal K Data Browser to view raw data from the server. |
|
|
108
110
|
| Wrong units | Default convert unit used | Edit widget config paths and set the desired target unit. |
|
|
109
111
|
| Slow dashboard switching| Excessive data sampling/too many widgets| Increase sample times; remove unused widgets. Split widgets into separate dashboards. Optimize system resource usage. |
|
|
110
112
|
| Embedded page blank | Cross‑origin blocked | See "Embed Page Viewer" help section. |
|
|
113
|
+
| History dialog not opening on locked dashboard | Dashboard is still in edit mode, or interaction did not register as right-click / two-finger tap | Lock the dashboard first, then retry with a right-click (desktop) or two-finger tap (touch). |
|
|
111
114
|
|
|
112
|
-
---
|
|
113
115
|
|
|
114
|
-
##
|
|
116
|
+
## Next Steps
|
|
115
117
|
See also:
|
|
116
118
|
- Remote Control (switch dashboards on unattended displays)
|
|
117
119
|
- Night Mode (automatic theme + brightness)
|
|
@@ -10,7 +10,7 @@ The Data Inspector is a good way to validate raw data and available paths withou
|
|
|
10
10
|
- Type `self.` to view paths related to your vessel.
|
|
11
11
|
- Type `environment` to view environmental data like wind or temperature.
|
|
12
12
|
- Type `speed` to view any speed related data like wind speed, max speed, polar speed, etc.
|
|
13
|
-
|
|
13
|
+
- Type `derived` to view all paths from source `derived-data`.
|
|
14
14
|
|
|
15
15
|
2. **Sort and Navigate**:
|
|
16
16
|
- Click on column headers to sort the data by Path, PUT Support, or Source.
|
|
@@ -24,7 +24,7 @@ The Data Inspector is a good way to validate raw data and available paths withou
|
|
|
24
24
|
|
|
25
25
|
2. **PUT Support**:
|
|
26
26
|
- You can see if a path supports PUT operations, indicated by a green checkmark in the **PUT Support** column.
|
|
27
|
-
- For more details on PUT support and how to use it, refer to the
|
|
27
|
+
- For more details on PUT support and how to use it, refer to the [Updating Signal K Data](putcontrols.md) help documentation.
|
|
28
28
|
|
|
29
29
|
3. **Multiple Data Sources**:
|
|
30
30
|
- The Data Inspector displays how many sources are providing data for each path.
|
|
@@ -41,11 +41,13 @@ The Data Inspector is a good way to validate raw data and available paths withou
|
|
|
41
41
|
- Use the Data Inspector to validate raw data and available paths without the constraints that widgets can impose. This is especially useful when setting up new devices or debugging data issues.
|
|
42
42
|
|
|
43
43
|
- **Verify PUT Support**:
|
|
44
|
-
|
|
44
|
+
- Check if a path supports PUT operations. It is required to configure widgets like Switch Panel, Slider, or Multi State Switch.
|
|
45
|
+
- For more details on PUT support and how to use it, refer to the [Updating Signal K Data](putcontrols.md) help documentation.
|
|
46
|
+
- If you are learning Node-RED flows and want your flow to work with KIP digital switching widgets, continue with [Node-RED Control Flows for KIP Widgets (Beginner Guide)](nodered-control-flows.md).
|
|
45
47
|
|
|
46
48
|
- **Troubleshoot Data Issues**:
|
|
47
|
-
|
|
49
|
+
- The Data Inspector is a good troubleshooting tool, but it should be used with the Signal K Data Browser when trying to understand raw data and behavior. The combination of these tools provides a more complete picture of the data, its processing, and its behavior.
|
|
48
50
|
|
|
49
51
|
## Summary
|
|
50
52
|
|
|
51
|
-
The Data Inspector is an essential tool for managing and understanding the data KIP receives from your Signal K server. With its real-time updates, filtering, and unit conversion capabilities, it provides a comprehensive view of your vessel's data
|
|
53
|
+
The Data Inspector is an essential tool for managing and understanding the data KIP receives from your Signal K server. With its real-time updates, filtering, and unit conversion capabilities, it provides a comprehensive view of your vessel's data whether you're monitoring performance, configuring widgets, or troubleshooting issues. For deeper analysis and understanding of raw data, pair it with the Signal K Data Browser.
|
|
@@ -0,0 +1,116 @@
|
|
|
1
|
+
## Using the History-API to Obtain Historical Data
|
|
2
|
+
|
|
3
|
+
KIP can automatically request History Provider historical data points when opening chart widgets, seamlessly integrating past data with live updates.
|
|
4
|
+
|
|
5
|
+
This enables the display of minutes, hours, days, weeks, etc. of pre-populated historical data immediately—no waiting, no empty charts. The History-API is used to achieve this.
|
|
6
|
+
|
|
7
|
+
A History Provider can also be used as a source for the widget historical data feature.
|
|
8
|
+
|
|
9
|
+
## What Is the History-API?
|
|
10
|
+
|
|
11
|
+
A Signal K server endpoint that provides access to recorded historical data. Behind the endpoint, the data is served by a history provider plugin. KIP automatically requests historical data points when opening chart widgets, pre-filling the chart instead of starting empty.
|
|
12
|
+
|
|
13
|
+
## Which Widgets Support History?
|
|
14
|
+
|
|
15
|
+
### Data Chart Widget
|
|
16
|
+
- **Supported**: Yes, fully seeded with history data when available.
|
|
17
|
+
- **Requirements**: Time scale = minutes or longer.
|
|
18
|
+
- See "Configure Time Scales" below for more details.
|
|
19
|
+
|
|
20
|
+
### Wind Trends Widget
|
|
21
|
+
- **Supported**: Yes, uses fixed paths (True Wind Direction and Speed).
|
|
22
|
+
- **Requirements**: Time Span of `5 minutes` or `30 minutes`.
|
|
23
|
+
- See [Wind Trends Fixed Paths](#wind-trends-fixed-paths) below for configuration details.
|
|
24
|
+
|
|
25
|
+
### Numeric Widget (with Mini Chart)
|
|
26
|
+
- **Supported**: No. Mini charts use very short time windows (12 seconds) and skip history seeding.
|
|
27
|
+
- Mini charts start live-only for performance reasons.
|
|
28
|
+
|
|
29
|
+
## What Plugins and Signal K Version Are Required?
|
|
30
|
+
|
|
31
|
+
The History-API requires Signal K version 2.22.1 or above and one plugin that records data to a persistent store. Currently, two plugins support the History-API:
|
|
32
|
+
|
|
33
|
+
### 1. signalk-to-influxdb2, v2.0.0 or above
|
|
34
|
+
- **Purpose**: Records Signal K data to an InfluxDB v2 time-series database. Requires pre-installed InfluxDB v2.
|
|
35
|
+
- **Link**: [signalk-to-influxdb2](https://www.npmjs.com/package/signalk-to-influxdb2)
|
|
36
|
+
- **Setup**: Consult the plugin documentation for installation and configuration.
|
|
37
|
+
- **Path Configuration**: By default, records all paths. Configure filters, resolution, and other settings to match the paths you want available in KIP charts.
|
|
38
|
+
|
|
39
|
+
### 2. signalk-parquet, (supporting version not release yet)
|
|
40
|
+
- **Purpose**: Records Signal K data to Parquet files for efficient storage and querying. No external database installation required.
|
|
41
|
+
- **Link**: [signalk-parquet](https://www.npmjs.com/package/signalk-parquet)
|
|
42
|
+
- **Setup**: Consult the plugin documentation for installation and configuration.
|
|
43
|
+
- **Path Configuration**: Specify which paths to record in the plugin settings. None are recorded by default.
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
## How History Data Works in KIP
|
|
47
|
+
|
|
48
|
+
### History Seeding
|
|
49
|
+
When you open a chart widget with a larger time scale (minutes/hours):
|
|
50
|
+
1. KIP checks if history data is available via the History-API.
|
|
51
|
+
2. If available and the time window allows (resolution >= 1000ms), KIP requests historical data points.
|
|
52
|
+
3. The chart immediately displays the historical trend.
|
|
53
|
+
|
|
54
|
+
### Live Updates
|
|
55
|
+
After history data loads:
|
|
56
|
+
- New data points arrive continuously via Signal K's live WebSocket connection.
|
|
57
|
+
- The chart smoothly transitions from history to live updates.
|
|
58
|
+
- Old data points are removed to maintain a rolling window of the configured time scale.
|
|
59
|
+
|
|
60
|
+
### When History Is Not Available
|
|
61
|
+
- If a History-API plugin is not installed, or the plugin report the path is not recorded, history requests are skipped silently.
|
|
62
|
+
- The chart will display only live data starting from when it was opened.
|
|
63
|
+
- This is normal and does not indicate an error.
|
|
64
|
+
|
|
65
|
+
## Wind Trends Fixed Paths
|
|
66
|
+
|
|
67
|
+
The Wind Trends widget uses two fixed Signal K paths:
|
|
68
|
+
- **True Wind Direction**: `environment.wind.directionTrue`
|
|
69
|
+
- **True Wind Speed**: `environment.wind.speedTrue`
|
|
70
|
+
|
|
71
|
+
For Wind Trends to display historical data, both of these paths **must be configured in your chosen History-API plugin**. Check your plugin documentation to ensure these paths are included in the capture list.
|
|
72
|
+
|
|
73
|
+
## Limitations
|
|
74
|
+
|
|
75
|
+
For historical data to seed widgets, you need to, in most cases, manually configure your chosen provider to collect the said data. This is not an automatic process.
|
|
76
|
+
|
|
77
|
+
## Troubleshooting
|
|
78
|
+
|
|
79
|
+
### History Data Is Not Showing
|
|
80
|
+
|
|
81
|
+
**Check 1: Is the History-API plugin installed?**
|
|
82
|
+
- Confirm that a History-API plugin is installed and enabled on your Signal K server.
|
|
83
|
+
- Verify that the plugin is running without errors (check server logs).
|
|
84
|
+
|
|
85
|
+
**Check 2: Are the paths configured in the plugin?**
|
|
86
|
+
- Open your plugin's configuration settings.
|
|
87
|
+
- Confirm that the paths you're charting (e.g., `navigation.speedThroughWater`) are in the capture list.
|
|
88
|
+
|
|
89
|
+
**Check 3: Is there historical data available?**
|
|
90
|
+
- If the plugin was just installed, data will start recording from that moment forward.
|
|
91
|
+
- Charts will not show history for times before the plugin was enabled or the path configured for recording.
|
|
92
|
+
- Allow the plugin to record data for a while (days or weeks) before expecting deep history.
|
|
93
|
+
|
|
94
|
+
**Check 4: Is the chart time scale eligible?**
|
|
95
|
+
- Very short time scales (seconds) skip history seeding for performance.
|
|
96
|
+
- Use time scales of **minutes or longer** to enable history seeding.
|
|
97
|
+
|
|
98
|
+
**Check 5: Are there any network or permission issues?**
|
|
99
|
+
- Confirm that KIP can reach the Signal K server's History-API endpoint. Use the OpenApi link in the Server Admin pages to the test.
|
|
100
|
+
- Check browser console logs (F12) for any HTTP errors from history requests.
|
|
101
|
+
|
|
102
|
+
|
|
103
|
+
## Next Steps
|
|
104
|
+
|
|
105
|
+
1. Verify that a History-API plugin is installed on your Signal K server.
|
|
106
|
+
2. Configure the plugin to capture the paths you want to chart.
|
|
107
|
+
3. Wait for plugin to capture enough data to fill your Data Chart's time span.
|
|
108
|
+
4. Open a Data Chart or Wind Trends widget with a time scale of minutes or longer.
|
|
109
|
+
5. Allow the chart to load—history data will appear if available.
|
|
110
|
+
6. For more details, consult your plugin's documentation and the Signal K community resources.
|
|
111
|
+
|
|
112
|
+
|
|
113
|
+
## Questions or Issues?
|
|
114
|
+
|
|
115
|
+
- Refer to the plugin and History-API documentation for plugin-specific configuration and troubleshooting.
|
|
116
|
+
- For general questions or issues, see `Contact-Us` help page—the KIP community is active on Discord and GitHub.
|
|
@@ -2,15 +2,27 @@
|
|
|
2
2
|
{ "title": "The basics", "file": "welcome.md" },
|
|
3
3
|
{ "title": "Login & Configurations", "file": "configuration.md" },
|
|
4
4
|
{ "title": "Dashboards and Layout", "file": "dashboards.md" },
|
|
5
|
+
{ "title": "Data Inspector", "file": "datainspector.md" },
|
|
5
6
|
{ "title": "Chartplotter Mode", "file": "chartplotter.md" },
|
|
6
7
|
{ "title": "Zones, Notifications and Highlights", "file": "zones.md" },
|
|
7
|
-
{ "title": "Data Inspector", "file": "datainspector.md" },
|
|
8
8
|
{ "title": "Digital Switching and PUT", "file": "putcontrols.md" },
|
|
9
|
-
{ "title": "
|
|
10
|
-
{
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
9
|
+
{ "title": "Historical Widget Data", "file": "widget-historical-series.md" },
|
|
10
|
+
{
|
|
11
|
+
"title": "Integrations",
|
|
12
|
+
"items": [
|
|
13
|
+
{ "title": "Node-RED (Getting Started)", "file": "nodered-control-flows.md" },
|
|
14
|
+
{ "title": "The Embed Page Viewer", "file": "embedwidget.md" },
|
|
15
|
+
{ "title": "Using The History-API", "file": "history-api.md" },
|
|
16
|
+
{ "title": "Grafana Integration", "file": "grafana.md" },
|
|
17
|
+
{ "title": "InfluxDB and Signal K", "file": "influxdb.md" }
|
|
18
|
+
]
|
|
19
|
+
},
|
|
20
|
+
{
|
|
21
|
+
"title": "Advanced Features",
|
|
22
|
+
"items": [
|
|
23
|
+
{ "title": "Kiosk Mode", "file": "kiosk.md" }
|
|
24
|
+
]
|
|
25
|
+
},
|
|
14
26
|
{ "title": "Online Community Content", "file": "community.md" },
|
|
15
27
|
{ "title": "Contact Us", "file": "contact-us.md" }
|
|
16
28
|
]
|
|
@@ -0,0 +1,125 @@
|
|
|
1
|
+
## Node-RED Control Flows for KIP Widgets (Beginner Guide)
|
|
2
|
+
|
|
3
|
+
This guide is for first-time Node-RED users who want KIP control widgets to trigger real actions (like GPIO or relay switching) through Signal K. It is not a full Node-RED product guide or a complete flow-programming course. It focuses on the Signal K and KIP-specific parts you need for digital switching.
|
|
4
|
+
|
|
5
|
+
Before you start building flows, read **[Digital Switching and PUT Path Setup](putcontrols.md)** so you understand the core concepts, data flow, and control logic.
|
|
6
|
+
|
|
7
|
+
## What You Are Building
|
|
8
|
+
|
|
9
|
+
Use this sequence as your basic mental model:
|
|
10
|
+
|
|
11
|
+
KIP widget → Signal K path (PUT) → Node-RED **put handler** → action node (GPIO/relay/driver/Web Service/etc.)
|
|
12
|
+
|
|
13
|
+
This is the basic flow:
|
|
14
|
+
|
|
15
|
+
1. A KIP widget sends a value to a Signal K path (PUT).
|
|
16
|
+
2. Node-RED receives that path value through a **put handler** node.
|
|
17
|
+
3. Your flow converts or uses that value to perform the final action.
|
|
18
|
+
|
|
19
|
+
Think of Signal K as the shared data bus and Node-RED as the automation logic.
|
|
20
|
+
|
|
21
|
+
### Why You Need a PUT Handler in the Flow
|
|
22
|
+
|
|
23
|
+
To receive commands sent by KIP widgets, your flow needs a Signal K node named `put handler`.
|
|
24
|
+
|
|
25
|
+
Why it is needed:
|
|
26
|
+
- KIP writes values to Signal K paths using PUT.
|
|
27
|
+
- The `put handler` listens for PUT updates on those paths.
|
|
28
|
+
- Without it, your flow will not receive widget commands, so no action will run.
|
|
29
|
+
|
|
30
|
+
Where to find it:
|
|
31
|
+
- In Node-RED, open the **Signal K** node group.
|
|
32
|
+
- Add the node called **put handler** to your flow.
|
|
33
|
+
|
|
34
|
+
## Before You Start
|
|
35
|
+
|
|
36
|
+
Check these basics first:
|
|
37
|
+
|
|
38
|
+
1. KIP is connected and authenticated to Signal K.
|
|
39
|
+
2. You can see your target path in Data Inspector, unless you plan to create a new path with your flow.
|
|
40
|
+
3. The path type matches your widget type.
|
|
41
|
+
4. Your Node-RED environment can access target hardware (GPIO, relay board, Web Service, etc.).
|
|
42
|
+
|
|
43
|
+
## Safety First
|
|
44
|
+
|
|
45
|
+
Always test with non-critical outputs first.
|
|
46
|
+
|
|
47
|
+
- Start with a debug/test path or non-critical device before controlling live systems.
|
|
48
|
+
- Validate expected behavior in Data Browser and Data Inspector before switching real loads.
|
|
49
|
+
- Add safe defaults so outputs stay in a known state on startup/restart.
|
|
50
|
+
|
|
51
|
+
## 5-Minute First Success
|
|
52
|
+
|
|
53
|
+
Goal: prove the full command path works end-to-end (KIP → Signal K PUT → Node-RED `put handler` → value update).
|
|
54
|
+
|
|
55
|
+
1. In Node-RED, open **Import** (`Cmd+I` on Mac).
|
|
56
|
+
2. In **Examples**, go to: `flows -> @signalk/node-red-embedded -> put-handler`, then click **Import**.
|
|
57
|
+
3. Open the imported **put handler** node and note the path it listens to (default example: `self.red.autoLights.state`).
|
|
58
|
+
Leave defaults unchanged for this first test.
|
|
59
|
+
4. Click **Deploy**.
|
|
60
|
+
5. In KIP **Data Inspector**, search for `self.red.autoLights.state`.
|
|
61
|
+
- Confirm the path exists.
|
|
62
|
+
- Confirm **PUT Support** is enabled.
|
|
63
|
+
6. In KIP, add a **Switch Panel** widget:
|
|
64
|
+
- Add a **Toggle** control.
|
|
65
|
+
- Set the control path to `self.red.autoLights.state`.
|
|
66
|
+
- Save/apply widget settings.
|
|
67
|
+
7. Toggle ON/OFF in KIP and verify:
|
|
68
|
+
- The widget changes state without error notifications.
|
|
69
|
+
- The value updates in both Signal K Admin Data Browser and KIP Data Inspector.
|
|
70
|
+
- The updated value is visible in Node-RED under the **send autoLights** node (green status dot, e.g. **State: 1**).
|
|
71
|
+
|
|
72
|
+
Note that this example flow uses numeric `1/0` path values. For ON/OFF control, the preferred value type is `boolean` (`true/false`).
|
|
73
|
+
|
|
74
|
+
You can change this by double-clicking the **Inject** node labeled `1` and changing `msg.payload` type from `number` to `boolean`.
|
|
75
|
+
|
|
76
|
+
When changing an existing path type, restart Signal K so the path is recreated with the new type. Path types are not safely changed in-place during runtime.
|
|
77
|
+
|
|
78
|
+
Remember to click **Deploy** after any flow change.
|
|
79
|
+
|
|
80
|
+
If this works, your core control pipeline is correctly set up. You can now repeat the same pattern with different path values for Slider and Multi State Switch paths.
|
|
81
|
+
|
|
82
|
+
## Troubleshooting for Beginners
|
|
83
|
+
|
|
84
|
+
If something does not work, check these first.
|
|
85
|
+
|
|
86
|
+
### Widget changes value, but flow does not react
|
|
87
|
+
- Verify Node-RED is watching the same exact Signal K path.
|
|
88
|
+
- Verify your flow includes a Signal K **put handler** node and it is configured for the same path.
|
|
89
|
+
- Verify authentication/permissions and path visibility.
|
|
90
|
+
|
|
91
|
+
### Flow reacts, but hardware still does nothing
|
|
92
|
+
- Verify hardware node wiring, pin mapping, and runtime permissions.
|
|
93
|
+
- Test with a known manual value from Node-RED first.
|
|
94
|
+
|
|
95
|
+
### Multi State widget shows no options
|
|
96
|
+
- Metadata is incomplete for that path. Confirm `multiple` type and possible values list in Signal K metadata.
|
|
97
|
+
|
|
98
|
+
## Suggested Learning Path
|
|
99
|
+
|
|
100
|
+
Build in this order to keep setup simple.
|
|
101
|
+
|
|
102
|
+
1. Start with one boolean switch end-to-end.
|
|
103
|
+
2. Add one numeric slider flow.
|
|
104
|
+
3. Add one multi-state mode flow.
|
|
105
|
+
4. After each step, confirm path value in Data Inspector and physical result on hardware.
|
|
106
|
+
|
|
107
|
+
## Glossary (Beginner)
|
|
108
|
+
|
|
109
|
+
Use these terms consistently while setting up your flow.
|
|
110
|
+
|
|
111
|
+
- **PUT**: Writing a value to a Signal K path.
|
|
112
|
+
- **Path**: The Signal K key where a value is stored (for example `self.electrical.switches.bank.0.1.state`).
|
|
113
|
+
- **PUT Support**: Signal K metadata indicating a path handler will react to PUT writes.
|
|
114
|
+
- **put handler**: The Signal K Node-RED node that receives PUT writes from Signal K paths.
|
|
115
|
+
- **Metadata**: Extra path information such as type, units, possible values and more.
|
|
116
|
+
- **Possible values**: The allowed list of modes/states for a Multi State path.
|
|
117
|
+
|
|
118
|
+
## Related Guides
|
|
119
|
+
|
|
120
|
+
Use these guides next as needed.
|
|
121
|
+
|
|
122
|
+
- SignalK signalk-node-red: [Show and tell](https://github.com/SignalK/signalk-node-red/discussions/categories/show-and-tell)
|
|
123
|
+
- Path requirements and widget compatibility: [Digital Switching and PUT Path Setup](putcontrols.md)
|
|
124
|
+
- Finding paths and checking PUT support: [Data Inspector](datainspector.md)
|
|
125
|
+
- Adding and configuring widgets: [Dashboards and Layout](dashboards.md)
|
|
@@ -1,60 +1,101 @@
|
|
|
1
|
-
## Digital Switching and
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
1
|
+
## Digital Switching, Node-RED, and PUT
|
|
2
|
+
|
|
3
|
+
Use KIP digital switching controls when you want to do real actions from your dashboard, like turning devices on/off, changing levels, or selecting operating modes. This guide helps you choose the right Signal K path for Switch Panel, Slider, and Multi State Switch controls so they work reliably in daily use.
|
|
4
|
+
|
|
5
|
+
The focus here is practical KIP setup: what path type to use, what PUT support is needed, and how to avoid common configuration mistakes. This guide supports built-in server handlers, custom plugins, and Node-RED flows.
|
|
6
|
+
|
|
7
|
+
If you are new to Node-RED, start with this guide, then continue with **[Node-RED Control Flows for KIP Widgets (Beginner Guide)](nodered-control-flows.md)** for beginner flow examples.
|
|
8
|
+
|
|
9
|
+
## What PUT Does (and Does Not Do)
|
|
10
|
+
|
|
11
|
+
Start with this key idea:
|
|
12
|
+
|
|
13
|
+
PUT writes a value to a Signal K path. By itself, that write does not trigger hardware or system behavior. For actions to happen, a handler must be registered for that path. The handler reacts to the new value and performs the action. This handler capability is commonly called PUT Support.
|
|
14
|
+
|
|
15
|
+
Examples of server-side handlers:
|
|
16
|
+
- A built-in server handler
|
|
17
|
+
- A Signal K plugin (see [Popular Digital Switching Plugins](#popular-digital-switching-plugins))
|
|
18
|
+
- A Node-RED flow (see [Node-RED Control Flows for KIP Widgets (Beginner Guide)](nodered-control-flows.md))
|
|
19
|
+
|
|
20
|
+
## Basic Requirements
|
|
21
|
+
|
|
22
|
+
Check these basics first:
|
|
23
|
+
|
|
24
|
+
1. For security reasons, KIP must be authenticated against Signal K for the server to accept PUTs.
|
|
25
|
+
2. The target path must exist in Signal K and have metadata matching the digital switching widget type.
|
|
26
|
+
3. For control widgets that send commands, the path metadata must report that PUT Support is enabled.
|
|
27
|
+
4. The appropriate server-side handler must be present to react to value changes and control the targeted hardware.
|
|
28
|
+
|
|
29
|
+
## Verifying Path Configuration
|
|
30
|
+
|
|
31
|
+
Use this quick check before widget setup:
|
|
32
|
+
|
|
33
|
+
1. Open **Data Inspector**.
|
|
34
|
+
2. Search for your candidate path (for example `self.electrical.switches.bank.0.1.state`).
|
|
35
|
+
3. Confirm the path data type and whether **PUT Support** is enabled (a handler is registered).
|
|
36
|
+
4. For Multi State controls, confirm the path metadata includes possible values (use the Signal K Data Browser).
|
|
37
|
+
|
|
38
|
+
## Path Eligibility by Widget and Control Type
|
|
39
|
+
|
|
40
|
+
Use this table to match each control to the right path type.
|
|
41
|
+
|
|
42
|
+
| Widget / Control | Typical Path Type | PUT Required | Notes |
|
|
43
|
+
|---|---|---|---|
|
|
44
|
+
| Switch Panel → Toggle | `boolean` (preferred) or `number` (`1/0` mode) | Yes | Use **Use numeric path** only when your system expects numeric states. |
|
|
45
|
+
| Switch Panel → Push | `boolean` (preferred) or `number` (`1/0` mode) | Yes | Behaves like a momentary action style control. |
|
|
46
|
+
| Switch Panel → Indicator | `boolean` or `number` | No (display only) | Indicator is read-only visualization and does not send commands. |
|
|
47
|
+
| Slider | `number` | Yes | Best for ranges such as dimmer level or percentage setpoints. |
|
|
48
|
+
| Multi State Switch | `multiple` metadata type | Yes | Metadata should expose possible values so options can be shown. |
|
|
49
|
+
|
|
50
|
+
## Quick Setup Workflow
|
|
51
|
+
|
|
52
|
+
Follow these steps in order:
|
|
53
|
+
|
|
54
|
+
1. Install the required plugin or configure a Node-RED flow.
|
|
55
|
+
2. If you installed a new plugin, restart the server. If you created a Node-RED flow, make sure the flow is Deployed.
|
|
56
|
+
3. If using Node-RED, include a Signal K **put handler** node in your flow so widget commands are received.
|
|
57
|
+
4. Confirm path exists in Data Inspector.
|
|
58
|
+
5. Confirm type and PUT support are compatible with widget/control type.
|
|
59
|
+
6. Configure the widget in KIP.
|
|
60
|
+
7. Trigger the control and verify the value changes in Data Inspector.
|
|
61
|
+
8. Validate the server-side handler executes the expected real-world action.
|
|
62
|
+
|
|
63
|
+
## Popular Digital Switching Plugins
|
|
64
|
+
|
|
65
|
+
If you prefer plugin-based integrations instead of building your own flow logic, these are commonly used options in the Signal K ecosystem:
|
|
66
|
+
|
|
67
|
+
- **Shelly Gen 1 integrations**
|
|
68
|
+
- Commonly used to control Shelly Gen 1 relays, switches, and I/O modules.
|
|
69
|
+
- npm: [signalk-shelly](https://www.npmjs.com/package/signalk-shelly)
|
|
70
|
+
|
|
71
|
+
- **Shelly Gen 2+ integrations**
|
|
72
|
+
- Commonly used to control Shelly Gen 2+ smart devices relays, switches, and I/O modules.
|
|
73
|
+
- npm: [signalk-shelly2](https://www.npmjs.com/package/signalk-shelly2)
|
|
74
|
+
|
|
75
|
+
- **Sonoff integrations**
|
|
76
|
+
- Commonly used for eWeLink switches running the factory firmware.
|
|
77
|
+
- npm: [signalk-sonoff-ewelink](https://www.npmjs.com/package/signalk-sonoff-ewelink)
|
|
78
|
+
|
|
79
|
+
|
|
80
|
+
## Troubleshooting
|
|
81
|
+
|
|
82
|
+
If something does not work, check these first.
|
|
83
|
+
|
|
84
|
+
### Path does not appear in widget config
|
|
85
|
+
- Check type compatibility with the control you selected.
|
|
86
|
+
- Check **PUT Support** for controls that write values (all except Indicator).
|
|
87
|
+
|
|
88
|
+
### Value updates but hardware does nothing
|
|
89
|
+
- The PUT write is working, but no server-side action handler is registered, or the handler has an error.
|
|
90
|
+
- Verify plugin/flow/integration logic and server logs.
|
|
91
|
+
|
|
92
|
+
### Multi State options are empty
|
|
93
|
+
- Confirm the path metadata is type `multiple` and includes possible values.
|
|
94
|
+
|
|
95
|
+
## Related Guides
|
|
96
|
+
|
|
97
|
+
Use these guides next as needed.
|
|
98
|
+
|
|
99
|
+
- **Node-RED beginners:** [Node-RED Control Flows for KIP Widgets (Beginner Guide)](nodered-control-flows.md)
|
|
100
|
+
- **Path discovery and validation:** [Data Inspector](datainspector.md)
|
|
101
|
+
- **Widget overview and placement:** [Dashboards and Layout](dashboards.md)
|
|
@@ -10,8 +10,7 @@ KIP supports multiple input modes for seamless navigation across devices.
|
|
|
10
10
|
| Toggle Night mode | N/A | N/A | <kbd>Shift</kbd> + <kbd>Ctrl</kbd> + <kbd>N</kbd> |
|
|
11
11
|
| Toggle dashboard edit mode | N/A | N/A | <kbd>Shift</kbd> + <kbd>Ctrl</kbd> + <kbd>E</kbd> |
|
|
12
12
|
|
|
13
|
-
|
|
14
|
-
<br/>
|
|
13
|
+
> Note that the words Touch and Tap are synonymous with mouse click.
|
|
15
14
|
|
|
16
15
|
## General Layout
|
|
17
16
|
<img src="../../assets/help-docs/img/general-layout.png" alt="Sidebar Menus" title="Sidebar Menus" width="100%">
|
|
@@ -101,11 +100,11 @@ If multiple devices log in with the same Signal K user to share configuration, t
|
|
|
101
100
|
| Wrong device switched | Two devices share same Instance Name—rename one. |
|
|
102
101
|
| Works, then stops | Network drop or Signal K reconnect in progress—wait a few seconds or reload. |
|
|
103
102
|
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
103
|
+
> **Tips**
|
|
104
|
+
>- Keep Instance Names short but meaningful (e.g. Mast, Helm, NavTV).
|
|
105
|
+
>- For unattended displays, enable the browser’s keep‑awake / no‑sleep features if supported.
|
|
106
|
+
>- Combine with Night Mode + per‑profile layouts for role‑specific remote switching.
|
|
107
|
+
>- Use different Signal K users if you want fully isolated configurations.
|
|
109
108
|
|
|
110
109
|
### Privacy / Safety Note
|
|
111
110
|
Anyone with access to a logged‑in controlling KIP instance can switch dashboards on enabled targets. Only enable remote management on displays where that is acceptable.
|