I'm calling orion with a Geo-location filter, like this one:
(curl localhost:1026/v1/queryContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "City",
"isPattern": "true",
"id": ".*"
}
],
"restriction": {
"scopes": [
{
"type" : "FIWARE::Location",
"value" : {
"circle": {
"centerLatitude": "40.418889",
"centerLongitude": "-3.691944",
"radius": "13500"
}
}
}
]
}
}
EOF
I read on the fiware orion documentation that the returned entities are returned by increasing entity/registration creation time. Like is explained here
There is the possibility to change this behaviour?
Changing the order is not possible in NGSIv1, but in NGSIv2 it has been taken into account. Have a look to this issue in the fiware-orion repository in order to monitor the implementation status of the feature.
EDIT: since Orion 0.28.0 you can use the orderBy URL parameter to change this behaviour, both in NGSIv1 (see this piece of documentation) and NGSIv2 (see "Ordering results" section in the NGSIv2 specification).
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 have ELK cloud v. 7.13.2 and trying to create alert rule with slack action via REST API. This is my curl invocation:
curl -u ****** -s -H 'kbn-xsrf: true' -H 'Content-Type: application/json' https://***********.westeurope.azure.elastic-cloud.com:9243/api/alerting/rule -X POST -d #src/rules/cpu_utilization.json
I am expecting that new rule is created, but unfortunately I am getting following error:
{
"statusCode": 400,
"error": "Bad Request",
"message": "Invalid action groups: default"
}
The contents of src/rules/cpu_utilization.json are:
{
"params": {
"nodeType": "host",
"criteria": [
{
"comparator": ">",
"timeSize": 1,
"metric": "cpu",
"threshold": [
80
],
"timeUnit": "m"
}
],
"sourceId": "default"
},
"consumer": "alerts",
"schedule": {
"interval": "1m"
},
"tags": [],
"name": "CPU2",
"throttle": "1000d",
"enabled": true,
"rule_type_id": "metrics.alert.inventory.threshold",
"notify_when": "onThrottleInterval",
"actions": [
{
"group": "default",
"id": "fce4c27f-d22a-4209-858c-253a06511c1b",
"params": {
"message": "{{alertName}} - {{context.group}} is in a state of {{context.alertState}}\n\nReason:\n{{context.reason}}"
}
}
]
}
Documentation says clearly:
Properties of the action objects:
group
(Required, string) Grouping actions is recommended for escalations for different types of alerts. If you don’t need this, set this value to default.
Is this a bug in ELK or I am doing something wrong? I am able to use API for other purposes, like listing rules, deleting rules etc. I am also capable of creating a rule without an action, but this doen`t seem to be too useful...
OKAY, I got an answer from ELK support. Apparently, you can use another endpoint to list all rule types GET /api/alerting/rule_types. Then you need to find your type and lookup property default_action_group_id - it will hold the correct value. Eg. in the above example it was:
"default_action_group_id": "metrics.inventory_threshold.fired"
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.
Using this script:
#!/bin/bash
(curl http://orionip:1026/v1/subscribeContext -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' --header 'fiware-service: service' --header 'fiware-servicepath: /servicepath' \
-d #- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "Sensor",
"isPattern": "true",
"id": "Parquimetro:.*"
}
],
"attributes": [
"recaudacion"
],
"reference": "http://cometip:80/notify",
"duration": "P4Y",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"recaudacion", "numeroTiques"
]
}
],
"throttling": "PT24H"
}
EOF
Makes a subscription for 170 entities (Parquimetro:1, Parquimetro:2, Parquimetro:3, ..., Parquimetro:170) to notify Comet for storing historical data, but only the first 20 entities got notified. I need it to notify all entities (which are right now 170, not 20).
Using /v1/subscribeContext?limit=200 doesn't help either.
Any idea?
There is an open issue at Orion github about it from time ago.
Currently Orion behaves that way, but there is a workaround in place: do a (paginated) query to get all entities just before doing the subscription. It could happen some "race condition" if some update arrives since the query and the subscription, but, depending on the use case, it may suffice.
we are testing the subscription functionality using the APIv2. We are following the guidelines described in http://telefonicaid.github.io/fiware-orion/api/v2/ . We are able to create a correct subscription but the format of the notification messages that we received is not what we expected. The format of these messages is like the APIv1 version. Is this the expected behavior?
We are using the Docker image from https://hub.docker.com/r/fiware/orion/.
Version information about the build:
{
"orion" : {
"version" : "1.0.0-next",
"uptime" : "0 d, 1 h, 28 m, 47 s",
"git_hash" : "a729812c45d2749fffbc19add17631b2fffc8797",
"compile_time" : "Fri Apr 8 10:05:55 UTC 2016",
"compiled_by" : "root",
"compiled_in" : "838a42ae8431"
}
}
Steps to reproduce:
Create an entity:
(curl -X POST http://<cb_url>:<cb_port>/v2/entities?options=keyValues -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"type":"Room",
"id": "test",
"humidity":40
}
EOF
Create a subscription:
(curl -X POST http://<cb_url>:<cb_port>/v2/subscriptions -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"description": "One subscription to rule them all",
"subject": {
"entities": [
{
"idPattern": ".*",
"type": "Room"
}
],
"condition": {
"attributes": [
"humidity"
],
"expression": {
"q": "humidity>40"
}
}
},
"notification": {
"callback": "http://192.168.99.1:5000",
"attributes": [
"humidity"
],
"throttling": 5
},
"expires": "2016-05-05T14:00:00.00Z"
}
EOF
Update attribute.:
(curl -X PUT <cb_url>:<cb_port>/v2/entities/test/attrs/humidity/value -s -S --header 'Content-Type: application/json' \
--header 'Accept: application/json' -d #- | python -mjson.tool) <<EOF
{
"value": 50
}
EOF
We get the notification with the following format:
{u'contextResponses': [
{u'contextElement': {
u'attributes': [{
u'name': u'humidity',
u'type': u'none',
u'value': {u'value': 50}
}],
u'id': u'test',
u'isPattern': u'false',
u'type': u'Room'
},
u'statusCode': {
u'code': u'200',
u'reasonPhrase': u'OK'
}}],
u'originator': u'localhost',
u'subscriptionId': u'5707b72882fc213130f4e5b9'}
NGSIv2 notification formats have not been yet implemented (at Orion 1.0.0). Note that NGSIv2 is yet in beta status and sometimes the specification (where the new notification format has been defined) is a step forward the implementation.
There is a github issue about this, to which you can subscribe in order to know when this feature gets implemented.
EDIT: NGSIv2 notification formats have been implemented in Orion 1.1.0.