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.
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.
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.
