Commande MQTT en temps réel

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

Configuration initiale (point de départ pour les nouveaux utilisateurs)

Je possède un SmartgridOne Controller que j'aimerais configurer pour le contrôle à distance via MQTT.

Avant de continuer, assurez-vous que votre réseau et vos appareils sont prêts en suivant le guide Configuration MQTT.

1. Ajouter le signal externe MQTT

2. Activer le signal distant MQTT

Le délai d'expiration du mécanisme de repli indique au SmartgridOne Controller combien de temps il doit attendre de nouvelles commandes. Lorsque le SmartgridOne Controller cesse de recevoir des commandes, il reprend automatiquement la stratégie par défaut à l'issue de ce délai.

Ensuite, sélectionnez tous les appareils que vous souhaitez inclure dans la commande à distance MQTT.

3. Le signal distant est ajouté

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

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

Script de démonstration Python

Pour commencer, il serait pertinent de tester votre intégration nouvellement configurée avec un exemple simple.

Ce code de test se contente d'envoyer en continu les commandes suivantes :

• Batterie : charger à 5 kW
• Solaire : régler la puissance sur 0 kW

Le SmartgridOne Controller répond en continu avec un message de « feedback » contenant les valeurs observées de puissance du réseau et des actifs. Cette fonctionnalité est également incluse dans cet exemple.

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

Une fois l'opération ci-dessus réussie, vous pouvez continuer à envoyer d'autres types de commandes. Toutes les commandes sont décrites dans notre documentation sur la commande à distance MQTT.

Documentation MQTT pour l'envoi de commandes

Cette section décrit le format des messages MQTT et les exigences relatives aux charges utiles pour contrôler à distance les politiques de puissance des appareils du réseau du SmartgridOne Controller.

Rubrique MQTT

La rubrique MQTT utilisée pour l'envoi des commandes est structurée 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 sous forme de charges utiles JSON. La structure de la charge utile est conçue pour spécifier différentes politiques de gestion de l'énergie et valeurs de consigne pour les composants du réseau électrique intelligent. Voici un aperçu de la charge utile avec une description détaillée des champs :

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

Description des champs

• extraTags (Object) :
  • nodeId (String) : Identifiant unique du nœud au sein du réseau du SmartgridOne Controller. Il correspond à votre numéro de série, suivi de « _site_0 » pour la plupart des appareils SmartgridOne Controller.
• time (Integer) : Horodatage Unix en secondes indiquant l'heure d'envoi du message.
• fields (Object) :
  • <Component>_policy (String) : Type de politique du composant. Ce champ est facultatif ; s'il n'est pas spécifié, le système utilise la configuration par défaut du SmartgridOne Controller.
  • <Component>_power_setpoint_w (Float) : Valeur de consigne de puissance souhaitée en watts pour le composant. Ce champ est facultatif et pertinent uniquement si une politique correspondante est spécifiée.

Composants et politiques

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

• solar_policy et solar_power_setpoint_w :

  • Contrôle la politique et la valeur de consigne de production d'énergie solaire. Politiques prises en charge :
    • Policy setpoint : définit 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 production en watts.
    • Policy feed-in-restriction : produit à pleine puissance, en respectant les limites actuelles du réseau.
    • Policy cost : active la minimisation des coûts selon les prix du lendemain (marché EPEX Spot) pour la production solaire. Lorsque les prix d'injection sont négatifs, la production est limitée à la consommation propre. Lorsque les prix de prélèvement et d'injection sont tous deux négatifs, toutes les installations solaires sont arrêtées. Le champ solar_power_setpoint_w est ignoré.
    • Policy off : désactive toute interaction avec les actifs solaires. Avertissement : les limites ne sont pas surveillé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 ainsi que le taux de décharge ou de charge.
    • Policy setpoint : définit la puissance totale de charge (valeur de consigne positive) ou de décharge (valeur de consigne négative) pour le groupe de batteries. Lorsque plusieurs batteries sont connectées, la valeur de consigne est répartie selon les puissances de charge/décharge disponibles afin de solliciter les batteries de manière égale. Le champ storage_power_setpoint_w est défini sur la puissance souhaitée de la batterie.
    • Policy peak-shaving-only : active l'optimisation d'écrêtement des pointes sur la batterie. Cette politique doit être combinée à quatre paramètres d'écrêtement au niveau du site.
    • Policy cost : active l'optimisation des coûts selon les prix du lendemain (marché EPEX Spot) sur les batteries, en les chargeant pendant les heures bon marché et en utilisant l'énergie pendant les heures coûteuses. Le champ storage_power_setpoint_w est ignoré.
    • Policy self-consumption : active un algorithme simple d'autoconsommation sur les batteries. La production solaire excédentaire est stockée dans la batterie pendant la journée et, lorsque le soleil est couché, l'énergie est prélevée de la batterie. Le champ storage_power_setpoint_w est ignoré.
    • Policy off : désactive toute interaction avec les actifs des batteries. Avertissement : les limites ne sont pas surveillées dans ce mode. Le champ storage_power_setpoint_w est ignoré.

• heat_pump_policy :

  • Active ou désactive les systèmes de pompe à chaleur. Les durées minimale et maximale d'activation sont toujours respectées.
    • Policy cost : active l'optimisation des coûts selon les prix du lendemain (marché EPEX Spot) sur les pompes à chaleur. L'algorithme local de tarification dynamique détermine les meilleures périodes d'activation.
    • Policy self-consumption : active les pompes à chaleur lorsqu'une production solaire excédentaire est disponible.
    • Policy power_off : éteint les pompes à chaleur.
    • Policy power_on : allume les pompes à chaleur.

• switched_load_policy :

  • Active ou désactive les systèmes commandés par relais. Il peut s'agir du relais intégré ou de relais connectés au réseau.
    • Policy cost : active l'optimisation des coûts selon les prix du lendemain (marché EPEX Spot) sur le relais.
    • Policy self-consumption : active le relais lorsqu'une production solaire excédentaire est disponible.
    • Policy power_off
    • Policy power_on

• variable_power_load_policy et variable_power_load_power_setpoint_w :

  • Gère la politique et la valeur de consigne de consommation électrique des véhicules électriques.
    • Policy setpoint : définit la puissance totale de charge du groupe de véhicules électriques. Le champ variable_power_load_power_setpoint_w est défini sur la puissance de charge souhaitée.
    • Policy cost : active l'optimisation des coûts selon les prix du lendemain (marché EPEX Spot) sur les batteries, en les chargeant pendant les heures bon marché. Le champ variable_power_load_power_setpoint_w est ignoré.
    • Policy self-consumption : active la charge lorsqu'une production solaire excédentaire est disponible. Le champ variable_power_load_power_setpoint_w est ignoré.
    • Policy off : désactive toute interaction avec les actifs des véhicules électriques. Le champ variable_power_load_power_setpoint_w est ignoré.

Limites de puissance

Au lieu de définir des stratégies de contrôle et des valeurs de consigne, il est également possible de définir des limites de puissance pour les appareils de stockage et les appareils solaires.

Par exemple :

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "{prefix}_maxChargePower_W": <Max Charge Power W>,
        "{prefix}_maxDischargePower_W": <Max Discharge Power W>,
        "{prefix}_maxProductionPower_W": <Max Production Power W>,
    }
}

où prefix correspond à storage, solar ou à l'nodeID de l'appareil concerné.

Contrôle du site

Le site peut être contrôlé séparément. Les commandes de site suivantes peuvent être envoyées au contrôleur :

• default ou fallback Supprime toutes les commandes de site actives
• export Définit la limite d'exportation du site
• import Définit la limite d'importation du site
• setpoint Une valeur de consigne du site peut varier jusqu'à 5 % dans les deux directions
• setpoint_A Pas encore implémenté

Les variables suivantes sont des paramètres d'écrêtement des pointes et ne seront appliquées que lorsque la stratégie de la batterie est définie sur l'écrêtement des pointes.

• startChargeBelow_W
• stopChargeAbove_W
• startDischargeAbove_W
• stopDischargeBelow_W

Une valeur de consigne du site n'est PAS compatible avec une limite d'importation/exportation.

Par exemple :

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "<Policy Type>",
        "<Component Power Setpoint>": <Setpoint in watts>,
        "site_export": <Export Limit W>,
        "site_import": <Import Limit W>,
        "site_setpoint": <Setpoint W>,
        "site_startChargeBelow_W": <Value_W>
    }
}

Contrôle des appareils

Il est également possible de contrôler des appareils spécifiques plutôt que des groupes d'appareils en fonction de leur type. Le message est structuré de manière identique :

• nodeId_policy et nodeId_power_setpoint_w

Comportement de repli

Pour chaque composant, si _policy et _power_setpoint_w ne sont pas spécifiés, le système utilise automatiquement la politique de repli 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 aucune instruction spécifique n'est fournie.

Si aucune commande n'est envoyée, après 60 secondes (ou après le délai d'expiration configuré), les politiques par défaut des actifs sont réactivées.

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

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

Commande de repli

Une commande de repli annulera la commande existante immédiatement et le SmartgridOne Controller reprendra le contrôle de l'installation. La politique exécutée dépend des paramètres définis dans les Paramètres du SmartgridOne Controller.

Cette commande peut également être utilisée lorsqu'un signal de contrôle secondaire, tel qu'une planification, sert de solution de repli.

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 recueillir des informations sur le site. Elle n'annulera pas la commande actuelle.

La commande vide est structurée comme suit :

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

Exemple de charge utile

Voici un exemple de charge utile permettant de définir différentes politiques et valeurs 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 réglée pour produire jusqu'à 5 000 watts, tandis que le système de stockage d'énergie est configuré pour charger ou décharger à un rythme de 5 000 watts, selon le signe de la valeur de consigne. Si solar_policy ou storage_policy était omis, l'appareil concerné reviendrait aux paramètres par défaut déterminés par le SmartgridOne Controller.

Documentation MQTT pour la réception des retours

Cette section présente la structure et le contenu des messages de retour envoyés par le SmartgridOne Controller via MQTT. Ces messages sont publiés sur la rubrique standard1/outbound/remoteControlMetrics/feedback/<Controller SN> après le traitement d'une commande.

Rubrique de retour MQTT

La rubrique MQTT de retour est structurée 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

Les messages de retour sont formatés sous forme de charges utiles JSON. Ces charges utiles fournissent des informations détaillées sur l'état du système après l'application des commandes de valeur de consigne, en tenant compte des limites du réseau et des appareils. Vous trouverez ci-dessous la structure de la charge utile de retour ainsi que la description de ses champs :

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Grid Active Power in Watts>,
                "today_imported_energy_Wh": <Grid Imported Energy in Watt-hours>,
                "today_exported_energy_Wh": <Grid Exported Energy in Watt-hours>,
                "import_limit_W": <Grid Import Limit in Watts>,
                "export_limit_W": <Grid Export Limit in Watts>,
            },
            "storage": {
                "energy_stored_Wh": <Energy Stored in Watt-hours>,
                "energy_capacity_Wh": <Total Energy Capacity in Watt-hours>,
                "mean_soc_perc": <Mean State of Charge Percentage>,
                "active_power_W": <Active Power in Watts>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "executed_policy": <Policy Executed by the Controller>,
                "max_charge_power_W": <Maximum Charge Power in Watts>,
                "max_discharge_power_W": <Maximum Discharge Power in Watts>,
                "today_charged_Wh": <Energy Charged Today in Watt-hours>,
                "today_discharged_Wh": <Energy Discharged Today in Watt-hours>,
                "realised_charge_power_W": <Adapted maximum charge power>,
                "realised_discharge_power_W": <Adapted maximum discharge power>,
                "constraint_ph0_label": <Constraint reason for limiting power setpoint>,
                "errorCodes": <Error status messages per device>,
                "nr_devices": <Number of Controlled Storage Devices Installed>
            },
            "solar": {
                "active_power_W": <Solar Active Power in Watts>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "executed_policy": <Policy Executed by the Controller>,
                "capacity_W": <Solar Capacity in Watts>,
                "today_energy_Wh": <Energy Produced Today in Watt-hours>,
                "constraint_ph0_label": <Constraint reason for limiting power setpoint>,
                "errorCodes": <Error status messages per device>,
                "nr_devices": <Number of Controlled Solar Devices Installed>
            },
            "heat_pump": {
                "executed_policy": <Policy Executed by the Controller>,
                "operation_modes": <Heatpump Operation Modes>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "constraint_ph0_label": <Constraint reason for limiting power setpoint>,
                "errorCodes": <Error status messages per device>,
                "nr_devices": <Number of Controlled Heat Pump Devices Installed>
            },
            "switched_load": {
                "executed_policy": <Policy Executed by the Controller>,
                "devices_on": <Number of Devices On>,
                "devices_off": <Number of Devices Off>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "constraint_ph0_label": <Constraint reason for limiting power setpoint>,
                "errorCodes": <Error status messages per device>,
                "nr_devices": <Number of Controlled Switched Load Devices Installed>  
            },
            "variable_load": {
                "active_power_W": <Power of the device in Watts>,
                "ev_charging": <How many EVs are currently charging>,
                "ev_not_charging": <How many EVs are currently unconnected>,
                "executed_policy": <Policy Executed by the Controller>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "ev_requiring_charge": <Does the EV require charge>,
                "currentL1_A": <Current of the device on phase 1 in Ampere>,
                "currentL2_A": <Current of the device on phase 2 in Ampere>,
                "currentL3_A": <Current of the device on phase 3 in Ampere>,
                "executed_current_A": <Current Setpoint Sent to Devices in Ampere>,
                "today_charged_Wh": <Energy Charged Today in Watt-hours>,
                "today_discharged_Wh": <Energy Discharged Today in Watt-hours>,
                "total_charged_Wh": <Total Energy Charged in Watt-hours>,
                "total_discharged_Wh": <Total Energy Discharged in Watt-hours>,
                "min_charge_current_A": <Minimum Charge in Ampere>,
                "max_charge_current_A": <Maximum Charge in Ampere>,
                "allow_zero_current": <Does the Charger Support Pausing>,
                "current_charging_session": {
                    "pluginTime": <The session start time>,
                    "endTime": <The session end time>,
                    "firstChargingStartTime": <The time when the vehicle first charged>,
                    "isFull": <Is the vehicle fully charged or not>,
                    "chargedEnergy_Ws": <How much energy has been charged this session>,
                    "usedPhases": <The list of phases used during charging>,
                    "historicMaxChargeCurrent_A": <The maximum current at which the vehicle was charged during the session>
                },
                "previous_charging_session": {
                    "pluginTime": <The session start time>,
                    "endTime": <The session end time>,
                    "firstChargingStartTime": <The time when the vehicle first charged>,
                    "isFull": <Is the vehicle fully charged or not>,
                    "chargedEnergy_Ws": <How much energy has been charged this session>,
                    "usedPhases": <The list of phases used during charging>,
                    "historicMaxChargeCurrent_A": <The maximum current at which the vehicle was charged during the session>
                },
                "constraint_ph0_label": <Constraint reason for limiting power setpoint>,
                "errorCodes": <Error status messages per device>,
                "nr_devices": <Number of Variable Power  Load Devices Installed>  
            }
        },
        "error": {
            <Errors occured during driver execution>
        }
        "response_code": <Response Code>
    },
    "fields": {},
    "requestTime": "<Unix Timestamp>",
    "time": "<Unix Timestamp>",
    "siteNodeId": "<Controller SN>_site_0"
}

Description des champs

• time (Integer) : Horodatage Unix indiquant l'heure d'envoi du message de retour.
• requestTime (Integer) : Horodatage Unix indiquant l'heure d'envoi du message de contrôle d'origine.
• siteNodeId (String) : nodeId du site envoyant le retour.
• fields (Object) : Objet vide
• data (Object) :
  • state (Object) :
    • vpp_id (String) : Identifiant de la centrale électrique virtuelle associée à cet appareil.
    • grid (Object) :
      • active_power_W (Float) : Représente la puissance active actuelle sur le réseau, en watts.
      • today_imported_energy_Wh (Float) : Énergie totale prélevée sur le réseau aujourd'hui, en wattheures. Remarque : « aujourd'hui » est exprimé en temps UTC.
      • today_exported_energy_Wh (Float) : Énergie totale injectée sur le réseau aujourd'hui, en wattheures. Remarque : « aujourd'hui » est exprimé en temps UTC.
      • import_limit_W (Float) : Limite d'importation du réseau en watts,
      • export_limit_W (Float) : Limite d'exportation du réseau en watts,
    • storage (Object) :
      • energy_stored_Wh (Float) : Quantité actuelle d'énergie stockée en wattheures.
      • energy_capacity_Wh (Float) : Capacité énergétique totale du système de stockage en wattheures.
      • mean_soc_perc (Float) : État de charge en pourcentage. Il s'agit de la moyenne pondérée de toutes les batteries connectées. (Lorsque plusieurs batteries sont connectées : par exemple, la batterie « a » a une capacité énergétique de 10 kWh et un état de charge de 20 % ; la batterie « b » a une capacité énergétique de 20 kWh et un état de charge de 50 %, alors mean_soc_perc vaut 40 %.)
      • active_power_W (Float) : Puissance active actuelle du système de stockage en watts, indiquant le taux de charge ou de décharge.
      • max_charge_power_W (Float) : Puissance maximale à laquelle le stockage peut être chargé.
      • max_discharge_power_W (Float) : Puissance maximale à laquelle le stockage peut être déchargé.
      • executed_power_W (Float) : Somme de la puissance totale demandée pour charger ou décharger les actifs de stockage, envoyée par notre algorithme de contrôle. Applicable uniquement si la politique « follow_setpoint » est active.
      • executed_policy (Str) : Politiques appliquées aux éléments contrôlables.
      • today_charged_Wh (Float) : Énergie totale fournie aujourd'hui aux actifs de batteries contrôlables. Remarque : « aujourd'hui » est exprimé en temps UTC.
      • today_discharged_Wh (Float) : Énergie totale déchargée aujourd'hui par les actifs de batteries contrôlables. Remarque : « aujourd'hui » est exprimé en temps UTC.
      • realised_charge_power_W (Float) : Puissance maximale de charge adaptée, calculée à partir des réponses des appareils,
      • realised_discharge_power_W (Float) : Puissance maximale de décharge adaptée, calculée à partir des réponses des appareils,
      • constraint_ph0_label (List[string]) : Raisons pour lesquelles les valeurs de consigne externes ont été limitées.
      • errorCodes (Dict[str, Dict]) : Codes d'erreur reçus des appareils.
      • nr_devices (Int) : Nombre d'actifs de batteries contrôlables.
    • solar (Object) :
      • active_power_W (Float) : Puissance active actuelle produite par les panneaux solaires, en watts.
      • capacity_W (Float) : Capacité totale du système de production solaire, en watts.
      • executed_power_W (Float) : Somme de la puissance totale demandée aux actifs solaires, envoyée par notre algorithme de contrôle. Applicable uniquement si la politique « follow_setpoint » est active.
      • executed_policy (Str) : Politiques appliquées aux éléments contrôlables.
      • today_energy_Wh (Float) : Énergie totale produite aujourd'hui par les actifs solaires contrôlables. Remarque : « aujourd'hui » est exprimé en temps UTC.
      • constraint_ph0_label (List[string]) : Raisons pour lesquelles les valeurs de consigne externes ont été limitées.
      • errorCodes (Dict[str, Dict]) : Codes d'erreur reçus des appareils.
      • nr_devices (Int) : Nombre d'actifs solaires contrôlables.
    • heat_pump (Object) :
      • executed_policy (Str) : Politiques appliquées aux éléments contrôlables.
      • operation_modes (Str) : Mode de la pompe à chaleur (mode blocage, mode boost, mode de contrôle autonome).
      • executed_power_W (Float) : Puissance attendue actuellement utilisée.
      • errorCodes (Dict[str, Dict]) : Codes d'erreur reçus des appareils.
      • constraint_ph0_label (List[string]) : Raisons pour lesquelles les valeurs de consigne externes ont été limitées.
      • nr_devices (Int) : Nombre de pompes à chaleur contrôlables.
    • switched_load (Object) :
      • executed_policy (Str) : Politiques appliquées aux éléments contrôlables.
      • devices_on (Int) : Nombre d'appareils activés.
      • devices_off (Int) : Nombre d'appareils désactivés.
      • executed_power_W (Float) : Puissance actuellement utilisée, si disponible.
      • constraint_ph0_label (List[string]) : Raisons pour lesquelles les valeurs de consigne externes ont été limitées.
      • errorCodes (Dict[str, Dict]) : Codes d'erreur reçus des appareils.
      • nr_devices (Int) : Nombre de charges commutées contrôlables.
    • variable_load (Object) :
      • active_power_W (Float) : Représente la puissance active actuelle sur le réseau, en watts.
      • ev_charging (Int) : Nombre de véhicules électriques actuellement connectés et en charge.
      • ev_not_charging (Int) : Nombre de véhicules électriques non connectés.
      • executed_policy (Str) : Politiques appliquées aux éléments contrôlables,
      • executed_power_W (Float) : Somme de la puissance totale demandée aux actifs, envoyée par notre algorithme de contrôle.
      • ev_requiring_charge (Bool) : Indique si le véhicule électrique doit être chargé (si une voiture est connectée).
      • currentL1_A (Float) : Courant de l'appareil sur la phase 1, en ampères.
      • currentL2_A (Float) : Courant de l'appareil sur la phase 2, en ampères.
      • currentL3_A (Float) : Courant de l'appareil sur la phase 3, en ampères.
      • executed_current_A (Float) : Somme du courant total demandé aux actifs, envoyée par notre algorithme de contrôle.
      • today_charged_Wh (Float) : Énergie fournie aujourd'hui aux actifs chargeurs de véhicules électriques. Remarque : « aujourd'hui » est exprimé en temps UTC.
      • today_discharged_Wh (Float) : Énergie fournie aujourd'hui aux actifs chargeurs de véhicules électriques. Remarque : « aujourd'hui » est exprimé en temps UTC.
      • total_charged_Wh (Float) : Énergie totale fournie aux actifs chargeurs de véhicules électriques.
      • total_discharged_Wh (Float) : Énergie totale fournie aux actifs chargeurs de véhicules électriques.
      • min_charge_current_A (Float) : Courant minimal auquel le véhicule électrique peut être chargé.
      • max_charge_current_A (Float) : Courant maximal auquel le véhicule électrique peut être chargé.
      • allow_zero_current (Bool) : Indique si le chargeur du véhicule électrique autorise la mise en pause.
      • current_charging_sessions (Dict) :
        • pluginTime (Date) : Heure de début de la session.
        • endTime (Date) : Heure de fin de la session.
        • firstChargingStartTime (Date) : Heure à laquelle le véhicule a été chargé pour la première fois.
        • isFull (Bool) : Indique si le véhicule est complètement chargé.
        • chargedEnergy_Ws (Float) : Quantité d'énergie chargée pendant cette session.
        • usedPhases (List[str]) : Liste des phases utilisées pendant la charge.
        • historicMaxChargeCurrent_A (float) : Courant maximal auquel le véhicule a été chargé pendant la session.
      • constraint_ph0_label (List[string]) : Raisons pour lesquelles les valeurs de consigne externes ont été limitées.
      • errorCodes (Dict[str, Dict]) : Codes d'erreur reçus des appareils.
      • nr_devices (Int) : Nombre de charges commutées contrôlables.
    • nodeId (Object) :
      • Si un nodeId est inclus dans la commande, le retour contiendra l'état correspondant de l'appareil.
  • response_code (Int) :
    • Indique le statut de l'opération. Un response_code égal à 0 signifie généralement que l'opération a réussi ; les autres valeurs peuvent indiquer différents types d'erreurs ou d'informations d'état (qui doivent être détaillés dans une référence distincte).

Libellés des contraintes de stockage

Les valeurs de consigne envoyées par un signal externe peuvent être limitées en interne par l'EMS. Le tableau ci-dessous présente un aperçu des contraintes possibles pour le champ de retour constraint_ph0_label.

Codes d'erreur MQTT

Les codes d'erreur sont regroupés par plages indiquant la catégorie générale du problème :

Les codes d'erreur individuels sont répertoriés ci-dessous.

Erreurs de connexion (200)

Problèmes de connexion entre l'EMS et l'appareil.

Erreurs de réponse (300)

L'appareil est connecté, mais ses réponses ne sont pas valides.

Erreurs de contrôle (600)

Erreurs de mesure et de point de consigne (1000)

Versions MQTT prises en charge et comportement concernant les rubriques non autorisées

Lors de l'utilisation de MQTT, il est important de tenir compte des différences de spécifications entre les versions 3.1, 3.1.1 et 5.0, notamment en ce qui concerne le comportement du broker lorsque les clients publient sur des rubriques non autorisées.

Selon la spécification MQTT 3.1.1 (voir la spécification OASIS MQTT 3.1.1, section MQTT-3.3.5-2), un broker doit interrompre la connexion dès qu'un client envoie une publication (PUBLISH) vers une rubrique pour laquelle il ne dispose pas des autorisations nécessaires. Ce comportement peut entraîner des déconnexions inattendues pour les clients qui tentent de publier sur des rubriques mal configurées ou non autorisées.

Dans MQTT 3.1, cette exigence n'est pas présente. Lorsqu'un client publie sur une rubrique non autorisée avec cette version, le broker ignore généralement le message (suppression silencieuse) sans interrompre la connexion. Dans certains cas, MQTT 3.1 est donc plus adapté lorsque la robustesse face aux erreurs de configuration ou aux permissions temporairement manquantes est plus importante qu'une application stricte des exigences de sécurité.

Bien que MQTT 5.0 introduise la possibilité d'utiliser des codes de raison (tels que PUBACK avec une raison de refus), cela nécessite une prise en charge à la fois du côté du client et du serveur. La migration vers MQTT 5.0 implique donc un effort d'implémentation supplémentaire.

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 rubriques non autorisées, le broker interrompra brusquement la session. Cela peut entraîner une instabilité, une perte de connectivité ou une charge accrue en raison de tentatives de reconnexion répétées.

Approche recommandée : Pour les systèmes dans lesquels les clients peuvent tenter (temporairement) de publier sur des rubriques non autorisées, ou lorsque la gestion des erreurs n'est pas strictement implémentée, nous recommandons d'utiliser MQTT 3.1. Cela garantit des connexions plus stables et évite les déconnexions involontaires pendant l'exécution.