This is very useful, and it should be easy to add another layer on top
of the base driver to return data in an OIC appropriate format, but this
at least solves the confusion around SI unit types and scale, etc.
That is a good point. There are data models for different
type of sensors/controls over there. I’m see these are at
http://oneiota.org <http://oneiota.org/>. Acceleration, humidity, temperature
I think that's what everyone had in mind, yes, and similar to what I've
done with other systems where I implemented a generic 'read' and 'get
sensor details' function and a single sample data type across all
sensors (following what Android does beneath the hood).
- Are there specific config mechanisms that should be kept in mind?
Current framework provides a way to register resources; you can
register put/get routines for sensor/control. So it would be possible
to have very specific code per sensor.
However, if our sensor framework allowed us to enumerate connected
sensors, with common read interface serving data in known format, we
could export connected sensors to OIC automatically. That might be pretty
With a bit of thought and work, it should be possible to scan the I2C
bus at startup (for example) and initialise any sensors found on the
system if desirable, although it does mean maintaining a large list of
drivers in the firmware so space will become an issue over time.
Thanks for the link above though .... it's very useful to start poking
at a proof of concept, and keep in mind for any first draft APIs.