DIO CH54552 et retour d'état (bt9) depuis MaJ RFXCom

Plugins Protocole domotique
1

Bonjour à tous,
encore et toujours le problème de retour d’état sur un module DIO (contact sec CH54552) depuis la MaJ du plugin RFXCom.
Je pense avoir à peu près tout lu sur le sujet dans le Forum et comme je ne suis pas d’accord avec la solution donnée qui détourne du vrai problème, je voudrais savoir quand une correction sera faite pour retrouver le fonctionnement précédent avec un vrai retour d’état donné par le module et pas par jeedom ?

Comme l’ont déjà dit d’autres utilisateurs DIO, précédemment avec le Logical ID à bt9 on avait le vrai état ON ou OFF, poussé par le module. C’est pratique parce que si l’état change par un événement externe à Jeedom, cela permet d’en être informé.
A présent, je peux avoir un état présenté dans Jeedom qui est l’inverse de l’état réel du module.

Pour info, n’ayant rien trouvé de mieux, je suis en équipement 0x11 : Prise Chacon, l’action ON sur Logical ID 0B110000#ID#09010F90 et l’action OFF sur Logical ID 0B110000#ID#09000090

Merci de prendre en compte ce problème de retour d’état.

2

Bonjour,

Vous êtes SUR de VOUS ?

Car il n’y a pas de retour d’état sur ces modules (c’est l’une des GROSSES lacunes de ce protocole).

  • Un module de ce type ne fait qu’écouter, il ne parle pas.
  • A l’inverse d’une sonde, qui ne fait que parler, sans écouter.
  • Ou une télécommande, qui ne fait que parler, sans écouter

C’est ce qui ce dit partout en plus. Aurions nous tous tord ?

3

Il y a quand même le DIO 54700 qui te permet de connaître l’état d’ouverture de chacune de ses entrées.
Je m’en sers pour gérer ma BAL.

4

Oui, mais lui, tu ne le commandes pas ?
- c’est « juste » une télécommande.

Relis bien ma précédente réponse.

1 « J'aime »
5

Oui oui, je suis affirmatif, avant la MaJ j’avais le retour d’état en bt9 sans avoir ajouté le lien vers la commande d’info Etat dans les paramètres des commandes d’action ON et OFF.

C’est tellement vrai qu’après la MaJ je ne comprenais pas pourquoi je n’avais plus l’état correct, il était toujours à OFF alors que visiblement le contact était bien à ON.
J’utilise ce contact sec pour piloter le circulateur de mon chauffage, c’est facile à voir quand il est ON ou OFF.

En lisant le forum j’ai vu que je n’étais pas le seul dans ce cas et j’ai utilisé la « solution » de gestion de l’état par Jeedom mais j’ai rencontré des cas où l’état se désynchronisait.
Par exemple lors des coupures de courant, le module passe à OFF lorsque le courant revient alors que mon Jeedom étant derrière onduleur n’a pas de changement d’état et reste dans l’état avant coupure (qui peut être ON).

6

bt9 est un « faux » retour d’état, il est l’état de la commande ON/OFF, hors, si vous ne branchez pas votre module, l’état passe bien ON et OFF (alors que cela n’est pas possible).

Regardez ici :
Chacon DiO 54552 - Module encastrable actionneur à contact sec avec minuterie réglable intégrée DiO 1 à 433MHz - www.domotique-store.fr (domotique-store.fr)
- Lisez le commentaire de Domotique-Store

Je pense sincèrement, que vous vous trompez sur les retours d’états de ces modules.

7

Je ne vois pas de commentaire sur la page référencée, juste un avis et un commentaire de l’équipe sur cet avis. Le commentaire parle plus du Chacon 54700 que du 54552 et je ne vois pas comment le 54700 aurait pu récupérer tout seul l’état du 54700 (mais je ne suis pas un pro …)

On doit être trop peu à utiliser ce genre de module et avoir le problème de remontée d’état, je vois d’ailleurs que le post https://community.jeedom.com/t/retour-detat-depuis-mise-a-jour-rfxcom/44736 a été fermé.
Il n’y a plus qu’à croiser les doigts qu’une désynchronisation n’intervienne pas.
Cependant j’aimerais savoir comment font ceux qui utilisent un moyen de commande physique et Jeedom pour piloter ce type de module. J’imagine que l’état ne les intéresse pas et peut-être même qu’ils ne l’affichent pas et n’ont pas de scénario associé dans Jeedom.

8

Le commentaire parle en général de ce type de module. Comme indiqué, il n’y a pas de retour d’état.

Et pour ceux qui on des commandes externe (comme moi par exemple) j’ai rusé. Soit je passe par l’API du module soit, dans le cadre de la télécommande par exemple, elle actionne un scénario qui lui actionne la prise. Ainsi, j’ai un « faux » retour d’état qui est toujours OK.

Sauf que, si le module n’est pas présent, cela ne change RIEN, toute la chaine est leurrée, car il n’y pas de vrais retour d’état.

Ce qui à changé chez moi, c’est que, avant la mise à jour, j’avais une commande info ETAT et depuis la mise à jour du plugin RFXCom, cela m’a créé automatiquement des BT3 ou BT9 en fonction de la façon que j’avais inclus le module. J’ai donc juste changé les virtuels pour prendre en compte cette nouvelle commande à la place de l’état que j’avais moi même créé.

Mais je vous assure, il n’y a pas de VRAIS retour d’état sur ces modules.

9

Soit je suis complètement miro soit je ne comprends plus rien !
C’est du commentaire suivant dont tu parles ?

Bonjour, Nous vous remercions pour votre avis. Malheureusement, le Chacon 54700 ne dispose pas de fonction minuterie intégrée et c’est plutôt du côté actionneur que cette fonction est parfois présente. Exemples de modules intégrant une minuterie : Intertechno ITL-1000 (compatible Chacon DiO 433) avec un minuterie réglable à partir de 2s ou Chacon 54552 avec une minuterie réglable à partir de 1s. Cela serait d’autant plus fiable que le protocole radio Chacon DiO émet parfois pendant plus d’une seconde et qu’il n’est pas évident d’envoyer 2 commandes à 1 seconde d’intervalle. De plus, contrairement au protocole « Z-Wave », plus fiable et performant, le protocole Chacon DiO1 n’a pas de système « d’accusé réception » (ACK) avec retransmission automatique en cas d’échec : si le OFF qui suit le ON n’est pas reçu, le module pourrait rester en position ON jusqu’à la prochaine commande. En revanche, s’il s’agit d’une minuterie intégrée à l’actionneur, il y a certitude que la sortie repassera bien à OFF après le ON. N’hésitez pas à nous demander conseil si vous avez d’autres demandes particulières. Bien cordialement, Jérôme, Service Clients domotique-store.fr

C’est le seul commentaire que je trouve sur la page que tu références.

10

C’est juste cette phrase qu’il faut prendre en compte.

L’expert RFXcom arrive :slight_smile:

11

Il n’y a pas de "retour d’état’ sur ce module, il n’y a pas d’info de retour comme les EDISIO

Le btx correspond au numéro de la commande de groupe, pour toi (après #ID# 09) donc bt9

  1. Avec quoi commande tu ton module ?

  2. Si tu as une télé cde, effectivement que le btx se met à jour .

Le RFXCOM ne peut pas lire une info en même temps que l’on envoie une commande, tu auras une info virtuelle si tu forces l’état de l’équipement dans la cde ( du ON ou OFF)

12

Pour moi un ACK dans un protocole de communication n’a rien à voir avec la capacité ou non d’un équipement à fournir son état sur commande. C’est juste que l’équipement n’acquitte pas l’émetteur qui lui a envoyé une information pour lui signifier qu’il l’a bien reçue et que l’émetteur n’a donc pas besoin de lui renvoyer.

13

C’est juste l’abréviation du mot : acknowledge (dans ce cas précis accusé de récèption, retour d’état, ou reconnaitre).

Cela fait des années que tout le monde indique que ce protocole n’a pas de retour d’état, je pense que si cela n’était pas vrais, cela serait visible.

14

Pour votre information:
J’ai fait implémenté l’information d’acceptation d’une commande par le RFXCOM, si vous avez le log de votre commande (mode « debug »)
Appuie sur On d’une cde 0x11 00

0741|[2021-02-08 18:00:48]DEBUG : Message received in socket JEEDOM_SOCKET_MESSAGE
0742|[2021-02-08 18:00:48]DEBUG : Test message: 0B1100F100C1327A04010177
0743|[2021-02-08 18:00:48]DEBUG : flushOutput serial port
0744|[2021-02-08 18:00:48]DEBUG : flushInput serial port
0745|[2021-02-08 18:00:48]DEBUG : Write message to serial port
0746|[2021-02-08 18:00:48]DEBUG : Write data to serial port : 0b1100f100c1327a04010177
0747|[2021-02-08 18:00:48]DEBUG : Write message ok : 0B1100F100C1327A04010177
0748|[2021-02-08 18:00:48]DEBUG : Message: 040201f100
0749|[2021-02-08 18:00:48]DEBUG : Decode : 040201f100
0750|[2021-02-08 18:00:48]DEBUG : Test message: 040201f100
0751|[2021-02-08 18:00:48]DEBUG : PacketType: 0x02
0752|[2021-02-08 18:00:48]DEBUG : Length: 5
0753|[2021-02-08 18:00:48]DEBUG : Start decoding packet type 0x02
0754|[2021-02-08 18:00:48]DEBUG : Subtype = Reponse du Transmetteur
0755|[2021-02-08 18:00:48]DEBUG : Data : {'packetlen': '0x04', 'packettype': '0x02', 'subtype': '0x01', 'seqnbr': '0xF1', 'msg1': '0x00'}
0756|[2021-02-08 18:00:48]DEBUG : Reponse du Transmetteur  = 0x00
0757|[2021-02-08 18:00:48]DEBUG : Message Transmis
 Vous voyez le message Transmis , cela ne veut pas dire que le module lui, a reconnu cette commande, mais que le RFXCOM l'a transmis !```
15

Voici la cde depuis Jeedom avec un Bt9

0747|[2021-02-08 18:08:11]DEBUG : Message read from socket: b'{"apikey":"Doubledom","cmd":"send","data":["0B1100F100C1327A09010F77"]}'
0748|[2021-02-08 18:08:11]DEBUG : Client disconnected from [127.0.0.1:58830]
0749|[2021-02-08 18:08:11]DEBUG : Message received in socket JEEDOM_SOCKET_MESSAGE
0750|[2021-02-08 18:08:11]DEBUG : Test message: 0B1100F100C1327A09010F77
0751|[2021-02-08 18:08:11]DEBUG : flushOutput serial port
0752|[2021-02-08 18:08:11]DEBUG : flushInput serial port
0753|[2021-02-08 18:08:11]DEBUG : Write message to serial port
0754|[2021-02-08 18:08:11]DEBUG : Write data to serial port : 0b1100f100c1327a09010f77
0755|[2021-02-08 18:08:11]DEBUG : Write message ok : 0B1100F100C1327A09010F77
0756|[2021-02-08 18:08:11]DEBUG : Message: 040201f100
0757|[2021-02-08 18:08:11]DEBUG : Decode : 040201f100
0758|[2021-02-08 18:08:11]DEBUG : Test message: 040201f100
0759|[2021-02-08 18:08:11]DEBUG : PacketType: 0x02
0760|[2021-02-08 18:08:11]DEBUG : Length: 5
0761|[2021-02-08 18:08:11]DEBUG : Start decoding packet type 0x02
0762|[2021-02-08 18:08:11]DEBUG : Subtype = Reponse du Transmetteur
0763|[2021-02-08 18:08:11]DEBUG : Data : {'packetlen': '0x04', 'packettype': '0x02', 'subtype': '0x01', 'seqnbr': '0xF1', 'msg1': '0x00'}
0764|[2021-02-08 18:08:11]DEBUG : Reponse du Transmetteur  = 0x00
0765|[2021-02-08 18:08:11]DEBUG : Message Transmis

Voici la réception du même code (produit par une télécde)

0762|[2021-02-08 18:15:24]DEBUG : Message: 0b11000b00c1327a09010f70
0763|[2021-02-08 18:15:24]DEBUG : Decode : 0b11000b00c1327a09010f70
0764|[2021-02-08 18:15:24]DEBUG : Test message: 0b11000b00c1327a09010f70
0765|[2021-02-08 18:15:24]DEBUG : PacketType: 0x11
0766|[2021-02-08 18:15:24]DEBUG : Length: 12
0767|[2021-02-08 18:15:24]DEBUG : Start decoding packet type 0x11
0768|[2021-02-08 18:15:24]DEBUG : Subtype = AC KlikAanKlikUit,HomeEasyUK,Chacon,NEXA,Intertechno
0769|[2021-02-08 18:15:24]DEBUG : Data : {'packetlen': '0x0B', 'packettype': '0x11', 'subtype': '0x00', 'seqnbr': '0x0B', 'id1': '0x00', 'filler1': '0x00', 'id2': '0xC1', 'id3': '0x32', 'id4': '0x7A', 'unitcode': 9, 'cmnd': 1, 'level': 15, 'filler2': 0, 'rssi': 7}
0770|[2021-02-08 18:15:24]DEBUG : Decoded info : {'packettype': '0x11', 'subtype': '0x00', 'id': '00C1327A', 'unitcode': 9, 'cmnd': 1, 'level': 100.0, 'rssi': 7}
0771|[2021-02-08 18:15:24]DEBUG : Device is known id : 00C1327A
0772|[2021-02-08 18:15:24]DEBUG : Send to jeedom : {'devices': {'00C1327A11': {'packettype': '0x11', 'subtype': '0x00', 'id': '00C1327A', 'unitcode': 9, 'cmnd': 1, 'level': 100.0, 'rssi': 7}}}
0773|[2021-02-08 18:15:24]DEBUG : Starting new HTTP connection (1): 127.0.0.1:80
0774|[2021-02-08 18:15:24]DEBUG : {"devices":{"00C1327A11":{"packettype":"0x11","subtype":"0x00","id":"00C1327A","unitcode":9,"cmnd":1,"level":100,"rssi":7}}}
16

Je suis désolé mais vous confondez deux choses : le type de protocole et les capacités d’interrogation d’un équipement.
Ce que je comprends c’est que le protocole DIO 1.0 est sans gestion de flux, comme l’UDP (broadcast) si on prend l’exemple d’une couche transport du modèle OSI et contrairement au TCP. Le TCP dispose d’une gestion de flux, basée entres autres sur des acquittements des messages (ACK).
Ce n’est pas parce qu’on s’appuie sur un protocole de communication sans acquittement que pour autant on ne peut pas avoir une communication bi-directionnelle et des échanges de données.
C’est typiquement le cas d’applications qui reposent sur l’UDP : NFS, TFTP, DNS, SNMP …
Cela repose sur un modèle du type « interrogation-réponse », la réponse pouvant être utilisée comme un accusé de réception à l’interrogation. S’il n’y a pas de réponse au bout d’un certain temps alors il y a réémission de l’interrogation. On peut donc avoir une communication sans gestion de flux, sans acquittement (ACK).

17

DOMMAGE VOUS PARTEZ UN PEU LOIN DANS VOTRE RAISONNEMENT !

Ce protocole n’as pas de retour d’information !

18

C’est cela, mais pas ici.

Le Z-Wave qui « aurait » cela, ne se comporte pas comme cela. Il arrive (et nous sommes pas mal dans ce cas) à devoir renvoyer une commande marche / arrêt à un module Z-Wave qui pourtant devrais gérer cela en natif (mais visiblement, ne le fait pas).

J’ai trop vulgarisé pour vous, je le reconnais : la, il faut le prendre comme un accusé. Ce que n’a pas ce protocole, il ne sais pas dire dans quel état il est.

19

@Doubledom, je répondais à l’histoire du Ack de @Fabrice.
J’ai bien compris qu’il n’y avait pas possibilité de demander l’état à ces modules.
Il y a donc eu une hallucination collective au sujet de la capacité précédente du plugin à remonter cet état qui n’existe pas.
Ce n’est pas grave je vais bien trouver une façon de gérer ces désynchronisations.
Si quelqu’un sait où je peux trouver la spé détaillée de la messagerie DIO je suis preneur.
Bonne soirée à vous et merci pour le temps que vous passez à répondre aux questions des jeedomiens.

20

Pour information cela était écrit en dur dans le plugin, dans les versions précédentes, @Loic ayant mis à jour (refonte du plugin pour être au plus prés de la doc du RFXCOM) l’a supprimée. Donc maintenant on le fait par mise à jour du « btx » lors de l’envoie de la cde lui correspondant.
Si vous initié votre module avec une Télécde , Jeedom le reconnaitra et mettra l’info btx à jour, mais cela ne dit pas que le module lui: a accusé réception du message et l’a commandé .