Go Down

Topic: Interrupteurs domotique Blyss de castorama (Read 55050 times) previous topic - next topic

skywodd


encore un test à faire
verifier si les 2emes/3emes ... trames successives "apres init" sont identiques, même pour des appuis décalés dans le temps

Les trames commencent toujours de la même manière âpres mise sous tension :
Quote
FE 79 5F 78 19 87 D (A)
FE 79 5F 78 0D A2 F (B)
FE 79 5F 78 11 E9 9 (C)
FE 79 5F 78 0E 66 3 (D)



Que donnent plusieurs ON successifs suffisement espacés dans le temps et sans OFF intermédiaires ?

Avec l'interrupteur c'est impossible d'avoir plusieurs ON successif sans OFF intermédiaires vu que c'est un interrupteur "va et vient".
Et comme je ne peut pas piquer le signal de la télécommande ...

Bon sinon j'ai mis en place un systéme de boutons, côte émetteur j'ai un inter ON /OFF, et côté récepteur j'ai un inter DUMP / RUN ce qui me permet de faire des dump de l'eeprom après chaque basculement de l'inter ON / OFF.

Je peut donc affirmer sans me tromper que les 8 bits tournants et les 8 bits inconnu NE SONT PAS stocké dans l'eeprom.
Les seuls modifications apporté lors d'un appui sur le BP sont au niveau de l'octet 0x00 / 0xFF qui stocke l'état du relai du récepteur.
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

barbudor

Si tu génère 8 bits aléatoires en emission, est-ce que l'objet télécommandé réagit ou pas ?
Peut être n'y a t'il aucune corrélation entre les bits, il faut juste qu'ils soient différents
Barbuduino: Arduino sur Breadboard & VinciDuino: Clone Leonardo // WR703: Mini-routeur hacké // LauchPad MSP430 et Stellaris // Panda II Arduino-like .NetMF sous VisualC#
RTFC: Read That F.....g Code / RTFD: Read That F.....g Doc / RTFDS: Read That F.....g DataSheet / RTFS: Read That F.....g Schematic / Wot da ya wanna D.I.Y. today ?

al1fch

#77
Jun 16, 2012, 03:37 pm Last Edit: Jun 16, 2012, 03:46 pm by al1fch Reason: 1
Oui, barbudor la piste du timer est intéressante
j'ai repris ton fichier pour faciliter l'analyse de l'évolution du dernier octet.
c'est peu être fortuit (je ne sais pas comment ont été rythmées les emissions successives) mais je crois voir des répétitions sur le quartet fort de ce qui pourrait être une valeur de timer pris au vol et  envoyée en fin de trame ! (F271 ou 5DD...) cf texte colorié joint.
J'ai trop envie que ce soit ça !!

Quote
Je peut donc affirmer sans me tromper que les 8 bits tournants et les 8 bits inconnu NE SONT PAS stocké dans l'eeprom.
Les seuls modifications apporté lors d'un appui sur le BP sont au niveau de l'octet 0x00 / 0xFF qui stocke l'état du relai du récepteur.

skywodd je crois qu'on peut éliminer (ouf !) le rolling code qui nécessiterait un minimum de mémorisation supplémentaire en eeprom récepteur.

skywodd


Si tu génère 8 bits aléatoires en emission, est-ce que l'objet télécommandé réagit ou pas ?

Héhé ! JACKPOT ! Avec des chiffres complétement aléatoire ça marche !
Bon parfois ça rate mais sinon dans le principe ça fonctionne !
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

Artouste

Pour l'anecdote
meme si je ne ressortirais mes "jouets" que plus tard   8) , je ne vais pas me priver déjà de sortir un connecteur kivabien
:smiley-mr-green:




al1fch

#80
Jun 16, 2012, 03:49 pm Last Edit: Jun 16, 2012, 03:54 pm by al1fch Reason: 1
Quote
Héhé ! JACKPOT ! Avec des chiffres complétement aléatoire ça marche !
Bon parfois ça rate mais sinon dans le principe ça fonctionne !


timer++ !!  le récepteur écarterait les trames dont les octets de fin seraient trop proches.

en complémentant l'octet de fin à chaque envoi ,au lieu d'envoyer de l'aléatoire,ça suffit peut être à maintenir un delta suffisant pour le récepteur entre deux messages successifs ?

Artouste

#81
Jun 16, 2012, 03:49 pm Last Edit: Jun 16, 2012, 03:53 pm by Artouste Reason: 1


Si tu génère 8 bits aléatoires en emission, est-ce que l'objet télécommandé réagit ou pas ?

Héhé ! JACKPOT ! Avec des chiffres complétement aléatoire ça marche !
Bon parfois ça rate mais sinon dans le principe ça fonctionne !

alors continue l'analyse  :smiley-mr-green:
quels codes ratent, quels codes fonctionnent, si ça se trouve ça se reduit simplement  8)


Quote
Héhé ! JACKPOT ! Avec des chiffres complétement aléatoire ça marche !
Bon parfois ça rate mais sinon dans le principe ça fonctionne !


timer++ !!  le récepteur écarterait les trames dont les octets de fin seraient trop proches

Bonne suggestion
faire un test avec des des valeurs moyennement eloignées  :smiley-mr-green:
0 63 127 255

skywodd

#82
Jun 16, 2012, 03:52 pm Last Edit: Jun 16, 2012, 03:54 pm by skywodd Reason: 1

alors continue l'analyse  :smiley-mr-green:
quels codes ratent, quels codes fonctionnent, si ça se trouve ça se reduit simplement  8)

En faite je crois que les ratés sont du à ma méthode basé sur random() d'arduino qui est pas si random que ça  :smiley-mr-green:
Je suis en train de regarder comment ça ce comporte avec une bête addition à chaque fois.

Ps: Quand il va falloir que je reprenne tout le topic depuis le début pour faire le compte rendu ... ça va être plus long que le hack en lui même :smiley-mr-green:
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

skywodd

Les valeurs des 8 derniers bits sont effectivement pompé d'un timer 8bits (à incrémentation positive) !

-> voir fichier calc joint
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

al1fch

#84
Jun 16, 2012, 04:14 pm Last Edit: Jun 16, 2012, 04:24 pm by al1fch Reason: 1
écart mini constaté  = 5  = 0xD5 -0xD0 FAUX il faut faire (n) par rapport à (n-1) !
(cf 65 trames de barbudor) ...  sauf erreur de lecture

Sans doute içi : delta de 3 seulement
Code: [Select]
> FE 4A 23 D8 0 9 8 5 3
> FE 4A 23 D8 0 D A D 5
> FE 4A 23 D8 0 1 E D 0
> FE 4A 23 D8 0 E 6 D E <<
> FE 4A 23 D8 0 6 7 E 1 <<

> FE 4A 23 D8 0 9 8 F A


Artouste

#85
Jun 16, 2012, 04:15 pm Last Edit: Jun 16, 2012, 04:17 pm by Artouste Reason: 1

Les valeurs des 8 derniers bits sont effectivement pompé d'un timer 8bits (à incrémentation positive) !

-> voir fichier calc joint

comme ce ne doit pas etre verifié temporellement par le recepteur
fais qq test successifs avec 0 et 127 en finale

barbudor

Nan, pas un timer.
Quelque soit le temps entre 2 pressions de boutons, la séquence ne change pas.
Nouvelle séquence avec 285 captures
Aucune répétition

je ne sais plus si on l'a déjà dit mais la séquence inconnue ne dépend pas du flag ON/OFF

Séquence que de ON :

> FE 4A 23 D8 0E A3 1
> FE 4A 23 D8 0E F9 D
> FE 4A 23 D8 0B 96 B
> FE 4A 23 D8 07 C0 9
> FE 4A 23 D8 06 24 0
> FE 4A 23 D8 0E EB 9
> FE 4A 23 D8 05 7A F
> FE 4A 23 D8 07 89 8
> FE 4A 23 D8 09 A6 5
> FE 4A 23 D8 09 EF 3
> FE 4A 23 D8 0E 61 9
> FE 4A 23 D8 06 76 2
> FE 4A 23 D8 09 8F 9
> FE 4A 23 D8 0D A2 6
> FE 4A 23 D8 01 E7 9

Séquence ON et OFF

> FE 4A 23 D8 0E A3 1
> FE 4A 23 D8 0E F9 D
> FE 4A 23 D8 0B 96 B
> FE 4A 23 D8 07 C0 9
> FE 4A 23 D8 06 24 0
> FE 4A 23 D8 0E EB 9
> FE 4A 23 D8 05 7A F
> FE 4A 23 D8 17 89 8
> FE 4A 23 D8 19 A6 5
> FE 4A 23 D8 19 EF 3
> FE 4A 23 D8 1E 61 9
> FE 4A 23 D8 06 76 2
> FE 4A 23 D8 09 8F 9
> FE 4A 23 D8 0D A2 6
> FE 4A 23 D8 01 E7 9
Barbuduino: Arduino sur Breadboard & VinciDuino: Clone Leonardo // WR703: Mini-routeur hacké // LauchPad MSP430 et Stellaris // Panda II Arduino-like .NetMF sous VisualC#
RTFC: Read That F.....g Code / RTFD: Read That F.....g Doc / RTFDS: Read That F.....g DataSheet / RTFS: Read That F.....g Schematic / Wot da ya wanna D.I.Y. today ?

barbudor

Et Skywodd, tu as un noyau multi-tâche
Simultanément il continue à répondre aux différents sujets, a publier sur son blog et a décortiquer les Blyss
Barbuduino: Arduino sur Breadboard & VinciDuino: Clone Leonardo // WR703: Mini-routeur hacké // LauchPad MSP430 et Stellaris // Panda II Arduino-like .NetMF sous VisualC#
RTFC: Read That F.....g Code / RTFD: Read That F.....g Doc / RTFDS: Read That F.....g DataSheet / RTFS: Read That F.....g Schematic / Wot da ya wanna D.I.Y. today ?

skywodd

#88
Jun 16, 2012, 04:33 pm Last Edit: Jun 18, 2012, 05:13 pm by skywodd Reason: 1

en complémentant l'octet de fin à chaque envoi ,au lieu d'envoyer de l'aléatoire,ça suffit peut être à maintenir un delta suffisant pour le récepteur entre deux messages successifs ?

J'ai pris un delta de 50 entre chaque trame, ça marche nikel comme sur des roulettes, je testerai avec juste +1 ;)

--> Voir .ino en pièce jointe


écart mini constaté  = 5  = 0xD5 -0xD0 FAUX il faut faire (n) par rapport à (n-1) !
(cf 65 trames de barbudor) ...  sauf erreur de lecture

Ou tu as vu min = 5 ? Dans mon fichier calc j'ai bien min = 3.


comme ce ne doit pas etre verifié temporellement par le recepteur
fais qq test successifs avec 0 et 127 en finale

Raaa encore des tests :smiley-mr-green:


Et Skywodd, tu as un noyau multi-tâche
Simultanément il continue à répondre aux différents sujets, a publier sur son blog et a décortiquer les Blyss

Tout en répondant à mes mail et à mes @mention twitter, le tout en discutant sur skype  :smiley-sweat:
Certain appellerons ça de la dispersion ... d'autre du multi-taches :smiley-mr-green:
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

al1fch

#89
Jun 16, 2012, 04:40 pm Last Edit: Jun 16, 2012, 04:56 pm by al1fch Reason: 1
s'il n'y a pas de bug au niveau de ton systeme de capture, barbudor,  on doit faire un pas en arrière dans l'analyse car on voit apparaitre des valeurs nouvelles (par exemple 78, 9A ou 9E dans l'avant dernier octet., valeurs qui ne sont pas toutes dans le cycle 98 > DA > 1E > E6 -> 67 > DA .. qu'ont pensait identifié  :~

Quote
> FE 4A 23 D8 05 7A F
> FE 4A 23 D8 1  78*   9 8......78, pas 98 ?
> FE 4A 23 D8 1  9A*   6 5......9A ,pas DA ?
> FE 4A 23 D8 1  9E*   F 3......9E, pas 1E ?
> FE 4A 23 D8 1  E6    1 9
> FE 4A 23 D8 0  67    6 2
> FE 4A 23 D8 0  98    F 9
> FE 4A 23 D8 0  DA   2 6
> FE 4A 23 D8 0  1 E   7 9


@skywodd
Quote
Ou tu as vu min = 5 ? Dans mon fichier calc j'ai bien min = 3.

le min de 5 a été constaté "à vue de nez"  dans l'enregistrement de barbudor '65 trames...' avant ton analyse !!

Go Up