Piloter vos récepteurs volets OTIO avec un Raspberry Pi

Cet article est le premier d’une longue série sur la mise en place d’une centrale domotique pour piloter des périphériques de ma maison (volets roulants, détecteurs de mouvements, lumière, …). Je commencerais par quelques expérimentations autour de la technologie RF avec le Raspberry Pi ou l’Arduino puis par la mise en place d’une interface Web de contrôle. Mais ça, ce n’est pas pour demain 🙂

Je possède des volets électriques Somfy à mon domicile. Seulement, ces volets ne sont pas pilotables sans fils mais uniquement via les interrupteurs muraux filaires. J’ai donc installé des micro-récepteurs sans fils afin de pouvoir les piloter à distance. Les micro-récepteurs que j’ai sélectionné ont l’avantage de ne pas modifier l’installation existante et de pouvoir être masqués derrière les interrupteurs existants. J’ai donc choisi les récepteurs de la marque OTIO disponibles sur Internet ou dans les GSB pour moins de 100€ le pack. Au niveau des caractéristiques, c’est du classique RF 433 Mhz avec une portée de 70 mètres. Ce n’est certes pas ce qui se fait de mieux mais le rapport qualité/prix est intéressant. L’autre avantage c’est que les récepteurs sont pilotables à l’aide d’un simple module RF connecté sur un Raspberry ou un Arduino.

I 577466

Du côté Hardware

Pour ce premier tutorial, je vais vous présenter comment récupérer, à l’aide d’un récepteur RF, les codes des commandes haut/bas de la télécommande permettant respectivement d’ouvrir et fermer les volets roulants et comment les envoyer aux différents récepteurs à l’aide d’un transmetteur RF connecté à un Raspberry Pi. Pour cela, j’ai utilisé :

  • Un Raspberry Pi (Modèle B rev. 1 – RAM 256 Mb),
  • Des modules émetteurs/récepteurs RF 433 Mhz (Amazon) :
    • Récepteur référencé XY-MK-5V
    • Emetteur référencé XY-FST
Pour le côté pratique, j’ai également utilisé une carte d’expérimentation (Breadbord), un T-Cobbler, ainsi que des fils de connection pour réaliser mon montage sans soudures.
Le Raspberry Pi possède une interface GPIO (General Purpose Input/Output), un port d’extension composé de 26 pins sur lesquels il est possible de s’interfacer. Les 26 pins sont répartis ainsi :
  • 2 pins fournissant du 5v,
  • 2 pins fournissant du 3,3v,
  • 5 pins pour la terre (Ground)
  • et 17 pins pour les entrées et sorties (GPIO).
 Raspberry PI GPIO
Le Raspberry Pi s’interface avec les modules RF émetteur/récepteur comme sur le schéma ci-dessous :
Raspberry RF rx tx bb
Les deux modules sont alimentés par du 5v et sont reliés à la terre. Les entrées utilisées sont :
  • La broche 13 (GPIO 21/27 suivant la version du Raspberry) pour l’entrée du récepteur,
  • La broche 11 (GPIO 17) pour l’entrée de l’émetteur.
Pour récapituler, le branchement se fait de cette manière :
Pins Raspberry Pi Pins Récepteur 433 Mhz
GND GND
5V VCC
GPIO 21/27 Data
Pins Raspberry Pi Pins Emetteur 433 Mhz
GND GND
5V VCC
GPIO 13 Data
Il est également préférable, pour gagner en portée, d’ajouter un petit bout de fil sur le connecteur ANT des modules. La taille idéale étant de 17,3cm ou de 33cm en spirales. A noter que si vous utilisez déjà ces broches pour d’autres montages, il est possible d’en choisir d’autres, vous n’aurez qu’à le spécifier au niveau du code.
Une photo du montage une fois terminé (à noter, l’ajout de la LED permettant de savoir si le montage est sous tension).
IMG 20140923 001003
Du côté software
Une fois votre montage réalisé, il ne reste plus qu’à installer les logiciels permettant d’envoyer et recevoir des signaux RF en manipulant les états des ports GPIO. Pour cela, nous allons installer :
  1. La librairie WiringPi permettant de manipuler les GPIO en ligne de commande,
  2. La librairie 433Utils regroupant des outils pour s’interfacer avec les modules RF,
  3. Exécuter RFSniffer afin d’obtenir les codes de la télécommande actuelle,
  4. Puis exécuter le code permettant d’envoyer les ordres RF vers les récepteurs OTIO.
C’est parti 🙂
1. Installer la librairie WiringPi à l’aide des comandes ci-dessous 

2. Installer la librairie 433Utils à l’aide des commandes ci-dessous :

3. Intercepter les codes d’envoi/réception de la télécommande avec RFSniffer (~/433Utils/RPi_utils/RFSniffer) :
RFSniffer 433
Une fois cette commande lancée, il suffit d’approcher la télécommande du récepteur RF. Les codes s’affichent alors dans la console. Pour ma part, les codes sont :
  • 959542784 pour la fermeture,
  • 892433920 pour l’ouverture.
Ces codes ne seront sûrement pas les même pour vous car ils différent d’un kit à l’autre pour éviter les interférences entre les différents kits. Le mécanisme d’association des récepteurs avec la télécommande sert d’ailleurs aux récepteurs à apprendre les différents codes (haut/bas) de la télécommande.
Il ne reste plus qu’a rejouer ces codes via un programme pour contrôler les récepteurs depuis le Raspberry Pi :

Les commandes doivent être envoyées en 32 bits, via le protocole 2 avec une durée d’impulsion de 700ms. Il est possible de réduire le nombre d’envois à 10 voir 5 en fonction de la qualité de votre antenne et des interférences environnantes. Voilà, il ne reste plus qu’à vous amusez avec ces petites commandes en attendant de pouvoir piloter vos périphériques depuis une interface Web.

 

Mes références/sources sur le sujet :
Prochaine étape…
Je vous présenterais comment réaliser la même opération à l’aide de l’Arduino au lieu du Raspberry Pi. J’ai dans l’idée de déléguer la partie émission/réception RF à un module Arduino connecté au Raspberry Pi soit par liaison série USB soit en utilisant le port I2C plutôt que d’utiliser le Raspberry Pi pour cet usage car la consommation CPU de la boucle de traitement des signaux RF est trop importante et qu’il n’est pas fait pour le temps réel.


, , , , ,

33 réponses à Piloter vos récepteurs volets OTIO avec un Raspberry Pi

  1. temps 30 septembre 2014 à 1:46 #

    Bonjour,
    Belle installation.
    J’éviterai peut-être le web.
    Cordialement

  2. Emmanuel 5 novembre 2014 à 22:22 #

    Bonjour

    J’essaye depuis un moment d’utiliser le recepteur en l’allimentant en 5V, mais mon GPIO n’apprecie pas trop de recevoir le signal en 5V.
    il fonctionne parfaitement avec le 3,3v, mais la portée est de qqes metres maxi

    Sur la photo, je crois voir une resitance. un pont diviseur ?
    ça fonctionne sans pb ?

    Merci

    • Yohann CIURLIK 5 novembre 2014 à 22:28 #

      La résistance sert juste à alimenter la LED.

      Malheureusement, j’ai le même problème de réception, j’ai même réalisé une antenne de 32cm (1/2 longeur d’onde) hélicoïdale mais je ne gagne que quelques mètres de plus, rien de bien transcendant.

      Il semblerait que le récepteur Aurel AM RX-4M50RR30SF soit de meilleur qualité mais aussi plus cher (30€). Je cherche confirmation avant de me lancer dans son achat.

  3. Emmanuel 5 novembre 2014 à 22:33 #

    J’ai vu une version qui montait en 12 et reconvertissait en 3,3 via un transistor et la personne avait une bonne portée.
    J’ai pas les compétences pour me lancer sur ce sujet.
    Je vais deja tenter le 5V et un pont diviseur de tension pour le GPIO.

    Sinon pour 30€ je conseillerais plutot un SDR type RTL2838
    c’est un dongle USB qui capte une large frequence pour 15€ maxi.

    • Yohann CIURLIK 5 novembre 2014 à 22:36 #

      Bon à savoir, effectivement le module peut être alimenté de 3,3v à 12v, du coup avec un transistor on peut sûrement redescendre à 3,3v sur la sortie data associée au GPIO.

      D’autant plus intéressant que je souhaite dédié (je viens juste de réaliser le montage) la partie émission/réception RF à un Arduino.

  4. AmeniIng 26 décembre 2014 à 0:50 #

    Salut, Bravo pour ce tuto. je vous remercie de m’avoir clarier tant de chauses :D.
    en suivant vos instructions, et lors dinstallation de la lib : 433Utils du site github, il me demande un login et un mot de passe. que doit je ecrire??
    Merci

  5. Philarete 3 janvier 2015 à 21:19 #

    Hello,
    merci pour le tuto: j’ai suivi le tracé scrupuleusement et je suis content sur mon B+ d’être parvenu à lire les trames OTIO sans problème. Par contre, rien d’autre: ni chacon, ni clé, etc….
    Maintenant, j’hallucine complètement sur l’émetteur: si je fais un codesend X alors que je viens de RFsniffer X, il ne se passe rien. J’ai mis deux LEDS de contrôle, et les deux clignotent simultanément (côté émetteur et récepteur), mais je ne lis rien.
    Si je prends le code lu chiffre par chiffre, je peux émettre & lire jusqu’à 6 chiffre du code (sur 9 lus).
    Par exemple, si je reçois d’un interrupteur « 905628953 » (youpi 🙂
    et que je fais « ./codesend 905628953 »
    Par contre, si je fais « ./codesend 90 », je RFsniffe « 90 », puis « 905 » etc … jusqu’à « 90562 »
    C’est y que j’ai pas compris quelque chose ??
    Merci pour le coup de main et
    bravo pour le blog.

    • Yohann CIURLIK 3 janvier 2015 à 22:33 #

      Hello,

      C’est sûrement dû au fait que ‘codesend’ envoi les codes sur 24 bits alors qu’il faut les envoyer en 32 bits. Il faut faire mySwitch.send(code, 32); au lieu de 24 :
      https://github.com/ninjablocks/433Utils/blob/master/RPi_utils/codesend.cpp

      Ecrit ton code sur la base de codesend, d’ailleurs je pense que Chacon utilise un protocole différent. OTIO c’est le protocole 2.

      • philarete 3 janvier 2015 à 22:53 #

        Yeeeeeeeees
        Merci 🙂

  6. Philarete 4 janvier 2015 à 8:50 #

    Hello (bis),
    Rajouter une résistance de 10k sur la masse du receveur, c’est peut être une bonne idée non ? Le receveur matche en 5v et tous les sites ont l’air de dire que le gpio marche en 3.3.
    Courage

    • Emmanuel 4 janvier 2015 à 9:58 #

      Hello (ter)

      Apres de nombreuses expérimentations, je pense avoir compris comment la bete fonctionne :
      Qu’il soit alimenté en 3.3v ou 5v, la sortie logique a 1 est autour de 1.20v.

      -> pas besoin de faire un pont reducteur de tension pour le 5v, on perdrait meme l’etat haut (je crois que le seul du gpio est autour de 1v)

      Par contre, a 5V c’est bourré de bruit. J’ai mis du temps a trouver l’info.
      Le bidule 433 utilise un AGC (Automatic Gain Control) qui amplifie le signal meme qd il n’y a rien sur la ligne.
      Bilan : Une quantité énorme de bruit.

      MAIS 🙂
      Si on regarde le signal du OTIO (allez voir Blyss ou Advisen, c’est pareil)
      Il y’a un préambule HAUT de 5000ms.
      D’ailleurs tous les signaux a 433mhz on ce genre de préambule.
      Je pense que la raison est simple et permet de gerer l’AGC.
      En restant dans un etat haut assez longtemps, l’AGC se cale sur le bon signal.
      On est ensuite sur que le signal est un signal et non du bruit.

      -> Toujours attendre le signal haut de 5000 avant de lancer la détection.

      Sinon,je ne sais pas ou tu en es Yohan sur le passage sur Arduino.
      Mais c’est unn vrai plus !
      Mon raspberry etait vraiment trop occupé par le decodage.
      L’Arduino est une super solution : il s’occupe du signal et retourne juste le code via un Serial.print()

      J’ai un bout de code basé sur DecodeOOK de Jeelab si ça vous interesse

      Manu

      • Philarete 4 janvier 2015 à 10:15 #

        Hello (etc),
        Le préambule HAUT, c’est pas le codage de manchester ? (Pour un signal binaire, 1010 on convertit en 11101110 pour être sûr d’éliminer les parasites)
        Sinon, moi je suis intéressé par le transfert vers Arduino. J’ai testé la bibliothèque en revanche, et je ne vois pas grand chose alors qu’avec le pi, c’est allé tout seul.

        • Emmanuel 4 janvier 2015 à 15:25 #

          Si on veut être « basique » une communication se fait sur 2 étapes :
          1) On définit un support physique de communication (le son, les ondes, la lumiere…)
          2) On définit ensuite une couche logique : comment coder l’information qui va se balader sur le support physique.

          Le préambule, je le vois plus comme un support physique du signal.
          C’est une sorte de porteuse qui annonce le début d’un signal.
          Il est régulier, simple et facilement identifiable par des objets a 2€

          Le codage manchester sert a transmettre de l’informaton.
          C’est de la couche logique : comment coder un 1 ou 0
          il en existe d’ailleurs pleins: Otio utilise un truc différent pour coder ses 1 et 0
          1 = High + 2 Low
          0 = High + 1 Low

          Je vais poster mon sketch sur Github.
          il décode 2 signaux pour le moment : un thermometre LIDL et mes commandes OTIO pour le chauffage.
          Mon objectif est de fabriquer un Dongle Telldus pour 10€ max

          il me reste aussi la partie emission.

  7. Philarete 4 janvier 2015 à 20:44 #

    Ok, c’est intéressant: courage.
    J’ai réussi aujourd’hui à utiliser l’arduino en réception et à émettre du raspberry en émulant les codes maison (HouseCode et Otio). Du coup, comme j’ai un Tellnet, j’ai réussi à créer une dummy device que je peux switcher On/Off depuis le PI. Bon, c’est déjà pas mal: avec un cron, on peut émuler un timer sans prendre la version pro !

  8. Philarete 5 janvier 2015 à 10:25 #

    Re,
    une question encore, toute bête.
    J’étais content hier de pouvoir interagir avec mon Tellnet: j’émets depuis le Pi et je reçois sur Arduino (comme ça, je suis sûr que je transmets).
    Bref, si je reçois un code en 32 bits du genre 975065231, je fais un codesend en 32 bits du même message et Oh miracle, ça s’affiche sur la console Arduino.
    Mais…. il ne se passe rien côté récepteur Otio dans le mur. Nib, le calme plat.
    Ma question est donc la suivante:
    – est-ce que l’interrupteur devrait réagir, ou faut-il que je l’associe au module mural ?

    • emmanuel 5 janvier 2015 à 10:46 #

      Bonjour,

      En theorie : OUI

      En pratique :
      1) le recepteur est il a la bonne distance ?
      La présence d’une antenne est ultra importante.
      Il faudrait verfier en séparant Arduino et Rapsberry de la meme distance.

      2) Le code est il le bon ?
      J’ai remarqué qu’Il y’a 2 codes « On » et 2 codes « Off »
      Un en mode uniquement ce switch, l’autre en mode « Batch »
      Le mieux est d’utiliser la télécommande à proximité du Arduino pour verifier que c’est le bon.

      3) RC Switch est il capable de bien analyser le protocole ?
      Là j’en sais rien.
      Imaginons que le code soit sur 36bits et que RC Switch s’arrete a 32
      alors il manque 4 bits que le récepteur ne vera jamais.

  9. philarete 5 janvier 2015 à 12:10 #

    Ok,
    merci 😉
    J’ai donc séparé les deux animaux dans deux pièces, à 7 mètres l’une de l’autre.
    Plus de réception. J’ai donc soudé une antenne en cuivre sur l’émetteur (17,3 cm, que j’ai récupérée sur un vieil interrupteur OTIO) et là, miracle, ça remarche: l’émetteur voit le récepteur et reçoit le message.
    C’est là que ça se gâte.
    Je m’explique. J’ai l’impression que RCSwitch « parle » en natif le « home easy », mais que ça ne colle pas complètement avec Otio. En fait, j’ai RFsniffé des codes en 32 bits que j’arrive à repdroduire et à recevoir mais qui ne font rien avec les prises murales ».
    En revanche, j’ai « vu passer » une trame (telldus ?) en 24 bits qui m’a permis d’allumer et d’éteindre deux radiateurs (dans une pièce lointaine, d’ailleurs).
    Du coup, ça pose le problème que tu évoquais des trames trop courtes. En plus, si on émet en 24 bits, on est vu par Telldus; jamais en 32.
    Je vais bidouiller dans la journée, si ça peut vous intéresser….

  10. philarete 5 janvier 2015 à 18:16 #

    Bon, me revoilà avec une petite avancée: j’ai réussi à commander toutes mes prises Chacon en émulant les codes existant. Ouf !
    Pour ce, j’ai compilé le code de http://www.homautomation.org/2013/10/09/how-to-control-di-o-devices-with-a-raspberry/#comment-662
    Puis, je suis allé dans ma config Telldus et j’ai récupéré tous les HouseCodes et les Unitcodes qui figuraient dans la liste. Attention, subtilité suédoise: Unitcode 1 = Unit 0 …
    Par exemple, si vous avez un Housecode: 1234569 avec UnitCode: 1, il faudrait lancer un « send 0 1234569 0 on ». Du coup, dialogue en direct avec mes unités installées.
    Le rapport avec Otio ?
    J’y viens:
    Telldus a enregistré les housecodes Otio. Il ne capte pas les télécommandes (comme nous), mais il est associé avec chaque device Otio. Il y a donc un moyen de communiquer avec les prises en utilisant ces codes. La seule différence que j’entrevois pour l’instant, c’est qu’avec Otio c’est donc du 32 bits et Chacon/Dio en 64. Enfin, je crois.

  11. Philarete 6 janvier 2015 à 17:46 #

    Ok, j’arrive à piloter tous mes récepteurs. Merci à spawrider pour le coup de main. Voilà le working code pour piloter les OTIO en ligne de commande (sudo ./send 012345678)
    ———————–
    #include
    int main(int argc, char *argv[]) {
    int PIN = 0;
    int systemCode = atoi(argv[1]);
    if (wiringPiSetup () == -1) return 1;
    RCSwitch rf_cmd = RCSwitch();
    rf_cmd.enableTransmit(0);
    rf_cmd.setProtocol(2);
    rf_cmd.setRepeatTransmit(15);
    rf_cmd.setPulseLength(700);
    rf_cmd.send(systemCode, 32);
    }
    ——————
    Je n’avais pas compris les protocoles… Bref, ça roule pour les OTIO et les CHACON (protocol 1).

    donc je récapitule la démarche
    1/ sniffer les codes avec « receive advanced » de HRCswitch (avec H, hein: https://github.com/maditnerd/HRCSwitch )

    2/ Récupérer les codes Otio. En fait, il y a pour chaque récepteur un code pour ouvrir et un code pour fermer

    3/ utiliser le code compilé ci-dessus et faire sudo ./send 012345678 et hop ! la lumière s’allume, le chauffage aussi et tout, et tout.

    Bon, maintenant, récupérer les codes oregon scientifique et tout faire fonctionner ensemble.

    Adieu

  12. ck10 18 janvier 2015 à 16:05 #

    Bonjour,

    Merci bien pour la petite astuce pour faire fonctionner des appareils à RF de n’importe quelle marque sur RPI.

    J’ai un petit soucis, que je n’arrive absolument pas à comprendre par contre…

    J’ai un Raspberry avec Domoticz d’installé dessus.

    J’ai réussi à cloner le code de la télécommande de ma prise avec RFSniffer, puis à allumer/éteindre la prise grâce à codesend.

    Histoire de faire simple, j’ai écrit un petit script shell pour lancer la commande codesend 3fois de suite pour être sûr que la prise s’allume.
    Lorsque j’exécute moi-même mon petit script, 0 soucis. Je peux allumer ou éteindre.

    J’ai ensuite écrit un petit script en LUA dans Domoticz pour exécuter mon script bash qui est censé allumer/éteindre ma prise.

    Rien ne se passe, et ça marche une fois sur 30, si j’arrive à allumer je ne peux plus éteindre… Bref c’est chaotique.

    Mais là où je suis plus qu’étonné, c’est que si je lance le sniffer, je remarque que quand je lance la commande ON/OFF depuis domoticz, mon script est bien exécuté, et je vois mon code s’exécuter normalement, comme si je lançais le script à la main sauf que… la prise ne réagit pas.

    Comment expliquer cela ?? Si l’émetteur envoie le code, la prise ne devrait faire aucune différence entre le code envoyé par le script exécuté par moi, ou par Domoticz…

  13. Zeverybest 24 janvier 2015 à 8:43 #

    bonjour
    Cette solution m’intéresse pour l’évolution de ma domotique
    Malheureusement je ne maîtrise pas le Ç
    Quelqu’un a t il fait des script en Python pour récupérer et émettre les code de télécommande ?

  14. Raspi 24 janvier 2015 à 17:05 #

    Bonjour,

    J’ai une petite question je débute sur raspberry

    J’ai suivi le tuto a la lettre mais le problème c’est que RFSniffer ne me renvoi rien telecomande a 1cm pourtant j’ai vérifier mes câblages plusieurs fois.

    Mon module 433mhz est défectueux ou alors il y a une manip a faire pour activer les gpio ?

    Merci beaucoup d’avance.

  15. Zeverybest 26 janvier 2015 à 16:15 #

    J’ai le meme probleme

    J’ai mis une LED en parrallele au la sortie data pour voir et la LED clignote lorsque j’actionne une telecommand

    Mais auncun code retourné par RFSniffer

  16. deennoo 7 février 2015 à 12:16 #

    Salut

    Je suis sur ce sujet depuis septembre 2014

    En premier la led sur le récepteur branchée au gpio

    Si l alim est en 3.3v la led consomme trop et rfsniffer sur les gpio ne voit rien.

    Enlever la et rfsniffer sniffera !

    Moi aussi je suis intéresser par un rfsniffer sur arduino, qui créé une base de donnée, et un script qui update mes devices domoticz, car le rfx com ne gère pas tous les protocoles pt2262 lors que Rcswitch oui.

    Reste a gérer les codes « parasites » ou n autoriser que ceux déjà enregistré.

    Dans le wiki de domoticz il y a un exemple de lecture du port série d’un arduino

    Pour codesend et domoticz, je donne un exemple fonctionnel ici (a partir du moment ou codesend fonctionne)

    http://www.domoticz.com/forum/viewtopic.php?f=6&p=31718

  17. Seb0unet 2 mars 2015 à 10:31 #

    Bonjour,

    J’ai le même problème que Raspi, RFSniffer ne renvoi rien 🙁 pourtant si je branche une LED sur « data » ça clignote.

    Es-ce qu’il faut configurer les GPIO dans un mode spécial ? ou bien RFSniffer lui préciser le pin ?
    Je suis branché en 5V (j’ai essayé en 3.3V) avec un raspberry version 1B (Es-ce suffisant ?).
    J’ai même racheté des modules XY-MK-5V au cas où…

  18. DMike92 27 mars 2015 à 18:02 #

    Bonjour,
    J’ai le même problème mais j’ai la chance de disposer d’un vieil oscilloscope.
    J’ai alimenté le récepteur en 5V et mis une résistance en série vers le pi (10 kOhms).

    A l’entrée de la broche 13 du connecteur (sur un Pi B+) je vois un magnifique signal carré lorsque j’appuie sur une télécommande (ouverture de portail type JolyOpen).
    Mais RFSniffer reste définitivement muet 🙁
    Si je branche directement la broche 13 sur + 3,3V je peux voir que Pi la voit bien en tapant :
    gpio read 2 (ou gpio readall et en regardant dans le tableau l’état de la broche 13).

    Lorsque je n’appuie sur rien, la sortie du récepteur 433 présente beaucoup de parasites (qui montent jusqu’à 1). Cela pourrait-il être la cause (Sniffer trop occupé !) ?

    D’avance merci de vos lumières 🙂

    Et, si je trouve, je viens ici.

  19. starjuice 6 juin 2015 à 12:34 #

    Bonjour,

    Apparement on a tous le même problème…

    Je pense que le problème vient de trop de parasites malgré que j’habite en pleine campagne… 😮

    J’ai donc essayé de changer ma source d’alimentation usb, j’ai branché le module sur mon Rpi. Là même clignotement de led sans action de ma part.

    Puis j’ai branché sur une batterie de secours de téléphone et là, la led reste allumée fixe et quand j’utilise une télécommande elle se met à clignoter puis s’éteint et se rallume fixe. ( la led s’éteint également sur mon PC et le RPi).

    J’ai vu un post qui disait que l’on pouvait supprimer les parasites en soudant une résistance de plus d’1 mégaOhm sur les pin 3 et 4 du LM358. http://www.touteladomotique.com/forum/viewtopic.php?f=118&t=15760

    Ce que j’ai fait avec une résistance de 330Mohm.(J’avais que ca).
    La led ne semble plus parasitée. Quand j’appui sur une télécommande 433 (Simu, Faac, Adyx) elle s’allume et clignote.

    Mais ca ne marche pas sur rfsniffer ni sur arduino avec RCswitch.

  20. cege 12 septembre 2015 à 18:52 #

    salut
    je pense que c’est parceque RFSniffer filtre les codes.
    Par défaut il doit être en 24bits protocole 1 je suppose.
    Donc il faut un sniffer plus universel ou au moins en 32bits.
    Je vais essayer HRSwitch mais je n’aime pas trop les forks.
    a plus

    • DMike92 12 septembre 2015 à 20:31 #

      Effectivement.
      Depuis j’ai avancé : Sur un site, j’ai pu voir qu’on pouvait enregistrer le sortie du récepteur 433 MHz sur l’entrée audio. L’énorme intérêt c’est qu’on peut enregistrer un certain temps, voire un temps certain :-). On peut alors très facilement examiner les codes reçus et on a tout son temps et on peut avoir un bonne idée des durées.
      Je me suis alors rendu compte que RFSniffer n’était pas en cause, ni ma télécommande mais bien les codes que j’avais enregistrés dedans.
      Comme tu dis ils n’étaient pas compris par RFSniffer (il y en a tout un tas).

      J’ai donc acheté un module Arduino nano (4 euros) sur lequel j’ai branché le récepteur et j’ai réussi à décoder tous me signaux. Non pas que je sache quel protocole est utilisé mais en mettant une suite de 1 et de 0 je peux très facilement arriver à savoir qui dit quoi (par apprentissage).

      En plus j’ai pu voir comment brancher l’Arduino Nano sur le Raspberry pour qu’il écoute (et enregistre) les codes reçus du Nano.

  21. Steff 27 septembre 2015 à 12:19 #

    Salut
    Genial le tuto
    j ai fais plusieurs tests de mon coté. je recois bien les codes du RFSiffer
    et pour d’autres prise autre que OTIO ca fonctionne bien.
    Mais voila !!! je veux faire fonctionner du OTIO
    je recois bien les codes mais la prise ne reagit pas au codesend.
    Je ne comprends pas car tout semble OK vu que ca marche sur d autres prises.
    Si vous avez une solution je prends
    Merci

  22. Emmaanuel 18 octobre 2015 à 14:28 #

    Solution interessante.
    De mon coté, j’ai fait évoluer la solution en utilisant un attiny en plus du RPi.

    http://www.emmaanuel.com/Domotique-DIY-2-Controle-des

  23. FrThib 25 janvier 2016 à 22:50 #

    Bonjour
    Procédure intéressante et très claire mais malheureusement cela ne fonctionne pas pour moi . Il est vrai que je n’utilise pas le système Otio mais un smart home mmv-100 avec télécommande TEL-010 , j’ai voulu essayer pour voir .
    Le protocole semble bien verrouillé avec ce système.
    Merci pour le tp . Si quelqu’un a une idée je suis preneur
    François

  24. Nicolas_a 1 août 2016 à 19:41 #

    Salut
    J’ai un petit soucis, je bloque au niveau de l’emission du signal.
    J’ai le 09HA14.
    J’ai reussi à recuperer les codes mais lorsque je les envoie, rien ne se passe. Le sniffer les voit bien passer mais c’est tout, les volets restent figés.
    J’ai bien modifié le codesend.cpp avec :

    int main(int argc, char *argv[]) {

    // This pin is not the first pin on the RPi GPIO header!
    // Consult https://projects.drogon.net/raspberry-pi/wiringpi/pins/
    // for more information.
    int PIN = 28;

    // Parse the firt parameter to this command as an integer
    int code = atoi(argv[1]);

    if (wiringPiSetup () == -1) return 1;
    printf(« sending code[%i]\n », code);
    RCSwitch mySwitch = RCSwitch();
    mySwitch.enableTransmit(PIN);

    mySwitch.send(code, 32);

    return 0;

    }

Laisser un commentaire

Time limit is exhausted. Please reload the CAPTCHA.