M1 Préparation de l'intervention

Cette voie configure une passerelle depuis l'état d'usine, et produit le fichier de référence qui servira aux suivantes. Si ce fichier existe déjà, la mise en service tient en une page : Installation rapide.

Matériel

Outillage du poste d'administration

M2 se fait dans un navigateur, depuis n'importe quelle machine. M3 et M4 demandent un poste outillé :

Un poste Windows sans WSL n'exécute ni M3 ni M4. Prévoir une machine Linux ou macOS. Avec un OpenSSH antérieur à 8.5, les scripts s'arrêtent sur Bad configuration option.

Fiche de site

Douze valeurs. Elles constituent les fichiers config/<site>.env et config/<site>.balises.json.

Deux systèmes distincts y apparaissent, et la passerelle parle aux deux :

Installer le dossier de mise en service

Le dossier de mise en service contient tout ce qui sera installé dans la passerelle, ainsi que les commandes des chapitres M3 et M4. Il est remis par le fournisseur, soit sous forme d'archive, soit par un accès au dépôt Git.

Toutes les commandes de cette documentation se tapent dans un terminal : l'application Terminal sur macOS, l'émulateur de la distribution sous Linux.

1. Ouvrir un terminal.
2. Vérifier que les outils nécessaires répondent. Chaque ligne doit afficher un numéro de version :

   git --version
   python3 --version
   curl --version
   ssh -V
   sshpass -V

   Une ligne qui répond command not found signale un outil absent. Le faire installer avant de poursuivre.

3. Créer le répertoire de travail et s'y placer :

   mkdir -p ~/cloudgate-sites
   cd ~/cloudgate-sites

4. Installer le dossier de mise en service, selon ce qui a été remis.
   • Archive : la décompresser dans ce répertoire.
   • Accès Git : git clone <adresse remise par le fournisseur>
5. Entrer dans le dossier et vérifier qu'il est complet. La commande doit lister au moins config, flow, scripts et docs :

   cd cloudgate
   ls

Créer le fichier du site

Chaque site a son propre fichier de configuration, qui reçoit les valeurs de la fiche ci-dessus.

1. Choisir un nom de site : minuscules, sans espace ni accent. Il apparaîtra dans chaque commande. Exemple : mon-site.
2. Créer le fichier du site à partir du modèle fourni :

   cp config/exemple.env config/mon-site.env

3. Ouvrir config/mon-site.env dans un éditeur de texte et renseigner chaque ligne à partir de la fiche de site. Le fichier décrit ce qui est attendu pour chaque valeur.
4. Pour déclarer les capteurs dès maintenant plutôt qu'au chapitre M4 :

   cp config/balises.modele.json config/mon-site.balises.json

   puis renseigner une entrée par capteur.

Ces deux fichiers contiennent les mots de passe du site et les clés des capteurs. Ils restent sur ce poste et dans les sauvegardes du site. Ils ne sont jamais transmis avec le dossier de mise en service.

Prévenir l'administrateur d'IoBase

IoBase n'accepte pas une passerelle inconnue. Avant de lui délivrer ses identifiants, la plateforme exige qu'une personne habilitée reconnaisse l'équipement dans son interface. Cette validation est un geste humain, fait chez l'exploitant, et rien ne la remplace.

Le déroulé est le suivant :

1. En M3.6, la commande register déclare la passerelle et obtient un code d'attente.
2. L'équipement apparaît alors dans l'interface d'IoBase, en attente de validation.
3. Un administrateur l'ouvre, menu Services et équipements, puis clique sur Valider l'équipement.
4. La commande token obtient enfin les identifiants. Avant la validation, elle répond une erreur d'attente.

Rien de tout cela ne se fait en M1. Ce qui se fait ici, c'est de s'assurer qu'il y aura quelqu'un au bout :

1. Identifier, chez l'exploitant, la personne disposant d'un compte administrateur IoBase pour ce site.
2. L'informer de la date d'intervention, et de l'équipement qui apparaîtra sous le nom de passerelle choisi dans la fiche de site.
3. Convenir d'un moyen de la joindre le jour venu.

Tant que la validation n'est pas donnée, la passerelle est configurée et n'envoie rien. Le délai s'est déjà compté en jours sur ce projet. Relancer register pendant l'attente annule le code en cours et exige une nouvelle validation : l'attente repart de zéro.

Contrôles avant de commencer

1. Vérifier que le terminal se trouve dans le dossier de mise en service. La réponse doit se terminer par /cloudgate :

   pwd

2. Préparer le fichier qui sera installé dans la passerelle :

   python3 flow/build.py mon-site

   La réponse commence par flux assemblé →. Rien n'est envoyé à la passerelle à ce stade.

   Si la réponse est valeurs absentes de la configuration : suivie d'un ou plusieurs noms, ces lignes du fichier de site sont vides. Les compléter, puis relancer la commande.

3. Vérifier que l'administrateur IoBase est prévenu de la date d'intervention.
4. Vérifier que les capteurs sont présents, avec leurs étiquettes lisibles.