@rhizomatics/signalk-einklabel-plugin 1.3.0-beta3 → 1.3.0-beta4

package/CHANGELOG.md

@@ -2,6 +2,7 @@
 
 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/devices/bleBackend.d.ts

@@ -25,6 +25,15 @@ export interface BleBackend {
  */
 export declare function withSessionWatchdog(conn: GattConnection, timeoutMs: number, forceClose: () => Promise<void>): GattConnection;
 export declare function nodeBleBackend(): BleBackend;
+/**
+ * Waits for the BLE Manager to know about `address` before a GATT connect is attempted against it -
+ * mirrors `getOrDiscoverDevice` in `bleDiscovery.ts`, which gives `nodeBleBackend` the same guarantee
+ * against BlueZ directly. Without this, a specifically-addressed device that the manager hasn't seen
+ * yet (e.g. this plugin's own `scanOnStart` is off and no other BLE plugin happens to be scanning)
+ * would sit on `bleApi.connectGATT()` until that call's own `timeoutMs` gives up, rather than the
+ * plugin quietly rediscovering it the way the direct-BlueZ backend already does.
+ */
+export declare function ensureDeviceVisible(bleApi: BLEApi, pluginId: string, address: string, timeoutMs: number): Promise<void>;
 /**
  * `bleApi.connectGATT()` has no timeout of its own, same story as node-ble's `Device#connect()` (see
  * `connectWithTimeout` in `bleDiscovery.ts`) - races it against `timeoutMs`.

package/dist/devices/bleBackend.js

@@ -2,6 +2,7 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.withSessionWatchdog = withSessionWatchdog;
 exports.nodeBleBackend = nodeBleBackend;
+exports.ensureDeviceVisible = ensureDeviceVisible;
 exports.bleApiBackend = bleApiBackend;
 const pluginVersion_1 = require("../pluginVersion");
 const bleDiscovery_1 = require("./bleDiscovery");
@@ -137,6 +138,35 @@ function nodeBleBackend() {
         },
     };
 }
+/**
+ * Waits for the BLE Manager to know about `address` before a GATT connect is attempted against it -
+ * mirrors `getOrDiscoverDevice` in `bleDiscovery.ts`, which gives `nodeBleBackend` the same guarantee
+ * against BlueZ directly. Without this, a specifically-addressed device that the manager hasn't seen
+ * yet (e.g. this plugin's own `scanOnStart` is off and no other BLE plugin happens to be scanning)
+ * would sit on `bleApi.connectGATT()` until that call's own `timeoutMs` gives up, rather than the
+ * plugin quietly rediscovering it the way the direct-BlueZ backend already does.
+ */
+async function ensureDeviceVisible(bleApi, pluginId, address, timeoutMs) {
+    const known = await bleApi.getDevice(address).catch(() => null);
+    if (known)
+        return;
+    const seen = await new Promise((resolve) => {
+        const timer = setTimeout(() => {
+            unsubscribe();
+            resolve(false);
+        }, timeoutMs);
+        const unsubscribe = bleApi.onAdvertisement(pluginId, (adv) => {
+            if (adv.mac !== address)
+                return;
+            clearTimeout(timer);
+            unsubscribe();
+            resolve(true);
+        });
+    });
+    if (!seen) {
+        throw new Error(`device ${address} isn't visible to the SignalK BLE Manager yet (out of range, asleep, or never seen) after waiting ${timeoutMs}ms`);
+    }
+}
 /**
  * `bleApi.connectGATT()` has no timeout of its own, same story as node-ble's `Device#connect()` (see
  * `connectWithTimeout` in `bleDiscovery.ts`) - races it against `timeoutMs`.
@@ -149,6 +179,7 @@ function bleApiBackend(bleApi, pluginId) {
             // "already claimed" until the server restarts - see signalk-bluetti-plugin's BleManagerDevice
             // for the same defensive call. A no-op if we don't currently hold the claim.
             await bleApi.releaseGATTDevice(address, pluginId).catch(() => { });
+            await ensureDeviceVisible(bleApi, pluginId, address, DEVICE_DISCOVERY_TIMEOUT_MS);
             const connecting = bleApi.connectGATT(address, pluginId);
             let timedOut = false;
             const conn = await Promise.race([connecting, (0, bleDiscovery_1.sleep)(timeoutMs).then(() => void (timedOut = true))]);
@@ -179,6 +210,14 @@ function bleApiBackend(bleApi, pluginId) {
             // `BLEDeviceInfo` (from `getDevices()`/`getDevice()`) carries mac/name/rssi/seenBy but not
             // manufacturer data (see `BLEDeviceInfoSchema` in `@signalk/server-api`'s `ble-schemas.ts`) -
             // only the streamed `BLEAdvertisement` does. So this always actively waits on the stream.
+            //
+            // Same defensive release as `connectGatt`, and just as necessary here: a device the BLE Manager
+            // still thinks *we* hold a GATT claim on (e.g. from a crash/reload mid-paint, before this call
+            // ever reaches `connectGatt` below) stops advertising while claimed - which would otherwise wedge
+            // this wait forever, since nothing else in this path ever calls `connectGatt` (and so never gets a
+            // chance to release the stale claim) unless a fresh advertisement shows up first. A no-op if we
+            // don't currently hold the claim.
+            await bleApi.releaseGATTDevice(address, pluginId).catch(() => { });
             return new Promise((resolve) => {
                 const timer = setTimeout(() => {
                     unsubscribe();

package/package.json

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