Interrupteurs domotique Blyss de castorama

Salut tout le monde :slight_smile:

Je voudrai savoir si il y a sur le forum des personnes intéressaient pour renverser le protocole des interrupteurs domotique de la marque "Blyss" (de castorama) ?
J'ai commencé de mon côté à regarder la chose mais j'ai quelques difficultés ...

EDIT: Derniére ligne droite ! Tout ou presque a été décodé !
-> Interrupteurs domotique Blyss de castorama - #178 by skywodd - Français - Arduino Forum

--

Après une analyse sommaire du hardware j'ai pu déduire que :

  • les interrupteurs travaillent sur une fréquences de 433MHz en modulation ASK
    --> Ils peuvent donc (je pense) être lu / émulé avec un bête module 433MHz du commerce (?)
  • Les parties émettrice et réceptrice sont constitué d'un microcontrôleurs "SONIC SN8P2501BSG"
    --> J'ai pu trouver un datasheet ici mais il n'as pas était d'une grande aide.
  • les modules émetteurs possèdent chacun une adresse (unique ?) qui semble être fixé en usine.
  • les modules récepteur possèdent une EEPROM I2C 24C02 (256 octets)
    --> Les adresses des émetteurs appareillé avec le récepteur doivent ce trouvé dedans.

Par la suite avec mon Open Logic Sniffer (fraichement sorti de son carton) j'ai pu capturer une trame en provenance du module émetteur.
(Voir pièces jointes -> fichier de projet olp + version image)

Du coup j'ai pu déduire qu'il s'agissait d'une trame encodé en manchester (?) avec un entête de taille fixe, et un préambule de 4 "1" logique.

Après mesures dans le logiciel OLS :
Durée de l'entête : 2.45ms
Durée d'un temps d'horloge complet : ~830us
Durée d'un demi temps d'horloge : 400us
On peut donc déduire que la liaison ce fait à 2500 bauds (?)

Si j'ai bien compté il y a 52 bits, moins les 4 bits du préambule cela ferai 48 bits soit 6 octets (?)
J'ai tenté de décoder la trame manchester mais âpres les 6 premiers "1" je suis complétement perdu ...
D'après ce que j'ai pu voir plus bas les adresses serait sur 5 octets, il y aurait donc un 6eme octet mystère dont l'utilité reste à déterminer.

J'ai aussi sorti mon bus pirate pour regarder ce qui ce passe du coté de l'EEPROM.
Edit : (...)

Bref si il y a des bricoleurs dans l'âme qui voudraient participer ce serais cool :wink:
Le but serais de décoder la trame RF des télécommandes pour pouvoir par la suite émuler une télécommande à partir d'une carte arduino.
Ce serais tiptop vu que la box domotique que commercialise castorama est hors de prix, et qu'en faire une en DIY serait quand même plus gratifiant !

blyss.olp (3.68 KB)

skywodd:
...

Bref si il y a des bricoleurs dans l'âme qui voudraient participer ce serais cool :wink:
Le but serais de décoder la trame RF des télécommandes pour pouvoir par la suite émuler une télécommande à partir d'une carte arduino.
Ce serais tiptop vu que la box domotique que commercialise castorama est hors de prix, et qu'en faire une en DIY serait quand même plus gratifiant !

bonsoir skywodd
pour résumer à ce stade : les appuis successifs sur ton bouton ne génèrent pas la même trame ?
Il y a peut être suspicion de rolling code et là pour faire faire du reverse ce n'est pas gagné.

comment tu affecte un émetteur au récepteur ?

Ton sniffer peut rejouer ses acquisitions ?
si oui , il y a peut peut être déjà un test à faire

  • rejouer la dernière trame pour voir si elle est correctement réceptionnée
  • acquérir hors de portée du récepteur la trame suivante et la rejouer pour voir si elle est correctement receptionnée

Artouste:
pour résumer à ce stade : les appuis successifs sur ton bouton ne génèrent pas la même trame ?
Il y a peut être suspicion de rolling code et là pour faire faire du reverse ce n'est pas gagné.

Moi je soupçonne fortement ma carte bus pirate de ne pas capturer correctement certaine trames ...
J'ai regardé avec mon OpenLogic Sniffer et son décodeur de trame I2C, ça à l'air d'être de l'I2C software respectant trés moyennement les standards I2C ...
En tout cas le décodeur I2C de OLS part dans les choux à chaque tentative de décodage ...

Edit: Aprés test plus poussé il semble bien que ce soit un probléme de décodage des trames I2C ... du coup je sait pas trop comment faire ...

Artouste:
comment tu affecte un émetteur au récepteur ?

Pour affecter un émetteur il faut appuyé sur un bouton côté récepteur, puis appuyer sur l'interrupteur que l'on veut associer.
On peut associer plusieurs interrupteurs à un même récepteur.

Artouste:
Ton sniffer peut rejouer ses acquisitions ?
si oui , il y a peut peut être déjà un test à faire

  • rejouer la dernière trame pour voir si elle est correctement réceptionnée
  • acquérir hors de portée du récepteur la trame suivante et la rejouer pour voir si elle est correctement receptionnée

Je ne crois pas que je puisse rejouer les trames avec une carte OLS (barbudor help !) ...

Je viens de tomber sur un article intéressant :

Techniquement, la radio de la box domotique et des accessoires Blyss Liveez fonctionne sous double fréquence : 433Mhz et 868Mhz.

Il s’agit d’un protocole spécifique développé par Avidsen. Un protocole propriétaire et sécurisé. Car à ce jour il n’existe pas de protocole universel adopté par la majeure partie des fabricants. Par ailleurs, ce protocole étant bi-directionnel en 868Mhz, il permet le retour d’information.

Concrètement, la box ou l’accessoire envoie un ordre à un autre accessoire. Ce dernier envoie à son tour un accusé de réception. Et le premier continuera d’envoyer son ordre tant qu’il n’aura pas reçu d’accusé réception. Fini, donc, les interférences.

La je reste perplexe !

Sur la carte émettrice il n'y a qu'un bête modulateur RF 433MHz, et aucune self ... donc pour la partie double fréquence / bi-directionnel c'est louche ...
(Mais bon c'est dit "bi-directionnel en 868Mhz" donc peut être qu'en 433MHz il n'y pas ce même protocole ?)

Et pour ce qui est de la partie acquittement des ordres je vois mal comment le récepteur pourrait emmètre en retour sans le moindre modulateur ...
C'est de plus en plus louche cette histoire ...

skywodd:
Je ne crois pas que je puisse rejouer les trames avec une carte OLS (barbudor help !) ...

dommage
Tu repique ton signal à acquérir où exactement et comment ?

photos ?

Artouste:
Tu repique ton signal à acquérir où exactement et comment ?

photos ?

Je sort l'appareil photo :wink:

skywodd:
Je viens de tomber sur un article intéressant :
Quand la journée démarre toute seule...
...
Techniquement, la radio de la box domotique et des accessoires Blyss Liveez fonctionne sous double fréquence : 433Mhz et 868Mhz.

Il y a peut être des équipements qui permettent l’acquittement et/ou du flux bidirecetionnel entre eux et la box, mais pour une simple telec commandant une prise ce serait étonnant (surtout vu le prix)

Artouste:
Il y a peut être des équipements qui permettent l’acquittement et/ou du flux bidirecetionnel entre eux et la box, mais pour une simple telec commandant une prise ce serait étonnant (surtout vu le prix)

Je pense aussi ... donc leur histoire de protocole sécurisé blablabla pour la partie interrupteurs c'est du vent ...

Sinon voila les photos de l'émetteur et du récepteur, avec en bonus le code arduino pour tenter d'imiter une télécommande (mais qui ne marche pas pour le moment) :
https://dl.dropbox.com/u/53604363/project_blyss.zip

skywodd:

Artouste:
Il y a peut être des équipements qui permettent l’acquittement et/ou du flux bidirecetionnel entre eux et la box, mais pour une simple telec commandant une prise ce serait étonnant (surtout vu le prix)

Je pense aussi ... donc leur histoire de protocole sécurisé blablabla pour la partie interrupteurs c'est du vent ...

Sinon voila les photos de l'émetteur et du récepteur, avec en bonus le code arduino pour tenter d'imiter une télécommande (mais qui ne marche pas pour le moment) :
https://dl.dropbox.com/u/53604363/project_blyss.zip

ok
Tu a un bon oscillo analogique je crois ?
ça donne quoi visuellement le signal en pin 1 en appuyant en continu sur le BP, si le code émis reste le même cela se vérifie simplement en réglant la BdT et le bon déclenchement , une trace bien propre , si le code est changeant ça se verra vite trace gigotante.

Artouste:
Tu a un bon oscillo analogique je crois ?
ça donne quoi visuellement le signal en pin 1 en appuyant en continu sur le BP, si le code émis reste le même cela se vérifie simplement en réglant la BdT et le bon déclenchement , une trace bien propre , si le code est changeant ça se verra vite trace gigotante

Mon oscilloscope commence a rendre l'âme malheureusement ... la base de temps est quasi HS et ya plus de syncro sur les fronts ...
Je vais tenter quand même histoire de voir mais je garanti rien.

Edit: bon apparemment la trame reste la même durant 2sec (environ), âpres plus rien, et quand on relâche le bouton il y a une seconde trame (différente de la 1er) qui reste stable elle aussi durant ~2sec.

skywodd:
Edit: bon apparemment la trame reste la même durant 2sec (environ), âpres plus rien, et quand on relâche le bouton il y a une seconde trame (différente de la 1er) qui reste stable elle aussi durant ~2sec.

Ok
un bon vieux oscillo ana rend bien des services même en numérique :grin:
essaie de faire des photos des trames appui/relâchement sur plusieurs cycles pour comparer.

mais à ce stade à priori j’évacue du "rolling code"
Tes essais de reverse peuvent être pollué par ton nouveau jouet (sniffer) qui part dans les choux pour une raison ou une autre
Tu peux maximiser l''acquisition en affectant toute la mémoire dispos sur une seule voie à horloge max ?

Artouste:
un bon vieux oscillo ana rend bien des services même en numérique :grin:
essaie de faire des photos des trames appui/relâchement sur plusieurs cycles pour comparer.

J'essayerai ça demain :wink:

Artouste:
Tes essais de reverse peuvent être pollué par ton nouveau jouet (sniffer) qui part dans les choux pour une raison ou une autre
Tu peux maximiser l''acquisition en affectant toute la mémoire dispos sur une seule voie à horloge max ?

Sur le bus pirate le sniffer I2C tourne déja à la fréquence max de 100KHz ...
Je vais essayer d'utiliser une nouvelle fois la carte OLS ... à 200MHz ça dépote :sweat_smile:
Bon par contre j'espère que l'analyseur I2C ce décidera à décoder ma trame ...

Bonjour

Le sujet m'intéresse mais j'ai actuellement peu de temps à y consacrer.
Le décodage Manchester me parait être la voie la plus efficace.
On perd vite le fil en faisant ce décodage à la main...
Un petit soft de décodage travaillant sur PC en aval d'OLS pourrait booster la recherche.
Le top : un plugin Manchester pour OLS avec l'aide d'un connaisseur de java !!

J'ai ouvert , skywodd, ton fichier blyss.ods avec OLS.0.95 puis exporté en 'Value Change Dump' (VCD) pour avoir en clair et en décimal les valeurs et leurs instants de transition.
Après un petit nettoyage manuel de mon blyss.vcd (recherche et remplacement) j'en ai fait un blyss.csv
Je n'ai pas eu le temps de trouver la bonne macro sous tableur.....
(Sans export en VCD il est aussi possible de dézipper le fichier ODS , ça donne la même chose en hexa)
En gros je voulais tester l'algo suivant:
On connait le bit initial, ensuite selon que l'intervalle est long ou court on inverse ou pas la valeur....

Fichiers vcd, csv et tableur LibreOffice ci joints

Blisstraité.zip (11.9 KB)

skywodd:
Bon par contre j'espère que l'analyseur I2C ce décidera à décoder ma trame ...

Bonjour skywodd
Là je ne te suis pas (ou je n'ai pas bien compris ce que tu exprime 8) )
Tu part du principe que le motif (la trame) de transmission appliqué à l'emetteur (et reçu par le recepteur)
et un simple "copié collé" d'une trame I2C juste conditionnée/reconditionnée ? , que l’émetteur UHF (du bouton) et le récepteur (la prise) ne transmettent que de la trame "standardisée" I2C ( avec diminution de débit ) ?

Perso , je ne le pense pas , les MCU embarqués (bouton, prise) ont surement d'autres fonctions que la seule de simplement remettre en forme/vitesse une trame I2C emise/reçue en RAW.

al1fch:
Le décodage Manchester me parait être la voie la plus efficace.
On perd vite le fil en faisant ce décodage à la main...

Je suis justement en train de décoder la trame ... mais je suis fasse à un probléme ... un gros probléme !

J'ai fait quelques statistiques sur les durées des temps haut / temps bas :
Temps haut : 812us en moyenne
Temps bas : 410us en moyenne
Problème n°1: Il ya de relativement grosses variations dans les temps haut / temps bas au cours de l'émission de la trame !
On peut quand même dire sans trop s'avancer que la fréquence porteuse à une période de 400us soit 2500Hz.

Problème n°2 : Après un petit tour sur Codage Manchester — Wikipédia
J'ai découvert qu'il 'était impossible de décoder en code manchester la trame en question ...

(T = 400us, 2T = 800us)
Au début on as 0:T 1:2T 0:T 1:2T ...
L'encodage manchester spécifie qu'il doit y avoir absolument un changement d'état durant une portion de temps T

Si on découpe en morceau de longueur T cela donne :
0 11 0 11

Ensuite (normalement) c'est tout con pour avoir les bits d'origine :

  • on groupe par lot de 2 bits
  • si c'est 10 -> 1, si c'est 01 -> 0 (ou l'inverse suivant la logique utilisé)

Donc :
01 10 11 -> 0 1 ... probléme 11 est tout simplement impossible en manchester ?
Du coup je vois pas comment faire .. Une possible erreur de ma pars ? Trame de codage inconnu ? ... ?

al1fch:
Un petit soft de décodage travaillant sur PC en aval d'OLS pourrait booster la recherche.
Le top : un plugin Manchester pour OLS avec l'aide d'un connaisseur de java !!

Je sait coder en java mais de là à faire un plugin OLS c'est hors de ma porté.
Par contre je sait utiliser un tableur :grin:
J'ai fait un petit truc de décodage (voir pièce jointe)

al1fch:
Après un petit nettoyage manuel de mon blyss.vcd (recherche et remplacement) j'en ai fait un blyss.csv
Je n'ai pas eu le temps de trouver la bonne macro sous tableur.....

Tu fera attention j'ai l'impression que tu as décalé tes valeurs de un bits au début :wink:

Artouste:
Là je ne te suis pas (ou je n'ai pas bien compris ce que tu exprime 8) )
Tu part du principe que le motif (la trame) de transmission appliqué à l'emetteur (et reçu par le recepteur)
et un simple "copié collé" d'une trame I2C juste conditionnée/reconditionnée ? , que l’émetteur UHF (du bouton) et le récepteur (la prise) ne transmettent que de la trame "standardisée" I2C ( avec diminution de débit ) ?

Perso , je ne le pense pas , les MCU embarqués (bouton, prise) ont surement d'autres fonctions que la seule de simplement remettre en forme/vitesse une trame I2C emise/reçue en RAW.

Arf je crois que t'as pas compris :grin:
Ma carte bus pirate embarque un sniffer I2C relativement sommaire, qui marche jusqu'à ~100KHz ... en théorie.
En pratique c'est trés variable, il suffit que le µc fasse de l'i2c software et que les timings soit pas tiptop pour que le sniffer se plante.

Ce qui me conforte dans l'idée de l'i2c software c'est tout simplement que le datasheet du sonic machin truc ... dit que celui ne possède aucun périphériques de communication !
De plus le fait que l'analyseur de trames de OLS ne puisse pas décoder la trame en I2C laisse vraiment penser que celle ci est plus que bancale niveau timing ...
(Je parle bien de la trame sniffé sur la partie réceptrice, entre le µc et l'eeprom, pas de la trame RF envoyé via le module 433MHz)

Donc en gros on ne peut pas se baser sur les données du bus I2C ... il faut réussir par un moyen quelconque à décoder la trame RF puis regarder si les info quelle contient auraient un rapport avec les brides de données sniffé sur le bus I2C ...

De belle heures de prises de tête en perspective :zipper_mouth_face:

blyss.ods (19.4 KB)

skywodd:
(Je parle bien de la trame sniffé sur la partie réceptrice, entre le µc et l'eeprom, pas de la trame RF envoyé via le module 433MHz)

Donc en gros on ne peut pas se baser sur les données du bus I2C ... il faut réussir par un moyen quelconque à décoder la trame RF puis regarder si les info quelle contient auraient un rapport avec les brides de données sniffé sur le bus I2C ...

De belle heures de prises de tête en perspective :zipper_mouth_face:

Ha ba voilà :grin:
Quand on m'explique bien , en règle générale je comprend assez vite 8)
Bien d'accord , il faut déjà acquérir et eplucher les data envoyé en driver de l’émetteur UHF (ou sortie du recepteur ) , avant de voir ensuite comment cela joue (eventuellement) sur la gestion de l'EEprom par le MCU.

J'ai vu que la telco avait plusieurs "boutons" , perso je ferais déjà des acquisitions de trame au niveau de l'entrée du module UHF (en ON/OFF) pour ensuite les comparer entre elles et voir ce qui est variant (et déjà bien verifier que le motif est identique pour une même action) .

Artouste:
Ha ba voilà :grin:
Quand on m'explique bien , en règle générale je comprend assez vite 8)

J'avais un peu tout mélangé désolé :sweat_smile:

Artouste:
Bien d'accord , il faut déjà acquérir et eplucher les data envoyé en driver de l’émetteur UHF (ou sortie du recepteur ) , avant de voir ensuite comment cela joue (eventuellement) sur la gestion de l'EEprom par le MCU.

C'était surtout pour avoir idée de la taille des données qui pouvait transiter entre E / R.
Vu que j'imagine qu'il y a dans la trame RF une adresse, et un (ou plusieurs) octet de statut (on / off, ...)

Artouste:
J'ai vu que la telco avait plusieurs "boutons" , perso je ferais déjà des acquisitions de trame au niveau de l'entrée du module UHF (en ON/OFF) pour ensuite les comparer entre elles et voir ce qui est variant (et déjà bien verifier que le motif est identique pour une même action) .

Oui chef !
Voir piéces jointes chef ! :grin:

J'ai enregistrer la trame complète ON + OFF : ça permet déjà de voir qu'il faut 13 envois de la portion de données à chaque appui / relâchement pour être pris en compte.
J'ai aussi pris les trame séparément en basse définition pour avoir 2 portion de trame et en haute définition pour avoir une portion complète avec des timings précis.

On remarque que les deux trames ON et OFF sont identique sur le début puis différentes sur la fin.
A mon avis c'est entête + 4 bits de syncro + 5 octets d'adresse + 1 octets de statut On / Off ... maintenant comment décoder le tout ... mystère ...

trame_blyss.zip (17.2 KB)

Manchester ? faut y regarder de plus près et pas s'emballer !
Je n'ai pas été loin dans la trame mais pour l'instant je vois des fronts descendants à intervalle de temps régulier...
Si ça se confirme on serait en présence d'un banal codage basé sur la position du front montant.
le premier octet pouvant être 0x01 ou 0xFE
Je vais aller voir un peu plus loin dès que possible

al1fch:
Manchester ? faut y regarder de plus près et pas s'emballer !
Je n'ai pas été loin dans la trame mais pour l'instant je vois des fronts descendants à intervalle de temps régulier...

Je vois du manchester partout de tout façon :sweat_smile:
A force d'utiliser cette méthode partout je ne jure que par ça :zipper_mouth_face:

al1fch:
Si ça se confirme on serait en présence d'un banal codage basé sur la position du front montant.
le premier octet pouvant être 0x01 ou 0xFE
Je vais aller voir un peu plus loin dès que possible

Hoho C'est prometteur !
J'ai vu passer ces deux octets pendant le dump de l'eeprom !

Par contre ... je ne vois pas du tout comment fonctionne ton "banal codage basé sur la position du front montant" :sweat_smile:
Une ch'tite explication m'sieur ? :grin:

rapport cyclique 1/3 ou 2/3 entre deux fronts descendants
on peut essayer de lire en se concentrant sur la durée des états bas
ça serait plus habituel en inversant les niveaux logiques.
Disons qu'on serait, si l'hypothèse se vérifie, en PWM mais en logique négative