> On Dec 1, 2016, at 12:57 PM, Kevin Townsend <ke...@adafruit.com> wrote:
>> 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
>> 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 <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 <http://oneiota.org/>. Acceleration, humidity, temperature
> - 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
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.
> - 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.