Données de Télémétrie

Aggregated APIs

Les API agrégées sont principalement utilisées lorsque vous souhaitez obtenir, pour un certain type de données, une seule valeur en réponse, qui permet de résumer une certaine tendance et/ou résultat, pour une fenêtre temporelle personnalisée.

Ces types d’API sont toujours structurés comme suit:

Le path, qui permet de pointer vers les ressources souhaitées, nécessite toujours les paramètres suivants:

  • {power,frequency,wind,temperature,voltage,current,energy,kpis}: le type de ressource vers laquelle pointer. Ce paramètre ne précise pas les données réelles que vous souhaitez obtenir, mais la catégorie générale à laquelle appartiennent les données souhaitées (veuillez noter qu’un appel API n’accepte qu’une seule catégorie à la fois, il n’est actuellement pas possible de faire des appels BULK);
  • {entityID}: il peut s’agir d’un EID d’usine ou d’un appareil. Dans le premier cas, la valeur obtenue tient compte de l’agrégation de tous les appareils, pour lesquels cette valeur existe, au niveau de l’usine ; dans le second cas, la valeur obtenue fait référence à l’appareil unique d’intérêt;
  • {dataType}: représente les données réelles à obtenir. Les dataTypes disponibles varient selon les ressources pointées, une description détaillée est disponible directement dans la OpenAPIs Swagger;
  • {valuetype}: représente le type de critère d’agrégation avec lequel les données demandées sont à obtenir.

Les requêtes, qui permettent de filtrer les données demandées, nécessitent toujours les paramètres suivants:

  • {startDate}: la borne inférieure qui permet de définir le début de la fenêtre temporelle d’intérêt. Son format est YYYYMMGG (eg: 20220321);
  • {endDate}: la borne supérieure qui permet de définir la fin de la fenêtre temporelle d’intérêt. Son format est YYYYMMGG (eg: 20220322) et il doit être temporellement postérieur au {startDate};
  • {timezone}: permet de guider l’appel de l’API vers une récupération correcte des données en fonction du fuseau horaire demandé.

Un appel agrégé fournit toujours une seule valeur comme réponse, qui est manipulée en fonction de la fenêtre horaire et du fuseau horaire indiqués. Dans ce contexte, le paramètre {valuetype} a une grande importance car il varie selon la catégorie de ressources, donc de {dataType}, à obtenir.

Pour un {dataType} appartenant à la catégorie {power,frequency,wind,temperature,voltage,current,kpis}, le {valueType} peut prendre trois valeurs différentes:

  • Maximum: renvoie la valeur maximale trouvée parmi tous les échantillons présents dans le temps {startDate} et {endDate} défini fenêtre, pour le {dataType};
  • Minimum: renvoie la valeur minimale trouvée parmi tous les échantillons présents dans le temps {startDate} et {endDate} défini fenêtre, pour le {dataType};
  • Average: renvoie la valeur moyenne de tous les échantillons présents dans la fenêtre temporelle {startDate} et {endDate} défini fenêtre, pour le {dataType};

REMARQUE: pour la catégorie kpis , les considérations ci-dessus ne sont valables que si les Power-Based KPIs sont appelés. Pour plus de détails, veuillez consulter OpenAPIs Swagger.


Regardons quelques cas d’utilisation, où nous considérons une installation ( entityID: 12345678 ) avec un seul onduleur enregistré ( entityID : 87654321 ):

Pour un {dataType} appartenant à la catégorie {energy,kpis}, le {valueType} peut prendre deux valeurs différentes:

  • Cumulative: renvoie la dernière valeur cumulée disponible dans la fenêtre temporelle {startDate} et {endDate} défini fenêtre, pour le {dataType};
  • Delta: renvoie la différence entre la dernière et la première valeur cumulée disponible dans le {startDate} et {endDate} défini fenêtre, pour le {dataType};

REMARQUE: pour la catégorie kpis , les considérations ci-dessus ne sont valables que si les Energy-Based KPIs sont appelés. Pour plus de détails, veuillez consulter OpenAPIs Swagger.


Regardons quelques cas d’utilisation, où nous considérons une installation ( entityID: 12345678 ) avec un seul onduleur enregistré ( entityID : 87654321 ):