Hi Daniel,
see inline some answers and ideas for your use case.
Kind regards,
Marian
Dear RIOT OS community,
I'm Daniel a PhD in Hydrology at GFZ Potsdam and currently working on a
data logger system for use in extensive field campaigns. As far as I
have understood, RIOT OS seems to be very suitable for the tasks I have
in mind. Since I am new to using an OS on microcontrollers (rather than
running simple single-thread applications), I would very much like to
discuss with a RIOT expert (or several) what is possible and what is an
illusion of my perception. Here are some points to give you a bit of an
idea what I mean:
* Adding pre-compiled sensor driver packages to a running application
Let's say we have 20 stations running but with varying numbers and
types of sensors (e.g. sensors monitoring trees only in forests,
discharge sensors only at rivers, etc.). Is it possible to have a
common application running on all stations and adding/removing
pre-compiled sensor driver packages to change sensor setup? It would
allow easier on-site maintenance, where fast adding/removing sensors
would not lead to changing source code and compiling a new
application for one particular station (maintenance of course always
happens in winter, at night, with strong winds, heavy rain, in a
remote forest, hard to work on source code 
).
It would certainly be possible to use a common firmware that targets the
"full-fledged" node, but flash it on nodes with fewer sensors plugged in. Our
goal is that drivers perform during initialization a self check (usually read
out manufacturer and device ID and compare it against the expected values) - if
no such sensor is present, the initialization should return with an error code.
So my proposal is to just let the firmware detect upon start up which sensors
are present. Sadly, you will likely not be able to use auto initialization with
that approach, as you really want to check the return value of the
initialization to verify if the sensor is available and functional. (Well, you
could use SAUL with auto-initialization, as only successfully initialized
sensors should be registered in the SAUL registry.)
Note however, that it is pretty much impossible to detect hardware
configuration at runtime due to the plethora of different and incompatible
communication standards and the lack of any "plug and pray" protocols. So my
suggestion would only work if for each sensor the configuration is known at
compile time and each sensor can either be present in this very configuration,
or being unconnected.
But I fear that the test coverage for this scenario is not too well, so be
prepared to file a few bug reports regarding the self checks. (I expect some
drivers to still initialize even without hardware present, and some other
drivers to infinitely loop while trying to communicate with non-existing
hardware.)
* Having a web interface running, accessible via Ethernet or BLE (for
on-site maintenance) and remote (e.g. via LTE CAT M1/NB1 for
administration) to allow configuring sensor setup (number and type)
as well as general configuration (measurement interval, time of data
upload, etc.)
A simple graphical web interface would ease the maintenance for the
technician as he would "only" need to change configurations rather
than changing source code and compiling (see point above). Since I
am working currently with OpenMediaVault, I really appreciate their
web interface concept, with the possibility to revert all currently
made changes.
That would certainly be possible to implement on top of RIOT. I'm unaware of
anyone running an HTTP server on RIOT, but that shouldn't be too difficult to
achieve.
However, maybe a CoAP server would be a better option? By reusing the
core concepts of HTTP based REST APIs (same message-response model, URIs,
content formats (lightweight MIME Types), ...) CoAP can be trivially reached
from HTTP by using cross protocol proxies that transparently translate between
HTTP and CoAP. And you might be able to use the same CoAP interfaces for both
human 2 machine maintenance scenarios as well regular m2m communication.
Btw: lwm2m could also be something you might want to check out as an option for
device management.
* All these configurations would need to be stored locally, I imagine
as JSON on an EEPROM with some kind of file system. Is this how it
is done in general?
Usually the overhead of file systems is considered to be too huge for EEPROM
devices. RIOT has the EEPROM registry module that works well as a low-overhead
key value storage - which could be viewed as a primitive non-hierarchical file
system. That should actually be quite a good match for storing configuration
data.
If you want to go with an actual file system, you're likely better off with
flash memory or SD cards as storage.
You might want to look at CBOR as alternative to JSON. It uses pretty much the
same data model as JSON, but is more efficient in terms of storage and in terms
of parsing overhead. Same as CoAP and HTTP, you can just convert data between
the formats (with some limitations), but generally CBOR should be better suited
for constrained devices.
* All configurations should also be synced with the remote server
(e.g. running ODM2)
I hope these points make some sense even if the answer is: No, what you
want is not possible. And if not, I am happy to learn more. As mentioned
before, I would appreciate a discussion about this use case and the
potential use of RIOT OS with experienced people who find it
interesting. In case spamming the user list is not desired you can of
course contact me via my email address daniel.beiter@gmx.at
Actually, I personally would like to hear more about how people are using RIOT
or intending to use RIOT. Have this context information can be quite beneficial
for making design decisions in RIOT - and hearing some success stories are quite
motivating for the RIOT developers. So from my point of view you are very
welcome to keep this discussion here.
).