homematic-manager 3.0.0-beta.7 → 3.0.0-beta.9

package/node_modules/@homematic-manager/backend/dist/api/backend.js

@@ -416,6 +416,8 @@ export class Backend {
                 return this.#resetUnreach(p[0], p[1]);
             case 'serviceMessages.list':
                 return this.#serviceMessages(p[0]);
+            case 'serviceMessages.refresh':
+                return this.#refreshAllServiceMessages(p[0]);
             case 'serviceMessages.ack':
                 return this.#acknowledge(p[0], p[1], p[2]);
             case 'events.recent':
@@ -1022,6 +1024,28 @@ export class Backend {
     #serviceMessages(interfaceName) {
         return this.#caches.listServiceMessages(interfaceName);
     }
+    /**
+     * Issue #146: what the refresh button of the service-message tab asks for.
+     *
+     * The list itself comes out of the cache, which the events and a five-minute poll keep up to
+     * date; pressing refresh re-read that cache and therefore changed nothing at all - "Refresh
+     * Button ohne Funktion". This makes the round trip the button promises: `getServiceMessages`
+     * on every connected interface that has the method, and the `:0` sweep on HmIP, which is where
+     * its messages come from. Failures are notices, as everywhere else here - an interface that
+     * does not answer must not turn the button into an error dialog.
+     */
+    async #refreshAllServiceMessages(interfaceName) {
+        const names = (this.#manager?.names() ?? []).filter((name) => (interfaceName === undefined || name === interfaceName) && this.#manager?.isConnected(name) === true);
+        for (const name of names) {
+            if (name === 'HmIP-RF') {
+                await this.sweepHmip(name);
+            }
+            else {
+                await this.#refreshServiceMessages(name);
+            }
+        }
+        return this.#serviceMessages(interfaceName);
+    }
     /**
      * Does it make sense to ask this interface for its service messages?
      *
@@ -1390,6 +1414,7 @@ export const API_METHOD_NAMES = [
     'unreach.list',
     'unreach.reset',
     'serviceMessages.list',
+    'serviceMessages.refresh',
     'serviceMessages.ack',
     'events.recent',
     'events.clear',

package/node_modules/@homematic-manager/backend/dist/interfaces/manager.d.ts

@@ -25,6 +25,8 @@ import { RpcClient, type RpcCallRecord, type RpcClientOptions } from '../rpc/cli
 import { type CallbackHandler, type CallbackServerSet } from '../rpc/server.js';
 /** How often the watchdog looks at every interface. 2.x used the same 15 s. */
 export declare const WATCHDOG_INTERVAL_MS = 15000;
+/** Where an interface process on this very box calls back (#144). */
+export declare const LOOPBACK_IP = "127.0.0.1";
 /** How long `stop()` waits for the de-registering `init(url, '')` calls. */
 export declare const SHUTDOWN_TIMEOUT_MS = 5000;
 /**
@@ -97,7 +99,15 @@ export declare function firstBidcosInterfaceAddress(result: unknown): string | u
 export declare class InterfaceManager {
     #private;
     constructor(options: InterfaceManagerOptions);
-    /** The address the interface processes are told to call back on. */
+    /**
+     * The address the interface processes are told to call back on.
+     *
+     * Issue #144: on the CCU itself (`local`, which is what the addon sets) that is `127.0.0.1`.
+     * The first LAN address of the box worked, but it is the wrong answer twice over: it is the
+     * one address that changes - a new lease, another network - while `init` registrations survive
+     * such a change in the interface process's handler list, and every other local subscriber on a
+     * CCU registers on the loopback, which is what a look at that list expects to see.
+     */
     get callbackIp(): string;
     /** D-31: are the subscriptions currently dropped because nobody is looking? */
     get idle(): boolean;

package/node_modules/@homematic-manager/backend/dist/interfaces/manager.js

@@ -27,6 +27,8 @@ import { CallbackServers } from '../rpc/server.js';
 import { localIPv4Addresses, probePort, withTimeout } from '../util/net.js';
 /** How often the watchdog looks at every interface. 2.x used the same 15 s. */
 export const WATCHDOG_INTERVAL_MS = 15_000;
+/** Where an interface process on this very box calls back (#144). */
+export const LOOPBACK_IP = '127.0.0.1';
 /** How long `stop()` waits for the de-registering `init(url, '')` calls. */
 export const SHUTDOWN_TIMEOUT_MS = 5000;
 /**
@@ -86,14 +88,25 @@ export class InterfaceManager {
             },
         });
     }
-    /** The address the interface processes are told to call back on. */
+    /**
+     * The address the interface processes are told to call back on.
+     *
+     * Issue #144: on the CCU itself (`local`, which is what the addon sets) that is `127.0.0.1`.
+     * The first LAN address of the box worked, but it is the wrong answer twice over: it is the
+     * one address that changes - a new lease, another network - while `init` registrations survive
+     * such a change in the interface process's handler list, and every other local subscriber on a
+     * CCU registers on the loopback, which is what a look at that list expects to see.
+     */
     get callbackIp() {
         const configured = this.#options.connection.callback.ip;
         if (configured !== '') {
             return configured;
         }
+        if (this.#options.connection.local === true) {
+            return LOOPBACK_IP;
+        }
         const addresses = (this.#options.localAddresses ?? (() => localIPv4Addresses()))();
-        return addresses[0] ?? '127.0.0.1';
+        return addresses[0] ?? LOOPBACK_IP;
     }
     /** D-31: are the subscriptions currently dropped because nobody is looking? */
     get idle() {

package/node_modules/@homematic-manager/backend/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@homematic-manager/backend",
-  "version": "3.0.0-beta.7",
+  "version": "3.0.0-beta.9",
   "type": "module",
   "description": "Homematic Manager backend: XML-RPC/BIN-RPC clients and callback servers, caches, optional ReGa",
   "license": "AGPL-3.0-or-later",

package/node_modules/@homematic-manager/core/dist/api/types.d.ts

@@ -811,6 +811,18 @@ export interface ApiMethods {
         params: [interfaceName?: string];
         result: ServiceMessage[];
     };
+    /**
+     * Issue #146: asks the interface processes again and answers with the fresh list.
+     *
+     * {@link 'serviceMessages.list'} reads the backend's cache, which is filled by the events and
+     * by a poll every five minutes - so the refresh button of the tab returned the same list it
+     * already showed and looked like a button without a function. This is the call that makes the
+     * round trip: `getServiceMessages` per BidCos interface, the `:0` sweep on HmIP.
+     */
+    'serviceMessages.refresh': {
+        params: [interfaceName?: string];
+        result: ServiceMessage[];
+    };
     /** Acknowledge by writing the datapoint (STICKY_UNREACH etc.). */
     'serviceMessages.ack': {
         params: [interfaceName: string, address: string, datapoint: string];

package/node_modules/@homematic-manager/core/dist/rssi/index.d.ts

@@ -107,4 +107,57 @@ export declare class RssiStore {
         readonly tx?: number;
     } | undefined;
 }
+/**
+ * Why a device is, or is not, proposed for another receiver (#69).
+ *
+ * - `switch`: another interface receives the device better than the configured one by at least
+ *   the margin.
+ * - `marginal`: another interface receives it better, but by less than the margin - one sample
+ *   apart, which `rssiInfo` values are between two reads.
+ * - `unheard`: the configured receiver has no measurement of the device at all while another
+ *   interface has one; that can mean the device never reaches its receiver, or that rfd has not
+ *   heard it since a restart.
+ * - `keep`: the configured receiver hears it best, or at least as well as any other.
+ * - `unmeasured`: no interface has a measurement.
+ * - `roaming`: the device roams, so the CCU picks its receiver itself; nothing to assign.
+ */
+export type ReceiverVerdict = 'switch' | 'marginal' | 'unheard' | 'keep' | 'unmeasured' | 'roaming';
+/** One row of the "assign the best receiver" proposal (#69). */
+export interface ReceiverProposal {
+    readonly address: string;
+    /** The serial of the receiver the device is configured for. */
+    readonly configured: string;
+    /** What the configured receiver receives from the device, in dBm. */
+    readonly configuredTx: number | undefined;
+    /** The interface that receives the device best; `undefined` without a measurement. */
+    readonly best: string | undefined;
+    readonly bestTx: number | undefined;
+    /** `bestTx - configuredTx` where both are known. */
+    readonly gain: number | undefined;
+    readonly verdict: ReceiverVerdict;
+}
+/**
+ * The margin a better interface has to clear before a switch is proposed, in dB. The values of
+ * `rssiInfo` are the last measurement rfd holds, and two reads of the same link differ by a few dB
+ * without anything having moved; 6 dB is roughly a quartering of the received power and clears
+ * that noise.
+ */
+export declare const DEFAULT_RECEIVER_MARGIN_DB = 6;
+/** The fields of a device description the proposal reads. */
+export interface ReceiverCandidate {
+    readonly ADDRESS: string;
+    readonly PARENT?: string | undefined;
+    readonly INTERFACE?: string | undefined;
+    readonly ROAMING?: boolean | number | undefined;
+}
+/**
+ * The dry run behind issue #69: for every BidCos-RF device with a receiver, which interface hears
+ * it best and whether that is worth a `setBidcosInterface`. Nothing is written here - the list
+ * is what the user confirms, device by device, before anything is. Channels and devices without
+ * an `INTERFACE` (HmIP, Wired, groups) are not in the answer at all. Sorted by verdict in the
+ * order of {@link ReceiverVerdict}, then by gain, then by address.
+ */
+export declare function proposeReceivers(devices: readonly ReceiverCandidate[], interfaceAddresses: readonly string[], store: Pick<RssiStore, 'get' | 'bestInterfaceFor'>, options?: {
+    readonly marginDb?: number | undefined;
+}): ReceiverProposal[];
 //# sourceMappingURL=index.d.ts.map

package/node_modules/@homematic-manager/core/dist/rssi/index.js

@@ -196,4 +196,63 @@ function channel(value) {
 function hex(value) {
     return `0${value.toString(16)}`.slice(-2);
 }
+/**
+ * The margin a better interface has to clear before a switch is proposed, in dB. The values of
+ * `rssiInfo` are the last measurement rfd holds, and two reads of the same link differ by a few dB
+ * without anything having moved; 6 dB is roughly a quartering of the received power and clears
+ * that noise.
+ */
+export const DEFAULT_RECEIVER_MARGIN_DB = 6;
+const VERDICT_ORDER = ['switch', 'marginal', 'unheard', 'keep', 'unmeasured', 'roaming'];
+/**
+ * The dry run behind issue #69: for every BidCos-RF device with a receiver, which interface hears
+ * it best and whether that is worth a `setBidcosInterface`. Nothing is written here - the list
+ * is what the user confirms, device by device, before anything is. Channels and devices without
+ * an `INTERFACE` (HmIP, Wired, groups) are not in the answer at all. Sorted by verdict in the
+ * order of {@link ReceiverVerdict}, then by gain, then by address.
+ */
+export function proposeReceivers(devices, interfaceAddresses, store, options = {}) {
+    const margin = Math.max(0, options.marginDb ?? DEFAULT_RECEIVER_MARGIN_DB);
+    const proposals = [];
+    for (const device of devices) {
+        const configured = device.INTERFACE ?? '';
+        if (configured === '' || (device.PARENT ?? '') !== '') {
+            continue;
+        }
+        const configuredTx = store.get(device.ADDRESS, configured)?.tx;
+        const best = store.bestInterfaceFor(device.ADDRESS, interfaceAddresses);
+        const gain = best?.tx !== undefined && configuredTx !== undefined ? best.tx - configuredTx : undefined;
+        let verdict;
+        if (device.ROAMING === true || device.ROAMING === 1) {
+            verdict = 'roaming';
+        }
+        else if (best === undefined) {
+            verdict = 'unmeasured';
+        }
+        else if (best.address === configured) {
+            verdict = 'keep';
+        }
+        else if (gain === undefined) {
+            verdict = 'unheard';
+        }
+        else if (gain <= 0) {
+            verdict = 'keep';
+        }
+        else {
+            verdict = gain >= margin ? 'switch' : 'marginal';
+        }
+        proposals.push({
+            address: device.ADDRESS,
+            configured,
+            configuredTx,
+            best: best?.address,
+            bestTx: best?.tx,
+            gain,
+            verdict,
+        });
+    }
+    return proposals.sort((a, b) => VERDICT_ORDER.indexOf(a.verdict) - VERDICT_ORDER.indexOf(b.verdict) ||
+        (b.gain ?? Number.NEGATIVE_INFINITY) - (a.gain ?? Number.NEGATIVE_INFINITY) ||
+        a.address.localeCompare(b.address));
+}
 //# sourceMappingURL=index.js.map

package/node_modules/@homematic-manager/core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@homematic-manager/core",
-  "version": "3.0.0-beta.7",
+  "version": "3.0.0-beta.9",
   "type": "module",
   "description": "Pure domain logic of the Homematic Manager: no I/O, no DOM",
   "license": "AGPL-3.0-or-later",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "homematic-manager",
-  "version": "3.0.0-beta.7",
+  "version": "3.0.0-beta.9",
   "type": "module",
   "description": "Configure and administer Homematic and HomematicIP devices - devices and channels, direct links, paramsets, RSSI, service messages, events and an RPC console - from a local HTTP/WebSocket server that also serves the web UI",
   "keywords": [
@@ -67,8 +67,8 @@
     "hm-simulator": "^1.0.0"
   },
   "dependencies": {
-    "@homematic-manager/backend": "3.0.0-beta.7",
-    "@homematic-manager/core": "3.0.0-beta.7",
+    "@homematic-manager/backend": "3.0.0-beta.9",
+    "@homematic-manager/core": "3.0.0-beta.9",
     "binrpc": "^4.2.0",
     "homematic-rega": "^2.0.0",
     "homematic-xmlrpc": "^2.0.0",