NetCreek

Historique

Les technologies utilisées ont été initialement développées par Siemens qui décida en 2001 de créer une filiale nommée EnOcean détenant tous les brevets et chargée de continuer les développements. Puis en 2008 fut crée l'Alliance EnOcean dans le but de promouvoir la technologie et de fédérer les acteurs (fabricants, intégrateurs). Enfin, en 2012, la Commission Electrotechnique Internationale (CEI) ratifiait la norme ISO/CEI 14543-3-10 promulguant les technologies radio ultra basse consommation et la collecte d'énergie développées par EnOcean au rang de norme internationale.

Dès lors, tous les ingrédients étaient là pour favoriser l'essor de ce standard :

• La technologie de collecte d'énergie (energy harvesting) qui permet d'éviter les changements de piles. Un gros avantage par rapport aux autres technologies radio du marché, comme le très répandu Z-wave par exemple, dont on peut lire ici ou là que les modules sont assez énergivores.
• La multiplication des fabricants, attirés par la pérennité d'un protocole normalisé et la facilité d'intégration des modules EnOcean dans leurs produits.
• L'assurance pour les clients de disposer de multiples sources d'approvisionnement afin de ne pas se lancer dans une installation domotique qui représente un investissement important, sans avoir l'assurance de pouvoir la maintenir et la faire évoluer facilement.

Pourtant, d'autres facteurs limitent encore le développement de ce marché, à commencer par le prix des modules EnOcean qui reste élevé malgré une concurrence relative entre fabricants, ou encore l'esthétique discutable de certains équipements (boutons poussoirs par exemple).

Le prix d'un bouton poussoir EnOcean qui va de moins de 30 € à plus de 50 € selon le fabricant doit cependant être relativisé. J'ai constaté que chez NodOn, qui fabrique des boutons poussoirs EnOcean, mais aussi Z-Wave, le modèle Z-Wave était vendu 5 € plus cher que le modèle EnOcean. Si on ajoute à ce surcoût le fait que NodOn indique une durée de vie de la pile de 18 à 24 mois sur le BP Z-Wave, et que la pile CR2032 vaut 4 € chez Darty (et heureusement beaucoup moins cher sur internet), il vous en coûterait 40 à 50 € de piles pour 20 ans d'utilisation, soit le prix du BP EnOcean qui lui ne vous coûtera jamais rien en piles.

Energy harvesting

Derrière ces mots qui peuvent se traduire par collecte d'énergie, on trouve les différents moyens utilisés par les modules EnOcean pour générer leur propre énergie et réussir ainsi à se passer de piles. On trouve par exemple :

• L'effet mécanique (magnéto-résistif ou piézo-électrique) qui transforme l'énergie d'une pression mécanique en électricité. C'est la technique utilisée par les boutons poussoirs.
• L'effet photovoltaïque (mini cellule solaire secondée par une batterie miniature) qui transforme la lumière en électricité. C'est la technologie utilisée par les détecteurs d'ouverture, les sondes de température ou d'hygrométrie.
• L'effet thermo-électrique qui transforme par effet Peltier une différence de température en électricité. C'est la technologie utilisée par les électrovannes de régulation de chauffage.

Si ces principes innovants ont fait la réputation d'EnOcean, il n'en reste pas moins qu'ils peuvent aussi présenter quelques inconvénients. Ainsi, les boutons poussoirs EnOcean sont souvent plus durs à manoeuvrer que les boutons poussoirs classiques. De même, les capteurs équipés de cellules solaires ne peuvent pas être placés la ou la lumière est insuffisante. D'autant que si vous fermez la maison pendant vos congés, plus aucune lumière ne pourra recharger vos détecteurs d'ouverture. Plutôt gênant d'un point de vue sécurité. C'est la raison pour laquelle on peut souvent ajouter des piles dans ces capteurs. Mais il n'en reste pas moins très pratique de pouvoir placer une sonde de température et d'humidité en extérieur sans avoir à passer le moindre câble et sans devoir en changer les piles.

Un peu de théorie

Principe

EnOcean utilise un protocole de type Point à Multipoint (1 vers n), ce qui signifie que l’émetteur (le capteur) envoi un message qui sera écouté par tous les récepteurs (les actionneurs), mais traité par les seuls récepteurs qui ont été préalablement appairés avec l’émetteur.

L’émetteur ne se soucie pas de savoir s’il existe un ou plusieurs destinataires. Il n’a donc pas besoin d’être configuré. En revanche, chaque destinataire devra avoir été préalablement appairé avec les émetteurs qui le concernent, afin qu’il puisse les reconnaître.

Appairage

Le processus d’appairage le plus courant consiste à appuyer un bouton ou tourner un petit commutateur sur le récepteur afin de le placer en mode apprentissage. Il suffit ensuite de forcer l’émetteur à envoyer un message pour que le récepteur mémorise l’identifiant de l’émetteur. C’est tout. La même procédure répétée avec le même récepteur et le même émetteur aura l’effet inverse et supprimera l’émetteur de la mémoire du récepteur.

Il est donc possible de commander plusieurs récepteurs avec un même émetteur, de même qu'un récepteur peut mémoriser une trentaine d'émetteurs.

Identification des modules par le CHIP_ID

Chaque module EnOcean possède un identifiant unique sur 32 bits, que l’on nomme CHIP_ID, et qui est généralement imprimé en hexadécimal sur une étiquette collée sur le produit. Parmi les notations courantes on trouve par exemple 19F7D34A, ou 19.F7.D3.4A ou encore 19:F7:D3:4A.

C’est la présence de cet identifiant dans le télégramme (champ SENDER_ID) qui va permettre aux récepteurs d’identifier l’émetteur. Dans le télégramme, on trouvera également un champ DESTINATION_ID pour identifier le destinataire, mais comme celui-ci peut être multiple, ce champ contiendra l’adresse de broadcast FF.FF.FF.FF (sauf cas particuliers).

Le cas particulier des dongles EnOcean USB300/USB310

Imaginons que l'installation dispose d’un logiciel de supervision. Il peut s’agir d’une Box domotique, ou encore d’une simple application développée par vos soins pour interagir avec les modules. Votre application va utiliser un dongle USB300 ou USB310 pour dialoguer par radio avec les modules. D'un coté, ce dongle communique par radio en émettant et en recevant les messages EnOcean de type ERP (télégrammes radio), et de l'autre, il communique avec votre application via un port série virtuel créé par le driver FTDI intégré (à installer sur le PC). Vous voila donc capable d'émettre et de recevoir des télégrammes EnOcean en écrivant ou en lisant des trames sur un port série, à charge pour le dongle de convertir les trames en télégrammes radio.

Pour émuler un bouton poussoir et ainsi allumer une ampoule depuis votre application, vous pourriez penser qu’il suffit de placer le CHIP_ID d'un bouton poussoir déjà appairé avec l'actionneur de l'ampoule dans le champ SENDER_ID. Mais pour des raisons de sécurité, vous ne pourrez pas, via le dongle, envoyer une trame comportant le CHIP_ID d'un autre module. Ce serait de l’usurpation d’identité. C’est le dongle qui refusera d’émettre cette trame, en constatant qu’il s’agit d’un CHIP_ID qui n’est pas le sien. Car un dongle est un module EnOcean comme un autre qui dispose par conséquent de son propre CHIP_ID unique.

Identification du dongle par le CHIP_ID

Puisqu'on ne peut pas usurper le CHIP ID d'un module, la solution qui alors vient à l’esprit est de renseigner le champ SENDER_ID avec le CHIP_ID du dongle. Ainsi, sur le réseau, le dongle émettra sous sa propre identité. Bien sûr, vous prendrez la précaution d'appairer le dongle avec le récepteur (en plaçant l'actionneur en mode apprentissage et en envoyant une trame RPS depuis votre application). Cela fonctionne et vous pourrez allumer ainsi votre première ampoule.

Mais cette méthode pose très vite un problème de taille car vous voulez sans doute pouvoir allumer plus d'une ampoule, et certainement pas toutes les ampoules à la fois. Or à chaque appairage d'actionneur, c'est le même CHIP_ID du dongle qui sera stocké dans l'actionneur. Toute demande d’allumage émis ensuite via le dongle sera alors prise en compte par tous les actionneurs appairés et toutes les ampoules s'allumeront.

Identification du dongle par le BASE_ID

Pour contourner ce problème, on va pouvoir utiliser la notion de BASE ID dans le dongle en lieu et place du CHIP ID. Chaque dongle est en effet doté – en plus de son CHIP ID unique et non modifiable – d'un BASE ID qui peut se substituer au CHIP ID. Pour émettre avec le BASE ID plutôt que le CHIP ID, il suffit que l'application renseigne le BASE ID du dongle dans le champ SENDER ID de la trame, plutôt que le CHIP ID. Le dongle reconnaîtra son BASE ID et acceptera d'émettre sous cette identité.

Voici une astuce pour vos premiers tests. Pour allumer votre première ampoule sans vous prendre la tête, vous pouvez renseigner le champ SENDER_ID avec 00.00.00.00. Lorsque vous allez envoyer la trame, le dongle va automatiquement remplacer 00.00.00.00 par son BASE_ID et recalculer les checksums. De quoi arriver au premier résultat avec le minimum d’effort, puisque vous n'aurez même pas besoin de calculer les checksums.

L'intérêt de cette méthode, c'est qu'avec le BASE ID on dispose en fait de 128 adresses d'émission différentes. En effet, les BASE ID codés dans les dongles sont des identifiants espacés les uns des autres de 128 adresses. Un dongle est donc autorisé à utiliser son propre BASE ID ainsi que les 127 adresses qui suivent, sans empiéter sur d'autres BASE_ID.

Dans l'application, on pourra donc émuler 128 émetteurs différents en leur attribuant un identifiant interne de BASE_ID +0 à BASE_ID +127. Ainsi, on sera toujours sûr d'utiliser le même BASE ID unique pour un émetteur donné, tout en restant dans la plage autorisée pour le dongle.

Prenons un exemple. Au moment d’appairer le dongle avec l’actionneur de l’ampoule #1, on va envoyer via le dongle une trame dont le champ SENDER_ID contiendra le BASE ID du dongle +1, ce qui donnera FF.4C.E7.81 si le BASE ID du dongle est FF.4C.E7.80. Et pour l’appairage de l’actionneur qui commande l’ampoule #2, on va envoyer une trame dont le SENDER_ID contiendra le BASE ID du dongle +2. Ainsi, les deux actionneurs auront mémorisés des émetteurs différents (FF.4C.E7.81 et FF.4C.E7.82).

Si vous voulez allumer l’ampoule #1 avec votre application, vous placerez le BASE_ID FF.4C.E7.81 dans le champ SENDER_ID. La passerelle reconnaîtra un BASE_ID valide car faisant partie des 127 BASE_ID associés à son propre BASE ID et elle acceptera d’émettre la trame. Du coté des actionneurs, seul celui qui a été appairé avec le BASE_ID FF.4C.E7.81 traitera le message et seule l’ampoule #1 s’allumera.

Notez que pour simplifier les choses et éviter aux applications d'avoir à connaître le BASE_ID du dongle utilisé, EnoGateway (un module de la suite EnoSolution présentée sur ce site) autorise les applications à utiliser un identifiant relatif de 0 à 127 en lieu et place du BASE_ID du dongle, Avant d'émettre le message, EnoGateway ajoutera le BASE_ID du dongle à l'identifiant relatif transmis par l'application. A noter que l'identifiant relatif 0 aboutira à utiliser le propre BASE ID du dongle, tandis que les autres identifiants relatifs utiliseront les 127 adresses qui suivent le BASE ID. Ceci est tout à fait légal.

Si l'on souhaite émuler plus de 128 émetteurs dans l'application, il faudra utiliser plusieurs dongles afin d’augmenter le nombre de BASE_ID différents utilisables. Il faudra alors modifier EnoGateway pour qu'il soit capable de gérer plusieurs dongles. Mais n'oubliez pas qu'avec un même BASE_ID, vous pouvez envoyer 4 trames RPS différentes (pour les touches AI, AO, BI, BO). Vous pouvez donc envoyer jusqu'à 512 commandes RPS différentes avec un seul dongle.

Un peu de pratique

Récupérer le BASE_ID du dongle

Par programmation, le BASE_ID du dongle peut être récupéré en utilisant la commande CO_RD_BASEID qui est décrite dans la documentation du protocole ESP3..

Voici un exemple d'échange :

	[TX] - 55 00 01 00 05 70 08 38
	[RX] - 55 00 05 01 02 DB 00 FF E6 95 80 0A C0

Ici, le BASE_ID de la passerelle est FF.E6.95.80, il sera possible d'envoyer des commandes vers les actionneurs en utilisant les BASE_ID FF.E6.95.80 à FF.E6.95.FF.

Modifier le BASE ID du dongle

Drôle d'idée à priori que de vouloir modifier le BASE ID du dongle. Cela peut toutefois être utile, voire quasiment indispensable.

Imaginons que votre installation soit terminée et que votre application émule des dizaines de capteurs via les BASE ID transmis par le dongle et mémorisés dans les actionneurs. Que se passerait-il si votre dongle tombait en panne. Vous le remplaceriez par un autre bien sûr, mais le BASE ID du nouveau dongle étant différent du BASE ID de l'ancien, il émettra désormais vos messages avec une nouvelle plage de BASE ID, et plus rien ne fonctionnera puisque les actionneurs n'auront pas été appairés avec ce nouveau BASE ID. La solution consisterait à ré-appairer tous les actionneurs avec le nouveau dongle. Comme les actionneurs sont la plupart du temps encastrés dans les murs ou les faux plafonds, vous comprenez que cela ne se fera pas en 10 minutes.

Pour vous éviter ces tracas, il a été prévu une commande permettant de modifier le BASE ID d'un dongle.

Pour des raisons de sécurité, on ne peut pas changer le BASE ID plus de 10 fois.

N'oubliez pas de noter le BASE ID utilisé par votre dongle avant qu'il ne tombe en panne, si vous voulez être capable de le réécrire dans un autre plus tard (et sachez qu'EnoGateway mémorise ce BASE_ID dans son fichier log).

Retour à l'accueil