Qui génère le NodeId dans le cas de Matterbridge ?

La réponse dépend de ce qu’on entend par « Node ID » — dans Matterbridge, il y a en fait **plusieurs identifiants distincts**.

## 1. Node ID Matter (protocole, `bigint`)

C’est l’identifiant du nœud sur un fabric Matter (ex. `116` dans les données de test). **Ni Matterbridge ni le plugin ne le génèrent.**

Il est **attribué par le commissioner** (Apple Home, Google Home, etc.) lors du **commissioning**, puis stocké par **matter.js** dans les credentials opérationnels. Matterbridge se contente de l’exposer via `fabricInformations` :

```3337:3347:packages/core/src/matterbridge.ts
  private sanitizeFabricInformations(fabricInfo: ExposedFabricInformation[]): SanitizedExposedFabricInformation[] {
    return fabricInfo.map((info) => {
      return {
        fabricIndex: info.fabricIndex,
        fabricId: info.fabricId.toString(),
        nodeId: info.nodeId.toString(),
        rootNodeId: info.rootNodeId.toString(),
        // ...
```

**Cas particulier des appareils bridgés** : ils **n’ont pas leur propre Node ID Matter**. Ils partagent celui du bridge (ou du plugin en mode `childbridge`). Ce qui les distingue, c’est leur **numéro d’endpoint**.

En mode `server`, chaque appareil a son propre `ServerNode` et reçoit donc **son propre Node ID Matter** au moment du pairing.

---

## 2. `storeId` / `serverNode.id` (clé de stockage interne)

C’est un identifiant **texte** pour le stockage persistant (`"Matterbridge"`, nom du plugin, etc.). **C’est Matterbridge (le core) qui le choisit**, pas le plugin :

| Contexte | `storeId` |
|---|---|
| Bridge principal | `"Matterbridge"` |
| Plugin dynamique / accessoire | `plugin.name` |
| Mode `server` (appareil autonome) | `device.deviceName` sans espaces ni `.` |

```2514:2524:packages/core/src/matterbridge.ts
    this.matterbridgeContext = await this.createServerNodeContext(
      'Matterbridge',
      'Matterbridge',
      // ...
```

```1032:1040:packages/core/src/matterNode.ts
      this.matterStorageContext = await this.createServerNodeContext(
        device.deviceName.replace(/[ .]/g, ''),
        device.deviceName,
        // ...
```

Ce n’est **pas** le Node ID Matter du protocole.

---

## 3. `id` de l’endpoint (clé interne de l’appareil bridgé)

Le **plugin** le fournit en créant le `MatterbridgeEndpoint` :

```typescript
new MatterbridgeEndpoint(onOffLight, { id: 'MaLampe' })
```

Matterbridge **normalise** ensuite cet `id` :
- suppression des espaces et des `.`
- si caractères non latins → hash MD5 via `generateUniqueId()`

```372:380:packages/core/src/matterbridgeEndpoint.ts
    if (options.id && checkNotLatinCharacters(options.id)) {
      options.id = generateUniqueId(options.id);
  // ...
      id: options.id?.replace(/[ .]/g, ''),
```

---

## 4. Numéro d’endpoint Matter

Le plugin peut le fixer via `options.number`. Sinon, **matter.js** assigne le prochain numéro disponible à l’ajout de l’endpoint. Matterbridge suit ces changements dans `checkEndpointNumbers()`.

---

## Synthèse

| Identifiant | Qui le définit ? |
|---|---|
| **Node ID Matter** (`bigint`) | Le **commissioner** (écosystème Matter), pas Matterbridge ni le plugin |
| **`storeId`** du `ServerNode` | **Matterbridge** (core) |
| **`id` de l’endpoint** | Le **plugin** (avec normalisation par Matterbridge) |
| **Numéro d’endpoint** | Le **plugin** (optionnel) ou **matter.js** (auto) |

En pratique : pour un appareil bridgé classique, le plugin choisit l’`id` interne et éventuellement le numéro d’endpoint ; le **Node ID Matter** n’existe qu’au niveau du bridge/plugin parent et est fixé au pairing.