Re: New Device Services & SDK Requirements document (v5)


On 03/06/2018 06:24 PM, Drasko DRASKOVIC wrote:
On Tue, Mar 6, 2018 at 7:19 PM, espy <espy@...> wrote:

Thanks for the suggestion! It looks like this is still a draft, so we
should keep any eye on it as it progresses.
Yes, it's still a draft, but it's 13th release - it has been crafted
over a number of years now and is pretty mature. When it comes to
standards, this is the probably the best I know (not ideal, but at
least it is IETF standard draft).

Some observations:

- the readings embed the device name, making it possible to combine
readings from different devices in the same result array. EdgeX currently
adds the device name to the event, which contains readings.

- the format allows custom attributes to be defined, which would allow us
to add EdgeX specific attributes
Sure, this is all good. My only remark is that it is EdgeX specific,
and I think it is good to align on some more generic standard, if
Sure, I was just pointing out that if needed, the standard supports extra fields, so if we need the extensibility, it's already builtin.

- I don't think there's a big difference in size between our current
messages and the JSON SenML format, in fact the latter messages might even
be a bit larger than our current messages. That said, on constrained
devices using CBOR would be an advantage.
I think that difference comes from aggregated sensor measurements.
I.e. one sensor that reads for example temperature every hour, but it
does not send the reading immediately, but rather keeps the readings
in internal flash, then sends all in one message once a day. SenML is
good at packing these kind of messages in the array of readings,
removing redundancy and making messages as small as possible. For
cellular IoT sensors it is very important, as bandwidth is expensive.
And for battery powered devices radio Tx/Rx is the biggest enemy of
battery budget.
All good points.

Implementing this would require pretty invasive re-work across all of our
services, so this is something we should put on our post-California
architecture list.
I totally agree. I am not even sure that this is the best idea for
EdgeX, I was just pointing out SenML as a potentially good candidate
for standardized message semantics. We can do some research and
evaluation in later phases, post California MVP.


Join to automatically receive all group messages.