Intégration périphérique protocole inconnu RFXCom

Salut tout le monde !
J’ai fini par réussir à intégrer dans mon Jeedom les fonctions de 2 boutons d’une télécommande pilotant mon spot de piscine (inutile donc indispensable).

Le sujet a déjà été abordé ici comme ailleurs mais j’ai pourtant eu énormément de mal à trouver un « tuto » simple et clair pour réaliser une implémentation d’un périphérique utilisant un protocole non géré nativement par RFXCom.

J’ai donc acheté un RFXtrx433XL qui pour le coup est très simple à intégrer à Jeedom.
Je tente alors d’intégrer ma télécommande, il s’agit d’une PHOX4-333 :

image

Je me balade alors dans les options du plugin, comprend qu’on peut activer en écoute certains protocoles mais pas tous car ils peuvent se gêner les un les autres, je joue avec ces protocoles mais rien a faire, je ne vois jamais la télécommande apparaitre.

Je me rends donc sur le site du fabriquant du boitier et je débute la lecture de la doc.
On voit bien le tableau qui indique la compatibilité entre les protocole et surtout on apprend à se servir de RFXmngr et de RFXflash.

J’active dans RFXmngr le protocole « undec on » après avoir établi la connexion avec le RFXCom et j’appuie sur un bouton de la télécommande.
J’obtiens une entrée (que j’aurais pu voir dans jeedom avec le mode debug), ou je peux voir que le protocole utilisé est Oregon3 et je lis sur un forum anglais qu’il n’est pas « décodé » (est-ce le bon terme ?) nativement par le boitier, voir même pas supporté … Visiblement ce OREGON3 ne semble pas faire partie du lot de protocoles OREGON pris en charge par le RFXCom, car même avec la case OREGON cochée (par défaut), ça ne suffit pas.
J’avais vraiment ce type d’info (UNDECODED OREGON3) avant les étapes qui suivront dans le tuto :

image

Je parcours la doc et au paragraphe 16 je lis ceci :

image

On apprend que le firmware Pro permet d’afficher en clair les trame avec message RAW et que pour fonctionner, il faut que le périphérique n’utilise pas de code tournant (en gros des trames au contenu différent à chaque fois, donc différentes grâce un algorithme comme le RTS de Somfy).

Petit tour au paragraphe 2.2.2 qui traite des capacité des différents firmware et hop je flash mon RFXCom avec le firmware pro1 pour la version XL (car il semble pouvoir recevoir et transmettre avec plus de protocoles).

Rebelote ==> RFXmngr / protocole « undec on » / appuie sur le bouton de la télécommande.

Cette fois ci j’ai quelque chose de plus verbeux et effectivement j’ai mes paquets RAW qui apparaissent (3 à chaque clic).
Je vous passe les détails et je vais à l’essentiel, en vous basant sur la doc paragraphe 16. Receive en transmit RAW data, vous pourrez potentiellement obtenir le nécessaire pour créer votre commande Jeedom.

Je le met en copie sait on jamais :


Je me lance dans l’analyse de mon paquet.
Je n’ai plus la capture initiale sous la main mais pour faire simple et en se basant sur l’exemple 1 cité plus haut, la trame se compose de toutes ces infos :

image

Il faut donc copier coller dans un fichier txt toute la chaine principale (le gros bloc jaune).
Mais ce n’est pas tout. Avant cette chaine il faudra insérer 0 1 xxxxxxxxxxxxxxx (xxxxx étant la chaine).
Pourquoi ?
0 = RAW Packet ou 1 = Second RAW Packet (trames multiples) ==> correspond à la propriété « Packet Type »
1 = Nombre de répétitions ==> Correspond à la propriété « Repeat »

Dans mon fichie text, je fait un saut de ligne après chaque digit (en script ou a la mimine à vous de voir) et je fais bien attention à ne pas avoir de caractère non désiré en début ou fin de fichier.

Il a donc cette tête :

image

Si c’est le bon message et qu’il est bien construit, dans RFXmngr direction l’onglet « Raw transmit », puis Go, puis je sélectionne mon fichier texte fraichement créé et je joue ma requête.

WAW la piscine s’allume, cool …

Au final, sur les 3 paquets RAW, un seul suffisait pour réaliser l’action.
Pour les commandes nécessitant l’enchainement de paquets RAW, je n’ai pas pu le tester mais il me semble que l’on peut les chainer via la configuration avancée de la commande :

image

Dans la fenêtre jaune de RFXmngr j’ai ma requête émise qui apparait.
On y est, la commande à utiliser dans Jeedom correspond à RAW transmit command :

Direction le plugin RFXCom dans Jeedom, puis « Ajouter », je créé mon nouvel équipement, je l’active, je vais dans « Commandes », j’en créé une nouvelle de type action, je la nomme et dans le champ « Commande » je C/C la chaine hexa telle quelle est apparue dans RFXmngr :

Voila c’est fait, j’ai paramétré un bouton de ma télécommande et je peux désormais allumer mon spot depuis Jeedom.

En espérant que ça aide du monde !

6 « J'aime »

Haha ! Je viens d’intégrer mes 2 portes de garage (moteur futurcom) et un comportement étrange m’a forcé à trouver une solution originale !
Là aussi pas d’intégration facilité possible (ou en tout cas je n’ai pas trouvé comment faire), donc passage par RFXmngr et capture des trames.
Mode « undec on », je repère les signaux provenant de la télécommande et ouvrant la première porte.
Nous somme sur du type :
Packettype = Security2
subtype = Classic KeeLoq

J’active donc le protocole KeeLoq et remarque qu’en appuyant sur la télécommande, j’ai 2 trames bien distinctes qui ressortent : ouvrir/fermer et stop.
Le message est composé de 9 digits (IDs) et je vois bien qu’entre les 2 types de trames, 2 digits sortent du lot :

image

L’ID3 s’incrémente à chaque appui, l’ID8 correspond bien à la différence entre stop et ouvrir / fermer.

Je créé donc mes 2 commandes et constate assez vite que je dois chainer le stop avant ouvrir / fermer. Ainsi m’a commande ouvrir / fermer gère la séquence et j’obtiens le même comportement que ma clé : un clic le portail bouge, un autre il se stop et un troisième il bouge dans l’autre sens.

L’ID3 ne semble avoir aucune incidence ici.

Je me dis que pour l’autre porte de garage (2eme bouton sur la télécommande, ça va être aussi simple).
Que nenni ! Cette fois - et j’ai beau le faire depuis Jeedom en debug ou RFXmngr - il n’y a qu’un seul type trame qui part !

L’ID8 reste inchangé ici, seul l’ID3 s’incrémente. Je vous passe tous les essais possibles et imaginables et j’en viens à la conclusion.
Même moteur, même télécommande mais comportement différent. A force de tests, je me rend compte que la même trame envoyé au second portail agira pour les 2 types d’actions possibles (ouvrir / fermer et stop). Par contre entre 2 commande, il est impératif que l’ID3 évolue.
La bonne nouvelle c’est que le récepteur il accepte malgré tout les mêmes valeurs !

J’étais parti initialement sur une séquence qui appelé un scénario qui gérait une variable Jeedom afin de lui affecter toujours une valeur différente de la fois précédente, mais je n’ai pas été capable d’utiliser cette foutu variable pour cet usage (intégration de la variable dans la commande envoyée). Ça à toujours été interprété comme du texte.
Je suis donc parti sur une solution hyper « simple » et redoutable, le curseur !

Mon ID 3 était bloqué à 161 (A1 en hexa) lors de mes tests. J’ai donc mis une valeur à mon slider de 1 à 9 pour affecter à la volée à l’ID3 une valeur allant de A1 (161) à A9 (169).

Ma commande du coup est construite ainsi :

On voit le A (premier caractère de mon ID3) et #slider# qui vient récupérer la valeur du curseur et changer à la volée le contenue de la commande.

Le bouton ressemble à ça :

image

Désormais il me suffit de toucher le curseur en différent points, une fois pour ouvrir, une fois pour stopper (si besoin) et une fois pour fermer.

C’est étrange mais ça fonctionne. :sweat_smile:

Edit: j’ai testé avec les actions de type Liste (car ça permettre de mettre du text et donc une grosse fourchette de digit en Hexa et donc moins de chance de retomber 2x sur la même valeur), mais je ne parviens pas pour le coup, à utiliser la variable #listvalue# comme j’utilise #slider#.
Peut être que ce n’est pas la bonne variable pour récupérer l’élément sélectionné dans la liste ? J’ai tenté également #select#, mais avec adminer je n’ai pas trouvé de billes supplémentaires.

Edit2: je suppose que pour qui maîtrise le bloc code dans un scénario, il aurait été plus propre d’envoyer la commande via l’API directement au boîtier RFXCom, avec une gestion propre de l’ID3.
Je n’ai hélas pour l’heure par les compétences, mais si quelqu’un veut bien nous éclairer ?

A la lecture de cet article ça me confirme un doute que j’avais, a savoir que ça ressemble à du rolling code :

Malgré tout, je ne dépasse jamais A9 pour l’ID3 et au delà de ça, je peux réutiliser la commande une fois sur 3 avec la même valeur. Et pour finir, la télécommande reste fonctionnelle malgré plusieurs essais… vous en pensez quoi les experts ?

bonjour à tous, je suis en train de vouloir piloter mon portail en utilisant RFX com, je n’obtiens un signal qu’en mode undec, mais c’est comme s’il était vide, il n’y a que ça, pas de contenu de trame, les cinq séquences qui semblent identiques… je débute donc c’est peut-être un truc simple que je ne connais pas…

Packettype = RAW transmit
Packet Length = 68
subtype = RAW transmit
Sequence nbr = 3
Repeat = 1

image

J’ai essayé avec les firmwares pro1 et pro2, pas plus d’infos…

Est-ce que quelqu’un sait ce que ça veut dire et comment je peux l’exploiter ?

En pensant que mon portail se contentait peut-être d’un message vide, j’ai fait un fichier texte ne contenant que 0 et 1 que j’ai envoyé mais cela crée un message beaucoup plus court que 68 paquets, donc ce n’est pas la solution.

image