Von English mit KI übersetzt ·
Beim Funkteil hat er teilweise recht. Contiki-NG unterstützt IPv6-Multicast für RPL-Netze: zwei Engines, SMRF und MPL. Man aktiviert eine davon zur Build-Zeit in der project-conf.h der Knoten und in der des Border Routers:
/* 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 */Wo er recht hat: Der Standard-rpl-border-router leitet Multicast aus dem externen Netz nicht ins Mesh weiter. Der Multicast muss daher auf dem Border Router selbst entstehen: ein kleiner Prozess auf diesem Gerät, der auf Befehl von Hermetry ein MPL-Datagramm an eine Gruppe sendet, der die Knoten beigetreten sind. Dafür müssen alle 30 Knoten mit aktiviertem Multicast neu geflasht werden, was bei einer Kühlhaus-Installation einen Vor-Ort-Termin bedeutet.Ehrlich gesagt würde ich bei 30 Knoten auf Multicast verzichten. Der Border Router iteriert über die 30 Adressen und sendet Unicast mit Wiederholung. 30 kleine Pakete im Mesh sind nichts, das ist in Sekunden erledigt, und jeder Knoten bestätigt, sodass man weiß, wer es verpasst hat. Kein erneutes Flashen.Dann in Hermetry: einen Befehl wie sampling.set mit einem Parameter period_s im Profil des Gateways anlegen, diesen Prozess antworten lassen, sobald alle Knoten bestätigt haben, und zwei Schaltflächen im QA-Dashboard platzieren. Die Knoten sollen ihre aktuelle Periode als Client-Attribut melden, damit QA sieht, dass sie übernommen wurde.
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.