Re: OIC support

[Kevin Townsend]

me and Paul brought in constrained iotivity stack few months back
to Mynewt, and I probably should send an update what’s going on.

I’ve been working on getting it more fully integrated. My first
goal is to get the code size/RAM usage down.

Just as a FYI for anyone else interested in understanding 
OIC/Iotivity/etc. a bit more, I found this presentation useful to 
highlight the key concepts: 
https://openconnectivity.org/wp-content/uploads/2016/01/OIC_Specification_Overview_201501131.pdf

Re: OIC support

[Kevin Townsend]

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

Re: OIC support

[marko kiiskila]

> On Dec 1, 2016, at 12:57 PM, Kevin Townsend  wrote:
> 
>> 
>> Hi,
>> 
>> me and Paul brought in constrained iotivity stack few months back
>> to Mynewt, and I probably should send an update what’s going on.
>> 
>> I’ve been working on getting it more fully integrated. My first
>> goal is to get the code size/RAM usage down.
>> 
>> To cut down code size I’m converting it to use MyNewt’s memory pools,
>> timers, and event queues. By default we also left quite a bit logging
>> turned on, so I’ll make that optional (inclusion controlled by syscfg
>> settings).
>> To cut down RAM use I’m going to convert it to use os_mbuf for
>> data packets. This will probably make code size slightly larger,
>> but allows me to share the memory pool with bluetooth stack.
>> 
>> My end goal is to have OIC running over bluetooth in a way which
>> allows us to connect to apps written using iotivity’s framework
>> https://github.com/iotivity/iotivity  
>> > >.
> I'm quite interested in this from a sensor driver point of view. I have no 
> experience with iotivity, but if it will be a core part of Mynewt moving 
> forward, it would be good to get a sense of what kinds of requirements the 
> stack would place on sensors and sensor configuration, since that's the area 
> I'm most likely to get involved with on my end.

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 . Acceleration, humidity, temperature 
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.

Protocol allows the client to discover what resources are exported by
the device. So a generic app would not be out of the question.

> - Are there any definitions about power mode and device/driver 'state’?

I have not encountered power management stuff in the spec, but
admittedly I have not studied it in detail.
https://openconnectivity.org/resources/specifications 

> - What are the practical payload limitations given BLE as a transport?

This uses modified CoAP for data transfer, and that allows bluetooth
to do it’s fragmentation without limiting frame size for data on top.
Our current code only does ‘standard CoAP’; I’ll add the support
for TCP-like headers as well. Then it’s just memory consumption which
will be the issue, AFAIK.

> It's too early to probably answer a lot of those things definitively, but it 
> would be good to get the ball rolling as we start throwing some ideas around 
> publicly about a sensor API as well.

Agreed. We can always adjust things later, but it’s better to get
off with the right foot.

Re: OIC support

[Kevin Townsend]

Hi,

me and Paul brought in constrained iotivity stack few months back
to Mynewt, and I probably should send an update what’s going on.

I’ve been working on getting it more fully integrated. My first
goal is to get the code size/RAM usage down.

To cut down code size I’m converting it to use MyNewt’s memory pools,
timers, and event queues. By default we also left quite a bit logging
turned on, so I’ll make that optional (inclusion controlled by syscfg
settings).
To cut down RAM use I’m going to convert it to use os_mbuf for
data packets. This will probably make code size slightly larger,
but allows me to share the memory pool with bluetooth stack.

My end goal is to have OIC running over bluetooth in a way which
allows us to connect to apps written using iotivity’s framework
https://github.com/iotivity/iotivity .
I'm quite interested in this from a sensor driver point of view. I have 
no experience with iotivity, but if it will be a core part of Mynewt 
moving forward, it would be good to get a sense of what kinds of 
requirements the stack would place on sensors and sensor configuration, 
since that's the area I'm most likely to get involved with on my end.


- Are there specific config mechanisms that should be kept in mind?
- Are there any definitions about power mode and device/driver 'state'?
- What are the practical payload limitations given BLE as a transport?

It's too early to probably answer a lot of those things definitively, 
but it would be good to get the ball rolling as we start throwing some 
ideas around publicly about a sensor API as well.


Kevin

OIC support

[marko kiiskila]

Hi,

me and Paul brought in constrained iotivity stack few months back
to Mynewt, and I probably should send an update what’s going on.

I’ve been working on getting it more fully integrated. My first
goal is to get the code size/RAM usage down.

To cut down code size I’m converting it to use MyNewt’s memory pools,
timers, and event queues. By default we also left quite a bit logging
turned on, so I’ll make that optional (inclusion controlled by syscfg
settings).
To cut down RAM use I’m going to convert it to use os_mbuf for
data packets. This will probably make code size slightly larger,
but allows me to share the memory pool with bluetooth stack.

My end goal is to have OIC running over bluetooth in a way which
allows us to connect to apps written using iotivity’s framework
https://github.com/iotivity/iotivity .