> For the complete documentation index, see [llms.txt](https://docs.myrspoven.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.myrspoven.com/myrspoven-docs/myrspoven-docs-fr/integrations/overview/bms-integrations/siemens.md).

# Siemens

L'intégration Siemens couvre deux plateformes. **Siemens Building X (BPCloud)** est la plateforme cloud et la voie recommandée pour les nouveaux sites — détaillée ci-dessous. **Siemens Desigo CC** est la plateforme héritée sur site, toujours prise en charge mais nécessitant une configuration manuelle des signaux virtuels dans le BMS ; résumée à la fin. Les deux voies ne partagent aucune prérequis.

## Siemens Building X (BPCloud)

### Ce que fait l'intégration

myCoreAI se connecte à un tenant Building X via son JSON:API public pour découvrir les équipements et les points, lire les valeurs actuelles et historiques, et écrire des consignes numériques lorsque cela est autorisé. La découverte mappe automatiquement les équipements, appareils et points de Building X vers les systèmes, composants et signaux Myrspoven.

* **Style d'API :** JSON:API sur HTTPS
* **Authentification :** Identifiants client OAuth2
* **URL de base :** `https://api.bpcloud.siemens.com/`

### Identifiants requis

Par bâtiment :

| Propriété                     | Description                                                                 |
| ----------------------------- | --------------------------------------------------------------------------- |
| `ClientId`                    | ID client OAuth2 pour le compte de service                                  |
| `ClientSecret`                | Secret client OAuth2 (à traiter comme un identifiant)                       |
| `SiemensBuildingXPartitionId` | UUID de partition Building X — périmètre du tenant pour tous les appels API |
| `ExternalBuildingId`          | GUID d'emplacement du bâtiment dans l'API de structure Building X           |

{% hint style="warning" %}
**Sécurité.** `ClientSecret` est partagé uniquement via un canal sécurisé convenu (partage via gestionnaire de mots de passe ou transfert chiffré). S'il est exposé dans un chat, un e-mail ou un ticket, le secret est renouvelé dans Building X / Auth0 puis repartagé.
{% endhint %}

### Autorisations API requises

* **API Structure (lecture) :** `équipements`, `types d'équipements`, `emplacements`, `groupes de points`, `groupes-de-points/{id}/points`
* **API Opérations (lecture) :** `appareils`, `appareils/{id}/points`, `points/{id}`, `ressource-valeur-point` (valeur actuelle et historique)
* **API Opérations (écriture) :** `POST points/{id}` — uniquement lorsque myCoreAI écrit des consignes

Un accès en lecture seule suffit pour l'analyse et le reporting. L'accès en écriture n'est requis que lorsque myCoreAI optimise activement le bâtiment.

### Découverte

La découverte s'exécute en deux phases déterministes. Les données brutes sont d'abord récupérées ; l'interprétation a lieu dans un passage séparé. Le résultat est vérifiable et reproductible d'une exécution à l'autre.

**Phase 1 — collecte des instantanés**

1. Récupérer la liste des équipements et le catalogue des types d'équipement pour la partition.
2. Résoudre le périmètre de localisation du bâtiment et filtrer les équipements pour ce bâtiment.
3. Construire une carte des appareils vers les équipements à partir de `isControlledBy` relations.
4. Récupérer les appareils dans l'emplacement du bâtiment.
5. Construire des cartes d'enrichissement des groupes de points (tags, ID d'équipement, ID d'appareil par ID de point).
6. Pour chaque appareil, récupérer ses points et résoudre l'équipement propriétaire.

**Phase 2 — étiquetage des signaux et des composants**

1. Initialiser les composants à partir des équipements en utilisant les correspondances connues des types d'équipement.
2. Convertir chaque point en signal et normaliser ses tags de groupe de points.
3. Faire correspondre au catalogue de règles (GUID de type d'équipement + tags requis/interdits) pour attribuer une position de signal et un type de composant.
4. Se rabattre sur le rattachement de composant par défaut de l'équipement lorsqu'aucune règle ne correspond.
5. Post-traitement : fusionner les doublons, dédupliquer les noms de signaux, supprimer les affectations incompatibles.

### Groupes de points et stratégie de repli

Les groupes de points de Building X lient les points aux équipements de manière déterministe. Un ID de groupe de points encode le type d'entité — `Équipement-{id}` ou `Appareil-{id}`.

La voie privilégiée est `GET /structure/partitions/{partitionId}/point-groups`. Certains tenants restreignent ce point de terminaison et renvoient HTTP 403 ; l'intégration le détecte automatiquement et se rabat sur un sondage par entité. Aucune configuration requise.

### Lecture et écriture des valeurs

**Les valeurs actuelles** sont lues avec un repli à trois niveaux par signal :

1. Point de terminaison des groupes de points (par lots — le moins de requêtes)
2. Point de terminaison des valeurs de points par lot
3. Point de terminaison de l'historique par point (dernière valeur, en dernier recours)

Le parseur de valeurs gère les chaînes, les nombres, les booléens et les éléments JSON. `« on »/« off »` et `« ouvert »/« fermé »` se normalisent en 1/0. NaN et l'infini sont rejetés.

**Valeurs historiques** sont récupérées via le point de terminaison point-value-resource avec une plage de dates UTC. La pagination est automatique.

**Les écritures** ne sont acceptées que pour des valeurs numériques finies.

### Types d'équipements et de signaux pris en charge

Le mappage des signaux est piloté par un catalogue de règles indexé sur les GUID des types d'équipement et des tags sémantiques.

| Famille d'équipements                                   | Système Myrspoven           | Exemples de positions de signaux                                                    |
| ------------------------------------------------------- | --------------------------- | ----------------------------------------------------------------------------------- |
| Unité de traitement d'air (AHU)                         | Ventilation                 | Température, pression, débit, CO₂, consignes d'air soufflé/repris                   |
| Unité terminale (VAV/CAV)                               | Ventilation                 | Commande de zone, observables de confort, position du registre                      |
| Circuit hydraulique                                     | Chauffage                   | Températures d'aller/retour, consignes, position de vanne, état de la pompe         |
| Refroidissement (groupe froid, tour de refroidissement) | Refroidissement             | Températures du groupe froid, eau du condenseur, signaux de tour de refroidissement |
| Échangeur de chaleur                                    | Chauffage / Refroidissement | Positions des vannes d'aller/retour, de dérivation et d'isolement                   |
| Compteur d'énergie                                      | Énergie                     | Points de consommation d'énergie                                                    |
| Capteurs observables                                    | Observables                 | Météo, confort de la pièce, CO₂, occupation                                         |

Les équipements hors de cette liste complètent néanmoins la découverte ; les points non appariés ne sont pas reliés automatiquement et peuvent nécessiter une extension des règles. Le fichier de diagnostics est le point de départ de cette extension.

### Liste de vérification d'intégration

* Créer un compte de service OAuth2 (flux d'autorisation par identifiants client) dans le tenant Building X / Auth0.
* Accorder l'accès en lecture — et l'accès en écriture si applicable — à la partition concernée.
* Partager `ClientId`, `ClientSecret`, `SiemensBuildingXPartitionId`, et `ExternalBuildingId` avec Myrspoven via le canal sécurisé convenu.

## Héritage : Desigo CC (sur site)

Les anciens déploiements Siemens utilisent Desigo CC sur site plutôt que Building X. Le modèle d'intégration est fondamentalement différent : au lieu d'une API cloud avec des métadonnées d'équipement structurées, myCoreAI communique via des signaux virtuels créés directement dans le BMS.

Cette voie reste prise en charge mais n'est plus recommandée pour les nouveaux sites. Les sites Desigo CC sont intégrés au cas par cas avec Myrspoven, car la configuration exacte des signaux virtuels dépend des signaux lus par rapport à ceux écrits.

Étapes générales :

1. Lancer la découverte sur le BMS pour énumérer les signaux disponibles.
2. Sélectionner les signaux à lire et à écrire.
3. Créer les signaux virtuels requis dans le BMS (configuration manuelle unique par bâtiment).
4. Relancer la découverte pour détecter les signaux virtuels.
5. Confirmer la structure résultante dans Myrspoven.

La disposition du dossier des signaux virtuels, la gestion du watchdog et le comportement de repli sont coordonnés au cas par cas avec Myrspoven afin d'éviter de perturber le BMS en fonctionnement.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.myrspoven.com/myrspoven-docs/myrspoven-docs-fr/integrations/overview/bms-integrations/siemens.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
