LLM en edge au-dessus des flux temps réel pour les interpréter, les qualifier, les résumer, détecter des anomalies et aider à générer des règles EMS.

Introduction

On ne place pas les données qui changent tout le temps “dans le LLM”. On place le LLM en edge au-dessus des flux temps réel pour les interpréter, les qualifier, les résumer, détecter des anomalies et aider à générer des règles EMS.

Il faut séparer deux mondes.

1. Deux familles de données

A. Données quasi statiques : description du quartier / château / bureau d’études

Ces données changent peu.

Donnée	Fréquence de changement	Où la placer ?
Description du site	Une fois / rarement	Odoo + Semantic Layer
Schéma énergétique	Rarement	JSON-LD / Energy Core Ontology
Liste équipements	À l’installation / maintenance	Odoo + catalogue
Classes ETIM	Stable	Dictionnaire central
Tags Haystack	Stable	Semantic Layer
Profils SAREF4ENER	À la configuration	Semantic Layer
Contraintes réseau	Occasionnel	EMS config / Odoo
Règles métier	Versionnées	Git / Odoo / Semantic API

Exemple :

Château de Quinsac
↓
Production PV
↓
Zendure 4000 Pro
↓
PowerHub
↓
Station de charge EV
↓
Compteur réseau
↓
Charges bâtiment

Cela doit être modélisé comme un jumeau sémantique statique :

Site Semantic Twin

Il décrit :

ce qu’il y a
où c’est installé
comment c’est connecté
quelles contraintes existent
quels points sont mesurables
quels points sont pilotables

B. Données dynamiques : mesures, états, commandes

Ces données changent tout le temps.

Donnée	Fréquence typique	Où la placer ?
Puissance PV	1 s à 1 min	Time-series DB
Puissance bâtiment	1 s à 1 min	Time-series DB
SoC batterie	5 s à 1 min	Time-series DB
Puissance charge EV	1 s à 1 min	Time-series DB
Import/export réseau	1 s à 1 min	Time-series DB
Prix énergie	15 min / 1 h	Cache EMS
Prévision météo	15 min / 1 h	Cache prévision
État défaut équipement	événementiel	Event bus
Commande charge/décharge	temps réel	EMS controller

Ces données ne doivent pas être stockées directement en JSON-LD à chaque point. Ce serait trop lourd.

La bonne pratique est :

JSON-LD / ontologie = description des objets et points
Time-series DB = valeurs qui changent dans le temps
MQTT / Modbus / API = transport des mesures et commandes

2. Où placer le LLM edge ?

Je placerais le LLM edge ici :

API / MQTT / Modbus / OCPP
↓
Edge Gateway
↓
Time-series + Event Bus
↓
LLM Edge Overlay
↓
EMS Rules / Optimizer
↓
Commandes terrain

Mais attention : le LLM ne doit pas être dans la boucle de contrôle critique.

Mauvais design

Mesure temps réel
↓
LLM
↓
Commande batterie immédiate

Risque :

latence
hallucination
non-déterminisme
audit difficile
commande dangereuse

Bon design

Mesure temps réel
↓
Règles EMS déterministes
↓
Commande sécurisée

Et en parallèle :

Mesures + contexte sémantique
↓
LLM edge
↓
diagnostic, résumé, recommandation, génération de règles candidates
↓
validation / garde-fous
↓
EMS

Donc :

Le LLM edge doit être un copilote sémantique et analytique, pas le contrôleur électrique principal.

3. Rôle exact du LLM edge

Le LLM edge serait très utile pour 8 fonctions.

Fonction	Exemple
Interprétation des points	Comprendre que battery/soc = état de charge batterie
Mapping automatique	Associer un topic MQTT à un tag Haystack ou SAREF
Détection d’anomalies explicable	“La batterie ne charge pas malgré surplus PV”
Résumé opérationnel	“Aujourd’hui, le site a importé trop d’énergie entre 18h et 21h”
Assistant de configuration EMS	Proposer une règle de peak shaving
Diagnostic local	Détecter API muette, capteur incohérent, PowerHub absent
Génération de règles candidates	“Si SoC > 80 % et PV > charges, autoriser charge EV”
Interface langage naturel	“Pourquoi la batterie n’a pas déchargé hier soir ?”

4. Données à mettre en edge

Sur un Apple M4, Mac mini, NUC ou autre gateway local, je mettrais :

Donnée locale	Pourquoi
Dernières mesures 24 h / 7 jours	Diagnostic rapide
Configuration site	Contexte local
Mapping topics → objets	Comprendre les flux
Contraintes EMS	Ne pas proposer d’action absurde
Règles actives	Explication et supervision
Logs événements	Analyse des anomalies
Embeddings locaux	Recherche documentaire locale
Petit modèle LLM quantifié	Raisonnement local hors cloud

L’Apple M4 est crédible comme machine edge pour petits modèles et traitements IA locaux : Apple indique que son Neural Engine M4 atteint jusqu’à 38 TOPS.

En revanche, pour un EMS edge, le plus important n’est pas seulement les TOPS : c’est la stabilité, les E/S réseau, la continuité de service, la consommation, le refroidissement et la capacité à redémarrer proprement.

5. Données à ne pas mettre directement dans le LLM

Je ne mettrais pas dans le LLM :

Donnée	Pourquoi
Tous les points chaque seconde	Trop volumineux
Historique complet brut	Inefficace
Commandes critiques immédiates	Non déterministe
Logique de sécurité électrique	Doit rester codée/règles
Calculs de protection	Normatif / déterministe
Actions sans validation	Risque opérationnel

Le LLM doit recevoir des fenêtres résumées, par exemple :

{
  "period": "last_15_minutes",
  "pv_power_avg_kw": 12.4,
  "building_load_avg_kw": 8.1,
  "battery_soc": 82,
  "grid_export_avg_kw": 3.7,
  "ev_charger_status": "idle",
  "active_constraints": [
    "backup_reserve_min_soc_30",
    "grid_export_limit_6kw"
  ]
}

Pas 10 000 points bruts.

6. Rôle de MQTT / Modbus / API

Oui, MQTT est très pertinent comme bus local.

Pour Victron, l’écosystème est assez favorable à l’intégration locale : la documentation Victron indique que Venus OS est le logiciel des équipements GX, que l’on peut interfacer la gamme GX via MQTT, et que le portail VRM peut être interrogé via une API REST JSON.

Victron documente aussi Modbus-TCP sur les GX devices, avec lecture et écriture de données vers chargeurs, battery monitors, inverter/chargers et autres produits connectés au GX device ; Modbus-TCP est désactivé par défaut et doit être activé dans les services.

Pour Zendure, je serais plus prudent : je prévoirais un adapter Zendure isolé dans l’architecture, car la stabilité et l’ouverture des API locales peuvent varier selon produits, firmware et politique fournisseur. Il ne faut pas que tout l’EMS dépende d’une hypothèse d’API non validée.

7. Architecture recommandée

Je ferais cette architecture :

                Cloud / SI central
     ┌────────────────────────────────────┐
     │ Odoo                               │
     │ projets, équipements, catalogue    │
     │ CCTP, DPGF, contrats, clients      │
     └────────────────────────────────────┘
                    ↓
     ┌────────────────────────────────────┐
     │ Semantic Layer centrale            │
     │ ETIM / Haystack / SAREF4ENER       │
     │ Energy Core / JSON-LD / SHACL      │
     └────────────────────────────────────┘
                    ↓ synchronisation
────────────────────────────────────────────────
                    ↓
                Edge Gateway
     ┌────────────────────────────────────┐
     │ Connecteurs terrain                │
     │ MQTT / Modbus / API / OCPP         │
     └────────────────────────────────────┘
                    ↓
     ┌────────────────────────────────────┐
     │ Time-series locale                 │
     │ mesures, états, événements         │
     └────────────────────────────────────┘
                    ↓
     ┌────────────────────────────────────┐
     │ EMS déterministe                   │
     │ règles, optimisation, sécurité     │
     └────────────────────────────────────┘
                    ↓
     ┌────────────────────────────────────┐
     │ Commandes terrain                  │
     │ batterie, EV, charges, relais      │
     └────────────────────────────────────┘

       En parallèle :
     ┌────────────────────────────────────┐
     │ LLM Edge Overlay                   │
     │ diagnostic, mapping, explication   │
     │ recommandations, règles candidates │
     └────────────────────────────────────┘

8. Positionnement précis du LLM edge

Je le positionnerais comme cela :


LLM Edge Overlay
= au-dessus des APIs et bus terrain
= au-dessus de la time-series locale
= branché sur la couche sémantique
= à côté du moteur EMS
= jamais seul maître des commandes critiques

Donc oui :

Le LLM edge peut être en overlay des APIs, de l’EMS, du Zendure, du Victron, de MQTT et des points terrain.

Mais son rôle principal est :

comprendre
mapper
résumer
diagnostiquer
expliquer
proposer

Et non :

commander directement sans garde-fous

9. Exemple concret Château de Quinsac

Description statique centrale

{
  "site": "Château de Quinsac",
  "assets": [
    "production_pv",
    "zendure_4000_pro",
    "powerhub",
    "ev_charger",
    "building_loads",
    "smart_meter"
  ],
  "semantic_profiles": [
    "ETIM",
    "Haystack",
    "SAREF4ENER",
    "EnergyCore"
  ]
}

Cette partie est produite une fois lors du bureau d’études, validée, puis synchronisée vers le edge.

Données dynamiques locales

{
  "timestamp": "2026-05-28T16:20:00+02:00",
  "pv_power_kw": 14.2,
  "building_load_kw": 6.4,
  "battery_soc": 78,
  "battery_power_kw": -3.2,
  "grid_export_kw": 4.1,
  "ev_charger_power_kw": 0
}

Cette partie est stockée en time-series locale.

Travail du LLM edge

Le LLM peut dire :

Le site exporte 4,1 kW alors que la batterie est à 78 %.
La borne EV est inactive.
Si un véhicule est présent et autorisé à charger, il serait pertinent
de déclencher une charge solaire prioritaire, sous réserve des contraintes utilisateur.

Mais la commande réelle reste faite par l’EMS :


IF pv_surplus > 3 kW
AND battery_soc > 70 %
AND ev_connected = true
AND user_deadline_ok = true
THEN enable_ev_charging_limit_3kw

10. Le bon découpage technique

Couche	Technologie possible	Rôle
Description site	Odoo + JSON-LD	Référentiel
Ontologies	ETIM / Haystack / SAREF4ENER	Sémantique
Synchronisation edge	API REST / MQTT retained config	Descendre la config
Flux terrain	MQTT / Modbus / API	Mesures et commandes
Stockage local	TimescaleDB / InfluxDB / SQLite	Historique court
Règles EMS	Node.js / Python / Rust	Décision déterministe
LLM edge	Qwen / Mistral petit modèle	Diagnostic / assistant
Dashboard	React local ou cloud	Supervision
Cloud	Odoo / Supabase / RAG	Historique long / reporting

11. Cas d’usage très pertinent pour LLM edge

A. Mapping automatique des points MQTT

Exemple :

topic: victron/battery/288/soc
value: 82

Le LLM, avec le dictionnaire Haystack/SAREF, propose :


{
  "haystackTags": ["point", "sensor", "battery", "soc"],
  "sarefProperty": "StateOfCharge",
  "unit": "%",
  "equipmentRef": "battery_001"
}

L’humain valide une fois. Ensuite, c’est déterministe.

B. Diagnostic d’incohérences

PV élevé
batterie pas pleine
export réseau positif
batterie ne charge pas

Le LLM peut produire :

Hypothèses :
1. limite de charge batterie atteinte
2. PowerHub en mode bypass
3. règle EMS désactivée
4. consigne backup reserve trop élevée
5. communication batterie indisponible

C. Explication utilisateur

Question :

Pourquoi avons-nous importé du réseau hier soir ?

Réponse LLM edge :


Entre 19h10 et 21h30, la charge bâtiment a dépassé la puissance disponible batterie.
La batterie était conservée au-dessus de 30 % pour réserve backup.
L’EMS a donc autorisé l’import réseau pour respecter la contrainte de sécurité.

12. Ma recommandation finale

Je ferais exactement ce découpage :

Central / cloud

Odoo
Semantic Layer
JSON-LD / SHACL
Catalogue équipements
Bureau d’études
Configuration site
Historique long

Edge local

MQTT / Modbus / API adapters
Time-series courte
EMS déterministe
LLM edge assistant
Dashboard local
Fail-safe rules

Pas dans le LLM

la vérité métier
les historiques complets
les commandes critiques
les protections électriques
les règles non validées

Synthèse

Oui, il y a bien deux niveaux :

1. Description statique du site
→ Odoo + JSON-LD + Energy Core + SAREF4ENER
→ créée lors du bureau d’études, modifiée rarement

2. Données dynamiques terrain
→ MQTT / Modbus / API + time-series locale
→ traitées par EMS edge
→ interprétées par LLM edge

La meilleure place du LLM edge est donc :

au-dessus des flux terrain,
à côté du moteur EMS,
connecté à la couche sémantique,
mais hors de la boucle critique de commande.

Formule clé :

Le jumeau sémantique décrit le système.
Le time-series mesure le système.
L’EMS pilote le système.
Le LLM edge explique, mappe, diagnostique et propose.