Personne ne conteste qu’une plateforme IoT a besoin d’une bonne visualisation. Des données de capteurs que personne ne regarde, c’est une facture de stockage. Chaque acheteur que nous rencontrons place les “dashboards sur mesure” parmi ses premières exigences, et chaque éditeur, nous compris, répond par une démo : une jauge, une courbe, une carte avec des repères, quelques widgets sur une grille. ThingsBoard et Grafana arrivent dans la même conversation, et chacun sort une démo tout aussi convaincante.
La démo est justement le problème. Un dashboard pour un seul appareil sur grand écran ne dit rien de ce qui se passe quand le parc compte 400 appareils, quand le client veut un type de graphique que le produit ne propose pas, et quand ceux qui ont besoin des données sont des techniciens qui n’ouvriront jamais un ordinateur portable. Ces trois points décident si la visualisation passe à l’échelle, et aucun n’apparaît dans une démo.
Voici comment nous structurons la visualisation sur TagoIO pour un parc entier, et là où il faut encore écrire du code.
Un seul dashboard pour des centaines d’appareils
La première chose qui casse après la démo, c’est le nombre de dashboards. Si chaque appareil a le sien, l’appareil 400 veut dire le dashboard 400, et un changement de mise en page veut dire 400 modifications. Le clonage passe encore à dix appareils et devient ingérable à cinquante.
Un Blueprint Dashboard relie plutôt les widgets aux appareils à l’exécution. Vous construisez une seule mise en page. Chaque widget pointe vers un emplacement blueprint et non vers un appareil figé, et chaque emplacement porte un filtre par tag (type=pump, par exemple) qui décide quels appareils apparaissent dans sa liste déroulante. L’utilisateur choisit un appareil en haut du dashboard, chaque widget rattaché à cet emplacement se recharge, et le même dashboard sert toutes les pompes que vous avez taguées. Un dashboard accepte jusqu’à 20 emplacements, si bien qu’une seule vue montre une pompe et une cuve côte à côte, et des conditions de filtre peuvent enchaîner les emplacements : choisir un client réduit la liste déroulante aux capteurs de ce client.
Le piège relève de la discipline, pas des fonctionnalités. Blueprint ne fonctionne que si les appareils qui partagent un emplacement utilisent les mêmes noms de variables. Un widget qui lit pressure reste vide sur l’appareil qui envoie pump_pressure. Fixez les noms de variables et le schéma de tags dans le Payload Parser ou le Connector avant que le premier dashboard n’existe, parce que renommer des variables sur 400 appareils plus tard, c’est une semaine que personne n’a prévue au budget. Blueprint ne contrôle pas non plus qui voit quoi : ce sont les politiques d’Access Management qui associent les utilisateurs TagoRUN aux appareils par tag.
Quand le widget dont vous avez besoin n’existe pas
Les widgets natifs couvrent les cas habituels : graphiques, jauges, cartes, tableaux, listes d’appareils et d’utilisateurs, formulaires pour renvoyer des données. Tôt ou tard, un client veut quelque chose que le produit ne propose pas : une heatmap hexagonale du sol d’un entrepôt, une jauge circulaire alignée sur une charte graphique, une forme de graphique qui n’existe que dans une seule bibliothèque.
Le Custom Widget est la porte de secours. C’est une tuile sur un dashboard Normal ou Blueprint qui charge vos propres fichiers HTML, CSS et JavaScript depuis une URL que vous hébergez (TagoIO Files fait l’affaire). N’importe quelle bibliothèque de graphiques web convient, et le tutoriel ECharts est le moyen le plus rapide de voir comment se fait l’échange : inclure la bibliothèque custom-widget de TagoIO, recevoir les variables configurées de l’appareil, dessiner. Les Custom Widgets accèdent au modèle de données complet, avec les mises à jour en temps réel, le renvoi de données et le déclenchement d’une Analysis, et ils fonctionnent dans TagoRUN comme n’importe quel autre widget.
Soyons clairs : c’est du code. Quelqu’un dans votre équipe écrit et héberge du JavaScript. C’est un prix acceptable pour un graphique que la plateforme n’a pas, et un mauvais calcul quand un widget natif fait déjà l’essentiel du travail.
Il y a aussi le Custom Dashboard expérimental, où toute la page est votre fichier HTML, hébergé et versionné par TagoIO, les données arrivant par des requêtes TagoSQL enregistrées. Il tourne dans Admin et n’est disponible ni dans TagoRUN, ni en partage public, ni en distribution : traitez-le comme un outil de reporting interne. L’AI Dashboard expérimental construit une mise en page Admin pleine page à partir d’un prompt en langage naturel et l’affine par chat ; pratique pour prototyper une vue avant de s’engager sur une grille de widgets, et lui non plus n’est pas disponible dans TagoRUN.
Les mêmes vues sur les téléphones, à votre marque
La troisième chose que la démo masque, c’est le public. Les personnes qui ont le plus besoin de visualisation ne sont pas au bureau : responsables de site, techniciens de terrain, responsable d’exploitation chez le client. Ils ne se connecteront pas à une console Admin et ne toléreront pas un dashboard illisible sur un téléphone.
TagoRUN est l’endroit où vos utilisateurs finaux voient les dashboards que vous avez construits : un portail web sous votre domaine et votre marque, avec sa propre gestion des utilisateurs et des politiques d’accès par utilisateur. Le même Blueprint Dashboard s’y affiche, résolu sur les appareils que chaque utilisateur a le droit de voir. L’application mobile TagoRUN donne à ces utilisateurs les mêmes dashboards sur iOS et Android, sans développement supplémentaire.
Les notifications push sont ce que l’on oublie de vérifier pendant une démo, et elles font la moitié de la valeur du mobile. Une Action qui surveille un seuil, ou une Analysis qui mène un contrôle plus poussé, envoie une notification directement sur le téléphone des utilisateurs TagoRUN enregistrés. Les notifications envoyées depuis une Analysis peuvent porter des boutons : un technicien acquitte une alerte sans ouvrir de dashboard.
Si la fiche du store doit porter votre nom plutôt que le nôtre, l’option Custom Mobile App publie une version en marque blanche de l’application sur l’App Store et Google Play, à votre marque. Des frais uniques couvrent l’empaquetage et le déploiement ; le tarif figure sur la page Profile dans Admin.
La limite qu’un dashboard chargé finira par atteindre
Chaque chargement de dashboard consomme du Data Output. Chaque fois que quelqu’un ouvre un dashboard dans Admin ou dans TagoRUN, TagoIO compte une sortie par enregistrement affiché : un dashboard qui trace 3 000 points de données en compte 3 000. Ce compteur est distinct du Data Output Service et n’est pas facturé, mais il a un plafond mensuel strict par plan, que vous ne pouvez pas relever vous-même :
| Plan | Enregistrements de dashboard par mois |
|---|---|
| Free | 3 000 000 |
| Starter | 15 000 000 |
| Scale | 50 000 000 |
Une fois le plafond atteint, les dashboards renvoient une erreur jusqu’à la remise à zéro du mois.
Concevez avec cette limite en tête. Un graphique qui trace un mois de relevés à la minute charge environ 43 000 enregistrements chaque fois qu’un technicien y jette un coup d’œil. Agrégez dans une Analysis, stockez le résumé dans une variable, et tracez celle-ci. Définissez des plages de temps courtes par défaut. Surveillez la ligne “Dashboard Output” sous Hard Limits dans Admin avant qu’un client ne le fasse, et vérifiez les plafonds actuels dans le Data Output des dashboards.
Une liste de contrôle avant de vous engager
- Un seul dashboard peut-il servir tous les appareils d’un même type, choisis à l’exécution, sans clonage ?
- Les noms de variables et le schéma de tags sont-ils figés avant que le premier dashboard n’existe ?
- Quand un client demande un graphique que le produit n’a pas, pouvez-vous l’ajouter avec une bibliothèque web, et fonctionne-t-il encore dans le portail des utilisateurs finaux ?
- Vos utilisateurs finaux ont-ils les mêmes dashboards sur le web et sur téléphone, à votre marque, avec des notifications push issues des mêmes règles ?
- Savez-vous ce qu’un dashboard chargé coûte en Data Output, et où se situe le plafond ?
Une démo ne répond à aucune de ces questions. Une semaine avec un parc tagué, un Blueprint Dashboard, un Custom Widget et l’application mobile sur le téléphone d’un technicien y répond à toutes.
