homematic-manager 3.0.0-beta.2 → 3.0.0-beta.21

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

@@ -7,13 +7,10 @@
  * as events and sit in every device's `<device>:0` VALUES paramset - the same thing 2.x does in
  * main.js (:404-432 for the events, :800-822 for the paramset read).
  */
+import type { BidcosInterfaceInfo } from '../api/types.js';
 import type { Paramset, ParamsetValue } from '../rpc/values.js';
 /** What an interface process sends instead of a value it does not have. */
 export declare const RSSI_UNKNOWN = 65536;
-/** The thresholds of the 2.x `rssiColor()` (homematic-manager.js:4649). */
-export declare const RSSI_BAD = -120;
-export declare const RSSI_MEDIUM = -100;
-export declare const RSSI_GOOD = -20;
 /** What one partner measures of another. `undefined` where the interface reported 65536. */
 export interface RssiPair {
     /** What this device receives from the peer, in dBm. */
@@ -25,22 +22,84 @@ export interface RssiPair {
 export type RawRssiInfo = Readonly<Record<string, Readonly<Record<string, readonly unknown[]>>>>;
 /** device or interface address -> peer address -> the pair. */
 export type RssiMatrix = Record<string, Record<string, RssiPair>>;
-/** How good a signal is, for the colour of the grid cell. */
-export type RssiClass = 'unknown' | 'bad' | 'medium' | 'good';
-/** One value from an `rssiInfo` answer: a number, unless it is the "unknown" placeholder. */
+/** A step of the RSSI scale, 1 the strongest signal, 8 the weakest. */
+export type RssiStep = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8;
+/** How many of the pill's four signal bars a step lights. */
+export type RssiBars = 0 | 1 | 2 | 3 | 4;
+/** One band of the RSSI scale. */
+export interface RssiBand {
+    readonly step: RssiStep;
+    /** The lowest reading that still belongs to the band, in dBm; `-Infinity` for the last one. */
+    readonly min: number;
+    readonly bars: RssiBars;
+    /** What the band means, in English - the key the UI translates it by. */
+    readonly label: string;
+}
+/**
+ * The RSSI scale of the Funk tab (#161): eight bands, 10 dB apart from -30 to -90 dBm.
+ *
+ * Until 3.0.0-beta.17 there were three classes from the 2.x colour gradient - good from -20 dBm,
+ * bad below -100 - and nearly every real link, which lies between -40 and -90, was the same yellow
+ * "medium". Issue #161 (@Baxxy13) asked for a finer scale closer to the OpenCCU WebUI, which colours
+ * green above -70, yellow down to -90 and red below; both of its edges are edges here. The maintainer
+ * posted three eight-step palettes, and on 2026-09-15 he, @Baxxy13 and @Herbert-Testmann settled on
+ * "Variante 3" with signal bars in the pill (arrangement B), so that the step reads without its
+ * colour too. The fills are theme tokens (`--hmm-rssi-<step>`); this table is the part that is not
+ * a colour.
+ *
+ * A reading belongs to the first band whose lower edge it reaches: -30 is step 1, -40 is step 2.
+ */
+export declare const RSSI_BANDS: readonly RssiBand[];
+/**
+ * One RSSI value as the CCU hands it out, as dBm - or `undefined` where it is not a measurement.
+ *
+ * Issue #154: a receive level in dBm is always negative, and yet `rssiInfo` and the `RSSI_*`
+ * datapoints produce positive numbers (`37`), numbers far below the noise floor (`-208`) and
+ * placeholders (`65536`, `128`). Three things are mixed in there:
+ *
+ * - **`65536`** is eQ-3's documented "no information" (the WebUI's `rssiinfo.tcl`: *"Der Wert 65536
+ *   bedeutet, dass keine Informationen vorliegen"*), and `-65536`, `±256`, `0` and `±1` are used
+ *   the same way by one component or another - `0`/`1` meaning nothing was received in that
+ *   direction since the last start.
+ * - **`128` / `-128`** (`0x80`) is the radio chip's "no RSSI available", not a level.
+ * - The rest is a **sign that was lost on the way**: ReGaHss creates the maintenance datapoints as
+ *   an unsigned byte (`ivtByte`) although the paramset says `INTEGER`, so values arrive with an
+ *   offset of 256 or with the sign dropped. `130…255` is `value - 256`, `-255…-130` is
+ *   `-value - 256` (which is what turns the maintainer's `-208` into a perfectly ordinary
+ *   -48 dBm), and a bare positive `2…126` is the same level without its minus.
+ *
+ * The mapping is the one Home Assistant's `aiohomematic` applies (`model/generic/sensor.py`,
+ * `_fix_rssi`); OpenCCU's WebUI does the `- 256` half in
+ * `0144-WebUI-ControlForMaintenanceChannel` and hm2mqtt.js does it for the ReGa cache. The
+ * inversion of a small positive value is the one step no eQ-3 source confirms - it is
+ * `aiohomematic`'s reading, and it is what makes a `37` in the grid the -37 dBm it plainly is.
+ */
 export declare function normaliseRssiValue(value: unknown): number | undefined;
 /** Turns an `rssiInfo` answer into the matrix, dropping the 65536 placeholders. */
 export declare function normaliseRssiInfo(raw: RawRssiInfo): RssiMatrix;
 /**
- * How good a signal is. -20 dBm and better is good, -100 and worse is bad, in between is medium;
- * an absent value is unknown. The bounds come from the 2.x colour gradient.
+ * The band of {@link RSSI_BANDS} a reading falls into, or `undefined` where it is not a measurement
+ * at all (65536 and the other placeholders of #154) - the grid shows a faint dash for those.
  */
-export declare function rssiClass(dbm: number | undefined): RssiClass;
+export declare function rssiBand(dbm: number | undefined): RssiBand | undefined;
+/** The two fields of a `listBidcosInterfaces` entry that name it. */
+export type BidcosInterfaceName = Pick<BidcosInterfaceInfo, 'ADDRESS' | 'DESCRIPTION'>;
 /**
- * The red/green gradient of the 2.x grid, kept so the radio tab looks the same (D-3).
- * `undefined` for a value there is none for - the cell stays empty, as it did.
+ * How a BidCos interface is named for a person: the `DESCRIPTION` the CCU carries for it - the
+ * name a LAN gateway was given in the WebUI, `CCU2-Coprocessor` for the built-in module - and the
+ * serial when there is none. The 2.x Funk grid put the serial over the interface's columns with
+ * the description in small print under it; a gateway without a description shows its serial alone.
  */
-export declare function rssiColor(dbm: number | undefined): string | undefined;
+export declare function bidcosInterfaceLabel(gateway: BidcosInterfaceName): string;
+/**
+ * The receiver a BidCos-RF device is routed through, for the device grid (BUGS.md B-2): the
+ * label of the gateway whose serial the description's `INTERFACE` names, the serial itself when
+ * `listBidcosInterfaces` does not know it or has not been read yet, and nothing for a device
+ * without one - HmIP and Wired have no receivers.
+ */
+export declare function receiverLabel(device: {
+    readonly INTERFACE?: string | undefined;
+}, gateways: readonly BidcosInterfaceName[]): string;
 /** The HmIP datapoints the matrix is built from. */
 export declare const RSSI_DATAPOINTS: readonly string[];
 export interface RssiStoreOptions {
@@ -88,4 +147,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

@@ -9,16 +9,72 @@
  */
 /** What an interface process sends instead of a value it does not have. */
 export const RSSI_UNKNOWN = 65536;
-/** The thresholds of the 2.x `rssiColor()` (homematic-manager.js:4649). */
-export const RSSI_BAD = -120;
-export const RSSI_MEDIUM = -100;
-export const RSSI_GOOD = -20;
-/** One value from an `rssiInfo` answer: a number, unless it is the "unknown" placeholder. */
+/**
+ * The RSSI scale of the Funk tab (#161): eight bands, 10 dB apart from -30 to -90 dBm.
+ *
+ * Until 3.0.0-beta.17 there were three classes from the 2.x colour gradient - good from -20 dBm,
+ * bad below -100 - and nearly every real link, which lies between -40 and -90, was the same yellow
+ * "medium". Issue #161 (@Baxxy13) asked for a finer scale closer to the OpenCCU WebUI, which colours
+ * green above -70, yellow down to -90 and red below; both of its edges are edges here. The maintainer
+ * posted three eight-step palettes, and on 2026-09-15 he, @Baxxy13 and @Herbert-Testmann settled on
+ * "Variante 3" with signal bars in the pill (arrangement B), so that the step reads without its
+ * colour too. The fills are theme tokens (`--hmm-rssi-<step>`); this table is the part that is not
+ * a colour.
+ *
+ * A reading belongs to the first band whose lower edge it reaches: -30 is step 1, -40 is step 2.
+ */
+export const RSSI_BANDS = [
+    { step: 1, min: -30, bars: 4, label: 'Very good (maximum)' },
+    { step: 2, min: -40, bars: 4, label: 'Very good' },
+    { step: 3, min: -50, bars: 4, label: 'Good' },
+    { step: 4, min: -60, bars: 3, label: 'Good (normal operation)' },
+    { step: 5, min: -70, bars: 3, label: 'Sufficient' },
+    { step: 6, min: -80, bars: 2, label: 'Sufficient to weak' },
+    { step: 7, min: -90, bars: 1, label: 'Poor' },
+    { step: 8, min: Number.NEGATIVE_INFINITY, bars: 0, label: 'Critical' },
+];
+/**
+ * One RSSI value as the CCU hands it out, as dBm - or `undefined` where it is not a measurement.
+ *
+ * Issue #154: a receive level in dBm is always negative, and yet `rssiInfo` and the `RSSI_*`
+ * datapoints produce positive numbers (`37`), numbers far below the noise floor (`-208`) and
+ * placeholders (`65536`, `128`). Three things are mixed in there:
+ *
+ * - **`65536`** is eQ-3's documented "no information" (the WebUI's `rssiinfo.tcl`: *"Der Wert 65536
+ *   bedeutet, dass keine Informationen vorliegen"*), and `-65536`, `±256`, `0` and `±1` are used
+ *   the same way by one component or another - `0`/`1` meaning nothing was received in that
+ *   direction since the last start.
+ * - **`128` / `-128`** (`0x80`) is the radio chip's "no RSSI available", not a level.
+ * - The rest is a **sign that was lost on the way**: ReGaHss creates the maintenance datapoints as
+ *   an unsigned byte (`ivtByte`) although the paramset says `INTEGER`, so values arrive with an
+ *   offset of 256 or with the sign dropped. `130…255` is `value - 256`, `-255…-130` is
+ *   `-value - 256` (which is what turns the maintainer's `-208` into a perfectly ordinary
+ *   -48 dBm), and a bare positive `2…126` is the same level without its minus.
+ *
+ * The mapping is the one Home Assistant's `aiohomematic` applies (`model/generic/sensor.py`,
+ * `_fix_rssi`); OpenCCU's WebUI does the `- 256` half in
+ * `0144-WebUI-ControlForMaintenanceChannel` and hm2mqtt.js does it for the ReGa cache. The
+ * inversion of a small positive value is the one step no eQ-3 source confirms - it is
+ * `aiohomematic`'s reading, and it is what makes a `37` in the grid the -37 dBm it plainly is.
+ */
 export function normaliseRssiValue(value) {
-    if (typeof value !== 'number' || !Number.isFinite(value) || value === RSSI_UNKNOWN) {
+    if (typeof value !== 'number' || !Number.isFinite(value)) {
         return undefined;
     }
-    return value;
+    if (value > -127 && value < 0) {
+        return value; // already a dBm value
+    }
+    if (value > 1 && value < 127) {
+        return -value; // the minus was lost
+    }
+    if (value > -256 && value < -129) {
+        return -value - 256; // -208 -> -48
+    }
+    if (value > 129 && value < 256) {
+        return value - 256; // 218 -> -38
+    }
+    // 0, ±1, ±128, ±129, ±256, ±65536 and anything outside: not a measurement
+    return undefined;
 }
 /** Turns an `rssiInfo` answer into the matrix, dropping the 65536 placeholders. */
 export function normaliseRssiInfo(raw) {
@@ -33,31 +89,39 @@ export function normaliseRssiInfo(raw) {
     return matrix;
 }
 /**
- * How good a signal is. -20 dBm and better is good, -100 and worse is bad, in between is medium;
- * an absent value is unknown. The bounds come from the 2.x colour gradient.
+ * The band of {@link RSSI_BANDS} a reading falls into, or `undefined` where it is not a measurement
+ * at all (65536 and the other placeholders of #154) - the grid shows a faint dash for those.
  */
-export function rssiClass(dbm) {
+export function rssiBand(dbm) {
     const value = normaliseRssiValue(dbm);
     if (value === undefined) {
-        return 'unknown';
-    }
-    if (value >= RSSI_GOOD) {
-        return 'good';
+        return undefined;
     }
-    return value >= RSSI_MEDIUM ? 'medium' : 'bad';
+    return RSSI_BANDS.find((band) => value >= band.min);
 }
 /**
- * The red/green gradient of the 2.x grid, kept so the radio tab looks the same (D-3).
- * `undefined` for a value there is none for - the cell stays empty, as it did.
+ * How a BidCos interface is named for a person: the `DESCRIPTION` the CCU carries for it - the
+ * name a LAN gateway was given in the WebUI, `CCU2-Coprocessor` for the built-in module - and the
+ * serial when there is none. The 2.x Funk grid put the serial over the interface's columns with
+ * the description in small print under it; a gateway without a description shows its serial alone.
  */
-export function rssiColor(dbm) {
-    const value = normaliseRssiValue(dbm);
-    if (value === undefined) {
-        return undefined;
+export function bidcosInterfaceLabel(gateway) {
+    const description = gateway.DESCRIPTION?.trim() ?? '';
+    return description === '' ? gateway.ADDRESS : description;
+}
+/**
+ * The receiver a BidCos-RF device is routed through, for the device grid (BUGS.md B-2): the
+ * label of the gateway whose serial the description's `INTERFACE` names, the serial itself when
+ * `listBidcosInterfaces` does not know it or has not been read yet, and nothing for a device
+ * without one - HmIP and Wired have no receivers.
+ */
+export function receiverLabel(device, gateways) {
+    const serial = device.INTERFACE ?? '';
+    if (serial === '') {
+        return '';
     }
-    const red = channel((256 * (value - RSSI_GOOD)) / (RSSI_MEDIUM - RSSI_GOOD));
-    const green = channel((256 * (value - RSSI_BAD)) / (RSSI_MEDIUM - RSSI_BAD));
-    return `#${hex(red)}${hex(green)}00`;
+    const gateway = gateways.find((candidate) => candidate.ADDRESS === serial);
+    return gateway ? bidcosInterfaceLabel(gateway) : serial;
 }
 /** The HmIP datapoints the matrix is built from. */
 export const RSSI_DATAPOINTS = ['RSSI_DEVICE', 'RSSI_PEER'];
@@ -166,10 +230,63 @@ function pair(rx, tx) {
     }
     return result;
 }
-function channel(value) {
-    return Math.min(255, Math.max(0, Math.round(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/dist/serviceMessages/index.d.ts

@@ -10,11 +10,23 @@
  * The store below is that logic without the globals: a value that is truthy sets the message, a
  * falsy one clears it, and clearing the last message of a channel drops the channel.
  */
+import type { ParameterDescription } from '../paramset/description.js';
 import type { Paramset, ParamsetValue } from '../rpc/values.js';
 /**
  * The datapoints that are service messages. `ERROR*` is a prefix rule: devices carry `ERROR`,
  * `ERROR_CODE`, `ERROR_OVERHEAT`, `ERROR_JAMMED` and a dozen more, all of them meaning the same
  * thing for the list.
+ *
+ * `FAULT_REPORTING` (BUGS.md B-24, #150) is the ENUM of the HM-CC-RT-DN's
+ * `CLIMATECONTROL_RT_TRANSCEIVER` channel - not on `:0` and not named `ERROR*`, so it was dropped
+ * and the WebUI's "Kommunikationsstörung" never reached the list. Its index `0` is `NO_FAULT`,
+ * which is falsy, so the store's "falsy clears" rule needs no exception for it. It is not
+ * acknowledgeable: its `OPERATIONS` are 5 (read, event), and the WebUI's service-message page
+ * enables its confirm button only for a datapoint with the write bit.
+ *
+ * Only the datapoints named here count, not every one with the description's SERVICE flag: that
+ * would take the next device-specific one automatically, but it needs a description per channel
+ * before a message can be listed, and it is a broader change than this bug.
  */
 export declare const SERVICE_MESSAGE_DATAPOINTS: readonly string[];
 /** Prefix of the device-specific error datapoints. */
@@ -38,6 +50,14 @@ export declare function isAcknowledgeable(datapoint: string): boolean;
  * measurement, not a message (main.js:406 - "Not a Service Message!").
  */
 export declare function countsAsServiceMessage(datapoint: string, value: ParamsetValue): boolean;
+/**
+ * The `VALUE_LIST` name of an ENUM service message's value: `COMMUNICATION_ERROR` for a
+ * `FAULT_REPORTING` of `4` (B-24). BidCos sends the index, HmIP may send the name itself; either
+ * way the answer is the name, which is what the translations are keyed by
+ * (`CLIMATECONTROL_RT_TRANSCEIVER|FAULT_REPORTING|COMMUNICATION_ERROR`). `undefined` when the
+ * parameter is not an ENUM, has no such entry, or the entry is one of the empty gaps of a list.
+ */
+export declare function serviceMessageValueName(parameter: ParameterDescription | undefined, value: unknown): string | undefined;
 /**
  * One stored service message. The shape that crosses the transport is `ServiceMessage` in
  * `api/types.ts`; this is what the store keeps, with the device and the acknowledgeable flag
@@ -77,7 +97,7 @@ export declare class ServiceMessageStore {
      * Applies one datapoint. Returns true when something changed, so a caller can decide whether
      * to notify the UI. A datapoint that is not a service message is ignored.
      */
-    apply(interfaceName: string, address: string, datapoint: string, value: ParamsetValue): boolean;
+    apply(interfaceName: string, address: string, datapoint: string, value: ParamsetValue, timestamp?: number): boolean;
     /** Applies an `event` callback; the same thing, named for the call site. */
     applyEvent(interfaceName: string, address: string, datapoint: string, value: ParamsetValue): boolean;
     /**
@@ -85,7 +105,13 @@ export declare class ServiceMessageStore {
      * start-up: every service-message datapoint in it is applied, everything else ignored.
      */
     applyParamset(interfaceName: string, address: string, values: Paramset): boolean;
-    /** Replaces everything an interface has with a fresh `getServiceMessages` answer. */
+    /**
+     * Replaces everything an interface has with a fresh `getServiceMessages` answer.
+     *
+     * Issue #150: a message that is still there with the same value keeps the time it was first
+     * seen. Rebuilding the map from scratch stamped every row with "now", so pressing Refresh
+     * moved the "Since" column of six-day-old messages to this minute.
+     */
     replaceInterface(interfaceName: string, tuples: readonly ServiceMessageTuple[]): void;
     /** Removes one message. Returns true when there was one. */
     clear(interfaceName: string, address: string, datapoint: string): boolean;

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

@@ -15,10 +15,22 @@ import { deviceAddress } from '../address/address.js';
  * The datapoints that are service messages. `ERROR*` is a prefix rule: devices carry `ERROR`,
  * `ERROR_CODE`, `ERROR_OVERHEAT`, `ERROR_JAMMED` and a dozen more, all of them meaning the same
  * thing for the list.
+ *
+ * `FAULT_REPORTING` (BUGS.md B-24, #150) is the ENUM of the HM-CC-RT-DN's
+ * `CLIMATECONTROL_RT_TRANSCEIVER` channel - not on `:0` and not named `ERROR*`, so it was dropped
+ * and the WebUI's "Kommunikationsstörung" never reached the list. Its index `0` is `NO_FAULT`,
+ * which is falsy, so the store's "falsy clears" rule needs no exception for it. It is not
+ * acknowledgeable: its `OPERATIONS` are 5 (read, event), and the WebUI's service-message page
+ * enables its confirm button only for a datapoint with the write bit.
+ *
+ * Only the datapoints named here count, not every one with the description's SERVICE flag: that
+ * would take the next device-specific one automatically, but it needs a description per channel
+ * before a message can be listed, and it is a broader change than this bug.
  */
 export const SERVICE_MESSAGE_DATAPOINTS = [
     'CONFIG_PENDING',
     'DUTY_CYCLE',
+    'FAULT_REPORTING',
     'LOWBAT',
     'LOW_BAT',
     'SABOTAGE',
@@ -56,6 +68,21 @@ export function countsAsServiceMessage(datapoint, value) {
     }
     return datapoint !== 'DUTY_CYCLE' || typeof value === 'boolean';
 }
+/**
+ * The `VALUE_LIST` name of an ENUM service message's value: `COMMUNICATION_ERROR` for a
+ * `FAULT_REPORTING` of `4` (B-24). BidCos sends the index, HmIP may send the name itself; either
+ * way the answer is the name, which is what the translations are keyed by
+ * (`CLIMATECONTROL_RT_TRANSCEIVER|FAULT_REPORTING|COMMUNICATION_ERROR`). `undefined` when the
+ * parameter is not an ENUM, has no such entry, or the entry is one of the empty gaps of a list.
+ */
+export function serviceMessageValueName(parameter, value) {
+    const list = parameter?.TYPE === 'ENUM' ? parameter.VALUE_LIST : undefined;
+    if (list === undefined) {
+        return undefined;
+    }
+    const name = typeof value === 'number' ? list[value] : typeof value === 'string' && list.includes(value) ? value : '';
+    return name === undefined || name === '' ? undefined : name;
+}
 /**
  * The current service messages of every interface.
  *
@@ -83,12 +110,12 @@ export class ServiceMessageStore {
      * Applies one datapoint. Returns true when something changed, so a caller can decide whether
      * to notify the UI. A datapoint that is not a service message is ignored.
      */
-    apply(interfaceName, address, datapoint, value) {
+    apply(interfaceName, address, datapoint, value, timestamp) {
         if (!countsAsServiceMessage(datapoint, value)) {
             return false;
         }
         return value
-            ? this.#set(interfaceName, address, datapoint, value)
+            ? this.#set(interfaceName, address, datapoint, value, timestamp)
             : this.clear(interfaceName, address, datapoint);
     }
     /** Applies an `event` callback; the same thing, named for the call site. */
@@ -106,11 +133,22 @@ export class ServiceMessageStore {
         }
         return changed;
     }
-    /** Replaces everything an interface has with a fresh `getServiceMessages` answer. */
+    /**
+     * Replaces everything an interface has with a fresh `getServiceMessages` answer.
+     *
+     * Issue #150: a message that is still there with the same value keeps the time it was first
+     * seen. Rebuilding the map from scratch stamped every row with "now", so pressing Refresh
+     * moved the "Since" column of six-day-old messages to this minute.
+     */
     replaceInterface(interfaceName, tuples) {
+        const previous = new Map();
+        for (const record of this.forInterface(interfaceName)) {
+            previous.set(`${record.address}|${record.datapoint}`, record);
+        }
         this.#byInterface.delete(interfaceName);
         for (const [address, datapoint, value] of tuples) {
-            this.apply(interfaceName, address, datapoint, value);
+            const kept = previous.get(`${address}|${datapoint}`);
+            this.apply(interfaceName, address, datapoint, value, kept?.value === value ? kept.timestamp : undefined);
         }
     }
     /** Removes one message. Returns true when there was one. */
@@ -155,7 +193,7 @@ export class ServiceMessageStore {
     toTuples(interfaceName) {
         return this.forInterface(interfaceName).map((message) => [message.address, message.datapoint, message.value]);
     }
-    #set(interfaceName, address, datapoint, value) {
+    #set(interfaceName, address, datapoint, value, timestamp) {
         let channels = this.#byInterface.get(interfaceName);
         if (!channels) {
             channels = new Map();
@@ -177,7 +215,7 @@ export class ServiceMessageStore {
             datapoint,
             value,
             acknowledgeable: isAcknowledgeable(datapoint),
-            timestamp: this.#now(),
+            timestamp: timestamp ?? this.#now(),
         });
         return true;
     }

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

@@ -1,6 +1,6 @@
 {
   "name": "@homematic-manager/core",
-  "version": "3.0.0-beta.2",
+  "version": "3.0.0-beta.21",
   "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.2",
+  "version": "3.0.0-beta.21",
   "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.2",
-    "@homematic-manager/core": "3.0.0-beta.2",
+    "@homematic-manager/backend": "3.0.0-beta.21",
+    "@homematic-manager/core": "3.0.0-beta.21",
     "binrpc": "^4.2.0",
     "homematic-rega": "^2.0.0",
     "homematic-xmlrpc": "^2.0.0",