Salut à tous 
Après pas mal de temps passé le nez dans les payloads Shelly, je vous présente une intégration externe Shelly pour Gladys, en version 1.0.0.
Dépôt : GitHub - Terdious/gladys-shelly · GitHub
Documentation : Français · English
En deux mots
Relais, prises connectées et compteurs d’énergie Shelly, en local d’abord, sans compte et sans cloud. L’installation type demande un formulaire de configuration entièrement vide : vous installez, vous lancez un scan, vous ajoutez vos appareils.
Vous pilotez déjà vos Shelly via un pont ?
Pierre-Gilles vient de publier sa position sur le sujet — Retour d’expérience : pourquoi je recommande désormais les intégrations externes — et je la partage entièrement.
Si vos Shelly passent aujourd’hui par une couche intermédiaire, vous pouvez les basculer ici. Ce que vous y gagnez concrètement : plus rien à maintenir entre Gladys et vos appareils, et surtout 100 % de ce que le matériel sait faire, sans passer par un standard qui doit d’abord savoir l’exprimer. Un Pro 3EM ressort avec ses 24 fonctionnalités — les trois phases séparément, puissance active et apparente, tension, intensité, courant de neutre, et les huit compteurs d’énergie consommée et réinjectée.
Une seule précaution : retirez-les de l’ancien pont avant de les ajouter ici, sinon vous verrez chaque Shelly en double.
Ce qu’elle sait faire
Local, et en temps réel. L’intégration parle le protocole RPC Gen2+ directement à vos appareils, sur une WebSocket que l’appareil alimente lui-même : un relais basculé à l’interrupteur mural remonte en une seconde environ, pas au prochain sondage.
Toutes les générations. Gen2 et suivantes (Plus, Pro, Mini, Gen3, Gen4) et Gen1 (Shelly 1, 1PM, 2.5, Plug S, EM, 3EM). Les Gen1 parlent une API complètement différente — REST au lieu de JSON-RPC, Basic au lieu de Digest — mais elles sont normalisées vers le même modèle : un 3EM Gen1 expose exactement les mêmes 24 fonctionnalités qu’un Pro 3EM Gen2.
Trois transports, du meilleur au dernier recours : local → MQTT → cloud. Chacun a sa raison d’être :
- le local est le chemin nominal ;
- MQTT (optionnel) est le moyen le plus fiable de trouver une grande installation. Le mDNS s’annonce par courtes rafales multicast faciles à manquer : chez moi, le même parc revenait tantôt à 19, tantôt à 27 appareils, avec certains systématiquement absents. Un Shelly qui publie sur votre broker s’annonce en permanence — il est découvert, il remonte en temps réel, et il reste pilotable même injoignable en local ;
- le Shelly Cloud (optionnel) prend le relais quand un appareil n’est joignable ni en local ni par MQTT.
Gladys affiche le transport réellement utilisé, appareil par appareil, avec le badge dégradé et sa raison quand ce n’est pas le chemin nominal.
Le modèle d’appareil est déduit, pas codé en dur. Les fonctionnalités viennent des composants que l’appareil déclare réellement dans Shelly.GetStatus, jamais d’une table de modèles. Un Pro 1 obtient un On/Off, un Pro 1PM obtient en plus la métrologie — et un Shelly sorti après ce code fonctionne quand même, tant qu’il parle le vocabulaire documenté.
Composants couverts : switch, em, emdata, em1, em1data, pm1, temperature, humidity, devicepower.
Le temps réel, et pourquoi il est réglable
Gladys accepte 300 états par minute par intégration. Un seul Pro 3EM pousse environ une mise à jour par seconde sur ~25 mesures : tout transmettre tel quel ferait ~900 états/minute, trois fois le plafond.
Les valeurs sont donc réparties sur deux voies :
- une voie temps réel (5 s par défaut, réglable de 1 s à 30 s) qui porte toutes les puissances instantanées — totale, par phase, par relais — et tous les états marche/arrêt ;
- le reste (tensions, intensités, puissances apparentes, compteurs d’énergie, températures) suit l’intervalle de rafraîchissement, mais servi depuis la valeur poussée la plus fraîche, sans aller-retour HTTP.
Le point auquel je tiens : votre réglage est un plancher, pas une promesse. Le coût de la voie dépend du parc, pas du réglage — une valeur qui ne bouge jamais ne coûte rien. L’intégration mesure donc ce qu’elle publie réellement et allonge son propre intervalle si le parc devient trop gros, en l’écrivant dans les logs, puis y revient d’elle-même. Un état refusé par Gladys serait invisible ; une voie ralentie, non.
Et chaque minute, une ligne dit exactement où vous en êtes :
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
Installation
Dans Gladys : Intégrations → Installer une intégration → Shelly → Installer, puis Découverte → Scanner.
Il n’y a rien à remplir pour une installation 100 % locale. Les champs (adresses supplémentaires, mot de passe des appareils, broker MQTT, clé cloud) ne servent que si votre installation en a besoin, et chacun est expliqué directement dans le formulaire.
(image 4 : la page de configuration, formulaire vide)
Nécessite Gladys ≥ 4.83.0. Si un appareil reste introuvable au scan, la doc explique quoi regarder — et configurer MQTT est presque toujours la réponse sur une grosse installation.
Testé sur
Mon installation : 19 Shelly, 10 x Pro 3EM, 1 x Pro 4PM, 2 x Pro 3, 1 x Plus 2PM, 2 x Plus Plug S, et 3 x 3EM Gen1. Local, MQTT et les deux mélangés.
Merci @pierre-gilles 
Au passage j’ai buté sur une limite du core : publishDiscoveredDevices() se prenait un PayloadTooLargeError au-delà d’une douzaine d’appareils riches en fonctionnalités (un Pro 3EM = 24 fonctionnalités ≈ 8,4 Ko). Pierre-Gilles a corrigé ça très vite côté core (PR #2732). En attendant que tout le monde soit à jour, l’intégration publie le plus gros sous-ensemble acceptable et journalise nommément ce qui a été écarté, plutôt que de perdre le scan en silence.
La suite
Pas encore supportés, faute de matériel pour les valider : volets roulants (cover), éclairages variables (light) et entrées (input) . Le code est prêt à les accueillir, il me manque les appareils : si vous en avez et que vous voulez tester une image :dev, dites-le, je vous prépare ça avec plaisir — c’est le meilleur moyen que ça arrive vite.
Les Shelly BLU ne sont pas gérés non plus : ils parlent Bluetooth, et l’intégration ne fait pas de BLE.
La roadmap est ouverte : Roadmap — Shelly external integration · Issue #1 · Terdious/gladys-shelly · GitHub
Bugs, retours, payloads d’appareils exotiques : les issues sont grandes ouvertes. Et si vous testez, dites-moi ce que ça donne — surtout sur des modèles que je n’ai pas, et surtout sur des modèles que je n’ai pas 
Mise à jour : v1.0.0 → v1.1.0
Nécessite désormais Gladys ≥ 5.1.0 (widgets et scènes).
Volets roulants (
Lumières (
Entrées et boutons (
Scènes (catégorie Intégrations)
4 widgets de tableau de bord
Diagnostic dans la Configuration
4 langues
Sécurité et maintenance
Pour en profiter
Retours très attendus
Un mot de passe différent par appareil
Capteurs Gen1 sur batterie
Shelly Cloud
Correction : un appareil Gen1 lu via le cloud (par exemple un 3EM Gen1 injoignable en local) ne remontait aucune valeur. Il est maintenant lu exactement comme en local.