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

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.
- 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
exciting.
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).

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.

Reply via email to