@rhizomatics/signalk-einklabel-plugin 1.3.0-beta5 → 1.3.0-beta7

package/CHANGELOG.md

@@ -2,7 +2,6 @@
 
 First implementation of using new SignalK BLE Manager rather than directly using the `bluez` services. Off by default until longer term stability demonstrated.
 
-
 # 1.2.3
 
 - Improved example tide template for 2.9" Gicisky, and added blank and error templates

package/dist/config.d.ts

@@ -71,6 +71,9 @@ export interface PluginConfig {
      * signalk-bluetti-plugin does. Off by default - a `device: ALL_DEVICES` entry scans on demand the
      * first time it has nothing discovered yet (see `resolveTargets` in `repaintScheduler.ts`), and an
      * explicit device selection only ever needed this to populate the dropdown once at initial setup.
+     * Also unnecessary with `useBleApi` on, which discovers continuously in the background instead (see
+     * `startBleApiDiscoveryListener` in `discoveryCoordinator.ts`) - kept meaningful mainly for direct
+     * BlueZ access, which has no continuous-scan equivalent to piggyback on.
      */
     scanOnStart: boolean;
     /** How long the startup scan runs, in seconds. */

package/dist/config.js

@@ -333,7 +333,8 @@ function configSchema(app, discovered = []) {
                 type: "boolean",
                 title: "Scan for devices on plugin start",
                 description: 'Runs a short BLE scan so discovered devices show up in a device\'s "Device" picker below. ' +
-                    'Not needed if every device uses "All discovered devices" - that scans on demand instead.',
+                    'Not needed if every device uses "All discovered devices" (that scans on demand instead), or if ' +
+                    '"Use BLE Manager" below is on (that discovers continuously in the background instead of needing a scan).',
                 default: defaults.scanOnStart,
             },
             scanDurationSeconds: {

package/dist/devices/bleBackend.js

@@ -205,11 +205,11 @@ function bleApiBackend(bleApi, pluginId) {
                 // whatever the claim currently is, connected or still connecting, regardless of how the
                 // original `connectGATT()` promise eventually settles - disconnecting it too if it does still
                 // resolve afterwards, harmlessly, since a connection the server already released is a no-op to
-                // disconnect again.
-                void bleApi
-                    .releaseGATTDevice(address, pluginId)
-                    .catch(() => { })
-                    .then(() => connecting.then((c) => c.disconnect()).catch(() => { }));
+                // disconnect again. The release is awaited (only the late disconnect is left in the
+                // background) so a caller retrying straight away - `withRetries` - can't race it with a new
+                // `connectGATT()` and get rejected with "has a GATT claim in progress" for its trouble.
+                await bleApi.releaseGATTDevice(address, pluginId).catch(() => { });
+                void connecting.then((c) => c.disconnect()).catch(() => { });
                 throw new Error(`connecting to device timed out after ${timeoutMs}ms`);
             }
             return withSessionWatchdog(conn, GATT_SESSION_WATCHDOG_MS, async () => {

package/dist/devices/bleDiscovery.d.ts

@@ -34,9 +34,16 @@ export declare function forEachAdvertisedDevice(adapter: Adapter, fn: (advertise
 /**
  * Retries `fn` up to `attempts` times (including the first try), returning on the first success -
  * shared by the repaint scheduler and the CLI's `paint` command so one flaky BLE connection
- * doesn't fail a whole repaint after a single bad attempt.
+ * doesn't fail a whole repaint after a single bad attempt. `delayMs` pauses between attempts, giving
+ * the adapter (and any BLE Manager claim the failed attempt held) a moment to settle rather than
+ * hitting the device again in the same tick. `onError` sees every failed attempt's error, not just the
+ * last one that's eventually thrown - an early attempt's error is often the real cause, with later
+ * ones just fallout from it.
  */
-export declare function withRetries<T>(attempts: number, fn: (attempt: number) => Promise<T>): Promise<T>;
+export declare function withRetries<T>(attempts: number, fn: (attempt: number) => Promise<T>, { delayMs, onError }?: {
+    delayMs?: number;
+    onError?: (err: unknown, attempt: number) => void;
+}): Promise<T>;
 /**
  * Opens exactly one BLE discovery window and one D-Bus/BlueZ session, then hands the adapter to
  * `fn` - shared by `plugin.ts`'s startup scan and the CLI's `scan` command so scanning across

package/dist/devices/bleDiscovery.js

@@ -68,16 +68,25 @@ async function forEachAdvertisedDevice(adapter, fn) {
 /**
  * Retries `fn` up to `attempts` times (including the first try), returning on the first success -
  * shared by the repaint scheduler and the CLI's `paint` command so one flaky BLE connection
- * doesn't fail a whole repaint after a single bad attempt.
+ * doesn't fail a whole repaint after a single bad attempt. `delayMs` pauses between attempts, giving
+ * the adapter (and any BLE Manager claim the failed attempt held) a moment to settle rather than
+ * hitting the device again in the same tick. `onError` sees every failed attempt's error, not just the
+ * last one that's eventually thrown - an early attempt's error is often the real cause, with later
+ * ones just fallout from it.
  */
-async function withRetries(attempts, fn) {
+async function withRetries(attempts, fn, { delayMs = 0, onError } = {}) {
+    const total = Math.max(1, attempts);
     let lastErr;
-    for (let attempt = 1; attempt <= Math.max(1, attempts); attempt++) {
+    for (let attempt = 1; attempt <= total; attempt++) {
         try {
             return await fn(attempt);
         }
         catch (err) {
             lastErr = err;
+            onError?.(err, attempt);
+            if (attempt < total && delayMs > 0) {
+                await sleep(delayMs);
+            }
         }
     }
     throw lastErr;

package/dist/devices/discoveryCoordinator.d.ts

@@ -18,3 +18,21 @@ export declare function scanInProgressSince(): number | undefined;
  * one, which would make both fail.
  */
 export declare function ensureScan(app: ServerAPI, durationSeconds: number, useBleApi: boolean): Promise<ScanResult>;
+/**
+ * Keeps the "Device" picker (and `ALL_DEVICES`) current for as long as the plugin runs, without any
+ * bounded "scan" step at all - unlike `runScanViaBleApi`/`runScanViaBlueZ` above, which only ever look
+ * for new devices during an explicit, timed window (`scanOnStart`, or an on-demand `ALL_DEVICES` scan).
+ * BLE Manager already runs its own continuous scan server-side to build the device list the admin UI's
+ * "BLE Manager" page shows - a device that's visible there but never appears in *this* plugin's own
+ * picker unless `scanOnStart` happens to be ticked is exactly that mismatch: nothing was ever listening
+ * for BLE Manager's advertisements outside a bounded window. This instead subscribes once, for good,
+ * so a device shows up here as soon as BLE Manager itself has seen it - no manual scan required.
+ *
+ * Only runs a genuinely new (or long-expired, see `DISCOVERED_DEVICE_TTL_MS`) address through
+ * `driver.identifyDevice()` - a real GATT connect+read. A device already in the persisted store just
+ * gets `lastSeenAt` bumped via `touchDiscoveredDevice`, since re-identifying it on every ~1s
+ * advertisement would otherwise hammer it (and the shared GATT slots) for no reason. `pending` guards
+ * against two advertisements for the same brand-new device starting a second identify attempt while
+ * the first is still connecting.
+ */
+export declare function startBleApiDiscoveryListener(app: ServerAPI, pluginId: string): () => void;

package/dist/devices/discoveryCoordinator.js

@@ -2,6 +2,7 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.scanInProgressSince = scanInProgressSince;
 exports.ensureScan = ensureScan;
+exports.startBleApiDiscoveryListener = startBleApiDiscoveryListener;
 const bleDiscovery_1 = require("./bleDiscovery");
 const bleBackend_1 = require("./bleBackend");
 const discoveredDevicesStore_1 = require("./discoveredDevicesStore");
@@ -67,43 +68,55 @@ async function runScanViaBlueZ(app, durationSeconds) {
     const merged = (0, discoveredDevicesStore_1.recordScanResults)(app, foundThisScan);
     return { foundThisScan, merged };
 }
+/**
+ * The `matchesAdvertisement`+`identifyDevice` half of processing one BLE Manager sighting - shared by
+ * `runScanViaBleApi`'s bounded scan and `startBleApiDiscoveryListener`'s indefinite one below. Doesn't
+ * decide *whether* to attempt identification (a bounded scan's own per-call `seen` set vs. the
+ * listener's persisted-store check need different answers to that) - just does the attempt and reports
+ * what it found, or `undefined` for "no matching driver"/"identify failed". `adv.manufacturerData`
+ * (from either an advertisement or, seeded, a `getDevices()` entry) is `Record<number, string>`
+ * (decimal company ID -> hex-encoded payload) rather than node-ble's `Buffer` - converted here so
+ * drivers never see the difference.
+ */
+async function identifyOne(app, backend, mac, name, rssi, manufacturerDataHex) {
+    const [manufacturerIdKey] = Object.keys(manufacturerDataHex ?? {});
+    const manufacturerId = manufacturerIdKey === undefined ? undefined : Number(manufacturerIdKey);
+    const manufacturerData = manufacturerId === undefined ? undefined : Buffer.from(manufacturerDataHex[manufacturerId], "hex");
+    const driver = (0, registry_1.allDrivers)().find((candidate) => candidate.matchesAdvertisement(name, manufacturerId));
+    if (!driver) {
+        return undefined;
+    }
+    const connect = () => backend.connectGatt(mac, SCAN_GATT_CONNECT_TIMEOUT_MS);
+    const found = await driver.identifyDevice({ address: mac, name, manufacturerId, manufacturerData, rssi }, connect).catch((err) => {
+        app.debug(`${driver.vendor} discovery failed for [${mac}]: ${err.message}\n${err.stack ?? ""}`);
+        return undefined;
+    });
+    if (found) {
+        const pid = found.pid !== undefined ? `0x${found.pid.toString(16).padStart(4, "0")}` : "unknown";
+        const hwid = found.hwVersion ?? "unknown";
+        app.debug(`discovered ${driver.vendor} device "${found.name ?? ""}" [${found.address}] pid=${pid} hwid=${hwid}`);
+    }
+    return found;
+}
 /**
  * Same as `runScanViaBlueZ` but sourced from the SignalK server's BLE Manager API instead of a direct
  * BlueZ discovery session - subscribes to the merged advertisement stream for `durationSeconds`,
  * seeded with whatever the server already knows about (mirrors `BleManagerScanner` in
- * signalk-bluetti-plugin). `app.bleApi.getDevices()`/advertisements don't carry manufacturer data
- * directly comparable to node-ble's `Buffer` - `adv.manufacturerData` is `Record<number, string>`
- * (decimal company ID -> hex-encoded payload), converted here so drivers never see the difference.
+ * signalk-bluetti-plugin).
  */
 async function runScanViaBleApi(app, durationSeconds) {
     const foundThisScan = [];
     const seen = new Set();
-    const drivers = (0, registry_1.allDrivers)();
     const backend = (0, bleBackend_1.bleApiBackend)(app.bleApi, pluginVersion_1.PLUGIN_NAME);
     const identify = async (mac, name, rssi, manufacturerDataHex) => {
         if (seen.has(mac)) {
             return;
         }
-        const [manufacturerIdKey] = Object.keys(manufacturerDataHex ?? {});
-        const manufacturerId = manufacturerIdKey === undefined ? undefined : Number(manufacturerIdKey);
-        const manufacturerData = manufacturerId === undefined ? undefined : Buffer.from(manufacturerDataHex[manufacturerId], "hex");
-        const driver = drivers.find((candidate) => candidate.matchesAdvertisement(name, manufacturerId));
-        if (!driver) {
-            return;
-        }
         seen.add(mac);
-        const connect = () => backend.connectGatt(mac, SCAN_GATT_CONNECT_TIMEOUT_MS);
-        const found = await driver.identifyDevice({ address: mac, name, manufacturerId, manufacturerData, rssi }, connect).catch((err) => {
-            app.debug(`${driver.vendor} scan failed: ${err.message}\n${err.stack ?? ""}`);
-            return undefined;
-        });
-        if (!found) {
-            return;
+        const found = await identifyOne(app, backend, mac, name, rssi, manufacturerDataHex);
+        if (found) {
+            foundThisScan.push(found);
         }
-        foundThisScan.push(found);
-        const pid = found.pid !== undefined ? `0x${found.pid.toString(16).padStart(4, "0")}` : "unknown";
-        const hwid = found.hwVersion ?? "unknown";
-        app.debug(`discovered ${driver.vendor} device "${found.name ?? ""}" [${found.address}] pid=${pid} hwid=${hwid}`);
     };
     try {
         const unsubscribe = app.bleApi.onAdvertisement(pluginVersion_1.PLUGIN_NAME, (adv) => {
@@ -129,3 +142,57 @@ async function runScanViaBleApi(app, durationSeconds) {
     const merged = (0, discoveredDevicesStore_1.recordScanResults)(app, foundThisScan);
     return { foundThisScan, merged };
 }
+/**
+ * Keeps the "Device" picker (and `ALL_DEVICES`) current for as long as the plugin runs, without any
+ * bounded "scan" step at all - unlike `runScanViaBleApi`/`runScanViaBlueZ` above, which only ever look
+ * for new devices during an explicit, timed window (`scanOnStart`, or an on-demand `ALL_DEVICES` scan).
+ * BLE Manager already runs its own continuous scan server-side to build the device list the admin UI's
+ * "BLE Manager" page shows - a device that's visible there but never appears in *this* plugin's own
+ * picker unless `scanOnStart` happens to be ticked is exactly that mismatch: nothing was ever listening
+ * for BLE Manager's advertisements outside a bounded window. This instead subscribes once, for good,
+ * so a device shows up here as soon as BLE Manager itself has seen it - no manual scan required.
+ *
+ * Only runs a genuinely new (or long-expired, see `DISCOVERED_DEVICE_TTL_MS`) address through
+ * `driver.identifyDevice()` - a real GATT connect+read. A device already in the persisted store just
+ * gets `lastSeenAt` bumped via `touchDiscoveredDevice`, since re-identifying it on every ~1s
+ * advertisement would otherwise hammer it (and the shared GATT slots) for no reason. `pending` guards
+ * against two advertisements for the same brand-new device starting a second identify attempt while
+ * the first is still connecting.
+ */
+function startBleApiDiscoveryListener(app, pluginId) {
+    const backend = (0, bleBackend_1.bleApiBackend)(app.bleApi, pluginId);
+    const pending = new Set();
+    const identify = async (mac, name, rssi, manufacturerDataHex) => {
+        const existing = (0, discoveredDevicesStore_1.loadDiscoveredDevices)(app)[mac];
+        if (existing) {
+            if (Date.now() - existing.lastSeenAt < discoveredDevicesStore_1.DISCOVERED_DEVICE_TTL_MS) {
+                (0, discoveredDevicesStore_1.touchDiscoveredDevice)(app, existing);
+                return;
+            }
+        }
+        if (pending.has(mac)) {
+            return;
+        }
+        pending.add(mac);
+        try {
+            const found = await identifyOne(app, backend, mac, name, rssi, manufacturerDataHex);
+            if (found) {
+                (0, discoveredDevicesStore_1.recordScanResults)(app, [found]);
+            }
+        }
+        finally {
+            pending.delete(mac);
+        }
+    };
+    const unsubscribe = app.bleApi.onAdvertisement(pluginId, (adv) => {
+        void identify(adv.mac, adv.name, adv.rssi, adv.manufacturerData);
+    });
+    // Seeds from whatever BLE Manager already knows about (e.g. a device it saw before this plugin
+    // subscribed) - same manufacturer-data caveat as `runScanViaBleApi`'s equivalent seed loop; a driver
+    // that needs it (rather than matching on name) picks it up once a fresh advertisement arrives above.
+    void app.bleApi
+        .getDevices()
+        .then((known) => Promise.all(known.map((device) => identify(device.mac, device.name, device.rssi, undefined))))
+        .catch((err) => app.debug(`discovery listener: could not read known devices: ${err.message}`));
+    return unsubscribe;
+}

package/dist/devices/gicisky/index.js

@@ -53,19 +53,23 @@ class GiciskyDriver {
          */
         const manufacturerData = await backend.waitForManufacturerData(config.address, protocol_1.GICISKY_MANUFACTURER_ID, MANUFACTURER_DATA_RESCAN_TIMEOUT_MS);
         const info = manufacturerData ? (0, protocol_1.decodeAdvertisedInfo)(manufacturerData) : undefined;
+        // A device that's quiet right now (e.g. still refreshing from the last paint) can still be painted
+        // when its PID is already known from config/a previous scan - the connect below doesn't need the
+        // advertisement, only this lookup does.
+        const pid = info?.deviceId ?? config.pid;
         const metadata = config.modelOverride
-            ? { pid: info?.deviceId ?? 0, ...config.modelOverride }
-            : info
-                ? this.metadataForPid(info.deviceId)
+            ? { pid: pid ?? 0, ...config.modelOverride }
+            : pid !== undefined
+                ? this.metadataForPid(pid)
                 : undefined;
         if (!metadata) {
-            throw new Error(info === undefined
+            throw new Error(pid === undefined
                 ? "gicisky device isn't advertising - rescanned but got nothing back (out of range, asleep, or already connected " +
                     "elsewhere) - pass --width/--height/--voffset/--colours to describe it manually"
-                : `gicisky device reports unrecognised deviceId 0x${info.deviceId.toString(16).padStart(4, "0")} - ` +
+                : `gicisky device reports unrecognised deviceId 0x${pid.toString(16).padStart(4, "0")} - ` +
                     "pass --width/--height/--voffset/--colours to describe it manually");
         }
-        const layout = (info && layout_1.GICISKY_PID_LAYOUT[info.deviceId]) || (0, layout_1.defaultLayoutFor)(metadata.colours);
+        const layout = (pid !== undefined && layout_1.GICISKY_PID_LAYOUT[pid]) || (0, layout_1.defaultLayoutFor)(metadata.colours);
         const framed = (0, reframe_1.reframeBitmap)(bitmap, metadata.width, metadata.height, config.reframe ?? "crop");
         const payload = (0, encode_1.encodeBitmap)(framed, metadata, layout);
         const conn = await backend.connectGatt(config.address, config.connectTimeoutMs ?? DEFAULT_PAINT_CONNECT_TIMEOUT_MS);
@@ -89,6 +93,12 @@ class GiciskyDriver {
                     const chunk = payload.subarray(part * chunkSize, Math.min(part * chunkSize + chunkSize, payload.length));
                     const ackData = await writeAndAwaitAck(conn, imgServiceUuid, imgUuid, (0, protocol_1.imageChunkPacket)(part, chunk), ack);
                     const decoded = (0, protocol_1.decodeTransferAck)(ackData);
+                    if (decoded && !decoded.ok && part * chunkSize + chunk.length >= payload.length) {
+                        // The device answers the final chunk with a non-zero status (seen: `05 08 00000000`) once
+                        // it has the whole image and starts refreshing - the transfer's done, not failed. Matches
+                        // hass-gicisky's writer, which ends the transfer on any non-zero status rather than erroring.
+                        break;
+                    }
                     if (!decoded?.ok) {
                         throw new Error(`gicisky device reported an error transferring image part ${part}: ${ackData.toString("hex")}`);
                     }

package/dist/devices/types.d.ts

@@ -53,6 +53,13 @@ export type DeviceModelOverride = Omit<DeviceMetadata, "pid">;
 /** Per-device settings the user supplies when registering a device, beyond what's in DeviceMetadata. */
 export interface VendorDeviceConfig {
     address: string;
+    /**
+     * The PID already known for this device (from the configured `"<vendor>:<pid>@<address>"` or a
+     * previous scan) - a fallback for drivers that otherwise only learn it from a fresh advertisement
+     * (gicisky), so a device that's quiet at paint time can still be painted. A live advertised PID
+     * takes precedence when there is one.
+     */
+    pid?: number;
     /** AES key for vendors that need it, entered by the user. If omitted, vendors that have one may fall back to a stock/manufacturer-default key instead of failing. */
     aesKey?: string;
     /** Forces the device model facts instead of looking up the advertised PID - for hardware not yet in the driver's table. */

package/dist/plugin.js

@@ -9,6 +9,7 @@ const discoveryCoordinator_1 = require("./devices/discoveryCoordinator");
 const bleDiscovery_1 = require("./devices/bleDiscovery");
 const discoveredDevicesStore_1 = require("./devices/discoveredDevicesStore");
 const repaintScheduler_1 = require("./repaintScheduler");
+const pluginVersion_1 = require("./pluginVersion");
 /** Mirrors signalk-bluetti-plugin's convention: scan briefly, report finds via plugin status for the user to copy-paste. */
 async function runStartupScan(app, durationSeconds, useBleApi) {
     const alreadyRunning = (0, discoveryCoordinator_1.scanInProgressSince)();
@@ -41,6 +42,7 @@ function createPlugin(app) {
     // enough to have added it - checked at runtime rather than trusted from the type.
     const bleApiAvailable = !!app.bleApi;
     let scheduler;
+    let stopDiscoveryListener;
     let stopped = false;
     const plugin = {
         id: "signalk-einklabel-plugin",
@@ -73,6 +75,11 @@ function createPlugin(app) {
                 scheduler = (0, repaintScheduler_1.startRepaintScheduler)(app, pluginConfig);
             };
             if (useBleApi) {
+                // BLE Manager already runs its own continuous scan server-side (that's what populates its own
+                // admin UI device list) - unlike direct BlueZ access below, discovery here doesn't need a
+                // bounded scan window at all, so this listens for as long as the plugin runs rather than only
+                // during `scanOnStart`/an on-demand `ALL_DEVICES` scan. See its own doc comment.
+                stopDiscoveryListener = (0, discoveryCoordinator_1.startBleApiDiscoveryListener)(app, pluginVersion_1.PLUGIN_NAME);
                 // The server/provider governs its own local-adapter readiness once BLE Manager mode owns
                 // `hci0` (or has none at all, behind a remote gateway) - waiting on a *local* BlueZ adapter
                 // here would be waiting on something this mode may never even need.
@@ -90,6 +97,8 @@ function createPlugin(app) {
             stopped = true;
             scheduler?.stop();
             scheduler = undefined;
+            stopDiscoveryListener?.();
+            stopDiscoveryListener = undefined;
             app.debug("stopped");
         },
     };

package/dist/repaintScheduler.js

@@ -23,6 +23,8 @@ const pluginVersion_1 = require("./pluginVersion");
 const httpJson_1 = require("./httpJson");
 const INTERVAL_POLL_MS = 60000;
 const SUBSCRIPTION_DEBOUNCE_MS = 2000;
+/** Pause between paint attempts - see `withRetries`' `delayMs`. */
+const PAINT_RETRY_DELAY_MS = 5000;
 const RESOURCES_API_PATH = "/signalk/v2/api/resources";
 /**
  * The most recent wall-clock instant at or before `now` that an `interval`-triggered device's own
@@ -346,13 +348,22 @@ async function considerRepaint(app, config, device, target, state, getApiUrl) {
     }
     const connectTimeoutMs = config.paintConnectTimeoutSeconds * 1000;
     const gattBackend = config.useBleApi && app.bleApi ? (0, bleBackend_1.bleApiBackend)(app.bleApi, pluginVersion_1.PLUGIN_NAME) : undefined;
-    const paintWithRetries = () => (0, bleDiscovery_1.withRetries)(config.paintRetries, async (attempt) => {
-        if (attempt > 1) {
-            app.debug(`${label}: attempting paint ${attempt}/${config.paintRetries}`);
-        }
+    const attempts = Math.max(1, config.paintRetries);
+    const paintWithRetries = () => (0, bleDiscovery_1.withRetries)(attempts, async (attempt) => {
+        app.debug(`${label}: attempting paint ${attempt}/${attempts}`);
         const startedAt = Date.now();
-        await driver.paint(bitmap, { address, aesKey: device.aesKey, connectTimeoutMs, reframe: device.reframe, gattBackend });
+        await driver.paint(bitmap, {
+            address,
+            pid: target.pid,
+            aesKey: device.aesKey,
+            connectTimeoutMs,
+            reframe: device.reframe,
+            gattBackend,
+        });
         paintDurationMs = Date.now() - startedAt;
+    }, {
+        delayMs: PAINT_RETRY_DELAY_MS,
+        onError: (err, attempt) => app.debug(`${label}: paint attempt ${attempt}/${attempts} failed: ${err.message}`),
     });
     await (gattBackend ? (0, bleBackend_1.exclusiveBleManagerAccess)(paintWithRetries) : paintWithRetries());
     (0, discoveredDevicesStore_1.touchDiscoveredDevice)(app, { address, vendor: target.vendor, pid: target.pid, hwVersion: target.hwVersion, metadata });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rhizomatics/signalk-einklabel-plugin",
-  "version": "1.3.0-beta5",
+  "version": "1.3.0-beta7",
   "description": "Display SignalK data on eInk Electronic Shelf Labels, includes working examples for tide clock and watch schedule.",
   "keywords": [
     "ble",