Intégration Linknx + RFXCOM 433MHz

[alain]

Bonjour à tous

Pour info, je viens de faire un premier pas dans l'intégration d'un module RFXCOM RFXtrx433MHz avec Linknx. Ceci me permet de piloter des prises commandées Chacon (40€ les 3 prises). A mon avis, une bonne solution pour la rénovation.

Ce petit module RFXtrx 433 coûte un peu moins de 100€ . Il permet d'échanger (émettre et recevoir) avec pas mal de composants radio, dont les modules X10. J'ai fait un test hier : je peux également récupérer l'état de mes capteurs de fumée.

Module relié en USB à mon vieux NSLU2 qui tourne Linknx + un pont One-Wire + la téléinfo EDF (je vais bientôt migrer tout ça sur une USB Station Synology).

Premier pas d'intégration car, pour l'instant, je ne fais qu'émettre. Il reste à traiter la configuration du module (pour l'instant, sous Windows avec le logiciel de démo fourni), et la partie réception. 

Pour ceux que ça intéresse, voici les extraits de ma conf Linknx (1.30)

<?xml version="1.0" ?>

<config>

    <services>

        <ioports>

            <ioport id="rfxcom" type="serial" dev="/dev/ttyUSB2" speed="38400" framing="8N1" flow="none" />

        </ioports>

    </services>

     <objects>

        <object type="1.001" id="radio.prise-routeur-wifi.cmd" init="persist">Prise commandee radio - Routeur WIFI</object>

     </objects>

     <rules>

        <rule id="radio.wifi-on">

           <condition type="object" id="radio.prise-routeur-wifi.cmd" value="on" trigger="true" />

           <actionlist>

              <action type="ioport-tx" data="0B11002B004CB31603010F00" ioport="rfxcom" hex="true" />

           </actionlist>

        </rule>

        <rule id="radio.wifi-off">

           <condition type="object" id="radio.prise-routeur-wifi.cmd" value="off" trigger="true" />

           <actionlist>

              <action type="ioport-tx" data="0B11002B004CB31603000F00" ioport="rfxcom" hex="true" />

           </actionlist>

        </rule>

      </rules>

</config>

La chaîne "0B11002B004CB31603010F00" correspond à la trame radio attendue par les prises Chacon. On peut récupérer ça par copier/coller depuis le logiciel de démo RFXCOM. Mais elle sont faciles à décoder et à construire soi-même.

0B = longueur de trame, premier octet non compté

1100 = type de trame adaptée aux prises Chacon

2B = compteur, on met ce qu'on veut sauf 00

004CB316 = identifiant de groupe (entre 00000001 et 03FFFFFF) 

03 = identifiant d'item dans le groupe (entre 01 et 0F)

01 = ON (mettre 00 pour OFF, 04 pour GROUP-ON et 03 pour GROUP-OFF)

0F = niveau radio d'émission (entre 00 et 0F)

00 = niveau radio de réception (mettre 00 en émission)

Un gros intérêt des prise Chacon est leur prix (40 € pour 3 prises + 1 télécommande). Il existe aussi des douilles E27 télécommandées, et des petits modules à loger dans des boîtes de connexion.

Leur second est qu'elles sont autoconfigurables, c'est à dire qu'elles apprennent toutes seules les identifiants auxquels elles doivent répondre. Ainsi, dans mon exemple, l'identifiant est "004CB316". 

Leur inconvénient est l'absence de retour d'état. 

Il n'empêche : un petit serveur Linux, un module RFXCOM, Linknx + Knxweb et hop ! Voici un petit système domotique pas cher pour télécommander la maison de vacances. Le tout sans tirer un seul câble.

Bonne journée

Alain

 

[jef2000]

Excellente nouvelle. J'attendais avec impatience la disponibilité du tellstick duo pour pouvoir m'attaquer à ce genre d'intégration, mais le RFXtrx433 me semble parfait comme remplaçant.
En ce qui concerne la réception, je vais essayer de me pencher sur le problème un de ces jours. Pour l'instant, les possibilités de "matching" de ce qui est reçu sont un peu légères, il faudrait trouver quelque chose de fonctionnel et suffisamment générique pour pouvoir s'adapter a toute sorte de situations.
Le premier problème a attaquer est de définir ce qu'est un message. L'io-port reçoit un flux de données, comment détermine-t-on où commence et où se termine un message. Dans certains cas, c'est un "timeout" (si on ne reçoit plus de données pendant plus de x millisecondes, on  considère le message comme terminé.), dans d'autres cas c'est un byte/caractètre ou une séquence de bytes/caractères qui délimite les messages. Ensuite, dans le contenu d'un message, il faut pouvoir définir ce qui va rendre la condition vraie ou fausse. On pourrait utiliser une sorte de "pattern matching". J'imagine que pour certaines application il faudrait également pouvoir extraire certaines parties du message et les stocker dans des objets linknx. Tout l'art de la chose est de trouver le juste milieu entre fonctionnalité, complexité, (in)dépendance vis à vis de librairies externes, ....

Jean-François

[alain]

Bonsoir Jean-François

Dans le cas du 433 MHz, pour délimiter les messages, on peut partir sur un timeout de quelques centaines de millisecondes. C'est ce qui me semble le plus approprié dans le cas de réception de commandes radio évènementielles. 

Une reconnaissance de pattern pour détecter un début de message ne me paraît pas possible dans le cas du RFXtrx : il y a bien 3 octets de début de message (longueur / type / sous-type), mais leur valeur peut être confondue avec la valeur d'octets de données dans le cas d'une réception de message prise en cours de route.

Par contre, pour l'exploitation des données dans le message, je suis tout à fait d'accord avec toi : il est intéressant de pouvoir extraire des données pour alimenter des objects linknx (par exemple, pour récupérer des infos de station météo Oregon). La difficulté est la multitude de protocoles existants sur du 433 MHz. Le RFXtrx en traite une bonne vingtaines, tous assez bien documentés d'ailleurs.

Je pense qu'il faut pouvoir :

- spécifier l'emplacement et la taille d'identifiant du message -> permet de faire ensuite un lien avec l'identifiant de l'objet linknx

- spécifier l'emplacement, la taille et le type de la donnée

Je n'ai pas analysé tous les protocoles 433MHz supportés par le RFCtrx, mais si ça peut t'aider, je peux faire un récap pour voir si on peut faire un lien simple entre les types de données 433MHz et les types KNX.

A+

Alain

[jef2000]

Bonjour,

Je viens de publier une amélioration des io-port dans linknx. Elle permet plus de flexibilité pour réagir lors de la réception de données sur un ioport.
Elle devrait déjà permettre de faire pas mal de choses, notamment avec un RFXTrx.

J'ai ajouté des partamètres dans la définition de l'io-port:
<ioport id="rfxtrx433" type="serial" dev="/dev/ttyUSB0" speed="38400" mode="raw" timeout="100ms"/>

Dans les versions précédentes de linknx, le port série était en mode texte. Dans ce cas, les données ne sont reçues que lorsqu'on reçoit un caractère de fin de ligne, et certains caractères sont altérés (LF à la place de CR LF, etc...). En mode "raw", on reçoit toutes les données brutes, et on peut définir un timeout (entre 0 et 25.5 secondes par pas de 100ms). Lorsque plus aucune donnée n'est reçue pendant la période correspondant au timeout, le buffer de données est transmis à linknx.

Ensuite, j'ai ajouté la possibilité d'utiliser des expressions régulières dans les conditions.
<condition type="ioport-rx" expected="^0b1100..00e1100701......$" ioport="rfxtrx433" hex="true" regex="true" trigger="true"/>

Grace au paramètre hex="true", les données binaires reçues seront converties en texte hexadécimal, ce qui facilite grandement la gestion de messages binaires.
Si le paramètre regex est "true", la valeur du paramètre "expected" sera interprétée comme une expression régulière. Pour faire simple, ^ signifie "début du message", $ signifie "fin du message", le point remplace n'importe quel caractère. On peut faire des choses beaucoup plus complexes avec des expressions régulières, je ne vais pas tout expliquer ici (une recherche sur "posix extended regexp" devrait suffire).

Je continue a y travailler de manière à pouvoir extraire des données lors du matching et les assigner a des objets KNX (récupérer une température ou une consommation électrique par exemple)
Si quelqu'un a déjà joué avec un io-port linknx et la téléinfo EDF, un retour d'info m'intéresse pour savoir ce qu'il faut que je développe pour pouvoir exploiter la téléinfo directement en utilisant un io-port.

Jean-François

[alain]

Bonjour Jean-François

Je viens de récupérer les sources, et de lancer la compil. Je te tiens au courant pour les tests avec le RFXTrx en mode réception.

Concernant la téléinfo, j'étais en train d'adapter le logiciel de réception téléinfo que j'utilise pour lui faire générer des commandes XML et attaquer l'interface XML de linknx. Je vais donc mettre en standby :)

Côté paramètres de transmission, la liaison téléinfo est une liaison série à 1200 bits/s, 7 bits, parité paire, 1 bit de stop.

Une trame est composé d'un STX, d'une ligne par triplet token/valeur/checksum, et un ETX en fin de trame. Les trames sont émises en continu, c'est à dire que dès qu'une trame est terminée, le compteur commence à transmettre la suivante.

Par contre, si tu veux un support complet du protocole, il faut aussi tenir compte des trames prioritaires que le compteur émet en cas de dépassement du courant souscrit. Dans ce cas, le compteur interrompt la trame en cours, et attaque une trame portant des tokens spécifiques.

J'ai trouvé un site qui résume tout ça, plus un code source complet qui traite les trames normales et les trames d'interruption. 

- Description : http://vesta.homelinux.free.fr/site/wiki/demodulateur_teleinformation_edf.html

- Code source : http://vesta.homelinux.free.fr/site/wiki/teleinfoserial_csv.html

Toutes ces infos concernent la téléinfo émise par les compteurs électroniques actuels. Je n'ai pas encore trouvé d'info précise sur les futurs compteurs Linky, mais il semblerait qu'ils soient, eux aussi, équipés d'une sortie téléinfo.

J'espère que ces éléments t'aideront. Je te tiens au courant pour le RFXTrx.

Bon courage. 

Alain

[alain]

Bonjour à tous

Test effectuée pour la livrée de Jef. Tout fonctionne correctement : j'arrive maintenant à émettre (c'était déjà le cas) et à recevoir (c'est nouveau) des trames radio 433MHz.

Je vais donc pouvoir utiliser les télécommandes Chacon pour piloter n'importe quel objet géré par Linknx.

Pour info, je fais tourner Linknx et NSLU.

Merci à Jef pour cette modif.

Bonne journée

Alain

[fabrice]

bonjour a tous,

j'ai réussi a faire fonctionner 2 prise chacon avec le recepteur   RFXtrx433MHz  comme expliqué ci dessus merci deja pour ca

mais je me pose 3 question

1 serait-il possible d'avoir grace a une rule linknx par exemple d'enregistrer dans un GA (ets) le status de la lampe pour pouvoir utilisé cette GA avec Domovea par exemple (c'est un peu tordu mais bon :))

j'ai essayer de cree un GA vide dans ETS (a mon avis ca ne sufit pas il devrait y avoir une sorte d'objet virtuel dedans ou quelque chose du genre) et de faire un rules qui envoir un on ou un off suivant l'etat mais ca marche pas vraiment (et je me demande si c'est seulement possible :))

 <object type="1.001" id="prise_radio1_status" gad="12/3/1" init="request" log="true" flags="crwt">prise radio cuisine status</object>

 <object type="1.001" id="prise.radio1.cmd" init="persist">Prise cuisine commandee radio</object>

</rule>

     <rule id="radio.prise1-off">

          <condition type="object" id=" prise.radio1 .cmd" value="on" trigger="true" />

      <actionlist>

           <action type="ioport-tx" data="0710040b41010000" ioport="rfx433" />

           <action type="set-value" id=" prise.radio1_status" value="off" />

      </actionlist>

</rule>

<rule id="radio.prise1-on">

       <condition type="object" id="r prise.radio1.cmd" value="on" trigger="true" />

        <actionlist>

             <action type="ioport-tx" data="0710040c41010100" ioport="rfx433" />

                <action type="set-value" id=" prise.radio1_status" value="on" />

       </actionlist>

 </rule>

2 est-il possible d'utilisé des contact de fenetre Chacon (MT-02 par ex) avec ce fameux RFXtrx433MHz 

3 est-il possible d'exploiter la fonction DImer d'une prise chacon ?

merci

[knx...@gmail.com]

On lundi 04 juin 2012, fabrice wrote:

> 1 serait-il possible d'avoir grace a une rule linknx par exemple
> d'enregistrer dans un GA (ets) le status de la lampe pour pouvoir
> utilisé cette GA avec Domovea par exemple (c'est un peu tordu mais bon
> :))
>
> j'ai essayer de cree un GA vide dans ETS (a mon avis ca ne sufit pas il
> devrait y avoir une sorte d'objet virtuel dedans ou quelque chose du
> genre) et de faire un rules qui envoir un on ou un off suivant l'etat
> mais ca marche pas vraiment (et je me demande si c'est seulement
> possible :))

C'est tout à fait possible. Et tu n'as pas besoin de créer une GA virtuelle
dans ETS. Pour la rule, je ne sais pas trop ce qui cloche, mais tu dois
pouvoir y arriver.

Pour info, certains device KNX n'ont pas de base ETS ; ils se paramètrent
via un soft externe. Ils ont un certain nombre de GA rpé-définies, que tu
utilises dans ETS. Dans ton cas, ça revient exactement au même.

[fabrice]

mais si j'ai bien  compris le principe la valeur on/off ici ne se sauvegarde pas dans une GA mais dans un objet non ?

donc si je cree une GA 1/1/1 status radio vide comment catte GA va t elle garder la valeur envoyé ?

[alain]

Salut

Tu peux créer un objet dans Linknx qui n'a pas de GA. Dans ce cas, c'est Linknx qui garde la valeur à jour de l'objet. Il ne faut pas utiliser init="request", car Linknx ne peut pas aller sur le bus KNX demander l'état de l'objet.

Ensuite, tu pourras toujours commander l'objet par knxweb.

Mais si tu veux commander ton boîtier Chacon avec un interrupteur KNX, il te faut 

- un objet de commande (ton objet prise.radio1.cmd par exemple), avec GA, qui sera mis à jour par l'interrupteur KNX. Init="request" pour cet objet est correct.

- un objet de status (ton objet prise.radio1_status) avec ou sans GA, qui sera mis à jour par la <rule>. Init="persist" ok pour cet objet

Je ne connais pas Domovea, mais je suppose qu'il est capable de commander des GA. Si tu veux commuter ta prise Chacon avec une commande Domovea, il faut que Domovea utilise le GA de l'objet de commande. Linknx détectera le changement d'état avec les <rules>, et génèrera l'ordre radio qui va bien.

Une remarque concernant les modules Chacon. En cas de coupure d'électricité, ou si tu les débranchent, ils "oublient" leur état. Donc, au retour du courant, ils sont toujours initialisés à "OFF". Tu risques donc d'avoir, dans ce cas, un écart entre l'état réel du module et l'état dans lequel Linknx pense qu'il est. 

Concernant les contacts de fenêtres, il faut recevoir les trames radio. Ceci n'est par possible avec la v0.0.1.30, mais c'est possible avec la version de Linknx que Jean-François est en train de développer. Tu peux récupérer les sources dans le repository CVS de sourceforge, et ensuite compiler le tout (http://linknx.cvs.sourceforge.net/viewvc/linknx/linknx/linknx/src/)

Enfin, pour le dimmer, il y a 2-3 choses à prendre en compte :

- pour l'instant, Linknx ne sait pas insérer des valeurs d'objets dans les trames io-port (je crois que Jef y travaille)

- le dim Chacon est codé sur 4 bits, je crois que c'est différent en KNX, il faudrait donc faire une conversion de format

- Il faut consulter la doc du module RFXTrx433 pour voir la forme de trame à envoyer. Je sais qu'il est capable de le faire, mais je n'ai pas regardé le format.

Pour contourner le 1er point, la seule solution que je vois à court terme, mais c'est pas joli-joli, c'est de définir 16 rules, chacune construisant une des 16 trames radio possibles, une seule étant émise. Mais c'est pas bô !!

J'espère t'avoir aidé.

A+

[Anthony PENHARD]

> Enfin, pour le dimmer, il y a 2-3 choses à prendre en compte :
> - pour l'instant, Linknx ne sait pas insérer des valeurs d'objets dans les
> trames io-port (je crois que Jef y travaille)

a priori si il est possible d'insérer des object dans les data ioport envoyés
exemple
<action type="ioport-tx" ioport="ID_IOPORT" data="donnée
${id_object}" var="true"></action>


@+
Anthony

[alain]

Double Mea culpa. 

- tu as raison pour les io-port Tx. Il reste donc juste le problème de conversion de format. Peut être possible avec une formula.

- Jef bosse sur l'extraction de valeurs depuis les io-port Rx.

[fabrice]

bonjour,

j'ai réinstaller proprement le trio eib/linknx/knxweb2 (enfin aussi proprement que je puisse le faire :))

et j'ai un souci avec les prise radio chacon

j'ai essayer avec linknx .30 

http://linknx.cvs.sourceforge.net/viewvc/linknx/linknx/linknx/src/

mais je comprends pas pourquoi cela ne marche pas.

quand j'essaye avec le RFXmng.exe ca marche et voici le log du soft

pour le ON

0B110000003C9C3601010F50

The system is going down for reboot NOW!esmes.lan (pts/0) (Tue Jun 19 15:13:3

subtype       = AC

Sequence nbr  = 0

ID            = 03C9C36

Unit          = 1

Command       = On

Signal level  = 5

Lighting2 command:0B 11 00 18 00 3C 9C 36 01 01 04 00

------------------------------------------------

0402011800

Packettype        = Receiver/Transmitter Message

subtype           = Transmitter Response

Sequence nbr      = 24

response          = ACK, data correct transmitted

pour le off

------------------------------------------------

0B110001003C9C3601000040

Packettype    = Lighting2

subtype       = AC

Sequence nbr  = 1

ID            = 03C9C36

Unit          = 1

Command       = Off

Signal level  = 4

Lighting2 command:0B 11 00 19 00 3C 9C 36 01 00 04 00

------------------------------------------------

0402011900

Packettype        = Receiver/Transmitter Message

subtype           = Transmitter Response

Sequence nbr      = 25

response          = ACK, data correct transmitted

donc avec le soft ça marche 

mais si j’essaye avec linknx je vois bien les commande partir mais pas de reaction de la prise

config linknx

<ioports>

            <ioport id="rfx433" type="serial" dev="/dev/ttyUSB0" speed="38400" framing="8N1" flow="none" />

        </ioports>

 <object type="1.001" id="prise_radio_a1" init="persist">Prise Radio A1</object>

 <rule id="radio.prise.a1-off" init="false">

            <condition type="object" id="prise_radio_a1" value="off" trigger="true" />

            <actionlist>             

                <action type="ioport-tx" data="0B110019003C9C3601000400" ioport="rfx433" />

            </actionlist>

        </rule>

        <rule id="radio.prise.a1-on" init="false">

            <condition type="object" id="prise_radio_a1" value="on" trigger="true" />

            <actionlist>

                <action type="ioport-tx" data="0B110018003C9C3601010400" ioport="rfx433" />

            </actionlist>

        </rule>

et le log de linknx quand je teste

2012-06-19 15:36:56,292 [ INFO] Action: SetValueAction: Configured for object prise_radio_a1 with value on

2012-06-19 15:36:56,292 [ INFO] Action: Execute SetValueAction: set prise_radio_a1 with value on

2012-06-19 15:36:56,292 [ INFO] Object: New value on for object prise_radio_a1 (type: 1.001)

2012-06-19 15:36:56,293 [ INFO] Rule: Evaluate rule radio.prise.a1-off

2012-06-19 15:36:56,293 [ INFO] ObjectValue: SwitchingObjectValue: Compare value_m='1' to value='0'

2012-06-19 15:36:56,293 [ INFO] Condition: ObjectCondition (id='prise_radio_a1') evaluated as '0'

2012-06-19 15:36:56,293 [ INFO] Rule: Rule radio.prise.a1-off evaluated as 0, prev value was 1

2012-06-19 15:36:56,293 [ INFO] Rule: Evaluate rule radio.prise.a1-on

2012-06-19 15:36:56,293 [ INFO] ObjectValue: SwitchingObjectValue: Compare value_m='1' to value='1'

2012-06-19 15:36:56,293 [ INFO] Condition: ObjectCondition (id='prise_radio_a1') evaluated as '1'

2012-06-19 15:36:56,293 [ INFO] Rule: Rule radio.prise.a1-on evaluated as 1, prev value was 0

2012-06-19 15:36:56,293 [ INFO] MysqlPersistentStorage: Writing 'on' for object 'prise_radio_a1'

2012-06-19 15:36:56,294 [ INFO] Action: Execute TxAction send '0B110018003C9C3601010400' to ioport rfx433

2012-06-19 15:36:56,294 [ INFO] SerialIOPort: send(buf, len=24):0B110018003C9C3601010400

2012-06-19 15:36:58,179 [ INFO] Action: SetValueAction: Configured for object prise_radio_a1 with value off

2012-06-19 15:36:58,179 [ INFO] Action: Execute SetValueAction: set prise_radio_a1 with value off

2012-06-19 15:36:58,179 [ INFO] Object: New value off for object prise_radio_a1 (type: 1.001)

2012-06-19 15:36:58,179 [ INFO] Rule: Evaluate rule radio.prise.a1-off

2012-06-19 15:36:58,179 [ INFO] ObjectValue: SwitchingObjectValue: Compare value_m='0' to value='0'

2012-06-19 15:36:58,179 [ INFO] Condition: ObjectCondition (id='prise_radio_a1') evaluated as '1'

2012-06-19 15:36:58,179 [ INFO] Rule: Rule radio.prise.a1-off evaluated as 1, prev value was 0

2012-06-19 15:36:58,179 [ INFO] Rule: Evaluate rule radio.prise.a1-on

2012-06-19 15:36:58,179 [ INFO] ObjectValue: SwitchingObjectValue: Compare value_m='0' to value='1'

2012-06-19 15:36:58,179 [ INFO] Condition: ObjectCondition (id='prise_radio_a1') evaluated as '0'

2012-06-19 15:36:58,179 [ INFO] Rule: Rule radio.prise.a1-on evaluated as 0, prev value was 1

2012-06-19 15:36:58,180 [ INFO] MysqlPersistentStorage: Writing 'off' for object 'prise_radio_a1'

2012-06-19 15:36:58,180 [ INFO] Action: Execute TxAction send '0B110019003C9C3601000400' to ioport rfx433

2012-06-19 15:36:58,180 [ INFO] SerialIOPort: send(buf, len=24):0B110019003C9C3601000400

mais la la prise ne reagi pas

si quelqu'un a une idée ?

merci

Le dimanche 8 avril 2012 07:20:21 UTC+2, alain a écrit :

[jef2000]

Si mes souvenirs sont bons, tu dois ajouter le paramètre hex="true" dans l'action pour lui dire que les caractères dans data sont une description hexadécimale du message a envoyer:
<action type="ioport-tx" data="0B110019003C9C3601000400" hex="true" ioport="rfx433" />

Jean-François

[fabrice]

merci beaucoup effectivement avec hex="true" ca marche merci beaucoup

[fabrice]

bonjour,

alors je viens de remarquer un truc bizarre,

apres un reboot du serveur les data dans linknx.xml se modifie

avant le reboot toute les ligne "radio" fonctionne et son dans le format :

 <action type="ioport-tx" hex="true" data="0b110015003c9c3603000300" ioport="rfx433" />

               

et apres le reboot a ca ne marche plus car les ligne se sont transformé en :

 <action type="ioport-tx" hex="true" data="0b110015003cffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff9c3603000300" ioport="rfx433" />

               

bizarre, un bug ou une erreur de ma part ?