I am trying to make code to store historic data, in case my network connection have been down, I want the attribute values collected during the network downtime, to be sent to the serer once the network connection is restored.
I read the documentation here:
and there are a method mentioned where I should use the endpoint
/api/master/asset/{assetID}/attribute/{attributeName}/{timestamp}
BUT if I do etc.
/api/master/asset/5NjH8Zl2d36EuqCItcjwJ5/attribute/temperature/1746284228
I get an error 404 NOT found
If I remove the timestamp and do like this
/api/master/asset/5NjH8Zl2d36EuqCItcjwJ5/attribute/temperature/
I get an error 406 Not acceptable
I also tried the solution mentioned here:
And then add json body like this
[
{
“ref”: {
“id”: “5NjH8Zl2d36EuqCItcjwJ5”,
“name”: “temperature”,
“timestamp”: 1746284228
},
“value”: 25
}
]
I had the same need when that functionality was not yet possible in OR. Now, I can’t use it either, but that’s another story. So I wrote my code to allow direct writing to PostgreSQL from OR, it’s always good to have a plan B!
In case of a single attribute update, the payload should be the raw value in itself.
So it’s not necessarily a JSON Object, but a JSON value like a number or string.
For example;
'test message'
curl -L -X PUT 'http://<hostname>/api/master/asset/3ZhpgRBZXTtpU4vRUT1pB1/attribute/notes/1752665582860' -d 'test message'
.
or in case of numbers
0.601
curl -L -X PUT 'http://<hostname>/api/master/asset/3ZhpgRBZXTtpU4vRUT1pB1/attribute/amount/1752665582860' -d '0.601'
.
It’s on our roadmap / radar to improve the HTTP API documentation.
But I hope this helps!
Yes, putting only the value works. However, it seems that there are some peculiarities depending on the timestamp used, which may be what causes confusion when testing the endpoint. The timestamp restrictions don’t make sense to me, and you should be able to allow any timestamp, even future ones. I suppose it must be related to the inner workings of OR.
Well, it doesn’t matter, for some uses it will serve me, for others it will not.
Thanks Martin