Catégories
ElyticBridge Produits

ElyTicBridge

1. Introduction

Le projet ElyTicBridge s’inscrit dans un cadre où la gestion de l’énergie devient un enjeu majeur de notre monde. Ainsi, ce projet va avoir pour objectif d’aider à la transition énergique en utilisant une technologie présente dans nos domiciles : la télé information client d’Enedis. Cette technologie est disponible uniquement avec le réseau électrique français et sur les compteurs adéquats. Parmi ces compteurs, un compteur est désormais le plus populaire en France, le compteur Linky. Ainsi, lors de ce projet, nous n’aurons à notre disponibilité que deux compteurs, tous deux les Linky (un monophasé, un triphasé).  

Un article détaillé sur cette technologie est disponible ici si vous souhaitez en apprendre plus.

L’objectif de ce produit est d’être capable de s’adapter aux besoins des utilisateurs et donc d’être utilisé dans des environnements très variés. Ainsi, nous avons conçu un produit qui est capable de récupérer les informations de la TIC, les traiter et de les retransmettre de différentes manières.

2. Environnement

Comme dit lors de l’introduction, notre objectif est de réaliser un produit qui s’adapte aux différents environnements. Mais quels sont ces environnements ?

Ils se décomposent en deux parties très différentes : l’environnement physique (quels sont les moyens de communication que l’on peut utiliser pour remonter les informations par exemple) et l’environnement d’intégration. Le second type d’environnement consiste plutôt à la cible de ce projet. Nous les détaillerons dans un second temps.

Aujourd’hui, notre compteur électrique peut être à différents endroits, avec différentes conditions d’accessibilité. En effet, on pourrait très bien avoir son compteur électrique dans un local dédié au rez-de-chaussée de son immeuble tout en habitant au 10ème étage ou bien situé dans une pièce de la maison avec un accès direct aux réseaux domestiques ou encore dans un garage à l’autre bout de la propriété. Ces différents environnements nous ont obligé à réfléchir sur comment s’adapter au maximum aux besoins des clients. Ainsi, nous avons décidé de séparer le développement de ce produit en deux parties : la partie principale, sujet de cet article, est en cours de développement (voir 3. Résultat) et une seconde partie qui seront des modules complémentaires (à la manière d’Arduino, des cartes additionnelles autrement appelé « shields ») qui seront à brancher directement sur la partie principale.

La partie principale a été développée dans un environnement spécifique où il y a un accès internet (WiFi ou Ethernet) pour réaliser les remontées d’information avec différents protocoles. Pour les environnements où il n’est pas possible d’avoir un accès internet, certains protocoles permettent une communication avec le réseau local (modbus TCP par exemple) mais des « shields » pourront résoudre ces problèmes dans le futur.

Passons désormais au second type d’environnement, les environnements dans lesquels nous allons nous intégrer. Nous avons identifié 3 grands environnements :

  • L’environnement résidentiel

Il s’agit de l’habitation classique d’un individu. La remontée des informations via certains protocoles (Zigbee par exemple) pourrait permettre d’automatiser des tâches via des éléments intelligents (Google Home par exemple). Le second objectif de l’ElyTicBridge est de permettre aux individus d’avoir un suivi temps réel sur leur consommation électrique (avec un historique).

  • L’environnement Maker

Cet environnement est réservé aux personnes ayant quelques compétences techniques. En effet, ElyTicBridge pourrait alors devenir une carte de développement mettant à disposition des informations qui pourrait être utile dans l’un des nombreux projets de ces individus. Ainsi, il sera possible de le reprogrammer en fonction des besoins et des envies.

  • L’environnement industriel

Ce dernier environnement est un domaine où le suivi énergétique a un enjeu commercial. En effet, nous pouvons utiliser le suivi de consommation pour l’analyser en profondeur et mettre en place des solutions adaptées. On pourrait très bien utiliser cette analyse pour réfléchir à une installation de panneaux solaires. On pourrait aussi chercher à identifier des anomalies électriques (une machine qui s’active de manière périodique alors que nous n’en n’avons ni le besoin, ni conscience) ou encore utiliser ces données pour mettre en place un « Energy Manager » directement.

3. Résultat

Ce projet est un projet qui a commencé en 2023 et a donc déjà des premiers résultats. En effet, aujourd’hui, 2 produits sont installés depuis l’été 2023 et nous avons toujours une remontée des informations fiables sur les différents moyens mis en place. Mais quel est l’état actuel de ces produits qui sont installés et qui fonctionne ?

Cette première version d’ElyTicBridge est déjà utilisée dans deux environnements différents. Le premier produit est installé au siège social d’Elyxoft, équipé d’un compteur Linky triphasé et est utilisé uniquement pour avoir un suivi de la consommation électrique (via l’outil Grafana). Le second est installé dans les locaux d’une entreprise équipée d’un compteur Linky Monophasé. Il a permis de réaliser des tests avec un Energy Manager dans le cadre de leurs activités professionnelles. Ainsi, malgré le fait que le projet n’en était qu’à sa première version, il est déjà capable de s’adapter à différents types d’environnement. Il reste tout de même le développement du dernier environnement, l’environnement résidentiel pour pouvoir communiquer avec des plateformes intelligentes telles que Google home. De plus, ces deux environnements ont un point commun : l’accès facile à une alimentation micro USB ainsi qu’un accès au réseau (via un câble RJ-45, réseau internet pour Elyxoft, réseau local pour l’autre bridge).

Un autre élément important est qu’il existe deux types de TIC, le mode « historique » et le mode « standard » (si vous souhaitez plus d’informations, je vous redirige une nouvelle fois vers notre article traitant ce sujet juste ici). Nous avons fait le choix de ne supporter que le mode historique pour notre première version d’ElyTicBridge car il s’agit du mode par défaut de tous les compteurs et il est le mode le plus répandu. Des tests avec le mode « standard » sont prévus, voir la partie « 4. Futur du projet ».  Ce mode de fonctionnement permet à l’utilisateur d’obtenir certains types d’informations en fonction des contrats (le courant par phase pour un contrat triphasé, par exemple). Ces informations permettent de réaliser des actions et un suivi en temps réel de sa consommation électrique. Elles ont déjà permis d’identifier certains facteurs de consommation et ces deux produits nous ont permis d’être un POC (proof of concept) concluant et de nous orienter vers un développement d’une nouvelle version qui sera ensuite en vente sur le marché.

Cependant, comme nous pouvons le voir sur la photo ci-dessus, le produit utilise des éléments déjà conçus. Ainsi, ces produits présentent des risques de défaillance accrue (un câble qui casse, un composant qui n’est pas correctement connecté…) et nous possédons une preuve que nous pouvons utiliser cette technologie. Ainsi, nous avons décidé de créer une seconde version du projet, toujours en développement à l’heure où j’écris ces lignes.

4. Futur du projet

Nous avons vu, à l’aide des deux produits présentés dans la section précédente, que le principe d’utiliser la TIC pour faire un suivi temps réel de la consommation électrique était possible et peut fonctionner. Nous avons alors lancé le développement d’une nouvelle version de ce produit, qui sera prochainement disponible à la vente.

Cette nouvelle version implique de nombreux domaines :

  • Mécanique

Cette version sera intégrée à un boîtier au format Rail DIN 3 modules. Le format Rail DIN est le format utilisé dans les tableaux électriques pour y fixer les différents éléments électriques (des disjoncteurs par exemple). Ainsi, en respectant ce format, cette nouvelle version du bridge a pour objectif de s’intégrer facilement dans vos installations électriques.

  • Électronique

L’utilisation d’éléments déjà routés et cartes diverses ne sont pas viables pour le produit (pour différentes raisons, dont la fiabilité). Ainsi, nous avons lancé le développement d’un PCB dédié (un circuit électronique imprimé pour les novices) qui utilisera un microcontrôleur plus puissant (ESP32 C6) et permettra donc d’implémenter de nouvelles fonctionnalités. On va alors intégrer les différents éléments nous-mêmes afin d’avoir un contrôle total et d’augmenter la fiabilité d’ElyTicBridge tout en ayant une connaissance complète du produit (allant du logiciel à l’électronique en passant par la mécanique). Ce PCB est actuellement terminé et en cours de fabrication.

  • Logiciel

Nous avons vu certaines limites à la première version de notre produit (par exemple le manque de configuration et un accès complexe aux configurations du bridge). Ainsi, ce premier retour d’expérience nous a permis de prendre conscience de certains aspects pratiques et d’intégrer alors de nouvelles fonctionnalités avec par exemple un web serveur embarqué dédié à la configuration du bridge à l’aide de votre réseau mais aussi la possibilité de réaliser ces mêmes configurations en Bluetooth et donc avec votre smartphone. De plus, nous intégrons de nouvelles fonctionnalités comme la possibilité de choisir entre une connexion au réseau de manière sans fil (WiFi) ou filaire (Ethernet), faciliter la configuration d’ElyTicBridge en le rendant entièrement configurable en fonction des besoins et envies ou l’utilisation de protocoles pour s’intégrer dans les réseaux domestiques (Zigbee ou Matter par exemple).

Cette nouvelle version, prochainement disponible, va donc permettre une adaptation totale à vos besoins, allant du simple suivi de la consommation électrique à une analyse poussée que vous pourrez réaliser pour ensuite réduire votre consommation électrique (ou celle d’un client) ou penser à des manières alternatives de génération électrique (par exemple l’installation de panneaux solaires).

Actuellement, nous développons la dernière partie manquante, la partie logicielle.

Voici quelques images d’un rendu 3D liant la mécanique (boîtier Rail DIN 3 module) et notre carte électronique (en cours de fabrication).

5. Conclusion

En conclusion, quel que soit votre profil, si vous avez besoin d’un suivi de consommation électrique en temps réel (que ça soit pour vous, pour un client ou pour convaincre un futur client d’une action dans l’objectif d’optimiser sa consommation électrique), ce produit est la solution qu’il vous faut. Il est un projet entièrement configurable, facile d’utilisation même pour les novices et très modulable afin de s’adapter à toutes les situations que vous pourriez rencontrer.

Cet article a été rédigé le 22 février 2024.

Catégories
Recherche technologique

openThread et GreenPower – Objectif

L’objectif de cette série d’article est de pouvoir utiliser une commande zigbee green power dans un réseau thread.

Pour cela nous allons réaliser les étapes suivantes :

  • Mise en place d’un environnement de développement openthread pour pouvoir générer des firmwares.
  • Mise en place d’un sniffer permettant de visualiser les communications.
  • Créations d’un réseau thread composé de deux nœuds, un leader et un router.
  • Ajout d’une implémentation minimaliste du protocole applicatif de la zigbee alliance pour réseau IP (ZCLIP, DotDot, CHIP … en fonction du temps et des communications) afin de réaliser une commande et un actionneur on/off avec nos deux produits.
  • Implémentation d’un combo zigbee green power minimaliste dans le firmware de l’actionneur on/off.
  • Idées complémentaire : réalisation d’un proxy minimaliste dans le firmware de la commande on/off, ajout d’un border router, extension de l’app de commissioning thread pour l’ajout de commande green power au réseau, recherche d’un algorithme de maintenance pour l’optimisation des proxy green power à activé en fonctions des niveau rssi reçu par les commandes.

Catégories
Recherche technologique

openThread et GreenPower – DotDot

Et pourquoi pas CHIP ? (https://www.connectedhomeip.com/) Et bien tout simplement car aucune spécification n’est encore publique actuellement !

Les documents de référence

L’objectif

L’objectif n’est pas d’implémenter l’ensemble du protocole dotdot mais le strict minimum pour passer à l’étape suivante : le pilotage depuis une commande green power. Pour se faire seul la commande toggle du cluster on/off sera implémentée sur le premier endpoint de l’actionneur. Seront donc ignoré :

  • La découverte des produits et des ressources depuis le /.well-known et de fait la gestion de l’UID produit.
  • Tous les mécanismes de sécurité.
  • La gestion du multicast, seul un post unicast sera géré par le serveur.
  • Les bindings et autres tokens

On peut donc résumé que le client enverra un post coap depuis la cli, le serveur quand à implémentera ce post sur la ressource « /zcl/e/1/s6/c/2 » qui correspond a la commande toggle du cluster on/off sur l’enpoint 1 du produit. Commande qui n’a pas besoin de payload.

Le code !

Jusqu’à présent nous avons compilé le projet exemple qui donne accès à une ligne de commande. Pour réaliser notre objectif on définira le leader comme l’actionneur, on ne touchera pas au code du routeur. Pour simplifier l’on va modifier le projet example cli pour :

  • créé automatiquement le réseau en tant que leader
  • activé coap et lui ajouter la ressource zcl/e/1/s6/c/2
  • ajouter un handler sur cette ressource
  • imprimer sur la sortie RTT les informations permettant de s’assurer que toute les étapes ce sont bien passée
  • a chaque fois que le handler de la ressource coap est appelée changé d’état une variable représentant la charge et l’afficher.
void CoAPHandleRequest(void *aContext, otMessage *aMessage, const otMessageInfo *aMessageInfo)
 {
     static bool light_on_state = false;
     OT_UNUSED_VARIABLE(aContext);
     OT_UNUSED_VARIABLE(aMessage);
     OT_UNUSED_VARIABLE(aMessageInfo);

     otPlatLog(OT_LOG_LEVEL_NONE, 
               OT_LOG_REGION_PLATFORM, 
               "Light %s",light_on_state?"ON":"OFF");
     light_on_state = !light_on_state;
}
int main(int argc, char *argv[])
 {
     otInstance *instance;
...

// configure node as leader
otError lError;

otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "Create new network : dataset ");
otOperationalDataset aDataset;
uint8_t demoMasterKey[OT_MASTER_KEY_SIZE] = {0x9d,0x7d,0xdc,0xb4,0x40,0x8b,0xe4,0x70,0xe2,0x24,0x02,0x56,0xfe,0xaf,0x9c,0xf2};

if( OT_ERROR_NONE == otDatasetCreateNewNetwork(instance, &aDataset) )
{
    otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "SUCCESS, set active ");
    aDataset.mChannel = 15;
    memcpy(aDataset.mMasterKey.m8, demoMasterKey, OT_MASTER_KEY_SIZE);
    if( OT_ERROR_NONE == otDatasetSetActive(instance, &aDataset) )
    {
        otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "SUCCESS, enable IPv6 ");
        if( OT_ERROR_NONE == otIp6SetEnabled(instance, true) )
        {
            otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "SUCCESS, start as leader ");
            lError = otThreadSetEnabled(instance,true);
            if( OT_ERROR_NONE == lError )
            {
                otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "SUCCESS\n");
                const otNetifAddress *unicastAddrs = otIp6GetUnicastAddresses(instance);

                for (const otNetifAddress *addr = unicastAddrs; addr; addr = addr->mNext)
                {
                    otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM,
                        "%x:%x:%x:%x:%x:%x:%x:%x", tSwap16(addr->mAddress.mFields.m16[0]), tSwap16(addr->mAddress.mFields.m16[1]),
                        tSwap16(addr->mAddress.mFields.m16[2]), tSwap16(addr->mAddress.mFields.m16[3]), tSwap16(addr->mAddress.mFields.m16[4]),
                        tSwap16(addr->mAddress.mFields.m16[5]), tSwap16(addr->mAddress.mFields.m16[6]), tSwap16(addr->mAddress.mFields.m16[7]));
                }                    
            }
            else { otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "FAILED %s\n", otThreadErrorToString(lError)); }    
        }
        else { otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "FAILED\n"); }    
    }
    else { otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "FAILED\n"); }    
}
else { otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "FAILED\n"); }    


// Initialize coap service
otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "CoAP start : ");
if( OT_ERROR_NONE == otCoapStart(instance, OT_DEFAULT_COAP_PORT) )
{
    otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "SUCCESS\n");

    // add ressources
    otCoapResource mResource;
    char zclToggleRscr[] = "zcl/e/1/s6/c/2";
    memset(&mResource, 0, sizeof(mResource));
    mResource.mUriPath = zclToggleRscr;
    mResource.mHandler = CoAPHandleRequest;

    otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "CoAP add ressource : ");
    lError = otCoapAddResource(instance, &mResource);
    if( OT_ERROR_NONE == lError )
    {
        otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "SUCCESS\n");
    }
    else { otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "FAILED %s\n", otThreadErrorToString(lError)); }    
}
else
{
    otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "FAILED\n");
}


while (!otSysPseudoResetWasRequested())
{
    ...

return 0;
}

Et le résultat :

Catégories
Recherche technologique

openThread et GreenPower – GreenPower

Pour le dernier article de cette étude, nous allons voir comment recevoir une trame green power issue d’une commande Philips Tap (https://zigbeealliance.org/zigbee_products/philips-hue-tap/) puis la transformer pour la renvoyer sous forme d’un message DotDot.

Méthodologie:

  • L’actionneur sera le leader et conserve le code développé précédemment.
  • Le nœud enfant contiendra le proxy Green Power et sera également modifier pour rejoindre automatiquement le réseau créé par le leader.
  • Pour simplifier l’adresse ipv6 du leader sera codée en dur dans l’enfant pour l’envoie du message CoAP.
  • La sécurité Green Power est ignorée pour cette étude. La trame issue de la commande Philips Tap contien l’ordre en clair.

La trame Green Power

Sans chercher à décoder entièrement la trame Green Power pour notre étude, nous utiliserons les filtres suivants:

  • Au moins 24 octets de long.
  • Le frame control 802.15.4 doit valoir 0x0801.
  • Le frame control du header network doit être de type data et la version du protocole doit être 3 (green power).
  • Le frame counter de la trame reçue doit être supérieur au frame counter de la trame précédente.
  • L’ordre green power doit être 0x22 (Toggle)

Le code du nœud enfant

Rejoindre le réseau et activer le handler de réception 802.15.4 à placer dans la fonction main avant la boucle infinie.

    // enable promiscuous mode for capture Grenn Power Frame
    // set callback
    otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "Set Pcap callback.");
    otLinkSetPcapCallback(instance, &PromicuousHandleLinkPcapReceive, 0);
    
    // join existing network
    // set master key
    memset(&aDataset, 0, sizeof(aDataset));
    memcpy(aDataset.mMasterKey.m8, demoMasterKey, sizeof(aDataset.mMasterKey));
    aDataset.mComponents.mIsMasterKeyPresent = true;
    otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "Commit dataset : ");
    lError = otDatasetSetActive(instance, &aDataset);
    if( OT_ERROR_NONE == lError )
    {
        otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "SUCCESS, enable IPv6 ");
        if( OT_ERROR_NONE == otIp6SetEnabled(instance, true) )
        {
            otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "SUCCESS, start as router ");
            lError = otThreadSetEnabled(instance,true);
            if( OT_ERROR_NONE == lError )
            {
                otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "SUCCESS\n");
                const otNetifAddress *unicastAddrs = otIp6GetUnicastAddresses(instance);

                for (const otNetifAddress *addr = unicastAddrs; addr; addr = addr->mNext)
                {
                    otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM,
                        "%x:%x:%x:%x:%x:%x:%x:%x", tSwap16(addr->mAddress.mFields.m16[0]), tSwap16(addr->mAddress.mFields.m16[1]),
                        tSwap16(addr->mAddress.mFields.m16[2]), tSwap16(addr->mAddress.mFields.m16[3]), tSwap16(addr->mAddress.mFields.m16[4]),
                        tSwap16(addr->mAddress.mFields.m16[5]), tSwap16(addr->mAddress.mFields.m16[6]), tSwap16(addr->mAddress.mFields.m16[7]));
                }                    

                // Initialize coap service
                otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "CoAP start : ");
                lError = otCoapStart(instance, OT_DEFAULT_COAP_PORT);
                if( OT_ERROR_NONE == lError )
                {
                    otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "SUCCESS\n");
                }
                else { otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "FAILED %s\n", otThreadErrorToString(lError)); }    
            }
            else { otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "FAILED %s\n", otThreadErrorToString(lError)); }    
        }
        else { otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "FAILED\n"); }    
    }
    else { otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "FAILED %s\n", otThreadErrorToString(lError)); }    

Filtrer les messages 802.15.4 pour n’être réactif qu’à la trame Green Power qui nous intéresse.

void PromicuousHandleLinkPcapReceive(const otRadioFrame *aFrame, bool aIsTx, void *aContext)
{
    OT_UNUSED_VARIABLE(aContext);

    // receive frame only
    if( !aIsTx )
    {
        otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "Rx %d bytes on channel %d, at time %d",
                                                                aFrame->mLength,aFrame->mChannel,aFrame->mInfo.mRxInfo.mTimestamp);
        // get only frame starting 0x01 0x08 : frame type data without security and short addressing mode fot destination, minimal length shall be 24
        if( (aFrame->mLength>=24) && (aFrame->mPsdu[0]==0x01) && (aFrame->mPsdu[1]==0x08) )
        {
            // green power use data frame with protocol 3, use it only
            if( (aFrame->mPsdu[7]&0x0F)==0x0C )
            {
                static uint32_t ls_previous_frm_counter = 0;
                otError lError;
                otMessage *   message = NULL;
                otMessageInfo messageInfo;  
                otIp6Address coapDestinationIp;              
                uint32_t l_src_id = aFrame->mPsdu[9] + (aFrame->mPsdu[10]<<8) + (aFrame->mPsdu[11]<<16) + (aFrame->mPsdu[12]<<24);
                uint32_t l_frm_counter = aFrame->mPsdu[13] + (aFrame->mPsdu[14]<<8) + (aFrame->mPsdu[15]<<16) + (aFrame->mPsdu[16]<<24);
                uint8_t l_cmd_id = aFrame->mPsdu[17];
                
                otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "GPF from %08X, frame counter %d, command %02X", l_src_id, l_frm_counter, l_cmd_id);

                // send CoAP message to leader only if frame counter is higher than previous message and only toggle (0x22) GP order
                if( (0x22 == l_cmd_id) && (l_frm_counter > ls_previous_frm_counter) )
                {
                    ls_previous_frm_counter = l_frm_counter;
                    message = otCoapNewMessage(instance, NULL);
                    otCoapMessageInit(message, OT_COAP_TYPE_NON_CONFIRMABLE, OT_COAP_CODE_POST);
                    otCoapMessageGenerateToken(message, 2);
                    otCoapMessageAppendUriPathOptions(message, "zcl/e/1/s6/c/2");
                    otIp6AddressFromString("fd85:74ee:7560:9626:dd0e:3508:db6:44c9", &coapDestinationIp);
                    memset(&messageInfo, 0, sizeof(messageInfo));
                    messageInfo.mPeerAddr = coapDestinationIp;
                    messageInfo.mPeerPort = OT_DEFAULT_COAP_PORT;                

                    otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "Send CoAP message : ");
                    lError = otCoapSendRequestWithParameters(instance, message, &messageInfo, NULL, NULL,NULL);
                    if( OT_ERROR_NONE == lError )
                    {
                        otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "SUCCESS\n");
                    }
                    else { otPlatLog(OT_LOG_LEVEL_NONE, OT_LOG_REGION_PLATFORM, "FAILED %s\n", otThreadErrorToString(lError)); }                   
                }
            }
        }
    }
}

Le résultat

Conclusion

Tout d’abord POURQUOI ? Pourquoi vouloir utilisé des devices Green Power dans un réseau thread ? Pour plusieurs raison :

  • Thread possède un type de device Low Energy MAIS il est encore trop consommateur par rapport à un device Green Power
  • Une commande Green Power peut devenir indépendante du type de réseau mesh 802.15.4 en place (Zigbee ou Thread).

Et la sécurité ? En effet Thread est un réseau sécurisé dans toutes les étape de sa vie. Pour cela il oblige l’utilisation d’un border routeur et d’un outils commissioneur, généralement un smartphone. Green Power contient bien des niveaux de sécurités dont un qui permet d’obtenir le même résultat que la sécurité mise en place dans Thread. Grâce à l’outil on peut venir entrer la clé de sécurité du device Green Power que l’on souhaite utiliser directement dans les proxy/actionneur concerné.

Pour résumer seul les devices Green Power Mono directionnel avec une sécurité de type install code et un frame counter incrémentiel présente un intérêt d’utilisation dans un réseau Thread. En effet ils permettent de combler le manque de spécification d’un device vraiment low power sans dégrader le niveau de sécurité du système.