Dear RIOT Users community, first of all thank you very much for your input, it is very much appreciated! While trying to put the various responses into context, this is what I made out of it:
* IP communication between remote/on-site and node either via HTTP (not adapted for constrained environments) or CoAP (no web browser support) Under these circumstances, a cross-platform client application using libCoAP seems reasonable as it also allows running as much logic as possible on the client. * Binary CBOR format instead of JSON for configuration data makes parsing cheaper * Instead of storing it on an EEPROM it could be done on an on-board flash memory with according file system * The most complicated part seems to me the sensor situation. From what I understand the best approach would be to deliver all device drivers for potential sensors as part of the compiled application firmware. If a new sensor could be potentially interesting for the node, a device driver must be developed and the firmware needs to be compiled anew. That would be alright and is not so much of an obstacle. However, I wonder how much control I would still have regarding the sensor configuration during run-time (or after a reboot). For example in environmental monitoring many commercial producers of sensors use the SDI-12 bus (serial communication at 1200 baud, half-duplex, single character as local address, specified protocol with set of commands, responses, timings, etc.). Let's say maintenance requires to replace a defect sensor, device ID might/should change, local address (on the bus) might change or remain the same, calibration parameters might vary, but from a scientific point of view the new sensor still measures the same quantity as the one before. It would be good, to have this degree of control in the form of configuration settings regarding the device driver and node. So far it is not clear to me, whether everything needs to be defined at compile-time, making it necessary to recompile after every change to the system setup, or if the device driver can access configuration information stored as CBOR on the flash memory (on runtime or after boot-up). Perhaps the answer lies in SAUL, but so far I could not make myself familiar with it. In any case, thank you for your feedback so far. Of course I am happy to hear any other ideas of yours. Kind regards Daniel
_______________________________________________ users mailing list users@riot-os.org https://lists.riot-os.org/mailman/listinfo/users
