Interrupteurs domotique Blyss de castorama

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

al1fch:
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

Ce qui pourrait collerai avec le fait que le µc ne comporte qu'un timer avec un générateur de PWM associé ...
Je vais regarder le datasheet voir si la broche d'émission du signal est celle permettant de faire de la PWM ou celle associé au timer.

Quand j'écrivais PWM c'était juste pour évoquer l'allure du signal, pas sa production.
si ça e trouve c'est codé en assembleur avec des boucles de temporisation.
Un petit µC 4 bits ferait même l'affaire côté emetteur !

al1fch:
Quand j'écrivais PWM c'était juste pour évoquer l'allure du signal, pas sa production.
si ça e trouve c'est codé en assembleur avec des boucles de temporisation.
Un petit µC 4 bits ferait même l'affaire côté emetteur !

Bon bin ya effectivement de forte chance que ce soit basé sur des boucles + tempo ...
Pour ceux qui est du code c'est quasi sur c'est de l'assembleur ...
1Ko flash, 48o ram ... http://www.sonix.com.tw/sonix/product.do?p=SN8P2501B

Le brochage :
Bouton externe : P1.0
Bouton interne : P1.2 (bouton inutile ... il fait la même chose que le bouton externe)
Led de statut : P2.1 (semble clignoter au même rythme que la sortie RF)
Module RF : P2.2

Au passage c'est un peu mal foutu l'interrupteur externe est cablé sur une broche ne supportant pas le mode "wake up" donc le truc reste h24 en marche ...
En réveillant le CI juste au moment de l'appui ça permettrai d'économiser la batterie ... bref :grin:

Je retourne sous paint.net décodé tout ce petit monde suivant ton principe :slight_smile:

Bon en suivant ton principe je trouve :

0000 00011000 01101010 00001000 01111111 00100101 01101110

Ou en logique inversé :

1111 11100111 10010101 11110111 10000000 11011010 10010001