Deux stores, de l'AES et six relais plus tard…

Domotisation de stores MaDeco, ou quand les choses peuvent parfois déraper très (trop ?) loin

Il y a des projets qui commencent par un besoin parfaitement identifié.

Et puis il y a ceux qui commencent par : « Tiens… ce serait quand même sympa. »

Celui-ci appartient clairement à la seconde catégorie.

À la maison, nous avons deux stores MaDeco motorisés sur batterie. Ils doivent avoir sept ou huit ans, fonctionnent toujours parfaitement et sont commandés par radio. À l'époque, chaque store avait été livré avec sa télécommande monocanal, et nous avions ensuite acheté une télécommande multicanal pour piloter les deux depuis un seul appareil.

Bref, tout fonctionnait. Il n'y avait absolument aucun problème à résoudre.

Mais j'étais en pleine phase d'intégration d'un maximum d'équipements dans Home Assistant, et forcément, mon regard a fini par se poser sur ces deux stores.

Et si Home Assistant pouvait également les commander ? Cela permettrait par exemple de les ouvrir ou les fermer automatiquement en fonction de la luminosité extérieure.

Rien de vital. Mais ce serait fun.

---

99 € ? Pour ça ?

Je me souvenais vaguement que MaDeco proposait une solution pour connecter ses stores. Quelques recherches plus tard, je retrouve effectivement une petite passerelle USB/Wi-Fi. Prix : 99 € — et c'est toujours son prix au moment où j'écris ces lignes.

Soyons clairs : je ne prétends pas que 99 € constitue objectivement un mauvais prix. Pour quelqu'un qui souhaite simplement connecter ses stores, brancher une passerelle, effectuer quelques opérations d'appairage et passer à autre chose, la solution peut parfaitement avoir du sens.

Le problème est ailleurs. Quand j'ai une idée relativement précise de ce qui peut se trouver dans un appareil, j'ai énormément de mal à ne pas commencer à le décomposer mentalement. Une petite électronique, un contrôleur, une interface RF, du Wi-Fi, un boîtier, du firmware... et mon cerveau commence immédiatement à faire ses propres calculs. D'autant qu'une télécommande de remplacement coûtait une vingtaine d'euros.

99 € pour connecter deux vieux stores ? Ça me paraissait beaucoup. Je devais certainement pouvoir faire autrement.

RF 433 MHz. Ça va être simple.

Premier réflexe : regarder les télécommandes d'un peu plus près. Je retourne l'une d'elles.

RF 433 MHz. Parfait.

Le 433 MHz est utilisé par une quantité invraisemblable de télécommandes et de petits équipements domestiques, et les modules permettant de recevoir ou d'émettre dans cette bande ne coûtent que quelques euros. Dans ma candeur infinie, le plan me paraît donc assez évident : capturer le signal, le reproduire, le piloter depuis Home Assistant. Ça ne devait pas être bien sorcier.

Mes premières recherches m'amènent rapidement au Broadlink RM4 Pro, capable d'apprendre et de reproduire différents signaux infrarouges et RF. Et ça tombe plutôt bien : j'ai également plusieurs télécommandes infrarouges que j'aimerais intégrer à Home Assistant. Même si l'expérience avec les stores ne fonctionne pas, le Broadlink ne sera donc pas perdu.

Je le commande sans beaucoup hésiter. Il arrive. Je lance l'apprentissage de la télécommande MaDeco.

Rien. Je recommence. Toujours rien.

Bon. Apparemment, « RF 433 MHz » n'était pas encore la réponse complète.

Très bien. Regardons ce qu'elle raconte.

À ce stade, la télécommande commence surtout à piquer ma curiosité. Je partais du principe qu'un store motorisé vieux de plusieurs années devait utiliser quelque chose de relativement basique. Puisque le Broadlink ne parvenait pas à apprendre le signal, j'allais donc essayer de le récupérer moi-même.

Je monte un ESP32 NodeMCU-32S avec un CC1101, embarque le tout dans ESPHome et commence à tester différentes bibliothèques disponibles. Il existe énormément de projets autour du 433 MHz : quelqu'un avait forcément déjà rencontré mon problème.

C'est également à ce moment que mes recherches commencent régulièrement à faire apparaître un nom : Dooya. Plusieurs éléments semblent indiquer que mes télécommandes pourraient être apparentées à des modèles ou protocoles utilisés par ce fabricant, et je commence effectivement à récupérer des portions de trames avec le CC1101.

Bonne nouvelle : il y a quelque chose. Moins bonne nouvelle : ce quelque chose ne correspond à aucun des protocoles reconnus par les bibliothèques que je teste.

Dans le doute, j'essaie tout de même de forcer l'émission d'un protocole Dooya existant. Je place un store en mode appairage, j'envoie la séquence.

Rien.

Ce ne serait donc pas du Dooya ? Ou, autre possibilité, « Dooya » ne désigne pas un seul et unique protocole. En approfondissant les recherches, je découvre effectivement différentes variantes, et un terme commence à apparaître de plus en plus souvent : rolling code.

Pour un store. Ça commence à faire beaucoup de sécurité pour faire monter et descendre un morceau de tissu.

Le rolling code n'explique pas tout

J'avais cependant déjà quelques informations intéressantes sur le fonctionnement de mes télécommandes. Tout indiquait une communication essentiellement unidirectionnelle entre celles-ci et les stores. Chaque télécommande possède également sa propre identité, et l'ajout d'une nouvelle télécommande nécessite une procédure d'appairage : le store doit être placé dans un mode particulier avant qu'une séquence soit envoyée depuis la télécommande à enregistrer.

Le principe général d'un rolling code ne me semblait donc pas particulièrement mystérieux : une télécommande possède une identité, transmet une information qui évolue à chaque commande, et le récepteur maintient une fenêtre permettant d'accepter les nouveaux codes tout en refusant le simple rejeu d'une ancienne transmission.

En théorie, puisque la télécommande ne semble rien recevoir du store, tout ce dont j'ai besoin doit nécessairement se trouver dans ce qu'elle émet. Encore faut-il parvenir à l'observer correctement.

Mes premières captures commencent d'ailleurs à montrer quelque chose d'intéressant : une partie du signal paraît stable tandis qu'une autre évolue. Cela colle plutôt bien avec mon hypothèse. Sauf qu'il semble y avoir autre chose — et que cet autre chose est nettement moins évident à expliquer.

Il va falloir sortir l'artillerie

Pour comprendre réellement ce qui se passe, il faut maintenant observer le signal avec un peu plus de finesse. Je ne vais évidemment pas acheter un analyseur de spectre pour deux stores. En revanche, mes recherches me ramènent vers un domaine que j'avais vaguement étudié pendant mes études et jamais vraiment eu l'occasion d'explorer depuis : la radio logicielle, ou SDR — Software Defined Radio.

Pour quelques dizaines d'euros, une petite clé USB permet aujourd'hui d'entrer dans un univers qui nécessitait autrefois du matériel autrement plus spécialisé. La perspective devient presque aussi intéressante que les stores eux-mêmes.

Je commande donc une clé SDR. Quelques jours plus tôt, je voulais simplement ouvrir et fermer deux stores depuis Home Assistant. Me voilà maintenant en train de dépoussiérer de vieux souvenirs de radio.

Tout va bien.

Le rabbit hole SDR

Je ne vais pas détailler ici tous les logiciels, réglages et essais réalisés pendant cette phase. À ce moment du projet, je me suis retrouvé entraîné dans une sorte de spirale où se mélangeaient deux objectifs : récupérer correctement les trames de ma télécommande, et redécouvrir un univers radio beaucoup plus vaste que prévu.

Parmi les outils qui m'ont réellement été utiles, Universal Radio Hacker (URH) a occupé une place centrale pour l'analyse, accompagné notamment de rtl_433 et SDR++ pour différentes expériences de réception et de capture.

Mais avant même de comprendre ce que racontait ma télécommande, encore fallait-il parvenir à l'entendre correctement — et c'est là que j'ai découvert à quel point mon environnement RF était encombré. Une partie non négligeable du travail a consisté à obtenir des captures suffisamment propres pour distinguer ce que je cherchais du reste : distances, positionnement, réglages, réduction des perturbations... J'ai même improvisé quelques pseudo-cages de Faraday.

À ce stade, rappelons tout de même l'objectif initial : ouvrir et fermer deux vieux stores. Depuis Home Assistant. Parce que ce serait fun.

Enfin des trames qui commencent à parler

Tout ce travail finit néanmoins par payer. J'obtiens des captures relativement stables et suffisamment propres pour commencer à comparer plusieurs émissions. Une partie des trames est parfaitement reproductible ; une autre change. Le rolling code revient évidemment immédiatement à l'esprit — mais mes captures continuent d'indiquer qu'il y a quelque chose de plus.

À ce stade, Dooya apparaît de plus en plus souvent dans mes recherches, sans que je puisse réellement confirmer que mes télécommandes MaDeco proviennent de cet écosystème. J'ai des indices. Pas de preuve. Et surtout, je continue à observer la télécommande comme une boîte noire.

Il est peut-être temps de changer de méthode.

---

BREAK — Ouvrons la boîte noire

Heureusement, j'ai un cobaye. Puisque nous utilisons depuis longtemps la télécommande multicanal pour commander les deux stores, les deux télécommandes monocanal d'origine sont devenues largement dispensables. Je peux donc en sacrifier une à la curiosité scientifique.

Tournevis. Voyons ce qu'il y a réellement là-dedans.

Le PCB apporte rapidement de nouveaux indices. On y trouve notamment des références comme DD251 V1.0 et NO. DA327, qui renforcent encore la piste que je suis depuis un moment.

En poursuivant l'inspection et les recherches sur les composants, un petit circuit intégré attire surtout mon attention. Le cœur de la télécommande semble être un Silicon Labs Si4010.

Et là, les choses deviennent nettement plus intéressantes.

Ah. AES.

Le Si4010 n'est pas simplement un petit émetteur 433 MHz. C'est un SoC RF programmable intégrant notamment un cœur 8051, de la mémoire, un émetteur RF capable d'OOK/FSK, un identifiant unique et surtout un accélérateur matériel AES-128. Silicon Labs propose même des designs de référence utilisant le Si4010 pour réaliser des liaisons radio unidirectionnelles sécurisées par AES.

Tout commence soudainement à s'emboîter : une partie stable, une identité d'émetteur, un compteur évolutif, un rolling code — et une partie dont les variations étaient beaucoup plus difficiles à expliquer. Du chiffrement AES devenait une hypothèse extrêmement crédible.

Le problème est que comprendre pourquoi quelque chose ne fonctionne pas ne signifie pas nécessairement savoir le reproduire. En fait, je venais surtout de comprendre pourquoi ce n'était pas aussi simple que prévu.

Deux pistes

À ce stade, deux possibilités se dessinent.

1. Générer moi-même les trames

La structure générale commence à être relativement claire. Si une partie de la trame est effectivement chiffrée en AES, il « suffirait » en théorie de connaître la clé utilisée, de maintenir correctement le compteur et de générer des trames valides.

Les guillemets autour de « suffirait » commencent évidemment à prendre une certaine importance.

Mais la clé doit bien se trouver quelque part. Et si le Si4010 effectue le chiffrement, elle doit nécessairement être disponible pour son firmware. Pourquoi ne pas simplement la récupérer sur le composant ?

Parce que Silicon Labs avait manifestement prévu que quelqu'un puisse avoir cette idée. Le Si4010 dispose de mécanismes permettant de protéger son contenu programmé et de verrouiller l'accès en lecture. La voie simple consistant à connecter quelques fils et à récupérer tranquillement le firmware et ses secrets n'était donc pas disponible sur ma télécommande.

On pourrait évidemment commencer à imaginer des techniques d'attaque matérielle beaucoup plus invasives. Mais même selon mes critères, il existe une limite à ce qu'il est raisonnable d'entreprendre pour deux stores.

Enfin, normalement.

2. Utiliser directement une passerelle Dooya

L'autre piste est beaucoup plus pragmatique. Au fil de mes recherches, je rencontre de plus en plus de témoignages laissant penser que Dooya fournit sa technologie à différents fabricants, et que certains équipements commercialisés sous d'autres marques peuvent être commandés avec des télécommandes ou passerelles de cet écosystème.

Si mes stores sont effectivement basés sur cette technologie, pourquoi essayer de fabriquer une passerelle Dooya ? Dooya en fabrique déjà. Excellent. Il suffit d'en commander une.

Enfin… il existait effectivement plusieurs hubs et passerelles, mais les modèles qui m'intéressaient semblaient devenus particulièrement difficiles, voire impossibles, à trouver. Je découvre également des clés USB commercialisées sous d'autres marques qui ressemblent furieusement à la solution MaDeco. La tentation d'en acheter une devient forte, ne serait-ce que pour boucler la boucle.

Mais après tout ce chemin, acheter finalement une autre version de cette clé aurait eu un petit goût d'aveu d'échec. Et une idée que j'avais écartée très tôt dans le projet me revient alors en tête.

Et si j'arrêtais d'essayer de remplacer la télécommande ?

Mes deux télécommandes monocanal, dont je ne me sers plus, sont compatibles avec mes stores. Elles connaissent leur protocole. Elles savent gérer leur identité et maintenir leur rolling code. Elles disposent de la clé AES, quelle qu'elle soit. Et surtout : elles fonctionnent.

Pourquoi continuer à essayer de reproduire tout cela ? Un ESP32 n'a finalement pas besoin de savoir parler au store. Il lui suffit de savoir appuyer sur les boutons de la télécommande.

Après des semaines à explorer la radio, le protocole et le chiffrement, la solution commence soudainement à devenir ridiculement simple. Chaque télécommande possède trois boutons — montée, stop, descente — soit trois contacts à simuler.

Je sors le multimètre. Trois boutons, une ligne commune. Quatre petites soudures par télécommande, plus l'alimentation.

Facile. Évidemment.

J'ai peut-être voulu faire trop bien

Un détail m'intrigue cependant. La ligne commune aux trois boutons, que j'avais spontanément envie de considérer comme une masse, ne semble pas directement reliée au négatif de l'alimentation. Ça me paraît un peu louche — mais je décide néanmoins de partir sur une solution à transistors NPN pour simuler les appuis.

Sur le papier, le montage me plaît bien : quelques résistances, trois transistors par télécommande, des GPIO depuis l'ESP32. Compact, propre, élégant.

Je réalise le montage. Je lance les tests. Et ça fonctionne. Enfin… parfois. Les commandes sont instables et le comportement suffisamment erratique pour qu'il soit évident que quelque chose ne va pas.

Pour piloter mes NPN, j'avais fini par référencer mon montage sur ce fameux commun des boutons. Le multimètre m'avait pourtant prévenu : ce n'était manifestement pas une bonne idée. Rien de dramatique — les télécommandes fonctionnent toujours, et je n'ai sacrifié que quelques transistors et résistances à l'expérience.

Mais il faut revenir au problème de base. J'ai un contact normalement ouvert. Je veux pouvoir le fermer électriquement sans imposer de référence commune entre les deux circuits.

Il existe un composant extrêmement sophistiqué pour cela. Un relais.

Six relais

Oui. Après du SDR, de l'analyse RF, du rolling code, de l'AES, un Si4010 et quelques transistors… j'allais utiliser des relais pour piloter mes télécommandes qui allaient piloter mes stores.

Nous en étions là.

Il m'en fallait six : trois boutons pour chacune des deux télécommandes. Je voulais malgré tout conserver un montage relativement compact, et je trouve de petites cartes comportant quatre relais 5 V, suffisamment compactes pour être facilement intégrées avec l'ESP32.

Deux cartes. Six relais utilisés. Quelques soudures. Un petit build ESPHome.

Et ça marche. Tout simplement.

À toutes fins utiles, voici le YAML pour ESPHome Builder :

esphome:
  name: store-salon

esp32:
  board: esp32dev
  framework:
    type: arduino

# Connexion à Home Assistant (auto-découverte)
api:
  encryption:
    key: ****************************************************
ota:
  - platform: esphome
    password: ***********************************************
    
wifi:
  ssid: "WIFI_SSID"
  password: WIFI_PASSWORD

# Interface web de test, accessible via l'IP de l'ESP32
web_server:
  port: 80

logger:
  level: DEBUG

output:
  - platform: gpio
    pin: GPIO23
    id: sortie_stop_1
    inverted: true
  - platform: gpio
    pin: GPIO5
    id: sortie_monter_1
    inverted: true
  - platform: gpio
    pin: GPIO22
    id: sortie_descendre_1
    inverted: true
  - platform: gpio
    pin: GPIO18
    id: sortie_stop_2
    inverted: true
  - platform: gpio
    pin: GPIO19
    id: sortie_monter_2
    inverted: true
  - platform: gpio
    pin: GPIO21
    id: sortie_descendre_2
    inverted: true

cover:
  - platform: template
    name: "Store Salon Droite"
    open_action:
      - output.turn_on: sortie_monter_1
      - delay: 400ms
      - output.turn_off: sortie_monter_1
    close_action:
      - output.turn_on: sortie_descendre_1
      - delay: 400ms
      - output.turn_off: sortie_descendre_1
    stop_action:
      - output.turn_on: sortie_stop_1
      - delay: 400ms
      - output.turn_off: sortie_stop_1
    has_position: false
    optimistic: true
  - platform: template
    name: "Store Salon Gauche"
    open_action:
      - output.turn_on: sortie_monter_2
      - delay: 400ms
      - output.turn_off: sortie_monter_2
    close_action:
      - output.turn_on: sortie_descendre_2
      - delay: 400ms
      - output.turn_off: sortie_descendre_2
    stop_action:
      - output.turn_on: sortie_stop_2
      - delay: 400ms
      - output.turn_off: sortie_stop_2
    has_position: false
    optimistic: true

Le système final peut difficilement être plus explicite :

Home Assistant → ESPHome → ESP32 → relais → télécommandes MaDeco → RF → stores

Home Assistant conserve l'état des stores en mode optimistic. Il n'y a pas de retour réel de position provenant de ces anciens stores : l'état affiché correspond donc à ce que Home Assistant leur a demandé de faire. Pour mon usage, c'est largement suffisant — et surtout, les stores peuvent maintenant participer aux automatisations de la maison.

Objectif atteint.

Un mois plus tard

Au moment où j'écris cet article, le montage fonctionne depuis environ un mois sans le moindre problème. Les télécommandes sont désormais alimentées directement par le montage : plus de piles à remplacer. La portée RF est excellente et me permet de cacher l'ensemble pratiquement où je veux, sans devoir me préoccuper de sa position par rapport aux stores.

Et la meilleure indication de sa fiabilité est probablement celle-ci : je l'ai oublié. Il fait partie de ces montages qu'on installe dans un coin et auxquels on ne pense plus, parce qu'ils font simplement leur travail.

Il ne me reste plus qu'à imprimer un vrai boîtier pour remplacer la très élégante boîte en plastique qui accueille actuellement le prototype. Rien de techniquement compliqué — je n'en ai simplement pas encore trouvé le temps.

Entre-temps, j'ai eu une autre drôle d'idée : créer un site web pour raconter ce genre de projets.

Vous êtes dessus.

Et les fameux 99 € ?

La question est évidemment tentante. Est-ce que tout cela m'a permis d'économiser les 99 € de la passerelle ?

Probablement pas. Si je rassemble tout le matériel acheté pendant l'aventure, j'ai vraisemblablement dépensé une somme comparable, voire légèrement supérieure.

Mais cette comparaison n'a finalement pas beaucoup de sens. Le Broadlink n'a pas été acheté uniquement pour les stores et me permet de piloter d'autres équipements infrarouges. La clé SDR est devenue un véritable outil d'expérimentation. Les ESP32, CC1101 et autres composants peuvent être réutilisés dans quantité d'autres projets. Et quelques transistors ont donné leur corps à la science.

Surtout, les 99 € auraient acheté une passerelle. Le détour m'aura fait toucher au 433 MHz, au CC1101, au SDR, à l'analyse de signaux, à URH, aux rolling codes, à l'AES, au Si4010 et à ESPHome, tout en approfondissant quelques notions d'électronique. Il m'aura également permis de revenir vers un domaine que je n'avais plus vraiment exploré depuis mes études.

Vu sous cet angle, le calcul devient beaucoup moins évident.

Quelqu'un d'autre aurait acheté la clé à 99 €, connecté ses stores en quelques minutes et consacré les semaines suivantes à quelque chose de totalement différent. Et il aurait parfaitement eu raison.

Moi, j'ai fait autrement. Et je ne pense pas avoir eu tort non plus. Nous ne cherchions simplement pas exactement la même chose.

Comprendre, apprendre, reproduire

Avec le recul, ce projet résume assez bien l'un de mes moteurs lorsque je bricole quelque chose : comprendre, apprendre et, dans la mesure du possible, reproduire.

Ce n'est certainement pas toujours la manière la plus rapide d'arriver au résultat. Mais le résultat n'est souvent qu'une partie de ce que je cherchais. Si mon seul objectif avait été d'avoir deux stores dans Home Assistant, acheter une passerelle aurait probablement été la décision la plus rationnelle. Mais dès que le Broadlink a refusé de reconnaître cette télécommande, le problème lui-même est devenu intéressant.

Et quelques semaines plus tard, mes stores étaient effectivement dans Home Assistant. Grâce à six relais.

Ce n'est pas la solution techniquement sophistiquée que j'imaginais au milieu de mes investigations. C'est même probablement la plus primitive de toutes celles que j'ai envisagées.

Mais elle est simple. Elle est robuste. Elle fonctionne. Et après un mois, je n'y pense déjà plus.

Difficile de demander beaucoup mieux à un système domotique.

Dossier classé ?

Oui. Enfin… il reste cette fichue clé AES.

Quelque part dans cette histoire se trouve toujours l'information qui me manque pour générer moi-même des trames valides et supprimer complètement les télécommandes de l'équation. Aujourd'hui, aller la chercher demanderait un investissement en temps et en moyens totalement disproportionné.

Même selon mes critères.

Alors les relais vont rester.

Mais si, un jour, cette clé — ou suffisamment d'informations permettant de reproduire complètement le protocole — venait à apparaître quelque part…

Je ne garantis absolument pas que ce dossier resterait classé.