Saltar al contenido principal
CloudStudio

v1.9.4 — Octubre 2026

23 de octubre de 2026

Esta versión acompaña los despliegues grandes de punta a punta: cada dispositivo tiene un ciclo de vida (alta, instalación, baja), la puesta en marcha deja constancia y hay reportes para seguir el ritmo de instalación. Las alarmas suman notas con fotos y un PDF con su historia, y la plataforma ahora verifica que las órdenes enviadas a los equipos se cumplan. También llegan nuevas integraciones y varios cambios en la API que conviene revisar.

Nuevas funcionalidades

Ciclo de vida del dispositivo

Cada dispositivo tiene un estado de despliegue, independiente del modo mantenimiento.

  • Estados: Registered (dado de alta), Installed (montado en el sitio) y Retired (dado de baja, conserva el historial). "Comisionado" y "en servicio" no se marcan a mano: se calculan a partir de la prueba de puesta en marcha y de si el equipo está comunicando.
  • Acceso: Manager → Devices → Devices → dispositivo → tab Details → sección Lifecycle, con Mark as installed y Retire this device. Deshacer una instalación exige un motivo.
  • Historial: la tabla Lifecycle history muestra fecha, transición, quién la hizo y el motivo.
  • Cambio masivo: en el listado de dispositivos, con varios seleccionados, el botón Mark lifecycle cambia el estado de todos a la vez.
  • Depósitos: en Manager → Facilities → Facility types, la casilla Stock location (depot) marca los lugares de stock. Sus equipos no cuentan en las cifras de despliegue aunque transmitan.
  • Los dispositivos que ya reportaban desde un sitio de campo quedan como Installed.

Seguimiento del despliegue: progreso y ritmo de comisionado

Dos reportes nuevos en Manager para seguir un despliegue.

  • Commissioning progress: instalados contra objetivo, en servicio contra instalados y sitios comisionados por técnico y por semana. Parámetros: rango de fechas, objetivo y horas para considerar que un equipo está comunicando.
  • Commissioning throughput: ritmo de comisionado por día, semana y técnico, con proyección a una fecha objetivo. Puede contar solo días laborables (opción activada por defecto). Los técnicos aparecen anonimizados por defecto.
  • Acceso: Manager → General Maintenance → reportes.

Confirmación en sitio de la puesta en marcha

La prueba de puesta en marcha suma la confirmación del técnico y un historial.

  • Acceso: Manager → Devices → Devices → dispositivo → tab Details → sección Commissioning test.
  • Confirm on site: el técnico confirma que la salida actuó de verdad, ya que la plataforma solo ve el acuse del equipo.
  • Commissioning records: tabla con fecha, quién hizo la prueba y resultado (Successful, In progress o Failed), indicando qué parte falló: comando, confirmación en sitio o notificación.

Notas, fotos y PDF del registro de cada alarma

  • Acceso: Monitor → Alarms → alarma → acciones y Event log.
  • Add note: agrega un comentario al registro sin cambiar el estado de la alarma, también en alarmas resueltas.
  • Download PDF: descarga un PDF con todas las transiciones y notas de la alarma.
  • Fotos: Add photos permite adjuntar hasta 5 fotos por nota desde la cámara del teléfono (JPEG, PNG o WebP de hasta 5 MB). Se ven como miniaturas en el registro y también en el PDF.
  • Móvil: en pantallas angostas la vista pasa a una columna.
  • Disponibilidad: requiere el ciclo de vida de alarmas. Las fotos son además un add-on. Ambos disponibles bajo activación; contactá a soporte.

Avisos de alarmas de todas las instalaciones

  • Alcance: la campanita y los avisos de Monitor informan de las alarmas de todas las facilities del cliente, no solo de la que está en pantalla.
  • Alarmas cortas: ya no se pierden las alarmas que se abren y se cierran entre dos consultas.
  • Rapidez: la consulta pasa a cada 5 segundos y se repite al volver a la pestaña.
  • Detalle: el aviso indica la facility y marca las alarmas que ya volvieron a la normalidad.
  • Equipos silenciados: ya no suenan.

Verificación de las órdenes de encendido y apagado

Cuando una acción enciende o apaga una salida, la plataforma comprueba que el equipo llegue al estado pedido.

  • Comportamiento: tras la orden se espera a que la salida informe el estado pedido. Si no llega en el tiempo máximo (180 segundos por defecto), se reintenta una vez.
  • Alarma: si después del reintento la salida sigue sin responder, se abre la alarma de sistema Output did not reach the requested state, con el estado pedido, el último informado y los intentos. Se cierra sola si la salida llega tarde al estado o si se confirma una orden posterior.
  • Alcance: órdenes del motor de acciones sobre salidas que ya informaron su estado alguna vez. Las órdenes manuales, por API o por script no se verifican.

Reintento de downlinks en ThingPark

  • Reintento: si ThingPark informa que no pudo transmitir un comando, se reenvía hasta 3 veces.
  • Alarma: agotados los reintentos se abre la alarma de sistema Command not transmitted by the network, que se cierra sola cuando la red vuelve a transmitir a ese endpoint.
  • Orden: ya no se envían dos comandos seguidos al mismo equipo; se espera la respuesta de la red.

Monitoreo de gateways propios con The Things Stack

El monitoreo de gateways suma la conexión directa con The Things Stack para los gateways propios.

  • Own / Observed: la columna Type distingue los gateways propios de los que solo se observan por el tráfico.
  • Conexión: en Manager → Devices → LoRaWAN Gateways → gateway → sección Network server connection se cargan el ID del gateway en el network server, el servidor y una API key (se guarda cifrada), con el botón Check now. La plataforma consulta el estado cada 5 minutos, haya o no tráfico de sensores.
  • En Monitor: Monitor → LoRaWAN Gateways muestra por cada gateway propio el estado en el network server, desde cuándo está conectado o desconectado, últimos uplink y downlink, tráfico de 24 horas con gráfico por hora, latencia y protocolo.
  • Señal y radio: RSSI y SNR de los sensores propios y de todo lo que escucha, lista de dispositivos escuchados, paquetes recibidos y reenviados. Si el gateway está conectado pero no recibe uplinks, se avisa y se sugiere qué revisar.
  • Disponibilidad: forma parte del monitoreo de gateways, apagado por defecto. Disponible bajo activación por cliente; contactá a soporte.

Inventario de gateways LORIOT

  • Inventario: con la clave nueva Network API key (gateway inventory) se lee el inventario completo de gateways del network server.
  • Facility: cada gateway se asigna a la facility de los equipos que escucha o a la más cercana.
  • Ubicación estimada: se estima la ubicación de los gateways que no la declaran, marcada como Estimated.
  • Disponibilidad: forma parte del monitoreo de gateways, bajo activación.

Resumen de sitios sin señal configurable por cliente

  • Acceso: Manager → configuración del cliente → tab Alarm settings → resumen de sitios sin señal.
  • Opciones: activarlo para el cliente, días y hora de envío con zona horaria, horas sin señal para considerar un sitio mudo y cantidad de alarmas para considerar una ráfaga.
  • Destinatarios: los administradores del cliente o direcciones específicas.
  • Mientras el cliente no lo configure, se usa el valor general.

Comunicaciones con plantillas y aprobación

Permite preparar comunicaciones a partir de plantillas y pasarlas por un circuito de aprobación antes de enviarlas.

  • Preparar: en el panel de detalle del dispositivo, Prepare communication abre la plantilla con un destinatario sugerido y una vista previa.
  • Aprobar: Monitor → Communications pending approval lista las comunicaciones pendientes con su historial, para aprobarlas con comentario o rechazarlas con motivo. La aprobación se asigna por facility con un permiso propio.
  • Plantillas: Manager → Communication templates, con marcadores como {DEVICE_NAME}, {FACILITY_NAME} o {COMFORT_SUMMARY}, vista previa y aprobación obligatoria opcional.
  • Disponibilidad: apagado por defecto. Disponible bajo activación por cliente; contactá a soporte.

Seguimiento y ubicación detallada del dispositivo

  • Acceso: panel de detalle del dispositivo en Monitor.
  • Detailed location: datos de ubicación detallada del dispositivo.
  • Follow-up status: estado de seguimiento con Change status (motivo obligatorio) y Status history.
  • Histórico: se puede abrir el histórico de un solo sensor desde su panel, y la comparación de sensores suma 3, 6 y 12 meses y Compare with the previous year.

Visibilidad de reportes por cliente y reporte de confort

  • Acceso: Manager → configuración del cliente → tab Reports. Cada reporte de Monitor tiene un interruptor, con la opción de volver al valor por defecto.
  • Facility comfort summary: reporte nuevo en PDF con temperatura, humedad y CO2, confort por vivienda y comparación antes y después de cada intervención. Viene oculto por defecto y se muestra desde esa pestaña.

Nuevas opciones del mapa de dispositivos

  • Show connectivity as a ring around the pin: el pin toma el color de la severidad y un aro indica la conectividad, con leyenda.
  • Open the device map with the active facility only: el mapa abre con la facility activa, con un conmutador para ver todas.
  • Acceso: Manager → configuración del cliente → tab Maps settings. Ambas opciones vienen apagadas.
  • Mantenimiento desde el mapa: la ventana de detalle del dispositivo en el mapa de Monitor permite ponerlo en mantenimiento y devolverlo a servicio, con un permiso propio más acotado.

Capa de geometría externa en los mapas

  • Acceso: Manager → configuración del cliente → tab Maps settings → External geometry layer.
  • Configuración: URL de un GeoJSON (https), nombre de la capa y propiedad que define el color.
  • Uso: los mapas de Monitor dibujan la capa sin almacenarla, hasta 20.000 formas y 25 MB.

Mapa de calor renovado

  • Capas: el mapa de calor se puede combinar con las capas de dispositivos y de gateways, e incluye una leyenda de valores.
  • Variables: el mapa por métrica admite todas las variables, incluidas las propias del cliente (antes, solo 5 tipos).

Disparador "Value changed" en acciones

  • Acceso: Manager → Actions → acción → disparador.
  • Uso: la condición Value changed ejecuta la acción cada vez que cambia el valor, en endpoints numéricos, discretos y genéricos.
  • Las alertas no admiten esta condición.

Sonido de alarma en la app móvil

  • Alarm sound on the mobile app: las notificaciones push de alarma usan el sonido propio de la app y prioridad alta.
  • Disponibilidad: apagado por defecto. Disponible bajo activación por cliente; contactá a soporte. Requiere una versión de la app que incluya el sonido.

Integraciones nuevas

  • Davis WeatherLink: Manager → configuración del cliente → tab Integrations → Davis WeatherLink Weather Stations, con API v2 Key, API v2 Secret y Polling interval (minutes).
  • Ecowitt: permite indicar desde qué fecha importar el histórico.
  • Sensores Tekelek: el TEK811 se conecta por TCP, y los TEK733, TEK822 y TEK880 se suman al catálogo de modelos.
  • Proveedor externo programado: una integración que envía periódicamente datos del cliente a un servicio externo por https, que devuelve sus resultados por la API de uplink.

Mejoras

  • Copiloto de IA: responde en el idioma del usuario, encadena varias consultas antes de contestar, interpreta bien fechas, horas e identificadores largos, y el control de cuota tiene en cuenta también el costo. Sigue siendo un add-on bajo activación.
  • Tipo de alarma en las alertas: una alerta puede abrir alarmas de un tipo elegido en lugar del genérico, también en las plantillas de alerta.
  • Plantillas de alerta: el editor muestra las unidades de los umbrales, y el informe de aplicación explica por qué falló cada dispositivo.
  • Horarios de alertas: se indica que las horas están en la zona horaria del sitio, y los 7 días entran en una fila.
  • Detalles de alarma: las alarmas de alerta simple muestran la condición (antes, un guion).
  • Ciclo de vida de alarmas: su activación pasa a la nueva pestaña Alarm settings del cliente.
  • Errores más claros: al borrar algo con dependencias, el mensaje dice qué lo impide. Una orden a un equipo NB-IoT o Cat-M1 que todavía no se conectó indica que quedó en cola, en lugar de un tiempo agotado.
  • Comandos: al enviar un comando nuevo a un endpoint se cancelan los anteriores pendientes, con el motivo "Replaced by command N".
  • Uplinks duplicados: se descarta el reenvío de un uplink ya procesado.
  • Reintentos de notificaciones: los rechazos definitivos (buzón inexistente, teléfono inválido) se descartan en el momento en lugar de reintentarse durante 48 horas.
  • Reportes: los desplegables de parámetros siempre tienen buscador, y el parámetro de dispositivo de Endpoints data history Extended busca en el servidor.
  • Gráfico de histórico: las alarmas de severidades personalizadas se dibujan con su color y nombre.
  • Direcciones de gateway: se normalizan, y el error de dirección duplicada indica qué dispositivo la usa.
  • Freno de redisparo de acciones: se puede fijar un tiempo mínimo entre disparos de una misma acción. Viene apagado.
  • Selector de período: rotula los rangos relativos, como "Últimos 14 días".
  • Interfaz: mejor contraste en botones y textos secundarios y en el asistente de migración, y sin bordes blancos en modo oscuro.
  • Traducciones: estados de endpoint traducidos y chino en el asistente de migración y en las operaciones masivas.
  • Correo por OAuth 2.0 con Microsoft 365: las instalaciones propias pueden enviar las notificaciones por Microsoft 365 con OAuth 2.0.
  • Estabilidad: menos errores esporádicos de base de datos ante operaciones simultáneas.

Cambios en la API

  • PrivateKey retirada de los dispositivos: DeviceService.EnumDevices, GetDevice y el resto de los métodos que devuelven la entidad Device (incluida la respuesta de CreateDevice) ya no incluyen la clave privada del dispositivo. El campo Device.PrivateKey sigue en el contrato, pero siempre vale null. /api/v2 no la devolvía.
  • Aviso de deprecación: GET /api/v2/instance/details/{seqFrom} está obsoleto. Usar GET /api/v2/instance/mapping/{seqFrom}, que requiere los mismos permisos y devuelve el mapa de la instancia en forma de árbol: la estructura de la respuesta es distinta, así que hay que adaptar el código que la lee. Dejará de estar disponible el 23 de abril de 2027.
  • Imágenes de entidades: EntityImageService exige permiso de acceso sobre la entidad (dispositivo, endpoint o alarma), además del permiso de API, y solo admite esos tres tipos.
  • Métodos nuevos:
    • DeviceService: SetDeviceLifecycleState, EnumDeviceLifecycleLog, ConfirmCommissioningTestOnSite, EnumDeviceCommissioningTests, EnumClientCommissioningTests, GetDeviceLocationDetails, SetDeviceLocationDetails, SetDeviceFollowUpState, EnumDeviceFollowUpLog.
    • AlarmService: EnumRecentAlarms, AddAlarmNote, GetAlarmEventLogPdf.
    • CommandService: EnumCommandHistory, con el ciclo de vida de cada comando (Queued, SentToNetwork, Acknowledged, Confirmed, Failed, Cancelled, Expired).
    • GatewayService: RefreshGatewayLnsStatus, EnumGatewayLnsSamples, EnumGatewayHeardDevices.
    • Servicio nuevo CommunicationService.
  • Entidades: Device suma LifecycleState y FollowUpState; FacilityType, IsStockLocation; Alert y AlertTemplate, AlarmTypeID.
  • Alarmas de sistema nuevas: 13 (Command not transmitted by the network) y 14 (Output did not reach the requested state).
  • Códigos de error nuevos: entre otros, 18009 (comando en cola para un equipo que aún no se conectó), 28005 y 28006 (un script intentó guardar un valor NaN o infinito) y 33001 a 33007 (comunicaciones).
  • CoolAutomation Cloud: la integración «CoolAutomation.CloudIntegration» ya no se ofrece para dispositivos nuevos.

Correcciones

  • Sesión caducada: Monitor cierra la sesión y lleva al login en lugar de seguir consultando sin avisar.
  • Geozonas: el editor sigue funcionando tras el retiro de la herramienta de dibujo de Google Maps, ya no pierde el último vértice ni hace zoom con doble click.
  • Altas simultáneas: dar de alta dos facilities o dos dispositivos al mismo tiempo ya no hace fallar a uno de ellos.
  • Borrado de dispositivos: ya se puede borrar un dispositivo con una alarma enganchada abierta, el borrado ya no se deshace si había una alarma de endpoint abierta, y borrar un gateway ya no deja huérfanos a sus dispositivos.
  • Serie reutilizable: la dirección de un dispositivo borrado se puede volver a usar.
  • Pérdida de datos: un error de base de datos a mitad de un uplink ya no pierde el dato, y la cola de mediciones ya no descarta lecturas ante un tiempo agotado.
  • Alarmas offline: las que no se pudieron crear se reintentan, y los dispositivos dados de alta que nunca enviaron datos ya no cuentan como "sin señal".
  • Monitor → Devices: los comandos del menú contextual ya no se pierden tras filtrar, y la tabla refresca el estado en cuanto se acepta un comando.
  • Widget de mapa en asset tracking: ya no sale siempre vacío.
  • Gráfico XY: ya no muestra error con un rango sin duración ni con agregaciones en endpoints sin muestras previas.
  • Selector de fechas: rechaza rangos sin duración o invertidos.
  • Reporte de dashboard: respeta el rango guardado en el favorito; los PDF programados salían con el último rango visto.
  • Señal LoRaWAN: la calidad de señal salía en 0 % con el equipo reportando.
  • Dashboards generados desde plantilla: los widgets Device ya no salen vacíos, y la barra de chips aparece siempre.
  • Gateways: el seguimiento por TTN v3 vuelve a registrar gateways, los gateways LORIOT se pueden guardar y mover de facility, y los downlinks de LORIOT salen de a uno y se reintentan.
  • Severidad personalizada borrada: sus alarmas ya no muestran un texto faltante.
  • Plantillas de alerta: aplicar una plantilla ya no queda a medias ante un error.
  • Notificaciones por email: el destino lista todos los destinatarios, no solo el primero.
  • Planos: cambiar el fondo ya no pierde el archivo ni da error.
  • Widgets de métrica y de texto: el valor ya no sale cortado.
  • Formularios: Enter dentro de un cuadro de varias líneas ya no guarda el modal.
  • Log in as: el usuario vuelve a recibir el aviso por email cuando un administrador entra como él, en los 8 idiomas.
  • Clientes: borrar un cliente con escalamiento por severidad ya no falla.
  • Dispositivos: editar un dispositivo con datos inválidos devuelve un error claro en lugar de un error interno.

Soporte

Para consultas, contactar al equipo Cloud Studio: contacto@cloud.studio.