Manuel installateur SCADA V18

Ce manuel s'adresse aux installateurs et techniciens qui mettent en service, configurent et maintiennent une installation SCADA V18. Pour l'utilisation quotidienne par les opérateurs, voir le manuel utilisateur.

1. Architecture V18

Capteurs / Actionneurs (4-20 mA, TOR, vannes, pompes)
   │ câblage physique
   ▼
Cartes I/O Beckhoff BK9000 (coupleurs Modbus TCP + modules KL)
   │ Modbus TCP (switch ethernet)
   ▼
Mini PC industriel Linux (IPC)
   ├── Runtime (G1)  — boucle asyncio, pymodbus, port 8765
   └── Serveur (G2)  — FastAPI + WebSockets, port 8000
   │ HTTP + HTTPS (Tailscale)
   ▼
Clients navigateur / PWA mobile

Points clés V18 :

• Pas d'OpenPLC — le runtime Python parle directement Modbus TCP aux coupleurs
• Deux process séparés : Runtime (G1) + Serveur (G2) — communicants via WebSocket interne
• Deux bases SQLite : scada_v18.db (runtime, données live + historique) et serre.db côté serveur (config, bureaux, alarmes, courbes)
• Mode WAL activé sur les 2 bases — lecteurs/écrivains concurrents
• Frontend JS vanilla (pas de framework), widgets autonomes

Adresses Modbus

Les adresses Modbus de chaque canal sont calculées automatiquement selon la position physique des modules KL sur le rail Beckhoff. Vous n'avez pas à les saisir manuellement — il suffit de déclarer les modules dans le bon ordre.

2. Accès super utilisateur

Le panneau d'administration n'est pas accessible via un menu visible. Il faut entrer la combinaison clavier :

Ctrl + Alt + 2 + 2

Ce panneau contient les onglets :

3. Premier déploiement

IPC neuf (Debian 13)

Un script setup_ipc.sh automatise toute l'installation sur un IPC vierge :

git clone https://github.com/Fkruger22/serre-v17-openplc.git /opt/scada
cd /opt/scada/v18
sudo bash setup_ipc.sh

Le script installe :

• Python 3.11 + dépendances (FastAPI, pymodbus 3.x, aiosqlite, pywebpush…)
• Service systemd scada-runtime (G1) + scada-serveur (G2)
• Certificats VAPID pour Web Push
• Permissions sudo restreintes pour Tailscale

Mise à jour depuis Windows (poste dev)

Depuis le PC de développement Windows :

cd f:\scada+plc
bash deploy_v18.sh

Le script effectue : push GitHub → pull IPC → restart services → vérification statut.

4. Coupleurs Beckhoff BK9000

Le SCADA V18 communique avec des coupleurs Beckhoff BK9000 en Modbus TCP. Chaque coupleur supporte jusqu'à 64 modules KL (entrées/sorties).

Configuration du coupleur

• Adresse IP fixe à attribuer (ex: 192.168.1.3)
• Port Modbus TCP : 502 (par défaut)
• Unit ID : 0 (par défaut)
• Mode compact : pas de bits de statut dans le registre de données
• Détection fil coupé : valeur > 32767 (bit de signe)
• Registre statut : 0x100C — K-bus, configuration, watchdog
• Plage AI : 0–32767 (mode compact)

Watchdog

5. Armoires & coupleurs

Ctrl+Alt+22 → Config matériel → Armoires

Une armoire regroupe un ou plusieurs coupleurs Modbus. Elle correspond physiquement à une armoire électrique de la serre.

Créer une armoire

1. Onglet Config matériel → bouton ＋ Armoire
2. Saisissez le nom (ex: Armoire 1) et une description
3. L'armoire apparaît dans l'arborescence

Ajouter un coupleur Modbus

1. Sélectionnez l'armoire → bouton ＋ Coupleur
2. Saisissez l'IP (ex: 192.168.1.3) et le port (502 par défaut)
3. Le runtime tente la connexion — pastille verte si OK, rouge si timeout

Insertion entre coupleurs

Glissez-déposez un coupleur entre deux séparateurs animés pour l'insérer à une position précise. L'ordre dans l'arborescence reflète l'organisation physique du rail.

6. Modules KL

Catalogue KL replié + zone de drop entre séparateurs

Les modules KL Beckhoff sont les briques d'I/O insérées sur le rail à côté du coupleur. Le SCADA fournit un catalogue intégré.

Catalogue intégré

Pour ajouter un nouveau modèle non listé, modifier v18/runtime/kl_library.py.

Ajouter un module à un coupleur

1. Cliquez sur un coupleur dans l'arborescence — la zone modules s'affiche à droite
2. Le catalogue KL est replié par défaut — cliquez pour déplier les sections (DI / DO / AI / AO)
3. Glissez la référence souhaitée vers la zone de drop entre les séparateurs animés
4. Le module est inséré à la position voulue, les adresses Modbus sont recalculées automatiquement

Suppression

Survolez un module → bouton ✕ rouge avec hover. Si le module a des canaux câblés à des variables, un message détaillé liste les variables impactées avant la suppression.

7. Attribution canaux

Attribution variable physique ↔ canal Modbus

Une fois les modules KL déclarés, il faut câbler logiquement chaque variable physique de l'installation à un canal Modbus.

Workflow

1. Créez d'abord l'arborescence des équipements via le wizard d'installation
2. Onglet Config matériel → Attribution canaux
3. Liste de gauche : variables physiques de l'installation (sondes, sorties, contacts) — non câblées en haut, câblées en bas
4. Liste de droite : canaux disponibles, groupés par module KL
5. Glissez une variable de gauche sur un canal de droite
6. Pour les analogiques (AI/AO) : configurez le scaling (raw_min/raw_max → val_min/val_max) + filtre éventuel
7. Pour les digitaux (DI/DO) : pas de scaling, juste l'attribution

Scaling des entrées/sorties analogiques

val_physique = val_min + (raw - raw_min) × (val_max - val_min) / (raw_max - raw_min)

Exemple : sonde 4-20mA mesurant 0-50°C →

• raw_min = 0, raw_max = 32767 (pleine échelle BK9000 mode compact)
• val_min = -10, val_max = 60 (selon la sonde)
• Le runtime applique automatiquement la conversion à chaque cycle

Filtres

Filtres disponibles par variable (configurables dans Attribution canaux) : moyenne mobile, médiane, butterworth, plage de validité.

8. Wizard installation — Étape 1 : Domaines

Wizard installation — sélection des domaines

Le wizard d'installation crée l'arborescence des équipements logiques. Accessible depuis Config matériel → bouton Nouvelle installation ou Modifier installation.

Sélection des domaines

Cochez les domaines présents dans votre serre :

• 🌤️ Météo — station météo
• 🌡️ Climat — compartiments
• 🔥 Énergie — chaudières, ballons stratifiés, collecteurs chaleur/CO₂
• 💧 Irrigation — stations, groupes, vannes, réservoirs
• ⚙ Système — gestionnaire alarmes, coupleurs (auto)

Décocher un domaine purge ses quantités et son arbre des étapes suivantes.

9. Wizard — Étape 2 : Quantités

Pour chaque domaine activé, saisissez le nombre d'équipements de chaque type :

• Climat : nombre de compartiments
• Énergie : nombre de chaudières, ballons, collecteurs
• Irrigation : nombre de stations d'irrigation, réservoirs eau claire/drainage
• Météo : 0 ou 1 station

Les quantités sont utilisées à l'étape suivante pour générer l'arborescence par défaut.

10. Wizard — Étape 3 : Arborescence

Arborescence éditable des équipements

L'arbre des équipements est généré automatiquement à partir des quantités. Vous pouvez :

• Renommer chaque équipement (clic sur le nom)
• Ajouter des enfants optionnels (briques) — ex: ajouter une 2ᵉ sonde temperature à un compartiment
• Supprimer un équipement non obligatoire (✕)
• Côté ouvrant : sélectionner Gauche / Droite (alterne par défaut)

Auto-nommage

Les noms par défaut sont générés selon la position dans la fratrie : "Compartiment 1", "Compartiment 2"… Le flag nom_auto=1 en DB indique qu'un nom est auto-généré et donc retraduisible quand la langue change. Renommer manuellement bascule en nom_auto=0 (nom figé).

Enfants obligatoires

Le catalogue déclare des enfants obligatoires (ex: chaudière → 1 brûleur). Ces enfants sont créés automatiquement et marqués obligatoires (couleur bleue, pas de bouton ✕).

11. Wizard — Étape 4 : Liens

Définition des liens entre équipements (chaleur, CO₂)

Les liens définissent les relations entre équipements de domaines différents. Deux types :

Chaleur (règle stricte)

Chaque collecteur chaleur doit recevoir des chaudières/ballons et alimenter des circuits HT/BT. Exclusivité : une chaudière ne peut alimenter qu'un seul collecteur. Les chaudières/ballons/circuits non assignés sont grisés et bloquants.

CO₂ (règle souple)

• Chaque vanne CO₂ doit être attribuée à un collecteur CO₂
• Chaque collecteur CO₂ doit avoir au moins une source (chaudière fumées OU source CO₂ liquide)
• Pas d'exclusivité sur les sources — une chaudière peut alimenter plusieurs collecteurs CO₂

12. Wizard — Étape 5 : Validation

Récapitulatif de l'installation avant application :

• Nombre d'équipements par domaine
• Liens chaleur / CO₂ établis
• Variables physiques à câbler ensuite via Attribution canaux

Cliquez sur Appliquer au runtime :

1. Le serveur valide la cohérence (enfants obligatoires, liens, variables physiques cablees)
2. Les équipements sont insérés en DB
3. Le runtime est rechargé (lit la nouvelle config sans redémarrer le process)
4. Vous repassez à l'étape Attribution canaux pour câbler les variables physiques

13. Domaine Météo

Une seule station météo par installation. Variables physiques :

• Sondes : temperature, humidite, rayonnement (W/m²), vitesse_vent, direction_vent
• Capteur de pluie (DI)
• Optionnel : co2_ext

Variables calculées

• sunrise_min / sunset_min — calculées par calculer_soleil selon date + latitude
• rayonnement_cumul — intégrale journalière (MJ)
• securite_vent, securite_pluie, securite_gel — flags pilotés par controler_meteo_securite

14. Domaine Climat

Compartiments — la chaîne de chauffage est : compartiment → circuit HT/BT → collecteur → chaudière.

Briques sous compartiment

• sonde_temperature (1 ou plus — régulation + contrôle dérive)
• sonde_humidite
• sonde_co2
• moteur écran thermique / ombrage
• vanne_co2
• brumisateur, deshumidificateur, eclairage (sorties)
• ouvrant (côté gauche / droit, mode coefficient ou limitation vitesse vent)

Fonctionnalités activables

Onglet Fonctionnalités du compartiment :

• Chauffage (intrinsèque) — PID + bornes chauffage_kp/ki/kd
• Aération — PID
• Humidité — brumisation et déshumidification
• CO₂ — enrichissement
• Écran — énergétique nuit + ombrage jour selon rayonnement
• Éclairage — DLI cible
• Ouvrant vent / abrité — sécurité vent + bornes ouverture min/max par côté

15. Domaine Énergie

Domaine introduit en V18. Regroupe :

• Chaudières — avec brûleur 2 allures OU modulant (exclusif)
• Ballons stratifiés (open buffer)
• Collecteurs chaleur — agrègent demande circuits, distribuent vers chaudières/ballons
• Collecteurs CO₂ — distribution CO₂ vers vannes compartiment
• Source CO₂ liquide — alternative aux fumées chaudière
• Source externe (chauffage importé, ex: cogénération)

Régulation chaudière

Bornes temp_mini / temp_maxi :

• Brûleur démarre quand temp_depart < temp_mini
• Brûleur s'arrête quand temp_depart >= temp_maxi
• temp_maxi_alarme déclenche l'alarme surchauffe
• Anti-cycles via devi_min_s (TON) sur la chaudière

Brûleur 2 allures

Bascule petite/grande allure selon écart consigne avec hystérésis :

• delta_grande_allure (3 °C) — passage en grande allure
• delta_petite_allure (1 °C) — retour en petite allure
• allure_min_s (60 s) — temps min entre bascules

Brûleur modulant

PID autour de consigne → demande_bruleur 0–100 %. La modulation 0 % ≠ 0 kW (plage min→max kW selon brûleur).

V3V chaudière (anticondensation)

Régulation proportionnelle temp_retour_min = temp_depart × coeff_anticond (par défaut 0.8). Maintient le retour au-dessus de cette valeur pour éviter la condensation dans le corps de chauffe.

16. Domaine Irrigation

Hiérarchie : Station → Groupe → Vanne.

Station d'irrigation

• Pompe — débit cible
• Doseurs EC A/B/C/D — ratio configurable + cycle PWM
• Doseur pH — mode acide (pH-) OU base (pH+) (jamais les 2)
• Sondes EC/pH — sonde 1 (régulation) + sonde 2 optionnelle (détection dérive)
• Réservoirs liés (eau claire + drainage)

Groupe d'irrigation

Un groupe regroupe plusieurs vannes simultanées. Paramètres :

• 4 périodes actives (P1-P4) — début/fin en minutes
• 4 déclencheurs (D1-D4) — type (heure fixe / cyclique / joules) + paramètres associés
• Vannes simultanées par période

Vanne d'arrosage

• Mode arrêt : 0=Temps, 1=Litres, 2=cc/goutteur
• Quantité cible, nombre de goutteurs, vol/goutteur
• Confirmation_s — délai avant alarme si débit ne monte pas

17. Domaine Système

Domaine technique pour la gestion globale.

Coupleurs Modbus (auto-créés)

Pour chaque coupleur déclaré dans Config matériel, un équipement coupleur_modbus est créé automatiquement sous Système. Il expose :

• connecte (booléen)
• adresse_ip, port
• alm_defaut_coupleur (alarme K-bus / config / watchdog)

Gestionnaire d'alarmes (auto-créé)

Voir section Gestionnaire d'alarmes.

18. Régulation PID

Tous les contrôleurs (chauffage, aération, V3V, brûleur modulant) utilisent un PID standard avec gains kp / ki / kd configurables par équipement.

Réglages typiques

Les gains sont stockés en consigne et modifiables à chaud — la prochaine itération du PID utilise les nouveaux gains.

Anti-windup

Le PID intègre un saturateur d'intégrale pour éviter le wind-up quand la sortie est saturée (ex: V3V à 100 %).

19. Sécurités météo

Trois sécurités pilotées par controler_meteo_securite :

Vent fort

• seuil_vent_fort (typiquement 8-12 m/s)
• confirm_vent_s — durée min au-dessus du seuil pour activer
• seuil_vent_ok — hystérésis pour lever la sécurité
• retour_vent_s — durée min sous le seuil pour réouverture
• Action : ferme tous les ouvrants à 0 %

Pluie

• Capteur DI pluie
• confirm_pluie_s — délai de confirmation (filtre les fausses détections)
• retour_pluie_s — délai après arrêt avant réouverture

Gel

• seuil_gel (typiquement 2 °C)
• Action : ferme ouvrants + active chauffage antigel

20. Gestionnaire d'alarmes

Le gestionnaire d'alarmes agrège toutes les alarmes en 3 sorties DO classifiées :

• alm_climat_global — agrégation des alarmes compartiment / météo
• alm_irrigation_global — agrégation alarmes station/dosage/réservoir
• alm_systeme_global — agrégation alarmes coupleur / brûleur / surchauffe

Ces 3 sorties pilotent typiquement des relais externes (sirène, voyant, GSM autonome…).

Entrées externes NF

3 entrées DI normalement fermées (NF) — alarme si contact ouvert :

• entree_alarme_climat
• entree_alarme_irrigation
• entree_alarme_systeme

Permettent de remonter au SCADA des alarmes externes (groupe froid, défaut moteur, etc.).

Création automatique

Le conteneur gestionnaire_alarmes est créé automatiquement sous Système au reload runtime via _sync_coupleurs_systeme. Les 3 sorties DO + 3 entrées DI sont obligatoires (couleur bleue dans le wizard, non supprimables). L'installateur peut ajouter d'autres entree_alarme_* NF supplémentaires.

21. Réservoirs & drainage

2 types de réservoirs :

• reservoir_eau_claire — alimentation pompe irrigation
• reservoir_eau_drainage — récupération drainage

Niveaux

3 contacts DI possibles par réservoir : contact_niveau_bas, contact_niveau_milieu, contact_niveau_haut. Pour chaque niveau, configurez les actions :

• alarme — alm_niveau_*
• arret_pompe — bloque la pompe d'irrigation
• ferme_v3v — force la V3V mélange à fermée

Drainage (calcul %)

Le FB controler_drainage intègre debit_station (arrosage) + debit_drainage sur le cycle pompe ON→OFF, expose pct_drainage. Indicateur clé culture hors-sol (cible 20-30 %).

22. Courbes de programmation

Les courbes permettent de programmer une consigne variable dans le temps (ex: température jour/nuit avec rampes).

• Stockées dans data/curves.json côté serveur
• Liées à la variable (varKey), pas au tableau qui les affiche
• 8 points horaires par courbe
• Modes : Absolu / Lever ± / Coucher ±
• Le runtime relit curves.json chaque seconde et applique la valeur interpolée à la consigne
• Export/import dans la sauvegarde JSON globale

Interpolation

interpoler_courbe(curve, temps_min) calcule la valeur courante par interpolation linéaire entre les points actifs. La courbe se boucle sur 24 h.

23. VPN Tailscale

Tailscale fournit un accès distant sécurisé HTTPS sans configuration routeur. URL stable : https://scada-ipc.<tailnet>.ts.net.

Installation initiale

cd /opt/scada/v18
sudo bash install_tailscale.sh

Le script installe Tailscale, configure les permissions sudo et active tailscale serve pour le port 8000.

Onglet VPN

Ctrl+Alt+22 → onglet 🔒 VPN :

• Statut — installé / connecté au tailnet / serve actif
• Hostname, IP Tailscale, URL HTTPS
• Boutons : Install / Up / Down / Cert / Serve On / Serve Off
• Peers — liste des appareils du tailnet
• Log — sortie des commandes

Authentification initiale

Cliquez sur Up → l'URL d'authentification Tailscale est extraite et affichée. Ouvrez-la dans un navigateur, validez l'appareil dans votre tailnet.

Certificat HTTPS

Cliquez sur Cert pour générer le certificat Let's Encrypt automatique (nécessite HTTPS Certificates activé dans l'admin Tailscale).

24. Web Push (VAPID)

Les notifications push utilisent le protocole VAPID. Côté serveur :

• Module v18/serveur/push.py avec pywebpush 2.0
• Clés VAPID générées au premier boot, stockées en data/vapid_keys.json
• Table push_subscriptions en DB serveur
• Broadcast automatique sur transition alm_*_global False → True
• Cleanup auto des subscriptions mortes (50 échecs consécutifs → suppression)

Endpoints

Détection alarmes

Les alarmes sont détectées dynamiquement par pattern (préfixe alm_, securite_, entree_alarme NF). Ajouter une nouvelle alarme = ajouter le label dans fr.json/alarmes, zéro code à modifier.

25. Configuration IA

Ctrl+Alt+22 → onglet ⚙ Général → Intelligence Artificielle.

Saisissez votre clé API (sauf LM Studio qui demande l'URL http://localhost:1234). Cliquez sur Sauver.

La clé est stockée dans serre_production.db table app_settings. Les widgets IA conseil + analyse maladies utilisent cette même clé via le module ia_helpers.py.

26. Export / Import config

Export

Onglet Config matériel → bouton Exporter config. Génère un JSON contenant :

• Armoires, coupleurs, modules KL, canaux
• Équipements logiques (arborescence + alias + nom_auto)
• Variables (avec scaling et filtres)
• Consignes utilisateur
• Liens entre équipements (chaleur, CO₂)
• Fonctionnalités activées
• Courbes de programmation

Une copie horodatée est aussi sauvegardée automatiquement dans data/backups/config_YYYY-MM-DD_HHMMSS.json à chaque export.

Import

Cliquez sur Importer config, sélectionnez un fichier JSON. Le serveur efface l'installation courante et recrée tout depuis le JSON.

27. Audit V18

Le script v18/tests/audit_v18.py automatise 11 audits depuis le poste Windows de développement :

cd f:\scada+plc
python v18/tests/audit_v18.py --all --runs 3 --output v18/rapports/AUDIT_$(date +%Y_%m_%d).md

Étapes :

1. Backup config courante
2. Tests unitaires (pytest sur Function Blocks)
3. Audit sécurité (rate limiting, headers HTTP, XSS)
4. Audit architecture (taille fichiers, couplage runtime/serveur)
5. Fuzzing IA — N runs (Sonnet génère des configs aléatoires réalistes)
6. Audit adversarial (5 attaques robustesse)
7. Audit performance (taille snapshot, débit API, DB)
8. Audit frontend (doublons variables, validation)
9. Audit alarmes (déclenchement, latch, acquittement)
10. Audit i18n (symétrie FR/EN, hardcodes, fetch _urlLang)
11. Restauration config (avec relance sim_modbus pour mapping coherent)

L'audit doit toujours être lancé depuis Windows (jamais SSH IPC) — sim_modbus tourne sur le PC dev.

Cohérence catalogue ↔ runtime

L'analyse statique catalogue ↔ runtime (catégories A-F) est faite par Claude Code en fin d'audit, puis appendée au fichier rapport. Elle vérifie qu'aucune variable lue/écrite par un FB n'est absente du catalogue, et que tous les FB sont orchestrés dans main.py.

28. Simulation Modbus

Le serveur Modbus de simulation simulation/sim_modbus.py permet de tester sans matériel terrain.

Lancement

cd f:\scada+plc
start_sim.bat

Ouvre une console séparée. Le sim sert à 192.168.1.3:502 et expose un serveur HTTP de scénarios sur :7001.

Mode nominal

Météo réelle Open-Meteo + oscillations T° + rétroaction simple (ouvrir un ouvrant fait baisser la température).

Scénarios métier

POST sur http://localhost:7001/scenario/<nom> :

• alarme_externe_climat — force le contact NF entree_alarme_climat à ouvert
• alarme_externe_irrigation
• alarme_externe_systeme
• niveau_bas_drainage
• defaut_sonde
• reset — retour mode nominal

Override primitif

POST http://localhost:7001/force {"fc":4,"addr":0,"val":12345} — forcer une valeur Modbus brute.

29. Mise à jour

Pour déployer une nouvelle version sur l'IPC :

cd f:\scada+plc
bash deploy_v18.sh

Le script :

1. git push depuis Windows vers GitHub
2. SSH IPC → git pull
3. pip install -r requirements.txt (si modifié)
4. systemctl restart scada-runtime scada-serveur
5. Vérification statut /api/status

Service worker (PWA)

À chaque mise à jour qui touche le frontend, bumpez CACHE_NAME dans sw.js (ex: v95 → v96). Le SW activera automatiquement la nouvelle version et les clients PWA se rechargeront via controllerchange.

30. Sauvegarde DB

Les 2 bases sont en mode WAL avec auto_vacuum INCREMENTAL. Sauvegarde recommandée :

• Quotidien : data/scada_v18.db (runtime + historique)
• Quotidien : data/serre.db (config serveur, alarmes, courbes)
• Hebdomadaire : data/serre_production.db (cultures, opérateurs, sessions)
• Backups config JSON dans data/backups/

Pour archiver manuellement :

sqlite3 data/scada_v18.db ".backup data/backups/scada_v18_$(date +%Y%m%d).db"

31. Function Blocks runtime

27 FB Python dans v18/runtime/fonctions/ :

Ordre d'orchestration dans runtime/main.py : météo → compartiments (chauffage, aération, CO₂…) → circuits → chaudières → irrigation → réservoirs → alarmes globales. Cycle 1 s par défaut.

32. API REST principale

Lecture

Écriture

WebSocket

ws://<host>:8000/ws — diffusion snapshot complet à chaque cycle runtime + broadcast alarmes événementiel.

33. Dépannage

Runtime déconnecté

1. Vérifier systemctl status scada-runtime
2. Logs : journalctl -u scada-runtime -f
3. Tester ping coupleur : ping 192.168.1.3
4. Tester Modbus : nc -vz 192.168.1.3 502

Tableaux système vides

• Le picker peut tarder à charger après reload — attendre 1-2 s
• Vérifier que les variables physiques sont câblées (Attribution canaux)
• Vérifier les fonctionnalités activées sur l'équipement

Push notifications ne marchent pas

• Nécessite HTTPS (Tailscale ou autre) — pas en HTTP local
• Vérifier que les clés VAPID existent dans data/vapid_keys.json
• Vérifier que le service worker est enregistré (DevTools → Application → Service Workers)
• Inspecter /api/push/test dans Postman pour test isolé

IA conseil retourne erreur 400

• Crédit API épuisé (le message exact s'affiche dans le widget depuis la fix HTTP body)
• Clé invalide / révoquée — recharger via Ctrl+Alt+22 → Général
• Provider tombé — basculer sur LM Studio en local le temps de la résolution

Frontend cache stale après deploy

• Hard refresh : Ctrl+Shift+R
• Si PWA installée : DevTools → Application → Service Workers → Unregister puis hard refresh
• Vérifier que CACHE_NAME a été bumpé dans sw.js

Doublons d'équipements après modifs successives

• Vérifier _DOMAINE_MAP dans routes_config_materiel.py — chaque type doit y être listé sinon parent_id=None et la réconciliation ne match pas
• Cas connu corrigé : gestionnaire_alarmes (rattaché à 'systeme' en V18.5)