Illustration générée par IA — visuel conceptuel.
Pourquoi la “liste de points” d’un hôtel devient vite ingérable
Dans un projet GTB/GRMS, on reçoit souvent un export « points automate » (adresses BACnet, objets Modbus, datapoints propriétaires, etc.) qui fonctionne pour afficher des valeurs… mais ne suffit pas à exploiter le bâtiment sur la durée. Dès que l’on veut faire de la supervision maintenable, des tendances fiables, de l’analytics, ou comparer plusieurs établissements, le problème n’est plus la connectivité : c’est la sémantique.
GTB signifie gestion technique du bâtiment (BMS) ; GRMS désigne généralement le Guest Room Management System (logique de chambre, interfaces client et échanges PMS, etc.).
Project Haystack propose un modèle pragmatique, centré sur des tags, pour transformer des signaux en données réutilisables. L’objectif de cet article est opérationnel : expliquer quoi exiger au DOE (et comment le recetter) pour obtenir une base site / equip / point exploitable en exploitation hôtelière.
Project Haystack en une phrase (version exploitation)
Dans Haystack, une entité (site, équipement, point, etc.) est décrite par un dictionnaire de tags. Une partie importante du “typage” se fait via des marker tags (des tags sans valeur) dont la présence porte le sens (ex. : site, equip, point). Voir : Project Haystack — Introduction.
Cette logique permet de requêter des objets par intention (tous les point historisés d’un site, tous les equip d’un étage, etc.) plutôt que de dépendre d’une convention de nommage fragile.
Le modèle minimal à exiger au DOE : site / space / equip / point
Haystack repose sur un mécanisme de “reflection” : on considère qu’un dict implémente une définition (def) lorsqu’il contient les tags appropriés. Par exemple, si un dict contient le marker equip, il est reflété comme implémentant la def equip. Voir : Project Haystack — Reflection.
Traduction opérationnelle (exigence DOE recommandée) : livrer des entités site, space/room, equip et point clairement taguées, pour que la base soit requêtable et réutilisable (supervision, analytics, multi-sites).
1) Site : la base du multi-sites (et l’endroit où poser la timezone)
Le site est l’entité qui représente l’installation (hôtel, bâtiment, tour, etc.). Dans la pratique projet, c’est l’unité qui vous permettra de faire de la comparaison inter-établissements sans “bricolage” (mêmes tags, mêmes requêtes, mêmes dashboards).
Le tag tz (timezone) peut s’appliquer à un site et sert d’identifiant de timezone. Voir : Project Haystack — def tz.
2) Space / Room : modéliser la chambre comme un objet exploitable
En hôtellerie, une “chambre” doit exister comme entité stable, sans dépendre du libellé d’un point. Haystack définit room comme une pièce fermée d’un bâtiment et précise que room est un sous-type de space. Voir : Project Haystack — def room.
Impact exploitation : vous pouvez agréger (confort, défauts, énergie) par chambre, par typologie, par étage, puis réutiliser la même structure sur un autre site.
3) Equip : l’actif (physique ou logique) qui porte les points
Les équipements sont modélisés avec le marker equip. Voir : Project Haystack — Equips. Un point clé pour éviter les “équipements orphelins” : la documentation indique que les entités equip doivent définir un siteRef vers leur site parent.
Deux tags sont ensuite très utiles en GRMS/GTB :
spaceRefpour rattacher un équipement à un espace (ex. contrôleur de chambre rattaché à uneroom).equipRefpour modéliser la contenance/nesting d’équipements (ex. un sous-système au sein d’un ensemble).
4) Point : capteur, commande, consigne… mais toujours “attaché” à un equip
Un point est tagué avec le marker point. Voir : Project Haystack — Points. La documentation impose une règle essentielle pour la maintenabilité : un point doit être associé à siteRef et equipRef.
Ensuite, la fonction du point doit être explicite via pointFunction (classification sensor/cmd/setpoint, etc.). Voir : Project Haystack — def pointFunction.
Historisation et timezone : rendre les tendances réellement exploitables
Historiser n’est pas “cocher une case” : il faut un contrat de temps
Un point historisé est tagué his. Voir : Project Haystack — Points. Pour l’exploitation, l’enjeu n’est pas seulement de stocker des valeurs, mais d’obtenir des séries temporelles comparables (entre équipements, étages, sites) et interprétables (pas d’ambiguïtés sur le temps).
Haystack indique que si un point implémente his, alors tz et hisMode sont attendus. La même page précise que le tz d’un point historisé doit correspondre à la timezone du site du point.
Point d’attention (très pratique) : dans Haystack, tz est une chaîne (timezone name). Les valeurs attendues sont celles de la définition du tag tz (énumération) — par exemple Casablanca, UTC, New_York. Références : Points et def tz.
hisMode : sampled, cov, consumption… ce que cela change en analytics
Le tag hisMode « indicates the way that history data is collected for a point ». Voir : Project Haystack — def hisMode. Dans les faits, c’est un tag à exiger au DOE parce qu’il conditionne l’interprétation des courbes, des agrégations et des KPI.
sampled: séries échantillonnées à intervalle régulier (utile pour beaucoup de tendances de confort).cov: log sur changement (Change Of Value). La valeur “tient” jusqu’au prochain événement (utile pour des états, des modes).consumption: historique de consommation (données intégrales), avec une interprétation de timestamp “fin d’intervalle”.
Accès aux historiques : hisRead / hisWrite
Le chapitre Points mentionne les opérations d’API associées aux historiques, notamment hisRead et hisWrite. Voir : Project Haystack — Points. Pour un exploitant (ou un AMO data), cela permet de cadrer une exigence simple : les historiques doivent être exportables et testables (pas seulement visibles dans un écran).
Commande (writable) : éviter les “écrasements” entre GTB, GRMS et terrain
Le chapitre Points décrit les points commandables avec le marker writable et documente un pattern de commande incluant notamment des tags tels que writeVal, writeLevel, writeStatus, writeErr. Voir : Project Haystack — Points.
En pratique projet (recommandation) : ne livrez pas un point commandable sans livrer aussi la stratégie de priorité (qui a le droit d’écrire, et comment on diagnostique une commande non appliquée). Le but n’est pas d’exposer tous les détails au client final, mais de rendre le diagnostic possible quand plusieurs couches (commande locale, GRMS, GTB) se croisent.
Exemples de tags (hôtel) : une base simple à répliquer
Les exemples ci-dessous illustrent une structure “lisible exploitation” (site → room → equip → points). Ils doivent être adaptés à votre architecture (références, protocoles, fonctions réellement disponibles).
Format : les extraits sont au format Trio, un format texte prévu pour rédiger des entités Haystack à la main (une ligne par tag, les markers étant des tags sans valeur). Voir : Project Haystack — Trio.
Exemple 1 — Site (hôtel)
id: @hotel.demo
site
dis: "Hotel – Site Demo"
tz: "Casablanca"Note : tz est un identifiant de timezone applicable aux sites et aux points (voir la définition du tag). Project Haystack — def tz.
Exemple 2 — Chambre (room) comme space
id: @hotel.demo.r0706
room
space
dis: "Chambre 706"
siteRef: @hotel.demoLe tag room est défini comme sous-type de space. Project Haystack — def room.
Exemple 3 — Équipement “contrôleur de chambre”
id: @hotel.demo.r0706.ctrl
equip
dis: "Ch 706 – Controller"
siteRef: @hotel.demo
spaceRef: @hotel.demo.r0706Le rattachement equip → siteRef est un invariant à exiger. Project Haystack — Equips.
Exemple 4 — Température mesurée (sensor) avec historique
id: @hotel.demo.r0706.temp
point
sensor
dis: "Ch 706 – Temp"
siteRef: @hotel.demo
equipRef: @hotel.demo.r0706.ctrl
spaceRef: @hotel.demo.r0706
kind: "Number"
unit: "°C"
his
tz: "Casablanca"
hisMode: "sampled"Rappels de cadrage (issus de Points) : un point doit référencer siteRef et equipRef, et l’historisation impose tz et hisMode. Project Haystack — Points.
Exemple 5 — Occupation (consigne) “occupied sp”
Le chapitre Zones documente explicitement la combinaison occupied sp (et occupied sensor) pour modéliser l’occupation. Project Haystack — Zones.
id: @hotel.demo.r0706.occSp
point
occupied
sp
dis: "Ch 706 – Occupied (Schedule)"
siteRef: @hotel.demo
equipRef: @hotel.demo.r0706.ctrl
spaceRef: @hotel.demo.r0706
kind: "Bool"Checklist DOE (et recette) : ce qu’il faut vraiment vérifier avant réception
Un modèle Haystack “déclaratif” ne suffit pas : il doit être recetté comme un livrable d’exploitation. Voici une checklist volontairement courte (à adapter au projet).
A. Structure et requêtabilité (bloquant)
- Présence des markers d’entités attendues par votre projet (
site,space/room,equip,point) pour que le “typage” Haystack soit exploitable en requêtes (principe de reflection/implementation). Project Haystack — Reflection. - Chaque
equipa unsiteRefcohérent (pas d’équipement “sans site”). Project Haystack — Equips. - Chaque
pointasiteRef+equipRefcohérents (pas de point “hors equip”). Project Haystack — Points.
B. Typage des points (bloquant)
pointFunctionexplicite et unique (sensor/cmd/sp/synthetic, selon le besoin). Project Haystack — Points.kindcohérent avec la valeur (Bool/Number/Str) et unités renseignées lorsque nécessaire (recommandation projet : pas d’unité “implicite”).
C. Historisation (bloquant si vous faites du pilotage/analytics)
- Pour tout point
his:tzprésent, et cohérent avec le site (exigence documentée). Project Haystack — Points. hisModeprésent et cohérent avec l’usage (sampled/cov/consumption). Project Haystack — Points.- Test de recette recommandé : extraire une série temporelle via API (
hisRead), vérifier la cohérence des timestamps et la lisibilité en supervision. Project Haystack — Points.
D. Commande (si GRMS/GTB doit écrire)
- Tout point commandable est tagué
writableet expose de quoi diagnostiquer une commande (writeLevel/writeStatus/writeErr, selon implémentation). Project Haystack — Points.
E. Livrables “data” à exiger (recommandation projet)
- Un export complet des entités (sites/spaces/equips/points) au format texte (par ex. Trio) pour audit humain, et/ou au format tabulaire (par ex. Zinc) pour import/outillage.
- Un jeu de requêtes de recette (exemples) permettant de prouver la cohérence
siteRef/equipRef, et d’identifier rapidement les points historisés et commandables.
Gouvernance (projet) : ce que Haystack ne décide pas à votre place
Haystack fixe une structure sémantique, mais votre projet doit encore cadrer des règles d’exploitation. En particulier (recommandations de projet) :
- Conventions d’identifiants et de libellés (
id,dis) : stables, lisibles terrain, et réplicables sur plusieurs sites. - Choix des points historisés : historiser “tout” produit souvent un bruit inutile ; historiser “trop peu” rend l’analytics impossible. C’est un arbitrage exploitation.
- Frontière OT/IT : si les points Haystack alimentent des services analytiques ou multi-sites, la segmentation réseau et la cybersécurité doivent être cadrées (droits, accès, bastion, etc.). Sur ce volet, vous pouvez compléter avec Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?, Cybersécurité d’un hôtel connecté : comment protéger GRMS, PMS, GTB et réseau ? et Segmentation OT/IT : isoler GTB/KNX-IP/GRMS/CCTV du SI bureautique.
Articles complémentaires Domocasa (pour cadrer un projet hôtel)
- Cahier des charges GRMS hôtel : les points à spécifier avant l’appel d’offres
- GRMS : comment fonctionne la gestion intelligente d’une chambre d’hôtel ?
- PMS, GRMS, GTB, serrures et contrôle d’accès : qui échange quoi dans un hôtel ?
- Chambre témoin hôtel : comment valider le GRMS, le CVC et l’éclairage avant le déploiement ?
- GTB, GTC et BMS : quelles différences ?
Si vous souhaitez transformer ces principes en annexes DOE (tags exigés, jeux de tests, livrables d’export et critères d’acceptation), Domocasa peut accompagner la maîtrise d’ouvrage et l’exploitant sur la partie “données & exploitation” du projet.
