Il a pas de risque a dialoguer sur un port serie dans tous les cas c’est le seul point d’entrée et de sortie. même principe sur un ESP …
De tout façon je crois pas que l’on accès à l’interface graphique du rfxflash depuis Jeedom
Bonjour
Je m’inscruste ici pour poser une petite question sur les trames rfxcom. J’ai ce genre de trame:
[2020-11-30 16:44:14][DEBUG] : Message: 08 20 0A 73 99 51 75 06 69
[2020-11-30 16:44:14][DEBUG] : Decode : 08 20 0A 73 99 51 75 06 69
[2020-11-30 16:44:14][DEBUG] : Test message: 08 20 0A 73 99 51 75 06 69
[2020-11-30 16:44:14][DEBUG] : PacketType: 20
[2020-11-30 16:44:14][DEBUG] : SubType: 0A
[2020-11-30 16:44:14][DEBUG] : SeqNbr: 73
[2020-11-30 16:44:14][DEBUG] : Id1: 99
[2020-11-30 16:44:14][DEBUG] : Id2: 51
[2020-11-30 16:44:14][DEBUG] : Decode data : {'status': 'Panic', 'raw': '08200A739951750669', 'battery': '9', 'signal': '6', 'subtype': '0A', 'packettype': '20', 'id': '995175'}
Ou encore celle-ci:
[2020-11-30 15:35:44][DEBUG] : Message: 0A 52 07 18 CF 0E 00 6B 47 03 69
[2020-11-30 15:35:44][DEBUG] : Decode : 0A 52 07 18 CF 0E 00 6B 47 03 69
[2020-11-30 15:35:44][DEBUG] : Test message: 0A 52 07 18 CF 0E 00 6B 47 03 69
[2020-11-30 15:35:44][DEBUG] : PacketType: 52
[2020-11-30 15:35:44][DEBUG] : SubType: 07
[2020-11-30 15:35:44][DEBUG] : SeqNbr: 18
[2020-11-30 15:35:44][DEBUG] : Id1: CF
[2020-11-30 15:35:44][DEBUG] : Id2: 0E
[2020-11-30 15:35:44][DEBUG] : Decode data : {'temperature': '10.7', 'raw': '0A520718CF0E006B470369', 'battery': '9', 'signal': '6', 'humidity': '71', 'subtype': '07', 'packettype': '52', 'id': 'CF0E'}
[2020-11-30 15:35:44][DEBUG] : Send to jeedom : {'devices': {'CF0E52': {'temperature': '10.7', 'raw': '0A520718CF0E006B470369', 'battery': '9', 'signal': '6', 'humidity': '71', 'subtype': '07', 'packettype': '52', 'id': 'CF0E'}}}
Je voudrais savoir à quoi correspondent les données PacketType et SubType, et surtout où trouver la liste de ce à quoi ils correspondent (je suppose que cela donne le protocole utilisé). J’ai cherché, mais je ne parviens pas à trouver cette liste.
Merci
Pour répondre simplicitement
PacketType c’est comme la marque
Subtype le modele
Il y des infos dans le RFXtrx_User_Guide_-_FR V5.68
name: « 0x20 : 0x0A » : « RM174RF,RM175RF »
name: « 0x52 : 0x07 » : « TFA TS34C/Cresta/Honeywell TS33C »
Merci de ta réponse. Je m’attendais à trouver un listing de tous les Packettype et subtype, mais je ne trouve rien dans le user guide (ça fait 4 fois que je le lis)… tu sais où je peux trouver cela?
Pour la physionomie de la trame rfxcom, si j’ai bien tout compris:
0A: longueur de la trame, ici 10
52: Packettype (donc la marque)
07: Subtype (donc le modèle)
18: N° de séquence (incrémenté à chaque message)
CF 0E 00: ID (le 00 à la fin semblerait être du padding dans le cas d’un ID à 3 octets)
6B: température (107, donc 10.7)
47: humidité (71)
03: ???
6: signal
9: battery
Déjà, à quoi correspond le 03?
Serait-il correct de résumer une trame rfxcom comme ceci (autrement dit, est ce que toutes les trames rfxcom sont construites comme ça?):
AA BB CC DD EEEEEE FF… GG
Avec:
AA: longueur de trame
BB: Packettype
CC: subtype
DD: N° séquence
EEEEEE: ID
FF…: datas (longueur selon AA moins les autres, par exemple, si AA vaut 12, FF sera codé sur FF FF FF FF FF)
GG: signal & battery
Merci
A peu prés pour le début pour les 4 octets, mais il y a des variantes de longueur d '« ID »
Le signal « RSSI » et batterie normalement sur le dernier octet , pas toujours présent (00)
La longueur de la trame est calculée sur la longueur qui commence à 0 pour le 1er octet, c’est comme si elle ne comptait pas , mais doit toujours être présente
Donc cela fait 11 dans la trame
OK donc j’ai plus ou moins compris la chose, merci à toi de ta confirmation.
Pour le premier octet, j’avais déduit qu’effectivement il ne comptait pas dans le total.
Pour le dernier, j’ai vu effectivement le 0 pour la battery (pas le signal par contre, je ne l’ai pas constaté sur les équipements).
Et pour la table de correspondance des packettype et subtype, tu sais si cela existe?
Oui mais elle est privée ( @Loic en a une) , moi je récupère avec l’API du RFXPLAYER
La partie Haute de l’octet est le « RSSI » et la base la Batterie
Et pourquoi qu’elle est privée d’abord?? 
C’est curieux de ne pas diffuser ce genre d’info (ceci explique pourquoi je ne le trouve pas dans la doc).
@loic si tu passes par là, tu peux partager la doc détaillée? Merci
Si tu veux avoir ceux que le plugin décode, tu peux « fouiller » dans le plugin , elle sont pratiquement en clair
Hello,
Il y a longtemps de ça, le dev de RFXCom donnait le SDK (la fameuse doc « privée ») sur simple demande part mail. J’en ai un exemplaire qui doit dater d’il y a 5 ans environ.
Mais malgré plusieurs demandes de ma part depuis, plus de réponse du dev. Je ne sais pas s’il a décidé d’arrêter de donner la doc (je ne vois pas ce qu’il a à y gagner) ou s’il reçoit tellement de demandes ou de spam qu’il a arrêté de répondre aux mails des individuels.
Bref, en tout cas si quelqu’un veut bien partager sa doc, je suis preneur (en MP). Je peux aussi partager la mienne (toujours en MP), mais elle n’est vraiment plus à jour pour les nouveaux protocoles.
1 « J'aime »
Tu aurais un lien ou une doc STP ? Ça doit pouvoir permettre de remonter au détail des protocoles que le RFX connait.
Bonjour
Malheureusement non rfxcom n’a pas autorisé la diffusion en public je ne peux donc pas me permettre de le faire.
C’est d’ailleurs pour ça qu’avant le plugin n’était pas basé sur la doc car jeedom étant open source en le basant sur la doc les personnes peuvent faire du reverse pour avoir une idée de la doc…
Merci de ta réponse Loic
Pour ce qui de API du RFXPLAYER , suite à l’abandon du projet repris par Zieblue , je crois que cela doit être possible de divulguer ? n’est-ce pas @Loic bien qu’elle soit indiquée CONFIDENTIAL sur toutes les pages, mais il y a toujours le brouilleur (Jamming detection) qui serait suivi ?
A voir en privé
un aperçu V1.14
Pour ziblue je peux pas dire je n’ai pas la doc et jamais travaillé dessus désolé…
Pas grave, pour info j’ai suivi le projet depuis le début, je connais bien la "bête "
Merci Akenad, mise à jour effectuée aujourd’hui sur RFXtrx433E en 1043 Pro 1.
1 « J'aime »
Bonjour et merci pour ce retour d’expérience.
Je l’ai lu avec attention, mais un problème persiste depuis cette mise à jour.
Voici la situation :
J’ai deux sondes Oregon qui émettent. Le Rfxcom les reçoit bien les infos, mais régulièrement (plusieurs fois par jour) cette erreur apparaît dans les logs :
Message:
Exception in thread Thread-4:
Traceback (most recent call last):
File « /usr/lib/python3.7/threading.py », line 917, in _bootstrap_inner
self.run()
File « /usr/lib/python3.7/threading.py », line 865, in run
self._target(*self._args, **self._kwargs)
File « /var/www/html/plugins/rfxcom/resources/rfxcomd/rfxcomd.py », line 160, in read_rfxcom
if jeedom_utils.dec2hex(message[0]) != « 0x00 »:
IndexError: index out of range
A partir de ce moment, il ne reçoit plus les trames de mes sondes.
Je suis alors obligé de relancer le démon.
Jeedom et le plugin Rfxcom sont bien à jour, ainsi que le Rfxcom en lui-même (1043).
J’ai bien réinstallé les dépendances après les mises à jour.
Voilà, si quelqu’un a une idée, je suis preneur.
Merci.
1 « J'aime »
C’est à cause de ça …
faut voir le log