Elasticsearch index mapping format,
"mappings": {
"dynamic": "true",
"_source": {"enabled": "true"},
"properties": {
"topic": {"type": "text"},
"value": {"type": "text"},
"date": {"type": "date", "format": "YYYY-MM-DD"}
}
}
search query is,
curl -X GET "localhost:9200/sample_index/_search?pretty" -H 'Content-Type: application/json' -d' {"query": {"bool": {"filter": [{"range": {"date": {"gte": "2023-01-14", "lte": "2023-01-16"}}}]}}}'
I should have got the result based on filter, but i am getting all the documents saved for index sample_index , not getting result based on date filter
tried with must as well,
curl -X GET "localhost:9200/sample_index/_search?pretty" -H 'Content-Type: application/json' -d' {"query": {"bool": {"must": [{"range": {"date": {"gte": "2023-01-14", "lte": "2023-01-16"}}}]}}}'
no luck :(
Will appreciate your help
replace date format "YYYY-MM-DD" to "yyyy-MM-dd"
Related
I am having trouble using Clockify's REST API to filter a detailed report for single project.
Filter Section (see below) of the relevant documentation shows:
"projects": null,
My first question is what "null" means in this context? Does it mean that one cannot use this field?
// FILTERS (OPTIONAL)
"users": {
"ids": ["45fd36c4b0798777049512e2"],
"contains": "CONTAINS",
"status": "ALL"
},
"invoicingState": "ALL",
"approvalState": "ALL",
"userGroups": null,
"clients": null,
--> "projects": null,
"tasks": null,
"tags": {
"ids": ["45fd36c4b0798777049512e2"],
"containedInTimeentry": "DOES_NOT_CONTAIN",
"status": "ALL"
},
An attempt to filter by "project id" or "project name" (below)
curl --request POST \
--url https://reports.api.clockify.me/v1/workspaces/workspace_id/reports/detailed \
--header 'content-type: application/json' \
--header 'X-Api-Key: xxxxxxxxxxxxxxxxxxxxxx' \
--data-raw '{
"dateRangeStart": "2022-06-01T00:00:00.000Z", \
"dateRangeEnd": "2022-10-31T23:59:59.999Z",\
"detailedFilter": { \
"page": 1, \
"pageSize": 50
}, \
----> projects": {["id": ["project_id"]}, \
or
----> projects": {["name": ["project_name"]}, \
"tags": {"ids": ["tag_id"]},
"exportType": "CSV"
}'
returns an empty report (header line only).
"Project","Client","Description","Task","User","Group","Email","Tags","Billable","Start Date","Start Time","End Date","End Time","Duration (h)","Duration (decimal)","Billable Rate (AUD)","Billable Amount (AUD)"
Removing line
"projects": {["id": ["project_id"]},
or replacing the above with:
"projects": null,
or
"non_exiting_key": null,
returns a detailed report for all projects. This tells me that "filtering for project" kind of works and I am not using a correct semantics.
Can anyone see where the problem may be?
Thank you in advance!
I am sending this to Orion:
curl --location --request POST 'http://xx.xx.xx.xx:1026/ngsi-ld/v1/entities/' \
--header 'link: <https://smartdatamodels.org/context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
--header 'Content-Type: application/json' \
--data-raw '{
"id": "urn:ngsi-ld:Device:01",
"type": "Device",
"description": "L9A",
"category": {
"value": ["sensor"]
},
"serialNumber": {
"value": "38479144"
},
"controlledProperty": {
"value": ["Water Supply"]
},
"owner": {
"value": ["Me"]
},
"location": {
"type": "Point",
"coordinates": [20.200416, 30.261837]
}
}'
and I get this:
Error 400: Bad Request
{
"type": "https://uri.etsi.org/ngsi-ld/errors/BadRequestData",
"title": "Attribute must be a JSON object",
"detail": "description"
}
I validated by json object and it passes. What am I doing wrong?
Look a little closer at your error message, especially:
detail": "description"
That's the name of the attribute that is not a JSON object:
"description": "L9A"
If you change it to:
"description": {
"type": "Property",
"value": "L9A"
}
that part should be OK.
But, the type member seems to be missing for all your attributes.
you'll need to add "type": "Property" to all of them, except "location" that's a GeoProperty:
"location": {
"type": "GeoProperty",
"value": {
"type": "Point",
"coordinates": [20.200416, 30.261837]
}
}
Perhaps spend some time reading the NGSI-LD specification?
https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.04.02_60/gs_CIM009v010402p.pdf
What is the best endpoint to subscribe Cygnus to Orion CB for subscription change: /v1/subscribeContext or /v2/subscriptions please?
Tried this, no response:
$(curl localhost:1026/v1/subscribeContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Fiware-Service: smartGondor' --header 'Fiware-ServicePath: /gardens' -d #- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "Device",
"isPattern": "false",
"id": "raspiSensorTV"
}
],
"attributes": [
"Temperature Sensor",
"TimeInstant"
],
"reference": "http://localhost:5050/notify",
"duration": "P1M",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"Temperature Sensor"
]
}
],
"throttling": "PT1S"
}
EOF
This seems to work, but not sure if its the best way to go, as no observations are received.
$curl -iX POST \
'http://localhost:1026/v2/subscriptions' \
-H 'Content-Type: application/json' \
-H 'fiware-service: smartGondor' \
-H 'fiware-servicepath: /gardens' \
-d '{
"description": "Notify Cygnus of all context changes",
"subject": {
"entities": [
{
"idPattern": ".*",
"type": "Device"
}
]
},
"notification": {
"http": {
"url": "http://cygnus:5050/notify"
},
"attrsFormat": "legacy"
},
"throttling": 5
}'
At the present moment Cygnus doesn't support NGSIv2 notifications so you need to use the NGSIv1 endpoint. You can find more information in this section of Cygnus documentation and this other.
I'm trying to use Orion notification to send SMS with Plivo.
This is how I send an SMS directly with Plivo:
curl -X POST https://api.plivo.com/v1/Account/MAMDA5ZDJIMDM1/Message/ -L -u MAMDA5ZDJIM:YzhiNDJjODNhNDkxMjhiYTgxZD -H 'Content-Type: application/json' -d #- <<EOF
{
"src": "0039414141414",
"dst": "0039414747111",
"text": "test SMS"
}
EOF
How should I encode it in Orion? I tried:
curl localhost:1026/v2/subscriptions -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' -d #- <<EOF
{
"description": "A subscription to get info about WS_UPPA_Sensor2",
"subject": {
"entities": [
{
"id": "Sensor1",
"type": "SensingDevice"
}
],
"condition": {
"attrs": [
"temperature"
]
}
},
"notification": {
"httpCustom": {
"url": "https://api.plivo.com/v1/Account/MAMDA5ZDJIMDM1NZVMZD/Message/",
"headers": {
"Authorization": "Basic TUFNREE1WkRKSU1ETTFOWlZNWkQ6WXpoaU5ESmpPRE5oTkRreE1qaGlZVGd4WkRkaE5qYzNPV1ZsTnpZMA=="
},
"payload": "{%22src%22%3A%2200393806412092%22%2C%22dst%22%3A%2200393806412093%22%2C%22text%22%3A%22test%20SMS%20from%20Waziup%22}"
},
"attrs": [
"temperature"
]
},
"expires": "2040-01-01T14:00:00.00Z",
"throttling": 5
}
EOF
Is there another way than percent encoding?
URL encoding (I understand is the one you refer by "percent encoding") is the only one which have an special treatment in custom notifications (details described as part of the Orion documentation).
In fact, taking into account the existing one is complete (I mean, any text can be expressed in the terms of URL encoding) there is no need of adding any other.
I followed the official documentation about cygnus and orion. All generic enablers are deployed correctly, without errors in their log files. But something strange happens, Orion never notifies Cygnus.
To test this mechanism I followed the example with Car entity provided in the official documentation.
My entity creation bash script:
(curl $1:1026/v1/updateContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"contextElements": [
{
"type": "Car",
"isPattern": "false",
"id": "Car1",
"attributes": [
{
"name": "speed",
"type": "integer",
"value": "75"
},
{
"name": "fuel",
"type": "float",
"value": "12.5"
}
]
}
],
"updateAction": "APPEND"
}
EOF
My entity subscription bash script:
(curl $1:1026/v1/subscribeContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Fiware-Service: vehicles' --header 'Fiware-ServicePath: /4wheels' -d #- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "Car",
"isPattern": "false",
"id": "Car1"
}
],
"attributes": [
"speed",
"oil_level"
],
"reference": "http://$2:5050/notify",
"duration": "P1M",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"speed"
]
}
],
"throttling": "PT1S"
}
EOF
My entity update bash script:
(curl $1:1026/v1/updateContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"contextElements": [
{
"type": "Car",
"isPattern": "false",
"id": "Car1",
"attributes": [
{
"name": "speed",
"type": "integer",
"value": $2
}
]
}
],
"updateAction": "UPDATE"
}
EOF
Note: Orion responds to all requests.
After executing these scripts, cygnus must receive reported information from orion and save it in the database, but nothing happens.
Neither in /var/log/cygnus/cygnus.log file or in /var/log/contextBroker/contextBroker.log file are reported any information about orion notification.
Note: If I use the notify.sh script provided in the official documentation, Cygnus works well and saves all data in the database.
Note: I read in other questions problems about open ports but those don't apply to mine.
EDIT 1
After I subscribe the orion, the response is:
{
"subscribeResponse": {
"duration": "P1M",
"subscriptionId": "563e12b4f4d8334d599753e0",
"throttling": "PT1S"
}
}
And when I update anentity, orion returns it:
{
"contextResponses": [
{
"contextElement": {
"attributes": [
{
"name": "speed",
"type": "integer",
"value": ""
}
],
"id": "Car1",
"isPattern": "false",
"type": "Car"
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
]
}
To GET entity from orion I used the following script:
(curl $1:1026/v1/queryContext -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "Car",
"isPattern": "false",
"id": "Car1"
}
]
}
EOF
Response:
{
"contextResponses": [
{
"contextElement": {
"attributes": [
{
"name": "fuel",
"type": "float",
"value": "12.5"
},
{
"name": "speed",
"type": "integer",
"value": "123"
}
],
"id": "Car1",
"isPattern": "false",
"type": "Car"
},
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
]
}
Note The speed value was updated with success.
Taking into account the Fiware-Service and Fiware-ServicePath headers in subscription request, it has been performeed in the "/4wheels" service path of the service "vehicles". However, entity creation request doesn't use such headers, so it is created in the default service path ("/") of the default service. Thus, the subscription is not "covering" the entity, so updates in the entity are not triggering notifications.
One solution to the problem would be to create the entity in the same service and service path of the subscription, i.e. "/4wheels" service path of the service "vehicles".
Please, check Orion official documentation about service and service path concepts.