Códigos de estado del inversor

Cada inversor reporta un estado operativo sobre sí mismo — conectado a la red, en espera, potencia limitada, fallo, etc. — en el vocabulario propio de su fabricante. Mirox registra ahora ese estado para cada inversor del que recopila datos, lo decodifica por fabricante a tu idioma y lo muestra junto a los estados de los componentes de la propia plataforma. Obtienes la palabra del propio dispositivo sobre su condición, sin abrir el portal del fabricante ni desplazarte a la instalación.

Qué se registra

• El código bruto del fabricante, por inversor, en cada ciclo de sondeo (normalmente una vez por minuto) — almacenado como su propia serie temporal junto a las mediciones del inversor, de modo que se puede consultar un estado para cualquier momento del pasado y cada cambio queda registrado.
• La palabra del propio dispositivo, no un veredicto de Mirox. El código de estado es lo que el inversor dice sobre sí mismo. Es independiente de los estados de los componentes que el Gemelo Digital deriva de la producción medida, y de los eventos de salud que la plataforma abre a partir de su propia evidencia. Muéstralos uno al lado del otro; responden a preguntas distintas.
• La ausencia de estado es un hueco, nunca un código. Cuando un inversor no envía ningún estado — el logger no puede alcanzarlo, o el dispositivo reporta "no disponible" — no se registra nada para ese momento. La plataforma nunca rellena el hueco con un estado propio.
• El significado es el del fabricante. El mismo número significa cosas distintas según el fabricante (el 512 de Huawei es Conectado a la red, un 512 de SMA es algo completamente distinto). Por eso Mirox almacena el fabricante junto a cada lectura y decodifica con la tabla de ese fabricante.

Junto a la palabra del fabricante, Mirox registra además un estado operativo estándar para cada inversor, traducido a partir del código del fabricante: produciendo, produciendo — con limitación del operador de red o de una consigna, autolimitación (el inversor se limita a sí mismo para protegerse), en reposo (noche, comprobaciones de arranque, espera), detenido por orden, parado por protección, fallo, inaccesible o desconocido. Así, la misma situación se lee igual en cualquier marca y un parque con cuatro fabricantes se revisa de una sola pasada. El código bruto sigue visible a su lado, y un código que ninguna tabla de decodificación contiene todavía aparece como desconocido junto con su número.

Dónde se ve

En la tabla Análisis → Inversores de un parque y en Componentes → Inversores, la columna Código de estado muestra el texto de estado decodificado con el código bruto debajo:

• el texto es lo que lee un operador, en el idioma de la interfaz;
• el código bruto es lo que necesita un ticket de soporte o el manual del fabricante;
• un guion significa que el inversor no ha enviado ningún estado recientemente;
• Código desconocido significa que el inversor reportó un número que la tabla de decodificación aún no contiene — el número sigue visible y no se adivina ningún significado para él (consulta Cuando un código es desconocido).

La columna se puede ordenar, de modo que los inversores que no están en su estado operativo normal aparecen arriba. La lectura se toma solo de los últimos ciclos de sondeo; un estado de hace horas no se muestra como si fuera en vivo.

Fabricantes compatibles

Cada tabla de decodificación incluye los seis idiomas de la interfaz (inglés, alemán, francés, español, italiano y portugués) y se mantiene de forma centralizada, de modo que un estado se redacta igual en la interfaz, en las notificaciones y en el asistente de IA.

Ejemplos

Cuando un código es desconocido

Los fabricantes añaden estados con cada nuevo firmware. Cuando un inversor reporta un número que la tabla aún no contiene, Mirox muestra Código desconocido junto con el número y conserva la lectura — nunca se descarta ni se sustituye por una etiqueta adivinada. Las tablas de decodificación se amplían a medida que aparecen nuevos códigos en campo; si ves un código desconocido que te resulta relevante, envía el número, el fabricante y el modelo del inversor al soporte (o abre un ticket) y se añadirá para todos.

Eventos de alarma activos

Más allá del estado operativo, Mirox lleva las alarmas y advertencias que un equipo comunica sobre sí mismo — las de un inversor, y también las de un convertidor de batería o de un BMS de contenedor — a los eventos del parque. Cada comunicación se usa dos veces, para dos preguntas distintas: se registra tal cual la envió el equipo, y se entrega a la monitorización propia de Mirox como una evidencia más junto a las mediciones. Los códigos se descodifican con las mismas tablas por fabricante que el estado, y el texto original del equipo y su severidad (crítica, mayor, menor, advertencia) se conservan en cada entrada.

• Dos registros, dos propósitos. Cuando un inversor levanta una alarma sobre sí mismo — por ejemplo el 2005 Fan abnormal de Huawei —, Mirox abre para ese inversor un pequeño registro de alarma comunicada por el equipo: abierto en el momento en que el equipo levanta el código, cerrado en el momento en que lo retira, un registro por código, con la cuenta de cuántas veces volvió. La severidad que asignó el equipo decide si se lee como Fallo notificado por el inversor o como Aviso notificado por el inversor (Fallo notificado por la batería / Aviso notificado por la batería en el caso de una batería). Estos registros son un espejo simple de la lista activa del propio fabricante: nunca se contrastan con nuestras mediciones, nunca cambian un estado de salud ni una cifra de disponibilidad, y lo que los cierra es la retirada del equipo.
• La misma comunicación se convierte en entrada de la monitorización propia de Mirox. En paralelo, la alarma se traduce al vocabulario estándar de Mirox y se entrega a la monitorización que ya vigila las mediciones de ese inversor. Un código alimenta exactamente una línea, así que un mismo hecho nunca tiene dos ciclos de vida — un código térmico alimenta el hallazgo de temperatura, uno de aislamiento el hallazgo de aislamiento, los de arco eléctrico y corriente residual una alarma de seguridad, un aviso de que el logger no alcanza a un inversor el registro propio de ese inversor, El logger no alcanza al inversor (y desde ahí, tras una hora de luz, un evento sin comunicación), y todo aquello para lo que Mirox no tiene medición propia se convierte en un Fallo de dispositivo del inversor (o un Fallo de dispositivo de la batería, donde también se quedan los avisos de comunicación de una batería). Eventos del inversor recoge el encaminamiento completo.
• Una tarea de mantenimiento azul, no una alarma de producción. Un fallo de dispositivo se asienta sobre un inversor que sigue produciendo, y así se muestra: en azul de mantenimiento en la lista de eventos, como estado Fallo de dispositivo en la página de análisis y contabilizado por la llave inglesa azul de la fila de la estación, junto a las cuatro tareas de mantenimiento. El inversor sigue contando como productor en toda esa página.
• Un filtro, para que un episodio aislado nunca se convierta en alarma. Cuánto debe mantenerse un código antes de abrir un evento depende de la severidad que el propio fabricante le haya asignado: un código de clase fallo necesita dos comprobaciones consecutivas, uno de clase advertencia un segundo levantamiento, y todo lo que no esté etiquetado cae del lado prudente de la advertencia. Los avisos de arco eléctrico y de corriente residual son la excepción en el otro sentido: una Alarma de seguridad del inversor se abre con un único aviso activo, de día o de noche. Consulta Eventos del inversor para los umbrales exactos.
• Dónde la palabra del equipo confirma un hallazgo de Mirox. En las dos clases que Mirox también mide por sí misma, la comunicación de la máquina es corroboración: refuerza la racha que nuestra propia medición ya está construyendo, y nunca puede impedir un veredicto limpio. La palabra del equipo confirma un hallazgo por sí sola solo allí donde nuestra propia comparación no puede juzgar en absoluto a ese inversor — un parque que no publica temperatura de armario, un logger con demasiados pocos equipos comparables —, y aun allí únicamente con severidad de fallo. Para el aislamiento es hoy la única vía a un hallazgo confirmado, porque la escalada basada en nuestra propia lectura está deliberadamente desactivada hasta que se rehaga la calibración, alrededor de noviembre de 2026. No hay ninguna vía desde una alarma comunicada a un hallazgo de desequilibrio de fases o de rendimiento: ninguna lista de fabricante contiene esas condiciones.
• Un solo registro, actualizado en su sitio. Si el inversor retira la alarma de ventilador por la noche y la vuelve a levantar la tarde siguiente, el evento sigue abierto y su cuenta pasa a 2 — nunca hay un segundo evento. Al abrirlo se ven el razonamiento y la tabla de Avisos del equipo: cada código con su cuenta, la palabra de gravedad del fabricante y su mensaje, y una etiqueta activo en los códigos que el equipo sigue levantando.
• El cierre lo decide Mirox. Un equipo que deja de repetir su propio fallo no está reparado — ha dejado de hablar de ello. Por eso un código retirado queda en espera y solo lo libera una comprobación independiente, un número suficiente de días tranquilos en los que la pieza averiada se haya usado realmente, un techo de cuánto tiempo puede mantenerse abierto o — en las clases a las que alguien tuvo que acercarse a reiniciar — la propia retirada. Los recuentos por clase están en Eventos del inversor.
• Cuando el inversor deja de producir — o deja de responder —, el evento de producción se hace cargo de la comunicación. El fallo de dispositivo se cierra dentro del nuevo Fallo de producción del inversor, que a partir de ahí lleva todos los códigos que levanta la máquina; el registro de alcanzabilidad se cierra del mismo modo dentro de un evento Inversor sin comunicación. Ambos cierres se anotan como escalados, nunca como resueltos. Cuando el evento se cierra a su vez, se abre un registro sucesor si sigue en pie alguna reclamación. Los códigos son corroboración, nunca una causa — el traspaso se describe por completo en la página de eventos.
• Lo que nunca llega a ser un hallazgo. Las autocomprobaciones rutinarias y los códigos que solo describen la noche o el crepúsculo (sin inyección de energía, tensión de continua demasiado baja) se registran, pero nunca abren nada nuestro — aunque sí se citan en el razonamiento de otros hallazgos cuando explican la situación. Cuando la mayoría de los inversores de un parque comunican la misma palabra de red en pocos minutos — una perturbación de red, un amanecer húmedo —, eso es una propiedad de la red, y Mirox suprime la apertura de un hallazgo por inversor. Inversor detenido por orden, Parada de protección del inversor y Autolimitación del inversor no se leen de la lista de alarmas: nacen del estado operativo del inversor.
• Compatible hoy: inversores Huawei SUN2000 tras un SmartLogger (ambos transportes, la lista de alarmas oficial completa de Huawei); SMA Sunny Central — los registros de fallo de la pasarela de planta SC-COM y el registro de eventos de la interfaz web clásica por inversor; el propio registro de mensajes emparejados del SMA Data Manager / Power Manager (dispositivo inalcanzable, esperando consignas, dispositivo informa de error, además de algunos avisos informativos rutinarios); y la lista de fallos activos del logger Sungrow (los códigos de protección de red de la serie SG y las alarmas de ventilador, mostrándose cualquier otro código con la redacción original del dispositivo hasta que se añada a la tabla de descodificación). Los controladores de planta Zebotec comunican solo un estado operativo y no tienen lista de alarmas, así que para ellos no se producen eventos de alarma. Seguirán más fabricantes.
• Nota sobre Sunny Central clásico: leer el registro de eventos requiere el inicio de sesión de instalador; con un usuario simple las mediciones no se ven afectadas, pero las alarmas no se pueden leer.
• Nota sobre SMA Data Manager: su registro de mensajes solo cubre los inversores que el propio manager monitoriza — un inversor leído directamente por su propio Sunny Central informa de sus alarmas por esa vía, así que nada se informa dos veces. Hoy solo está clasificada una pequeña parte de sus varios miles de etiquetas de mensaje; el resto son no traducibles, lo que significa que abren un fallo de dispositivo con nivel Error y nada con Warn, y que desde esta familia no se puede alcanzar ningún hallazgo térmico, de aislamiento ni de seguridad.

Trabajar con los datos

• Exportación de componentes. El estado está disponible como la métrica bruta de componente comp_raw_inverter_vendor_status para el tipo de componente inversor en la API de exportación de métricas — un valor por inversor y paso de tiempo, el código bruto del fabricante.
• Series temporales en bruto. En Grafana y MiroxQL la serie es powerplant_inverter_vendor_status, etiquetada con inverter_id, inverter_vendor (la tabla de decodificación) e inverter_model. Léela con el último valor por inversor; nunca promedies ni sumes un código de estado — el resultado sería un estado que ningún dispositivo reportó jamás.
• Asistente de IA. El asistente de IA y las herramientas MCP responden a preguntas sobre el estado reportado de un inversor y sus alarmas activas a partir de los mismos datos y las mismas tablas de decodificación.

Funciones relacionadas

• Eventos del inversor — todos los eventos que puede llevar un inversor, qué los abre y cómo se cierran
• Estados de los componentes — el estado propio de la plataforma, basado en evidencia, de cada componente
• Monitorización en tiempo real — datos de producción en vivo junto al estado
• Data loggers — qué loggers y familias de inversores son compatibles
• API de exportación de métricas — exportar el estado como serie temporal