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

Okay, that point is a bit tricky. At least tricky, if you want to have this web interface directly on the Microcontroller. I would use CoAP for this use-case. It makes the most sense. But there is one issue: Normal browser, like Mozilla, Chrome etc. don't support CoAP by default. There is Copper(https://github.com/mkovatsc/Copper), but as you can see it is discontinued. You can use an old browser, but I guess your point was to use a modern browser, right? There are other options as well, of course. LibCoAP is well supported. So, you can use it in a programming language of your choice. Every major language has some kind of CoAP lib. So, you could provide an CoAP interface you can interact with. Writing a CLI for it, shouldn't be a big deal. From the remote point of view: Just host a central management frontend which interacts with the devices. Collecting configs, collecting data etc. You probably also have to use edge device/border router/gateway in your setup. So, you could also put an instance of this web interface there as well. So that you have a web interface on-site as well. But having a CLI backup is probably also a good idea in case the web interface crashes. You can also have it more decentralized and let the edge device collect the data in some way.
There is room for different architecturial decisions.

*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?

Not sure, if JSONs is the best idea here, since you have to parse the JSON on the MCU. Using a filesystem in RIOT is quite simple. So, you can store it in files. When you call the API, you change the value in memory and on the file system. When the device wakes up it loads the configuration from the filesystem. I would also like to hear the input from other people, since I didn't had dynamic configuration yet.

*All configurations should also be synced with the remote server (e.g. running ODM2)
Just provide an API for this at your devices. So that you can change the configuration remotly. Of course, this should be done in a secured way.

Maybe it makes sense to use Web of Things (https://www.w3.org/WoT/) in your use-case. Especially considering you want to collect all these data, change the configuration etc. There is the WoT Scripting API which makes it quite simple to interact with the device and write a web frontend for it, once the WoT TD is present. Node-WoT(https://github.com/eclipse/thingweb.node-wot) is quite an advanced implementation of it. I wrote a PoC implementation for RIOT (https://github.com/w3c/wot-testing/tree/master/events/2020.09.Online/prototypes/RIOT-OS). If that sounds interesting to you, just ping me. I could imagine that you write some generic plugin/extension for ODM2 and support WoT TD on it. So that you can provide an interoperability layer. Eventually you could also replace your device with commercial available ones. They just have to support the WoT TD.


best regards
Philipp
_______________________________________________
users mailing list
users@riot-os.org
https://lists.riot-os.org/mailman/listinfo/users

Reply via email to