introduction
Spoony intègre un service capable de pousser des informations de point de données (ex: mesures de puissance) vers un serveur Http distant sous forme de données JSON.
Ce service permet à l'appareil d'envoyer des informations au serveur, sans avoir besoin d'une configuration réseau complexe, car l'appareil se connecte au serveur distant et utilise les protocoles standard et le format de données w3c.
Dans les applications typiques, le serveur distant est disponible via une connexion Internet, mais l'utilisation d'un serveur sur le réseau local est également possible.
Dans la plupart des cas, le serveur recevra simplement les données de l'appareil et les stockera dans une base de données, mais d'autres scénarios sont possibles en fonction des besoins des utilisateurs.
1. Exigences de base
Les exigences de base comprennent:
- Une infrastructure de serveur Http capable d'accepter une requête POST contenant des données JSON
- Une connectivité réseau entre l'appareil et le serveur
2. Mode de fonctionnement
Une fois configuré, l'appareil échantillonnera régulièrement les points de données (généralement à 1 Hz, soit un échantillon par seconde).
Une fois échantillonnées, les valeurs (appelées Records) sont encapsulées dans une trame JSON (DataChunk) et envoyées au serveur distant à l'adresse configurée, à l'aide d'une requête HTTP POST.
Si la connexion avec le serveur distant échoue, l'appareil est capable de stocker en interne jusqu'à 14400 DataChunk, ce qui représente jusqu'à 4 heures de données à une fréquence d'échantillonnage de 1 Hz.
3. Format des données
Une fois configuré, l'appareil échantillonnera régulièrement les points de données (généralement à 1 Hz, soit un échantillon par seconde).
Une fois échantillonnées, les valeurs (appelées Records) sont encapsulées dans une trame JSON (DataChunk) et envoyées au serveur distant à l'adresse configurée, à l'aide d'une requête HTTP POST.
Si la connexion avec le serveur distant échoue, l'appareil est capable de stocker en interne jusqu'à 14400 DataChunk, ce qui représente jusqu'à 4 heures de données à une fréquence d'échantillonnage de 1 Hz.
The DataChunks sent by spoony are organized as follow:
|
DataChunk |
|||
|
Nom de domaine |
Type |
|
|
|
"de" |
DataChunkSource (voir ci-dessous) |
Source de DataChunk. Identifiez le périphérique source et l'unité interne. |
|
|
“T” |
Date |
Horodatage de DataChunk. Date à laquelle le DataChunk a été envoyé depuis l'appareil. Format ISO 8601. |
|
|
“compter” |
Entier |
Nombre d'éléments dans les «éléments» du tableau suivants. |
|
|
“éléments” |
DataPointChunk[] (voir ci-dessous) |
Tableau contenant des données échantillonnées, regroupées par DataPoint. |
|
|
DataChunkSource |
||
|
Nom de domaine
|
Type |
La description |
|
"Reference de l'appareil" |
|
Identifiant de l'appareil source. Tel que configuré sur l'appareil. L'utilisateur est responsable de l'unicité des ID de périphériques au sein du serveur cible. |
|
"unité" |
|
|
|
DataPointChunk |
||
|
Nom de domaine |
Type |
La description |
|
“nom" |
Chaine |
Nom du point de données. Voir ci-dessous pour les points de données et les significations disponibles. |
|
“compter” |
Entier |
Nombre d'éléments dans les «enregistrements» du tableau suivant. |
|
"Records" |
DataPointRecord[] voir ci-dessous) |
Tableau d'archives. Chaque enregistrement est un échantillon de point de données unique. |
|
DataPointRecord |
||
|
Nom de domaine |
Type |
Description |
|
“i” |
|
Index de l'échantillon. L'index est incrémenté à chaque échantillonnage du point de données concerné. |
|
“t” |
Date |
Exemple d'horodatage. Format ISO 8601. |
|
“q” |
Chaîne |
Qualité de l'échantillon. Toujours «bon» dans les révisions actuelles des appareils. Les valeurs possibles sont: «bon», «mauvais», «incertain», «inconnu» |
|
“v” |
Point flottant |
Valeur de l'échantillon. Tous les points de données Spoony sont des nombres à virgule flottante simple précision. |
4.
Les objets JSON DataChunk (comme décrit dans les paragraphes précédents) sont envoyés au serveur distant à l'aide de requêtes HTTP POST.
Spoony envoie toujours des données en utilisant le codage de transfert Chunked, conformément à la RFC 2145.
Spoony offre deux possibilités de transfert de données: les données JSON brutes ou compressées.
4.1 Données JSON brutes
Les données JSON brutes sont transportées directement sur HTTP.
Les données JSON brutes sont envoyées au serveur distant avec l'en-tête suivant:
Type de contenu: application / json
selon RFC 1341 et RFC 4627
Protocole de transport
JSON DataChunk objects (as described in previous paragraphs), are sent to the remote server using HTTP POST requests.
Spoony always send data using Chunked transfer encoding, as per RFC 2145.
Spoony offer two possibilities for data transfert: raw or compressed JSON data.
4.1 Données JSON brutes
Les données JSON brutes sont transportées directement sur HTTP.
Les données JSON brutes sont envoyées au serveur distant avec l'en-tête suivant:
Type de contenu: application / json
selon RFC 1341 et RFC 4627
4.2 Données JSON compressées
Les données JSON sont compressées avant d'être envoyées via HTTP.
Spoony utilise un algorithme de compression spécifique basé sur LZSS adapté aux appareils contraints. La bibliothèque de compression et de décompression intégrée (et côté serveur) provient du heatshrink du projet Open-Source ( https://github.com/atomicobject/heatshrink ). Cet algorithme de compression utilise deux paramètres qui doivent être connus pour la compression et la décompression: window et lookahead.
Les données JSON compressées sont envoyées au serveur distant avec l'en-tête suivant:
Type de contenu: application / octet-stream
Selon RFC 1341 et RFC 2046
Le corps de la requête http (données binaires) est organisé comme suit:
La valeur du champ MIME_TYPE est «application / json» (donc TL = 16) lors de l'envoi de données JSON compressées.
DotVision propose gratuitement le code source utilisé pour l'analyse et la décompression des données compressées, inclus dans l'exemple de serveur Open-Source (voir paragraphe 5 ).
La compression permet une réduction de la bande passante du réseau et une utilisation réduite des données, et est particulièrement adaptée à une utilisation sur des réseaux 3G / 4G, ou tout autre type d'infrastructure de réseau à la carte.
Tout en restant conforme aux normes w3c, ce mode de fonctionnement nécessite un algorithme de décompression côté serveur propriétaire.
5. Implémentation du serveur
Voici quelques directives concernant l'implémentation du serveur:
- Le serveur DOIT accepter les requêtes HTTP POST.
- Le serveur DOIT répondre 200 OK à la requête POST si les données reçues sont valides. Si la réponse n'est pas envoyée, ou si la réponse est différente de 200 OK, Spoony réessayera d'envoyer le même DataChunk jusqu'à ce que son tampon interne déborde.
- Le serveur DOIT répondre dans les 2 secondes.
- Le serveur DEVRAIT vérifier que l'appareil source est autorisé à publier des données et DEVRAIT ignorer les données provenant d'appareils inconnus ou non autorisés.
- Le serveur DEVRAIT vérifier les données entrantes et les valider par rapport au schéma JSON fourni avant de gérer les données.
- Le serveur DEVRAIT accepter les données JSON compressées et brutes.
DotVision peut fournir aux clients un exemple d'implémentation de serveur sous la forme d'un gestionnaire Http Microsoft ® IIS Open-Source (IIS 7.0 ou plus récent), stockant les données dans une base de données InfluxDb.
Exemple de serveur:
- Bibliothèque c open-source Heatshrink écrite par Scott Vokes ( https://github.com/atomicobject/heatshrink )
- Enveloppe Heatshrink .NET C # sous forme de flux de compression / décompression et de fonctions utilitaires
- Front-end .NET C # pour recevoir des données compressées et non compressées de manière transparente à partir d'appareils.
- Exemple de gestionnaire .NET C # IIS pour les demandes DataChunk.
- Exemple de gestionnaire .NET C # IIS pour la requête Ping (utilisé pour la découverte et le diagnostic de périphérique et décrit dans un autre document).
Les deux gestionnaires stockent les données reçues dans une base de données InfluxDb spécifiée (v0.13) mais peuvent être facilement adaptés pour envoyer les données reçues à tout type de base de données.
|
Octets |
Champ |
|
Valeur |
|
0-5 |
HEADER |
En-tête de données thermorétractable |
0x50, 0x41, 0x4E, 0x44, 0x41, 0x5A |
|
6 |
V_MAJOR |
Version majeure |
0x01 |
|
7 |
V_MINOR |
Version mineure |
0x00 |
|
8 |
WINDOW |
Paramètre de compression de la fenêtre de thermorétraction |
Variable |
|
9 |
LOOKAHEAD |
Paramètre de compression Heatshrink Lookahead |
Variable |
|
10 |
TL |
Longueur de type MIME |
Variable |
|
11–(11 + TL) |
MIME_TYPE |
Type MIME de données compressées |
Variable |
|
(11+TL+1)–End |
Data |
Données compressées thermorétractables |
Variable |
La valeur du champ MIME_TYPE est «application / json» (donc TL = 16) lors de l'envoi de données JSON compressées.
DotVision propose gratuitement le code source utilisé pour l'analyse et la décompression des données compressées, inclus dans l'exemple de serveur Open-Source (voir paragraphe 5 ).
La compression permet une réduction de la bande passante du réseau et une utilisation réduite des données, et est particulièrement adaptée à une utilisation sur des réseaux 3G / 4G, ou tout autre type d'infrastructure de réseau à la carte.
Tout en restant conforme aux normes w3c, ce mode de fonctionnement nécessite un algorithme de décompression côté serveur propriétaire.
5. Implémentation du serveur
Voici quelques directives concernant l'implémentation du serveur:
- Le serveur DOIT accepter les requêtes HTTP POST.
- Le serveur DOIT répondre 200 OK à la requête POST si les données reçues sont valides. Si la réponse n'est pas envoyée, ou si la réponse est différente de 200 OK, Spoony réessayera d'envoyer le même DataChunk jusqu'à ce que son tampon interne déborde.
- Le serveur DOIT répondre dans les 2 secondes.
- Le serveur DEVRAIT vérifier que l'appareil source est autorisé à publier des données et DEVRAIT ignorer les données provenant d'appareils inconnus ou non autorisés.
- Le serveur DEVRAIT vérifier les données entrantes et les valider par rapport au schéma JSON fourni avant de gérer les données.
- Le serveur DEVRAIT accepter les données JSON compressées et brutes.
DotVision peut fournir aux clients un exemple d'implémentation de serveur sous la forme d'un gestionnaire Http Microsoft ® IIS Open-Source (IIS 7.0 ou plus récent), stockant les données dans une base de données InfluxDb.
Exemple de serveur:
- Bibliothèque c open-source Heatshrink écrite par Scott Vokes ( https://github.com/atomicobject/heatshrink )
- Enveloppe Heatshrink .NET C # sous forme de flux de compression / décompression et de fonctions utilitaires
- Front-end .NET C # pour recevoir des données compressées et non compressées de manière transparente à partir d'appareils.
- Exemple de gestionnaire .NET C # IIS pour les demandes DataChunk.
- Exemple de gestionnaire .NET C # IIS pour la requête Ping (utilisé pour la découverte et le diagnostic de périphérique et décrit dans un autre document).
Les deux gestionnaires stockent les données reçues dans une base de données InfluxDb spécifiée (v0.13) mais peuvent être facilement adaptés pour envoyer les données reçues à tout type de base de données.
Le code source fourni peut être utilisé gratuitement par les clients pour recevoir des données des appareils DotVision.
6. Configuration de l'appareil
L'appareil est configuré à l'aide de fichiers xml stockés sur la carte MicroSD intégrée.
Les fichiers suivants permettent la configuration de DataChunkWebPushService:
Le code source fourni peut être utilisé gratuitement par les clients pour recevoir des données des appareils DotVision.
6. Configuration de l'appareil
L'appareil est configuré à l'aide de fichiers xml stockés sur la carte MicroSD intégrée.
Les fichiers suivants permettent la configuration de DataChunkWebPushService:
|
Fichier: system \ services \ Device \ ODM \ ODMDataChunk \ serviceSettings.xml |
|
<configuration> <paramètres> <add key = "sourceAutomationService" value = "Automation" /> <add key = "samplingPeriod" value = "1" /> <add key = "chunkPoolSize" value = "15" /> <add key = "datapoint" value = "ade7758 / FREQ" /> <add key = "datapoint" value = "ade7758 / VRMSA" /> <add key = "datapoint" value = "ade7758 / VRMSB" /> <add key = "datapoint" value = "ade7758 / VRMSC" /> <add key = "datapoint" value = "ade7758 / IRMSA" /> <add key = "datapoint" value = "ade7758 / IRMSB" /> <add key = "datapoint" value = "ade7758 / IRMSC" /> </settings> </configuration>
|
Ce fichier contient la période d'échantillonnage (paramètre «échantillonnagePériode», exprimé en secondes, la valeur ici est 1 s), et la liste des points de données échantillonnés. Ici, les points de données suivants seront échantillonnés et envoyés au serveur distant:
ade7758 / FREQ, ade7758 / VRMSA, ade7758 / VRMSB, ade7758 / VRMSC, ade7758 / IRMSA, ade7758 / IRMSB et ade7758 / IRMSC.
Les points de données disponibles et leur signification sont expliqués au paragraphe 7 .
|
Fichier: system \ services \ Device \ ODM \ ODMWebPush \ serviceSettings.xml |
|
<WebPushService version = "1.0" > <paramètres> <add key = "uri" value = " http://www.yourserver.com:port/push " /> <add key = "shrink" value = "false" /> </settings> <headers size = "1024" > <! - size définira l'empreinte mémoire pour stocker les valeurs des en-têtes -> <add key = "User-Agent" value = "Mozilla / 5.0 (Windows; U; Windows NT 6.1; rv: 2.2) Gecko / 20110201" /> <! - la clé DOIT être un en-tête connu -> </headers> <encoder type = "DatapointRecordEncoder_Json_t" /> </WebPushService>
|
Ce fichier contient l'adresse du serveur cible (paramètre «uri»). L'adresse donnée peut inclure un numéro de port facultatif.
Le paramètre «shrink», lorsqu'il est réglé sur «true», permet la compression des données JSON comme décrit au paragraphe 4.2 . Si le paramètre est omis ou défini sur false, les données JSON brutes (non compressées) sont envoyées directement au serveur.
|
|
|
<configuration version = "1.0" >
<! - Partie gestionnaire de service -> <paramètres> <add key = "rootPath" value = "system / services / device" /> <add key = "fileName" value = "serviceSettings.xml" /> </settings>
<! - Déclaration de l'appareil -> <appareil> <serialNumber> 123456789 </serialNumber> <location> 48.8566140,2.3522220,0.0 </location> <! - PARIS -> <friendlyName> SpoonyDotVision-VirtualDevice </friendlyName> <firmwareVersion> 1.5.23 </firmwareVersion> <modèle> <manufacturer> DotVision </manufacturer> <manufacturerUrl> dotvision.com </manufacturerUrl> <name> spoony </name> <numéro> 1.5 </ numéro> <url /> <presentationUrl /> </model> </device>
<services> <service> <type> NtpClient_t </type> <name> Ntp </name> <startMode group = "2" > automatique </startMode> </service>
[. . . ]
<service> <type> ODMService_t </type> <name> ODM </name> <startMode group = "3" > automatique </startMode> </service>
<service> <type> CsvLogService_t </type> <name> CsvLog </name> <startMode group = "3" > manuel </startMode> </service> </services> </configuration> |
Le service «ODM» doit être déclaré et configuré avec startMode automatique afin d'être démarré au démarrage de l'appareil.
7. Points de données disponibles
Ces points de données sont disponibles dans le service Spoony Automation et peuvent être échantillonnés.
|
Point de données (unité / nom) |
La description |
Unité |
|
|
ODMDataChunk/TEMP |
|
°C |
|
|
ODMDataChunk /FREQ |
|
Hz |
|
|
ODMDataChunk /VRMSA |
VRMS Phase L1 |
V |
|
|
ODMDataChunk/VRMSB |
VRMS Phase L2 |
V |
|
|
ODMDataChunk/VRMSC |
VRMS Phase L3 |
V |
|
|
ODMDataChunk/IRMSA |
IRMS Phase L1 |
A |
|
|
ODMDataChunk/IRMSB |
IRMS Phase L2 |
A |
|
|
ODMDataChunk/IRMSC |
IRMS Phase L3 |
A |
|
|
ODMDataChunk/WATTA |
Puissance active Phase L1 |
W |
|
|
ODMDataChunk/WATTB |
Puissance active Phase L2 |
W |
|
|
ODMDataChunk/WATTC |
Puissance active Phase L3 |
W |
|
|
ODMDataChunk/VAA |
Puissance apparente Phase L1 |
VA |
|
|
ODMDataChunk/VAB |
Puissance apparente Phase L2 |
VA |
|
|
ODMDataChunk/VAC |
Puissance apparente Phase L3 |
VA |
|
|
ODMDataChunk/VARA |
Puissance réactive Phase L1 |
VAR |
|
|
ODMDataChunk/VARB |
Puissance réactive Phase L2 |
VAR |
|
|
ODMDataChunk/VARC |
Puissance réactive Phase L3 |
VAR |
|
|
ODMDataChunk/AWATTHR |
Phase d'énergie active L1 |
Wh |
|
|
ODMDataChunk/BWATTHR |
Phase d'énergie active L2 |
Wh |
|
|
ODMDataChunk/CWATTHR |
Phase d'énergie active L3 |
Wh |
|
|
ODMDataChunk/AVARHR |
Phase d'énergie réactive L1 |
VARh |
|
|
ODMDataChunk/BVARHR |
Phase d'énergie réactive L2 |
VARh |
|
|
ODMDataChunk/CVARHR |
Phase d'énergie réactive L3 |
VARh |
|
|
ODMDataChunk/AVAHR |
Phase énergétique apparente L1 |
VAh |
|
|
ODMDataChunk/BVAHR |
Phase énergétique apparente L2 |
VAh |
|
|
ODMDataChunk/CVAHR |
Phase énergétique apparente L3 |
VAh |
|
|
ODMDataChunk/PFA |
|
- |
|
|
ODMDataChunk/PFB |
|
- |
|
|
ODMDataChunk/PFC |
|
- |
Annexe 1: Schéma JSON des objets JSON DataChunk
|
Schéma JSON DataChunk |
|
{ "$ schema" : " http://json-schema.org/draft-04/schema# " , "title" : "SpoonyDataChunk" , "type" : "objet" , "propriétés" : { "de" : { "description" : "Source de Datachunk. Identifiez le périphérique source et l'unité interne." , "type" : "objet" , "propriétés" : { "deviceId" : { "description" : "Identificateur de périphérique source. Tel qu'il est configuré sur le périphérique. L'utilisateur est responsable de l'unicité des ID des périphériques sur le serveur cible." , "type" : "chaîne" }, "unité" : { "description" : "Source de données dans le périphérique (nom du service). Toujours ODMDataChunk dans les révisions actuelles des périphériques." , "type" : "chaîne" } } }, "t" : { "description" : "Horodatage de DataChunk. Date à laquelle le DataChunk a été envoyé depuis l'appareil. Format ISO 8601." , "type" : "chaîne" }, "count" : { "description" : "Nombre d'éléments dans le tableau" éléments "suivant." , "type" : "numéro" }, "éléments" : { "description" : "Tableau contenant des données échantillonnées, organisées par point de données." , "type" : "tableau" , "articles" : { "type" : "objet" , "propriétés" : { "nom" : { "description" : "Nom du point de données." , "type" : "chaîne" }, "count" : { "description" : "Nombre d'éléments dans le tableau suivant" enregistrements "." , "type" : "numéro" }, "enregistrements" : { "description" : "Tableau d'enregistrements. Un enregistrement est un échantillon de point de donnée unique" , "type" : "tableau" , "articles" : { "type" : "objet" , "propriétés" : { "i" : { "description" : "Index de l'échantillon. L'index est incrémenté à chaque échantillonnage du point de données concerné." , "type" : "numéro" }, "t" : { "description" : "Horodatage de l'échantillon. Format ISO 8601." , "type" : "chaîne" }, "q" : { "description" : "Qualité de l'échantillon. Toujours" bonne "dans les révisions actuelles des appareils." , "type" : "chaîne" }, "v" : { "description" : "Valeur de l'échantillon. Tous les points de données Spoony sont des nombres à virgule flottante simple précision." , "type" : "numéro" } } } } } } } } }
|
Annexe 2: Exemple d'objet JSON DataChunk
|
||
|
{ "de" : { "deviceId" : "SpoonyDotVisionDev" , "unit" : "ODMDataChunk" }, "t" : "2016-07-05T15: 13: 54.013Z" , "comte" : 29 , "éléments" : [{ "n" : "TEMP" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 25.03737 }] }, { "n" : "FREQ" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 50 000 000 }] }, { "n" : "VRMSA" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 220.03842 }] }, { "n" : "VRMSB" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 219.70237 }] }, { "n" : "VRMSC" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 220.19691 }] }, { "n" : "IRMSA" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : - 9,85277 }] }, { "n" : "IRMSB" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 7.34283 }] }, { "n" : "IRMSC" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 2,99373 }] }, { "n" : "WATTHRA" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : - 1250.21447 }] }, { "n" : "WATTHRB" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 887.71948 }] }, { "n" : "WATTHRC" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 382,72506 }] }, { "n" : "VARHRA" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : - 54,76239 }] }, { "n" : "VARHRB" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 37.80604 }] }, { "n" : "VARHRC" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 16.43738 }] }, { "n" : "VAHRA" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : - 1251.86120 }] }, { "n" : "VAHRB" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 888.86926 }] }, { "n" : "VAHRC" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 383.22750 }] }, { "n" : "WATTA" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : - 2163.50097 }] }, { "n" : "WATTB" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 1609.89099 }] }, { "n" : "WATTC" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 658,52893 }] }, { "n" : "VARA" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : - 139,41661 }] }, { "n" : "VARB" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 103,86761 }] }, { "n" : "VARC" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 30,00405 }] }, { "n" : "VAA" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : - 2167,98828 }] }, { "n" : "VAB" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 1613.23815 }] }, { "n" : "VAC" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 659.21209 }] }, { "n" : "PFA" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 0.99793 }] }, { "n" : "PFB" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 0,99792 }] }, { "n" : "PFC" , "count" : 1 , "enregistrements" : [{ "i" : 2068 , "t" : "2016-07-05T15: 13: 53.998Z" , "q" : "bien" , "v" : 0.99896 }] }] } |
Annexe 3: Exemples de tableaux de bord Grafana utilisant des données Spoony (surveillance et analyse des données en temps réel)
Tableaux de bord rendus dans un navigateur Web à l'aide de Grafana
Commentaires
0 commentaire
Vous devez vous connecter pour laisser un commentaire.