-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LwM2mNodeSenMLDecoder : Support for timestamped values #1479
Comments
Your client send that SenML value in a ReadResponse Correct ?
Exactly the point, the specification is not clear at all about that. The answer could be generalized to ReadResponse but this lead to some problem (as explain in OMA issue above ☝️), so I tried to get more answer about that without success ... 😞
Adding this to Leshan API is impacting and not clear how to handle inconsistent timestamp so I would prefer to get clear answer from OMA about that...
Yep timestamp is supported for |
For a short term solution, note that Leshan Library allow you to provide you own Encoder/Decoder, so you can change the behavior with some code if needed. |
Thanks, I confirm that it is send following a ReadResponse. |
I'm curious what do you plan to do ? 🙂 |
No big deal for now. We'll avoid SenML with ReadResponse. Our usecases for timestamps is mainly through observations. But we'll also try to clarify the specification with the owner client stack as it might not be compliant to timestamp values following a ReadResponse. |
Let me know what you find. In a general way, it's difficult to me to get answer from OMA. So do not hesitate to report us that this is an issue to not get answer and maybe you owner client stack can do that too ? (I added a new comment on related issue : OpenMobileAlliance/OMA_LwM2M_for_Developers#538) |
@cw8466 do you get more information about that ? |
Question
I have connected a client to a Leshan demo server (2.0.0-M10). That particular client adds a timestamp to the values when transmitted over SenML:
[{"n":"/3303/0/5700","t":321,"v":22.953123}]
which isn't typical of the examples provided by the specification as it doesn't specify an offset relative to a base timestamp. However, for a single value, it feels like the implementation makes sense, but the Leshan server throws this exception when it attempts to decode the SenML payload. Based on the exception, it feels like the issue is not how SenML timestamps are implemented by the client, but a lack a support altogether for SenML timestamped values by the server.
If correct, any particular reason why this is not supported? It seems like the timestamp is already parsed.
The text was updated successfully, but these errors were encountered: