@rhizomatics/signalk-einklabel-plugin 1.3.0-beta11 → 1.3.0-beta13
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/CHANGELOG.md +6 -0
- package/README.md +14 -543
- package/dist/config.d.ts +21 -5
- package/dist/config.js +101 -33
- package/dist/docs/templateReference.d.ts +18 -0
- package/dist/docs/templateReference.js +207 -0
- package/dist/repaintScheduler.js +23 -17
- package/dist/resolveApiUrl.js +3 -0
- package/docs/bluetooth.md +109 -0
- package/docs/cli.md +131 -0
- package/docs/examples/README.md +25 -0
- package/docs/examples/tide-clock.md +93 -0
- package/docs/examples/watch-schedule.md +37 -0
- package/docs/extending.md +33 -0
- package/docs/faq.md +40 -0
- package/docs/getting-started.md +111 -0
- package/docs/templates.md +142 -0
- package/package.json +5 -2
|
@@ -0,0 +1,109 @@
|
|
|
1
|
+
# Bluetooth
|
|
2
|
+
|
|
3
|
+
Advice for getting a reliable Bluetooth Low Energy (BLE) connection between the SignalK server and your labels.
|
|
4
|
+
|
|
5
|
+
Most of this applies to direct BlueZ mode only. If the "Use the SignalK BLE Manager API" setting is enabled, the adapter and its lifecycle are managed by the SignalK server, under its own Bluetooth admin settings, once for every BLE-consuming plugin.
|
|
6
|
+
|
|
7
|
+
## Choosing a Bluetooth Adapter
|
|
8
|
+
|
|
9
|
+
Only needed in direct BlueZ mode - in BLE Manager mode the adapter is whatever the SignalK server's own Bluetooth settings provide.
|
|
10
|
+
|
|
11
|
+
- Bluetooth adapters for Linux can be tricky
|
|
12
|
+
- TP-Link UB400 and Asus USB-BT500 are two well-known and available ones, though the ASUS USB-BT500 one can have problems with some Pi type boards (see [Adapter stops responding](#adapter-stops-responding-no-gpio-to-reset))
|
|
13
|
+
- CSR4.0 dongles (CSR8510 chip) have had kernel support for years, and there are well known work arounds for some of them, including in the Linux kernel since v5.17
|
|
14
|
+
- Some Raspberry Pi models come with suitable Bluetooth built in
|
|
15
|
+
- See advice at [Recommended Bluetooth Adapters for Linux](https://github.com/morrownr/USB-WiFi/blob/main/home/Recommended_Bluetooth_Adapters_for_Linux.md)
|
|
16
|
+
- Bluetooth adapters typically prefer being in USB2.0 ports rather than USB3.0 ports, since often the USB3.0 implementation leaks radio energy on the same 2.4Ghz spectrum as Bluetooth. If no USB2.0 port available, try a shielded USB2.0 extension lead to distance the dongle from the port. Some dongle manufacturees seems to do a better job at shielding for this than others.
|
|
17
|
+
|
|
18
|
+
> - Don't worry about the very latest Bluetooth versions, 4.0 is minimum for BLE, 5.0 is nice
|
|
19
|
+
> - Home Assistant is massively more popular than SignalK, and often also run on Raspberry Pi and similar, so good source of advice
|
|
20
|
+
|
|
21
|
+
## Weak Signal
|
|
22
|
+
|
|
23
|
+
If the label is too far from the SignalK server's adapter, try a BLE proxy device - ESP32 is popular for this - or, with the BLE Manager API, a remote BLE gateway.
|
|
24
|
+
|
|
25
|
+
## Bluetooth Plugins Impacting Each Other
|
|
26
|
+
|
|
27
|
+
Bluetooth plugins can kick off scanning, and otherwise interfere with each other. Worst case is when plugins attempt to connect directly to Bluetooth adapters. Better is when they connect using `bluez` and `dbus` Linux components, and best of all when they use the SignalK BLE Manager added in 2026.
|
|
28
|
+
|
|
29
|
+
If you're having problems with Bluetooth connections, make sure other plugins are well behaved, using BLE Manager where they can, and consider temporarily switching them off if needed to debug label connections.
|
|
30
|
+
|
|
31
|
+
## Stuck Bluetooth Adapters
|
|
32
|
+
|
|
33
|
+
Sometime Bluetooth adapters, and/or the Linux services that use them, can get into a 'stuck' state, where the only solution is to reboot the server (although unplugging and plugging the dongle may help). The best way to avoid this is using a known good dongle, and using BLE Manager in SignalK wherever possible.
|
|
34
|
+
|
|
35
|
+
## Tuning Bluetooth Connections
|
|
36
|
+
|
|
37
|
+
Labels spend most of their time asleep, so they can be slow to accept a connection, and slow to answer while an image is being sent to them. Linux's Bluetooth defaults are set with phones, headphones and sensors in mind, so if connections to labels regularly time out, or drop partway through a repaint (for example with GATT or connection-abort errors in the log), some Bluetooth settings on the server may need adjusting:
|
|
38
|
+
|
|
39
|
+
- **The plugin's own timeouts** - the _Paint connect timeout_ and _Paint retries_, set plugin-wide or per label (see [Setting up a Label](getting-started.md#setting-up-a-label)). Try these first, since they only affect this plugin.
|
|
40
|
+
- **BlueZ's connection settings**, in the `[LE]` section of `/etc/bluetooth/main.conf` - the connection interval range (`MinConnectionInterval`/`MaxConnectionInterval`), how long a quiet connection is kept before it's dropped (`ConnectionSupervisionTimeout`), and how long a connection attempt waits (`Autoconnecttimeout`). The file's own comments describe each one. Restart the Bluetooth service after changing it.
|
|
41
|
+
- **The kernel's Bluetooth settings** for the adapter, under `/sys/kernel/debug/bluetooth/hci0/` - such as `supervision_timeout`, `conn_min_interval` and `conn_max_interval`. Values written here are lost on reboot, unless something re-applies them at startup.
|
|
42
|
+
|
|
43
|
+
These apply whenever the server's Bluetooth goes through BlueZ, including the SignalK BLE Manager with a local adapter. They affect every Bluetooth device the server talks to, not just labels, so change one thing at a time and check that your other Bluetooth equipment still works.
|
|
44
|
+
|
|
45
|
+
No particular values are recommended here - what works depends on the adapter, the labels and whatever else is using Bluetooth. Get advice before changing them, for example from the [SignalK community](https://signalk.org) or Home Assistant's Bluetooth community, where many of the same adapters and Linux setups are used.
|
|
46
|
+
|
|
47
|
+
## SignalK starts before the Bluetooth daemon
|
|
48
|
+
|
|
49
|
+
This and the next section are about direct BlueZ mode only - if the "Use the SignalK BLE Manager API" setting is enabled, adapter/dongle lifecycle is the SignalK server's problem to manage once, for every BLE-consuming plugin, not this plugin's.
|
|
50
|
+
|
|
51
|
+
The plugin retries BLE adapter initialisation with backoff (starting at 2s, capping at 30s) if `bluetoothd`/D-Bus isn't up yet when the plugin starts, so a slow-starting Bluetooth stack on boot will no longer strand it — it keeps retrying until the adapter appears rather than failing once and giving up. You'll see `BLE adapter not ready … — retrying in Ns …` in the SignalK logs in the meantime.
|
|
52
|
+
|
|
53
|
+
That said, it's cleaner to fix the boot ordering at the systemd level so the plugin finds the adapter ready on its first attempt. If SignalK runs as a systemd service (`systemctl status signalk`) and its unit file has no `[Unit]` section (check with `systemctl cat signalk`), add one:
|
|
54
|
+
|
|
55
|
+
```bash
|
|
56
|
+
sudo systemctl edit signalk.service
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
This opens an override file — add:
|
|
60
|
+
|
|
61
|
+
```ini
|
|
62
|
+
[Unit]
|
|
63
|
+
After=bluetooth.target
|
|
64
|
+
Wants=bluetooth.target
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
Save and exit, then:
|
|
68
|
+
|
|
69
|
+
```bash
|
|
70
|
+
sudo systemctl daemon-reload
|
|
71
|
+
sudo systemctl restart signalk
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
This tells systemd to start `bluetoothd` first and wait for it before starting SignalK, rather than relying on both racing to start in parallel at boot.
|
|
75
|
+
|
|
76
|
+
## Adapter stops responding: "No gpio to reset"
|
|
77
|
+
|
|
78
|
+
Example log:
|
|
79
|
+
|
|
80
|
+
```
|
|
81
|
+
Bluetooth: hci0: No gpio to reset Realtek device, ignoring
|
|
82
|
+
Bluetooth: hci0: Unable to disable scanning: -110
|
|
83
|
+
Bluetooth: hci0: command 0x2042 tx timeout
|
|
84
|
+
Bluetooth: hci0: Opcode 0x2042 failed: -110
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
This happens when USB autosuspend cycles the dongle in and out of low-power suspend while idle. When bluetoothd sends an HCI command while the device is suspended or mid-resume, it never gets answered — adapters like the popular ASUS USB-500 lack a GPIO to allow reset and its stuck, and spams logs.
|
|
88
|
+
|
|
89
|
+
### Example udev rule fix
|
|
90
|
+
|
|
91
|
+
> [!Note]
|
|
92
|
+
> In these examples the dongle is for vendor `0b05` and product `190e`, adapt for your own devices, use `lsusb` to find out, and if there's no `lsusb` command, install the `usbutils` package.
|
|
93
|
+
|
|
94
|
+
Following file created at `/etc/udev/rules.d/99-bt500-no-autosuspend.rules`
|
|
95
|
+
|
|
96
|
+
```
|
|
97
|
+
# Disable USB autosuspend for the ASUS USB-BT500 (RTL8761BU, 0b05:190e).
|
|
98
|
+
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0b05", ATTR{idProduct}=="190e", TEST=="power/control", ATTR{power/control}="on"
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
### Example tlp fix
|
|
102
|
+
|
|
103
|
+
If `tlp` running to minimize power, it may have its own rules trying to suspend the Bluetooth dongle.
|
|
104
|
+
|
|
105
|
+
Following file created at /etc/tlp.d/99-bt500-no-autosuspend.conf
|
|
106
|
+
|
|
107
|
+
```
|
|
108
|
+
USB_DENYLIST="0b05:190e"
|
|
109
|
+
```
|
package/docs/cli.md
ADDED
|
@@ -0,0 +1,131 @@
|
|
|
1
|
+
# Command Line Interface
|
|
2
|
+
|
|
3
|
+
To get fast feedback on templates and shelf devices without updating and configuring SignalK, a CLI call `esl-cli` is provided when the module is manually installed (see [Using Outside of SignalK](getting-started.md#using-outside-of-signalk)) that has these commands. Use `--help` to get all the options.
|
|
4
|
+
|
|
5
|
+
- `vendors` - list supported vendors
|
|
6
|
+
- `scan` - report supported devices found from a BLE scan
|
|
7
|
+
- `render` - transform an SVG template and data into a PNG
|
|
8
|
+
- `paint` - render an SVG template and data to a selected ESL
|
|
9
|
+
- `fields` and `field` - see [Debugging Templates](#debugging-templates)
|
|
10
|
+
|
|
11
|
+
The width, height, vertical offset and colour palette for the device are taken from the internal register of devices, however can be overridden on the command line with `-w/--width`, `--height`, `--voffset` and `--colours`. This could be used to help you choose what size of label to buy, or to get an unsupported label working.
|
|
12
|
+
|
|
13
|
+
Left unset, both `render` and `paint` default `-w/--width`/`--height` to the template's own declared `width`/`height` (or `viewBox`) - neither command connects to a device just to size the render, since that would mean an extra BLE connect ahead of `paint`'s own, and doing two back-to-back is exactly the kind of churn that trips real BLE hardware.
|
|
14
|
+
|
|
15
|
+
`paint` also takes `--reframe <mode>`, applied once it has connected and identified the device, for when the rendered image doesn't come out the same size as its actual panel (see [Reframing](templates.md#reframing)):
|
|
16
|
+
|
|
17
|
+
- `crop` (default) - keeps pixels 1:1, placed from the top-left; a bigger render is truncated to fit, a smaller one leaves the extra panel space blank
|
|
18
|
+
- `scale` - stretches the rendered image onto the panel's exact dimensions (independently per axis, not preserving aspect ratio)
|
|
19
|
+
- `fixed` - no adjustment; rejects a size mismatch with an error instead
|
|
20
|
+
|
|
21
|
+
The main SignalK plugin offers the same choice per device (defaulting to `crop` there too) in each device's own config - "If the render doesn't match the panel size".
|
|
22
|
+
|
|
23
|
+
`paint` has matching options for the other per-label image settings too (see [Other Image Options](templates.md#other-image-options)):
|
|
24
|
+
|
|
25
|
+
- `--mirror <mode>` - `none` (default), `horizontal`, `vertical`, or `both` (rotate 180°). `render` also takes `--mirror`, to preview the flip as a PNG without a label
|
|
26
|
+
- `--no-compress` - send the image uncompressed, to rule compression out if a label won't update
|
|
27
|
+
- `--compression-format <format>` - `auto` (default) or `chunked`, to try the experimental compressed format on a Gicisky 4.2" BWR
|
|
28
|
+
|
|
29
|
+
`esl-cli` can also be extended with new subcommands - see [Extending](extending.md#cli-commands).
|
|
30
|
+
|
|
31
|
+
( The CLI can also be run from a checked out module, or by opening a terminal shell at `~/.signalk/node_modules/@rhizomatics/signalk-einklabel-plugin`, as `npx esl-cli command --args` )
|
|
32
|
+
|
|
33
|
+
## Scans from CLI
|
|
34
|
+
|
|
35
|
+
The command line tools, run from inside the `.signalk` directory, can be used to help troubleshoot
|
|
36
|
+
|
|
37
|
+
- Scan for longer, in this example 90 seconds
|
|
38
|
+
- `npx esl-cli scan -d 90`
|
|
39
|
+
- Scan for all BLE devices, whatever they are
|
|
40
|
+
- `npx esl-cli scan -a`
|
|
41
|
+
|
|
42
|
+
## Debugging Templates
|
|
43
|
+
|
|
44
|
+
The `esl-cli` can be used to debug and validate templates quickly:
|
|
45
|
+
|
|
46
|
+
- `render` - Render templates with SignalK data and write to a local PNG file
|
|
47
|
+
- `paint` - Render templates with SignalK data and send to selected ESL device
|
|
48
|
+
- `fields` - List the fields in the template, with the source specification and the rendered data value
|
|
49
|
+
- `field` - Accept a source specification (outside of any template context) and return the rendered value if available
|
|
50
|
+
|
|
51
|
+
Use `--help` to get the full set of arguments for any of the commands.
|
|
52
|
+
|
|
53
|
+
## CLI Examples
|
|
54
|
+
|
|
55
|
+
### Paint Image Directly
|
|
56
|
+
|
|
57
|
+
The label address previously discovered via `esl-cli scan`
|
|
58
|
+
|
|
59
|
+
```bash
|
|
60
|
+
npx esl-cli paint -t templates/tides/250x128-BWRY.svg -a FF:FF:92:84:53:93
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
If the label turns out to be a different size than the template (e.g. it's a 250x128 template on a 416x240 panel), it's cropped to fit by default - add `--reframe scale` to stretch it instead:
|
|
64
|
+
|
|
65
|
+
```bash
|
|
66
|
+
npx esl-cli paint -t templates/tides/250x128-BWRY.svg -a FF:FF:92:84:53:93 --reframe scale
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
If a label doesn't update, try sending it uncompressed to see whether compression is the cause:
|
|
70
|
+
|
|
71
|
+
```bash
|
|
72
|
+
npx esl-cli paint -t templates/tides/250x128-BWRY.svg -a FF:FF:92:84:53:93 --no-compress
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
If the image comes out mirrored, try each `--mirror` mode until it looks right, then set the same _Mirror_ option in the label's config:
|
|
76
|
+
|
|
77
|
+
```bash
|
|
78
|
+
npx esl-cli paint -t templates/tides/250x128-BWRY.svg -a FF:FF:92:84:53:93 --mirror horizontal
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
### Test Template Without Updating Label
|
|
82
|
+
|
|
83
|
+
This will work even if you don't have a label, or even bluetooth. (The `-u` can be left out if your SignalK server running locally on default ports).
|
|
84
|
+
|
|
85
|
+
```bash
|
|
86
|
+
npx esl-cli render -t templates/tides/250x128-BWRY.svg -o example.png -u http://localhost
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
and this version will work even without a running SignalK server, using some pre-packaged example data:
|
|
90
|
+
|
|
91
|
+
```bash
|
|
92
|
+
npx esl-cli render -t templates/tides/250x128-BWRY.svg -o example.png -e examples
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
### List all Fields and Rendered Values
|
|
96
|
+
|
|
97
|
+
```bash
|
|
98
|
+
npx esl-cli fields -t templates/tide.svg -u http://localhost
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
```
|
|
102
|
+
id spec value
|
|
103
|
+
station.name source=resources,resource=tides,provider=tides,path=station.name Tobermory
|
|
104
|
+
source.name. source=resources,resource=tides,provider=tides,path=station.source.name TICON-4
|
|
105
|
+
last_repaint source=einklabel,path=repainted,format=local_datetime_short 30 Jun 26 00:08
|
|
106
|
+
extremes.0 source=resources,resource=tides,provider=tides,path=extremes[0].label Low
|
|
107
|
+
extremes.1 source=resources,resource=tides,provider=tides,path=extremes[1].label High
|
|
108
|
+
extremes.2 source=resources,resource=tides,provider=tides,path=extremes[2].label Low
|
|
109
|
+
timezoneRegion source=einklabel,path=local_zone BST
|
|
110
|
+
lat source=resources,resource=tides,provider=tides,path=station.datums.LAT,category=depth 0.2m
|
|
111
|
+
hat source=resources,resource=tides,provider=tides,path=station.datums.HAT,category=depth 5.2m
|
|
112
|
+
extremes.2.level source=resources,resource=tides,provider=tides,path=extremes[2].level,category=depth 1.1m
|
|
113
|
+
extremes.2.time source=resources,resource=tides,provider=tides,path=extremes[2].time,format=local_time 13:15
|
|
114
|
+
extremes.1.level source=resources,resource=tides,provider=tides,path=extremes[1].level,category=depth 3.8m
|
|
115
|
+
extremes.1.time source=resources,resource=tides,provider=tides,path=extremes[1].time,format=local_time 07:05
|
|
116
|
+
extremes.0.time source=resources,resource=tides,provider=tides,path=extremes[0].time,format=local_time 01:21
|
|
117
|
+
extremes.0.time-8 source=resources,resource=tides,provider=tides,path=extremes[0].time,format=day_mon 30 Jun
|
|
118
|
+
extremes.0.time-8-5 source=resources,resource=tides,provider=tides,path=extremes[1].time,format=day_mon 30 Jun
|
|
119
|
+
extremes.0.time-8-9 source=resources,resource=tides,provider=tides,path=extremes[2].time,format=day_mon 30 Jun
|
|
120
|
+
extremes.0.level source=resources,resource=tides,provider=tides,path=extremes[0].level,category=depth 1.3m
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
## Offline Working
|
|
124
|
+
|
|
125
|
+
`render` and `paint` need a `--url` argument to point to the SignalK server to retrieve data. If you don't have access to one, you can use `--example-data` or `-e` to point to a directory of example data, which is bundled with the plugin or available in GitHub at [examples](https://github.com/rhizomatics/signalk-einklabel-plugin/tree/main/examples). This also allows you to write templates for resource APIs that aren't available yet.
|
|
126
|
+
|
|
127
|
+
- `vessels.json` - The standard SignalK vessel paths
|
|
128
|
+
- `resources/xxxx.json` - The output of the `xxxx` resources API call
|
|
129
|
+
- `categories.json` - SignalK unit categories needed for `category=depth` type formatting
|
|
130
|
+
|
|
131
|
+
For example, `npx esl-cli fields -t templates/tide.svg -e examples` will show all the field data that will be populated from the example API, vessel and category data in the `examples` local directory.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# Examples
|
|
2
|
+
|
|
3
|
+
The plugin comes with ready-made templates for these examples. Pick one as a label's _Template_ in the plugin config, or copy it into your own templates directory as a starting point - see [Templates](../templates.md).
|
|
4
|
+
|
|
5
|
+
- [Tide Clock](tide-clock.md) - the next few high and low tides, with the moon phase
|
|
6
|
+
- [Watch Schedule](watch-schedule.md) - who's on watch now and next
|
|
7
|
+
|
|
8
|
+
## Bundled Templates
|
|
9
|
+
|
|
10
|
+
Every bundled template, with its sizes and the data it needs. Each example's page lists the exact labels each size fits and every field it reads.
|
|
11
|
+
|
|
12
|
+
<!-- BEGIN GENERATED: templates-summary -->
|
|
13
|
+
<!-- Generated from the bundled templates by `npm run docs:templates` - do not edit by hand. -->
|
|
14
|
+
|
|
15
|
+
| Template | Sizes | Data needed |
|
|
16
|
+
| ---------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
17
|
+
| [`tide.svg`](tide-clock.md) | 416×240 | `tides` resource (provider `tides`), Signal K `environment.moon.phaseName` |
|
|
18
|
+
| [`tides`](tide-clock.md) | 416×240, 296×128, 250×128 | `tides` resource (provider `tides`), Signal K `environment.moon.phaseName` |
|
|
19
|
+
| [`watch`](watch-schedule.md) | 416×240 | Signal K `watch.current.endTime`, `watch.current.startTime`, `watch.current.teamName`, `watch.next.endTime`, `watch.next.startTime`, `watch.next.teamName`, `watch.system.name` |
|
|
20
|
+
|
|
21
|
+
<!-- END GENERATED -->
|
|
22
|
+
|
|
23
|
+
## Trying Examples Without a Boat
|
|
24
|
+
|
|
25
|
+
Each template can be rendered to a PNG with the CLI using the bundled example data, with no SignalK server or label needed - see [Test Template Without Updating Label](../cli.md#test-template-without-updating-label).
|
|
@@ -0,0 +1,93 @@
|
|
|
1
|
+
# Tide Clock
|
|
2
|
+
|
|
3
|
+

|
|
4
|
+
|
|
5
|
+
Template available as 416x240-BWRY for 3.7" ESLs and a simpler template, sized 250x128, also BWRY, for the cheapest 2.13" labels.
|
|
6
|
+
|
|
7
|
+
This mini tide clock is a 2.9" Gicisky device, less than £10 inc delivery in summer 2026.
|
|
8
|
+
|
|
9
|
+

|
|
10
|
+
|
|
11
|
+
## Pre-requisites
|
|
12
|
+
|
|
13
|
+
A _tides_ provider plugin for the Resources API installed and enabled, currently one of:
|
|
14
|
+
|
|
15
|
+
- [signalk-tides](https://github.com/openwatersio/signalk-tides) - uses [neaps](https://github.com/openwatersio/neaps) library for international off-line coverage
|
|
16
|
+
- [signalk-mareas-ihm](https://github.com/Aitonos/signalk-mareas-ihm) - interfaces with official Spanish IHM tidal predictions, or falls back to Open Meteo and _signalk-tides_
|
|
17
|
+
|
|
18
|
+
For versions with the moon phases:
|
|
19
|
+
|
|
20
|
+
- [signalk-derived-data](https://github.com/SignalK/signalk-derived-data) - unlike other plugins, this publishes lunar and solar facts as SignalK paths
|
|
21
|
+
|
|
22
|
+
The moon phase is optional - without it, the moon icon is simply left blank and the rest of the tide clock still shows.
|
|
23
|
+
|
|
24
|
+
The [tides](https://github.com/rhizomatics/signalk-einklabel-plugin/blob/main/templates/tides/) templates can be customized to run with any tide provider, a specific one, or switch to other APIs or SignalK data paths.
|
|
25
|
+
|
|
26
|
+
- In the template it uses a SVG description like `source=resources,resource=tides,provider=tides,path=extremes[0].time,format=local_time` to get the first tide time, ensures it's the preferred `signalk-tides` provider and makes it a simple local time rather than a UTC date-time.
|
|
27
|
+
|
|
28
|
+
To show the lunar phase, the `environment.moon.phaseName` path is required, which can be easily achieved by installing and configuring the `derived-data` plugin.
|
|
29
|
+
|
|
30
|
+
> [!TIP]
|
|
31
|
+
> If testing this without a boat, you'll need another plugin to provide `navigation.position` and `navigation.datetime` to make the moon and tide calcuations work. [signalk-datetime](https://github.com/tmcolby/signalk-datetime) can be configured for the datetime, and [signalk-sailboat-simulator](https://github.com/macjl/signalk-sailboat-simulator) for the postion; other ways may work too.
|
|
32
|
+
|
|
33
|
+
## Template Reference
|
|
34
|
+
|
|
35
|
+
The `tides` template family picks the best size for each label automatically - see [Template Families](../templates.md#template-families-multiple-panel-sizescolours).
|
|
36
|
+
|
|
37
|
+
<!-- BEGIN GENERATED: template-reference tides -->
|
|
38
|
+
<!-- Generated from the bundled templates by `npm run docs:templates` - do not edit by hand. -->
|
|
39
|
+
|
|
40
|
+
**Template:** `tides`
|
|
41
|
+
|
|
42
|
+
| File | Size (px) | Aspect ratio | Colours | Fits these labels exactly |
|
|
43
|
+
| ------------------------------------------------------------------------------------------------------------------------------ | --------- | ------------ | ------------------------- | ------------------------------------------------------------------------ |
|
|
44
|
+
| [`tides/416x240-BWRY.svg`](https://github.com/rhizomatics/signalk-einklabel-plugin/blob/main/templates/tides/416x240-BWRY.svg) | 416 × 240 | 1.73 : 1 | black, white, red, yellow | Zhsunyco 3.7" BWRY |
|
|
45
|
+
| [`tides/296x128-BWRY.svg`](https://github.com/rhizomatics/signalk-einklabel-plugin/blob/main/templates/tides/296x128-BWRY.svg) | 296 × 128 | 2.31 : 1 | black, white, red, yellow | Zhsunyco 2.9" BWRY, Gicisky 2.9" BW, Gicisky 2.9" BWR, Gicisky 2.9" BWRY |
|
|
46
|
+
| [`tides/250x128-BWRY.svg`](https://github.com/rhizomatics/signalk-einklabel-plugin/blob/main/templates/tides/250x128-BWRY.svg) | 250 × 128 | 1.95 : 1 | black, white, red, yellow | Zhsunyco 2.13" BWRY, Gicisky 2.1" BWR |
|
|
47
|
+
|
|
48
|
+
**Data used**
|
|
49
|
+
|
|
50
|
+
| Source | Path | Options | Used in |
|
|
51
|
+
| ----------------------------------- | ---------------------------- | ------------------------------------- | -------------------------- |
|
|
52
|
+
| `tides` resource (provider `tides`) | `extremes[n].label` | - | all |
|
|
53
|
+
| `tides` resource (provider `tides`) | `extremes[n].level` | category `depth` | all |
|
|
54
|
+
| `tides` resource (provider `tides`) | `extremes[n].time` | format `local_time`, format `day_mon` | all |
|
|
55
|
+
| `tides` resource (provider `tides`) | `station.datums.HAT` | category `depth`, round 1 | 416x240-BWRY |
|
|
56
|
+
| `tides` resource (provider `tides`) | `station.datums.LAT` | category `depth`, round 1 | 416x240-BWRY |
|
|
57
|
+
| `tides` resource (provider `tides`) | `station.name` | - | all |
|
|
58
|
+
| `tides` resource (provider `tides`) | `station.source.name` | - | 416x240-BWRY, 296x128-BWRY |
|
|
59
|
+
| Plugin | `local_zone` | - | 416x240-BWRY, 296x128-BWRY |
|
|
60
|
+
| Plugin | `plugin_version` | - | 416x240-BWRY |
|
|
61
|
+
| Plugin | `repainted` | format `local_datetime_short` | all |
|
|
62
|
+
| Signal K path | `environment.moon.phaseName` | image from `lunar_phases` | 416x240-BWRY |
|
|
63
|
+
|
|
64
|
+
<!-- END GENERATED -->
|
|
65
|
+
|
|
66
|
+
The original single-file version is also still available as `tide.svg`:
|
|
67
|
+
|
|
68
|
+
<!-- BEGIN GENERATED: template-reference tide.svg -->
|
|
69
|
+
<!-- Generated from the bundled templates by `npm run docs:templates` - do not edit by hand. -->
|
|
70
|
+
|
|
71
|
+
**Template:** `tide.svg`
|
|
72
|
+
|
|
73
|
+
| File | Size (px) | Aspect ratio | Colours | Fits these labels exactly |
|
|
74
|
+
| -------------------------------------------------------------------------------------------------- | --------- | ------------ | ------- | ------------------------- |
|
|
75
|
+
| [`tide.svg`](https://github.com/rhizomatics/signalk-einklabel-plugin/blob/main/templates/tide.svg) | 416 × 240 | 1.73 : 1 | - | Zhsunyco 3.7" BWRY |
|
|
76
|
+
|
|
77
|
+
**Data used**
|
|
78
|
+
|
|
79
|
+
| Source | Path | Options |
|
|
80
|
+
| ----------------------------------- | ---------------------------- | ------------------------------------- |
|
|
81
|
+
| `tides` resource (provider `tides`) | `extremes[n].label` | - |
|
|
82
|
+
| `tides` resource (provider `tides`) | `extremes[n].level` | category `depth` |
|
|
83
|
+
| `tides` resource (provider `tides`) | `extremes[n].time` | format `local_time`, format `day_mon` |
|
|
84
|
+
| `tides` resource (provider `tides`) | `station.datums.HAT` | category `depth`, round 1 |
|
|
85
|
+
| `tides` resource (provider `tides`) | `station.datums.LAT` | category `depth`, round 1 |
|
|
86
|
+
| `tides` resource (provider `tides`) | `station.name` | - |
|
|
87
|
+
| `tides` resource (provider `tides`) | `station.source.name` | - |
|
|
88
|
+
| Plugin | `local_zone` | - |
|
|
89
|
+
| Plugin | `plugin_version` | - |
|
|
90
|
+
| Plugin | `repainted` | format `local_datetime_short` |
|
|
91
|
+
| Signal K path | `environment.moon.phaseName` | image from `lunar_phases` |
|
|
92
|
+
|
|
93
|
+
<!-- END GENERATED -->
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
# Watch Schedule
|
|
2
|
+
|
|
3
|
+

|
|
4
|
+
|
|
5
|
+
Template available as 416x240-BWRY for 3.7" ESLs.
|
|
6
|
+
|
|
7
|
+
## Pre-requisites
|
|
8
|
+
|
|
9
|
+
- Source of `watch.current` and `watch.next` values
|
|
10
|
+
- `signalk-watch-schedule` plugin
|
|
11
|
+
|
|
12
|
+
## Template Reference
|
|
13
|
+
|
|
14
|
+
<!-- BEGIN GENERATED: template-reference watch -->
|
|
15
|
+
<!-- Generated from the bundled templates by `npm run docs:templates` - do not edit by hand. -->
|
|
16
|
+
|
|
17
|
+
**Template:** `watch`
|
|
18
|
+
|
|
19
|
+
| File | Size (px) | Aspect ratio | Colours | Fits these labels exactly |
|
|
20
|
+
| ------------------------------------------------------------------------------------------------------------------------------ | --------- | ------------ | ------------------------- | ------------------------- |
|
|
21
|
+
| [`watch/416x240-BWRY.svg`](https://github.com/rhizomatics/signalk-einklabel-plugin/blob/main/templates/watch/416x240-BWRY.svg) | 416 × 240 | 1.73 : 1 | black, white, red, yellow | Zhsunyco 3.7" BWRY |
|
|
22
|
+
|
|
23
|
+
**Data used**
|
|
24
|
+
|
|
25
|
+
| Source | Path | Options |
|
|
26
|
+
| ------------- | ------------------------- | ----------------------------- |
|
|
27
|
+
| Plugin | `plugin_version` | - |
|
|
28
|
+
| Plugin | `repainted` | format `local_datetime_short` |
|
|
29
|
+
| Signal K path | `watch.current.endTime` | format `local_time` |
|
|
30
|
+
| Signal K path | `watch.current.startTime` | format `local_time` |
|
|
31
|
+
| Signal K path | `watch.current.teamName` | - |
|
|
32
|
+
| Signal K path | `watch.next.endTime` | format `local_time` |
|
|
33
|
+
| Signal K path | `watch.next.startTime` | format `local_time` |
|
|
34
|
+
| Signal K path | `watch.next.teamName` | - |
|
|
35
|
+
| Signal K path | `watch.system.name` | - |
|
|
36
|
+
|
|
37
|
+
<!-- END GENERATED -->
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# Extending
|
|
2
|
+
|
|
3
|
+
## Architecture
|
|
4
|
+
|
|
5
|
+
The primary things managed and provided by the plugin are:
|
|
6
|
+
|
|
7
|
+
- ESL Vendor
|
|
8
|
+
- Sub-package per vendor
|
|
9
|
+
- ESL Device
|
|
10
|
+
- Metadata in the vendor package, using a `pid` or sometimes `pid` combined with `hwid` in the BLE results to pinpoint a model
|
|
11
|
+
- SVG Template
|
|
12
|
+
- SignalK API base URL
|
|
13
|
+
- Used for automatic unit conversion on `signalk`-sourced numeric values and for resolving an explicit `category=` binding - neither has an in-process equivalent, both go via this server's own REST API
|
|
14
|
+
- Optional: left blank, the plugin probes the probable values in likelihood order at startup - `http://localhost:3000`, `http://localhost`, `https://localhost`. Set it explicitly to skip probing
|
|
15
|
+
- Either way, errors clearly if nothing responds (wrong port) or the probe is rejected (anonymous read access not enabled) - these endpoints must allow anonymous read access, since the plugin has no login flow
|
|
16
|
+
|
|
17
|
+
## Hardware
|
|
18
|
+
|
|
19
|
+
Additional vendors and devices can be added by a separate npm package that implements the `VendorDriver` interface and registers itself - there's no scanning of installed packages, registration is always an explicit call by the extension's own code.
|
|
20
|
+
|
|
21
|
+
- `import esl from '@rhizomatics/signalk-einklabel-plugin'; esl.registerVendorDriver(myDriver)`
|
|
22
|
+
- In the SignalK runtime, call this from the extension's own plugin `start()`. In the CLI, load the extension with `esl-cli --require <module> <command>`.
|
|
23
|
+
- Declare this package as a regular npm `dependency` in the extension package - **not** a `peerDependency`, per SignalK's own guidance that npm's peer-dependency resolution interacts poorly with the server's plugin install layout - and declare the SignalK-level relationship via `"signalk": { "requires": ["@rhizomatics/signalk-einklabel-plugin"] }` in the extension's own `package.json` instead, so the App Store can install/report it.
|
|
24
|
+
|
|
25
|
+
## Template Providers
|
|
26
|
+
|
|
27
|
+
An alternative way to produce a device's content, alongside hand-authored SVG templates, can be added the same way - `esl.registerTemplateProvider({ suffix, listTemplates, render })`, from a separate package's own plugin `start()` (or `esl-cli --require <module>`). This is what [`@rhizomatics/signalk-einklabel-genai-plugin`](templates.md#genai-rendering) is: `listTemplates()` returns the entries it currently offers (already including its own `suffix`, e.g. `"forecast (GenAI)"`) for the "Template" dropdown, and `render(request)` - given the same signalk/resources/label context any SVG template's bindings get - returns a `Bitmap`, exactly as `SvgRenderer.render()` would. Rejecting from `render()` routes the repaint through this plugin's own generic fallback-warning template, the same as a broken hand-authored template failing to render.
|
|
28
|
+
|
|
29
|
+
`esl.SvgRenderer`, `esl.buildLabel`, `esl.findBindingsInText`, and `esl.substituteBindingsInText` are also exported for a `TemplateProvider` extension to reuse - e.g. to resolve its own `{...}`-style placeholders against the request's context, or to rasterize whatever SVG it produces into the `Bitmap` its `render()` must return.
|
|
30
|
+
|
|
31
|
+
## CLI Commands
|
|
32
|
+
|
|
33
|
+
`esl-cli` can also be extended with new subcommands by a `-r/--require`'d package, which is how [`@rhizomatics/signalk-einklabel-genai-plugin`](templates.md#genai-rendering) adds its own `prompt`/`generate` commands for testing prompts without a device. See [Command Line Interface](cli.md) for the built-in commands.
|
package/docs/faq.md
ADDED
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
# Frequently Asked Questions
|
|
2
|
+
|
|
3
|
+
## I can't see my device as a choice on the drop-down list after scan
|
|
4
|
+
|
|
5
|
+
SignalK plugins lack the ability to self-update after something like a scan, so first time round you may have to close the config and reload it to see this. Subsequently the plugin will remember all scanned devices, and only drop previously seen ones if it goes 24 hours without a positive scan or with failed paint attempts.
|
|
6
|
+
|
|
7
|
+
Easiest way to solve this is to choose 'All Discovered Devices' in the device configuration, and it will paint any compatible devices it finds on future scans.
|
|
8
|
+
|
|
9
|
+
## Sometimes values are missing on the display
|
|
10
|
+
|
|
11
|
+
If the plugin repaints a display at server startup, then the plugin that provides the data may not have started ( or in the case of `derived-data` the plugin that the plugin depends on! ) and unlike Home Assistant, there's no good way of sequencing the start of plugins.
|
|
12
|
+
|
|
13
|
+
Use the _settle_ time, to impose a minimum wait between the eInk Label plugin being initialized, and it attempting to paint any displays, and increase this value if it's still missing data.
|
|
14
|
+
|
|
15
|
+
## Times are showing incorrectly
|
|
16
|
+
|
|
17
|
+
If times are in the wrong timezone, or don't have daylight savings applied correctly,
|
|
18
|
+
then check that the server itself (at the Linux level, not SignalK, which doesn't know) is configured for your timezone, assuming of course that you're a coastal sailor. Use `raspi-config` on a Raspberry Pi, or `timedatectl` on a Linux server.
|
|
19
|
+
|
|
20
|
+
If you're a global cruiser, then use something like [signalk-set-gps-timezone](https://github.com/hoeken/signalk-set-gps-timezone) to set the value in the operating system.
|
|
21
|
+
|
|
22
|
+
## The ESL signal is too weak from my SignalK server
|
|
23
|
+
|
|
24
|
+
See [Weak Signal](bluetooth.md#weak-signal).
|
|
25
|
+
|
|
26
|
+
## Can't edit the text contents of SVG template in VSCode
|
|
27
|
+
|
|
28
|
+
If you have an SVG viewer extension, this will show the image rather than allowing editing of text. To solve, right click on the file in VSCode _Explorer_ view and choose to edit with _Text Editor_.
|
|
29
|
+
|
|
30
|
+
## Description is set in InkScape but doesn't render
|
|
31
|
+
|
|
32
|
+
Check if the text boxes are normal text or flowed text, and correct to normal text.
|
|
33
|
+
|
|
34
|
+
## My label just shows "CONTENT UNAVAILABLE"
|
|
35
|
+
|
|
36
|
+
That's the bundled fallback warning, not necessarily an error in this plugin - it means the most recent repaint failed, whatever produced the content (a broken hand-authored template, or a `TemplateProvider` extension like [`@rhizomatics/signalk-einklabel-genai-plugin`](templates.md#genai-rendering) - e.g. its LLM call failing on no network/API access, an invalid API key, or a response that wasn't a renderable SVG, after using up its configured retries). Check the SignalK server logs (debug logging on for this plugin) for the specific error, and if it's a GenAI device, check that plugin's own provider/API key/model settings. This plugin deliberately never leaves old content on screen when a repaint fails - it retries automatically at the next scheduled interval.
|
|
37
|
+
|
|
38
|
+
## Bluetooth problems
|
|
39
|
+
|
|
40
|
+
Choosing an adapter, adapters that stop responding, and Bluetooth starting after SignalK are covered on the [Bluetooth](bluetooth.md) page.
|
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
# Getting Started
|
|
2
|
+
|
|
3
|
+
## Pre-requisites
|
|
4
|
+
|
|
5
|
+
Unlike some eInk projects, this plugin doesn't require any physical modification to the labels, or loading any new firmware. It can send an image to a supported shelf label fresh out of the box.
|
|
6
|
+
|
|
7
|
+
Most of requirements below are to make SignalK work with Bluetooth Low Energy, which is good thing to have anyway, since vendors like Victron, Switchbot, Ruuvi and others have BLE enabled hardware that's useful to have on a boat.
|
|
8
|
+
|
|
9
|
+
This plugin can reach BLE hardware two ways - pick whichever fits your setup:
|
|
10
|
+
|
|
11
|
+
- **Direct BlueZ access** (default) - the plugin talks to BlueZ over D-Bus itself. Requirements 1-3 below apply.
|
|
12
|
+
- **SignalK BLE Manager API** (opt-in) - SignalK server >= 2.32.0 ships a [BLE Provider/Consumer API](https://github.com/SignalK/signalk-server/issues/2411) (admin UI: "BLE Manager") that arbitrates adapter access across every BLE-consuming plugin instead of each one grabbing `hci0` for itself, and can source BLE over a remote gateway instead of local hardware at all. Enable the "Use the SignalK BLE Manager API" setting in this plugin's config once it's available (it only appears once the running server has it) - requirements 1-3 below then become the SignalK server's problem, under its own Bluetooth admin settings, not this plugin's.
|
|
13
|
+
|
|
14
|
+
1. A SignalK server, **running Linux** (direct BlueZ mode only - BLE Manager mode with a remote gateway provider has no such requirement)
|
|
15
|
+
|
|
16
|
+
- MacOS and Windows aren't supported by the [BLE interface layer](https://www.npmjs.com/package/@naugehyde/node-ble) in direct BlueZ mode, however they can be used for template development and
|
|
17
|
+
debugging (everything except `scan` and `paint`)
|
|
18
|
+
|
|
19
|
+
2. A Bluetooth adapter, that can handle BLE (Bluetooth Low Energy) - direct BlueZ mode only; in BLE Manager mode this is whatever the server's own Bluetooth settings provide.
|
|
20
|
+
|
|
21
|
+
- Bluetooth adapters for Linux can be tricky - see [Choosing a Bluetooth Adapter](bluetooth.md#choosing-a-bluetooth-adapter) for advice
|
|
22
|
+
|
|
23
|
+
3. `bluez` package installed in Linux - direct BlueZ mode only
|
|
24
|
+
|
|
25
|
+
- No need to do this if you have a Raspberry Pi with recent Raspian version, since bluez comes built in.
|
|
26
|
+
- If you're not running a Raspberry Pi, then ensure that the `dbus` package is installed
|
|
27
|
+
|
|
28
|
+
4. One or more supported Electronic Shelf Labels
|
|
29
|
+
|
|
30
|
+
- The labels used for testing this are the [Zhsunyco 3.7" BWRY](https://www.aliexpress.com/item/1005010050104435.html) and a [Gicisky 2.9" BWRY](https://www.aliexpress.com/item/1005012933325056.html) - see [Supported Labels](#supported-labels)
|
|
31
|
+
|
|
32
|
+
5. Correct time zone set on server if local time is to be shown on display
|
|
33
|
+
|
|
34
|
+
- See [Times are showing incorrectly](faq.md#times-are-showing-incorrectly)
|
|
35
|
+
- If not set, everything will work, but you may see the wrong zone or not have daylight savings applied
|
|
36
|
+
|
|
37
|
+
Once you have all of that, it may be worth also installing [signalk-victron-ble](https://github.com/stefanor/signalk-victron-ble), [signalk-ruuvitag-plugin](https://github.com/vokkim/signalk-ruuvitag-plugin) or [bt-sensors-plugin](https://github.com/naugehyde/bt-sensors-plugin-sk) to pull in data from other sensors and equipment.
|
|
38
|
+
|
|
39
|
+
## Installation
|
|
40
|
+
|
|
41
|
+
Look for **eInk Label Displays** in the **SignalK AppStore** on your
|
|
42
|
+
server ( under _Apps & Plugins_ on the latest version).
|
|
43
|
+
|
|
44
|
+
### Using Outside of SignalK
|
|
45
|
+
|
|
46
|
+
The plugin can also be installed as a stand-alone module, which can be useful for designing templates away from the boat, and makes available the `esl-cli` command line tool for scanning devices and debugging templates - see [Command Line Interface](cli.md).
|
|
47
|
+
|
|
48
|
+
```bash
|
|
49
|
+
npm install @rhizomatics/signalk-einklabel-plugin
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
## Configuration
|
|
53
|
+
|
|
54
|
+
Use the standard configuration option in the SignalK menu for the plugin.
|
|
55
|
+
|
|
56
|
+

|
|
57
|
+
|
|
58
|
+
## Setting up a Label
|
|
59
|
+
|
|
60
|
+
Enable the plugin, and use the large **+** sign to add a label, which opens up these fields.
|
|
61
|
+
|
|
62
|
+

|
|
63
|
+
|
|
64
|
+
- _Friendly Name_ - Give the label any name (word or phrase) you like, for example 'Tide Clock'
|
|
65
|
+
- _Device_ - Unless you have multiple labels, don't bother with pre-scanning or selecting a specific device, instead pick **"All discovered devices"** and it will paint any compatible labels it finds. If you want to pick a specific device, you'll need to wait for a device scan to complete.
|
|
66
|
+
- _Template_ - Choose a built-in template (see [Examples](examples/README.md)), one you've added to the local templates directory, or - if a companion plugin like [`@rhizomatics/signalk-einklabel-genai-plugin`](templates.md#genai-rendering) is installed - one of its own contributed entries (shown with a suffix, e.g. "forecast (GenAI)")
|
|
67
|
+
- _Location/description_ - Optional free-text notes on where this label is physically mounted/viewed from, e.g. "chart table, viewed from ~1m in poor light" - available to any template as `source=label,path=description` (see [Label Details](templates.md#label-details))
|
|
68
|
+
- _Repaint Trigger_- Do you want this to repaint every few hours (at a chosen minutes past hour), or when a SignalK path changes?
|
|
69
|
+
- If it's a SignalK path, enter it next, for example `environment.tide.state`
|
|
70
|
+
- If it's time based, enter how many hours between repaints, for example 00:00/08:00/16:00 for an 8h schedule, and if you want a specific number of minutes after the hour.
|
|
71
|
+
|
|
72
|
+
The rest are grouped under _Advanced settings_, and can usually be ignored.
|
|
73
|
+
|
|
74
|
+
- _If the render doesn't match the panel size_ - see [Reframing](templates.md#reframing)
|
|
75
|
+
- _Compress upload_, _Mirror_ and _Wire format_ - see [Other Image Options](templates.md#other-image-options)
|
|
76
|
+
- _Force Repaint_ - Next time the label is due to be painted, update even if the data or template hasn't changed (this flag will automatically be cleared after this.)
|
|
77
|
+
- _BLE AES key_ - Only needed if the default key doesn't work and you have a better alternative, otherwise ignore
|
|
78
|
+
- _Paint connect timeout_ and _Paint retries_ for this device - leave blank to use the plugin-wide settings, or set them for a label that's slower to respond or further away than the others
|
|
79
|
+
|
|
80
|
+
Configs saved by earlier versions are moved into this layout automatically when the plugin starts.
|
|
81
|
+
|
|
82
|
+
When the plugin starts, it will automatically re-paint the label if it's new, or the last timed slot was missed and the data has changed.
|
|
83
|
+
|
|
84
|
+
### Scanning for Devices
|
|
85
|
+
|
|
86
|
+
Since these are ultra-low power devices, they don't respond instantly to either identify themselves or accept a new image. By default, both scanning and painting have time-outs to wait for a response, which can be altered in the plugin configuration or CLI argument.
|
|
87
|
+
|
|
88
|
+
One other quirk is that some devices respond with a different name at different times, for example the generic `WOESL` sometimes and model specific `WL17500C74` other times. However, the MAC address, e.g. `66:66:17:50:0D:2B` is constant, and this is what's tracked by the plugin.
|
|
89
|
+
|
|
90
|
+
The plugin can optionally re-scan whenever it starts up (off by default), although this isn't essential once a label has been configured. Devices found by any scan are remembered across restarts - see [Troubleshooting](faq.md#i-cant-see-my-device-as-a-choice-on-the-drop-down-list-after-scan).
|
|
91
|
+
|
|
92
|
+
## Supported Labels
|
|
93
|
+
|
|
94
|
+
### Zhsunyco
|
|
95
|
+
|
|
96
|
+
Also known as 'Suny' and 'WOLink'.
|
|
97
|
+
|
|
98
|
+
- [BLE ESLs](https://www.zhsunyco.com/digital-display-solution-for-small-retail-business/ble-esl-solution/)
|
|
99
|
+
- The range of labels available on retail sites like AliExpress may be larger than on their corporate site
|
|
100
|
+
- In mid 2026, a 4 colour (BWRY) 3.7" label retailed for about $35, with quantity discounts for bulk sets
|
|
101
|
+
- Cheapest units are 2 colour 1.54", and they go up to 7.5"
|
|
102
|
+
|
|
103
|
+
Python code for a variety of their labels at https://github.com/roxburghm/zhsunyco-esl and https://github.com/NickWaterton/Wolink
|
|
104
|
+
|
|
105
|
+
### Gicisky
|
|
106
|
+
|
|
107
|
+
Known by other names, e.g. 'Picksmart', and with white label brands
|
|
108
|
+
|
|
109
|
+
- BLE ESLs
|
|
110
|
+
- Official store is on [AliExpress](https://www.aliexpress.com/store/911771479/pages/all-items.html?productGroupId=40000001654819&spm=a2g0o.store_pc_home.pcShopHead_6000727597996.1_1)
|
|
111
|
+
- Cheapest labels under £10 GBP / $13 USD
|