Les objets connectés en Wi-Fi sont le plus souvent décevants, mais il y a des exceptions. C'est le cas de ceux de Shelly qui proposent une gestion locale via une interface web et une API complète. Nous les avons testés à travers la prise connectée avec mesure de consommation Plug S.
Ces dernières années, la domotique s'est largement transformée sous l'impulsion des géants américains du numérique. Alors qu'elle s'était structurée autour de différents protocoles basse consommation spécialisés (voir notre magazine #2), ils ont peu à peu imposé le Bluetooth et le Wi-Fi comme solution d'accès.
L'ère de la domotique facile et ses travers
Leur objectif principal était en effet de démocratiser des solutions grand public, clé en main, où il était possible de positionner leurs propres produits comme éléments centraux. Ces deux protocoles sans fil étant très connus, peu coûteux et présents dans tous les smartphones, tablettes et autres appareils, il était facile de les plébisciter.
Cette façon de faire s'est néanmoins confrontée à la réalité. Nombre de constructeurs se sont créé autour de la « folie » des objets connectés, imposant leurs applications, comptes et autres outils peu pratiques, pas toujours très sécurisés. Alors que la domotique ouverte explosait, on venait de lui ajouter une couche dispersée, composée de solutions propriétaires trop souvent mal ficelées. Elles sont encore légion aujourd'hui (nous y reviendrons).
Il y a néanmoins certains acteurs qui ont fait les bons choix et se sont démarqués. Comprenant que, quelle que soit la solution technique retenue, ce n'était pas en enfermant ses clients dans de mauvais outils que l'on allait les convaincre d'investir en masse dans les solutions maison. Comme on l'a vu avec l'API locale Philips Hue ou celle (officieuse) des prises connectées de TP-Link, un simple outil du genre peut faire toute la différence.
Shelly l'a bien compris et en a d'ailleurs fait sa force principale. La société bulgare propose ainsi une gamme complète de modules et produits domotiques exploitant le Wi-Fi, mais de la bonne manière. Dans le cadre de notre dossier sur les prises connectées, nous avons acheté et testé leur Plug S pour le vérifier.
Les partenaires et protocoles supportés par Shelly
Quand le Wi-Fi ne sert pas à enfermer les clients
L'utilisation du Wi-Fi dans une solution domotique n'est en général pas vu comme la solution idéale par les puristes : ce protocole de réseau sans fil est souvent surchargé (notamment en zone urbaine), pas toujours très stable et n'a pas vraiment été prévu pour de la basse consommation, ce qui pose souci pour des produits devant être autonomes.
Mais il y a une autre raison : les objets connectés exploitant le Wi-Fi sont en général très mauvais. Pensés pour être vendus en masse, à petit prix, par des constructeurs qui n'ont pas grand-chose à faire de l'expérience utilisateur, ils devaient surtout accompagner la vague d'équipement d'enceintes connectées. Car allumer une prise ou une ampoule via Alexa/Google Assistant/Siri, c'est rigolo, et cela fait un cadeau parfait pendant les fêtes. Si en plus il peut ne coûter que quelques dizaines d'euros avec des marges énormes... c'est encore mieux.
Résultat, les clients se retrouvent le plus souvent avec des appareils ne fonctionnant qu'avec une application propriétaire, nécessitant la création d'un compte, n'ayant aucune mécanique d'ouverture ou presque. Dans le meilleur des cas, on a droit à une API passant par les serveurs de l'entreprise, même pour un contrôle local.
Bref, tout ce que l'on devrait éviter en domotique.
Un catalogue intéressant, encore méconnu
Si Shelly a fait le choix du Wi-Fi (4, 802.11n), c'est heureusement avec une approche ouverte. Ainsi, ses produits embarquent un serveur web permettant une gestion locale via une interface en ligne. Elle est complétée par une API, elle aussi locale. Comme nous le verrons plus loin, les deux sont accessibles avec ou sans authentification.
De quoi faciliter les intégrations tierces, nombreuses, avec bien entendu l'éternel duo Amazon Alexa et Google Assistant. Dernière en date : un partenariat annoncé peu avant le CES avec le système domotique open source Home Assistant. Mais il y a aussi Domoticz, openHAB et quantité d'outils/plugins. Ainsi, on trouve même des firmwares alternatifs permettant un support d'Apple HomeKit, avec des fonctionnalités parfois limitées.
La société est surtout connue pour ses modules, proposés dès 10 euros environ avec le Shelly 1, permettant de contrôler un appareil. D'autres permettent d'aller au-delà, de gérer des moteurs de volet roulant, se connectent avec ou sans neutre, intègrent parfois des fonctionnalités de mesure de consommation, etc.
Mais son offre se compose aussi d'ampoules connectées, de divers accessoires et capteurs. Une solution intéressante sur le papier, mais dans les faits, tout est-il si idyllique ?
Premier regret, Shelly est peu distribué sur le marché français. On trouve bien entendu ses produits dans des boutiques spécialisées, mais pas chez des généralistes, même lorsqu'ils ont un large rayon consacré à la domotique. Le plus simple est donc de passer par la boutique en ligne du constructeur, simple et efficace.
Elle n'oblige pas à la création d'un compte, vous pouvez y commander en invité (guest). Les prix y sont raisonnables, certains produits étant proposés à l'unité ou via des packs à tarif réduit. La garantie est assurée pendant deux ans. On peut souscrire à un niveau « Plus » facturé 10 %, donnant droit à un remplacement gratuit (sans frais de port) pendant un an, même si la panne est de notre fait : mauvais câblage, casse, etc.
La livraison s'effectue de manière standard (dès 6,63 euros) ou via DHL (dès 15,28 euros). La carte bancaire et PayPal Express sont acceptés comme moyen de paiement.
Plug S : un modèle compact et accessible
Nous avons commandé plusieurs modules (nous y reviendrons), ainsi que le produit de notre test du jour : la Plug S vendue 20 euros (77 euros par 4). Cette prise connectée avec mesure de puissance est clé en main : il suffit de la brancher au secteur pour l'utiliser. Elle nous est arrivée en quelques jours, dans une simple enveloppe à bulles.
On apprécie que son emballage soit un carton minimal, juste à sa taille. Sa compacité est d'ailleurs un autre de ses atouts : 69 mm de long pour 46 mm de diamètre, comme la Wall Plug de Fibaro (vendue 60/70 euros). Comme elle, elle est limitée à 2 500 watts (12 A). Elle ne reprend par contre pas l'un de ses points forts que nous avons particulièrement apprécié : une LED dont la couleur change selon la puissance consommée. Dommage.
Deux LED permettent par contre de connaître le statut de la connexion Wi-Fi et l'état de la lampe. Sur le côté, un petit bouton de gestion est présent, ses fonctionnalités sont multiples comme nous le verrons plus loin. Si vous cherchez un modèle capable d'encaisser jusqu'à 3 500 watts (16 A), la Shelly Plug est également proposée. Mais elle est plus chère (32,4 euros) et surtout bien plus imposante (85 x 57 x 98 mm).
Un simple serveur web pour tout gérer
Comme nombre de solutions Wi-Fi, la Plug S et les modules de Shelly embarquent un micro-contrôleur ESP8266 capable de faire tourner un petit serveur web. Dès qu'elle est branchée au secteur, la prise émet un réseau Wi-Fi auquel on peut se connecter. L'interface est alors accessible via l'adresse IP 192.168.33.1.
On y obtient une interface classique mais plaisante, qui s'adapte à l'appareil (ordinateur, smartphone, etc.). Elle affiche la puissance actuellement consommée en watts. La valeur se met régulièrement à jour sans rafraîchissement de la page. On peut d'un clic allumer ou éteindre la prise.
De nombreuses fonctionnalités sont présentes pour configurer des délais de (dés)activation automatique ou selon un calendrier. Dans ce second cas, cela peut être à une heure précise ou selon le lever/coucher du soleil.
Il y a aussi les actions qui permettent d'envoyer une ou plusieurs requêtes à une URL lorsque le bouton principal est pressé ou selon le statut de la prise (allumée, éteinte). C'est notamment une manière de pouvoir faire interagir les produits Shelly entre eux via leur API locale (dont nous vous parlerons un peu plus loin).
La configuration permet de définir une puissance maximale qui peut être fournie (de 1 à 2 500 watts), mais aussi choisir le statut de la prise lorsqu'elle est branchée : allumée, éteinte ou un retour à son dernier état. On peut lui donner un nom, un type, un canal. Les LED peuvent être activées ou non selon votre préférence.
Lorsque la prise est connectée à votre réseau local, et donc à internet, elle propose deux firmwares : le dernier stable ou bêta en date. On regrette que leurs notes de versions ne soient pas directement visibles. La société, qui propose plusieurs outils de support et de remontée de demande de fonctionnalité se repose malheureusement sur Facebook uniquement pour cette communication technique. Via un groupe public dédié.
L'interface propose également tout ce qu'il faut pour redémarrer ou réinitialiser la prise, la rendre découvrable ou non sur le réseau, lui permettre de relancer sa couche logicielle après un souci de connexion, voir ses informations, etc.
Accès au réseau, fonctionnement AP ou via MQTT
Pour un produit Wi-Fi, il y a un autre onglet essentiel : celui de la configuration des accès réseau. Comme évoqué, la prise fonctionne par défaut comme un point d'accès (AP). On peut s'y connecter, la gérer, etc. Ce mode peut être renforcé par l'ajout d'un mot de passe. Sinon, on peut indiquer à la prise un réseau Wi-Fi tiers auquel elle peut se connecter (mode STA). Seule restriction : il doit être sur la bande des 2,4 GHz, la seule gérée.
Les développeurs peuvent activer le partage de ressources entre origines multiples (CORS) mais aussi un accès via le protocole léger MQTT (sans chiffrement). Pour cela, il faut définir l'URL et les paramètres d'un serveur (broker), qui peut être local ou distant. La prise lui enverra alors régulièrement des informations (statut, consommation, température) qui pourront être accédée via différents « topic ». Elle peut aussi être allumée/éteinte de la sorte.
L'accès à l'interface web, mais aussi à l'API, peut être protégé par un couple identifiant/mot de passe. Une procédure activée au sein du serveur HTTP, là aussi sans chiffrement. C'est encore l'un des points faibles des produits Shelly qui doivent donc être utilisés en prenant ce facteur en compte.
Les adeptes d'une gestion via le « cloud » simplifiée peuvent opter pour le service en ligne de Shelly qui met en place une interface dédiée permettant de gérer plusieurs de ses appareils. Il faut pour cela activer la fonctionnalité au sein de la prise puis l'associer à votre compte (MQTT doit être inactif). On apprécie que tout cela soit optionnel.
Notez enfin que Shelly propose des applications mobiles reprenant l'accès à cette interface en ligne. Mais aussi une autre, sur macOS et Windows, pour découvrir ses appareils présents sur votre réseau. Tout est détaillé ici.
L'API locale : un petit bijou pour bidouilleurs
Là où Shelly peut séduire nombre de développeurs et autres adeptes des solutions maison, c'est via l'API locale qui permet de communiquer directement avec ses produits. Vous n'avez ainsi pas à craindre que l'application officielle ne soit plus disponible, que les serveurs du constructeur tombent en rade, rien de tout cela n'est nécessaire.
Tout ce qui est possible via l'interface web l'est via l'API, qui est d'ailleurs plus complète. On peut l'utiliser pour récupérer des informations depuis la prise ou bien la configurer. Il s'agit d'une API REST classique, renvoyant des réponses au format JSON, exploitable dans des scripts ou via cURL.
Par exemple pour connaitre l'état de la prise :
curl http://192.168.33.1/status
Si vous demandez la consommation courante via cette commande :
curl http://192.168.33.1/meter/0
Vous obtiendrez un résultat de ce type
{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1611563166,"counters":[0.000, 0.000, 0.010],"total":108}
Pour modifier le mot de passe d'accès à l'API ou l'interface :
curl "http://192.168.33.1/settings/login?enabled=1&username=identifiant&password=motdepasse"
Puis pour faire une requête avec ces identifiants :
curl --user identifiant:motdepasse http://192.168.33.1/status
Une prise qui répond instantanément, utilisable via des scripts
Par rapport à la prise de TP-Link, outre le fait que l'API soit officielle et permette une authentification, même basique, on apprécie que la réponse soit instantanée. Mais il y a une raison à cela : là où la prise TP-Link effectue une mesure à chaque requête, avec la Shelly Plug S, la réponse vient d'un cache qui est régulièrement mis à jour.
Cela permet d'obtenir une réponse rapide en évitant toute surcharge de l'API. Mais il faut en tenir compte dans vos intégrations et différents scripts. Par exemple, si l'on reprend celui développé pour nos protocoles de tests et qu'on l'adapte, en effectuant une requête toutes les 300 millisecondes, on obtient le résultat suivant :
Si l'on relève trop régulièrement la consommation, elle se répète
Comme on peut le voir ci-dessus, le même relevé se répète plusieurs fois, jusqu'à six selon les cas. Après analyse nous avons constaté qu'il fallait une pause de deux secondes entre chaque requête pour éviter ce phénomène.
Adapter notre script Python n'a pas été très compliqué. Le module kasa-python n'est plus nécessaire, mais il nous faut effectuer nos requêtes directement désormais, via le module requests qui doit être installé via PiP. Cela ne complexifie néanmoins pas trop le code, que vous pouvez librement réutiliser :
import requests, json
from requests.auth import HTTPBasicAuth
from time import time, sleep
# On déclare les paramètres de connexion à la prise
API_URL ="http://192.168.33.1/meter/0"
API_LOGIN ="identifiant"
API_PASS ="motdepasse"
# On initialise les variables qui seront utilisées
count = total = 0
price_1 kWh = 15.58
time_start = time()
while True:
# On lit les données de la prise et on récupère la consommation actuelle
r = requests.get(API_URL, auth = HTTPBasicAuth(API_LOGIN, API_PASS))
watts = r.json()['power']
# On met à jour les différentes variables
count += 1
total += watts
# On effectue les calculs des valeurs à afficher
average = total/count
elapsed = time()- time_start
energy_J = average * elapsed
energy_Wh = energy_J / 3600
price_total = energy_Wh / 1000 * price_1 kWh
# On affiche le résultat et on attend 1 seconde avant de recommencer
print(f"{count}. "
f"Relevé : {watts:.2f} W -"
f"Moyenne : {average:.2f} W -"
f"Temps : {elapsed:.2f} s -"
f"Energie : {energy_J:.2f} J ou {energy_Wh:.2f} Wh -"
f"Coût : {price_total:.10f} cts€")
sleep(2)
Comme vous pouvez le voir, nous l'avons ici implémenté l'authentification HTTP, pensez donc à modifier l'IP et le couple identifiant/mot de passe. Si vous ne l'utilisez pas, il suffit de retirer l'import de HTTPBasicAuth et la déclaration de la variable auth dans la requête envoyée à la prise. Comme détaillé plus haut, nous avons passé le temps de pause entre deux requêtes à deux secondes pour éviter de relever plusieurs fois une même valeur.
Ainsi, si la prise de Shelly cumule les avantages en étant plus ouverte, facile à gérer, avec une API locale officielle plutôt qu'une officieuse qui peut disparaître à tout moment, il faudra prendre en compte ses limites au moment de votre choix : puissance limitée à 2 500 W (12 A), pas de chiffrement, délai de mise à jour des informations.
Néanmoins, cela sera bien suffisant pour la très grande majorité des cas. Avec son format plus compact, ses atouts multiples et son prix abordable, elle a très largement notre préférence. Espérons que cela finira par inspirer la concurrence pour que l'on en finisse avec la multiplication des applications propriétaires sans API locale.
Commentaires (100)
#1
Article intéressant et complet, et qui tombe bien d’ailleurs puisque j’avais repéré ces prises il y a quelques semaines. J’étais intéressé à la base par les prises connectées de TP-Link (qui étaient vendues à un prix similaire) car il y avait une API locale qui était restée ouverte, mais ils ont poussé une mise à jour qui l’a rendue inutilisable (https://www.reddit.com/r/homeassistant/comments/k00ait/psa_tplink_have_updated_some_of_their_smart_plugs/).
Je me demandais si la prise de Shelly était bien fiable pour 20 euros, d’autant plus qu’il y avait un modèle quasiment similaire deux fois plus cher (la seule différence étant la puissance maximale admissible), au vu de cet article ça a l’air pas trop mal. J’ai aussi vu que Shelly, malgré le fait qu’ils ne soient pas très connus, sont souvent recommandés sur des forums de bidouilleurs et des subreddits comme /r/selfhosted ou /r/homelab…
#2
Le jour où on a ce genre de solutions pour les appareils connectés type robot aspirateur (de la part des grands noms du domaine en tout cas) ce serait bien aussi…
Même dérive de l’application propriétaire avec communication forcée aux serveurs de la marque… Le jour où ils ferment coucou les t’as de ferraille chez soi..!
#3
Pour TP Link on en a parlé dans d’autres articles (notamment pour l’API locale vu que j’utilise ça pour certains relevé au labo). L’API a été débloquée suite à la grogne de mémoire.
#4
Je recommande toute la gamme shelly très chaudement.
Cela fait un peu plus de deux ans que j’utilise des shelly1, 1pm, 2.5 et récemment uni. Que du très bon et du très fiable. Une intégration à Home Assistant impeccable.
J’ai également posé des questions au support sur des points techniques, des réponses rapides.
Une API documentée, un support qui répond, du matériel fiable estampillé CE. Que chercher de plus :)
#5
Je suis toujours inquiet pour ces bidules en wifi… Coté sécurité, c’est souvent extrêmement pourri et ça peut joyeusement servir de relais pour des attaques.
#6
D’où l’intérêt de limiter l’accès web/API, mais le fait que ce soit en Wi-Fi n’est pas plus un facteur aggravant que de passer via des app tierces que personne n’a audité avec l’impossibilité d’empêcher un accès distant par exemple (ce qui arrive souvent)
#7
Vu les fonctions et limitations je pense qu’elles embarquent un ESP8266. Ceci dit c’est un concept sympa et le prix reste correct. Pour le moment pour les quelques prises que j’ai ce sont des prises du commerces flashées avec un firmware open source (Tasmota). Ca fonctionne nickel et ça permet de se passer du serveur du constructeur, en revanche flasher ce firmware alternatif requiert quelques manips et de démonter la prise. Donc c’est là l’avantage de Shelly : proposer une solution ouverte et clé en main.
#8
Le fait que ce soit en wifi, indépendamment de son mode d’accès, permet une connexion directe à internet et donc une utilisation de la bande passante du propriétaire pour faire on ne sait quoi.
C’est ça qui me gène. J’ai carrément pas envie de participer malgré moi à une attaque coordonnée envers un pays quelconque parce que mes ampoules ont été compromises. Ou qu’elles servent de relais pour pirater d’autres équipements plus sensibles chez moi…
J’ai aucune inquiétude de ce type pour mes gadgets zigbee ou zwave même si je sais qu’ils ne sont certainement pas sécurisés non plus.
#9
Rien n’empêche de filter les accès sortants de ces équipements wifi. Je le fais. Et les shelly ne s’en portent pas plus mal…
#10
Libre à toi de ne pas donner accès à internet à la prise, même si elle est en Wi-Fi (ou à le monitorer). L’intérêt étant justement qu’un tel produit n’est pas dépendant d’un accès en ligne pour fonctionner (contrairement à d’autres). Pour les protocoles domotiques, ils ont leur propres travers, et in fine ils restent en général reliés à un élément relié à internet et transmettent des données (ne serait-ce que pour leur mise à jour).
#11
Oui c’est vrai…
Perso, j’en achète même pas comme ça pas de problème. Mais c’est vrai que cette prise est vachement tentante quand même. C’est typiquement le genre de produit que je recherche aujourd’hui.
Je ne connais que Hue qui fait des maj à travers le protocole sans-fil mais les autres que j’utilise sont totalement hors ligne
#12
Ils sont reliés à une box domotique reliée à internet non ?
#13
Non, pas chez moi (sauf la box hue)
Mais bon, la question est pas tellement la box… la question est le nombre d’équipements qui peuvent servir de relais. Une box, ça reste négligeable à coté de 10 ampoules, 4 prises connectées, 5 ou 6 capteurs variés tous en wifi qui balancent des paquets en rafale sur une cible quelconque…
Enfin bref, mon point de vue est que le risque de sécurité est exacerbé par la présence de wifi. Bien plus que pour n’importe quel autre protocole domotique
#14
Tiens, question : ça mesure de façon à peu près précise les faibles charges ?
#15
Oui, et comme dit, si tu pars du principe que c’est du fait de l’accès au réseau externe, rien n’oblige à le donner à ces objets (que ce soit via un VLAN ou d’autres solutions). Pas plus qu’à d’autres équipements domotiques (que ce soit la box ou autre).
Par défaut la prise est sur son propre réseau Wi-Fi et peut être gérée de la sorte. Le Wi-Fi n’est pas spécialement en cause là dedans, c’est juste un protocole de réseau sans fil pù tu peux isoler ou non les appareils (ce qui peut être vu comme un avantage ou un inconvénient selon les cas).
#16
Ça réclame quand même des compétences et du matos pour faire ça… Perso, je les ai, toi aussi et certainement pas mal de gens ici mais nous sommes des exceptions.
#17
Une idée de la consommation de la prise elle-même ?
#18
Quand tu es prêt à laisser Siri, Alexa et ses copines rentrer chez toi, je pense que la sécurité de prise, d’ampules WiFi c’est le cadet de tes préoccupations.
#19
C’est toujours négligeable sur ce type d’appareil et je n’ai pas relevé de consommation spécifique via une autre prise posée dessus. Shelly la donne à moins de 1 watt, les LED ne jouant pas vraiment sur cet ordre de grandeur (puis au pire on peut les éteindre).
Tout est une affaire de besoin et de choix. Je précise juste que considérer le Wi-Fi comme la source du problème que tu évoques c’est se méprendre (sans parler du fait que c’est aussi une facilité pour les accès distant par exemple). Les produits hors Wi-Fi peuvent aussi poser des problème de sécurité divers, directement ou du fait qu’ils font eux-même partie d’un réseau, quel qu’il soit.
Comme dit dans l’article, certains produits Wi-Fi portent en eux des défauts, d’autres moins, si on mise sur le RF433 on y sera bien moins confronté mais à l’inverse on aura d’autres limitations avec lesquelles on devra composer, etc. Il n’y a aucune solution parfaite, même pas dans le domaine de la sécurité.
L’erreur à mon avis c’est de se dire, comme trop souvent dans le domaine du numérique, que monter un et entretenir un système domotique ne nécessite aucune compétence et peut être accessible à tous sans effort. C’est faux, mais “on” le fait croire pour vendre des bidules en masse sans se préoccuper des conséquences. Il faut savoir ce que l’on veut faire, les risques que ça pose, comment s’en préserver.
Se dire “je suis en ZigBee, osef j’ai un bouclier by design” pose plus de problèmes que de miser sur du Wi-Fi en ayant conscience de ses limites. Car c’est ça qui importe avant tout : avoir conscience de ce que l’on fait. Le reste, ce sont des choix, qui regardent chacun.
#20
tous les micromodules shelly et les prises ont une consommation de moins d’un watt.
J’en ai quelques-un, j’en suis très content.
Par contre je galère un peu sur home assistant.
#21
Tout à fait mais je parle pas de ça. Je parle même pas de piratage de MON réseau. Je parle de l’utilisation de mes ressources techniques pour pirater des cibles beaucoup plus intéressantes que moi (et conséquemment, me faire porter le chapeau).
Parce qu’au final, le piratage “domestique”, en vrai, c’est juste pour exploiter des ressources (cpu/gpu pour les miners de bitcoins, bande passante pour les malwares qui envoient du phishing, etc). Les particuliers ne sont presque jamais les cibles directes.
Oui, je sais bien que ça apporte plein de facilité et que ce n’est pas a jeter
Pour exploiter mon réseau zwave, faut venir chez moi déjà… Rien que ça, ça laisse sur le chemin un paquet de motivations d’attaques dont je pourrais être la victime.
Et si un type m’en veut assez pour venir chercher des noises à mon réseau zwave, j’ai d’autres soucis que protéger mes radiateurs.
Bien sur.
Ben ouais, je suis d’accord mais il n’empêche que les bidules se vendent en masse sans que la plupart des clients se préoccupent des conséquences.
Et entre “je suis en zigbee, osef” et “je suis en wifi, osef”, je prends le 1er…
Et même en ayant conscience des risques, je m’estime pas nul en réseau et en système mais je suis pas à l’abri d’un oubli, une erreur ou un nouveau type d’attaque qui m’est inconnu et, d’après moi, les conséquences peuvent être bien plus graves avec des appareils wifi qu’avec des appareils zigbee ou zwave.
#22
juste un truc
wifi != internet
de ce que je lis sur vos échanges, absolument rien n’empêche d’utiliser le réseau “AP” d’une des prises comme réseau auquel se connectent les autres prises
tout le monde est en wifi
pour les manipuler tu connecte ton smartphone à ce réseau wifi spécifique
mais absolument rien ne peut communiquer avec ces prises (ou autre) via internet
c’est un réseau isolé totalement offline.
tu dois pouvoir faire de même avec n’importe quel point d’accès, il génère un réseau wifi, mais il peut ne pas être relié à internet => zéro souci de botnet ou autre joyeuseté
#23
Il ne me semble pas avoir lu combien consommait la prise elle-meme ? Le site du fabricant indique “<1W” mais avez vous mesure cette consommation de votre cote ?
Edit : je n’avais pas vu qu’il y avait 3 pages de commentaires et que la question a deja ete posee. Je regarderai quand je recevrai ma commande !
#24
Comme un réseau Wi-Fi. Il reste local, comme dit plus haut, le fait de relier ou non à internet est un choix possible, pas une fatalité. La différence c’est surtout la portée du réseau (après tout dépend du maillage Z-Wave, mais la portée est en général moindre).
Je comprends ton propos, mais à mon avis, dans les deux cas le “osef” mènera à des problèmes un jour ou l’autre. Parce que comme tu le dis :
Concernant :
Une fois de plus, il faudrait préciser “un appareil Wi-Fi relié à internet”. Ce qui te protège dans le cas de ZigBee/Zwave dans ton installation telle que tu la décris, c’est que ta box de gestion (centralisée) ne soit elle même pas reliée à internet. Mais par exemple cela expose cet élément et tous ceux du réseau à de potentielles faille par défaut de mise à jour de leur firmwares (par exemple).
#25
ca reste quand meme pas très pratique…
#26
Oui on est d’accord
Je vois quand même difficilement comment utiliser mes modules zwave comme botnet…
#27
On ne peut pas résumer un modèle de menace à un seul élément (sauf à faire du cherry pickiéng
). Puis bon, de mémoire il y a du ZWave over IP (ce qui avait notamment poussé l’Alliance à imposer S2 pour la sécurité des nouveaux appareils il y a quelques années). Et je ne vois pas comment utiliser un module Wi-Fi n’ayant pas accès à Internet comme botnet.
#28
cool la série domotique ! merci @david_L
j’en profite du coup :
quelqu’un connait un module qui permet de dimmer de fortes puissances ? genre un radiateur électrique ?
histoire de voir si ça vaut le coup de bricoler un truc DIY ou pas
#29
Ca va pas plus vite d’utiliser le fil pilote pour gérer ça ? Surtout qu’il existe des modules clé en main comme heatzy dans ce but (on en reparle bientôt d’ailleurs)
#30
“fortes” à quel point ?
les halogènes de 500w se dimmaient “facilement” avant la démocratisation de l’éclairage led, j’ai entendu parler de “triacs”, de mémoire ça permettait de faire des montages pour dimmer des halogènes, donc selon ton ordre de grandeur …
par contre je n’ai aucune idée de comment ça marche, limitations de l’intensité dans le circuit ? ou système “PWM”, et comment réagiraient des radiateurs à ce genre de régulation et/ou le boxon d’interférences que ça pourrait engendrer sur le réseau elec
edit : grillé
le fil pilote est quand même limité (4 ou 6 ordres de mémoire selon les équipements, peut-être insuffisant selon l’amplitude de réglage souhaitée)
#31
Faut utiliser un module fil pilote, fibaro en fait des pas mal. Y’a plein d’autres marques et d’autres technos aussi.
#32
merci pour les retours
mais bon, le fil pilote c’est un peu le level 1 du controle …
l’idée est d’avoir une commande proportionnelle piloté par des scénarios jeedom
(je vais travailler en 5x8, donc il me faut un minimum de souplesse …)
j’étais parti sur un ESP8266 (ou un 32) avec un relais statique derrière, pour faire du PWM à 10A avec un PID en fonction de la consigne / mesure de T° dans la pièce
(oui, je sais, c’est un marteau hydraulique … mais faut prévoir de quoi s’occuper pour les prochains confinements
)
#33
Disons que ça fait un peu marteau pour frapper une mouche
Le fil pilote n’est pas pleinement proportionnel, mais ça donne déjà une bonne granularité. Je doute que contrôler un chauffage au watt près change réellement la donne au final, mais ça va ajouter une couche de complexité à la mise en œuvre (mais ça occupe, certes 
)
#34
vais creuser un peu + le fil pilote, quand même … ça occupera déjà un peu ^^
#35
On ne va pas se mentir : l’écrasante majorité des modules Wifi seront connectés au réseau domestique, qui est connecté à Internet et au reste des appareils.
Et ces dernières années, les cas d’exploitation de failles d’objects connectés en Wifi de ce type ont été nombreux.
Cela dit la prise est cool, ça peut être utile pour pas mal de projets.
#36
Comme tu peux avoir des failles dans ta box démotique (elle aussi reliée à Internet dans la majorité des cas), ton protocole domotique. La seule chose que je dis, c’est que si on ne veut pas qu’un appareil communique avec Internet il suffit de ne pas lui donner accès à Internet.
Si on veut lui donner accès, on s’expose à un risque donc il faut savoir le contrôler maîtriser. L’important c’est d’avoir le choix, ce qui est le cas ici. On peut aussi décider d’ajouter une couche au niveau de la gestion du réseau (via un VLAN dédié par exemple)
Dans tous les cas, penser qu’on est protégé by design est dangereux. On est jamais à l’abri de rien (bonjour ceinture bretelle)
#37
Tu es sûr qu’il n’a pas du tout d’électronique basse tension ton radiateur ? Donc un radiateur sans écran, avec un réglage par bouton à déplacer (tournant ou linéaire), un thermostat qui fait clic quand on bouge ce bouton, et qui gère son fil pilote (s’il en a un) sans électronique basse tension ?
S’il ne correspond pas exactement à cette description, c’est qu’il y a de l’électronique dedans, et tu ne pourras pas le dimmer au niveau de la prise, sinon l’électronique va perdre son alimentation, voire réagir très bizarrement à ton PWM. Il te faudra alors le démonter, repérer les fils de la résistance, et dimmer un de ces 2 fils au lieu de dimmer l’alimentation générale du radiateur.
Pour minimiser les perturbations sur le réseau, il faut que les commutations ON/OFF se fassent au moment du passage de la tension à 0. Tu peux par exemple faire une alternance sur 2, sur 3, sur 4… il y en a 100 par seconde. Ca demande un circuit de synchro pour détecter les passages à 0.
Si tu dois découper à l’intérieur de chaque alternance, fais en sorte qu’au moins une des commutations aie lieu au moment du passage à 0. Avec un triac ça se fait tout seul puisqu’il se décommute automatiquement à chaque passage à 0, mais il y a toujours besoin du circuit de synchro.
Tu peux trouver ici un montage similaire à ce que tu proposes, pour commander un chauffe-eau simple, ce qui revient au même.
#38
Merci pour cet article très clair et instructif. Je suis pas mal “shellysé” (quasiment 20 modules). Grâce à vous je me lance sur mqtt !
Sinon la console n’est pas si négligeable que ça : on compte presque 1w par shelly donc une vingtaine… Quasiment l’équivalent d’une lampe Led allumée en permanence. A prendre en compte.
#39
Les prochains articles vont te plaire
Pour la consommation, à voir si la gestion domotique des Shelly te permet d’économiser plus de 175 kWh par an ou pas ;)
#40
Pour la sécurité, j’espère que les routeurs avec la compatibilité HomeKit vont se développer un peu ; cela permet justement de facilement limiter les accès des équipements HomeKit présents sur le réseau (voire de les empêcher complètement de se connecter à internet).
#41
Arff à 200W près je l’aurais placé sur la prise de recharge de la voiture pour le suivi (recharge sur une prise standard, pas de Wallbox ni de greenup).
J’avais commandé des shelly 1 et 2.5 justement pour leur ouverture. Dans mon cas, j’étais passé par un revendeur français. Son groupe facebook donne pas mal de conseil à condition d’avoir acheté les produits chez lui.
#42
Après un peu de recherche sur Domoticz, shelly et Mqtt une piste intéressante https://github.com/enesbcs/Shelly_MQTT
Et merci @David pour les reponses aux commentaires ça fait plaisir !
#43
merci pour les conseils hein :)
mais l’idée est d’attaquer directement les resistances et de remplacer la gestion eventuelle interne
j’ai quelques connaissances en elec, je pars pas à l’inconnu, je sais reconnaitre un grille-pain d’un nest
un triac seul dissipe et chauffe, faut integrer l’opto pour le piloter proprement, faire gaffe à ton design pour respecter les distances d’isolation sur ta carte … plus simple de prendre un relais statique pour controler le nombre d’alternances utiles, pas besoin de réinventer les briques de base non plus
#44
Oui j’ai cru comprendre après coup, j’ai mélangé ton message avec celui de fry, du coup ça a du lui être plus instructif qu’à toi. Désolé s’il y a eu dérangement.
#45
Il est toujours possible de créer un réseau wifi bien distinct en ayant un second routeur servant qu’à la domotique et n’ayant aucune connexion physique au net.
Par contre il n’est plus possible de piloter quoi que ce soit depuis le boulot mais c’est le prix de la tranquillité.
#46
Si tu connais la température de la pièce un simple pilotage on/off suffit, donc plutôt que de bricoler les radiateurs, j’installerais un capteur de température dans chaque pièce et gérerait un fil pilote par pièce (il ne faut jamais déséquilibrer le chauffage dans une pièce : si il y’a deux radiateurs c’est qu’il faut deux radiateurs pour chauffer)
Ensuite pour tes radiateurs tu règles la température de confort maxi à ne jamais dépasser (disons 22 / 23°), et tu pilotes selon la température de la pièce entre les ordres confort (0v), et hors-gel (115v positif).
Je ne vois pas l’intérêt de dimmer un radiateur : il se régule tout seule avec sa propre inertie.
Je ne pense pas qu’il existe encore de grille-pains des années 80: La résistance chauffe un bloc de pierre ou un liquide qui produit une chaleur douce. Et si tu as encore un grill-pain (résistant à nue ou tu brules puis gèle à longueur de journée) tu le jettes rapidement et le remplace par un radiateur électrique normal à inertie : Ça coute une centaine d’euros que tu récupéreras très rapidement sur tes factures électriques. De toute manière le convecteur devrait être le prochain interdit de cité après a chaudière à gaz cette année!
#47
XD
mais du coup s’il s’agit de remplacer la partie électronique d’un radiateur, je pense qu’il n’y a aucun besoin de jouer avec du pwm sur de la haute tension / puissance
la partie électronique régule déjà, il “suffirait” de rendre pilotable la partie “consigne” du radiateur, et ne pas toucher au reste, non ?
#48
Je te rejoins KP2, encore un bidule pas du tout sécurisé !
Ces prises gèrent quel protocole wifi ? On peut au moins utiliser du chiffrage fort WPA2 ou WPA3 ?
HTTP + mot de passe c’est criminel ! À mon sens c’est pire que rien : ça donne une sensation de sécurité totalement inexistante ! Pire le mot de passe peut facilement être retrouvé donc ça ouvre une porte supplémentaire pour ceux qui auraient l’habitude d’utiliser le même mot de passe partout.
Scénario (très probable), un nouveau voisin vient d’arriver, il ne veut pas payer internet ou le FAI met trop de temps à câbler son logement. Il décide de faire tourner un aircrack-ng (c’est une simple clé USB bootable). Au bout de quelques jours la clé wifi est découverte il peut se connecter sur ton réseau (après avoir éventuellement usurpé une adresse mac). Le trafic en clair sur le wifi lui est accessible, il voit plein de bidules envoyer régulièrement leur mot de passe en clair : Il peut alors utiliser ce mot de passe (ou sa logique de construction) sur la borne WIFI ou les PC connectés au réseau…
=> Pas besoin d’être “hackeur pro”, un simple ado qui a trouvé un tuto et recopie des lignes de commandes sans trop les comprendre peut arriver à le faire.
Dans mon scénario, les prises sont au centre du problème :
Quant à la sécurité qui consisterait à avoir un réseau wifi dédié, c’est un poil irréaliste : il faut une borne wifi dédiée (ou un modèle pro capable de gérer plusieurs réseaux), puis un routeur pour que tu puisses piloter les prises depuis le réseau classique. Sans ça il faudrait que tu changes de wifi à chaque fois que tu veux mesurer / piloter un truc !
#49
il faut arrêter un peu le délire. En pratique, avec une passphrase forte (et WPS désactivé), le WPA2-PSK n’est pas cassé.
#50
J’ai presque envie de dire que chacun est responsable de son réseau…
Pour la plupart, quel est le risque sur une livebox actuelle avec sa config par défaut ?
#51
Sinon merci David de mettre les Shelly en avant, j’en ai une tripoté (rénovation, pas possible de passer du fil partout) et j’adore ces petits modules !
Mes retours :
#52
Bonjour,
Bon article, mais il y a vraiment UN truc qui manque : L’analyse des entrailles de la prise !
On est sur inpact-hardware, on veut voir du hardware-prOn !
Car si la prise “marche bien” mais que sa mesure de puissance se fait par un petit shunt merdique conçu pour 10A, ça va cramer la baraque un jour ou l’autre. Pareil si l’alimentation basse tension se fait pas un condensateur mal adapté etc… Et on pourra voir si c’est bien un ESP8266 à l’intérieur
#53
Je suis d’accord avec le sous-titre: “presque” parfait. Le pb de la connexion au réseau local/internet me semble être à la fois un avantage et un (gros) inconvénient.
J’ai la même appréhension qd j’en ai acheté un la semaine dernière. Le bidulle est connecté à internet, et s’il le veut, il peut crawler tout internet. J’ai évidemment bloqué direct ses acces, mais ca ne me plait qu’à moitié: d’abord, les règles peuvent sauter par erreur (fausse manip) et ca ne sera pas visible (pas d’erreur)… Ensuite, c’est probablement un objet dont le firmware sera mis à jour rarement (par le fabricant, et ensuite par moi, 2 sources de lenteurs potentielles)… Enfin, le firmware est fermé, je crois, on ne sait pas ce qui se passe dedans.
Donc, je vais chercher à remplacer le firmware par une version ouverte, plus configurable (iptables, aucun service autre que le serveur web, tant pis pour ntp, il aura pas l’heure), tout en gardant la fonctionnalité de base dont j’ai besoin (c’est un relai Shelly 1pm, on/off avec mesure de conso, c.a.d il ne fait pas gd chose).
Le maitre mot est “relié à un élément relié à internet”: ils ne sont pas directement reliés à internet, donc le piratage est bien plus complexe, et si ils sont compromis, ils ne seront probablement pas utilisés dans un réseau de bots car ils ne dialoguent probablement pas sur un réseau IP. Ex: un detecteur d’ouverture de porte zwave, y a du boulot avant d’en faire un bot pilotable à distance. Un relai Shelly 1 qui va chercher l’heure sur internet au démarrage, moins.
#54
On a toujours les avantages de ses inconvénients et inversement. La centralisation dans une box domotique c’est aussi un SPOF, un appareil à gérer et qui peut tout faire tomber s’il fonctionne mal. Comme l’accès à internet ou non : si oui on peut tout gérer à distance (je rentre à la maison, j’allume mon chauffage avant de partir), si non je suis sûr de ne pas avoir de faille par ce biais.
Pour le cas des Shelly, note que tu peux couper la poire en deux en limitant tous les accès sauf des échanges via MQTT (sur un seul port identifié) et à l’IP de ton Broker distant.
#55
Je rejoint globalement les réticences de KP2.
Bon alors déjà, si vous avez un produit dont l’API est capable d’être désactivée, il y a un gros problème. Je ne vois pas une maison se mettre à ne plus fonctionner du jour au lendemain parce que Papa TP-Link a décidé qu’il mettait à jour les appareils. Rien que ça, c’est entreprise à fuir.
Je lis qu’on peut “limiter l’accès”, qu’on peut garder l’appareil sur “son propre réseau Wifi” ou pire que l’appareil peut créer lui même un réseau Wifi.
Alors tout ça, c’est bien joli mais ce genre d’appareil est sur le réseau Wifi pour une raison : c’est facile à installer. Donc à partir du moment où vous laissez les gens utiliser ce genre de produit, ils n’iront pas plus loin que de les faire rejoindre leur réseau. Si vous êtes capable de faire de la “geekerie”, le protocole Wifi n’a plus aucun sens.
Du coup, on est quand même sur NextHardware donc vous n’êtes pas sans savoir que d’une part, multiplier les appareils sur un même réseau Wifi, ça va ralentir le réseau. On appelle cela l’overcrowding et bon, si c’est juste pour faire mumuse avec une prise, pourquoi pas, mais si on parle de “domotique”, oubliez tout de suite la solution Wifi.
Je vous rappelle ensuite que bien souvent, votre réseau Wifi est en compétition permanente avec ceux des voisins, donc multiplier les réseau pour ajouter des canaux, c’est tout sauf une bonne idée, même si je vous accorde que le 2.4 devrait être de moins en moins encombré.
Bon ensuite, les protocoles domotiques qui ont “leur propres travers”. Je crois qu’il va falloir arrêter de dire n’importe quoi pour avoir raison. Vous voulez vraiment qu’on énumère les nombreux avantages de ces réseaux domotiques versus ces appareils Wifi ? Je crois qu’on va vite monter à un rapport de 1 contre 10. Surtout tant que le connected over ip et consorts ne seront pas finalisés. Et d’un point de vue purement sécurité, ce n’est pas parce que vous pouvez mettre à jour un appareil domotique en Zigbee ou Zwave qu’il a accès à internet, même indirectement. Certes, on pourrait imaginer une faille sur la box domotique qui permettrait ensuite de controler l’appareil, mais ça a le mérite d’au moins ajouter une étape.
Je lis aussi que les protocoles comme le RF433 ont également leurs propres limitations. Encore une fois, il n’y a pas que le RF433 dans la domotique d’une part, et ensuite, comparer le Wifi au RF433 c’est comme comparer une Tesla à une Lada pour faire le Electrique contre Essence.
Je rejoint par contre l’avis de David sur la “simplicité”. C’est en effet assez rageant de constament voir le marketing faire croire aux clients que tout est simpliste. Même le Philips Hue est compliqué et peut déjà devenir un vrai casse tête (les boutons physiques, les coupures de courant, l’automatisation, etc.).
Mais du coup, c’est un peu contradictoire. On sait tous ici que la domotique n’est pas un hobby accessible. Alors pourquoi promouvoir le Wifi ? Il n’y a aucun standard finalisé sur ce protocole IP (à part peut-être pour les caméras et encore). Chaque appareil à sa propre API et sa propre norme. Et ça, c’est sans compter les backdoor sur un appareil sur 2. Vous voulez vraiment d’un réseau domotique aussi bordélique ? Mettez moi 50 appareils domotisés en wifi et essayez d’en faire quelque chose, on en reparle. Heureusement qu’il y a au moins MQTT pour rattraper tout ça.
Alors en effet, les choix regardent chacun mais on est ici pour donner les bons avis. Donc en résumé, si vous voulez faire de la domotique durable dans votre maison, oubliez définitivement le Wifi. Si par contre vous voulez faire mumuse avec 2-3 machins et 2-3 apis, alors ouais pourquoi pas.
#56
Dans un réseau Wifi, un appareil à, a minima, besoin de sa box pour communiquer. Dans un réseau Zigbee (ou Zwave), ce n’est pas le cas. Un bouton peut allumer une lumière directement, même si la box est hors-service. Certes c’est un état dégradé, mais c’est toujours mieux qu’avec du Wifi.
Pour le second point, effectivement, si on peut au moins utiliser MQTT, ça a l’avantage de ne pas avoir à apprendre à utiliser une api propriétaire.
#57
L’erreur c’est de penser qu’il y a le bien et le mal, la bonne et la mauvaise solution. Comme tu dis : les commentaires sont là pour échanger, donner son avis, pas tenter de l’imposer comme une règle à suivre.
Il y a une offre diverse, des besoins divers, des utilisateurs qui font des choix. Ils doivent juste le faire de manière éclairé. Comme évoqué plus haut, le Wi-Fi dans la domotique a ses défauts, qui tiennent souvent à la conception même des produits (plus qu’au protocole lui même). C’est le cas des autres protocoles de communication, fussent-ils spécialisés dans la domotique.
On peut les juger plus ou moins importants selon ses besoins. Certains ne veulent pas d’une box domotique centrale, d’autres veulent une large couverture, parfois c’est la faible consommation (et l’absence de pile) qui prime. Selon ces points on fera des choix différents. En général on a même une diversité de solutions au sein d’une même installation.
Non, ou alors je ne suis pas sûr de comprendre.
Note que c’est tout sauf le fonctionnement courant de ces systèmes.
MQTT c’est un protocole de transport de message, comme pour une API REST via HTTP(S), il y a des règles à respecter pour communiquer avec un appareil par ce biais (Topics, messages, etc.).
#58
Ca change tout, la box domotique fait une rupture protocolaire entre la prise et le monde extérieur. Le constructeur de la prise ne pourra pas y accéder via la box domotique.
#59
Oui et non, tu as une chaine d’appareils qui peuvent échanger des données (dans les deux sens) avec Internet au bout. C’est pas pour rien que l’on peut mettre à jour ces produits. Pour ce qui est de la rupture, comme dit, elle dépend des choix de l’utilisateur plus que du protocole de communication visé. Une fois de plus, je ne dis pas que le Wi-Fi ne favorise pas l’accès à Internet, juste que penser “protocole purement domotique = je suis préservé by design” c’est une erreur.
#60
C’est la confiance que tu apportes à ton objet connecté.
Par exemple les aspirateurs Roomba ont une connexion permanente à AWS (je suppose que iRobot héberge ses infras chez Amazon) pour pouvoir recevoir les notifications de l’utilisateur via l’application mobile.
Maintenant si le constructeur est malveillant (ce qui, je suppose actuellement, n’est pas le cas d’iRobot), ils ont un accès permanent à ton réseau LAN et peuvent scanner/découvrir/analyser etc etc.
Bref, tout repose dans la réputation du constructeur de ton objet (et accessoirement dans sa capacité à ne pas laisser découvrir ses iot par des moteurs comme shodan et corriger rapidement toute faille qui pourrait apparaitre)
#61
Je parlais dans le cas ou l’on interdit par le pare-feu l’accès à internet aux objets connectés (type la prise) et ou seul l’accès de la box domotique à internet est autorisé. (ainsi que l’ensemble de l’écosystème box + iot n’est pas du même constructeur (box jeedom à l’opposé du pont Hue par exemple)
Je te rejoins complètement sur le :
#62
Oui, c’est de cela dont il est question. La simplicité apparente de ces objets connectés wifi versus la complexité de la mise en place d’une solution (un minimum) sécurisée.
Tu parles de limiter l’acces a internet ou au réseau local interne (sans t) ?
Pour le premier, je suis d’accord, en limitant ses acces a un seul ip/port/service, on limite les risques d’acces externes non voulus.
Pour le second, je pensais plutot limiter les acces du Shelly au reseau local tout court, car je ne sais pas ce que fait le firmware de ces petites bêtes. Et s’il n’a pas acces au réseau local hors MQTT (par ex), alors il n’a pas acces non plus a internet.
Quoiqu’il en soit, je n’aime pas etre obligé de bidouiller un firewall. Une fausse manip, et hop, une règle disparait, le shelly a acces à internet. Cette erreur est quasi invisible (pour moi).
Ok, tout ca, c’est un brin parano, mais si on veut aller au bout, il n’y a qu’une conclusion: c’est compliqué à mettre en oeuvre alors que la promesse implicite de départ (la connectivité wifi) est de tout simplifier. C’est un vrai boulot. (conclusion #2: j’ai besoin d’un IT temps plein pour chez moi :p).
#63
Non, ça c’est ne prendre qu’une part des contraintes en compte. Parce que ce n’est pas parce qu’un truc est chiant à gérer qu’il est sécurisé. Ce n’est pas parce qu’il est pratique que c’est une passoire.
Comme dit, il y a un choix à faire de base : est-ce que je veux une gestion distante ou non. Si non, c’est simple : on isole, c’est réglé. Si oui, il faut se demander où est notre sweet spot personnel dans le rapport entre la complexité de configuration du réseau et ce dont on veut se prémunir. Partant de là, il y a différentes solutions, plus ou moins complexes.
Mais par exemple on peut imaginer ouvrir un accès à un service spécifique, que l’on maitrise (OSS, développé maison, confiance, ou autre), qui lui accèdera localement (via une API REST, MQTT, etc.) à des éléments du réseau sans accès au net (parce que bridé d’une manière ou d’une autre).
Cela revient à une segmentation similaire à une box domotique, mais c’est un choix et surtout on en maitrise les différents aspects.
C’est le genre de chose que l’on peut monitorer, dans tous les cas, un appareil communicant est toujours suceptible de communiquer sans qu’on le sache. D’où l’importance du ceinture/bretelle évoqué plus haut.
Le Wi-Fi c’est surtout une simplicité quand on veut de l’accès local/distant sans intermédiaire ou presque. Si la priorité c’est un produit purement local sans trop de maintenance, on prendra plutôt du Homekit Bluetooth (sous réserve de faire confiance à Apple bien entendu
)
#64
Pour le coup je vais rejoindre David car ici ces prises sont en mode AP par défaut et l’on peux connecter d’autres prise sur l’AP d’une des prises fait toute la différence.
Donc on peux avoir tout son réseau de prise sur un wifi complètement séparé du reste et si on a besoin de connecter sur internet mettre une passerelle entre ce réseau wifi et internet reviens exactement au même que si c’était du zwave zigbee ou autre protocole domotique car le pont réseau objet connectés - internet est fait par une passerelle / box domotique.
Pour contrôler les prises sans passerelle, il suffit sinon de basculer sur le réseau wifi séparé et c’est bon. L’avantage d’utiliser le wifi c’est que il y a un seul standard contrairement aux objets connectés où il y en a plusieurs zwave, zigbee, io (somfy) ce qui fait que l’on en viens à choisir un protocole pour tous ces objets.
En fait je pense que d’avoir un routeur wifi pour les objets connectés et un autre routeur wifi pour les smartphones/tablettes/pc de la maison est assez sain car du coup on peux contrôler finement ce que les objets connecté peuvent faire. Cela reviens à avoir une box domotique mais du coup je ne sais pas s’il existe des box qui font tous les protocoles domotiques.
#65
Il serait possible d’avoir des indications sur comment monitorer ces appareils connecté au réseau ?
C’est quelque chose que je me suis plusieurs fois demandé, sans vraiment trouvé comment faire facilement, et donc j’ai laissé tombé. Mais j’aimerai bien pouvoir être certain que certains appareil son “silencieux”, ou être averti si ce n’est pas le cas.
#66
C’est prévu dans de prochains articles, on en reparlera à ce moment là
#67
Tu as la Homey mais c’est plutôt l’exception. En général il faut choisir « son camp » ou accepter l’usine à gaz 😬
#68
ntopNG sur parefeu pfsense par exemple te permet de voir sous forme graphique et de listing les flux entre tes interfaces monitorés. (ntopng fonctionne également seul sur raspberry + un dongle rj45 usb pour faire la second interface)
Ca représente un peu de travail pour comprendre ce que l’on fait mais en informatique, rien n’est ‘gratuit’ (d’un point de vue intellectuel)
Sinon les softs cités ci dessus sont gratuits (juste le hardware à monter / acheter, un pc basse consommation avec 2 ports ethernet suffit)
#69
yep le coup de l’AP d’une des prises pour servir de réseau auquel se connecter pour les autres c’est ce que j’évoquais plus tôt.
et pour faire passerelle on pourrait très bien imaginer un raspberry, relié en ethernet à la box, et en wifi aux prises
il pourrait héberger un petit serveur web pour aller taper ensuite sur le mqtt des prises.
c’est un poil plus compliqué à mettre en place (encore que), mais les 2 réseaux sont super isolés
#70
Perso, j’utilise le fil pilote avec une température de consigne supérieure de 1°C à la T°C que je veux dans la pièce et je laisse le plugin thermostat de Jeedom se débrouiller. Ça donne d’excellents résultats pour ma part.
Perso, je jouerais pas trop avec l’alimentation de radiateurs électrique… c’est quand même des machins qui peuvent foutre le feu chez toi…
#71
Ce n’était pas le sens de ma question. C’était destinée à fofo9012 qui assure qu’à coup de aircrack-ng on rentre sur ton wifi comme dans du beurre.
#72
Merci pour cet article super intéressante cette petite prise. Elle me parait plus convainquant que la TP-Link finalement avec son API officiel et les coté cloud désactivé par défaut.
En revanche en lisant l’article et surtout les commentaires, je suis un peu sceptique sur les risques que représente ces prises d’un point de vus électrique (avant même la connectivité à internet). Que ce passe-t-il en cas de surcharge ? 12A ça convient probablement à la consommation de 90% des prises d’une maison, mais j’imagine assez bien un scénario : une personne installe une multiprise sur cette prise pour éteindre d’un coup tous les multimédia du salon puis un jour rajoute l’aspirateur dessus pour faire le ménage quand une autre et en pleine partie sur la console
.
Selon moi le risque que le prise crame et plus facile à reproduire que quelqu’un qui se verrais installer un botnet sur ladite prise. D’autant plus que cette question est réglée depuis 2009 puisque tout français souscrivant un abonnement internet se doit d’être admin réseau
#73
Jeedom.
#74
Mais oui, on peut faire potentiellement un serveur sur base JeeDom qui gère de nombreux protocole via autant de clés USB pour les gérer.
#75
J’adore ce genre de commentaires. Quand tu n’es pas initie tu te dis “kwaaaa???” apres lecture
J’ai pas encore mis le doigt dans la domotique mais ca commence a m’interesser beaucoup !!
Avec tous ces articles je sens que je vais ceder !
#76
Ca ne serait pas possible de brancher le second routeur et de mettre son access a internet en pause via l’appli ou la page du premier ?
Comme ca en cas d’urgence on pourrait retablir un access internet a la domotique pour piloter de l’exterieur ? et aussi recuperer des MAJ s’il y en a de temps en temps.
#77
j’imagine que la prise coupe si tu dépasses la puissance max donc aucun risques.
#78
Les box Jeedom supportent les protocoles supplémentaires comme le Jeedom diy. Bien sûr il faut acheter le dongle en plus comme pour les box Tahoma, Fibaro, etc …
#79
C’est presque le prix d’un wattmètre, et justement j’aimerai bien en avoir un. Est-ce que les mesures sont fiables sur ce produit ? Marge d’erreur de combien ?
C’est la seule utilité que j’en aurai. Le côté Wifi fait que c’est pratique selon là où ça serait branché à l’inverse des modèles à écran, et le côté serveur web me rassure pour éviter l’obsolescence d’un logiciel smartphone contrairement à d’autres modèles.
#80
Capture tcpdump sur ta gateway, et si c’est du HTTPS, il faut que tu y mettes un proxy. En général, les box opérateur ne font pas ce genre de truc donc tu installes un système (par ex, sur un raspberry) que tu mets sur le chemin de sortie de ton réseau et que tu routes vers la box (il faut une seconde interface réseau, éventuellement virtuelle, à ton proxy).
@trou
Pour savoir ce que consomme la shelly plug S, super simple : tu en achètes 2 et tu branches la première sur la seconde
Je sais pas si j’oserais (une prise qui passe 2000 ou 2500W pendant dix heures d’affilée a intérêt à être de très bonne qualité).
#81
#82
Pourquoi deux routeurs?
), LAN qui va se faire foutre quand on le souhaite (LAN2).
Si on considère 3 zones sur ton routeur: Accès internet (WAN) , LAN (LAN
Tu fais une règles “DROP LAN -> WAN” en priorité 0. Tu actives la règle? Plus de net pour LAN2. Tu la désactives, LAN2 a le net à nouveau.
En plus, ça te permet facilement de contrôler les fluxs entre LAN2 & LAN.
Le tout pour le prix d’un routeur normal parce que c’est le travail de tout routeur pare-feu
Facilement, ça n’existe pas.
Pour le faire, il faut que tu renvoies les logs de ton routeur (par SNMP ou autre) à un estomac qui va emmagasiner et réagir sur des conditions. En soit, ce n’est pas insurmontable, mais ce n’est pas simple non plus :) Le meilleur moyen d’être sûr qu’ils se taisent n’est pas de les écouter mais de leur couper la langue
#83
Ouais et encore, j’en ai une de Homey. Elle est dans un placard. Homey c’est juste une bonne idée mais en pratique, c’est assez catastrophique. A moins de se sentir capable de développer soit même les plugins de la box.
#84
Tu veux dire quoi par là ?
Tu iras dire ça aux FAI
#85
Bon, pour ceux qui se demandaient : oui c’est bien un ESP8266 à l’intérieur :
https://faulty.cloud/blog/shelly-plug-s-pinout
Mais j’aurais aimé voir plus en détail les composants de puissance. La référence du relais par exemple
#86
Je parlais pas des services qui fournissent un routeur castré, je parle de si tu achetais un routeur parefeu :P
Les FAIs sont des enculés sur leur équipement, on le sait tous… Et rien que le fait qu’on soit presque obligé de faire du double NAT pour être sûr que ça fonctionne avec tout FAI est une honte.
Bref, fin du HS :p
#87
La maison est neuve, tout est cablé en 2.5mm2, proche du compteur. La prise est une Legrand, elle supporte 3500W, elle encaisse facilement 2300W.
J’ai une prise greenup à installer pour une charge a 3200W. C’est une autre histoire, je dois tirer du 6mm2, ajouter un élément au tableau, la prise a des contacts renforcés pour une puissance théorique gérée par la prise de base.
#88
Sinon, il y a aussi les prises sonoff, hackables, avec des firmware sympa.
#89