Envoyer une seule instruction à chaque nœud d'un maillage Contiki 6LoWPAN derrière notre routeur de bordure
Traduit de English par IA ·
Je suis responsable de production, excusez donc mon vocabulaire. Il y a deux ans, notre prestataire a installé 30 nœuds de température sans fil dans les chambres froides. Ils fonctionnent sous Contiki-NG sur un maillage 6LoWPAN, et un boîtier exécutant le routeur de bordure se trouve dans le local électrique. Ce même boîtier transmet aussi les relevés à Hermetry en tant que passerelle, chaque nœud apparaissant comme son propre appareil enfant. Cette partie fonctionne parfaitement.Ce que je veux maintenant : lorsque l’équipe QA lance une campagne de validation, chaque nœud doit passer d’un échantillonnage de 5-minute à 30-second, puis revenir en arrière ensuite. Aujourd’hui, le prestataire se connecte en SSH et modifie chaque nœud un par un, ce qui prend presque une heure. Je lui ai demandé de « simplement tout diffuser », et il a répondu que le multicast via le routeur de bordure ne fonctionne pas dans Contiki et que Hermetry ne peut de toute façon pas envoyer de commandes aux enfants.A-t-il raison sur les deux points ? Je n’ai pas besoin des détails de la pile radio. Je dois savoir s’il faut le payer pour un correctif ou chercher une autre approche.
Plant manager, so forgive the vocabulary. Our contractor put 30 wireless temperature nodes in the cold stores two years ago. They run Contiki-NG on a 6LoWPAN mesh, and a box running the border router sits in the electrical room. The same box also reports the readings to Hermetry as a gateway, each node shows up as its own child device. That part has been rock solid.
What I want now: when the QA team starts a validation run, every node should switch from 5-minute to 30-second sampling, and back afterwards. Today the contractor SSHs in and pokes each node one by one, which takes most of an hour. I asked him to « just broadcast it » and he said multicast through the border router doesn’t work in Contiki and that Hermetry can’t send to children anyway.
Is he right on both counts? I don’t need the details of the radio stack, I need to know whether to pay him for a fix or look for another approach.
Traduit de English par IA ·
Il a tort concernant la partie Hermetry. Hermetry peut envoyer des commandes et des modifications d’attributs partagés aux appareils situés derrière une passerelle : la passerelle les reçoit sur v1/gw/rpc ou v1/gw/attributes et doit les appliquer. Tout dépend donc de la prise en charge de ces topics par le logiciel de passerelle du prestataire. Une commande adressée à l’appareil passerelle lui-même fonctionne aussi : le boîtier dans votre local électrique peut donc recevoir « démarrer l’échantillonnage de validation » depuis un bouton du tableau de bord ou une règle, puis le redistribuer localement. Cela fait une commande au lieu de 30. La partie radio relève du domaine d’Eric.
He’s wrong about the Hermetry half. Hermetry can send commands and shared attribute changes to devices behind a gateway: the gateway gets them on v1/gw/rpc or v1/gw/attributes and has to apply them, so it depends on whether the contractor’s gateway software handles those topics. A command to the gateway device itself works too, so the box in your electrical room can get « start validation sampling » from a dashboard button or a rule and fan it out locally. That’s one command instead of 30. The radio half is Eric’s territory.
Traduit de English par IA ·
Sur la partie radio, il a en partie raison. Contiki-NG prend en charge le multicast IPv6 pour les réseaux RPL : deux moteurs, SMRF et MPL. On l’active à la compilation dans le project-conf.h des nœuds et dans celui du border router :
/* every node and the border router */
#define UIP_MCAST6_CONF_ENGINE UIP_MCAST6_ENGINE_MPL
/* for SMRF instead you also need storing mode with multicast: */
/* #define UIP_MCAST6_CONF_ENGINE UIP_MCAST6_ENGINE_SMRF */
/* #define RPL_CONF_MOP RPL_MOP_STORING_MULTICAST */
Là où il a raison, c’est que le rpl-border-router standard ne transmet pas dans le maillage le multicast provenant du réseau externe. Le multicast doit donc être émis depuis le border router lui-même : un petit processus sur cette machine qui, sur commande de Hermetry, envoie un datagramme MPL vers un groupe auquel les nœuds ont adhéré. Cela implique de reflasher les 30 nœuds avec le multicast activé, ce qui, dans une installation en chambre froide, nécessite une intervention sur site.Honnêtement, pour 30 nœuds, je me passerais du multicast. Faites boucler le border router sur les 30 adresses et envoyez en unicast avec une nouvelle tentative. 30 petits paquets sur un maillage, c’est peu de chose : c’est terminé en quelques secondes, et chaque nœud acquitte, donc vous savez qui a manqué le message. Pas de reflashage.Ensuite, dans Hermetry : ajoutez une commande comme sampling.set avec un paramètre period_s dans le profil de la passerelle, répondez-y depuis ce processus une fois que tous les nœuds ont acquitté, et placez deux boutons sur le tableau de bord QA. Faites remonter la période courante de chaque nœud en tant qu’attribut client, afin que QA puisse vérifier que la modification a bien été prise en compte.
Partly right on the radio half. Contiki-NG does have IPv6 multicast for RPL networks: two engines, SMRF and MPL. You turn one on at build time in the nodes’ project-conf.h and in the border router’s:
/* every node and the border router */
#define UIP_MCAST6_CONF_ENGINE UIP_MCAST6_ENGINE_MPL
/* for SMRF instead you also need storing mode with multicast: */
/* #define UIP_MCAST6_CONF_ENGINE UIP_MCAST6_ENGINE_SMRF */
/* #define RPL_CONF_MOP RPL_MOP_STORING_MULTICAST */
Where he’s right is that the stock rpl-border-router does not forward multicast arriving from the outside network into the mesh. So the multicast has to originate on the border router itself: a small process on that box that, on a command from Hermetry, sends one MPL datagram to a group the nodes joined. It means reflashing all 30 nodes with multicast enabled, which on a cold store install is a site visit.
Honestly, for 30 nodes I’d skip multicast. Have the border router loop over the 30 addresses and send unicast with a retry. 30 small packets on a mesh is nothing, it finishes in seconds, and every node acks so you know who missed it. No reflash.
Then in Hermetry: add a command like sampling.set with a period_s parameter on the gateway’s profile, answer it from that process once all nodes acked, and put two buttons on the QA dashboard. Have the nodes report their current period as a client attribute so QA can see it took.
Traduit de English par IA ·
Le prestataire a réalisé la boucle en unicast en deux jours, sans visite sur site. Le QA appuie sur « Validation on », la passerelle répond 30/30 acquittés environ 8 secondes plus tard, et l’attribut sample_period des nœuds passe à 30. On est passé d’une heure à un bouton. Merci à vous deux, et j’ai arrêté de dire « il suffit de faire un broadcast ».
Contractor did the unicast loop in two days, no site visit. QA presses « Validation on », the gateway answers with 30/30 acked about 8 seconds later, and the nodes’ sample_period attribute flips to 30. Went from an hour to a button. Thanks both, and I’ve stopped saying « just broadcast it ».
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.

