Integración externa - Shelly

Hola a todos :waving_hand:

Después de pasar bastante tiempo con los payloads de Shelly, les presento una integración externa de Shelly para Gladys, en versión 1.0.0.

:package: Repositorio: GitHub - Terdious/gladys-shelly · GitHub
:open_book: Documentación: Francés · Inglés


En dos palabras

Relés, enchufes inteligentes y contadores de energía Shelly, localmente primero, sin cuenta y sin nube. La instalación típica requiere un formulario de configuración completamente vacío: instale, ejecute un escaneo, agregue sus dispositivos.


¿Ya controlas tus Shelly a través de un puente?

Pierre-Gilles acaba de publicar su postura sobre el tema — Retorno de experiencia: por qué ahora recomiendo las integraciones externas — y la comparto completamente.

Si sus Shelly pasan hoy por una capa intermedia, puede cambiarlos aquí. Lo que gana concretamente: ya no tiene que mantener nada entre Gladys y sus dispositivos, y sobre todo 100 % de lo que el hardware sabe hacer, sin pasar por un estándar que primero debe saber expresarlo. Un Pro 3EM sale con sus 24 funcionalidades — las tres fases por separado, potencia activa y aparente, tensión, intensidad, corriente de neutro, y los ocho contadores de energía consumida y reinyectada.

Una sola precaución: elimínelos del antiguo puente antes de agregarlos aquí, de lo contrario verá cada Shelly duplicado.


Lo que sabe hacer

Local, y en tiempo real. La integración habla el protocolo RPC Gen2+ directamente a sus dispositivos, en una WebSocket que el dispositivo alimenta por sí mismo: un relé cambiado en el interruptor de la pared se actualiza en aproximadamente un segundo, no en la próxima consulta.

Todas las generaciones. Gen2 y posteriores (Plus, Pro, Mini, Gen3, Gen4) y Gen1 (Shelly 1, 1PM, 2.5, Plug S, EM, 3EM). Las Gen1 hablan una API completamente diferente — REST en lugar de JSON-RPC, Basic en lugar de Digest — pero están normalizadas hacia el mismo modelo: un 3EM Gen1 expone exactamente las mismas 24 funcionalidades que un Pro 3EM Gen2.

Tres transportes, del mejor al último recurso: local → MQTT → nube. Cada uno tiene su razón de ser:

  • lo local es el camino nominal;
  • MQTT (opcional) es el medio más fiable para encontrar una gran instalación. El mDNS se anuncia en ráfagas multicast cortas fáciles de perder: en mi caso, el mismo parque a veces volvía a 19, a veces a 27 dispositivos, con algunos sistemáticamente ausentes. Un Shelly que publica en su broker se anuncia permanentemente — se descubre, se actualiza en tiempo real, y sigue siendo controlable incluso si no es accesible localmente;
  • la nube Shelly (opcional) toma el relevo cuando un dispositivo no es accesible ni localmente ni por MQTT.

Gladys muestra el transporte realmente utilizado, dispositivo por dispositivo, con el badge degradado y su razón cuando no es el camino nominal.

El modelo de dispositivo se deduce, no está codificado. Las funcionalidades provienen de los componentes que el dispositivo declara realmente en Shelly.GetStatus, nunca de una tabla de modelos. Un Pro 1 obtiene un On/Off, un Pro 1PM obtiene además la metrología — y un Shelly salido después de este código sigue funcionando, siempre que hable el vocabulario documentado.

Componentes cubiertos: switch, em, emdata, em1, em1data, pm1, temperature, humidity, devicepower.


El tiempo real, y por qué es ajustable

Gladys acepta 300 estados por minuto por integración. Un solo Pro 3EM envía aproximadamente una actualización por segundo en ~25 medidas: transmitir todo tal cual haría ~900 estados/minuto, tres veces el límite.

Los valores se distribuyen en dos vías:

  • una vía en tiempo real (5 s por defecto, ajustable de 1 s a 30 s) que lleva todas las potencias instantáneas — total, por fase, por relé — y todos los estados de encendido/apagado;
  • el resto (tensiones, intensidades, potencias aparentes, contadores de energía, temperaturas) sigue el intervalo de actualización, pero servido desde el valor empujado más fresco, sin ida y vuelta HTTP.

El punto al que me aferro: su ajuste es un suelo, no una promesa. El costo de la vía depende del parque, no del ajuste — un valor que nunca cambia no cuesta nada. La integración mide lo que publica realmente y alarga su propio intervalo si el parque se vuelve demasiado grande, escribiéndolo en los registros, luego vuelve por sí misma. Un estado rechazado por Gladys sería invisible; una vía ralentizada, no.

Y cada minuto, una línea dice exactamente dónde está:

Real-time lane: 178 state(s) published in the last minute (every 5s, from
5 WebSocket and 15 MQTT device(s)); 243/300 states/min of the Gladys budget used

Instalación

En Gladys: Integraciones → Instalar una integración → Shelly → Instalar, luego Descubrimiento → Escanear.

No hay nada que llenar para una instalación 100 % local. Los campos (direcciones adicionales, contraseña de los dispositivos, broker MQTT, clave de la nube) solo sirven si su instalación los necesita, y cada uno se explica directamente en el formulario.

(imagen 4: la página de configuración, formulario vacío)

Requiere Gladys ≥ 4.83.0. Si un dispositivo sigue sin encontrarse en el escaneo, la documentación explica qué mirar — y configurar MQTT es casi siempre la respuesta en una instalación grande.


Probado en

Mi instalación: 19 Shelly, 10 x Pro 3EM, 1 x Pro 4PM, 2 x Pro 3, 1 x Plus 2PM, 2 x Plus Plug S, y 3 x 3EM Gen1. Local, MQTT y los dos combinados.


Gracias @pierre-gilles :folded_hands:

De paso, me topé con un límite del núcleo: publishDiscoveredDevices() se encontraba con un PayloadTooLargeError más allá de una docena de dispositivos ricos en funcionalidades (un Pro 3EM = 24 funcionalidades ≈ 8,4 Ko). Pierre-Gilles lo corrigió muy rápido del lado del núcleo (PR #2732). Mientras todos se actualizan, la integración publica el subconjunto más grande aceptable y registra nominalmente lo que ha sido descartado, en lugar de perder el escaneo en silencio.


El futuro

Aún no soportados, por falta de material para validarlos: cortinas (cover), iluminación variable (light) y entradas (input). El código está listo para recibirlos, me faltan los dispositivos: si los tienes y quieres probar una imagen :dev, dime, te lo preparo con gusto — es la mejor manera de que llegue rápido.

Los Shelly BLU tampoco están gestionados: hablan Bluetooth, y la integración no hace BLE.

La hoja de ruta está abierta: Roadmap — Shelly external integration · Issue #1 · Terdious/gladys-shelly · GitHub

Errores, comentarios, payloads de dispositivos exóticos: las issues están abiertas. Y si pruebas, dime qué tal te va — especialmente en modelos que no tengo, y especialmente en modelos que no tengo :slightly_smiling_face:

¡Bravo! ¡Super integración!

@McFlyPartages ¿No estás en Shelly tú también? Te va a gustar :slight_smile: