Is it possible to update a child attribute through the updateAttributes() function from Wirecloud NGSI API?
For example, a coordinate (entity.location.coords.coordinates[0]=-2.000000) in this piece of entity.
"attrNames": [ "A1", "A2", "position" ],
"creDate": 1389376081,
"modDate": 1389376244,
"location": {
"attrName": "position",
"coords": {
"type": "Point",
"coordinates": [ -3.691944, 40.418889 ]
}
EDITED
My own answer: It is possible by passing an object as value of the attribute.
ngsi.updateAttributes([
{
'entity': {'id': "entity-id"},
'attributes':[{
"name":"location","contextValue": {
"attrName": "position",
"coords": {
"type": "Point",
"coordinates": [ -2.000000, 40.418889 ]
}
}
}]
}
], {
onSuccess: onUpdateAttributesSuccess,
onFailure: onUpdateAttributesFail
}
);
However, Wirecloud is using NGSI API v1, therefore all attributes are treated as strings when they are sent/received to/from Orion.
More info: http://fiware-orion.readthedocs.io/en/master/user/structured_attribute_valued/
Currently, it's not possible to make partial changes into an structure attribute using the WireCloud's NGSI API. Moreover, as far as I know, the NGSI API doesn't provide a direct way for making partial updates into structured attributes (neither v1 nor v2).
However, v1 of the NGSI API supports structured attribute values. So you can make use of the updateContext method to update only one attribute (e.g. the coordinates attribute). The only thing to take into account it's that you will have to provide the full value, so if you want to make a partial change you have to read the value, make the partial change and update it.
In fact, you almost have it working. You only have to fix the way you are passing the attributes to update, you should wrap them into an array:
ngsi.updateAttributes([{
"entity": {"id": "entity-id"},
"attributes": [
{
"name": "location",
"contextValue": {
"attrName": "position",
"coords": {
"type": "Point",
"coordinates": [-2.000000, 40.418889]
}
}
}
]
}],
{
onSuccess: onUpdateAttributesSuccess,
onFailure: onUpdateAttributesFail
}
);
Related
I am creating a data model for a particular application and I did not start from any base model; since I did not start from any base model, the context below is sufficient, correct?
"#context": [
"https://schema.lab.fiware.org/ld/context",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.3.jsonld"
]
My data model is not complicated, with just these properties and entity being more "complex":
"address": {
"type": "Property",
"value": {
"streetAddress": "",
"postalCode": "",
"addressLocality": "",
"addressCountry": ""
}
},
"location": {
"type": "Point",
"coordinates": [
,
]
},
{
"id": "urn:ngsi-ld:MeasurementSensor:",
"type": "MeasurementSensor",
"measurementVariable": {
"type": "Property",
"value": "Temperature"
},
"measurementValue": {
"type": "Property",
"value": 32.0,
"unitCode": "ÂșC",
"observedAt": "2022-05-10T11:09:00.000Z"
},
"refX": {
"type": "Relationship",
"object": "urn:ngsi-ld:"
},
"#context": [
"https://schema.lab.fiware.org/ld/context",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.3.jsonld"
]
}
If you are using your own custom vocabulary you should declare your types and properties in your own LD #context. For instance,
{
"#context": [
{
"MeasurementSensor": "https://example.org/my-types/MesaurementSensor"
},
"https://schema.lab.fiware.org/ld/context",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.3.jsonld"
]
}
it also seems you are not using URNs properly, you should check. unitCode seems to be broken as well, as it must follow the UN/CEFACT unit codes.
Nonetheless, I would not recommend to define your own vocabulary for sensors, given there are existing Vocabularies such as SAREF or W3C SOSA that can and should be reused.
I'm not a data model expert but I do know a thing or two about NGSI-LD and NGSI-LD brokers.
The #context you use is an array of "https://schema.lab.fiware.org/ld/context" and v1.3 of the core context.
"https://schema.lab.fiware.org/ld/context" in its turn is an array of "https://fiware.github.io/data-models/context.jsonld" and v1.1 of the core context ...
And, ""https://fiware.github.io/data-models/context.jsonld" doesn't define any of the three terms you are using, so, no need to give any context for that. The terms will be expanded using the default URL of the core context (the value of the #vocab member of the core context defines the default URL).
An NGSI-LD broker has the core context built-in, you don't need to pass it, so do yourself a favor, and get faster responses by not passing the core context to the broker. No need.
And, if you need a user context, pass it in the HTTP Header "Link" instead.
Host it somewhere (an NGSi-LD broker offers that service), so you don't force the poor broker to parse the #conterxt in each and every request.
Lastly, do follow Jose Manuels recommendations and use standard names for your attributes (and value for unitCode).
I'm new to couchbase. I want to update channels for some of the documents through sync functions. But right now, it is not updating but adding an extra channel to the document's meta but not removing the existing channel. Can anyone suggest how I can remove the existing channel in the document?
Sync Function:
function(doc, oldDoc) {
//....
if (doc.docType === "differentType") {
channel("differentChannel");
expiry(2332800);
return;
}
//.......
}
Document:
{
"channels": [
"abcd"
],
"docType": "differentType",
"_id" : "asjnc"
}
Metadata:
{
"meta": {
"id": "asjnc",
"rev": "64-1b500000000",
"expiration": 1650383285,
"flags": 0,
"type": "json"
},
"xattrs": {
"_sync": {
"rev": "1-db30e607872",
"sequence": 777,
"recent_sequences": [
777
],
"history": {
"revs": [
"1-db30e607872"
],
"parents": [
-1
],
"channels": [
[
"differentChannel"
]
]
},
"channels": {
"differentChannel": null
}
}
}
}
Expectation of the document with the same metadata:
{
"channels": [ ], // <--- no channels
"docType": "differentType",
"_id" : "asjnc"
}
With this sync function, for the document of type differentType, the channel differentChannel is set in the xattrs section in the metadata. But the channel that was added earlier from the couchbaseLite is not getting removed. Can anyone help?
I answered this in the Couchbase Forums: https://forums.couchbase.com/t/remove-channels-from-a-document/33212
The "channels" property in a document is counter-intuitively not describing what channels the document is currently in - it's just a user-definable field that happens to be the default routing for channels if you don't specify a sync function. It's up to the writer of the document what it should contain.
If you have another means of channel assignments (like "docType" in your case), then you don't need to specify "channels" in the document. The sync metadata shows that the document is in "differentChannel" at revision 1-db30e607872 but the contents of the document can be arbitrary.
I have noticed that upon querying Orion CB, while it is working with provisioned devices and having IoT Agent receive HTTP and MQTT messages, it will always output all the values written in the quotation marks:
{
"id": "sensor_data",
"type": "Sensor",
"ActiveTime": {
"type": "Seconds",
"value": "17703",
"metadata": {
"TimeInstant": {
"type": "ISO8601",
"value": "2018-07-04T13:32:27.357Z"
}
}
},
"Distance": {
"type": "Number",
"value": "312",
"metadata": {
"TimeInstant": {
"type": "ISO8601",
"value": "2018-07-04T13:32:27.413Z"
}
}
}
}
However, if to work with only entities in Orion CB, it is possible to receive actual values (like in the example in the manual):
{
"id": "Room1",
"pressure": {
"metadata": {},
"type": "Integer",
"value": 720
},
"temperature": {
"metadata": {},
"type": "Float",
"value": 23
},
"type": "Room"
}
Sometimes, I need to receive the actual value from my sensor in order to format it and use in further applications, but they are in quotation marks, which makes it a little difficult.
Is it possible to somehow change?(maybe in device provisioning), or it really should be that way regarding devices?
Thanks in advance!
EDIT 1
This is the way I provisioned the device:
{
"devices": [
{
"device_id": "sensor_data",
"entity_name": "sensor_data",
"entity_type": "Sensor",
"transport": "MQTT",
"timezone": "Europe/Helsinki",
"attributes": [
{ "object_id": "act", "name": "ActiveTime", "type": "Seconds"},
{ "object_id": "dst", "name": "Distance", "type": "Number"}
]
}
]
}
And this is how the MQTT messages are sent from my sensor (I have set up the topics for IoT Agent to understand them)
/123456789/sensor_data/attrs/act 12
/123456789/sensor_data/attrs/dst 322
123456789 is the API Key I have set here.
This situation tipycally happens when IoT Agents uses NGSIv1 to push data to Context Broker, given that NGSIv1 always "string-fy" any attribute value. Recently, the ability to use NGSIv2 (which doesn't have this limitatino) was introduced in IoT Agents.
In order to solve your problem you have to:
Use a recent IOTA-UL version (the current one from master branch will work)
Enable NGSIv2 in configuration as explained in documentation. This is done in the config.js file:
config.iota = {
...
contextBroker: {
...
ngsiVersion: 'v2'
}
...
}
or using environament variable IOTA_CB_NGSI_VERSION=v2 for the IOTA-UL process.
Enable autocast as explained in documentation. This is done in config.js file:
config.iota = {
...
autocast: true,
...
}
or using environament variable IOTA_AUTOCAST=true for the IOTA-UL process.
Set the right type for each attribute at provision time. The documentation here) provides the right types:
Type "Number" for integer or float numbers
Type "Boolean" for boolean
Type "None" for null
Thus, in your case the provisioning for Distance is ok, but for ActiveTime you should use also Number as type.
It's really hard to find a clear answer about how to create a comment on an issue which is internal only.
The JIRA Cloud REST API Documentation specifies the following schema for setting properties on comments when creating or updating a comment on an incident
https://docs.atlassian.com/jira/REST/cloud/#api/2/issue/{issueIdOrKey}/comment-addComment
"properties": {
"type": "array",
"items": {
"title": "Entity Property",
"type": "object",
"properties": {
"key": {
"type": "string"
},
"value": {}
},
"additionalProperties": false
}
}
To make a comment on an issue internal (meaning only service desk agents can see the comment) you need to set the sd.public.comment key to have the value { "internal": true }
Which can be achieved by passing the following JSON in the body of the create or update API request.
{
"properties": {
"key": "sd.public.comment",
"value": {
"internal": true
}
}
}
You will also need to set the Content-Type header on the request.
Content-Type: application/json
The following is an example of a creating an internal comment using a Groovy script - the scripting language used by ScriptRunner (a popular JIRA plugin)
post("/rest/api/2/issue/${issue.id}/comment")
.header("Content-Type", "application/json")
.body([
body: "This is the text which will appear in the comment",
properties: [
[key: "sd.public.comment", value: [ "internal": true ]]
]
]).asString()
Note that Object / JSON mapping will differ depending on which scripting language or HTTP Request framework you are using.
Request:
{
"PersonSearch":
{
"LastName": "Doe",
"Gender":"Male",
"State" : "FL"
}
}
or
{
"PersonSearch":
{
"FirstName": "John",
"Gender":"Male",
"State" : "FL"
}
}
What is the json schema that I can validate both requests.
It has to be compatible with drraftV3.
Your requirements seem to be that you need either "FirstName" or "LastName", correct?
There is no way to specify a single schema that works for both v4 and v3, because of some fundamental changes in the spec: in v4 type can only hold a string (or array of strings). It is not permitted to use schemas inside type.
You should avoid using v3 if possible, and move over to v4.
v4 method:
In that case, you'll need to use anyOf for that particular constraint:
{
"type": "object",
"anyOf": [
{"required": ["FirstName"]},
{"required": ["LastName"]}
],
"properties": {...}
}
v3
In v3 syntax, you use type instead of anyOf (also, required is a boolean):
{
"type": [
{
"type": "object",
"properties": {
"FirstName": {"required": true}
}
},
{
"type": "object",
"properties": {
"LastName": {"required": true}
}
}
],
"properties": {...}
}
v3 -> v4 conversion
If you're stuck with a mixture of v3/v4 schemas, this tool (json-schema-compatibility) will normalise schemas (v3 or v4) into v4 syntax.
If you're working in JavaScript, you can run the schemas through the compatibility tool before you use them. You can then use purely v4-tools for your actual validation/whatever.