Site : tvaira.free.fr
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).
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 :
→ 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.
Une trame UART est constituée des bits suivants :
Les paramètres de configuration sont donc : « 57600 8N1 »
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 :
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
].
Exemples :
D5
-> sur 1 octet00
soit [D5
-00
] -> Single Input Contact01
D2
-> longueur variable01
soit [D2
-01
] -> Electr. switches/dimmers, Energy Meas. / Local Ctrl. Type 0x0A0A
→ Protocole EnOceanSerialProtocol3
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]
$ 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
$ 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 |................|
...
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) |
F6
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 :
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) :
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
Relâchement (ON) : 55 00 07 07 01 7a f6 00 00 25 8a f8 20 00 ff ff ff ...
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 :
Cet équipement supporte les commandes suivantes :
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 Response61
-> OC = 0 (Over current switch off) - EL = 3 () - I/O channel = 1e4
-> (1XXXXXXX) LC = 1 (Local control enabled) - Output value = 100 % ou ON (0x64) X1100100Pour les Datas de la deuxième trame : 04 61 80
04
-> CMD 0x4 - Actuator Status Response61
-> OC = 0 (Over current switch off) - EL = 3 (Error level) - I/O channel = 180
-> LC = 1 (Local control enabled) - Output value = 0 % ou OFF (0x00)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) :
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 |
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 |
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 :
01
: Command ID01
: Dim value = 0 / I/O channel = 100
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
.
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 :