Site : tvaira.free.fr

EnOcean

La norme sans fil EnOcean est destiné aux capteurs et aux réseaux de capteurs sans fil à très faible consommation d’énergie. Elle est utilisée notamment dans le domaine de la domotique.

La norme sans fil EnOcean (ISO/ CEI 14543-3-1X) fonctionnant sur les bandes de fréquence inférieures à 1 GHz est optimisée pour une utilisation dans les bâtiments (portée radio de 30m en interieur est possible).

  • 868 MHz pour l’Europe et la Chine
  • 902 MHz pour l’Amérique du Nord
  • 928 MHz pour le Japon

L’Alliance Enocean promeut la seule norme de récupération d’énergie sans fil. Elle est dédiée aux solutions d’automatisation des bâtiments durables qui emploient cette technologie de récupération d’énergie sans fil. Rendant ainsi les bâtiments plus écoénergétiques, plus flexibles et donc plus économique.

Liens :

Protocole EnOcean ESP3

→ Téléchargement du protocole : EnOceanSerialProtocol3 (EnOcean ESP3)

L’ESP3 définit la communication série entre un hôte (host) et un contrôleur EnOcean. L’hôte est généralement un PC ou un système embarqué (microcontrôleur).

L’interface physique entre l’hôte et le module RF EnOcean (UART) est une interface série à 3 fils (RX, TX, GND). Le débit standard est de 57600 bauds (1 baud = 1 bit par seconde).

ESP3 est un protocole point à point avec une structure de données par paquets.

Trame UART

Une trame UART est constituée des bits suivants :

  • 1 bit de start (toujours à 0) servant à la synchronisation du récepteur
  • 8 bits de données (bits envoyés du LSB (bit de poids faible) au MSB (bit de poids fort))
  • 0 bit de parité (pas de parité)
  • 1 bit de stop (toujours à 1)

Les paramètres de configuration sont donc : « 57600 8N1 »

Paquet ESP3

La détection d’un paquet est réalisée sur les 6 premiers octets et commence toujours par la valeur de synbhronisation 0x55 :

Une vérification est réalisée sur l’entête (header) : si le CRC8H inclus dans la trame émise ne correspond pas au CRC8H calculé en réception, la trame doit être ignorée car celle-ci a été altérée.

Le contenu d’un paquet :

Les différents types de paquet :

Le CRC8H est calculé sur les octets des champs : DATA_LENGTH, OPTIONAL_LENGTH et TYPE. Il permet de détecter une erreur dans l’entête (header) du paquet. Le CRC8D est calculé sur les octets des champs : DATA et OPTIONAL_DATA. Il permet de détecter une erreur dans les données (data) du paquet.

Le checksum utilisé ici est en réalité un CRC (Cyclic Redundancy Check ou Contrôle de redondance cyclique) sur 8 bits (1 octet). C’est le reste de la division modulo 2 du polynôme G(x) = x^8 + x^2 + x^1 + x^0.

Le polynome est utilisé pour générer une table :

uint8_t u8CRC8Table[256] = {
    0x00, 0x07, 0x0e, 0x09, 0x1c, 0x1b, 0x12, 0x15,
    0x38, 0x3f, 0x36, 0x31, 0x24, 0x23, 0x2a, 0x2d,
    0x70, 0x77, 0x7e, 0x79, 0x6c, 0x6b, 0x62, 0x65,
    0x48, 0x4f, 0x46, 0x41, 0x54, 0x53, 0x5a, 0x5d,
    0xe0, 0xe7, 0xee, 0xe9, 0xfc, 0xfb, 0xf2, 0xf5,
    0xd8, 0xdf, 0xd6, 0xd1, 0xc4, 0xc3, 0xca, 0xcd,
    0x90, 0x97, 0x9e, 0x99, 0x8c, 0x8b, 0x82, 0x85,
    0xa8, 0xaf, 0xa6, 0xa1, 0xb4, 0xb3, 0xba, 0xbd,
    0xc7, 0xc0, 0xc9, 0xce, 0xdb, 0xdc, 0xd5, 0xd2,
    0xff, 0xf8, 0xf1, 0xf6, 0xe3, 0xe4, 0xed, 0xea,
    0xb7, 0xb0, 0xb9, 0xbe, 0xab, 0xac, 0xa5, 0xa2,
    0x8f, 0x88, 0x81, 0x86, 0x93, 0x94, 0x9d, 0x9a,
    0x27, 0x20, 0x29, 0x2e, 0x3b, 0x3c, 0x35, 0x32,
    0x1f, 0x18, 0x11, 0x16, 0x03, 0x04, 0x0d, 0x0a,
    0x57, 0x50, 0x59, 0x5e, 0x4b, 0x4c, 0x45, 0x42,
    0x6f, 0x68, 0x61, 0x66, 0x73, 0x74, 0x7d, 0x7a,
    0x89, 0x8e, 0x87, 0x80, 0x95, 0x92, 0x9b, 0x9c,
    0xb1, 0xb6, 0xbf, 0xb8, 0xad, 0xaa, 0xa3, 0xa4,
    0xf9, 0xfe, 0xf7, 0xf0, 0xe5, 0xe2, 0xeb, 0xec,
    0xc1, 0xc6, 0xcf, 0xc8, 0xdd, 0xda, 0xd3, 0xd4,
    0x69, 0x6e, 0x67, 0x60, 0x75, 0x72, 0x7b, 0x7c,
    0x51, 0x56, 0x5f, 0x58, 0x4d, 0x4a, 0x43, 0x44,
    0x19, 0x1e, 0x17, 0x10, 0x05, 0x02, 0x0b, 0x0c,
    0x21, 0x26, 0x2f, 0x28, 0x3d, 0x3a, 0x33, 0x34,
    0x4e, 0x49, 0x40, 0x47, 0x52, 0x55, 0x5c, 0x5b,
    0x76, 0x71, 0x78, 0x7f, 0x6a, 0x6d, 0x64, 0x63,
    0x3e, 0x39, 0x30, 0x37, 0x22, 0x25, 0x2c, 0x2b,
    0x06, 0x01, 0x08, 0x0f, 0x1a, 0x1d, 0x14, 0x13,
    0xae, 0xa9, 0xa0, 0xa7, 0xb2, 0xb5, 0xbc, 0xbb,
    0x96, 0x91, 0x98, 0x9f, 0x8a, 0x8D, 0x84, 0x83,
    0xde, 0xd9, 0xd0, 0xd7, 0xc2, 0xc5, 0xcc, 0xcb,
    0xe6, 0xe1, 0xe8, 0xef, 0xfa, 0xfd, 0xf4, 0xf3
};

Exemple de calcul de CRC :

#include <stdio.h>
#include <stdint.h>

#define START_CRC8H     1
#define LG_CRC8H        4
#define POS_CRC8H       5
#define POS_LG_OPT_DATA 3

int main()
{
    uint8_t u8Data[] = { 0x55, 0x00, 0x07, 0x07, 0x01, 0x7a, 0xf6, 0x10, 0x00, 0x25, 0x8a, 0xf8, 0x30, 0x00, 0xff, 0xff, 0xff, 0xff, 0x31, 0x00, 0xb6 };
    uint16_t u16DataLength = sizeof(u8Data);
    uint16_t u16DataSize = u16DataLength;
    uint16_t u16StartByte = 1;
    uint16_t u16PosCRC = 0;
    uint8_t u8CRC = 0;
    uint16_t i = 0;
    
    printf("Frame : ");
    for (i = 0 ; i < u16DataLength ; i++)
    {
        printf("0x%02X ", u8Data[i]);
    }
    printf("\n\n");
    
    u8CRC = 0;
    u16StartByte = START_CRC8H;
    u16DataSize = u16StartByte + LG_CRC8H;
    u16PosCRC = POS_CRC8H;

    printf("Datas : ");
    for (i = u16StartByte ; i < u16DataSize ; i++)
    {
        printf("0x%02X ", u8Data[i]);
        u8CRC = u8CRC8Table[u8CRC ^ u8Data[i]];
    }
    printf("\nCRC8H =  %02X\n", u8CRC); // calculé : 0x7a
    printf("CRC8H <- %02X\n", u8Data[POS_CRC8H]); // reçu : 0x7a
    
    // même principe pour le CRC8D ...
    
    return 0;
}

Code source : calcul-enocean-crc8.zip

Le paquet RADIO_ERP1 (0x01) encapsule le télégramme radio ERP1 :

Sa structure générale est la suivante :

La partie Radio telegram est décrite par un profil EPP (EnOcean Equipement Profile). Elle varie suivant le R-ORG qui indique le type de message radio.

Par exemple pour le R-ORG 0xD5, on aura la structure suivante :

Profil EPP

Le profil d’équipement enOcean ou profil EEP (EnOcean Equipement Profile) permet d’indiquer le type de données transmises par l’appareil.

Le profil EEP est défini par trois valeurs en hexédacimal [XX-YY-ZZ] :

  • XX -> R-ORG (Radio-telegram types grouped ORGanizationally) : indique le type de message radio.
Télégramme R-ORG Description
1BS 0xD5 Données sur 1 octet
4BS 0xA5 Données sur 4 octets
VLD 0xD2 Données à longueur variables
MSC 0xD1 Données spécifiques au constructeur
  • YY -> FUNC : détermine la fonction de base de l’appareil (détecteur, un capteur, une sonde, un interrupteur, …)

Les FUNC sont définies en fonction du RORG qui les précèdent. Par exemple, pour une valeur FUNC de 02, avec la combinaison RORG-FUNC [F6-02] il s’agira d’un interrupteur bistable, tandis que [A5-02] sera une sonde de température.

  • ZZ -> TYPE : caractéristiques précises propres à l’appareil. Par exemple pour ce capteur de température, 04 signifie que les valeurs possibles sont de -10°C à 30°C.

La valeur de TYPE dépend aussi du reste de l’EEP (RORG-FUNC) : [D5-00-01].

Liste des EEPS

Exemples :

  • RORG = D5 -> sur 1 octet
  • FUNC = 00 soit [D5-00] -> Single Input Contact
  • TYPE = 01
  • RORG = D2 -> longueur variable
  • FUNC = 01 soit [D2-01] -> Electr. switches/dimmers, Energy Meas. / Local Ctrl. Type 0x0A
  • TYPE = 0A

→ Protocole EnOceanSerialProtocol3

Contrôleurs EnOcean

  • L’USB 300 est une passerelle EnOcean/USB équipée d’un module émetteur-récepteur de type TCM 310. Prix : environ 40 €. [Datasheet | User manual]
  • La carte EnOcean Pi est une carte d’extension qui s’installe directement sur le connecteur GPIO d’une carte Raspberry Pi. Elle est basée sur le transceiver EnOcean TCM 310 qui supportent la fréquence 868,3 MHz (Europe). Prix : environ 40 €. [Datasheet | User manual | Getting started]

Mise en oeuvre de l’EnOcean USB 300

L’USB 300 est une passerelle EnOcean/USB équipée d’un module émetteur-récepteur de type TCM 310. Prix : environ 40 €. [Datasheet | User manual]

Prise en charge sous GNU/Linux

$ dmesg
...
[ 3874.133209] usb 2-1.5: Product: EnOcean USB 300 CA
[ 3874.133212] usb 2-1.5: Manufacturer: EnOcean GmbH
[ 3874.133214] usb 2-1.5: SerialNumber: FTUS8KZF
[ 3874.205286] usbcore: registered new interface driver usbserial
[ 3874.205302] usbcore: registered new interface driver usbserial_generic
[ 3874.205314] usbserial: USB Serial support registered for generic
[ 3874.228529] usbcore: registered new interface driver ftdi_sio
[ 3874.228546] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 3874.228646] ftdi_sio 2-1.5:1.0: FTDI USB Serial Device converter detected
[ 3874.228695] usb 2-1.5: Detected FT232RL
[ 3874.228699] usb 2-1.5: Number of endpoints 2
[ 3874.228703] usb 2-1.5: Endpoint 1 MaxPacketSize 64
[ 3874.228708] usb 2-1.5: Endpoint 2 MaxPacketSize 64
[ 3874.228712] usb 2-1.5: Setting MaxPacketSize 64
[ 3874.229599] usb 2-1.5: FTDI USB Serial Device converter now attached to ttyUSB0

$ lsusb
...
Bus 001 Device 029: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

$ lsusb -v -d 0403:6001

$ ls -l /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 nov.   1 18:19 /dev/ttyUSB0

Test de communication (réception)

$ sudo stty -F /dev/ttyUSB0 57600

# Door/Window Sensor (D5-00-01 Single Input Contact)
$ sudo hexdump -C < /dev/ttyUSB0 
00000000  55 00 07 07 01 7a d5 09  05 0f 80 62 00 00 ff ff  |U....z.....b....|
00000010  ff ff 34 00 3f 55 00 07  07 01 7a d5 08 05 0f 80  |..4.?U....z.....|
00000020  62 00 00 ff ff ff ff 2d  00 41 55 00 07 07 01 7a  |b......-.AU....z|
00000030  d5 09 05 0f 80 62 00 00  ff ff ff ff 2d 00 d5 55  |.....b......-..U|
00000040  00 07 07 01 7a d5 08 05  0f 80 62 00 00 ff ff ff  |....z.....b.....|
00000050  ff 2d 00 41 55 00 07 07  01 7a d5 09 05 0f 80 62  |.-.AU....z.....b|
...
$ sudo stty -F /dev/ttyUSB0 57600

# Émetteur radio portable mini FMH2
$ sudo hexdump -C < /dev/ttyUSB0 
00000000  55 00 07 07 01 7a f6 10  00 25 8a f8 30 00 ff ff  |U....z...%..0...|
00000010  ff ff 31 00 b6 55 00 07  07 01 7a f6 00 00 25 8a  |..1..U....z...%.|
00000020  f8 20 00 ff ff ff ff 31  00 fe 55 00 07 07 01 7a  |. .....1..U....z|
00000030  f6 30 00 25 8a f8 30 00  ff ff ff ff 34 00 09 55  |.0.%..0.....4..U|
00000040  00 07 07 01 7a f6 00 00  25 8a f8 20 00 ff ff ff  |....z...%.. ....|
...
$ sudo stty -F /dev/ttyUSB0 57600

# Émetteur radio portable mini FMH2
$ sudo hexdump -C < /dev/ttyUSB0 
00000000 55 00 09 07 01 56 d2 04   61 e4 05 0e 1c f2 00 00  |U...............|
00000016 ff ff ff ff 3a 00 86 55   00 09 07 01 56 d2 04 61  |....:...........|
00000032 80 05 0e 1c f2 00 00 ff   ff ff ff 3c 00 a3        |................|
...

Décodage des trames reçues

55 00 07 07 01 7a d5 09 05 0f 80 62 00 00 ff ff ff ff 34 00 3f 
55 00 07 07 01 7a d5 08 05 0f 80 62 00 00 ff ff ff ff 2d 00 41 
55 00 07 07 01 7a d5 09 05 0f 80 62 00 00 ff ff ff ff 2d 00 d5 
55 00 07 07 01 7a d5 08 05 0f 80 62 00 00 ff ff ff ff 2d 00 41
...

Soit pour la première trame :

Valeur hex Champ description
55 Synchronization byte
00 07 Data length -> 7 octets
07 Optionnal length -> 7 octets
01 Packet type -> RADIO_ERP1 (Radio Telegram)
7a CRC8H
d5 R-ORG -> 1BS soit un seul octet de donnée
09 Data
05 0f 80 62 SenderID
00 Status
00 SubTelNum Number of subtelegram Send : 3 / receive : 1 … y
ff ff ff ff Destination ID Broadcast radio: FF FF FF FF
34 dBm Receive best RSSI value of all received subtelegrams (value decimal without minus)
00 SecurityLevel 0 = telegram unencrypted
3f CRC8D

Le détecteur NODON a l’identifiant 05 0F 80 62 et il a envoyé des télégrammes radio (ERP1) en broadcast (FF FF FF FF). L’état du contact se trouve dans le champ Data.

Seul le champ Data change (0x09 ou 0x08) :

Valeur hex Contact CO DB0.0
09 0000 1001 -> 1 closed (contact fermé)
08 0000 1000 -> 0 open (contact ouvert)

Ces émetteurs de type F6 regroupent les interrupteurs et les capteurs récepteurs de commandes. Les données utiles se réduisent à une seule donnée d’état de type ON/OFF.

Champ Valeur hex Description
Type télégramme 0xF6 Type F6
Données Capteur 0xnn Donnée utile
Identité 0xnnnnnnnn Identité émettrice/destinataire
Status 0xnn Status 0x30 (action) et 0x20 (relaché)
Numéro de sous-télégramme 0x01 Numéro de télégramme
Destination Radio 0xFFFFFFFF Diffusion
Sensibilité Radio 0xnn Sensibilité Radio (en réception)
Cryptage Télégramme 0x00 Non crypté : 0
CRC8 Donnée 0xnn Checksum Données

Chaque capteur de ce type peut gérer jusqu’à 4 canaux maximum dans le champ Données Capteur :

b7 b6 b5 b4 b3 b2 b1 b0
n n I/O 1 0 0 0 0

Avec n le numéro de canal (0 à 3) et I/O (1 pour ON et 0 pour OFF).

Ce qui donnera :

  • Canal 1 OFF = 0x10 ; ON = 0x30
  • Canal 2 OFF = 0x50 ; ON = 0x70

Le capteur Interrupteur émettra deux télégrammes : un télégramme avec la donnée I/O (0x30 ou 0x10) lors l’appui et un second télégramme avec la valeur 0x00 pour signaler la position repos lors du relâchement. Dans le champ Status, on aura soit 0x30 (appui) soit 0x20 (relâchement).

55 00 07 07 01 7a f6 10 00 25 8a f8 30 00 ff ff ff ff 31 00 b6 
55 00 07 07 01 7a f6 00 00 25 8a f8 20 00 ff ff ff ff 31 00 fe 
55 00 07 07 01 7a f6 30 00 25 8a f8 30 00 ff ff ff ff 34 00 09 
55 00 07 07 01 7a f6 00 00 25 8a f8 20 00 ff ff ff ...

Le détecteur Eltako a l’identifiant 00 25 8A F8 et il a envoyé des télégrammes radio (ERP1) en broadcast (FF FF FF FF). L’état du contact se trouve dans le champ Data (10 pour O ou 30 pour I) et l’action dans le champ Status (30 pour l’appui ou 20 pour le relâchement) :

  • Appui OFF (O) : 55 00 07 07 01 7a f6 10 00 25 8a f8 30 00 ff ff ff ff 31 00 b6
  • Relâchement (OFF) : 55 00 07 07 01 7a f6 00 00 25 8a f8 20 00 ff ff ff ff 31 00 fe
  • Appui ON (I) : 55 00 07 07 01 7a f6 30 00 25 8a f8 30 00 ff ff ff ff 34 00 09
  • Relâchement (ON) : 55 00 07 07 01 7a f6 00 00 25 8a f8 20 00 ff ff ff ...

  • Prise intelligente NODON

Cet équipement a un profil D2-01-0A. Ce profil EEP est utilisé pour les actionneurs bidirectionnels qui contrôlent les charges électriques, par exemple à des fins d’éclairage. La commande locale, via un bouton, est supportée par l’actionneur.

Il se décompose ainsi :

  • RORG : D2 -> VLD Telegram
  • FUNC : D2-01 -> Electronic switches and dimmers with Energy Measurement and Local control
  • TYPE : D2-01-OA

Cet équipement supporte les commandes suivantes :

  • CMD 0x1 - Actuator Set Output
  • CMD 0x2 - Actuator Set Local
  • CMD 0x3 - Actuator Status Query
  • CMD 0x4 - Actuator Status Response
  • CMD 0x5 - Actuator Set Measurement
  • CMD 0x6 - Actuator Measurement Query
  • CMD 0x7 - Actuator Measurement Response

Les trames capturées sont :

55 00 09 07 01 56 d2 04 61 e4 05 0e 1c f2 00 00 ff ff ff ff 3a 00 86 
55 00 09 07 01 56 d2 04 61 80 05 0e 1c f2 00 00 ff ff ff ff 3c 00 a3
...

Pour la première trame, on réalise le décodage suivant :

Valeur hex Champ description
55 Synchronization byte
00 09 Data length -> 9 octets
07 Optionnal length -> 7 octets
01 Packet type -> RADIO_ERP1 (Radio Telegram)
56 CRC8H
d2 R-ORG -> VLD
04 61 e4 Datas
05 0e 1c f2 SenderID
00 Status
00 SubTelNum Number of subtelegram Send : 3 / receive : 1 … y
ff ff ff ff Destination ID Broadcast radio: FF FF FF FF
3a dBm Receive best RSSI value of all received subtelegrams (value decimal without minus)
00 SecurityLevel 0 = telegram unencrypted
86 CRC8D

Et pour les Datas : 04 61 e4

  • 04 -> CMD 0x4 - Actuator Status Response
  • 61 -> OC = 0 (Over current switch off) - EL = 3 () - I/O channel = 1
  • e4 -> (1XXXXXXX) LC = 1 (Local control enabled) - Output value = 100 % ou ON (0x64) X1100100

Pour les Datas de la deuxième trame : 04 61 80

  • 04 -> CMD 0x4 - Actuator Status Response
  • 61 -> OC = 0 (Over current switch off) - EL = 3 (Error level) - I/O channel = 1
  • 80 -> LC = 1 (Local control enabled) - Output value = 0 % ou OFF (0x00)

Communication avec l’USB 300

Il est possible d’interroger l’USB 300 en lui envoyant des paquets COMMON_COMMAND afin d’obtenir quelques informations. On utilisera cutecom pour émettre les paquets manuellement.

La structure du paquet COMMON_COMMAND :

Quelques codes de commandes :

Chaque clé USB possède un identifiant gravé dans son firmware. Il est possible d’obtenir des informations avec les codes 0x03 (demande de lecture de l’ID, …) et 0x08 (demande de lecture de l’identité de base) :

  • Lecture des caractéristiques (code 0x03 Read the device SW version / HW version, chip-ID, etc.)

Après avoir calculé les CRC8, on obtient le paquet : 0x55 0x00 0x01 0x00 0x05 0x70 0x03 0x09

Dans cutecom, on enverra donc le paquet suivant en hexadécimal : 5500010005700309

00000000 55 00 21 00 02 26 00 02   0f 00 00 02 06 09 00 05  U
00000016 16 76 1e 45 4f 01 03 47   41 54 45 57 41 59 43 54   v EO  G  ATEWAYCT
00000032 52 4c 00 00 00 00 00 82                            RL

Soit le paquet : 55 00 21 00 02 26 00 02 0f 00 00 02 06 09 00 05 16 76 1e 45 4f 01 03 47 41 54 45 57 41 59 43 54 52 4c 00 00 00 00 00 82

On réalise le décodage :

Valeur hex Champ description
55 Synchronization byte
0021 Longueur des données principales : 33 octets
00 Longueur des données optionnelles : 0
02 Paquet Réponse
26 CRC8 Entête
00 Réponse Commande 0x00 CR = OK
020f0000 Version Application
02060900 Version API
0516761e Chip ID
454f0103 Chip Version Reserved for internal use
Descripion 16 car. ASCII 47 41 54 45 57 41 59 43 54 52 4c 00 00 00 00 00 -> GATEWAYCTRL
82 CRC8 Données
  • Lecture de le numéro de baseID (code 0x08 Read ID range base number)

Après avoir calculé les CRC8, on obtient le paquet : 0x55 0x00 0x01 0x00 0x05 0x70 0x08 0x38

Dans cutecom, on enverra donc le paquet suivant en hexadécimal : 5500010005700838

00000000 55 00 05 01 02 db 00 ff   bb 0f 00 0a 5a           U

Soit le paquet : 55 00 05 01 02 db 00 ff bb 0f 00 0a 5a

On réalise le décodage :

Valeur hex Champ description
55 Synchronization byte
0005 Longueur des données principales : 5 octets
01 Longueur des données optionnelles : 1 octets
02 Paquet Réponse
db CRC8 Entête
00 Réponse Commande 0x00 CR = OK
ffbb0f00 Base ID Range between 0xFF800000 and 0xFFFFFF80
0a Remaining write cycles for Base ID (max 10)
5a CRC8 Données

Test de communication (émission)

On va maintenant commander la prise intelligente NODON.

Cet équipement a un profil D2-01-0A et admet une commande CMD 0x1 - Actuator Set Output.

Mais avant de pouvoir la commander, il faut l’appairer. En appuyant pendant 2 secondes sur son bouton, la prise envoie alors des paquets UTE avec le RORG D4 :

00000000 55 00 0d 07 01 fd d4 a0 01 46 00 0a 01 d2 05 0e    U
00000016 1c f2 00 00 ff ff ff ff 40 00 d0 

Dans ce paquet, on retrouve son profil EEP dans l’ordre TYPE-FUNC-RORG : 0a 01 d2 soit D2-01-0A. On va s’appairer avec cet équipement en lui renvoyant une réponse UTE 0x91 :

0x55 0x00 0x0D 0x06 0x01 0xE8 0xD4 0x91 0x01 0x46 0x00 0x0A 0x01 0xD2 0xFF 0xBB 0x0F 0x00 0x00 0x03 0x05 0x0E 0x1C 0xF2 0xFF 0x79

Les octets 0x01 à 0xD2 sont recopiés du paquet reçu. Ensuite, on trouve le SenderID qui est notre identifiant de base, le status et les données optionnelles.

Dans cutecom, on envoie le paquet ci-dessus en hexadécimal : 55000D0601E8D4910146000A01D2FFBB0F000003050E1CF2FF79.

Maintenant, on prépare le paquet de commande de la prise :

Valeur hex Champ description
55 Synchronization byte
00 09 Data length -> 9 octets
07 Optionnal length -> 7 octets
01 Packet type -> RADIO_ERP1 (Radio Telegram)
nn CRC8H
d2 R-ORG -> VLD soit 4 octets de donnée
xx yy zz Datas
ff bb 0f 00 SenderID (cf. BaseID)
30 Status
03 SubTelNum Number of subtelegram Send : 3 / receive : 1 … y
05 0e 1c f2 Destination ID Broadcast radio
ff dBm Receive best RSSI value of all received subtelegrams (value decimal without minus)
00 SecurityLevel 0 = telegram unencrypted
nn CRC8D

Les Datas se décomposent ainsi :

  • xx = 01 : Command ID
  • yy = 01 : Dim value = 0 / I/O channel = 1
  • zz = 00 ou 64 : Output value 0x00 (0% ou OFF) 0x01…0x64 (1% à 100% oo ON)

Après avoir calculé les CRC8, on obtient le paquet : 0x55 0x00 0x09 0x06 0x01 0x43 0xD2 0x01 0x01 0x00 0xFF 0xBB 0x0F 0x00 0x30 0x03 0x05 0x0E 0x1C 0xF2 0xFF 0xEC

Dans cutecom, on enverra donc le paquet suivant en hexadécimal : 550009060143D2010100FFBB0F003003050E1CF2FFEC pour commander la prise en OFF.

On obtient en réception 2 trames :

00000000 55 00 01 00 02 65 00 00   55 00 09 07 01 56 d2 04  U
00000016 61 80 05 0e 1c f2 00 00   ff ff ff ff 47 00 96     a.....

La première est la réponse (code 0x02) du contrôleur à la commande avec le code 0x00 pour RET_OK. La deuxième trame reçue est celle de la prise intelligente NODON qui envoie son nouvel état (0x4 - Actuator Status Response).

Pour commander la prise en ON, il faudra envoyer le paquet : 550009060143D2010164FFBB0F003003050E1CF2FF2B.

Développement

Comme on l’a vu, un contrôleur EnOcean se gère par le protocole ESP (EnOcean Serial Procotol) sur une liaison série. Il suffit donc d’intégrer la gestion d’un port série dans son application. Voir par exemple : Mise en oeuvre d’un port série sous Qt.

Il existe aussi :

  • une bibliothèque C++ EnOcean Link en version d’essai et comprenant les fonctions les plus importantes du protocole.
  • une bibliothèque Python EnOcean (non testé)

Retour au sommaire