Codes d'état des onduleurs

Chaque onduleur signale un état de fonctionnement le concernant — connecté au réseau, en veille, puissance limitée, défaut, et ainsi de suite — dans le vocabulaire propre à son constructeur. Mirox enregistre désormais cet état pour chaque onduleur dont il collecte les données, le décode par constructeur dans votre langue et l'affiche à côté des états des composants de la plateforme. Vous obtenez ce que l'appareil dit lui-même de son état, sans ouvrir le portail du constructeur ni vous déplacer sur le site.

Ce qui est enregistré

• Le code constructeur brut, par onduleur, à chaque cycle d'interrogation (généralement une fois par minute) — stocké comme série temporelle à part entière à côté des mesures de l'onduleur, de sorte qu'un état peut être consulté pour n'importe quel instant passé et que chaque changement est consigné.
• Ce que dit l'appareil, pas un verdict de Mirox. Le code d'état est ce que l'onduleur dit de lui-même. Il est distinct des états des composants que le Jumeau Numérique déduit de la production mesurée, ainsi que des événements de santé que la plateforme ouvre sur la base de ses propres indices. Affichez-les côte à côte ; ils répondent à des questions différentes.
• L'absence d'état est une lacune, jamais un code. Lorsqu'un onduleur ne transmet aucun état — le logger ne parvient pas à le joindre, ou l'appareil signale « non disponible » — rien n'est enregistré pour cet instant. La plateforme ne comble jamais la lacune par un état de son cru.
• La signification est celle du constructeur. Un même nombre signifie des choses différentes selon les constructeurs (512 chez Huawei signifie Connecté au réseau, un 512 chez SMA est tout autre chose). Mirox stocke donc le constructeur à côté de chaque relevé et décode avec la table de ce constructeur.

À côté du mot du constructeur, Mirox enregistre aussi, pour chaque onduleur, un état de fonctionnement standard traduit depuis le code du constructeur : en production, en production limitée — par le gestionnaire de réseau ou une consigne, autolimitation (l'onduleur se bride lui-même pour se protéger), au repos (nuit, tests de démarrage, attente), arrêté sur commande, arrêté par une protection, défaut, injoignable ou inconnu. La même situation se lit ainsi de la même façon chez tous les constructeurs, et un parc équipé de quatre marques se parcourt d'un seul regard. Le code brut reste visible à côté, et un code qu'aucune table de décodage ne contient encore s'affiche comme inconnu avec son nombre.

Où vous le voyez

Dans le tableau Analyse → Onduleurs d'une centrale et sur Composants → Onduleurs, la colonne Code d'état affiche le texte d'état décodé avec le code brut en dessous :

• le texte est ce que lit un exploitant, dans la langue de l'interface ;
• le code brut est ce dont ont besoin un ticket de support ou le manuel du constructeur ;
• un tiret signifie que l'onduleur n'a transmis aucun état récemment ;
• Code inconnu signifie que l'onduleur a rapporté un nombre que la table de décodage ne contient pas encore — le nombre reste visible et aucune signification n'est devinée pour lui (voir Quand un code est inconnu).

La colonne peut être triée, afin que les onduleurs qui ne sont pas dans leur état de fonctionnement normal remontent en tête. Le relevé provient uniquement des derniers cycles d'interrogation ; un état vieux de plusieurs heures n'est pas présenté comme s'il était en direct.

Constructeurs pris en charge

Chaque table de décodage est fournie dans les six langues de l'interface (anglais, allemand, français, espagnol, italien, portugais) et est maintenue de manière centralisée, de sorte qu'un état est formulé de la même façon dans l'interface, dans les notifications et dans l'assistant IA.

Exemples

Quand un code est inconnu

Les constructeurs ajoutent des états au fil des nouveaux firmwares. Lorsqu'un onduleur rapporte un nombre que la table ne contient pas encore, Mirox affiche Code inconnu avec le nombre, et conserve le relevé — celui-ci n'est jamais supprimé ni remplacé par une étiquette devinée. Les tables de décodage sont enrichies à mesure que de nouveaux codes apparaissent sur le terrain ; si vous rencontrez un code inconnu qui vous importe, transmettez le nombre, le constructeur et le modèle d'onduleur au support (ou ouvrez un ticket) et il sera ajouté pour tout le monde.

Événements d'alarme actifs

Au-delà de l'état de fonctionnement, Mirox porte les alarmes et avertissements qu'un appareil signale sur lui-même — ceux d'un onduleur, comme ceux d'un convertisseur de batterie ou d'un BMS de conteneur — dans les événements du parc. Chaque signalement sert deux fois, pour deux questions différentes : il est consigné exactement tel que l'appareil l'a envoyé, et il est remis à la surveillance propre à Mirox comme un indice de plus, à côté des mesures. Les codes sont décodés avec les mêmes tables par fabricant que l'état, et la formulation propre de l'appareil ainsi que sa sévérité (critique, majeure, mineure, avertissement) restent attachées à chaque entrée.

• Deux relevés, deux usages. Lorsqu'un onduleur lève une alarme sur lui-même — par exemple le 2005 Fan abnormal de Huawei —, Mirox ouvre pour cet onduleur un petit relevé d'alarme signalée par l'appareil : ouvert à l'instant où l'appareil lève le code, fermé à l'instant où il le retire, un relevé par code, portant le nombre de fois où il est revenu. La sévérité attribuée par l'appareil décide s'il se lit comme un Défaut signalé par l'onduleur ou comme un Avertissement signalé par l'onduleur (Défaut signalé par la batterie / Avertissement signalé par la batterie pour une batterie). Ces relevés sont un miroir brut de la liste active du constructeur : ils ne sont jamais confrontés à nos mesures, ils ne modifient jamais un état de santé ni un chiffre de disponibilité, et c'est le retrait par l'appareil qui les ferme.
• Le même signalement devient une entrée de la surveillance propre à Mirox. En parallèle, l'alarme est traduite dans le vocabulaire standard de Mirox et remise à la surveillance qui examine déjà les mesures de cet onduleur. Un code n'alimente qu'une seule voie, de sorte qu'un même fait n'obtient jamais deux cycles de vie : un code thermique alimente le constat de température, un code d'isolement le constat d'isolement, les codes d'arc et de courant résiduel une alarme de sécurité, un signalement disant que le logger n'atteint pas un onduleur le relevé propre à cet onduleur, Le logger n'atteint pas l'onduleur (et de là, après une heure de plein jour, un événement sans communication), et tout ce dont Mirox n'a aucune mesure propre devient un Défaut d'appareil onduleur (ou un Défaut d'appareil batterie, où restent aussi les signalements de communication d'une batterie). Événements des onduleurs expose l'aiguillage complet.
• Une intervention bleue, pas une alarme de production. Un défaut d'appareil se tient sur un onduleur qui produit toujours, et il est présenté comme tel : en bleu maintenance dans la liste d'événements, sous forme d'état Défaut d'appareil sur la page d'analyse, et compté par la clé bleue de la ligne de station à côté des quatre constats de maintenance. L'onduleur continue d'être compté comme producteur partout sur cette page.
• Un filtrage, pour qu'un simple soubresaut ne devienne jamais une alarme. La durée pendant laquelle un code doit tenir avant d'ouvrir un événement dépend de la sévérité attribuée par le constructeur lui-même : un code de classe défaut exige deux vérifications consécutives, un code de classe avertissement une seconde levée, et tout ce qui n'est pas étiqueté bascule du côté prudent de l'avertissement. Les signalements de défaut d'arc et de courant résiduel font exception en sens inverse : une Alarme de sécurité onduleur s'ouvre sur un unique signalement actif, de jour comme de nuit. Voir Événements des onduleurs pour les seuils exacts.
• Là où la parole de l'appareil confirme un constat de Mirox. Pour les deux classes que Mirox mesure aussi lui-même, le signalement de la machine est une corroboration : il renforce la série que notre propre mesure construit déjà, et il ne peut jamais bloquer un verdict propre. La parole de l'appareil confirme un constat à elle seule uniquement là où notre propre comparaison ne peut pas juger cet onduleur du tout — un parc qui ne publie aucune température d'armoire, un logger avec trop peu d'unités comparables — et même là, seulement à la sévérité défaut. Pour l'isolement, c'est aujourd'hui la seule voie vers un constat confirmé, car l'escalade sur notre propre relevé est délibérément désactivée jusqu'à ce que l'étalonnage soit refait, autour de novembre 2026. Il n'existe aucun constat de déséquilibre de phases ou de rendement atteignable depuis un signalement d'alarme : aucune liste de constructeur ne porte ces conditions.
• Un seul relevé, actualisé sur place. Si l'onduleur retire l'alarme de ventilateur le soir et la relève l'après-midi suivant, l'événement reste ouvert et son décompte passe à 2 — jamais un second événement. En l'ouvrant, on lit le raisonnement et le tableau Messages de l'appareil : chaque code avec son décompte, le mot de sévérité du constructeur et son message, ainsi qu'un marqueur actif sur les codes que l'appareil lève encore.
• La fermeture est la décision de Mirox. Un appareil qui cesse de répéter son propre défaut n'a pas été réparé : il a cessé d'en parler. Un code retiré passe donc en attente et n'en est libéré que par une vérification indépendante, par assez de journées calmes au cours desquelles la pièce défaillante a réellement été sollicitée, par un plafond de durée, ou — pour les classes qu'il a fallu aller réarmer sur place — par le retrait lui-même. Les décomptes par classe figurent dans Événements des onduleurs.
• Lorsque l'onduleur cesse de produire — ou cesse de répondre —, l'événement de production reprend le signalement. Le défaut d'appareil est fermé dans la nouvelle Panne de production onduleur, qui porte dès lors tous les codes levés par la machine ; le relevé d'accessibilité est fermé de la même façon dans un événement Onduleur sans communication. Les deux fermetures sont consignées comme escaladées, jamais comme résolues. Lorsque l'événement se ferme à son tour, un relevé successeur s'ouvre si une revendication tient toujours. Les codes sont une corroboration, jamais une cause — la reprise est décrite en entier sur la page des événements.
• Ce qui ne devient jamais un constat. Les autotests de routine et les codes qui ne décrivent que la nuit ou le crépuscule (aucune injection d'énergie, tension continue trop basse) sont consignés mais n'ouvrent jamais rien de notre part — ils sont toutefois cités dans le raisonnement d'autres constats lorsqu'ils expliquent la situation. Lorsque la plupart des onduleurs d'un parc signalent le même mot réseau en quelques minutes — une perturbation du réseau, une aube humide —, il s'agit d'une propriété du réseau, et Mirox supprime l'ouverture d'un constat par onduleur. Onduleur arrêté sur commande, Arrêt de protection onduleur et Autolimitation onduleur ne se lisent pas dans la liste d'alarmes : ils découlent de l'état de fonctionnement de l'onduleur.
• Pris en charge aujourd'hui : les onduleurs Huawei SUN2000 derrière un SmartLogger (les deux transports, la liste d'alarmes officielle complète de Huawei) ; SMA Sunny Central — les registres de défaut de la passerelle d'installation SC-COM et le journal d'événements de l'interface web classique par onduleur ; le propre journal de messages apparié du SMA Data Manager / Power Manager (appareil injoignable, en attente de consignes, appareil signalant une erreur, ainsi que quelques avis informatifs de routine) ; et la liste des défauts actifs du logger Sungrow (les codes de protection réseau de la série SG et les alarmes de ventilateur, tout autre code étant affiché dans le libellé d'origine de l'appareil jusqu'à son ajout à la table de décodage). Les contrôleurs de centrale Zebotec ne signalent qu'un état de fonctionnement et n'ont aucune liste d'alarmes : aucun événement d'alarme n'est donc produit pour eux. D'autres fabricants suivront.
• Note sur la Sunny Central classique : la lecture du journal d'événements nécessite la connexion installateur ; avec une connexion utilisateur simple, les mesures ne sont pas affectées mais les alarmes ne peuvent pas être lues.
• Note sur le SMA Data Manager : son journal de messages ne couvre que les onduleurs effectivement surveillés par le manager — un onduleur lu directement par son propre Sunny Central signale ses alarmes par cette voie, de sorte que rien n'est signalé en double. Seule une petite part de ses plusieurs milliers d'étiquettes de messages est classée aujourd'hui ; le reste est non traduisible, ce qui signifie que ces étiquettes ouvrent un défaut d'appareil à la sévérité Erreur et rien à la sévérité Avertissement, et qu'aucun constat thermique, d'isolement ou de sécurité ne peut être atteint depuis cette famille.

Travailler avec les données

• Export de composants. L'état est disponible sous forme de métrique brute de composant comp_raw_inverter_vendor_status pour le type de composant onduleur dans l'API d'export de métriques — une valeur par onduleur et par pas de temps, le code constructeur brut.
• Séries temporelles brutes. Dans Grafana et MiroxQL, la série est powerplant_inverter_vendor_status, étiquetée avec inverter_id, inverter_vendor (la table de décodage) et inverter_model. Lisez-la avec la dernière valeur par onduleur ; ne calculez jamais la moyenne ni la somme d'un code d'état — le résultat serait un état qu'aucun appareil n'a jamais rapporté.
• Assistant IA. L'assistant IA et les outils MCP répondent aux questions sur l'état rapporté d'un onduleur et sur ses alarmes actives à partir des mêmes données et des mêmes tables de décodage.

Fonctionnalités associées

• Événements des onduleurs — tous les événements qu'un onduleur peut porter, ce qui les ouvre et comment ils se ferment
• États des composants — l'état de chaque composant établi par la plateforme sur la base d'indices mesurés
• Supervision en temps réel — les données de production en direct à côté de l'état
• Data loggers — quels loggers et familles d'onduleurs sont pris en charge
• API d'export de métriques — exporter l'état sous forme de série temporelle