Télémétrie EdgeControl — Configuration

Activer la télémétrie EdgeControl d'une centrale se fait en deux gestes : écrire l'attribut EC_TELEMETRY de la passerelle côté cloud, puis redémarrer la passerelle. Sans redémarrage, rien ne se passe, et aucun message ne le signale.

Principe

Une fois active, la passerelle lit un petit jeu de mesures (puissance active, puissance réactive, irradiance, état de charge batterie) sur les équipements déjà déclarés en Modbus ou en OPC UA, puis les envoie au cloud EdgeControl. Par défaut : une lecture toutes les 10 min et un envoi par heure, resserrés à 10 s autour de chaque changement d'état du planning.

flowchart LR
    A[Attribut EC_TELEMETRY<br/>cloud] -->|au démarrage<br/>de l'agent| B[entity_config.json<br/>passerelle]
    B --> C[Script de télémétrie<br/>toutes les 5 s]
    D[Tables Modbus / OPC UA] --> C
    C -->|envoi périodique| E[Cloud EdgeControl]

La configuration ne descend du cloud vers la passerelle qu'au démarrage de l'agent : c'est la raison du redémarrage obligatoire.

Prérequis

Élément	Attendu
Paquet bridge	2.3.2 minimum (acquisition OPC UA), 2.4.0 recommandé (état de charge batterie)
Script et déclencheur	Livrés par le paquet bridge, aucune action
Tables d'acquisition	Au moins une table `input_modbus` ou `input_opcua` déjà en place sur la passerelle
Nom des points	Chaque mesure à remonter porte un nom reconnu (voir ci-dessous)
Accès cloud	Un compte autorisé à modifier la configuration de l'entité passerelle

Les noms de points reconnus, insensibles à la casse, sont les suivants. La mesure est toujours republiée sous le nom du groupe.

Groupe	Noms reconnus (extrait)
`active_power`	`active_power`, `pac`, `ac_power`, `power`, `p`, SunSpec `W`
`reactive_power`	`reactive_power`, `qac`, `ac_var`, `var`, `q`, SunSpec `VAr`
`irradiance`	`irradiance`, `irr`, `poa`, `gi`, `global_irradiance`, SunSpec `GHI` / `POAI`
`soc`	`soc`, `state_of_charge`, `battery_soc`, `bms_soc`, SunSpec `SoC` / `ChaState`

Un point dont le nom ne figure pas dans la liste n'est jamais remonté. Renommez-le dans la table d'échange plutôt que d'en ajouter un second.

Exemples de tables d'échange

La télémétrie ne crée pas de table : elle relit celles déjà présentes sur la passerelle et n'en retient que les points au nom reconnu. Les autres points de la table restent ignorés.

Modbus

Fichier dans /etc/alemca/scripts/bridge/input_modbus/, par exemple onduleur_1.yml. Registres tirés de la table Huawei V4 de la librairie :

controllers:
- name: huawei_v4
  controller_name: onduleur_1      # instance modbus déclarée dans la config de l'agent
  slave_id: 1
  port: 502
  default:
    byte_order: ABCD
    data_type: int32
    length: 2
  holding_registers:
  - name: W                        # reconnu : groupe active_power
    address: 32080
    unit: W
  - name: VAr                      # reconnu : groupe reactive_power
    address: 32082
    unit: var
  - name: PF                       # ignoré par la télémétrie
    address: 32084
    data_type: int16
    length: 1
    scale: 0.001

Sur un site piloté par planning, le champ controller de la cible du planning doit valoir le controller_name de la table (ici onduleur_1). Sinon, la cible n'est reliée à aucune table et rien n'est lu.

OPC UA

Fichier dans /etc/alemca/scripts/bridge/input_opcua/, par exemple ppc.yml. Il s'appuie sur une instance opcua de la config de l'agent, à déclarer avec persistent: true : sans, chaque lecture rejoue une négociation de sécurité complète.

iot:
  modules:
    opcua:
      - name: opcua1
        endpoint: "opc.tcp://192.168.1.50:4840"
        persistent: true
        username: "user"
        password: "secret"

Un point OPC UA s'adresse de deux façons. Les deux peuvent cohabiter dans une même table.

Forme	Valeur attendue	Quand l'utiliser
`node`	NodeId complet, préfixe `ns=` inclus : `ns=2;s=DA.MonSite.PPC.WAPC01.W`	Cas courant : le NodeId se copie tel quel depuis l'outil de découverte ou un client OPC UA
`id` + `namespace_uri`	Identifiant sans préfixe `ns=` : `DA.MonSite.PPC.WAPC01.W`, plus l'URI d'un namespace du serveur	Table réutilisable d'un serveur à l'autre, quand l'index `ns=` peut changer

Forme node :

protocol: opcua

controllers:
- controller_name: PPC
  opcua_module: opcua1             # nom de l'instance opcua de l'agent
  default:
    data_type: float32
  nodes:
  - name: active_power             # reconnu : groupe active_power
    node: "ns=2;s=DA.MonSite.PPC.WAPC01.W"
    unit: kW
  - name: reactive_power           # reconnu : groupe reactive_power
    node: "ns=2;s=DA.MonSite.PPC.WRPC01.VAr"
    unit: kvar

Forme id + namespace_uri :

protocol: opcua
namespace_uri: "http://opcfoundation.org/Quickstarts/DataAccess"

controllers:
- controller_name: PPC
  opcua_module: opcua1
  default:
    data_type: float32
  nodes:
  - name: active_power
    id: "DA.MonSite.PPC.WAPC01.W"  # sans "ns=2;s="
    unit: kW
  - name: reactive_power
    id: "DA.MonSite.PPC.WRPC01.VAr"
    unit: kvar

Deux erreurs donnent Flush OK, 0 points sans aucun message d'erreur :

id avec le préfixe ns= : le préfixe est ajouté une seconde fois, et le nœud obtenu (ns=2;s=ns=2;s=...) n'existe pas.
namespace_uri pris au mauvais endroit : il doit figurer dans la liste des namespaces du serveur, relevée par l'outil de découverte. L'URI du certificat client de l'agent (urn:alemca:agent) n'est pas un namespace du serveur.

En cas de doute, préférez la forme node.

Étape 1 — Écrire la configuration

La configuration minimale tient en une ligne : {"enable": true}. Tout le reste est optionnel et prend les valeurs par défaut.

Elle s'écrit dans l'attribut EC_TELEMETRY de la configuration de l'entité passerelle. Par l'API :

POST /v2/core/entities/{entity_ident}/config/EC_TELEMETRY
{
  "value": { "enable": true }
}

Cet appel n'écrit que la clé EC_TELEMETRY ; les autres clés de configuration (CMD_REGULATION, etc.) restent intactes.

Configuration complète, pour ajuster les mesures ou les cadences :

{
  "value": {
    "enable": true,
    "fields": ["active_power", "reactive_power", "irradiance", "soc"],
    "period": {
      "offset": 300,
      "read": { "OFF": 10, "ON": 600 },
      "send": { "OFF": 10, "ON": 3600 }
    }
  }
}

Champ	Défaut	Bornes	Rôle
`enable`	`false`	booléen `true`	Active la télémétrie. `"true"` ou `1` ne l'activent pas.
`fields`	les 4 groupes	—	Groupes à remonter. Absent ou vide = les 4.
`period.offset` (s)	300	0 – 3600	Fenêtre autour d'un changement d'état du planning où les cadences rapides s'appliquent. `0` la désactive.
`period.read.ON` (s)	600	10 – 3600	Lecture, centrale en marche
`period.read.OFF` (s)	10	10 – 60	Lecture, centrale à l'arrêt, bridée ou dans la fenêtre
`period.send.ON` (s)	3600	10 – 86400	Envoi, centrale en marche
`period.send.OFF` (s)	10	10 – 3600	Envoi, centrale à l'arrêt, bridée ou dans la fenêtre

Une valeur hors bornes est ramenée à la borne la plus proche. Les états ON et DEFAULT du planning utilisent les cadences ON ; OFF et TARGET utilisent les cadences OFF. Sans planning du jour, la passerelle applique les cadences ON.

Pour ne pas remonter l'état de charge d'un site de stockage, listez explicitement les groupes voulus dans fields : depuis le bridge 2.4.0, soc fait partie des groupes par défaut.

Étape 2 — Redémarrer la passerelle

Redémarrez la passerelle complète (commande reboot, ou redémarrage depuis l'interface du routeur). Au démarrage, l'agent recopie la configuration cloud dans /etc/alemca/system/entity_config.json, et la télémétrie démarre dans les secondes qui suivent.

Comptez 2 à 3 min d'interruption : acquisition, régulation et accès distant sont coupés pendant ce temps.
Évitez de redémarrer pendant un créneau de régulation actif (état OFF ou TARGET du planning) : la consigne est réappliquée au redémarrage, mais pas pendant l'interruption.
Redémarrez la passerelle entière plutôt que le seul service de l'agent : à distance, arrêter l'agent coupe aussi le tunnel d'accès.

Toute modification ultérieure d'EC_TELEMETRY (cadences, groupes, désactivation) suit la même règle : écrire, puis redémarrer.

Étape 3 — Vérifier la remontée

La première donnée arrive côté cloud quelques secondes après le démarrage, puis à la cadence d'envoi : 1 h par défaut en marche. Ne concluez pas à une panne avant d'avoir attendu une période send.ON complète.

Configuration descendue : /etc/alemca/system/entity_config.json contient la clé EC_TELEMETRY avec "enable": true.
Mesures lues : le log de l'agent affiche Target <nom>: N field(s) acquired avec N supérieur à 0.
Envoi réussi : le log affiche Flush OK, N points avec N supérieur à 0.
Côté cloud : les séries active_power, reactive_power, irradiance ou soc apparaissent sur la centrale EdgeControl.

Flush OK, 0 points n'est pas un succès : l'envoi fonctionne, mais aucune mesure n'a été lue. Voir le dépannage.

Dépannage

La plupart des pannes sont silencieuses : la passerelle ne remonte rien, mais ne signale aucune erreur.

Symptôme	Cause probable	Correction
Aucune donnée, `EC_TELEMETRY` absent d'`entity_config.json`	Passerelle non redémarrée depuis l'écriture cloud	Redémarrer la passerelle (étape 2)
Aucune donnée, `EC_TELEMETRY` présent	`enable` écrit `"true"` (texte) ou `1` au lieu du booléen `true`	Réécrire `"enable": true`, puis redémarrer
`Flush OK, 0 points` en continu (Modbus)	Aucun point ne porte un nom reconnu	Renommer les points dans la table d'échange (voir Prérequis)
`Flush OK, 0 points` en continu (Modbus, avec planning)	La cible du planning ne correspond à aucun `controller_name` d'`input_modbus`	Aligner le champ `controller` de la cible sur le `controller_name` de la table
`Flush OK, 0 points` en continu (OPC UA)	Nœud mal adressé : `id:` avec un préfixe `ns=2;s=`, ou `namespace_uri` qui reprend l'URI du certificat client	Écrire le NodeId complet dans `node: "ns=2;s=..."`
`Cannot flush: edgecontrol module not loaded`	Déclencheur de télémétrie absent ou modifié	Réinstaller le paquet bridge
`Flush failed` après un redémarrage	Lien cloud pas encore monté	Aucune : réessai automatique de 10 s à 5 min
Cadences cloud ignorées	Bridge antérieur à 2.3.2, qui ne lit que `period` / `ON` / `OFF`	Mettre à jour le bridge

Pour une table OPC UA, node: est la forme la plus sûre : le NodeId relevé dans l'outil de découverte s'y colle tel quel. Voir aussi le module OPC UA.

Si le problème persiste, transmettez au support Alemca l'identifiant de la passerelle, le contenu de la clé EC_TELEMETRY et l'heure du dernier redémarrage.