Hi community,
I am trying to get back into RIOT development after being absent for a longer period, so I have some questions around what the current state of the art is within the community.
What do you use for device discovery and orchestration for 6lowpan devices?
Scenario
A normal LAN setup with a wifi router providing internet access, a server running some time series database (e.g. InfluxDB), a 6lowpan border gateway routing between global IPv6 LAN/Internet and the 6lowpan network. The devices on the 6lowpan network will be different sensors whose values I want to be able to log to the TSDB.
Objectives
When I power on a new device I would like it to find the gateway (this part pretty much worked out of the box via SLAAC and RPL last time I worked on RIOT, as long as the radio channel etc was hard coded), but also find the database or some kind of data collection service which wraps the database so that the values can be translated from 6lowpan friendly messages into whatever format the database expects.
Additionally it would be useful to be able to configure the remote devices from the LAN side, e.g. setting update intervals to preserve battery life time or configuring alarm events to let the device sleep for longer periods.
My use case is a hobby project involving battery-powered 802.15.4 radio devices with some simple scalar sensors (temperature, humidity etc). I want to see if it is possible to build something like what I describe above in 2021 using only open standards and free software.
We currently working on a Web of Things implementation into RIOT. That is the last commit I checked out.
It kind of already works, also with the WoT Discovery standard.
Even though I haven’t tested the CoRE topic itself. I also haven’t done/tested the CoAP observe part yet. Even though it shouldn’t be a problem to reflect it in the WoT TD.
It would be kind of nice to have some kind of generic adapter to a time series database or logging system like Prometheus. I already created boilerplate applications for NodeJS and Scala in order to consume a TD.
But overall there is still a lot of work to do. The code is kind of messy at the moment.
Happy to welcome everyone who wants to help pushing this topic forward. Just ping me, if you think this is something you are interested in.
Thanks for all the useful info above. That sounds interesting. Definitely seems to be something that could fit the scenario described above.
I have not read about WoT before, what are the exact parts that are currently implemented or being implemented? Are you using CoAP for the transport?
How do you do discovery? Do you use mDNS?
I have not read about WoT before, what are the exact parts that are currently implemented or being implemented?
Jan worked on a script to generate the c config files from a given Thing Model ( tm ) and an instance.js.
The thing model is there to describe common properties of a group of Things. There are more details in the specification. The instance is basically a Thing Description, even though it contains some specific RIOT OS information. (We don’t know yet how to reflect that in the context extension though)
The idea is to just have a simple json config and generate all the necessary structs in order to use WoT in RIOT. You can also manipulate the structs in runtime. A use-case to give you some context: You might don’t want to expose all the endpoints when the user powers up the device for the first time. You only want to have a certain endpoint to setup the device. Once the setup is done, you can just enable the other endpoints as well. These kind of things are quite simple to implement, since there are a lot of functions to manipulate the WoT TD.
Are you using CoAP for the transport?
There is a working CoAP Module for that, yes.
There is also a short howto I made for the W3C. Kind of outdated now, but I think you should be probably able to connect all the dots. But you can also just send me a pm on Matrix.
Do you use mDNS?
Not at the moment. But that is a mechanism described in the discovery spec.
How do you do discovery?
I don’t do it at the moment. The specification for the WoT discovery should be implemented. At least the CoRE Resource Directory part. But I haven’t looked into it yet. Never used it before. I think Jan worked with it before.
I don’t do it at the moment. The specification for the WoT discovery should be implemented. At least the CoRE Resource Directory part. But I haven’t looked into it yet. Never used it before. I think Jan worked with it before.
At the moment, you can query the resources provided by the thing including its thing description by sending a GET request to /.well-known/core. As specified by the WoT, the link to the thing description has an added “endpoint type” parameter et=wot.thing and uses the well-known URI /.well-known/wot-thing-description which can also be used for discovery, e. g. by performing a multicast.
Although the discovery part of the specification is still a draft and could change with regard to these aspects, for now it works quite well I would say
If you are looking for something that could also allow you to manage the devices, you should take a look at LwM2M. The current integration has the basic objects to establish a connection and get node information, but it can be extended to include the objects for the sensors and actuators. The advantage is that LwM2M already defines how this objects look like and how to interact with them. For the server side I recommend Leshan.
I have some experience working with LwM2M in Contiki (this was back in 2015, probably outdated by now). But I don’t remember how we made the initial connection between a new device and the server side (we probably had the address hard-coded). Do you know if the RIOT supports the RDAO ND option mentioned in draft-ietf-core-resource-directory-26 Section 4.1.1? (or if anyone is working on an implementation)
Edit: After reading the IETF draft again I think it probably makes sense in my scenario to simply assume the 6LBR is a resource directory.
LwM2M has a bootstrap mechanism. The address of the LwM2M Bootstrap Server needs to indeed hard-coded in the device, but the LwM2M server could potentially change. You can also directly use a single LwM2M that is hard-coded for a simple setup.
I don’t think that there is support for this, and haven’t heard of anyone implementing it so far.
But I don’t remember how we made the initial connection between a new
device and the server side (we probably had the address hard-coded).
One easy method is using the “All CoAP RDs” multicast address. It’s not
overly efficient (baeh broadcasts on the radio), but as I remember from
the plug tests only happens on start-up. It’s also not really multicast
in the sense that the RD endpoint implementation would actually accept
multiple responses, but with easy setups there’s only one responder
anyway.
Do you know if the RIOT supports the RDAO ND option mentioned in […]? (or if anyone is working on an implementation)
I don’t think that there is support for this, and haven’t heard of anyone implementing it so far.
I started some exploratory work, but let that rot when I couldn’t easily
announce RDAO from a Linux / OpenWRT host. Any ideas how that could be
done? Then the RIOT side should be pretty straight-forward as we have
all the relevant code around for similar options.
Sorry, not really, just some musings. If the RDAO is in the RA, maybe radvd could be coaxed into adding that option? Since the RDAO is not in the current version, it would need to be patched most likely.
