Contrôle MQTT en temps réel

astuce

Le contrôle MQTT en direct est destiné au contrôle en direct. Pour envoyer des plannings à l'avance, voir Contrôle MQTT Programmé à la place.

Ce guide vous aidera à configurer MQTT sur votre SmartgridOne Controller pour contrôler et surveiller à distance les installations de batteries et de panneaux solaires.

Ce dont vous avez besoin

SmartgridOne Controller avec connectivité internet.
Identifiants MQTT : Cela peut être demandé en envoyant un e-mail à support@eniris.be.
Environnement de développement Python (ou tout autre client MQTT). Ce guide utilise un exemple de base écrit en Python pour vous aider à démarrer avec MQTT et l'envoi de commandes. Nous recommandons d'utiliser Python pour sa simplicité d'utilisation, mais tout autre client MQTT est supporté.

Informations supplémentaires

MQTT est un protocole de communication rapide sur internet. C'est un système de messagerie public/abonné, qui permet une connexion directe entre votre machine et le SmartgridOne Controller. Vos actifs sont classés en groupes solaires, batteries, véhicules électriques (VE) et HVAC.

Configuration pour la première fois (Point de départ pour les nouveaux utilisateurs)

J'ai un SmartgridOne Controller que j'aimerais configurer pour le contrôle à distance MQTT.

1. Vérifiez votre réseau

Assurez-vous que votre réseau permet le trafic réseau mqtt sur le port 1883. Vous pouvez le faire en utilisant la commande :

nc -zv mqtt.eniris.be 1883

Lorsque cette commande n'est pas disponible, vous pouvez alternativement télécharger et exécuter ce code python.

En cas de doute, consultez votre ingénieur réseau ou utilisez temporairement le point d'accès 4G/5G de votre téléphone lorsque des erreurs de connexion se produisent.

remarque

Lorsque le port 1883 n'est pas accessible depuis votre réseau, nous proposons une solution de secours sur le port 80. Cela peut être configuré dans votre client MQTT à une étape ultérieure de ce manuel.

2. Ajoutez vos appareils

Connectez-vous à l'interface de mise en service et assurez-vous que les appareils sont ajoutés au SmartgridOne Controller.

3. Ajoutez le signal externe MQTT

4. Activez le signal à distance MQTT

Le champ 'VPP ID' doit rester vide.

Le délai du mécanisme de secours indique au SmartgridOne Controller combien de temps il doit attendre de nouvelles commandes. Lorsque le SmartgridOne Controller cesse de recevoir des commandes, il adopte automatiquement la stratégie par défaut après ce délai.

Ensuite, sélectionnez tous les appareils que vous souhaitez inclure dans le contrôle à distance MQTT.

5. Le signal à distance est ajouté

L'interface de contrôle à distance MQTT a maintenant été activée sur le SmartgridOne Controller.

Nous sommes maintenant prêts à envoyer quelques commandes de base en utilisant un exemple simple. La colonne Statut vous indique si une commande est active.

Script de démonstration Python

Un bon point de départ serait de tester votre nouvelle intégration configurée avec un exemple simple.

Ce code de test fait un travail simple d'envoi continu des commandes suivantes :

Batterie : Chargement à 5 kW
Solaire : Régler la puissance à 0 kW

Le SmartgridOne Controller répond en continu avec un message de 'retour' contenant les valeurs de puissance de la grille et des actifs observés. Cette fonctionnalité est également incluse dans cet exemple.

Veuillez télécharger le fichier ci-dessous dans votre IDE Python préféré. Remplissez votre numéro de série et vos identifiants MQTT et exécutez le script :

Lorsque ceci est réussi, vous pouvez continuer à envoyer d'autres types de commandes. Toutes les commandes sont décrites dans notre documentation de Contrôle à distance MQTT.

Documentation MQTT pour l'envoi de commandes

Cette section détaille le format de message MQTT et les exigences de charge utile pour contrôler à distance les politiques de puissance sur les appareils dans le réseau du SmartgridOne Controller.

Sujet MQTT

Le sujet MQTT utilisé pour envoyer des commandes est structuré comme suit :

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Où 'controller SN' doit être remplacé par le numéro de série réel du SmartgridOne Controller que vous souhaitez contrôler.

Structure de la charge utile MQTT

Les commandes sont envoyées en tant que charges utiles JSON. La structure de la charge utile est conçue pour spécifier diverses politiques de gestion de la puissance et points de consigne pour différents composants du système de réseau intelligent. Voici l'esquisse de la charge utile avec des descriptions de champs détaillées :

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "<Policy Type>",
        "<Component Power Setpoint>": <Setpoint in watts>
    }
}

Description des champs

astuce

Plusieurs types d'appareils (par exemple, batteries + solaires) peuvent être contrôlés en même temps.

extraTags (Objet) :
- nodeId (Chaîne) : Un identifiant unique pour le nœud au sein du réseau du SmartgridOne Controller. Cela correspond à votre numéro de série, suivi de '_site_0' pour la plupart des appareils SmartgridOne Controller.
time (Entier) : Horodatage Unix en secondes indiquant le moment où le message est envoyé.
fields (Objet) :
- <Component>_policy (Chaîne) : Type de politique pour le composant. Il est facultatif et si non spécifié, le système reviendra au réglage par défaut du SmartgridOne Controller.
- <Component>_power_setpoint_w (Flottant) : Point de consigne de puissance souhaité en watts pour le composant. Ceci est facultatif et uniquement pertinent si une politique correspondante est spécifiée.

Composants et politiques

info

Les actifs du même type (par exemple, deux batteries) seront combinés comme un seul composant. Par exemple, lorsque deux batteries de 5 kWh sont installées, elles seront considérées comme une batterie de 10 kWh.

Chaque composant dans l'objet fields peut inclure une politique et un point de consigne de puissance. Les composants suivants peuvent être contrôlés :

solar_policy et solar_power_setpoint_w :
- Contrôle la politique de génération d'énergie solaire et le point de consigne. Politiques supportées :
  - Politique point de consigne : Réglez la puissance maximale produite par l'ensemble des installations solaires connectées. Le champ solar_power_setpoint_w doit être défini sur la limite de puissance de production en watts.
  - Politique de restriction d'alimentation : Produire à pleine puissance, suivant les limites actuelles du réseau.
  - Politique de coût : Active la minimisation des coûts des prix à venir (marché EPEX Spot) sur la production solaire. Lorsque des prix d'injection négatifs se produisent, nous limitons la production à la consommation propre. Lorsque les prix de retrait et d'injection sont tous deux négatifs, nous déconnectons toutes les installations solaires. Le champ solar_power_setpoint_w est ignoré.
  - Politique d'arrêt : Désactive toute interaction pour tous les actifs solaires. Avertissement : les limites ne sont pas gardées dans ce mode. Le champ solar_power_setpoint_w est ignoré.
storage_policy et storage_power_setpoint_w :
Contrôle la politique du système de stockage d'énergie et le taux de décharge ou de charge d'énergie.
- Point de consigne de la politique : Définit la puissance de charge totale (point de consigne positif) ou la puissance de décharge (point de consigne négatif) pour le groupe de batteries. Lorsque plusieurs batteries sont connectées, le point de consigne est réparti par la puissance de charge/décharge disponible afin de stresser les batteries de manière équitable. Le champ storage_power_setpoint_w est réglé sur la puissance de batterie souhaitée.
- Coût de la politique : Active l'optimisation des coûts par prix à venir (marché EPEX Spot) sur les batteries, en les rechargeant pendant les heures peu coûteuses et en utilisant l'énergie durant les heures coûteuses. Le champ storage_power_setpoint_w est ignoré.
- Auto-consommation de la politique : Active un algorithme simple d'auto-consommation sur les batteries. La production solaire excédentaire est stockée dans la batterie et lorsque le soleil est couché, l'énergie est prélevée de la batterie. Le champ storage_power_setpoint_w est ignoré.
- Politique désactivée : Désactive toute interaction pour tous les actifs de batterie. Avertissement : les limites ne sont pas surveillées en mode désactivé. Le champ storage_power_setpoint_w est ignoré.
heat_pump_policy :
- Active/désactive les systèmes de pompe à chaleur. Les temps d'activation minimum et maximum seront toujours respectés.
  - Coût de la politique : Active l'optimisation des coûts par prix à venir (marché EPEX Spot) sur les pompes à chaleur. L'algorithme de tarification dynamique local détermine les meilleurs périodes d'activation.
  - Auto-consommation de la politique : Active les pompes à chaleur si un excédent d'énergie solaire est produit.
  - Politique d'extinction : Éteint les pompes à chaleur.
  - Politique d'activation : Allume les pompes à chaleur.
switched_load_policy :
- Active/désactive les systèmes contrôlés par relais. Cela pourrait être le relais intégré ou les relais connectés au réseau.
  - Coût de la politique : Active l'optimisation des coûts par prix à venir (marché EPEX Spot) sur le relais.
  - Auto-consommation de la politique : Active le relais si un excédent d'énergie solaire est produit.
  - Politique d'extinction
  - Politique d'activation
variable_power_load_policy et variable_power_load_power_setpoint_w :
- Gère la politique de consommation d'énergie des véhicules électriques et le point de consigne.
  - Point de consigne de la politique : Définit la puissance de charge totale pour le groupe de VEs. Le champ variable_power_load_power_setpoint_w est réglé sur la puissance de charge souhaitée.
  - Coût de la politique : Active l'optimisation des coûts par prix à venir (marché EPEX Spot) sur les batteries, en les rechargeant pendant les heures peu coûteuses. Le champ variable_power_load_power_setpoint_w est ignoré.
  - Auto-consommation de la politique : Active la charge si un excédent d'énergie solaire est produit. Le champ variable_power_load_power_setpoint_w est ignoré.
  - Politique désactivée : Désactive toute interaction pour tous les actifs de VE. Le champ variable_power_load_power_setpoint_w est ignoré.
site_policy et site_power_setpoint_w :
- Gère les limites d'exportation du site.
  - Exportation de la politique : Définit la limite d'exportation pour le site. Le champ site_power_setpoint_w est réglé sur la limite d'exportation.
  - Politique par défaut : Rétablit la limite du site à la puissance d'exportation par défaut, définie dans la configuration du contrôleur.

Contrôle des appareils

Des appareils spécifiques peuvent également être contrôlés, au lieu de groupes d'appareils en fonction de leurs types. Le message est structuré de manière identique :

nodeId_policy et nodeId_power_setpoint_w

info

Lorsque deux commandes sont envoyées au même actif (par exemple, une commande spécifique à un appareil à un onduleur solaire, et une commande à tous les appareils solaires), la méthode de contrôle spécifique à l'appareil prendra la préférence sur le contrôle par type d'appareil.

Comportement par défaut

Pour chaque composant, si la politique _policy et _power_setpoint_w n'est pas spécifiée, le système utilisera automatiquement la politique par défaut configurée dans le SmartgridOne Controller. Cela garantit que chaque appareil ou groupe d'appareils fonctionne en toute sécurité et continue de fonctionner même si des instructions spécifiques ne sont pas fournies.

Si aucune commande n'est envoyée, après 60 secondes (ou la période de temporisation configurée), les politiques par défaut pour les actifs seront réactivées.

Annuler des commandes existantes et revenir aux modes de contrôle locaux

Une commande active peut être annulée en envoyant un message de commande de retour.

Commande de retour

Une commande de retour annulera la commande existante immédiatement et le SmartgridOne Controller prendra le contrôle de l'installation. La politique exécutée dépend de ce qui est défini dans les paramètres du SmartgridOne Controller.

Cela peut également être utilisé dans des cas où un signal de contrôle secondaire, tel qu'un emploi du temps, est utilisé comme retour.

Exemples de messages :

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "fallback",
    }
}

Commande vide

Une commande vide peut être envoyée à tout moment pour collecter des informations sur le site. Cela ne annulera pas la commande actuelle, et ne remplacera pas les commandes provenant de signaux de contrôle secondaires de moindre priorité.

La commande vide est structurée comme suit :

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {}
}

Exemple de charge utile

Ci-dessous un exemple de charge utile pour définir diverses politiques et points de consigne :

{
    "extraTags": {
        "nodeId": "OM12404080000000000_site_0"
    },
    "time": 1714652046,
    "fields": {
        "solar_policy": "setpoint",
        "solar_power_setpoint_w": 5000,
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": -5000
    }
}

Dans cet exemple, la puissance solaire est définie pour générer jusqu'à 5000 watts, et le système de stockage d'énergie est réglé pour charger ou décharger à un taux de 5000 watts, en fonction du signe de la valeur du point de consigne. Si la solar_policy ou la storage_policy étaient omises, l'appareil respectif reviendrait aux paramètres par défaut déterminés par le SmartgridOne Controller.

Documentation MQTT pour recevoir des retours

Cette section décrit la structure et le contenu des messages de retour envoyés par le SmartgridOne Controller via MQTT. Ces messages sont publiés sur le sujet standard1/outbound/remoteControlMetrics/feedback/<Controller SN> après qu'une commande a été traitée.

Sujet de retour MQTT

Le sujet de retour MQTT est structuré comme suit :

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

Où <Controller SN> doit être remplacé par le numéro de série du SmartgridOne Controller qui envoie le retour.

Structure de la charge utile de retour MQTT

remarque

Tous les actifs sont groupés par leur type. Cela signifie que deux installations solaires individuelles de 3 kW seront traitées comme un actif de 6 kW.

Les messages de retour sont formatés en tant que charges utiles JSON. Ces charges utiles fournissent des retours détaillés sur l'état du système après avoir appliqué les commandes de point de consigne, en tenant compte des limites du réseau/appareil. Ci-dessous la structure de la charge utile de retour avec des descriptions de ses champs :

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Puissance Active du Réseau en Watts>,
                "today_imported_energy_Wh": <Énergie Importée par le Réseau en Watt-heures>,
                "today_exported_energy_Wh": <Énergie Exportée par le Réseau en Watt-heures>,
                "import_limit_W": <Limite d'Importation du Réseau en Watts>,
                "export_limit_W": <Limite d'Exportation du Réseau en Watts>,
            },
            "vpp_id": "<Identifiant de l'Usine de Puissance Virtuelle>",
            "storage": {
{
    "energy_stored_Wh": <Énergie stockée en Watt-heures>,
    "energy_capacity_Wh": <Capacité énergétique totale en Watt-heures>,
    "mean_soc_perc": <Pourcentage moyen de l'état de charge>,
    "active_power_W": <Puissance active en Watts>,
    "executed_power_W": <Point de consigne de puissance envoyé aux appareils en Watts>,
    "executed_policy": <Politique exécutée par le contrôleur>,
    "max_charge_power_W": <Puissance de charge maximale en Watts>,
    "max_discharge_power_W": <Puissance de décharge maximale en Watts>,
    "today_charged_Wh": <Énergie chargée aujourd'hui en Watt-heures>,
    "today_discharged_Wh": <Énergie déchargée aujourd'hui en Watt-heures>,
    "nr_devices": <Nombre de dispositifs de stockage contrôlés installés>
},
"solar": {
    "active_power_W": <Puissance active solaire en Watts>,
    "executed_power_W": <Point de consigne de puissance envoyé aux appareils en Watts>,
    "executed_policy": <Politique exécutée par le contrôleur>,
    "capacity_W": <Capacité solaire en Watts>,
    "today_energy_Wh": <Énergie produite aujourd'hui en Watt-heures>,
    "nr_devices": <Nombre de dispositifs solaires contrôlés installés>
},
"heat_pump": {
    "executed_policy": <Politique exécutée par le contrôleur>,
    "operation_modes": <Modes de fonctionnement de la pompe à chaleur>,
    "executed_power_W": <Point de consigne de puissance envoyé aux appareils en Watts>,
    "nr_devices": <Nombre de dispositifs de pompe à chaleur contrôlés installés>
},
"switched_load": {
    "executed_policy": <Politique exécutée par le contrôleur>,
    "devices_on": <Nombre de dispositifs allumés>,
    "devices_off": <Nombre de dispositifs éteints>,
    "executed_power_W": <Point de consigne de puissance envoyé aux appareils en Watts>,
    "nr_devices": <Nombre de dispositifs de charge commutée contrôlés installés>  
},
"variable_load": {
    "executed_policy": <Politique exécutée par le contrôleur>,
    "executed_power_W": <Point de consigne de puissance envoyé aux appareils en Watts>,
    "active_power_W": <Puissance de l'appareil en Watts>,
    "ev_requiring_charge": <Le véhicule électrique a-t-il besoin de charge>,
    "currentL1_A": <Courant de l'appareil sur la phase 1 en Ampère>,
    "currentL2_A": <Courant de l'appareil sur la phase 2 en Ampère>,
    "currentL3_A": <Courant de l'appareil sur la phase 3 en Ampère>,
    "executed_current_A": <Point de consigne de courant envoyé aux appareils en Ampère>,
    "today_charged_Wh": <Énergie chargée aujourd'hui en Watt-heures>,
    "today_discharged_Wh": <Énergie déchargée aujourd'hui en Watt-heures>,
    "total_charged_Wh": <Énergie totale chargée en Watt-heures>,
    "total_discharged_Wh": <Énergie totale déchargée en Watt-heures>,
    "min_charge_current_A": <Courant de charge minimum en Ampère>,
    "max_charge_current_A": <Courant de charge maximum en Ampère>,
    "allow_zero_current": <Le chargeur prend-il en charge la mise en pause>
},
"response_code": <Code de réponse>
},
"fields": {},
"requestTime": "<Timestamp Unix>",
"time": "<Timestamp Unix>",
"siteNodeId": "<SN du contrôleur>_site_0"
}
            - executed_policy (Str): Les politiques qui ont été appliquées aux contrôlables,
            - executed_power_W (Float): La somme de la puissance totale demandée par les actifs, envoyée par notre algorithme de contrôle.
            - active_power_W (Float): Représente la puissance active actuelle sur le réseau en watts.
            - ev_requiring_charge (Bool): Le véhicule électrique nécessite-t-il une charge ? (Une voiture est-elle connectée ?).
            - currentL1_A (Float): Courant de l'appareil sur la phase 1 en Ampère.
            - currentL2_A (Float): Courant de l'appareil sur la phase 2 en Ampère.
            - currentL3_A (Float): Courant de l'appareil sur la phase 3 en Ampère.
            - executed_current_A (Float): La somme du courant total demandé par les actifs, envoyée par notre algorithme de contrôle.
            - today_charged_Wh (Float): L'énergie chargée dans l'actif(s) de charge de véhicule électrique aujourd'hui. Remarque : Aujourd'hui est donné en temps UTC.
            - today_discharged_Wh (Float): L'énergie déchargée de l'actif(s) de charge de véhicule électrique aujourd'hui. Remarque : Aujourd'hui est donné en temps UTC.
            - total_charged_Wh (Float): L'énergie totale chargée dans l'actif(s) de charge de véhicule électrique.
            - total_discharged_Wh (Float): L'énergie totale déchargée de l'actif(s) de charge de véhicule électrique.
            - min_charge_current_A (Float): Courant minimum auquel le véhicule électrique peut être chargé.
            - max_charge_current_A (Float): Courant maximum auquel le véhicule électrique peut être chargé.
            - allow_zero_current (Bool): Le chargeur de véhicule électrique permet-il de faire une pause.
        - nodeId (Object):
            - Si un nodeId est inclus dans la commande, le retour contiendra l'état correspondant de l'appareil.
    - response_code (Int):
        - Indique l'état de l'opération. Un response_code de 0 signifie généralement succès, tandis que d'autres valeurs peuvent indiquer différents types d'erreurs ou d'informations d'état (celles-ci doivent être détaillées dans une référence séparée).

### Exemple de Charge Utile de Retour
Voici un exemple d'un message de retour suivant une commande pour définir divers points de consigne de puissance :

<ClickableImage src="/img/generic/mqtt-example-feedback.png" alt="Image 1" maxWidth="450px" />

Ce retour démontre l'état opérationnel actuel du système suite à l'exécution des points de consigne, indiquant les effets sur la génération solaire, le stockage, et l'interaction globale avec le réseau.

## Versions MQTT Supportées et Comportement sur les Sujets Non Autorisés
Lors de l'utilisation de MQTT, il est important de prendre en compte les différences de spécifications entre les versions 3.1, 3.1.1, et 5.0, notamment en ce qui concerne le comportement du courtier lorsque des clients publient sur des sujets non autorisés.

Selon la spécification MQTT 3.1.1 (voir la spécification OASIS MQTT 3.1.1, section MQTT-3.3.5-2), un courtier doit interrompre la connexion dès qu'un client envoie un PUBLISH à un sujet pour lequel il n'a pas l'autorisation. Ce comportement peut entraîner des déconnexions inattendues pour les clients tentant de publier sur des sujets mal configurés ou non autorisés.

Dans MQTT 3.1, cette exigence n'est pas présente. Lorsqu'un client publie sur un sujet non autorisé sous cette version, le courtier ignore généralement le message (chute silencieuse) sans interrompre la connexion. Cela rend MQTT 3.1 dans certains cas plus approprié lorsque la robustesse face aux erreurs de configuration ou aux permissions temporairement manquantes est plus importante que l'application stricte de la sécurité.

Bien que MQTT 5.0 introduise la possibilité de travailler avec des codes de raison (comme PUBACK avec un motif de refus), cela nécessite un support tant du côté client que du côté serveur. La migration vers MQTT 5.0 nécessite donc des efforts de mise en œuvre supplémentaires.

__Conséquences de l'Ignorance de la Compatibilité :__
Si un client se connecte en utilisant MQTT 3.1.1 et tente de publier des messages sur des sujets non autorisés, le courtier mettra brusquement fin à la session. Cela peut entraîner une instabilité, une perte de connectivité, ou une charge accrue due à des tentatives de reconnexion répétées.

__Approche Recommandée :__
Pour les systèmes où les clients peuvent (temporairement) tenter de publier sur des sujets non autorisés, ou où la gestion des erreurs n'est pas strictement mise en œuvre, nous recommandons d'utiliser MQTT 3.1. Cela garantit des connexions plus stables et évite des déconnexions non intentionnelles pendant l'exécution.

Ce dont vous avez besoin​

Informations supplémentaires​

Configuration pour la première fois (Point de départ pour les nouveaux utilisateurs)​

1. Vérifiez votre réseau​

2. Ajoutez vos appareils​

3. Ajoutez le signal externe MQTT​

4. Activez le signal à distance MQTT​

5. Le signal à distance est ajouté​

Script de démonstration Python​

Documentation MQTT pour l'envoi de commandes​

Sujet MQTT​

Structure de la charge utile MQTT​

Description des champs​

Composants et politiques​

Contrôle des appareils​

Comportement par défaut​

Annuler des commandes existantes et revenir aux modes de contrôle locaux​

Commande de retour​

Commande vide​

Exemple de charge utile​

Documentation MQTT pour recevoir des retours​

Sujet de retour MQTT​

Structure de la charge utile de retour MQTT​