I created a measurements Java class called LoraRfInfo. I add LoraRfInfo as a measurement into Cumulocity as follows:
measurementRep.setSource(mo);
measurementRep.setType("tl_LoraRfInfo");
measurementRep.set(loraRfSignal);
measurementRep.setTime(new Date());
measurements.create(measurementRep);
I would like to visualize the stored LoraRfInfo measurement data in a "data points graph" widget, but can't figure out how to do that. Anyone knows how to visualize custom data points (i.e. non c8y_xxx) in a Cumulocity "data points graph" widget?
It's been a while since the question came up, but this might be useful for anyone who's looking for this.
In Java, you can create your own class if you want to visualize your custom data. The value however always has to be in a
com.cumulocity.model.measurement.MeasurementValue
Therefore, MeasurementValue has to be a property in your custom class.
The display name in Cumulocity will always be packageName_ClassName.
To use measurements in widgets, they need to follow the structure described in http://cumulocity.com/guides/reference/measurements/. On REST level, this structure is
{ "tl_LoraRfSignal": {
"<your measurement>": { "value": ..., "unit": "..." },
"<your measurement>": { "value": ..., "unit": "..." },
...
}
(Assuming that the class behind your variable loraRfSignal is tl.LoraRfSignal.)
On Java level, add properties of type MeasurementValue to locaRfSignal. An example can be found here: https://bitbucket.org/m2m/cumulocity-clients-java/src/53216dc587e24476e0578b788672416e8566f92b/device-capability-model/src/main/java/c8y/SignalStrength.java?at=default&fileviewer=file-view-default.
The "c8y_" in the beginning does not matter. It's merely a naming convention.
Related
The API I consume, thank to Retrofit, return a lot of json which the root level consist of a container with only a list inside of it, for example:
{
"data": [
...
]
}
In this example the name is "data" but it may vary depending on the route.
Is there a way to automatically unbox it so only the list is returned ?
Follow this article to implement this pattern:https://medium.com/#naturalwarren/moshi-made-simple-jsonqualifier-b99559c826ad
Could not find this answer online, so decided to post the question then the answer.
I created a table in the capabilities.json file:
"dataRoles": [
{
"displayName": "Stakeholders",
"name": "roleIwant",
"kind": "GroupingOrMeasure"
}
...
"dataViewMappings": [
{
"table": {
"rows": {
"select": [
{
"for": {
"in": "roleIwant"
}
}
]
}
}
}
]
I realized that I could not simply set, for instance, legend data from the first category, because the first category comes from the first piece of data the user drags in, regardless of position. So if they set a bunch of different pieces of data in Power BI online, for instance, then remove one, the orders of everything get messed up. I thought the best way to settle this would be to identify the role of each column and go from there.
When you click on show Dataview, the hierarchy clearly shows:
...table->columns[0]->roles: { "roleIwant": true }
So I thought I could access it like:
...table.columns[0].roles.roleIwant
but that is not the case. I was compiling using pbiviz start from the command prompt, which gives me an error:
error TYPESCRIPT /src/visual.ts : (56,50) Property 'roleIwant' does not exist on type '{ [name: string]: boolean; }'.
Why can I not access this in this way? I was thinking because natively, roles does not contain the property roleIwant, which is true, but that shouldn't matter...
The solution is actually pretty simple. I got no 'dot' help (typing a dot after roles for suggestions), but you can use regular object properties for roles. The command for this case would be:
...table.columns[0].roles.hasOwnProperty("roleIwant")
And the functional code portion:
...
columns.forEach((column) =>{
if(column.roles.hasOwnProperty("roleIwant")){
roleIwantData = dataview.categorical.categories[columns.indexOf(column)].values;
})
If it has the property, it belongs to that role. From here, the data saved will contain the actual values of that role! The only thing I would add on here is that if a column is used for multiple roles, depending on how you code, you may want to do multiple if's to check for the different roles belonging to a column instead of if else's.
If anyone has any further advice on the topic, or a better way to do it, by all means. I searched for the error, all over for ways to access columns' roles, and got nothing, so hopefully this topic helps someone else. And sorry for the wordiness - I tend to talk a lot.
I am trying to use the Asana API to create a task that is assigned to me and added to an existing project.
I have tried by not specifying the workspace as suggested by someone else but the task creation still fails.
The jSon I am using is the following;
{ "data":
{
"name":"Testing Project",
"followers":[10112, 141516],
"workspace":6789,
"assignee":12345,
"project": 1234
}
}
If I create the task and then send another call to the API with the following jSon it works, but this means I need to make 2 API calls every time I create a task.
{
"project": 1234
}
Rather old question but it might help someone. Yes, you can attach a task to a project during creation using the 'projects' (not 'project' as stated above) param, passing its id.
You can also attach the task to many projects stating an array at 'projects' => {22, 33, 44}.
It's all here at https://asana.com/developers/api-reference/tasks
(I work for Asana)
The specification for Tasks can be found here: https://asana.com/developers/api-reference/tasks
Notably, you cannot specify a project during creation - you must go through the addProject call for each project you wish to add.
If there is contradictory information on another SO question, I apologize as that may have been written without first double-checking the implementation.
The actual problem is that you are passing an int instead of an string for "projects". Some attributes work well as string or int (e.g. "assignee" or "workspace") but not "projects".
..so correct your json to the following:
{
"data":
{
"name":"Testing Project",
"followers":[10112, 141516],
"workspace":6789,
"assignee":12345,
"project": "1234"
}
}
I wasted half a day -.-'
I'm designing a REST API and am looking for the recommended best practice for updating object graphs. My question is best explained in an example, so let's say that I have a GET resource as follows:
URI: /people/123
This URI returns an object graph like this:
{
"name":"Johnny",
"country":{"id":100,"name":"Canada"},
"likes":[
{"id":5,"name":"Fruit"},
{"id":100,"name":"Sports"}
]
}
When allowing the API consumer to update this resource, how would you expect the object to be updated via PUT or PATCH? Updating the "name" property is pretty straightforward, but I'm not certain about "country" or "likes", as the consumer can only only change the relationship to other objects and not create new ones.
Here is one way to request the update:
{
"name":"Bob",
"countryId":200
"likeIds":[3,10,22]
}
This update will change the resource to the following:
{
"name":"Bob",
"country":{"id":200,"name":"United States of America"},
"likes":[
{"id":3,"name":"Cars"},
{"id":10,"name":"Planes"},
{"id":22,"name":"Real Estate"}
]
}
This design explicitly and clearly asks the consumer to only update the "IDs" of the "Person", but I'm concerned that the object graph for a PUT/PATCH looks different than the GET, making the API hard to learn and remember. So another option is to request the PUT/PATCH as follows:
{
"name":"Bob",
"country":{"id":100},
"likes":[
{"id":3},
{"id":10},
{"id":22}
]
}
This will yield the same change as the previous update and does not alter the object graph. However, it doesn't make it clear to the API consumer that only the "IDs" can be updated.
In this scenario, which approach is recommended?
In my opinion you should stay with the same structure for both, GET and PUT requests. Why? Because it's quite common to map JSON/XML data into objects, and most (if not all) software that do the actual mapping work best if JSON schema is always the same.
So your webservice should accept a following JSON code:
{
"name":"Joe",
"country":{"id":200,"name":"United States of America"},
"likes":[
{"id":5,"name":"Fruit"}
]
}
However it doesn't have to take into account the country name and may focus only on the country id.
I'm designing a new API for my project, and I want to return objects that have nested children as json. For that purpose i've decided to use RABL.
I want the client side to be able to understand whether the object is valid, and if not which fields are missing in order to save it correctly.
The design I thought of should include some fields as optional, under an optional hash, and the rest are required. The required fields should appear right under the root of the json.
So the output I try to describe should look something like this:
{
"name": "John",
"last_name": "Doe",
"optional": {
"address": "Beverly Hills 90210",
"phones":[{"number":"123456","name":"work"}, {"number":"654321","name":"mobile"}]
}
}
The above output example describes the required fields name and last name, and the not required address and phones (which is associated in a belongs_to-has_many relationship to the object). name, last_name and address are User's DB fields.
Playing with RABL I didn't manage so far to create this kind of structure.
Any suggestions? I'm looking for a DRY way to implement this for all my models.
RABL is really good in creating JSON structures on the fly, so I don't see why you couldn't achieve your goal. Did you try testing if a field is set to null-able in the schema, and thus presenting it as optional? It seems a good approach for me. For the nested children, just do the same, but extend the template for the children.
For example, in your father/show.rabl display a custom node :optional with all the properties that can be null.
Then, create a child/show.rabl with the same logic. Finally, go back to father/show.rabl and add a child node, extending the child/show.rabl template. This way you could achieve unlimited levels of "optionals".
Hope it helped you.
In this case I'd use the free form option.
From https://github.com/nesquena/rabl
There can also be odd cases where the root-level of the response
doesn't map directly to any object.
In those cases, object can be assigned to 'false'
and nodes can be constructed free-form.
object false
node(:some_count) { |m| #user.posts.count }
child(#user) { attribute :name }