Dernière mise à jour : 13 novembre 2026La rédaction, Rédaction
Shelly Cloud

Un module Shelly installé derrière un interrupteur parle à deux interlocuteurs possibles : un serveur du constructeur, via Internet, et la box domotique du salon, sur le réseau local. Beaucoup d’appareils ouvrent les deux canaux en même temps sans que personne l’ait décidé, et c’est à l’arrivée de Home Assistant que la question se pose vraiment. Ce que notre installation garde quand Internet tombe pèse autant que ce que l’on perd en coupant le Shelly Cloud.
Shelly Cloud, c’est le service en ligne de Shelly auquel les appareils de la marque peuvent se connecter pour être commandés à distance. Il s’appuie sur l’application Shelly Smart Control : selon la documentation de Shelly Europe, l’application repose surtout sur le cloud, ce qui permet de tout contrôler à distance.
Techniquement, un appareil Gen2, Gen3 ou Gen4 maintient une connexion permanente (JSON-RPC sur WebSocket) avec le serveur iot.shelly.cloud, sur le port TCP 6012. Elle transporte la télémétrie, les commandes à distance et les notifications push, selon le guide de conception réseau de la base de connaissances Shelly. Les appareils Gen1 emploient un protocole cloud différent, mais le principe est le même : l’appareil appelle le serveur, et non l’inverse. C’est ce qui permet de commander un module depuis un smartphone en 4G sans ouvrir de port sur la box.
L’application sait aussi travailler sans Internet. Shelly Europe indique qu’elle prend en charge un « contrôle local » qui permet de gérer les appareils du réseau domestique sans accès Internet. Le cloud n’est donc pas le seul chemin : c’est celui qui sort de la maison.
Non : l’intégration Shelly de Home Assistant échange directement avec l’appareil, et la page de l’intégration précise que la connexion au cloud n’est pas nécessaire. Elle est classée en « Local Push », c’est-à-dire que l’appareil envoie lui-même ses changements d’état à Home Assistant sur le réseau local, sans interrogation permanente ni passage par un serveur extérieur.
La façon dont l’appareil pousse ces informations dépend de sa génération.
| Génération | Mécanisme local | Ce qu’il faut savoir |
|---|---|---|
| Gen1 | CoIoT | À activer dans l’interface web de l’appareil. Méthode recommandée : unicast, avec l’adresse IP de Home Assistant et le port 5683 dans le champ « CoIoT peer ». Redémarrage de l’appareil nécessaire. |
| Gen2 et plus | Outbound WebSocket (protocole RPC) | Aucun réglage par défaut. Seuls les appareils sur batterie peuvent demander une configuration manuelle. |
Les versions minimales de micrologiciel comptent. Home Assistant demande la version 1.9 ou plus récente pour un Gen1 (1.11 pour les DUO, Bulb RGBW, Dimmer, Dimmer 2, RGBW2 et Vintage) et la version 1.0 ou plus pour un Gen2. Deux familles sont écartées : le Shelly 4Pro et le Sense de première génération, et le Shelly AZ H&T, faute d’Outbound WebSocket. Les capteurs de la gamme BLU ne passent pas par cette intégration : Home Assistant renvoie vers l’intégration BTHome.
Si vous désactivez le cloud d’un appareil, vous perdez la connexion à celui-ci depuis l’extérieur de votre réseau local. L’avertissement figure tel quel dans le guide de l’interface web du Shelly Plus 2PM. Chez vous, rien ne change pour Home Assistant, qui n’emprunte pas ce chemin.
Concrètement, trois choses se jouent.
Le témoin de l’interface web indique l’état : sur le Shelly Plus 2PM, l’icône du cloud est grise quand la connexion est désactivée, blanche quand elle est activée mais non établie, bleue quand l’appareil est connecté à Shelly Cloud.
Sur un appareil Gen2 ou plus récent, ouvrez l’interface web de l’appareil dans un navigateur, à son adresse IP locale, puis le menu Settings > Connectivity > Cloud (intitulé relevé sur le Shelly Plus 2PM). Le cloud y est activé par défaut. Le guide de conception réseau de Shelly donne le même geste sous la forme « Settings -> Cloud -> Disable » pour un fonctionnement entièrement local ; l’intitulé exact peut donc varier d’un modèle ou d’un micrologiciel à l’autre.
Le réglage existe aussi dans les commandes techniques de l’appareil. Le composant Cloud expose un paramètre `enable` (booléen) et la méthode `Cloud.SetConfig` : envoyer `enable` à `false` coupe la connexion, `true` la rétablit. La documentation technique de Shelly précise que la réponse indique `restart_required` à `false` : aucun redémarrage n’est annoncé pour ce réglage. La méthode `Cloud.GetConfig` renvoie l’état et le serveur auquel l’appareil est relié, et `Cloud.GetStatus` indique si la connexion est établie (`connected`).
Pour un Gen1, la procédure dans l’interface web n’a pas été relue à la source : consultez le guide d’utilisation de votre modèle dans la base de connaissances Shelly plutôt que de chercher un menu au hasard. Les adeptes des modules à base de puce ESP trouveront un autre univers de maison connectée dans notre page sur l’ESP32.
Oui : une installation entièrement locale est prévue par Shelly pour les appareils Gen2 et plus. Le guide de conception réseau décrit le montage : cloud désactivé, MQTT ou WebSocket en local, serveur NTP interne. Tout le trafic sortant peut alors être bloqué, à l’exception du TCP 443 vers updates.shelly.cloud, qui sert aux mises à jour du micrologiciel.
Le même guide cadre les ports côté Home Assistant : WebSocket est son protocole par défaut, avec le port TCP 80 ouvert depuis l’hôte Home Assistant vers l’appareil, ou le 443 à partir du micrologiciel 1.8. Côté Gen1, le port UDP 5683 (CoIoT) doit être ouvert entre sous-réseaux, et aussi sur le pare-feu de la machine si Home Assistant tourne dans une VM ou comme service hors HAOS. L’heure compte aussi : la mesure de puissance dépend de l’accessibilité du service SNTP.
Quand l’appareil et Home Assistant sont sur des sous-réseaux différents, ces ouvertures de ports se vérifient avant tout autre réglage.
Le cloud ouvre un chemin sortant vers un serveur du constructeur, et chaque appareil connecté au cloud étend l’exposition de votre installation à un tiers. Le guide de conception réseau ne précise pas si la connexion sur le port 6012 emploie TLS : ce point n’est donc pas affirmé ici. Pour la partie MQTT, ce guide indique que les appareils se connectent au courtier sur le port TCP 8883 avec TLS, et que ce trafic chiffré doit être transmis sans inspection par le pare-feu.
Côté Home Assistant, une évolution mérite attention. Les Gen2 et plus passés au micrologiciel 2.0.0 ou plus récent disposent d’un mode Enhanced Security, en lien avec la conformité à la directive européenne RED. Il active le HTTPS, détecté automatiquement par l’intégration. Les appareils mis à jour vers la 2.0.0 (et non livrés avec) ne servent que du HTTP par défaut tant qu’aucun certificat n’est téléversé. N’activez « Verify SSL » dans Home Assistant que si le certificat de l’appareil est signé par une autorité que Home Assistant reconnaît.
Dans le schéma de Shelly pour une installation locale, le serveur iot.shelly.cloud sur le port 6012 n’a plus de raison d’être joint une fois le cloud désactivé.
Non. L’intégration communique directement avec l’appareil sur le réseau local, et la connexion au cloud n’est pas requise. Il faut en revanche que l’appareil et Home Assistant se joignent : même réseau, ou ports ouverts entre sous-réseaux.
Dans l’application Shelly Smart Control, il a besoin du cloud pour être pleinement utilisable. Avec Home Assistant, c’est l’intégration qui prend le relais, mais un appareil sur batterie dort la plupart du temps : appuyez sur son bouton pour le réveiller avant la configuration.
Non, à l’exception du BLU TRV via une passerelle Gen3. Les autres appareils de la série BLU se gèrent avec l’intégration BTHome de Home Assistant.
Oui, sur un Gen1, le redémarrage est nécessaire après toute modification du pair CoIoT. Si les mises à jour en push n’arrivent pas, Home Assistant affiche un problème de réparation, qui sert d’indice pour vérifier le champ et le port 5683.
Pas complètement : pour ces appareils, les entités de mise à jour signalent seulement qu’une version est disponible, sans pouvoir la lancer. Le service `homeassistant.update_entity` ne fonctionne pas non plus sur eux, car ils sont le plus souvent endormis.
Oui, tant que le trafic vers updates.shelly.cloud en TCP 443 reste autorisé, d’après le guide de conception réseau de Shelly. Ce flux est celui que le guide réserve aux mises à jour du micrologiciel dans une installation locale.