SENML_JSON encoder modifications proposal

[JaroslawLegierski]

Question

1. Timestamp coding in SENML_JSON encoder

Currently leshan SENML_JSON encoder can encode following records:

[
	{
		"bn": "/3303/0/5700",
		"bt": 1699877805.766,
		"v": -128.8
	},
	{
		"bn": "/6/0/0",
		"bt": 1699877805.800,
		"v": -39.0
	}
]

can we change this format to following one: ?

[
	{
		"bn": "/3303/0/5700",
		"bt": 1699877805.766,
		"v": -128.8
	},
	{
		"bn": "/6/0/0",
		"t": 0.101,
		"v": -39.0
	}
]

2. Support of mixed data (with and without timestamps)

Is it possible to modify the encoder to support mixed data with timestamp and without it in one SENML record e.g.:

[
	{
		"bn": "/3303/0/5700",
		"bt": 1699877805.766,
		"v": -128.8
	},
	{
		"bn": "/6/0/0",
		"v": -39.0
	}
]

[sbernard31]

1. Just to be sure are we agree that current encoding is valid ?
2. What would be the point about changing the current behavior ? is it an optimization purpose (reduce payload size) ?

[JaroslawLegierski]

1. Just to be sure are we agree that current encoding is valid ?

   2. What would be the point about changing the current behavior ? is it an optimization purpose (reduce payload size) ?

It probably depends on the use case. However I checked examples in rfc8428 and I see that we have bt in the first measurement and t in subsequent measurements:

e.g. in this section:

   [
     {"bn":"urn:dev:ow:10e2073a0108006:","bt":1.276020076001e+09,
      "bu":"A","bver":5,
      "n":"voltage","u":"V","v":120.1},
     {"n":"current","t":-5,"v":1.2},
     {"n":"current","t":-4,"v":1.3},
     {"n":"current","t":-3,"v":1.4},
     {"n":"current","t":-2,"v":1.5},
     {"n":"current","t":-1,"v":1.6},
     {"n":"current","v":1.7}
   ]

or here:

   [
     {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09,
      "bu": "%RH", "v":20},
     {"u":"lon","v":24.30621},
     {"u":"lat","v":60.07965},
     {"t": 60, "v": 20,3},
     {"u":"lon","t":60,"v":24.30622},
     {"u": "lat", "t": 60, "v": 60.07965},
     {"t": 120, "v": 20,7},
     {"u":"lon","t":120,"v":24.30623},
     {"u": "lat", "t": 120, "v": 60.07966},
     {"u":"%EL","t":150,"v":98},
     {"t": 180, "v": 21,2},
     {"u":"lon","t":180,"v":24.30628},
     {"u": "lat", "t": 180, "v": 60.07967}
   ]

in OMA LwM2M specification we also can find similar record:

[{"bn":"/72/","bt":25462634,"n":"1/2","v":22.4,"t":-5},
{"n":"1/2","v":22.9,"t":-30},
{"n":"1/2","v":24.1,"t":-50}]

I noticed that similar rules apply to bn and n. What do You think ?

Device vendors are also using the following formats:

[
	{
		"bn": "/",
		"bt": 12,
		"n": "3303/0/5700",
		"v": 23.9034576
	},
	{
		"n": "3304/0/5701",
		"vs": "%hum"
	}
]

Please find above SenML record produced by IoTerop SDK ☝️

[sbernard31]

I must confess that I didn't get your point. I will try to summarize my understanding.

SenML is not a one to one encoding format.

There is several way to encode a given data in valid SenML format.

All those valid SenML example express exactly the same thing

{"bn":"/base/", "n":"name1", "v":101},
{ "n":"name2", "v":102},
{ "n":"name3", "v":103},

{ "n":"/base/name1", "v":101},
{ "n":"/base/name2", "v":102},
{ "n":"/base/name3", "v":103},

{"bn":"/base/name1", "v":101},
{"bn":"/base/name2", "v":102},
{"bn":"/base/name3", "v":103},

Leshan Decoder

As SenML is not a one to one encoding format, Leshan Decoder should be able to decode any possible way to express data in SenML.

Currently, I think Leshan Default SenML decoder to that.

Leshan Encoder
About encoding, Leshan should choose 1 valid way to encode.

Currently, I think Leshan Default SenML encoder to that.

Questions

Just to be sure I understand you :

• do you agree that current encoding is valid ?
• What would be the point about changing the current encoding behavior ? is it an optimization purpose (e.g. reduce payload size) ?

[JaroslawLegierski]

• do you agree that current encoding is valid ?

Yes I think current encoding is valid.

• What would be the point about changing the current encoding behavior ? is it an optimization purpose (e.g. reduce payload size) ?

I was thinking about using in this test the same data structure as produces Ioterop SDK, but finally we can leave it as is.

[sbernard31]

Oh ok, this was just about writing test, I get it now 🤔. I don't think this is a good reason to change default leshan encoder behavior.

But it could make sense to add Decoder tests with different kind of encoding than the one used by Leshan Encoder.
So, If you think this is a good idea and if you want to do it, you could add test about that :

• to the existing LwM2mNodeDecoderTest class
  -OR to a new class LwM2mNodeSenMLDecoderTest class (currently it does not exist)

[sbernard31]

with #1577 integrated, I guess we can close this issue.

(If I was wrong do not hesitate to reopen)